Try to run AlienFxLite on Alienware M17 R4, but no controller available yet.

$ java -jar AlienFX.jar
Device found: 187c:0530
and a window pop up and said
"Device unknow: no controller available. Please report this issue..."
So I am here reporting. ^_^
===== 10 Minuts Later ========
I try to run my M17 R4 (1748) as M17x or M17x R3 by modify the static pids in /src/java/uk/co/progger/alienFXLite/led/LEDController.java.
The GUI is there, but when i try to apply modify of color, it said:
"Error occured while trying to communicate with the AlienFX device: Data length should be 9 but was -9"
===== 10 Minuts Later ========
I replace "return write(data);" with "return 9;" in LEDController.java, the prev error msg is gone.
But, there is no reaction after I click the apply button or the "Reset AlienFX" in the menu.

I try to run my M17 R4 (1748) as M17x or M17x R3 by modify the static pids in /src/java/uk/co/progger/alienFXLite/led/LEDController.java.
The GUI is there, but when i try to apply modify of color, it said:
"Error occured while trying to communicate with the AlienFX device: Data length should be 9 but was -9"

I try to run my M17 R4 (1748) as M17x or M17x R3 by modify the static pids in /src/java/uk/co/progger/alienFXLite/led/LEDController.java.
The GUI is there, but when i try to apply modify of color, it said:
"Error occured while trying to communicate with the AlienFX device: Data length should be 9 but was -9"

I failed with this, and my keyboard light were still blue.

I failed with this, and my keyboard light were still blue.

I am sorry!!! I thought my Alienware 1748 is M17x R4, but NOT...
1748 is a Chinese version, maybe... there must be a lot of differences.
I gave up. :cry:

I am sorry!!! I thought my Alienware 1748 is M17x R4, but NOT...
1748 is a Chinese version, maybe... there must be a lot of differences.
I gave up. :cry:

This is fixed with my pull request

@liusida can you confirm that the PR from @jakeday solved your issue (merged to master)?

I have the Alienware 17 R4 and the newest source does not work with this machine, but it does get much further along than the source before about 14 days ago. I was just trying to send the email below to someone on this team.
Hello, I have been watching your alienfx project on github. After your recent updates, I have been able to get the project running on my hardware. I have an Alienware 17 R4, that I recently got in Dec 2016. I would very much like to use your software to control the lights on my hardware. However, it does not quite work just yet. Is there anything I could do to help you incorporate my hardware into your software? I can send you and machine information that might be needed. I have been a developer for many years, and I used to write Java code. It has been a while since I have, but I am sure I could help add the controller that is needed. However, I do not know much about C++, and it looks like there are some pretty specific hex codes that I don't understand.
Please let me know, as I would really love to be able to use this in Linux on my laptop.

@vowell When you run it, what device is reported as found in the console? Should be something like Device found: 187c:0530. Also, at which point are you seeing problems now?

Yes it displays Device found: 187c:0530. However when applying, it gives the error in the screencap.

I have a similar issue. I'm running an Alienware 15R2 and I'd like to help add it to the list of supported models if possible. Device found for me: 187c:0528

I, too, have this issue.
My sudo lsusb -v is as follows:
Bus 001 Device 003: ID 187c:0530 Alienware Corporation
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               0.02
  bDeviceClass            0
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x187c Alienware Corporation
  idProduct          0x0530
  bcdDevice            0.00
  iManufacturer           1 Alienware
  iProduct                2 AW1517
  iSerial                 3 02.90
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           41
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.01
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      56
         Report Descriptors:
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x000a  1x 10 bytes
        bInterval              10
can't get debug descriptor: Resource temporarily unavailable
Device Status:     0x0000
  (Bus Powered)

I'm running Arch Linux 4.11.3.
I'm also happy to provide any additional information or runtime tests that might be useful :)

I'm having the same problem in Linux Mint 18.1
Alienware M17x R4

Interestingly, I am still able to turn off all lights by using Help > Reset AlienFX.

By adding a line to ProfileSelectionPanel.java, I was able to obtain the following stack trace of the Data Length should be 9 but was -9 error:
uk.co.progger.alienFXLite.led.AlienFXCommunicationException: Data length should be 9 but was -9
        at uk.co.progger.alienFXLite.led.AlienFXController.setSpeed(AlienFXController.java:218)
        at uk.co.progger.alienFXLite.alienfx.AlienFXEngine.applyProfile(AlienFXEngine.java:66)
        at uk.co.progger.alienFXLite.gui.ProfileSelectionPanel$ApplyListener.actionPerformed(ProfileSelectionPanel.java:193)
        at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022)
        at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348)
        at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
        at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
        at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:252)
        at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:289)
        at java.awt.Component.processMouseEvent(Component.java:6533)
        at javax.swing.JComponent.processMouseEvent(JComponent.java:3324)
        at java.awt.Component.processEvent(Component.java:6298)
        at java.awt.Container.processEvent(Container.java:2236)
        at java.awt.Component.dispatchEventImpl(Component.java:4889)
        at java.awt.Container.dispatchEventImpl(Container.java:2294)
        at java.awt.Component.dispatchEvent(Component.java:4711)
        at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4888)
        at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4525)
        at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4466)
        at java.awt.Container.dispatchEventImpl(Container.java:2280)
        at java.awt.Window.dispatchEventImpl(Window.java:2746)
        at java.awt.Component.dispatchEvent(Component.java:4711)
        at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
        at java.awt.EventQueue.access$500(EventQueue.java:97)
        at java.awt.EventQueue$3.run(EventQueue.java:709)
        at java.awt.EventQueue$3.run(EventQueue.java:703)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
        at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:90)
        at java.awt.EventQueue$4.run(EventQueue.java:731)
        at java.awt.EventQueue$4.run(EventQueue.java:729)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
        at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

The line that I added was e1.printStackTrace(); above existing line 195.

I edited the writeDebug method of LEDController.java as follows:
static int writeDebug(byte[] data){
	if(AlienFXProperties.isDebug){
		System.out.print("Writing");
		for(byte b : data){
			System.out.printf(" 0x%x", b);
		}

		int resp = write(data);
		System.out.printf(" - Received response %d", resp);
		System.out.println();
		return 9;
	}
	return write(data);
}

Then, trying to apply this configuration:

I receive the following debug output:
Device found: 187c:0530
Writing 0x2 0x6 0x0 0x0 0x0 0x0 0x0 0x0 0x0 - Received response -9
Writing 0x2 0x7 0x3 0x0 0x0 0x0 0x0 0x0 0x0 - Received response 9
Writing 0x2 0x8 0x1 0x0 0x0 0x0 0x0 0x0 0x0 - Received response 9
Writing 0x2 0x3 0x1 0x0 0x0 0x1 0xf0 0x0 0x0 - Received response 9
Writing 0x2 0x8 0x1 0x0 0x0 0x0 0x0 0x0 0x0 - Received response 9
Writing 0x2 0x4 0x0 0x0 0x0 0x0 0x0 0x0 0x0 - Received response 9
Writing 0x2 0x9 0x0 0x0 0x0 0x0 0x0 0x0 0x0 - Received response 9
Writing 0x2 0x7 0x4 0x0 0x0 0x0 0x0 0x0 0x0 - Received response 9
Writing 0x2 0x6 0x0 0x0 0x0 0x0 0x0 0x0 0x0 - Received response 9
Writing 0x2 0xe 0x0 0x64 0x0 0x0 0x0 0x0 0x0 - Received response -9
Writing 0x2 0x3 0x10 0x0 0x0 0x1 0xf0 0x0 0x0 - Received response 9
Writing 0x2 0x4 0x0 0x0 0x0 0x0 0x0 0x0 0x0 - Received response 9
Writing 0x2 0x5 0x0 0x0 0x0 0x0 0x0 0x0 0x0 - Received response 9

Interestingly, this has allowed me to actually change pretty much all of the lights on my Alienware 17 R4.
There are distinct quirks.
So long as I don't have anything set for the Standby Power Button, I can actually set and play around with the lights.

@mgruben thanks for your captures to AW17 work need to change much on this repo:
DATA_SIZE  is 12 bytes no 9
Color codes is full RGB now 255(0xFF) per color
I share  my  repo https://github.com/swarzesherz/alienware, this is only for AW17 R4 and maybe work in AW15 R3.
Touch bar only work if activate always on in BIOS, i don't now how make work auto

TODO: Power blink

SEND_DATA_SIZE could be set dynamically from the Java code (for now it is indeed hardcoded to 9).


WSL Terminal Line Endings

Put into terminal and then increase the window size:
printf "%*s\n" "$(tput cols)" "" | tr " " "X"
Line endings acts like they disappeared if the string length matches exactly the window columns.
The terminal has different behavior for columns +- 1.
The behavior does not depend on the type of shell.

I discovered this yesterday and wanted to report today, LOL.
There's more to the story.
First, let's note that most shells redraw their prompt after a resize, potentially overwriting some of the previously printed Xs, or just making it harder to follow what's happening. So the given line that's exactly as wide as the screen should be followed by some other lines to clearly see what's going on (e.g. just tap on Enter once or twice to get new prompts).
Then, let's observe that if you have a shorter line than the width, e.g. shorter by one:
printf "%*s\n" "$(( $(tput cols) - 1 ))" "" | tr " " "Y"

(followed by some other lines), and then you narrow the window, this line wraps one step too early (e.g. in this case immediately as you shrink the window by 1), introducing an unnecessary empty line below (which in turn copy-pastes as tons of spaces).
Another thing I noticed is that double clicking stops the selection at the current physical row boundary, rather than selecting an entire word.
I haven't dug into the code yet, but I have a guts feeling that we might be seeing a conceptionally unusual and problematic handling (or rather: lack thereof) of newlines, rather than a simple off-by-one.
I have the feeling (and apologies if I'm wrong, I'm planning to explore the code soon) that it's not remembered whether a row ends in a newline or not; instead, the presence or absence of a trailing speical character ("unused space" or so), which occupies its own column, is used for that. Or something similar.
What most terminals do, and I believe is the right thing, is that they remember for each physical row whether it ended in an explicit newline or an overflow. This bit belongs to the row itself, rather than a particular cell thereof, and is obviously not directly visible (you could somehow display it in some debug mode). This information is used for multiple things:

Rewrapping on a resize
Selecting on double click (across physical wrap within a logical line, but not across newline characters)
Selecting entire logical lines on triple click
Automatically recognizing text patterns, e.g. URLs or user supplied regexps
Running the BiDi algorithm on logical lines as units (i.e. mapping them to Unicode Bidi Algorithm's notion of "paragraph")

Probably there's no official specification anywhere how exactly the line ending status needs to be set. It's mostly common sense, with the only nontrivial bit: a NL character does not set the line to end in an explicit newline, it leaves its state unchanged. My BiDi proposal also provides an overview of this, and then refines the behavior for some special cases.
I think that going with this traditional, well proven behavior of tracking newlines is the key to address multiple issues, e.g. rewrapping's off-by-one as reported here, proper spaces vs. newlines at copy-pasting (e.g. #2944), proper semantical behavior on double click, and to prepare for other cool features WT is about to have.

Just dropping in to say: yeah, we don't do wrapping correctly in Windows Terminal. Since it's a client of conhost, and conhost does wrapping somewhat okay, WT isn't yet enlightened here.
There's a lot of intricacies in the whole ConPTY layer -- it should almost certainly un-wrap wrapped lines before it sends them, and let the terminal emulator on the other end wrap them, but we can't do that until #780... WT won't even wrap right now (evidenced by #2588 #3094).
Curious thing about newlines in the traditional console is that using SetConsoleMode to turn off ENABLE_WRAP_AT_EOL_HANDLING and perhaps DISBALE_NEWLINE_AUTO_RETURN will impact the behavior of at-end and off-end line writing and wrapping.
Also of interest: #2089 (related to how we measure the righthand side of the screen).

For pseudo terminal (PTY) such as screen pseudo terminal slave (PTS) works properly.
This unexpected behavior occurs only for the default teletypewriter (TTY).

Incidentally, this is probably the same root cause as the issue with powershell where when you type off the edge of the screen it wraps one line early but the cursor jumps to the wrong place, and then when you backspace over it it destroys the known universe.


Add 'prepack' and 'postpack' commands

    debinate prepack  - 1st half of 'debinate package': install python things
    debinate postpack - 2nd half of 'debinate package': create the debian package

I'm planning to pull this in to remind me of the problem space identified here and put some more effort into adjusting the flow to accommodate it. In a nutshell, what this addresses is the case where a Python project has either generated or other static resources that need to be packaged alongside the project when it's installed. The workaround that we've applied in the past was hooking the install from the setup.py and calling out to a script that copied files around. It's not at all a straightforward solution.
Here's what I'm currently thinking through adding:
debinate clear

This will wipe only the build and target folders, leaving the cache folder intact. Most of the time, you'll want to do this to avoid having to rebuild the virtualenv. This method is long overdue so we can take better advantage of the virtualenv cache. It's also more necessary because of the following addition:
debinate prepare

This will wipe the build and target folders (the same as debinate clear) and regenerate their contents. After running this, one can further adjust paths and inject files into the target folder and have them added to the final debinate package'd .deb file. This should handle the case described above where we want access to the root folder structure after the virtualenv has been created and everything is about to be rolled up into a .deb file.
However, I'm also thinking through how the following functionality should change as well:
debinate package

This command now needs to detect whether the prepare command has run otherwise it'll try to wipe the build and target folders (that we might have tinkered with after running prepare). Thus, we will need to no longer wipe the build and target folders in package. In this way, we can safely run package and have it call out to prepare when the build or target folders don't exist and mostly maintain backward compatibility. Previously, it would have wiped the build and target folders no matter what we did. Also, the original flow of wiping the build and target flows would still exist, but instead it would become:
debinate prepare
debinate package

And finally, this flow stays the same, and continues to completely wipe and rebuild the project with no caching:
debinate clean
debinate package


pythonPackages.apache-airflow: 1.10.5 -> 1.10.14

Motivation for this change
Update apache-airflow to the latest version, to fix CVE security issues (See #106671).
Closes #106671.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[x] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Ok, got a clean build of apache-airflow. This is ready for review.

This looks to me better than the original as it removes the need for custom patching. LGTM

This is a semi-automatic executed nixpkgs-review which is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 106696 run on x86_64-linux 1

6 packages failed to build and are new build failures:

apache-airflow: log was empty
(python37Packages.apache-airflow): log was empty
python37Packages.sqlalchemy-jsonfield: log https://termbin.com/mm8g
python38Packages.apache-airflow: log was empty
python38Packages.sqlalchemy-jsonfield: log https://termbin.com/tysq
python39Packages.sqlalchemy-jsonfield: log https://termbin.com/som0

9 packages built:

python37Packages.cattrs
python37Packages.hdfs
python37Packages.python-nvd3
python38Packages.cattrs
python38Packages.hdfs
python38Packages.python-nvd3
python39Packages.cattrs
python39Packages.hdfs
python39Packages.python-nvd3

This is a semi-automatic executed nixpkgs-review which is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 106696 run on x86_64-linux 1

6 packages failed to build and are new build failures:

apache-airflow: log was empty
(python37Packages.apache-airflow): log was empty
python37Packages.sqlalchemy-jsonfield: log https://termbin.com/mm8g
python38Packages.apache-airflow: log was empty
python38Packages.sqlalchemy-jsonfield: log https://termbin.com/tysq
python39Packages.sqlalchemy-jsonfield: log https://termbin.com/som0

9 packages built:

python37Packages.cattrs
python37Packages.hdfs
python37Packages.python-nvd3
python38Packages.cattrs
python38Packages.hdfs
python38Packages.python-nvd3
python39Packages.cattrs
python39Packages.hdfs
python39Packages.python-nvd3

@bhipple @costrouc @ingenieroariel Can anyone of you review this?

@bhipple @costrouc @ingenieroariel Can anyone of you review this?

This is a semi-automatic executed nixpkgs-review which is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 106696 run on x86_64-darwin 1

4 packages failed to build and are new build failures:

apache-airflow: log https://termbin.com/v1t4
(python37Packages.apache-airflow): log was empty
python38Packages.apache-airflow: log was empty
python38Packages.cattrs: log https://termbin.com/vsqk

11 packages built:

python37Packages.cattrs
python37Packages.hdfs
python37Packages.python-nvd3
python37Packages.sqlalchemy-jsonfield
python38Packages.hdfs
python38Packages.python-nvd3
python38Packages.sqlalchemy-jsonfield
python39Packages.cattrs
python39Packages.hdfs
python39Packages.python-nvd3
python39Packages.sqlalchemy-jsonfield

The following issues got detected with the above build packages.
Please fix at least the ones listed with your changed packages:
apache-airflow:

Please consider this feature to be alpha.
A substituteInPlace with an unused --replace got detected:
substituteStream(): WARNING: pattern 'jinja2>=2.10.1, <2.11.0' doesn't match anything in file 'setup.py'

Please check the offending substituteInPlace for typos or changes in source.

This is a semi-automatic executed nixpkgs-review which is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 106696 run on x86_64-darwin 1

4 packages failed to build and are new build failures:

apache-airflow: log https://termbin.com/v1t4
(python37Packages.apache-airflow): log was empty
python38Packages.apache-airflow: log was empty
python38Packages.cattrs: log https://termbin.com/vsqk

11 packages built:

python37Packages.cattrs
python37Packages.hdfs
python37Packages.python-nvd3
python37Packages.sqlalchemy-jsonfield
python38Packages.hdfs
python38Packages.python-nvd3
python38Packages.sqlalchemy-jsonfield
python39Packages.cattrs
python39Packages.hdfs
python39Packages.python-nvd3
python39Packages.sqlalchemy-jsonfield

The following issues got detected with the above build packages.
Please fix at least the ones listed with your changed packages:
apache-airflow:

Please consider this feature to be alpha.
A substituteInPlace with an unused --replace got detected:
substituteStream(): WARNING: pattern 'jinja2>=2.10.1, <2.11.0' doesn't match anything in file 'setup.py'

Please check the offending substituteInPlace for typos or changes in source.

This is a semi-automatic executed nixpkgs-review which is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 106696 run on x86_64-linux 1

3 packages failed to build and are new build failures:

apache-airflow: log https://termbin.com/nv3l
(python37Packages.apache-airflow): log was empty
python38Packages.apache-airflow: log https://termbin.com/acjf

12 packages built:

python37Packages.cattrs
python37Packages.hdfs
python37Packages.python-nvd3
python37Packages.sqlalchemy-jsonfield
python38Packages.cattrs
python38Packages.hdfs
python38Packages.python-nvd3
python38Packages.sqlalchemy-jsonfield
python39Packages.cattrs
python39Packages.hdfs
python39Packages.python-nvd3
python39Packages.sqlalchemy-jsonfield

The following issues got detected with the above build packages.
Please fix at least the ones listed with your changed packages:
apache-airflow:

Please consider this feature to be alpha.
A substituteInPlace with an unused --replace got detected:
substituteStream(): WARNING: pattern 'jinja2>=2.10.1, <2.11.0' doesn't match anything in file 'setup.py'

Please check the offending substituteInPlace for typos or changes in source.

python38Packages.apache-airflow:

Please consider this feature to be alpha.
A substituteInPlace with an unused --replace got detected:
substituteStream(): WARNING: pattern 'jinja2>=2.10.1, <2.11.0' doesn't match anything in file 'setup.py'

Please check the offending substituteInPlace for typos or changes in source.

This is a semi-automatic executed nixpkgs-review which is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 106696 run on x86_64-linux 1

3 packages failed to build and are new build failures:

apache-airflow: log https://termbin.com/nv3l
(python37Packages.apache-airflow): log was empty
python38Packages.apache-airflow: log https://termbin.com/acjf

12 packages built:

python37Packages.cattrs
python37Packages.hdfs
python37Packages.python-nvd3
python37Packages.sqlalchemy-jsonfield
python38Packages.cattrs
python38Packages.hdfs
python38Packages.python-nvd3
python38Packages.sqlalchemy-jsonfield
python39Packages.cattrs
python39Packages.hdfs
python39Packages.python-nvd3
python39Packages.sqlalchemy-jsonfield

The following issues got detected with the above build packages.
Please fix at least the ones listed with your changed packages:
apache-airflow:

Please consider this feature to be alpha.
A substituteInPlace with an unused --replace got detected:
substituteStream(): WARNING: pattern 'jinja2>=2.10.1, <2.11.0' doesn't match anything in file 'setup.py'

Please check the offending substituteInPlace for typos or changes in source.

python38Packages.apache-airflow:

Please consider this feature to be alpha.
A substituteInPlace with an unused --replace got detected:
substituteStream(): WARNING: pattern 'jinja2>=2.10.1, <2.11.0' doesn't match anything in file 'setup.py'

Please check the offending substituteInPlace for typos or changes in source.

@bhipple @costrouc @ingenieroariel Can anyone of you review this? It's a big change and it worries me that it seems to bitrot already, while there a security issue with the whole thing.

@mweinelt I can run the latest version this weekend to verify that the binary and libraries work as expected. Airflow has a lot of dependencies and I am afraid this kind of work will be needed before every NixOS release. :/

@bhipple @costrouc @ingenieroariel Can anyone of you review this? It's a big change and it worries me that it seems to bitrot already, while there a security issue with the whole thing.

@mweinelt I can run the latest version this weekend to verify that the binary and libraries work as expected. Airflow has a lot of dependencies and I am afraid this kind of work will be needed before every NixOS release. :/

Airflow has a lot of dependencies and I am afraid this kind of work will be needed before every NixOS release. :/

This is not about a pre-release bump, this is about at least three CVEs that need to be addressed during the release cycle. Please see https://github.com/NixOS/nixpkgs/issues/106671.

Airflow has a lot of dependencies and I am afraid this kind of work will be needed before every NixOS release. :/

This is not about a pre-release bump, this is about at least three CVEs that need to be addressed during the release cycle. Please see https://github.com/NixOS/nixpkgs/issues/106671.

@mweinelt thanks for clearing up my confusion.
@drewrisinger I had to add this commit for it to build in OSX: https://github.com/piensa/nixpkgs/commit/fa9fc16aca8d44689fa6f6739aea5e3abfa7c067
I used this shell.nix to try things out:
let
  pkgs = import (fetchTarball "https://github.com/piensa/nixpkgs/archive/dr-pr-update-airflow.tar.gz") {};
in pkgs.stdenv.mkDerivation rec {
  name = "composer";
  src = ./.;
  buildInputs = with pkgs; [
    apache-airflow
  ];
}

Once it built, I created a sample dag, by creating a dags subfolder within it and this file in there simple.py:
from __future__ import print_function

import datetime

from airflow import models
from airflow.operators import bash_operator
from airflow.operators import python_operator

default_dag_args = {
    # The start_date describes when a DAG is valid / can be run. Set this to a
    # fixed point in time rather than dynamically, since it is evaluated every
    # time a DAG is parsed. See:
    # https://airflow.apache.org/faq.html#what-s-the-deal-with-start-date
    'start_date': datetime.datetime(2021, 1, 18),
}

# Define a DAG (directed acyclic graph) of tasks.
# Any task you create within the context manager is automatically added to the
# DAG object.
with models.DAG(
        'daily_hello_world',
        schedule_interval=datetime.timedelta(days=1),
        default_args=default_dag_args) as dag:
    def greeting():
        import logging
        logging.info('Hello World!')

    # An instance of an operator is called a task. In this case, the
    # hello_python task calls the "greeting" Python function.
    hello_python = python_operator.PythonOperator(
        task_id='hola',
        python_callable=greeting)

    # Likewise, the goodbye_bash task calls a Bash script.
    goodbye_bash = bash_operator.BashOperator(
        task_id='chao',
        bash_command='echo Goodbye.')

    # Define the order in which the tasks complete by using the >> and <<
    # operators. In this example, hello_python executes before goodbye_bash.
    hello_python >> goodbye_bash

With that, I set the airflow home to the folder where I had the checkout (not a great practice, but works for this test):
export AIRFLOW_HOME="$(pwd)"
and created the sqlite database needed before starting airflow:
airflow db init
This creates a few files, but one of them has a value that does not work with the Werkzeug version in this PR, see: https://github.com/apache/airflow/pull/11873/
so we need to manually change the following in the generated airflow.cfg:
# Set samesite policy on session cookie
cookie_samesite = Lax

and then run the webserver and navigated to localhost:8080 to find this:

In order for the sample task to actually run, we need to run airflow scheduler on a new terminal and using the same folder / env vars.
Then we can trigger the task manually on the UI:

and wait for evidence on the scheduler output that the task is running:

Functionality wise, and with some small modifications this PR looks good to me.

@mweinelt thanks for clearing up my confusion.
@drewrisinger I had to add this commit for it to build in OSX: https://github.com/piensa/nixpkgs/commit/fa9fc16aca8d44689fa6f6739aea5e3abfa7c067
I used this shell.nix to try things out:
let
  pkgs = import (fetchTarball "https://github.com/piensa/nixpkgs/archive/dr-pr-update-airflow.tar.gz") {};
in pkgs.stdenv.mkDerivation rec {
  name = "composer";
  src = ./.;
  buildInputs = with pkgs; [
    apache-airflow
  ];
}

Once it built, I created a sample dag, by creating a dags subfolder within it and this file in there simple.py:
from __future__ import print_function

import datetime

from airflow import models
from airflow.operators import bash_operator
from airflow.operators import python_operator

default_dag_args = {
    # The start_date describes when a DAG is valid / can be run. Set this to a
    # fixed point in time rather than dynamically, since it is evaluated every
    # time a DAG is parsed. See:
    # https://airflow.apache.org/faq.html#what-s-the-deal-with-start-date
    'start_date': datetime.datetime(2021, 1, 18),
}

# Define a DAG (directed acyclic graph) of tasks.
# Any task you create within the context manager is automatically added to the
# DAG object.
with models.DAG(
        'daily_hello_world',
        schedule_interval=datetime.timedelta(days=1),
        default_args=default_dag_args) as dag:
    def greeting():
        import logging
        logging.info('Hello World!')

    # An instance of an operator is called a task. In this case, the
    # hello_python task calls the "greeting" Python function.
    hello_python = python_operator.PythonOperator(
        task_id='hola',
        python_callable=greeting)

    # Likewise, the goodbye_bash task calls a Bash script.
    goodbye_bash = bash_operator.BashOperator(
        task_id='chao',
        bash_command='echo Goodbye.')

    # Define the order in which the tasks complete by using the >> and <<
    # operators. In this example, hello_python executes before goodbye_bash.
    hello_python >> goodbye_bash

With that, I set the airflow home to the folder where I had the checkout (not a great practice, but works for this test):
export AIRFLOW_HOME="$(pwd)"
and created the sqlite database needed before starting airflow:
airflow db init
This creates a few files, but one of them has a value that does not work with the Werkzeug version in this PR, see: https://github.com/apache/airflow/pull/11873/
so we need to manually change the following in the generated airflow.cfg:
# Set samesite policy on session cookie
cookie_samesite = Lax

and then run the webserver and navigated to localhost:8080 to find this:

In order for the sample task to actually run, we need to run airflow scheduler on a new terminal and using the same folder / env vars.
Then we can trigger the task manually on the UI:

and wait for evidence on the scheduler output that the task is running:

Functionality wise, and with some small modifications this PR looks good to me.


Moved max_amount to Paypal::Express::Request::setup

Moved max_amount from Paypal::Express::Request::agree! to Paypal::Express::Request::setup
According to the PayPal documentation, MAXAMT belongs with
[SetExpressCheckout](https://developer.paypal.com/docs/classic/api/merch
ant/SetExpressCheckout_API_Operation_NVP/) and not
[CreateBillingAgreement](https://developer.paypal.com/docs/classic/api/m
erchant/CreateBillingAgreement_API_Operation_NVP/).

@nov Any way I can help expedite this request?

probably you still need MAXAMT at Paypal::Express::Request::agree! too.
https://developer.paypal.com/docs/classic/express-checkout/integration-guide/ECReferenceTxns/

I don't see where it says you can pass MAXAMT when doing a reference transaction.  In order to use reference transactions, you need to "Set Up a Billing Agreement Before Any Payment" (the only reference to MAXAMT in the link you provided) – and that's done by using SetExpressCheckout.
Unless I'm missing something.

@nov Thoughts?

It's been a few months and I thought I'd revisit this since nobody answered my last 2 messages.

Why did you close this?


Updated instruction sentence on how to claim a ticket.

Trac ticket number
N/A
Branch description
The page contributing/writing-code/submitting-patches.html has been updated with this change. The issue was that the instructions on how to assign a ticket to yourself was out of date and confusing for a first time user of TRAC. This PR updates the sentence to accurately explain where to click on the page to assign a ticket.
The original instruction which is out of date with the UI:

The new instruction which is more accurate:

Checklist

[x] This PR targets the main branch.
[x] The commit message is written in past tense, mentions the ticket number, and ends with a period.
[ ] I have checked the "Has patch" ticket flag in the Trac system.
[ ] I have added or updated relevant tests.
[ ] I have added or updated relevant docs, including release notes if applicable.
[ ] I have attached screenshots in both light and dark modes for any UI changes.

I just had this small suggestion of changing the "radio button" to just a "button". What are your views? I just thought conciseness here can be good.

I just had this small suggestion of changing the "radio button" to just a "button". What are your views? I just thought conciseness here can be good.

Thanks for looking Yash! I left it as 'radio button' because that was in the original sentence and it still is a radio button on the form. It also differentiates from the fact that 'Modify Ticket' is a button. Here is the form:

I just had this small suggestion of changing the "radio button" to just a "button". What are your views? I just thought conciseness here can be good.

Thanks for looking Yash! I left it as 'radio button' because that was in the original sentence and it still is a radio button on the form. It also differentiates from the fact that 'Modify Ticket' is a button. Here is the form:

Agh okay, makes sense! good to go ig!

Sarah, do I need to rebase this now into one commit?

Sarah, do I need to rebase this now into one commit?

I don't think it's necessary in this case, but you can check on your own, searching for the message:

"✅ This branch has no conflicts with the base branch"

Since these are steps that need to be done sequentially, could you further help the reader communicate the sequentiality and order of execution by using a numbered list instead of an unnumbered list?
I know it's out of scope for this change, but it seems like a good opportunity to make this minor change (code-wise) that I don't think should trigger a change in the translations of the previous points that aren't changed by Maria's suggestion.
Feel free to skip on that, or, if you think it's an improvemente to open a new PR.

Sarah, do I need to rebase this now into one commit?

Squashing the commits to a single commit would be great but I can also do this


Props previously placed are disappearing when placing new props

For some reason this started happening today, before today it wasn't an issue. Now whenever I place new props it's making previously placed props disappear, most especially props previously placed using Anarchy but it's happening with other props to a lesser extent. The refresh props option doesn't seem to do anything (it didn't do anything before either) and reloading my save or the game doesn't seem to make them re-appear either. I saw there was a new version out yesterday so I tried installing that and it's not helping either. I really love the mod, it's really opened up my creative possibilities so I hope this is something you can do something about. Anyways thanks for the hard work.

Looks like reloading an older save fixed the problem. Didn't lose too much progress at least. I'm still not sure why this suddenly happened. I will be testing it on every load just to make sure this doesn't happen again though.

So two theories:

At some point you loaded the save without the Anarchy mod and saved. Doing this will lose all the history of what was placed with the anarchy toggle enabled.
Changes I made with  V1.2.1 are having some side effects. So I fixed a problem related to trees not being overridden when a growable building spawns, and cranes not being properly overridden. However, that fix also made it so that if you place a prop even with anarchy toggle enabled it will override other props if they weren't placed with anarchy toggle enabled.

The refresh props button is unrelated to the issue were discussing. It's about prop culling which doesn't have to do with placement. It has more to do with zooming in and out.

I’m having crashing issues that don’t seem to be mod related so I want to
reinstall the game. If I do this is there any specific files I should be
saving that have the anarchy history so this doesn’t happen afterward? Or
will just reinstalling the mod work?
On Wed, Jan 17, 2024 at 8:38 AM yenyang @.***> wrote:

So two theories:

At some point you loaded the save without the Anarchy mod and
saved. Doing this will lose all the history of what was placed with the
anarchy toggle enabled.
Changes I made with V1.2.1 are having some side effects. So I fixed
a problem related to trees not being overridden when a growable building
spawns, and cranes not being properly overridden. However, that fix also
made it so that if you place a prop even with anarchy toggle enabled it
will override other props if they weren't placed with anarchy toggle
enabled.

The refresh props button is unrelated to the issue were discussing. It's
about prop culling which doesn't have to do with placement. It has more to
do with zooming in and out.
—
Reply to this email directly, view it on GitHub
https://github.com/yenyang/Anarchy-BepInEx/issues/12#issuecomment-1895945497,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BFM7UZTU2RID2YWEXBA3T7TYO7O5DAVCNFSM6AAAAABB6C5BB2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJVHE2DKNBZG4
.
You are receiving this because you authored the thread.Message ID:
@.***>

The history is packaged with the rest of the saved game file. You will need
to reinstall anarchy and reload the save with the mod.
On Wed, Jan 24, 2024 at 2:50 AM Haneybd87 @.***> wrote:

I’m having crashing issues that don’t seem to be mod related so I want to
reinstall the game. If I do this is there any specific files I should be
saving that have the anarchy history so this doesn’t happen afterward? Or
will just reinstalling the mod work?
On Wed, Jan 17, 2024 at 8:38 AM yenyang @.***> wrote:

So two theories:

At some point you loaded the save without the Anarchy mod and
saved. Doing this will lose all the history of what was placed with the
anarchy toggle enabled.
Changes I made with V1.2.1 are having some side effects. So I fixed
a problem related to trees not being overridden when a growable building
spawns, and cranes not being properly overridden. However, that fix also
made it so that if you place a prop even with anarchy toggle enabled it
will override other props if they weren't placed with anarchy toggle
enabled.

The refresh props button is unrelated to the issue were discussing. It's
about prop culling which doesn't have to do with placement. It has more
to
do with zooming in and out.
—
Reply to this email directly, view it on GitHub
<
https://github.com/yenyang/Anarchy-BepInEx/issues/12#issuecomment-1895945497>,

or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/BFM7UZTU2RID2YWEXBA3T7TYO7O5DAVCNFSM6AAAAABB6C5BB2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJVHE2DKNBZG4>

.
You are receiving this because you authored the thread.Message ID:
@.***>

—
Reply to this email directly, view it on GitHub
https://github.com/yenyang/Anarchy-BepInEx/issues/12#issuecomment-1907882719,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEIKNUDOLVSQQXVF2WCNGF3YQDRRBAVCNFSM6AAAAABB6C5BB2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBXHA4DENZRHE
.
You are receiving this because you commented.Message ID:
@.***>


csharp.unitTestDebuggingOptions.env broken as of 1.24.2

Issue Description
Prior to v1.24.2 you could specify environment variables to use during unit test debugging in your settings.json under csharp.unitTestDebuggingOptions (which says any lauch.json option is available).
As of v1.24.2, environment variables provided via csharp.unitTestDebuggingOptions no longer show up in the unit test debugging environment.
If I had to guess, it has to do with this commit which changed the way environment variables get passed during the debug operation.
Steps to Reproduce
In settings.json, add an environment variable to use during unit testing:
{
  "csharp.unitTestDebuggingOptions": {
    "env": {
      "EXAMPLE": "1"
    }
  }
}

Create a unit test that tries to read that variable.
[Fact]
public void ExampleTest()
{
  Assert.False(String.IsNullOrEmpty(Environment.GetVariable("EXAMPLE"));
}

Use the Code Lens to debug that test.
Expected Behavior
I expect the test to pass - the environment variable should be there because it was provided in the debugging options.
Actual Behavior
The test fails - the environment variable is not present.
Logs
OmniSharp log
No relevant logs are captured.
C# log
No relevant logs are captured.
Environment information
VSCode version: 1.69.1
C# Extension: 1.24.1
Mono Information
        OmniSharp using built-in mono
Dotnet Information
.NET SDK (reflecting any global.json):
 Version:   6.0.301
 Commit:    43f9b18481
Runtime Environment:
OS Name:     Mac OS X
OS Version:  12.4
OS Platform: Darwin
RID:         osx.12-x64
Base Path:   /usr/local/share/dotnet/sdk/6.0.301/
Host (useful for support):
Version: 6.0.6
Commit:  7cca709db2
.NET SDKs installed:
3.1.413 [/usr/local/share/dotnet/sdk]
5.0.400 [/usr/local/share/dotnet/sdk]
6.0.301 [/usr/local/share/dotnet/sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 3.1.19 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.9 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.6 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.1.19 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.9 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.6 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
To install additional .NET runtimes or SDKs:
https://aka.ms/dotnet-download

Visual Studio Code Extensions

Extension
Author
Version

auto-close-tag
formulahendry
0.5.14

auto-rename-tag
formulahendry
0.1.10

azure-account
ms-vscode
0.11.0

beautify
HookyQR
1.5.0

better-comments
aaron-bond
3.0.0

better-toml
bungcip
0.3.2

code-spell-checker
streetsidesoftware
2.3.0

color-info
bierner
0.7.0

cpptools
ms-vscode
1.11.2

csharp
ms-dotnettools
1.24.1

cucumberautocomplete
alexkrechik
2.15.2

docomment
k--kato
0.1.31

dotenv
mikestead
1.0.1

dotnet-test-explorer
formulahendry
0.7.7

ecdc
mitchdenny
1.8.0

EditorConfig
EditorConfig
0.16.4

fabric8-analytics
redhat
0.3.6

git-extension-pack
donjayamanne
0.1.3

git-graph
mhutchie
1.30.0

githistory
donjayamanne
0.6.19

gitignore
codezombiech
0.8.0

gitlens
eamodio
12.1.2

go
golang
0.34.1

html-css-class-completion
Zignd
1.20.0

java
redhat
1.8.0

jupyter
ms-toolsai
2022.6.1101950301

jupyter-keymap
ms-toolsai
1.0.0

jupyter-renderers
ms-toolsai
1.0.8

jwt-debugger
yokawasa
0.4.2

live-server
ms-vscode
0.2.12

markdown-all-in-one
yzhang
3.4.3

markdown-emoji
bierner
0.2.1

marp-vscode
marp-team
1.5.2

material-theme
zhuangtongfa
3.15.2

metals
scalameta
1.18.0

msbuild-project-tools
tintoy
0.4.4

nc-gcode
ML
0.13.0

npm-intellisense
christian-kohler
1.4.2

openvpn
idleberg
0.2.3

output-colorizer
IBM
0.1.2

path-intellisense
christian-kohler
2.8.1

plantuml
jebbs
2.17.3

powershell
ms-vscode
2022.6.3

prettier-toml
bodil
0.1.0

project-manager
alefragnani
12.6.0

python
ms-python
2022.10.0

rainbow-csv
mechatroner
2.4.0

remote-containers
ms-vscode-remote
0.241.3

remote-repositories
ms-vscode
0.14.0

remote-ssh
ms-vscode-remote
0.84.0

remote-ssh-edit
ms-vscode-remote
0.80.0

remote-wsl
ms-vscode-remote
0.66.3

remotehub
GitHub
0.36.0

restructuredtext
lextudio
189.0.0

rewrap
stkb
1.16.3

scala
scala-lang
0.5.5

simple-rst
trond-snekvik
1.5.2

sort-lines
Tyriar
1.9.1

sort-lines-by-selection
earshinov
1.0.0

spectral
stoplight
1.0.0

terraform
hashicorp
2.23.0

todo-tree
Gruntfuggly
0.0.215

vscode-arduino
vsciot-vscode
0.4.12

vscode-azurefunctions
ms-azuretools
1.7.4

vscode-azureresourcegroups
ms-azuretools
0.5.4

vscode-azurestorage
ms-azuretools
0.14.2

vscode-code-review
d-koppenhagen
1.32.1

vscode-commons
redhat
0.0.6

vscode-cosmosdb
ms-azuretools
0.19.2

vscode-coverage-gutters
ryanluker
2.10.1

vscode-dapr
ms-azuretools
0.6.0

vscode-docker
ms-azuretools
1.22.1

vscode-eslint
dbaeumer
2.2.6

vscode-graphviz
joaompinto
0.0.6

vscode-icons
vscode-icons-team
11.13.0

vscode-java-debug
vscjava
0.42.0

vscode-java-dependency
vscjava
0.20.0

vscode-java-pack
vscjava
0.24.0

vscode-java-test
vscjava
0.35.2

vscode-json-stable-stringify
TravisIllig
1.2.1

vscode-kubernetes-tools
ms-kubernetes-tools
1.3.10

vscode-markdownlint
DavidAnson
0.47.0

vscode-maven
vscjava
0.36.0

vscode-npm-script
eg2
0.3.28

vscode-open-in-github
ziyasal
1.3.6

vscode-open-multiple-files
fabiospampinato
1.4.0

vscode-openapi
42Crunch
4.11.2

vscode-pylance
ms-python
2022.7.20

vscode-remote-extensionpack
ms-vscode-remote
0.21.0

vscode-xml
redhat
0.21.0

vscode-yaml
redhat
1.9.1

vscodeintellicode
VisualStudioExptTeam
1.2.22

xml
DotJoshJohnson
2.5.1

yaml-plus-json
hilleer
1.10.0

This is "by design" as env isn't a supported option for unit test debugging ([see here])https://github.com/OmniSharp/omnisharp-vscode/blob/88ad237e1e904ad0f91d2de39c30132198a02dcb/package.json#L631)), and it would be overwritten here.
I think the way to do what you are trying to do is with a .runsettings file. Documentation: https://docs.microsoft.com/en-us/visualstudio/test/configure-unit-tests-by-using-a-dot-runsettings-file?view=vs-2022

Then at the very least, the docs two lines down from that are wrong - any launch.json option is not valid.
I figured that's where it was getting overridden, which is why I linked to the commit that changed the behavior.
I'd like to challenge the idea that this is by design based on the docs. It seems like the intent actually was to allow launch.json stuff to work... And it did for a while! It seems like it still could if the environment got merged with the settings rather than completely overridden.
If I do end up having to use .runsettings, how do I set that so it only gets used during test debugging? I didn't see a specific option to indicate a .runsettings file in the unit test debugging options. Maybe I missed it? It was admittedly a bit confusing that the .runsettings page says it works for VS but specifically shows VS Code as not being supported. Stale docs?

We intentionally do not allow env or any other launch.json option that only can be applied to launch because it is up to the unit test framework as to if the debugger launches or attaches to the worker process. But I would agree that Any launch.json option is valid here is incorrect. I will send a PR to update the documentation.

Fair enough. Can you point me to how to specify a .runsettings in the unitTestDebuggingOptions?

I only know the debugging side of things, but you would use omnisharp.testRunSettings. That should apply both when debugging and when not.

Ah! Excellent. I'll give that a shot. I appreciate the help and the pointers!


Multi-line diagnostics

Hey, would you consider supporting multi-line diagnostics? Right now all lines are concatenated and displayed in a single line, while vim.lsp.diagnostic.show_line_diagnostics() displays them correctly.

I'll see what I can do. At the minimum, I can add a keyboard shortcut to open a small floating window with the multi-line text.

Such a keyboard shortcut would be fantastic! although just having a way to expand the error in the list would also be very welcome ^^

Just added this. It's the configurable hover action and defaults to K

Another cool idea I just had here would be to allow for having a split pane in the bottom list, where the right pane just shows the multiline error of the currently hovered error, and the error list is on the left. Although this hover solution works really well, too! Thanks a ton already!

@elkowar I'll just keep the hover for now, but thank you for the suggestion :)

I'd prefer if all errors in the trouble window are shown multiline. This could be an option in the configuration.
If the option is turned on, the errors would look something like this:
v file1.txt  4
     error  • Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore
              magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo
              consequat.
     error  • Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore
              magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo
              consequat.

hello everyone, was this added as an option ? or do we only have the hover key ?


HOS-01 | Lack of Sanity Check - Remove Validator

What is the purpose of the change
When removing a validator with non-zero delegation amount from the set, those funds will be stranded until we re-add this validator.
Brief Changelog

ensure that Validator.DelegationAmt and Validator.Weight is ZERO before removing the target validator from a host zone.
when rebalanding validators, sort ascending to avoid last-validator precision amount issue. See this example code: https://go.dev/play/p/3Zd_cVKZVyU

Testing and verifying
CI + integration
Documentation and Release Note

Does this pull request introduce a new feature or user-facing behavior changes? no
Is a relevant changelog entry added to the Unreleased section in CHANGELOG.md? no
How is the feature or change documented? audit

@riley-stride can you attach the go playground code used to test the validator sorting?

Is this still a draft? @asalzmann

lgtm. fixed small merge conflict. let's merge @asalzmann !


account statement is seriously confusing

I like how precise and clear the History page is trying to be, but it's failing. Payday 262 is the most complex yet and I'm really struggling to figure out what it's trying to tell me, so I can log it in my accounting system.

I agree. I think the history pages/statements need an overhaul. Folding into #4510.


An element command failed because the referenced element is no longer attached to the DOM

##Error when executing element.text method:
An element command failed because the referenced element is no longer attached to the DOM
##My code:

import time
from appium import webdriver
from appium_flutter_finder.flutter_finder import FlutterElement, FlutterFinder
from appium.webdriver.common.mobileby import MobileBy

desired_caps = {
    "platformName": "iOS",
    "platformVersion": "11.0.1",
    "automationName": "XCUITest",
    "deviceName": "Real Iphone",
    "bundleId": "com.example.flutterModule",
    "udid": "6fc9878eaa164505910585c1b04c1d9640026eb6",
}

driver = webdriver.Remote('http://localhost:4723/wd/hub', desired_caps)

time.sleep(3)

print('context:', driver.context)
print('contexts:', driver.contexts)

# iOS native
push = driver.find_element(MobileBy.ACCESSIBILITY_ID, 'Push Flutter Page')
print(push.text)
print(push)
push.click()

time.sleep(1)

# flutter view
finder = FlutterFinder()
set_login_finder = finder.by_text('set_login_pwd')
set_login = FlutterElement(driver, set_login_finder)
print(set_login)
print(set_login.text)  # error here
# print(set_login.location)
# print(set_login.size)

##Environment：
-- macOS
-- Python
-- iOS Real device
-- Appium 1.17.0

@waitan2018
Use automationName as Flutter to automate flutter application.

@ waitan2018
使用automationName作为Flutter来自动执行Flutter应用程序。

Ok, I have solved this problem, thank you very much for your reply.


Undoing and pistons

Hey Nathan,
we found another bug, when a block connected to a piston gets displaced and if the piston then extends, then when the block undo's then the piston will drop.
martdamp
A list of pictures showing what happens.
The move that we used while testing:
earth_test:
    icon: stone
    actions:
        cast:
        -   class: ChangeContext
            target_offset: 0,1,0
            actions:
            -   class: Cylinder
                radius: 2
                actions:
                -   class: Brush
                    brush: erase
                    actions:
                    -   class: ModifyBlock
            -   class: Delay
            -   class: Cylinder
                radius: 3
                actions:
                -   class: Brush
                    brush: erase
                    actions:
                    -   class: ModifyBlock
            -   class: Delay
            -   class: Cylinder
                radius: 4
                actions:
                -   class: Brush
                    brush: erase
                    actions:
                    -   class: ModifyBlock
    parameters:
        target: block
        destructible: earth
        falling: true
        delay: 50
        undo: 4000
        direction: 0,1,0
        speed: 0.2
        thickness: 1
        y_size: 1

Just wanted to let you know I saw this but don't have any ideas yet, this may be tricky to fix.


The dependency git+https://github.com/meteor/readable-stream.git causes problems with yarn

"readable-stream": "git+https://github.com/meteor/readable-stream.git"
There is a strange bug with yarn, it complains about git+https and I wonder what the reason for this kind of dependency is.

I'm aware of this problem (or a similar problem) on Windows (are you on Windows?).
Here's an example of the rationale that motivated this URL protocol: https://stackoverflow.com/a/17509764/128454
Do you have a suggestion for something different?

New answer in that thread claims the issue has gone away.  And the original format should work.


Parser bug error in RRMapParser

Describe the bug
There is a little bug in lib/RRMapParser.js.
In method PARSE data_length (line 370) is read as a UInt16, when in reality it's a UInt32. Not sure if this value is used anywhere 🤷. You can verify the correctness of this statement when you sum up header_length and data_length, the sum should be equal to the length of the buffer. Thought I'd let you know ^^
Edit: Just realised that map_sequence and map_index must be UInt32 for the same reason, they would be bad pointers if the valid range can only address half of the payload

Hi,
thank you for looking into this. Have you locally applied your changes and tested the adapter after that? Does it correctly create a map?
For example, changing data_length from UInt16 to UInt32 would change the length in my example from 14338 to 407554 which does not seem quite correct.
I have noticed a while ago there is some more data after data_length I'm just not quite sure what it is. See https://github.com/copystring/ioBroker.roborock/blob/ba1f62ec738fb404838469da4225a2e96a8514ca/lib/RRMapParser.js#L268
Let me know what you think.

Looks like you're correct. I wonder what kind of data it contains. 407554 is a LOT longer than 14338 ...

Given that there is one byte for each pixel and mine is for example 393 by 415 = 163095 byte it makes sense that the number is higher 😉 .
Yupp, I believe the code simply ignores data_length and accesses the raw pixel data by iterating over width and height. That's why I said

Not sure if this value is used anywhere 🤷
So parsing those values correctly doesn't do anything right now. It could help you in the future, if you start using it - possible save you from some headaches. You could use it to check if you're running out of bounds before accessing pixel data (x + y*width < data_length). Somewhat related: The last 20 bytes of the payload (aka digest) is a SHA-1 of all data in the payload up until the last 20 bytes (in case you want to check the integrity of the data before parsing it)

I implemented these changes: https://github.com/copystring/ioBroker.roborock/commit/e7b190e01f7ee6f73b6f8fd6d012c7194e71d2d3


Support C++11 Objective-C++ in objc_.* targets

I want to compile a target that contains some Objective-C files and some Objective-C++ files (conventionally ending in .mm). For the latter, I want to specify -std=c++11. If I add that to objccopts, my Objective-C++ files compile, but clang dies on my Objective-C files with:
error: invalid argument '-std=c++11' not allowed with 'C/ObjC'

Damien, could you help direct this to the right person?

Peter: do you have some comment on that?

We don't have the ability to add C++ opts yet. We are aware of the problem.
Sigh... file a bug please?
Cheers,
Dave
On Mon, Aug 10, 2015 at 7:18 AM, Damien Martin-Guillerez <
<EMAIL_ADDRESS>wrote:

Peter: do you have some comment on that?
—
Reply to this email directly or view it on GitHub
https://github.com/google/bazel/issues/366#issuecomment-129470219.

Until this is fixed, my planned workaround is to have my objc++ in a separate objc_library called mylib_objcc that specifies -std=c++11. This also means I need to take that out of my global copts and rely on the c++ toolchain providing it instead, which is... reasonable, I suppose.

Any update on this issue?

Alternatively, allowing .m / .mm files in cc_library could work.
Right now, it is possible to build an ObjC/ObjC++ library providing the files end with .c or .cpp and the -ObjC or -ObjC++ flags are passed when compiling.
This way, cross platform programs don't have to specify a special set of rules to use the objc_library from a cc_library or cc_binary dependency.

It seems like this is now fixed in objc_library, when passing copts = ["-ObjC++","-std=c++11"]

Consider separating out objc_library targets into srcs of different types, if their copts need to differ? These can be later recombined as a single objc_library which depends on both...
Per-language per-target copts strikes me as scaling poorly.


Enable loiter type offboard position setpoint for Fixedwing vehicles

Describe problem solved by this pull request
This PR Fixes #13180 , where sending the loiter type offboard position setpoint on a fixed wing vehicle will result in a fly away. Loiter setpoints can be useful for fixed wing offboard mode as normal position setpoints are passed as a reference to the l1 controller so there are no explicit constraints on the radius of the vehicle while keeping close to the position setpoint.
The reason the it wasn't working was

Commander thinks it is a valid setpoint, as it is receiving enough SET_POSITION_TARGET_LOCAL_NED messages, therefore the vehicle is able to switch to offboard mode.
The fixed wing position controller treats the setpoint as a loiter setpoint as it is marked here as a lotier setpoint.
However, as the loiter_radius and loiter_direction is not set from SET_POSITION_TARGET_LOCAL_NED, it is left as zero.

Describe your solution
Set the loiter_radius and lotier_direction if  loiter_radius<=0it is invalid (which probabiliy means it is in offboard mode following position setpoints). It uses the default NAV_LOTIER_RAD parameter as default loiter radius
Test data / coverage
This log shows a flight which is being sent a offboard local position setpoint at [0.0m, 0.0m, 20.0m] and being switched between mission mode and offboard mode

@hamishwillee The types of setpoints are in general UNDOCUMENTED. I realized this is a thing by going through the code. Would it make sense to add this to the documentation?

The types of position setpoints are in general UNDOCUMENTED. I realized this is a thing by going through the code. Now that it works would it make sense to add this to the documentation?

@Jaeyoung-Lim
How does the "type" of the setpoint get determined? I.e. I can't see it in https://mavlink.io/en/messages/common.html#SET_POSITION_TARGET_LOCAL_NED so it looks entirely internal to PX4.
Can someone determine what type of setpoint they are dealing with?
Upshot, I can't answer this yet, because I don't understand where these come from and how they are used.

@hamishwillee Exactly. It seems to be coming from https://github.com/PX4/Firmware/pull/3405 and the type definitions didn't make it through the mavlink spec. I do like the fact that we can use the type_mask to configure how the setpoint can be followed. But in my opinion, this should either be pushed to the mavlink standard or at least be documented somewhere.

@Jaeyoung-Lim Thanks for the clarification. I don't know if this should be public or not, but if it is then IMO it has been done incorrectly.
I have created https://github.com/mavlink/mavlink/pull/1250 to discuss whether it should be public or not. Depending on how that falls out will define how this is documented.
Can you tell me the difference between the idle and loiter setpoints, and why knowing the setpoint type is useful (as an answer to the linked PR?)

@hamishwillee Specifying the position of the setpoint does not always fully define the expected behavior of the vehicle.
An idle setpoint will make the vehicle be in idle state - zero throttle, zero roll / pitch.
A Loiter setpoint will make the vehicle circle around the setpoint.
A normally passed postion setpoint will make the vehicle use the position setpoint as a reference to the L1 controller, so it will fly in a flower like pattern.
All three types use the same position setpoint, but the behavior is handled differently in the fixed wing position controller.

@Jaeyoung-Lim What do the setpoints do on other vehicle types?

@hamishwillee I have replied in the user guide!

@sfuhrer Can we get this merged?

@sfuhrer Can we get this merged?

Yes!

This really makes me think that loiter radius should be a FW parameter rather than navigator.


Error at the end of "e2e kubeflow on GCP" guide

At the end of the guide, the command to activate port forwarding contains some errors:

the command refers to the variable $ {NAMESPACE} that is not defined
the command to select the pod does not work
when creating the ksonnet component for the UI, port 5000 is indicated while in port forwarding, port 80 is indicated

Below is a version that works:
kubectl port-forward -n ${DEPLOYMENT_NAME}  `kubectl get pods --all-namespaces \
  --selector=app=web-ui -o=jsonpath='{.items[0].metadata.name}'` 8080:5000

/assign
Thanks!


Bump to version 0.10.0

@tianon next steps?

Wait, shouldn't this be in a '10.0' directory?

Sorry for the delay @ahawkins (and thanks for poking it again to bring it back up in my inbox, @stelcheck :cold_sweat:) -- I think @stelcheck is probably right, unless upstream is not going to have any more 0.9 releases going forward, in which case the 0.9 folder should probably be renamed.
Either way, once you've merged the update, we'll just need a PR against https://github.com/docker-library/official-images/blob/master/library/thrift to get the updated commit reference. :+1:

From what I can tell, upstream appears to be in the single-version-track-supported-at-a-time camp (https://archive.apache.org/dist/thrift/ -- back in 2012 they appear to have released 0.7.0 and 0.8.0 simultaneously but haven't done anything similar since), so you could remove the folder entirely if you'd rather, but IMO it makes it a little easier to manage the repo.

Is there anything I could do to make this happen? Any way I could help?

I'm also interested in seeing this through. Our build process uses this official image, so we've been waiting for this change to land to recompile all our stuff.
I'm admittedly unfamiliar with how changes here impact the tags available on Docker Hub, but if having both a 0.9 and a 0.10 folder here means that both the :0.9 and :0.10 tags are available there then I'd suggest doing that.

I'll take care of this in the next couple days. Sorry for the delays :(
On Wed, Feb 22, 2017, at 01:13 PM, Tyler Christensen wrote:

I'm also interested in seeing this through. Our build process uses
this official image, so we've been waiting for this change to land to
recompile all our stuff.
I'm admittedly unfamiliar with how changes here impact the tags
available on Docker Hub, but if having both a 0.9 and a 0.10 folder
here means that both the :0.9 and :0.10 tags are available there then
I'd suggest doing that.
— You are receiving this because you were mentioned. Reply to this
email directly, view it on GitHub[1], or mute the thread[2].

Links:

https://github.com/ahawkins/docker-thrift/pull/5#issuecomment-281593348
https://github.com/notifications/unsubscribe-auth/AAC_IGxl_NhAMDqPGWRg1qxN6oTBG5q1ks5re-cXgaJpZM4Lhu4p


NOT READY FOR REVIEW

Overview
Closes https://github.com/celestiaorg/celestia-app/issues/1859
Checklist

[ ] New and updated code has appropriate documentation
[ ] New and updated code has new and/or updated testing
[ ] Required CI checks are passing
[ ] Visual proof for any user facing features like CLI or documentation updates
[ ] Linked issues closed with keywords

Codecov Report

Merging #1860 (42d6927) into main (0d8e692) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #1860   +/-   ##
=======================================
  Coverage   21.82%   21.82%
=======================================
  Files         116      116
  Lines       13247    13247
=======================================
  Hits         2891     2891
  Misses      10065    10065
  Partials      291      291

There's a lot of existing test fixture code that we should try use instead of continually recreating the same functions.

Agree with this, however, as far as I checked, the existing ones could not produce random blob count (for blob tx) and amount (for send tx). That is why I added the GenerateOrderedRandomTxs.

Callum raises good pionts, where ideally all randomness would be handled by go's fuzzing tools, then we could have an isolated test. As Sanaz has pointed out, since we already don't have that, I'm good with not for now though we might want to open an issue (it would be a good "good first issue"). I also think this is a meaningful addition to our share encoding testing and is worthwhile since we've caught weird edge cases in the past with similar tools having similar levels of randomness
left one blocking question, and would like to defer to @cmwaters for final approval

Created a tracking issue, as you @evan-forbes  suggested https://github.com/celestiaorg/celestia-app/issues/1942

Thank you, @cmwaters, for your insights on this matter. Based on our current discussion, I believe the conclusion for this PR can be summarized as follows:

Consolidating the square construct/deconstruct fuzzer (introduced in this PR) into the existing square fuzzer, as well as replacing the older transaction generation mechanism GenerateOrderedTxs  in the square fuzzer with a more randomized approach GenerateOrderedRandomTxs.
Ensuring that transactions are generated deterministically using the corpus generated by the fuzzer, thereby addressing this specific issue (In line with this comment).

@cmwaters, please let me know if these two steps align with your expectations. If so, I will proceed to address the first step within this PR and create a separate PR for the second step.

Yup, exactly

@cmwaters Please let me know whether the changes look good to you?


Ensure that all endpoints use shared data fetching and packaging code where possible

With new ALFRESCO PR #94 there are some functions added to shared modules that might be of use elsewhere. A lot of this boils down to the taspr endpoint not being brought up-to-date with much of the shared code, which we were aware of already, and it could be the only offender. But this ticket specifically requests a check that things are consistent and making use of shared fetching and packaging code where possible across all endpoints.
Some examples:

taspr endpoint not using shared function for creating WCPS string for averaging:

taspr not using common code for fetching bbox data as netcdf

taspr and permafrost / alfresco endpoints do not have a common method for fetching and packaging data: in taspr, all packaging is done in "run_" functions which are called by the endpoint functions, whereas in permafrost/alfresco, this is done in the endpoints functions:

Inconsistencies in naming functions. We should try to be consistent with naming, especially for endpoints, as well as with use of  common qualifiers in names e.g. "fetch_" , "run_" etc

scrap fetch_layer_data? duplicate of make_get_request

See also making consistent use of  fetch_data.get_wcs_xy_str_from_bbox_bounds and fetch_data.generate_netcdf_average_wcps_str.

Functions for polygon summaries may have shared code that can be pulled out into separate functions.

Currently taking a whack at this issue. I think this on is important to resolve to the extent we can. Now that we (maybe) know how to use rasdaman we're able to get data into there and out of there without a ton of weird, bespoke stuff happening, so I think we are in a good position to set the API up to handle new endpoints in a more general way and get from "geotiff pancakes" to "API endpoint" with less hassle.

scrap fetch_layer_data? duplicate of make_get_request

Totally! I've made this change in the working branch share-the-code

Functions for polygon summaries may have shared code that can be pulled out into separate functions.

I've broken these into small functions that work with the ALFRESCO endpoints and hopefully can be used in taspr as well. Lucky for us, we don't have zonal queries for permafrost right now so this is a good time to change stuff!

OWSLib may offer some stuff to clean this up a bit.


feat: add support for arm64 to errata-ai/vale

Check List

[x] Read CONTRIBUTING.md

[x] Read OSS Contribution Guide

[x] All commits are signed

This repository enables Require signed commits, so all commits must be signed

[x] Avoid force push
[x] Do only one thing in one Pull Request
[ ] Execute cmdx s to scaffold code
[ ] Install and execute the package and confirm if the package works well

This adds arm64 support to the errata-ai/vale package. This is supported by the package here
(also sorted the list for maintainability)

Thank you for your contribution!

https://aquaproj.github.io/docs/products/aqua-registry/contributing/#how-to-add-a-package

When you update pkgs/**/registry.yaml, you have to run cmdx gr to reflect the update to registry.yaml in the repository.

https://aquaproj.github.io/docs/products/aqua-registry/contributing/#how-to-add-a-package

When you update pkgs/**/registry.yaml, you have to run cmdx gr to reflect the update to registry.yaml in the repository.

Gotcha, thanks. I was double checking that page now to be able to fix the CI failure

Seems like the original configuration was very old, so we should regenerate it by cmdx s errata-ai/vale.

Is there a way to have arm64 supported, but not for a particular distribution? (There's no arm64 for windows in this case)
I'm not deeply familiar with the registry format (I'm not even an aqua user - I'm using mise to install dependencies and it's recently switched to aqua rather than asdf as a backend for the vale package)

Is there a way to have arm64 supported, but not for a particular distribution? (There's no arm64 for windows in this case)

windows_arm_emulation: true is available.
https://aquaproj.github.io/docs/reference/registry-config/windows_arm_emulation

cool. Give me 10 mins to spin up a 'full' dev env - with cmdx. I'll push an update here asap :)

Thank you.
The command cmdx s -B errata-ai/vale scaffolds the configuration but we need to fix the generated code manually.
Please see the error log and fix the code.
Honestly, it is a little difficult to fix it, so I can help you.

The full rescaffold pulled in a long version history which, as you saw, was causing all sorts of errors with older versions of the package.
I've trimmed this to only supporting the latest and previous release - this should (hopefully) resolve things.
cmdx t errata-ai/vale passes locally

Thank you.
There is no strict rule, but basically we support all versions as much as possible.
Of course, sometimes we stop the support of very old versions (e.g. versions released at over 5 years ago).
I've updated the setting and CI passed.

Great - thanks for your support and guidance here 🙏


python3Packages.jupyter-repo2docker: add missing dependencies

Motivation for this change
Add missing deps
Fix build (https://hydra.nixos.org/build/157261029)
ZHF: #144627
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

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

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

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

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

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 145638 run on x86_64-linux 1

2 packages built:

python38Packages.jupyter-repo2docker
python39Packages.jupyter-repo2docker


feat(lane_change): added lane change point

Description
update turn signal logic.
Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[ ] I've confirmed the contribution guidelines.
[ ] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.

After all checkboxes are checked, anyone who has write access can merge the PR.

Codecov Report

:exclamation: No coverage uploaded for pull request base (feat/add-new-intersection-algorithm@9ca34b0). Click here to learn what that means.
Patch has no changes to coverable lines.

Additional details and impacted files
@@                          Coverage Diff                          @@
##             feat/add-new-intersection-algorithm    #137   +/-   ##
=====================================================================
  Coverage                                       ?   2.55%
=====================================================================
  Files                                          ?      51
  Lines                                          ?    6488
  Branches                                       ?    3312
=====================================================================
  Hits                                           ?     166
  Misses                                         ?    6159
  Partials                                       ?     163

Flag
Coverage Δ

differential
2.55% <0.00%> (?)

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

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


NFC Manager sometimes deletes ndef from tag's available technologies

Hi I'm writing an app for ndef read/write with react-native-nfc-manager. It successfully works most of the time but sometimes it deletes ndef from "available technologies". I can't write to nfc until clone from another ndef tag with ST25 app.
I couldn't find a way to add cloning on my app with react-native-nfc-manager. One time I achieved to fix the nfc with using direct bytes with writeNdefMessage but didn't work again.
How can I handle this situation on my app? My NFC Write code:
                try {
              await NfcManager.requestTechnology(NfcTech.Ndef)
              await NfcManager.ndefHandler.writeNdefMessage([
               0xD1,0x01,0x0B,0x55,0x04,0x67,0x6F,0x6F,0x67,0x6C,0x65,0x2E,0x63,0x6F,0x6D
              ]);

            } catch (error) {
              console.log(error);
            } finally {
              NfcManager.cancelTechnologyRequest().catch(() => 0);
            }

Hello my friend, how do I get in touch with you, I want to make an nfc apk, can you help me to get the values right


Couldn't sign in [intellij] (CodeGPT v1.6.1)

Hi @nuth-vireak
Unfortunately Google nor Microsoft login isn't possible due their own security reasons.
FYI: The plugin is built around the completion's API and I'd suggest you to use the Chat tab instead.
Best regards


New jenkins build server

I noticed that the jenkins build server is down for the nameless plugin, so I've created a new one :)
https://jenkins.derkades.xyz/job/Nameless Plugin/
(by the way, the build failed because the placeholderapi maven repo is temporarily unavailabe)

Not sure if we are gonna make our own or use yours, leaving this open till we decide.

Builds are working now (see build 7). You can close this issue and add https://jenkins.derkades.xyz/job/Nameless Plugin/ yourself if you want to.


Duplicate MQTT messages with same timestamp

FrameTimestampIssue.zip
When the attached python code was run, we experienced 3 pairs of messages with the same timestamps. You can see these in the mqtt_logs.text at lines: 13/14, 21/22 and 25/26.
Wondering what is happening here, my understanding is that each MQTT message should come with unique and incremental timestamp. Is this an instance where both messages were generated close to each other so in the time resolution they fall in to the same ticker?

We looked into this issue and identified incorrect timestamps in the media source that rippled through to MQTT. Closing as this is not a VA Serving issue.


Could you provide the parameter configuration used to obtain the results in the paper?

I used both the default configuration and the following configuration, but neither produced the results mentioned in the paper.
CUDA_VISIBLE_DEVICES=0 python run_src/do_generate.py \
    --dataset_name GSM8K \
    --test_json_filename test_all \
    --model_ckpt 'models/mistral' \
    --note default \
    --num_rollouts 32\
    --num_subquestions 5\
    --num_a1_steps 5\
    --half_precision

Hi, here is the command and hyperparameters we used to reproduce the results for LLaMA-3-8B-Instruct from the paper:
CUDA_VISIBLE_DEVICES=0 python run_src/do_generate.py \
    --dataset_name GSM8K \
    --test_json_filename test_all \
    --model_ckpt meta-llama/Meta-Llama-3-8B-Instruct \
    --note reproduce \
    --num_rollouts 32 \
    --num_subquestions 5 \
    --num_a1_steps 5 \
    --disable_a5

Please note that results may vary slightly depending on the machine. We re-ran the command on an H100 node, and the score we obtained was 89.08.

Hi, here is the command and hyperparameters we used to reproduce the results for LLaMA-3-8B-Instruct from the paper:
CUDA_VISIBLE_DEVICES=0 python run_src/do_generate.py \
    --dataset_name GSM8K \
    --test_json_filename test_all \
    --model_ckpt meta-llama/Meta-Llama-3-8B-Instruct \
    --note reproduce \
    --num_rollouts 32 \
    --num_subquestions 5 \
    --num_a1_steps 5 \
    --disable_a5

Please note that results may vary slightly depending on the machine. We re-ran the command on an H100 node, and the score we obtained was 89.08.

May I ask how long it took you to run the above command on the H100? I find it takes a long time.

Hi, each case should take 3-4min in our testing.

Hi, each case should take 3-4min in our testing.

I also find it takes a long time and each case costs about 25 minutes.

Hi, each case should take 3-4min in our testing.

I also find it takes a long time and each case costs about 25 minutes.

H100-80GB?

H800-80GB

Hi, each case should take 3-4min in our testing.

I also find it takes a long time and each case costs about 25 minutes.

H100-80GB?

H800-80GB，model is llama-3-8B-Instruct, dataset is Math.

Hi, each case should take 3-4min in our testing.

I also find it takes a long time and each case costs about 25 minutes.

H100-80GB?

H800-80GB，model is llama-3-8B-Instruct, dataset is Math.

The inference time of Math is longer than that of GSM8K. You can run the code in multiply nodes.

Hi, here is the command and hyperparameters we used to reproduce the results for LLaMA-3-8B-Instruct from the paper:
CUDA_VISIBLE_DEVICES=0 python run_src/do_generate.py \
    --dataset_name GSM8K \
    --test_json_filename test_all \
    --model_ckpt meta-llama/Meta-Llama-3-8B-Instruct \
    --note reproduce \
    --num_rollouts 32 \
    --num_subquestions 5 \
    --num_a1_steps 5 \
    --disable_a5

Please note that results may vary slightly depending on the machine. We re-ran the command on an H100 node, and the score we obtained was 89.08.

What parameters have you used for Mistral-7B-v0.1?

The parameters for Mistral-7B-v0.1 are the same as those for Meta-Llama-3-8B-Instruct. You can simply replace the model_ckpt  and test.

@Cerlog The parameters for Mistral-7B-v0.1 are the same as those for Meta-Llama-3-8B-Instruct. You can simply replace the model_ckpt and test.

Thank you! :)

@JiahangXu For the generator, I used the parameter settings mentioned above with Mistral-7B-v0.1 and got 63% on GSM8K. Then for the discriminator I used the default settings from your provided script and got 67%. Note that I didn't use every single question given in test_all.json but I used a large subset so I still think my score should be more close to what you reported.

@emsjob Could you provide your generator/discriminator model and your generator scores? Our discriminator results should be the one generated with the default settings.

 After running generator.sh, my accuracy was 66%, and after running discriminator.sh, it reached 71%. I set the rollout to 16, but I saw in the paper that 16 rollouts correspond to 78.84%.

Hi, each case should take 3-4min in our testing.

I also find it takes a long time and each case costs about 25 minutes.

H100-80GB?

H800-80GB，model is llama-3-8B-Instruct, dataset is Math.

The inference time of Math is longer than that of GSM8K. You can run the code in multiply nodes.
@cingtiye
Hey, how did you run in multiple nodes? I tried to use tensor parallelism with vllm, i get divide by zero error


Data is not getting printed in the report

I'm trying to generate a very simple report. Data is coming from mysql db. But, data is not being printed in the generated pdf file. Though header and footer is being printed. Here is the code:
app.post('/adminreport', function(req,res){
  var reportDate = req.body.report_Date;

  console.log("Report Date : " + reportDate);

    connection.connect(function(err){
     if(err){
       console.log('Error connecting to Db');
       return;
     }
     console.log('Connection established');
   });

   connection.query('SELECT id, fName, lName, pickUpDate FROM reservations_db WHERE pickUpDate = ?', [reportDate], function(err, results, fields){
     if (!err)
	 {
	  //res.sendStatus(200).json({status:"ok"});

      console.log('The result is generated successfully!');
	  console.log(results);
	  //console.log(fields);

	var headerFunction = function(Report) {
      Report.print("Report By Date", {fontSize: 22, bold: true, underline:true, align: "center"});
      Report.newLine(2);
    };

    var footerFunction = function(Report) {
        Report.line(Report.currentX(), Report.maxY()-18, Report.maxX(), Report.maxY()-18);
        Report.pageNumber({text: "Page {0} of {1}", footer: true, align: "right"});
        Report.print("Report printed: "+ reportDate, {y: Report.maxY()-14, align: "left"});
    };
	//var res = function(Report) {
	//    Report.print(results);
	//};
	var myData = [{id: 1, name: 'mo'}, {id: 2, name: 'salam'}];
	console.log(myData);
	var rpt = new Report("report_js.pdf")
        .margins(20)                                 // Change the Margins to 20 pixels                                  // Add Data
        .pageHeader(headerFunction)                  // Add a header
        .data(myData) 		                         // Add Data
        .pageFooter(footerFunction)                  // Add a footer
        .render();
	  }

     else
	 {
	 console.log('Error while performing persistence!');
	 }
    });

This is the generated pdf file:
report_js.pdf

I think you may have misunderstood something, probably my lousy docs.  :grinning:       I don't see a detail function, it is what you need to print out the body of a report.   ;-)

@NathanaelA, Thanks man :) , it's working now! Another request, Could you please tell me how to center the table and how to center table data.

To center the table; you have to know the size of the table; then you set the offset of the table to be where it needs to start.
To center the text, look at the options you can pass in to the text() command, one of them is center.  :grinning:


operator/ingress: Add configuration for ownership check

operator/v1/types_ingress.go (IngressControllerSpec): Add new option
to disable namespace ownership check in the openshift-router. This
solves https://github.com/openshift/cluster-ingress-operator/issues/285
operator/v1/zz_generated.{swagger_doc_generated,deepcopy}.go: Regenerated

Implemented in https://github.com/openshift/cluster-ingress-operator/pull/292

@openshift/sig-network-edge @smarterclayton would it be accurate and/or useful to generalize namespace-boundaries and wildcard support as something like "route admission policies"?
For example, AllowInterNamespaceClaims
In any case they are both specific to Route resource.

Make sure https://github.com/openshift/api/blob/master/operator/v1/0000_50_ingress-operator_00-custom-resource-definition.yaml gets updated as part of this PR.

This PR needs to be updated to accurately reflect https://github.com/openshift/enhancements/pull/43


Excel Tool - Provide a way to create cells with formula.

Steps to reproduce the problem:
1.Create an agent with github.com/gptscript-ai/tools/apis/excel/write

Chat with this agent and ask it to open an excel file with following format -
mypay55.xlsx

Once it provides the details from this xlsheet,  ask to Add a new row with values for Gross Pay and Net Pay to be the total of corresponding column values from all the pervious rows

Notice that new rows with total gets added but is incorrect since the LLM's calculation is not acqurate.
In this case , we should have support for  tools that would allow us to create cells with formulas which will result in excel doing the right calculations.

Tested with latest version of tool
  "github.com/otto8-ai/tools": "77a6b1b41dc2cf3fd9d63624b77bbebade170894",
  "otto": "v0.0.0-dev-5a342362-dirty"

Create an agent with Excel tool bundle.

Chat with this agent and ask it to Read mypay55 sheet and create a column "Take Home" as a formula that subtracts "Gross Pay" and "Net pay" and add it to all existing rows
This is the file i used - mypay55.xlsx

This results in a new column "Take Home" getting added , but values are populated only the for the first 2 rows.
Tool call shows only 2 rows being used

Debug call -
calls (34).json
xlsheet after update


Add zsh completion for 'docker system df'

ref. #26108
Signed-off-by: Steve Durrheimer<EMAIL_ADDRESS>

LGTM


Dynamic capitalization of variables

Hi,
(This is just an idea, probably difficult to implement.)
is there a way to make Jinja behave in the following manner?
    template = Template('They are {{ nationality }} and they live in {{ Country }}')
    stream = template.render(nationality='portuguese', country='portugal')
    assert stream == 'They are portuguese and they live in Portugal'

Notice the use of a capitalized reference {{ Country }} to the country variable. Other possibilities:
    # if the variable reference matches, then present the value therein
    assert Template('var').render(var='YeLLoW') == 'YeLLoW'

    # if any of the variable reference's chars misses the capitalization, then
    assert Template('VAR').render(var='YeLLoW') == 'YELLOW'
    assert Template('VaR').render(var='YeLLoW') == 'YelloW'
    assert Template('vAr').render(var='YeLLoW') == 'yELLOw'
    assert Template('Var').render(var='yellow hats') == 'Yellow Hats'

The high level idea here is: when variable names and their respective references fail to match due to capitalization issues, is there a way to extract command information from that and implement a filter?

Do you have a concrete example where this would be especially convenient? Generally the title filter works fine for country names.
Personally, this feels like too much magic, I'd rather have casing changes handled through explicit filters, rather than leave room for ambiguity.


Label Feature, part deux

This adds a Label class which may be used to determine what nodes and jobs are linked together by a label. This information is taken from the /label/<labelname>/api endpoint provided by Jenkins.
The Node class has been extended to include a get_labels function which returns a list of Label instances. Each item in this list can be used to query the jenkins master for more information about the label. By default the list of labels returned includes a host label which a jenkins master internally creates for every node. Calling Node.get_labels(add_host_label=False) will return labels without the host label.
An example has been added in examples/how_to/find_jobs_for_node.py that demonstrates how to find the jobs that may potentially run on a node.
The Job class now includes a get_label_expression function that returns the string representation of a label expression. This string will be empty if there is no Label Expression defined under the "Restrict where this job can run" project option. In the simplest cases, where the expression is just a single label, this may be used to verify that the job is tied to a node. In more complicated cases where operators are used a full blown parser would be required for this verification.

It was open for too long...


how to validate two fields depending on ech other?

Hey,
Lets say i want to disable a field and show a error message depending on the value of an other field.
Is this possible?
Thank you and best regards
Johannes

I found a way. One could pass a validator to a form group like so:
export function validateMyFields(key: string, key1 : string) {
  return (group: FormGroup): {[key: string]: any} => {
    let password = group.controls[key];
...

but that would require to have a formgroup in the form model since otherwise there is no place where one could pass the validator to the group, right?

@JBusch I don't know if it's exactly what you mean but there's already such a thing as form control dependencies

for example, i mean to validate a date input depending on an other date input and display an error message if the second date is before the first date. that would be possible with the current setup?

@JBusch No that's not possible with the current state of the implementation. But your proposal seems to be a very good approach to this.


fix(ui_auth, ui_localizations): add localization label (#229)

Description
Replace this paragraph with a description of what this PR is doing. If you're modifying existing behavior, describe the existing behavior, how this PR is changing it, and what motivated the change.
Related Issues
closes https://github.com/firebase/FirebaseUI-Flutter/issues/229
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]).
This will ensure a smooth and quick review process. Updating the pubspec.yaml and changelogs is not required.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
[x] All existing and new tests are passing.
[x] I updated/added relevant documentation (doc comments with ///).
[x] The analyzer (melos run analyze) does not report any problems on my PR.
[x] All unit tests pass (melos run test:unit:all doesn't fail).
[x] I read and followed the Flutter Style Guide.
[x] I signed the CLA.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change.
[x] No, this is not a breaking change.

Hey @apnnux - you need to follow these instruction for adding this new label here: https://github.com/firebase/FirebaseUI-Flutter/blob/main/packages/firebase_ui_localizations/README.md#adding-a-new-language
In other words, you need to update the arb files for each language and generate the code based on the arb file. Once that is done, we can look to get this Pr approved. Thanks!

Hey @apnnux - are you going to follow up on this PR?

Hi @russellwheatley yes, I'm sorry but in this moment I'm not at home, but in a few days I'll update this


Resolve testing issue with missing dependent workflow data files

This issue focuses on a bug which periodically shows up from the test test_convert_s3_path_sqlite where single data extraction chunks appear to not be available for subsequent dependent workflow tasks. Examples of this occurring: see here, here, and here.
Patterns:

Often occurs within GitHub Actions runner images for ubuntu-latest(ubuntu-22.04 as of the time of this writing).
Often does not occur during local development test runs on MacOS (I've personally been unable to witness this occurring in a local development environment).
Often occurs with tests in Python 3.8 (Python >= 3.9, < 3.11 appear to succeed when they reach adjacent completion)
FileNotFoundError is emitted for extracted chunks of data in no apparent pattern (the files are often sourced from different chunk offsets or tables).
In the context of test_convert_s3_path_sqlite, cytotable.convert is used 3 times. The first two convert's succeed without failure, the third is typically the one which fails when this error occurs (error seems to manifest on running the same process multiple times with the first runs succeeding).
Pytest fixture nesting related to temporary directory usage in the testing suite does not appear to be a root cause (a hotfix was attempted here with issues persisting after merge here).
Adding simulated time.sleep delays for _source_chunk_to_parquet does not seem to exhibit the issue consistently (possibly indicating workflows steps are completing as designed).
Both DuckDB SQL COPY and pyarrow.parquet.write_table exhibit the issue (moving to one or the other doesn't resolve the issue).

Marking this as closed with merge of #83 , deferring to open new issues if this occurs again in the same way.