Parquet AVRO tests fail when debug logging is enabled

I found that on my machine some of the tests in the parquet-avro fail.
Tests run: 25, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.073 sec
Running org.apache.parquet.avro.TestAvroDataSupplier
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
Running org.apache.parquet.avro.TestReadWrite
Tests run: 18, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 0.414 sec <<< FAILURE!
Running org.apache.parquet.avro.TestBackwardCompatibility
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec
Running org.apache.parquet.avro.TestReadWriteOldListBehavior
Tests run: 16, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 0.148 sec <<< FAILURE!
Running org.apache.parquet.avro.TestInputOutputFormat
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.29 sec
Running org.apache.parquet.avro.TestReflectLogicalTypes
Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.165 sec
Running org.apache.parquet.avro.TestCircularReferences
Tests run: 1, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0 sec

Results :

Failed tests:   testWriteReflectReadGeneric(org.apache.parquet.avro.TestReflectReadWrite): expected:<{"myboolean": true, "mybyte": 1, "myshort": 1, "myint": 1, "mylong": 2, "myfloat": 3.1, "mydouble": 4.1, "mybytes": {"bytes": "\u0001\u0002\u0003\u0004"}, "mystring": "Hello", "myenum": "A", "mymap": {"a": "1", "b": "2"}, "myshortarray": [1, 2], "myintarray": [1, 2], "mystringarray": ["a", "b"], "mylist": ["a", "b", "c"]}> but was:<{"myboolean": true, "mybyte": 1, "myshort": 1, "myint": 1, "mylong": 2, "myfloat": 3.1, "mydouble": 4.1, "mybytes": {"bytes": ""}, "mystring": "Hello", "myenum": "A", "mymap": {"a": "1", "b": "2"}, "myshortarray": [1, 2], "myintarray": [1, 2], "mystringarray": ["a", "b"], "mylist": ["a", "b", "c"]}>
  testWriteDecimalBytes(org.apache.parquet.avro.TestGenericLogicalTypes): Should read BigDecimals as bytes expected:<[{"dec": {"bytes": "ò\u0096"}}, {"dec": {"bytes": "\u0000²àø"}}]> but was:<[{"dec": {"bytes": ""}}, {"dec": {"bytes": ""}}]>
  testAll[0](org.apache.parquet.avro.TestReadWrite): expected:<java.nio.HeapByteBuffer[pos=0 lim=5 cap=5]> but was:<java.nio.HeapByteBuffer[pos=5 lim=5 cap=5]>
  testAllUsingDefaultAvroSchema[0](org.apache.parquet.avro.TestReadWrite): expected:<java.nio.HeapByteBuffer[pos=0 lim=5 cap=5]> but was:<java.nio.HeapByteBuffer[pos=5 lim=5 cap=5]>
  testAll[1](org.apache.parquet.avro.TestReadWrite): expected:<java.nio.HeapByteBuffer[pos=0 lim=5 cap=5]> but was:<java.nio.HeapByteBuffer[pos=5 lim=5 cap=5]>
  testAllUsingDefaultAvroSchema[1](org.apache.parquet.avro.TestReadWrite): expected:<java.nio.HeapByteBuffer[pos=0 lim=5 cap=5]> but was:<java.nio.HeapByteBuffer[pos=5 lim=5 cap=5]>
  testAll[0](org.apache.parquet.avro.TestReadWriteOldListBehavior): expected:<java.nio.HeapByteBuffer[pos=0 lim=5 cap=5]> but was:<java.nio.HeapByteBuffer[pos=5 lim=5 cap=5]>
  testAllUsingDefaultAvroSchema[0](org.apache.parquet.avro.TestReadWriteOldListBehavior): expected:<java.nio.HeapByteBuffer[pos=0 lim=5 cap=5]> but was:<java.nio.HeapByteBuffer[pos=5 lim=5 cap=5]>
  testAll[1](org.apache.parquet.avro.TestReadWriteOldListBehavior): expected:<java.nio.HeapByteBuffer[pos=0 lim=5 cap=5]> but was:<java.nio.HeapByteBuffer[pos=5 lim=5 cap=5]>
  testAllUsingDefaultAvroSchema[1](org.apache.parquet.avro.TestReadWriteOldListBehavior): expected:<java.nio.HeapByteBuffer[pos=0 lim=5 cap=5]> but was:<java.nio.HeapByteBuffer[pos=5 lim=5 cap=5]>

I see two classes of problems:

The json with byte arrays appear different.
Some tests compare the 'toString' of a ByteBuffer. Now for two ByteBuffers that both contain the SAME bytes these tests fail simply because the position field of the ByteBuffer is different. I think these should compare the contents of the ByteBuffer instead.<java.nio.HeapByteBuffer[pos=0 lim=5 cap=5]> but was:<java.nio.HeapByteBuffer[pos=5 lim=5 cap=5]>

Reporter: Niels Basjes / @nielsbasjes
Assignee: Niels Basjes / @nielsbasjes
Related issues:

Release 1.8.2 (is blocked by)
Upgrade Avro to 1.8.1 (relates to)

Note: This issue was originally created as PARQUET-725. Please see the migration documentation for further details.

Niels Basjes / @nielsbasjes:
It seems the ByteBuffer problem is caused by the fact that the Buffer.equals(...) method also looks at the position field. Not just the 'actual content'.
Simple fix: Just pull the byte array and compare that.
Effectively several places:
-    assertEquals(ByteBuffer.wrap("hello".getBytes(Charsets.UTF_8)), nextRecord.get("mybytes"));
+    assertArrayEquals(ByteBuffer.wrap("hello".getBytes(Charsets.UTF_8)).array(), ((ByteBuffer) nextRecord.get("mybytes")).array());

Niels Basjes / @nielsbasjes:
Found the root cause (fixed in a yet to be released version of AVRO):
AVRO-1799:  java: GenericData.toString() mutates underlying ByteBuffer backed data
This also is the reason this problem did not occur in my IDE (IntelliJ).
The debugger underlying does a 'toString' to show the record on the screen during debugging.
Because this was done on both the 'equals' a step later would now succeed, while when running it would make it fail.

Niels Basjes / @nielsbasjes:
Easy fix:
diff --git a/parquet-avro/src/test/resources/car.avdl b/parquet-avro/src/test/resources/car.avdl
index b848da5..1f459a3 100644
--- a/parquet-avro/src/test/resources/car.avdl
+++ b/parquet-avro/src/test/resources/car.avdl
@@ -21,7 +21,7 @@
 protocol Cars {

     record Service {
-        long date;
+        long `date`;
         string mechanic;
     }

Niels Basjes / @nielsbasjes:
So the root cause is AVRO-1799 which surfaced after changing the logging setup in PARQUET-423.
For now I pushed a default log4j.properties that is set to INFO logging.
This passed the build. Set if to DEBUG and the build will fail.
The action that remains for this issue is to upgrade to AVRO 1.8.2 (as soon as it is released).
aIf you don't then any logging of the AVRO related data is likely to be modified by the logging itself.

Niels Basjes / @nielsbasjes:
After AVRO 1.8.2. has been released this problem can easily be fixed by changing the version of AVRO in the pom.xml.
So this issue will eventually be fixed with:
diff --git pom.xml pom.xml
index ca34309..e1f0cfd 100644
--- pom.xml
+++ pom.xml
@@ -86,7 +86,7 @@
     <fastutil.version>6.5.7</fastutil.version>
     <semver.api.version>0.9.33</semver.api.version>
     <slf4j.version>1.7.5</slf4j.version>
-    <avro.version>1.8.0</avro.version>
+    <avro.version>1.8.2</avro.version>
     <guava.version>11.0</guava.version>
     <mockito.version>1.9.5</mockito.version>
   </properties>

Ryan Blue / @rdblue:
Another work-around for this is to use slf4j-simple during tests, which is configured at INFO by the root POM. The reason why the log level is DEBUG is that slf4j-log4j12 is being pulled in transitively through hadoop-client. Excluding that dependency (which is provided anyway) avoids the problem. We still need to update Avro once it is fixed, but this will allow builds to pass for now.
diff --git a/parquet-avro/pom.xml b/parquet-avro/pom.xml
index b34838f..5eaf1e0 100644
--- a/parquet-avro/pom.xml
+++ b/parquet-avro/pom.xml
@@ -63,6 +63,13 @@
       <artifactId>hadoop-client</artifactId>
       <version>${hadoop.version}</version>
       <scope>provided</scope>
+      <exclusions>
+        <exclusion>
+          <!-- this changes logger used in testing -->
+          <groupId>org.slf4j</groupId>
+          <artifactId>slf4j-log4j12</artifactId>
+        </exclusion>
+      </exclusions>
     </dependency>
     <dependency>
       <groupId>com.google.guava</groupId>

Niels Basjes / @nielsbasjes:
Looks like the date problem has been picked up in PARQUET-765.
To fix the debug logging problem Avro 1.8.2 is needed.

Niels Basjes / @nielsbasjes:
I found that the upgrade to Avro 1.8.2 has been done in PARQUET-1149
I verified and the problem described here no longer occurs.

Niels Basjes / @nielsbasjes:
Note that AVRO 1.8.2 (as it stands currently) is likely to introduce this problem AVRO-1924 because that is used in the file parquet-avro/src/test/resources/car.avdl


Create new-user-story.yaml

New user story template based on team collaboration to establish a consistent approach to user stories, acceptance criteria, and technical tasks.

It looks like you can sorta preview them if you browse to the file on the branch the PR is on. In this case:

https://github.com/cfpb/sbl-project/blob/add-story-issue-template/.github/ISSUE_TEMPLATE/new-user-story.yaml

It doesn't render the way it will on the issue, and some of the settings just get pushed to the top into a table, but it should at least help you debug any issues with the config file.


Bad rendering on Raspberry Pi 3 with OpenGL

Versions

Python: 3.5.3
OS: Raspbian Stretch with packages up to date
Kivy: Master branch (67f7dee)
Kivy installation method: pip install https://github.com/kivy/kivy/archive/master.zip

Description
I tried running the kivycatalog demo on my Raspberry Pi 3 model B.
If I disable hardware acceleration using rapsi-config, the demo works fine but is very slow.
After enabling the OpenGL (full KMS) drivers, only the right side of the window gets drawn (scroll down for a picture). The resizing handle, menus at the top and text editor window on the left is all black.
Logs
[INFO   ] Logger: Record log in /home/pi/.kivy/logs/kivy_17-12-03_8.txt
[WARNING] [Config      ] Upgrading configuration in progress.
[WARNING] [Config      ] Older configuration version detected (20 instead of 19)
[INFO   ] Kivy: v1.10.1.dev0, git-Unknown, 20171203
[INFO   ] Python: v3.5.3 (default, Jan 19 2017, 14:11:04)
[GCC 6.3.0 20170124]
[INFO   ] Factory: 194 symbols loaded
[INFO   ] Image: Providers: img_tex, img_dds, img_pygame, img_pil, img_gif (img_ffpyplayer ignored)
[INFO   ] Text: Provider: pygame
[INFO   ] Window: Provider: pygame(['window_egl_rpi'] ignored)
[INFO   ] GL: Using the "OpenGL" graphics system
[INFO   ] GL: Backend used <gl>
[INFO   ] GL: OpenGL version <b'2.1 Mesa 13.0.6'>
[INFO   ] GL: OpenGL vendor <b'Broadcom'>
[INFO   ] GL: OpenGL renderer <b'Gallium 0.4 on VC4 V3D 2.1'>
[INFO   ] GL: OpenGL parsed version: 2, 1
[INFO   ] GL: Shading version <b'1.20'>
[INFO   ] GL: Texture max size <2048>
[INFO   ] GL: Texture max units <16>
[INFO   ] Window: virtual keyboard allowed, single mode, docked
[INFO   ] Clipboard: Provider: gtk3(['clipboard_dbusklipper'] ignored)
[INFO   ] Cutbuffer: Provider: xclip
[INFO   ] CutBuffer: cut buffer support enabled
[INFO   ] VideoGstplayer: Using Gstreamer <IP_ADDRESS>
[INFO   ] Video: Provider: gstplayer
[ERROR  ] Image: Error loading texture ../../widgets/cityCC0.mpg
[INFO   ] GL: NPOT texture support is available
[INFO   ] OSC: using <multiprocessing> for socket
[INFO   ] ProbeSysfs: device match: /dev/input/event0
[INFO   ] MTD: Read event from </dev/input/event0>
[INFO   ] ProbeSysfs: device match: /dev/input/event0
[INFO   ] HIDInput: Read event from </dev/input/event0>
[INFO   ] Base: Start application main loop
[INFO   ] MTD: </dev/input/event0> range position X is 0 - 800
[INFO   ] MTD: </dev/input/event0> range position Y is 0 - 480
[INFO   ] MTD: </dev/input/event0> range touch major is 0 - 0
[INFO   ] MTD: </dev/input/event0> range touch minor is 0 - 0
[INFO   ] MTD: </dev/input/event0> range pressure is 0 - 255
[INFO   ] MTD: </dev/input/event0> axes invertion: X is 0, Y is 0
[INFO   ] MTD: </dev/input/event0> rotation set to 0
[INFO   ] HIDMotionEvent: using <chinese touchscreen>
[INFO   ] HIDMotionEvent: <chinese touchscreen> range ABS X position is 0 - 800
[INFO   ] HIDMotionEvent: <chinese touchscreen> range ABS Y position is 0 - 480
[INFO   ] HIDMotionEvent: <chinese touchscreen> range ABS pressure is 0 - 255
[INFO   ] HIDMotionEvent: <chinese touchscreen> range position X is 0 - 800
[INFO   ] HIDMotionEvent: <chinese touchscreen> range position Y is 0 - 480
[INFO   ] HIDMotionEvent: <chinese touchscreen> range pressure is 0 - 255

Config
[kivy]
keyboard_repeat_delay = 300
keyboard_repeat_rate = 30
log_dir = logs
log_enable = 1
log_level = info
log_name = kivy_%y-%m-%d_%_.txt
window_icon =
keyboard_mode = dock
keyboard_layout = qwerty
desktop = 1
exit_on_escape = 0
pause_on_minimize = 0
kivy_clock = default
default_font = ['Roboto', 'data/fonts/Roboto-Regular.ttf', 'data/fonts/Roboto-Italic.ttf', 'data/fonts/Roboto-Bold.ttf', 'data/fonts/Roboto-BoldItalic.ttf']
log_maxfiles = 100
window_shape = data/images/defaultshape.png
config_version = 20

[graphics]
display = -1
fullscreen = 0
height = 480
left = 0
maxfps = 60
multisamples = 2
position = auto
rotation = 0
show_cursor = 1
top = 0
width = 800
resizable = 0
borderless = 0
window_state = visible
minimum_width = 0
minimum_height = 0
min_state_time = .035
allow_screensaver = 0
shaped = 0

[input]
mouse = mouse
mtdev_%(name)s = probesysfs,provider=mtdev
hid_%(name)s = probesysfs,provider=hidinput

[postproc]
double_tap_distance = 20
double_tap_time = 250
ignore = []
jitter_distance = 0
jitter_ignore_devices = mouse,mactouch,
retain_distance = 50
retain_time = 0
triple_tap_distance = 20
triple_tap_time = 375

[widgets]
scroll_timeout = 250
scroll_distance = 20
scroll_friction = 1.
scroll_stoptime = 300
scroll_moves = 5

[modules]

Outcome of running kivycatalog with hardware acceleration (Notice I can still use the widgets that aren't being drawn such as the resizing bar in this case):

Update: I was able to replicate this using the same hardware (Pi 3 model B) using KivyPie by simply running raspi-config and enabling experimental drivers with full KMS under advanced > OpenGL and rebooting.

Did you ever figure this out? I'm facing the same issue

Yes, I ended up using Ubuntu MATE 16 (MATE being important as it pulls in
older mesa/vc drivers or something) if you're running a raspberry pi 3b+
you can find third party ISOs for that but you'll need to copy over some
firmware files to get WiFi working.
The state is afaik: Ubuntu MATE had an old driver that works perfectly with
full KMS driver support
Drivers on the  latest raspbian has crashing/memory leak issues
Kivypi gave me this weird bug to begin with
And there's a thread regarding kivy and the videocore drivers on the
raspberry pi forums where a Pi engineer said you can build the drivers from
source yourself on the latest raspbian (or LFS for that matter?)
On Thu, Oct 25, 2018, 6:42 AM nicod182<EMAIL_ADDRESS>wrote:

Did you ever figure this out? I'm facing the same issue
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kivy/kivy/issues/5511#issuecomment-433002839, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAf3MrlsG32jB7lrleI6Am57G4C8USGgks5uoZWOgaJpZM4QzxKZ
.

@nicod182 Here is the forum thread mentioned in my last comment:
https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=216804&sid=6737631294cc008038399cb9bdf88b22&start=25

@xaviergmail Thank you very much for these tips, I'll try it before losing hope with kivy


Workaround change to needs_migration? in rails 5.2

In rails 5.2.0 there was a change to
ActiveRecord::Migrator.needs_migration? and it was moved under a
MigrationContext class.
Introduced by https://github.com/rails/rails/pull/31727

cc @jrafanie @carbonin

Opened https://github.com/ManageIQ/topological_inventory-api/pull/77 as an alternative. I don't think we actually need this logic.

:+1: works for me

👍 thanks for the headup

Or headsup


Fix Word converter warnings

Please verify these changes carefully.
With these in place, the only warnings are:
classes.md(2030): WARNING MD16: Term 'block body' defined a second time
classes.md(2024): WARNING MD16b: Here was the previous definition of term 'block body'
classes.md(2030): WARNING MD16: Term 'expression body' defined a second time
classes.md(2024): WARNING MD16b: Here was the previous definition of term 'expression body'
classes.md(3171): WARNING MD16: Term 'expression body' defined a second time
classes.md(2024): WARNING MD16b: Here was the previous definition of term 'expression body'

Those can be addressed later, as noted in #948.
After these changes are applied, this is the result: standard.docx

New version of the Word doc:
standard.docx

Out of curiosity, how does the C# 7 standardization proceed from here? I see there is a TC49-TG2 meeting scheduled for 4 October 2023; is that when you'll formally decide whether to send the Word document to ECMA?

Nope, that was basically decided yesterday. The October meeting is to make a start on the pre-C#-8 work, and to discuss how to divide the C# 8 features.
Rex is going to perform tweaks on the Word doc (there are bits that the converter can't do) and send it on to ECMA in about a week, to start the ratification process.

I don't think the changes in grammar.md are strictly necessary, as they'll be rewritten by an automated PR, but they are consistent with the changes in other files.

They were all automated already, so should be okay :)

Ah - it looks like we need 3 approving reviews for standard- branches. Let's wait until @RexJaeschke reviews as well, but at that point we can override and merge :)


build: Update poetry installation method

The installation method in the current Dockerfile is considered "deprecated" as of v1.2.0, see the disclaimer on their website: https://python-poetry.org/docs/#installation

Thanks @macintacos 💖


Support inspec attributes

I want to be able to pass in attributes to the inspec profile(s) that are in my list of profiles.
The inspec profile can use attributes and passed in an attributes.yml file. The chef run should be able to define these attributes, per profile, like this:
"audit": {
  "reporter": "chef-server-compliance",
  "inspec_version": "1.29.0",
  "profiles": [
    {
      "name": "linux",
      "compliance": "base/linux",
      "attributes": {
        "role": "mywebserver"
      }
    }
  ]
}

The audit cookbook will take attributes (if they exist) and pass those to the inspec profile when it runs it.
This enables "one profile to rule them all" pattern that @jeremymv2 proposed, but with a more inspec-native construct.

👍


pip install sparklingpandas failed

Error message:
Traceback (most recent call last):
      File "<string>", line 20, in <module>
      File "/private/tmp/pip-build-ibiITf/SparklingPandas/setup.py", line 12, in <module>
        long_description=open('README.md').read(),
    IOError: [Errno 2] No such file or directory: 'README.md'
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):

      File "<string>", line 20, in <module>

      File "/private/tmp/pip-build-ibiITf/SparklingPandas/setup.py", line 12, in <module>

        long_description=open('README.md').read(),

    IOError: [Errno 2] No such file or directory: 'README.md'

Thanks for point this out, I've always pip installed from the git repo so didn't notice this. I'll merge a fix soon.

I think the problem is that you have MANIFSET.in instead of MANIFEST.in.


Fix INSERT SELECT and add more test cases

This PR fixes two INSERT SELECT bugs.
Without this PR,

inserting tuples with SELECT on some specific order of columns may not be working correctly. (e.g. INSERT INTO foo1 SELECT b, a FROM foo2; may behave like INSERT INTO foo1 SELECT a, b FROM foo2; when foo1 has columns order of a and b.)
inserting tuples with SELECT may insert more tuples than required (e.g. INSERT INTO foo1 SELECT a, b FROM foo2; will insert more than the number of tuples from foo2.)

The column attribute information was not correctly retrieved in INSERT for the former case, and it is fixed. The latter was there because the tuples inserted were scanned again by the table scanner depending on the tile group selection.  This is fixed by keeping  a separate filter in INSERT to filter out those.  It could also implemented in other ways, e.g. the modules underneath the INSERT logic may take a sort of filter. It may be more efficient, but more complex, so for the moment, we do this at INSERT.
The legacy test cases did not cover all the cases, so more of them are added, too.

Coverage increased (+0.06%) to 75.432% when pulling bb44bb48bb3b8f6435b4ac3eb73efbca953645b5 on seojungmin:insert-select into ba1bfd57abb090a18bcbdee8b6c26b32f156c34b on cmu-db:master.

Coverage increased (+0.04%) to 75.414% when pulling d74f81a51733700eda324fb0c4c1fbad8eaa516f on seojungmin:insert-select into ba1bfd57abb090a18bcbdee8b6c26b32f156c34b on cmu-db:master.

@huangminchn This is the fixed I referred to that should fix your index scan into insert problem.
@seojungmin Can you provide some more details on the second bug this PR fixes? I can't reproduce it locally on master. From the look of it, you're duplicating information stored in the transaction's read/write set. At best, it's as simple as a missed check somewhere in TXN management; at worst it's a more insidious transaction bug. Either way, I'd prefer pulling these apart

The second one is reproducible, when the insertion of tuples are done to the tile groups that have not been selected to be read.  In those cases, when the table scan is executed, it does not distinguish whether it has been inserted by the current query or by the ones before this query.
The TXN manager may check this, but as far as I know, it also requires an additional read-write set to check whether the tuple is inserted by this query, since the concept of a read-write set at the TXN manager should be built around a transaction.  Do we have such facility inside or outside the read-write set?

@seojungmin Can you provide a SQL session that reproduces the bug?

@pmenon Sure. I am interested that it has not been reproducible in your session. I checked this in dev4 and 5. I did not check it at my laptop(OSX), though.
postgres=# create table foo(a int);
CREATE TABLE
postgres=# insert into foo values(1),(2);
INSERT 0 2
postgres=# select * from foo;
 a
---
 1
 2
(2 rows)

postgres=# insert into foo select * from foo;
INSERT 0 10
postgres=# select * from foo;
 a
---
 1
 1
 2
 2
 1
 2
 1
 2
 1
 2
 1
 2
(12 rows)

postgres=#

Coverage increased (+0.04%) to 75.414% when pulling d74f81a51733700eda324fb0c4c1fbad8eaa516f on seojungmin:insert-select into ba1bfd57abb090a18bcbdee8b6c26b32f156c34b on cmu-db:master.

I close this PR, since a similar case may occur in other queries.
This should be re-written by introducing a generalized filter for filtering out the tuples inserted by the current execution "context".  The execution engine translator, e.g. INSERT in this case, builds a generalized filter, and the table scanner should apply this filter only when it is required, e.g. scanning while inserting to the same table.


Tapping on Add to Spotify while not logged in

When a user taps on the plus button on the sticky player, it brings them to the settings page. There is no easy way to bring themselves back to the Feed.
Temporary fix would be to have the navigation on the side show that you are in the settings page. See below, it shows that you are still on Feed.
But the screen is still slightly confusing since it shows notifications settings as well, I'll look into designing a better screen that makes it clear right away that button is for people connected to spotify.

Currently as of 0.9 they can press the back arrow in navigation bar to go back to what they were doing

Yeah like Dennis said, I addressed this issue so I'm just gonna close it


Button detection doesn't work using EB==0

Hi Alex,
your plugin is exactly what I've been looking for! I couldn't get my FTM215 to work and have found out the following:
Using R1 to detect which button has been pressed only works when EB==1 (pressed event), not when EB==0 (released event). R1 is always 0 when EB==0.
I made a very small adjustment and it seems to work for me now:

Ignore the released event altogether (It seems the pressed event triggers button rules in HomeKit);
Look for the pressed event as a trigger for setSwitchEventValue.

(Code changes are in my fork)
Best,
Philipp

I'm trying to get this plugin to work but to no avail. Do you run HomeBridge on Raspberry Pi / Raspbian by any chance?
Would like to try out your fork, how can I get it to work in HomeBridge?

I had my homebridge instance running on an RPI for quite a while, so it should work! I have not pushed my fork to NPM yet, so you would have to clone the fork locally from GitHub and run "npm install" or the global version, depending on your setup. You should be able to use it in your homebridge config after that.

Thanks for you help. I removed homebridge-enocean, cloned yours to my RPi and tried 'sudo npm install' but I get errors, relating to serial port issues it seems.
gyp WARN EACCES current user ("pi") does not have permission to access the dev dir "/root/.cache/node-gyp/12.16.1"
gyp WARN EACCES attempting to reinstall using temporary dev dir<EMAIL_ADDRESS>gyp WARN install got an error, rolling back install
gyp WARN install got an error, rolling back install
gyp ERR! configure error
gyp ERR! stack Error: EACCES: permission denied, mkdir<EMAIL_ADDRESS>gyp ERR! System Linux 4.19.97-v7+
gyp ERR! command "/usr/bin/node" "/usr/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /home/homebridge/homebridge-enocean/node_modules/@serialport/bindings
gyp ERR! node -v v12.16.1
gyp ERR! node-gyp -v v5.1.0
gyp ERR! not ok
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>install: `prebuild-install --tag-prefix @serialport/bindings@ || node-gyp rebuild`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

I've also tried to run npm install serialport and npm install raspi-serial but I get errors that way too

That’s a permission problem with a dependency. You might want to try —unsafe-perm with your npm call.
On Mon, Apr 13, 2020, at 18:25, jeroen020 wrote:

Thanks for you help. I removed homebridge-enocean, cloned yours to my RPi and tried 'sudo npm install' but I get errors, relating to serial port issues it seems.

gyp WARN EACCES current user ("pi") does not have permission to access the dev dir "/root/.cache/node-gyp/12.16.1" gyp WARN EACCES attempting to reinstall using temporary dev dir<EMAIL_ADDRESS>gyp WARN install got an error, rolling back install gyp WARN install got an error, rolling back install gyp ERR! configure error  gyp ERR! stack Error: EACCES: permission denied, mkdir<EMAIL_ADDRESS>gyp ERR! System Linux 4.19.97-v7+ gyp ERR! command "/usr/bin/node" "/usr/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild" gyp ERR! cwd /home/homebridge/homebridge-enocean/node_modules/@serialport/bindings gyp ERR! node -v v12.16.1 gyp ERR! node-gyp -v v5.1.0 gyp ERR! not ok  npm ERR! code ELIFECYCLE npm ERR! errno 1 npm ERR<EMAIL_ADDRESS>install: prebuild-install --tag-prefix @serialport/bindings@ || node-gyp rebuild`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

`

I've also tried to run npm install serialport and npm install raspi-serial but I get errors that way too

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/alexsporn/homebridge-enocean/issues/1#issuecomment-612972898, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHYIIHX4XHMEACNQRREDJDRMM4GVANCNFSM4KISNIQA.

Thanks for your quick reply. It was weird, first time I tried adding --unsafe-perm I got errors, but just did it again and it now it looks like it has actually installed, no more errors.
Next stumbling block is how to make the plugin appear in HomeBridge - when I select 'Plugins' in the web interface, it only shows the default Homebridge Config UI X. I unpacked the zip in /home/homebridge/homebridge-enocean and added code to the config, but as the plugin is not registered, it gives errors. How do I make your plugin appear in the Homebridge web interface?

The example config file in the repo was not up to date. I just commited a version that should work.
You don't have to register plugins with homebridge as a separate step. Just use the platform in the config file and make sure that the plugin is installed in the npm repo that homebridge uses.
On Tue, Apr 14, 2020, at 09:37, jeroen020 wrote:

Thanks for your quick reply. It was weird, first time I tried adding --unsafe-perm I got errors, but just did it again and it now it looks like it has actually installed, no more errors.

Next stumbling block is how to make the plugin appear in HomeBridge - when I select 'Plugins' in the web interface, it only shows the default Homebridge Config UI X. I unpacked the zip in /home/homebridge/homebridge-enocean and added code to the config, but as the plugin is not registered, it gives errors. How do I make your plugin appear in the Homebridge web interface?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/alexsporn/homebridge-enocean/issues/1#issuecomment-613276981, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHYIIFDCCYAYZRO2M2VXEDRMQHCPANCNFSM4KISNIQA.

Yay, I've got it running! The install command that did it in the end was:
pi@raspberrypi:/home/homebridge $ sudo npm install -g https://github.com/zonefuenf/homebridge-enocean.git --unsafe-perm
Thanks so much for your help and patience, I now have a use for all those spare EnOcean switches!

Did some more testing, I get about 2 floors reach, which is not bad. However I noticed the plugin crashed after a while, with the following error:
[4/14/2020, 3:40:53 PM] [EnOcean] fef4c1d0 RPi2: Button A0 pressed
[4/14/2020, 3:41:08 PM] [EnOcean] fef4c1d0 RPi2: Button AI pressed
[4/14/2020, 3:41:08 PM] [EnOcean] fef4c1d0 RPi2: Button AI pressed
[4/14/2020, 3:41:09 PM] [EnOcean] fef4c1d0 RPi2: Button AI pressed
[4/14/2020, 3:41:53 PM] [EnOcean] Unknown sender fef4d1d0
(node:23238) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'services' of undefined
    at EnoceanPlatform.setSwitchEventValue (/usr/lib/node_modules/homebridge-enocean-zonefuenf/index.js:61:21)
    at Enocean.<anonymous> (/usr/lib/node_modules/homebridge-enocean-zonefuenf/index.js:43:19)
    at Enocean.emit (events.js:311:20)
    at Enocean.EventEmitter.emit (domain.js:482:12)
    at ESP3Transformer.<anonymous> (/usr/lib/node_modules/homebridge-enocean-zonefuenf/Enocean.js:52:25)
    at ESP3Transformer.emit (events.js:311:20)
    at ESP3Transformer.EventEmitter.emit (domain.js:482:12)
    at addChunk (_stream_readable.js:294:12)
    at readableAddChunk (_stream_readable.js:275:11)
    at ESP3Transformer.Readable.push (_stream_readable.js:209:10)
(node:23238) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:23238) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

When I restart HomeBridge it works as expected again.
Also, more of a warning, I see this message in the log:
[4/14/2020, 3:45:36 PM] [Config] [homebridge-enocean-zonefuenf] Failed to check registry.npmjs.org for updates: Request failed with status code 404

Thanks for the feedback. There seems to be a bug when a new sender is detected without having been configured first.
The npm error in the log is caused by me not having properly published the package to the repo. I was going to do that anyway, because it makes updating a lot easier.

Thanks @zonefuenf, that explains it. To cover my home I now have two raspberry's configured for Enocean so it sounds like I have to configure each switch in both Homebridge instances, otherwise it would crash the one it's not configured for. So if this bug could be fixed that would be great, is there any chance that'll happen? I'm planning to add a bunch of Enocean switches so would be good to know.

The NPM problem should be solved by now, I uploaded a release to the repo. I'm going to look into the other problem, as I agree that it's pretty serious. I can't promise a timeline, though.
On Tue, Apr 28, 2020, at 09:58, jeroen020 wrote:

Thanks @zonefuenf https://github.com/zonefuenf, that explains it. To cover my home I now have two raspberry's configured for Enocean so it sounds like I have to configure each switch in both Homebridge instances, otherwise it would crash the one it's not configured for. So if this bug could be fixed that would be great, is there any chance that'll happen? I'm planning to add a bunch of Enocean switches so would be good to know.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/alexsporn/homebridge-enocean/issues/1#issuecomment-620445331, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHYIIERDVFLTQTPZ5PMEC3RO2ECHANCNFSM4KISNIQA.

@jeroen020, I have published version 0.3.0, which should take care of your problem. I am going to close this issue for now. All code, documentation and issue tracking for my fork is at https://github.com/zonefuenf/homebridge-enocean-zonefuenf

Hero! Just tested it and it works. You've just made my weekend!

Sorry I haven’t taken a look at this, been busy with other projects and moved from homebridge to homeassistant for all of my home automation

That’s fine! I have solved my problem and added a few little things here and there in my fork. Thanks for starting this, it’s really useful.
On Fri, May 1, 2020, at 15:15, Alexander Sporn wrote:

Sorry I haven’t taken a look at this, been busy with other projects and moved from homebridge to homeassistant for all of my home automation

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub https://github.com/alexsporn/homebridge-enocean/issues/1#issuecomment-622383454, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHYIIFMGIAAVLYXKLZMS6DRPLDQNANCNFSM4KISNIQA.


docs(ee/34/plugins) update video for consumers

NOTE: Please read the CONTRIBUTING.md guidelines before submitting your patch,
and ensure you followed them all:
https://github.com/Kong/docs.konghq.com/blob/master/CONTRIBUTING.md
Summary
Update video in Getting Started: Creating Consumers to use 0.34 UI.

Checklist:

[x] Commit message & atomicity checked
[x] Documentation
[x] Spellchecked my updates
[x] Ready to be merged

@jitachi , @pd333 , see the preview at: https://5c5b813cf498cf0008745f3c--kongdocs.netlify.com/enterprise/0.34-x/getting-started/adding-consumers/#1-create-a-consumer


Vitest crashes and isn't recoverable if global-setup fails

Describe the bug
See these logs:
[INFO 11:59:12] [Vitest] Extension is activated because Vitest is installed or there is a Vite/Vitest config file in the workspace.
[INFO 11:59:12] [API] Running Vitest: v1.4.0 (/Users/dkMaLyLo/Documents/tmp/vscode/samples/basic/vitest.config.ts)
[Worker] root /Users/dkMaLyLo/Documents/tmp/vscode/samples/basic
[INFO 11:59:12] [API] Vitest process 12024 created
[Worker] Starting inspector on <IP_ADDRESS>:53040 failed: address already in use
[Error 11:59:14] [API] [Error Error] write EPIPE
Error: write EPIPE
    at ChildProcess._send (node:internal/child_process:865:20)
    at ChildProcess.send (node:internal/child_process:738:19)
    at post (/Users/dkMaLyLo/Documents/tmp/vscode/src/api/rpc.ts:101:16)
    at ChildProcess.<anonymous> (/Users/dkMaLyLo/Documents/tmp/vscode/node_modules/.pnpm/birpc@0.2.17/node_modules/birpc/dist/index.mjs:77:9)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
[Worker]
⎯ Error during global setup ⎯⎯
Error: This is a global setup error.
 ❯ Object.setup global-setup.ts:2:9
      1| export default async function () {
      2|     throw new Error('This is a global setup error.')
       |         ^
      3| };
 ❯ rerunTests ../../dist/worker.js:929:5
 ❯ runTests ../../dist/worker.js:938:9
 ❯ Proxy.collectTests ../../dist/worker.js:973:7
 ❯ process.<anonymous> ../../dist/worker.js:852:20

Reproduction

Clone this: https://github.com/ffMathy/vscode/tree/feature/repro-global-setup-crash
Run the basic tests sample.
It now can't discover or run any tests, and it gets stuck in a state where the socket disconnects and can't reconnect.

System Info
System:
    OS: macOS 14.4
    CPU: (10) arm64 Apple M1 Pro
    Memory: 118.06 MB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.15.0 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 9.5.0 - /usr/local/bin/npm
    pnpm: 8.6.12 - /usr/local/bin/pnpm
  IDEs:
    VSCode: 1.87.2 - /opt/homebrew/bin/code
    Vim: 9.0 - /usr/bin/vim
    Xcode: 15.3/15E204a - /usr/bin/xcodebuild
  Browsers:
    Chrome: 123.0.6312.59
    Edge: 122.0.2365.92
    Safari: 17.4
  npmPackages:
    vite: ^2.8.6 => 2.9.9
    vitest: ^1.4.0 => 1.4.0

Used Package Manager
pnpm
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

What do you mean by "not recoverable"? Can't you fix the error and press "Refresh Tests" button?

Nope. Once it disconnects, I have to restart the entire VS Code window.


TS-4548: Fix LogHost leak on config error path.

Ping @zwoop

FreeBSD build successful! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/542/ for details.

Linux build successful! See https://ci.trafficserver.apache.org/job/Github-Linux/439/ for details.

:+1:


Glance to support toggling of entities without opening more-info

Allow for an option on glance to support toggling of entities (that support toggle) like picture-glance without the need to open more info dialog

balloob said in a group of entities all entities shall have to same action. to it will be toggle only or dialog only

That should be enough for start, gives people the flexibility.

Maybe a config option that is tap-action: more-info/toggle ?


focus set with random sampling for selection

try head and tail window sampling of the subjects table with a random sample of the results. @edpaget @parrish @marten thoughts?

We're going to need to add a a worker right away to regenerate the random column, right? Otherwise this is going to server ~2000 subjects at the start.

Still needs the OFFSET and the random value reassignment.
Probably would improve things as is though

yeah - we could have a daily job to regenerate the random column values..

random value assignment on selection will swamp the db index update, right?

It would need to be more often that than unless we could with Michael's OFFSET suggestion. ~2000 subjects active in a day might be way too low for some projects.

Somewhat.  Depends on the index.  It looks like it's a non-composite btree which isn't terrible.

Hourly is probably fine

Or we could just only reset random column when rand < 0.05 or something

Upside: if there's lots of activity, we reset the column more often so we distribute over the entire set better instead of focussing on 2000 subjects for an hour.
Downside: if there's lots of activity, the DB has more load, and then on top of that has to update this index more often.

@edpaget @parrish added a worker to reassign the random attribute of the "focussed" set thanks to @marten . thoughts?

I'd be concerned that it could queue a bunch of these workers and update all the random values multiple times in short succession.

Re earlier:

It would need to be more often that than unless we could with Michael's OFFSET suggestion. ~2000 subjects active in a day might be way too low for some projects.

Well if a subject is retired we'll automatically pick the next, so it's a sliding limit if I'm not mistaken. But the 2000 limit is up for debate, as is the 0.05 (together they accidentally average out so that each subject will have seen one classification by the time we reshuffle).

Cool, well I'm good to try this out.

If you're worried about triggering the random reassignment worker too frequently, you could always rate limit it: https://github.com/parrish/sidekiq-congestion
You'd probably want to set track_rejected to false and reject_with to reschedule.

You need to change something to get anything approaching uniformly random.
You could choose a random starting point
# no guarantee you'll get the number you're fetching
direction = rand < 0.5 ? '>' : '<'
where("random #{ direction } ?", rand) # assuming a 0-1 range

or you could limit/offset it
# at least attempts to get the number you're fetching
amount = 2_000 # or however many you're fetching
ceiling = [(rand * 50_000).ceil, count - amount].min
offset(ceiling).limit(amount)

Playing devils advocate, is there any pressing concern that this would solve that bumping the db instance type wouldn't for the few weeks? There isn't a project launching in the near future, so we aren't going to get any massive spike either.
Feels like subject selection is such a core part of the API that we really need to take the time to get it right, rather than applying additional band aids.

@chrissnyder not really, it'll be cheaper and it'd be nice not to have the db being worked if / when we scale back. I do think we have the tate re-email to go out soon but that won't use random selection.

I've tested this strategy using 2 million set member subjects (2 x workflows, 2 x subject sets with ~50% assignment of the data into the selecting workflow) as well. However some note:

index updates are executed in line
i'm only updating the random value of selected set_member_subjects not the whole focus window so this PR needs an update if that's acceptable.

This won't reflect heavy concurrent usage of the index update so we need a uniq jobs / rate limiter in sidekiq to ensure we don't stress the index updates with lots of selections. This strategy shows fairly constant execution times but will impact performance on index updates (as you can see), i'd say that since we background this job most selection queries will be pretty quick. Code here

It might be worth running your benchmarks on postgres running in a docker container with memory limits set to mirror a m3.medium instance see here
docker run -m 3.75G -c 1 postgresql

Update, I used a memory / cpu limited pg docker container -m 3750M --cpu-shares 2 (it wouldn't start with 1 cpu limit).
response times were pretty similar to previous readings for both selection strategies, the main difference was the resulting random distribution of selected sms ids. Not surprisingly the random offset had better distribution by default but still suffers from poor performance approaching 1M rows (where we are now). The focus set selection maintained pretty consistent performance, the only variation here was due to the window select size we pluck from. It doesn't spread selection as much but rather creates a focus set of data that is a function of the activity on the project and the selection space size. For instance a 5K selection window over 250K subjects is 12.5K subjects being in the focus set. Retirement will modify this by reducing the selection space as will more people requesting data will result in greater spread via more frequent index updates and the smaller the selection space the greater the spread we get.
In summary i think we should go with this strategy over the offset selection. I suggest running at the 5K selection window for fast queries (~40ms in my benchmarking but not sure what we'll see in prod db / network latency, etc).
I'm going to update this PR with a YAML configuration directive for this window size and only index update the selected sms ids. Also we'll need to rate limit the index updates so i guess this should come in too, though i'd like to get this out there sooner than later (next week now).
Any thoughts / objects appreciated.

This sounds fine to me.

cool - i'll finish this off over the weekend / first thing next week.

I've built the prod / staging config file and will push it once this has been approved.

This looks good to :ship: to me.


Implement netstrings protocol in the Channel

https://en.wikipedia.org/wiki/Netstring

C library:

https://github.com/PeterScott/netstring-c

Node side stuff:

https://github.com/pgriess/node-netstring/
https://www.npmjs.com/package/network-byte-order

Done.


Questions about checkpoints

Sorry for dumb questions. I didn't really understood the description. Is it possible to use your checkpoints for ViT models to do classification tasks? Can I just load them into these models (from openai git), without using your script? Are they better than original openai weights?

this code is only for reproducing the experiments presented in CoOp
if you're interested in CLIP only, please refer to OpenAI's code

So I can use their code and load your checkpoints in their models?


problem with resolve_dependency!(dag::ExprDAG, node::ExprNode{<:AbstractMacroNodeType, options)

I've been trying to revive some PETSc wrappers I started a long time ago, and upon updating Clang.jl to the latest release I ran into a problem caused by e6022d2f710563bfb98cd9738932f0c7c01ad885.
When this commit is applied, the RemoveCircularReference pass just loops forever.
If I revert these changes, even with the latest master branch, the code will at least complete for a simple test case.
I've tried to strip things down pretty minimally in this gist for what I am running.

cc @melonedo

This is because PETSc_jll/include/pestclog.h defines macros that "hide" the implementation, which looks like circular reference.
#define foo(a,b,c) log(a,b,c); foo(a,b,c)


Update s3-transfer-manager to 2.17.267-PREVIEW

Updates software.amazon.awssdk:s3-transfer-manager from 2.17.238-PREVIEW to 2.17.267-PREVIEW.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "software.amazon.awssdk", artifactId = "s3-transfer-manager" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "software.amazon.awssdk", artifactId = "s3-transfer-manager" }
}]

labels: test-library-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #772.


Add Multisignture support

Downstream users would like to be able to ultilize multisignature on Token Accounts. A Multisig program would be an option down the road, when cross-program invocations are enabled.
In the meantime, the shortest path seems to be to add M-of-N multisig support in Token.
Instead of just one account owner, enable configuration of each Token account to have N authorities (1 <= N <= 11) and M required signers for transfers and updates to authorities and num-required-signers.
WIP TODO:

More tests
Update js bindings

Fixes: #49

@mvines @CriesofCarrots First stab, thoughts?

@mvines In general, what do you think of this approach?  In particular, identifying the multisig account type by owner and size?  Still think we should apply that to Mint?

what do you think of this approach? In particular, identifying the multisig account type by owner and size? Still think we should apply that to Mint?

sgtm.   Yeah, I feel like the Mint should support multisig too.  MintTo is a superuser command, great use case for multisig

@mvines

sgtm. Yeah, I feel like the Mint should support multisig too. MintTo is a superuser command, great use case for multisig

Mint already supports multisignature since its owner can be a multisignature account.  Later SetOwner and MintTo will use multisignature to validate.
My question was what do you think about moving away from enum for Mint and to a standalone structure like is proposed here for MultiSig?

My question was what do you think about moving away from enum for Mint and to a standalone structure like is proposed here for MultiSig?

oh sry.   Yep I think so.   Ditch the enum entirely.  It's weird to use it for some but not all the token accounts

@mvines @CriesofCarrots
This PR is rendered obsolete by these changes: https://github.com/jackcmay/solana-program-library/pull/1


[ENH][FIX]  Add Configurable Line Endings

Fix for Issue #224
Add new Parameter
--line-ending
that controls how the line endings are set for the output file

I'm actually a bit tempted to not add the configuration option at all, and just always use a \n character always. This is what I thought the current behavior was until you proved otherwise :smile:
I'm not sure if there's a good reason to prefer \r\n and if there's one person on earth who needs that, running in serial with an end of line fixer should solve that.
If it's later apparent that many people need \r\n then the configuration could be introduced.
What do you think @DragonCrafted87 ?

yeah as while hardcoding it to purely lf would work in my case and I imagine most others I'm sure there's someone who wants all crlf line endings and like you said it will fail if there is an end of line fixer running in line with it in the same way I noticed it.
I should be able to clean up the rest of the comments this evening though I may need a hand with the test as I tend to use python more for scripting than anything complicated enough to need a test suite

:+1:
For tests, please add these to tests/test_cli.py:
def test_eol__lf(tmp_path):
    file_path = tmp_path / "test.md"
    file_path.write_bytes(b"Oi\r\n")
    assert run([str(file_path), "--end-of-line=lf"]) == 0
    assert file_path.read_bytes() == b"Oi\n"

def test_eol__crlf(tmp_path):
    file_path = tmp_path / "test.md"
    file_path.write_bytes(b"Oi\n")
    assert run([str(file_path), "--end-of-line=crlf"]) == 0
    assert file_path.read_bytes() == b"Oi\r\n"

and these to tests/test_api.py:
def test_eol__lf(tmp_path):
    file_path = tmp_path / "test.md"
    file_path.write_bytes(b"Oi\r\n")
    mdformat.file(str(file_path), options={"end_of_line": "lf"})
    assert file_path.read_bytes() == b"Oi\n"

def test_eol__crlf(tmp_path):
    file_path = tmp_path / "test.md"
    file_path.write_bytes(b"Oi\n")
    mdformat.file(str(file_path), options={"end_of_line": "crlf"})
    assert file_path.read_bytes() == b"Oi\r\n"

that push should have everything accounted for to just do the crlf and lf options. Thank you for the tests if I ever wind up doing a larger project in python I'll have to take a closer look at pytest as it looks like its nice and straight forward for a test system

Thanks this is great! I'll try to have this released later today.


Tweak the DirectInput initialization failure message

This closes #36662.

That's a bit of a workaround as this message is just one symptom of a likely bigger issue with the user's Windows system. But if it's the last one that manages to print before failing the start, I guess it doesn't hurt.

Thanks!

Cherry-picked for 3.2.2.


Have to use .defaults when requiring from js

This does not work on node.js when using commonjs
const JSONHeroPath = require("@jsonhero/path");

Instead you have to do this:
const JSONHeroPath = require("@jsonhero/path").default;

I've changed this and added how to require/import to the Readme


Need AS3 to load HSM keys into non-Common partitions

On devices where AS3 has been extensively used, partitions are also typically a normal way of managing the device.  Currently, there's no ability to specify a key in an AS3 declaration which is not in the Common partition.
The documentation specifies the path be:
"class" : "certificate",
"certificate" : {"bigip" : "/Common/default.crt"},
"key" : {"bigip" : "/Common/default.key"}
But nothing other than "/Common/" is accepted.  The declaration should accept any available partition on the device.

Adding to this, I created a new key in a new partition:
`[admin@f5vm01:Active:Standalone] ~ # ls -lsR /config/filestore/files_d/test-partition-1_d
/config/filestore/files_d/test-partition-1_d:
total 8
4 drwxr-xr-x. 2 root root 4096 Dec 13 18:14 certificate_d
4 drwxr-xr-x. 2 root root 4096 Dec 13 18:13 certificate_key_d
/config/filestore/files_d/test-partition-1_d/certificate_d:
total 4
4 -rw-r--r--. 1 root apache 713 Dec 13 18:14 :test-partition-1:test-1-key-ecdsa_63742_1
/config/filestore/files_d/test-partition-1_d/certificate_key_d:
total 4
4 -rw-r-----. 1 root webservices 241 Dec 13 18:13 :test-partition-1:test-1-key-ecdsa_63739_1
`
So we would need the AS3 to look like:
"class" : "certificate",
"certificate" : {"bigip" : "/test-partition-1/test-1-key-ecdsa"} ,
"key" : { "bigip" : "/test-partition-1/test-1-key-ecdsa" }

Have another case where AS3 should work in conjunction with HSM. Certificates can only being created in /Common, this is currently a manual proces.

For HSM, first things to fix is add HSM support to REST-API then Terraform/Ansible/AS3.
We have automated this by adding the HSM cert directly to the load balancer nodes (In /Common) via SSH, and then using AS3 to use this.
In a multi tenant environment this is not really wanted, because in theory tenants (partitions) are able to use HSM certs from other tenants.
But have a feeling they are not doing much development on BIG-IP REST-API anymore, and focusing on BIG-IP NEXT.


Any idea how do I upgrading flutter in China with VPN?

I live in China I have a MacBook Pro which run the latest Mac OS version and a PC as well which with Ubuntu 20.04 , and I built VPN service like v2ray and Trojan as well on the Google cloud etc for using Google service like Google play and flutter upgrading etc ,everything works fine like logging on google,YouTube,Google play etc besides flutter upgrading, it always stuck in the steps which building the tools after downloaded the package when I tried to execute command 'flutter upgrade',even I have set the socket proxy on Mac OS and Ubuntu as well it doesn't work,any idea how to resolve this problem? thank you so much if you answered my question
Steps to Reproduce

on the terminal I tried to execute the 'flutter upgrade'
afterward it downloaded the package which about 195 M
after it finished downloaded the package it showed building the tools and stuck there

Logs

Logs

我用的蓝灯，可以正常升级

我用的蓝灯，可以正常升级

升级后你们工程的输入框键盘正常吗？ 我这里升级后键盘不弹出了

可以配置镜像的配置中国的镜像不用翻墙

@abcdef123ghi
Your question is better suited for StackOverflow. This repo is for tracking bugs and feature requests.
Please see https://flutter.dev/community for resources.
Closing from here.


See original size when compressing

Is your feature request related to a problem? Please describe.
Seeing the original size of the source image would be nice to compare.
Describe the solution you'd like
Show the original size of the source image probably at the top in smaller text under the converted size (idk maybe you can do better). Maybe also add a % of difference between them (EX: -20% would show in green or +10% would show in red because you wouldnt want it to be bigger)
Describe alternatives you've considered
None

I just realized ive been comparing to the first size i see, which is the size of a recompression instead of the original file size. So for already optimised images that would usually always be bigger than the original and theres nothing telling you that

this is the size, which image would take if you save it right now

Yes but im proposing to see the original size too in a way that makes comparing easy, so that people dont do what i did in my 2nd comment

Ofc, i will investigate for possible solution


[Bug]: go panic when running configure on js/ts project (inside parseTsConfigJSON)

What happened?
When running aspect configure in my org's source tree, the following error results:
bazel configure
Updating BUILD files for javascript
panic: runtime error: slice bounds out of range [:10] with length 0 [recovered]
panic: interface conversion: interface {} is runtime.boundsError, not *ast.item
goroutine 1 [running]:
github.com/msolo/jsonr/ast.(*lexer).yield.func1()
external/com_github_msolo_jsonr/ast/lex.go:72 +0x80
panic({0x101a2df20, 0x14001124120})
GOROOT/src/runtime/panic.go:884 +0x1f4
github.com/msolo/jsonr/ast.lexValue(0x1400127c780)
external/com_github_msolo_jsonr/ast/lex-jsonr.go:77 +0x20c
github.com/msolo/jsonr/ast.lexElement(0x40?)
external/com_github_msolo_jsonr/ast/lex-jsonr.go:52 +0x28
github.com/msolo/jsonr/ast.lexStream(0x1400127c780)
external/com_github_msolo_jsonr/ast/lex-jsonr.go:28 +0x3c
github.com/msolo/jsonr/ast.(*lexer).yield(0x1400127c780)
external/com_github_msolo_jsonr/ast/lex.go:78 +0x144
github.com/msolo/jsonr/ast.(*astParser).next(0x14000f714b0)
external/com_github_msolo_jsonr/ast/ast.go:132 +0xc0
github.com/msolo/jsonr/ast.(*astParser).Parse(0x14000f714b0, {0x0, 0x0})
external/com_github_msolo_jsonr/ast/ast.go:146 +0x130
github.com/msolo/jsonr/ast.Parse(...)
external/com_github_msolo_jsonr/ast/ast.go:117
github.com/msolo/jsonr.Convert2Json({0x0?, 0x1015b1a0c?})
external/com_github_msolo_jsonr/jsonr.go:60 +0x38
github.com/msolo/jsonr.Unmarshal({0x1400011fc00?, 0x100e2b9c8?, 0x100da2f50?}, {0x1018c8280, 0x14001a9c3c0})
external/com_github_msolo_jsonr/jsonr.go:19 +0x38
aspect.build/cli/gazelle/js/typescript.parseTsConfigJSON(0x14000edf6c0?, {0x140006846d8, 0x14}, {0x1400115b660, 0x17}, {0x1400011fc00, 0x0, 0x200})
gazelle/js/typescript/tsconfig.go:68 +0x6c
aspect.build/cli/gazelle/js/typescript.parseTsConfigJSONFile(0x14000680248, {0x140006846d8, 0x14}, {0x1400115b660, 0x17}, {0x1400112410b, 0x12})
gazelle/js/typescript/tsconfig.go:61 +0xd4
aspect.build/cli/gazelle/js/typescript.parseTsConfigJSON(0x14000edf500?, {0x140006846d8, 0x14}, {0x1400115b320, 0x19}, {0x14001041e00, 0x29, 0x200})
gazelle/js/typescript/tsconfig.go:74 +0x114
aspect.build/cli/gazelle/js/typescript.parseTsConfigJSONFile(0x14000680248, {0x140006846d8, 0x14}, {0x1400115b320, 0x19}, {0x10167c69b, 0xd})
gazelle/js/typescript/tsconfig.go:61 +0xd4
aspect.build/cli/gazelle/js/typescript.(*TsWorkspace).AddTsConfigFile(0x14000680240, {0x140006846d8?, 0x10166efe8?}, {0x1400115b320, 0x19}, {0x10167c69b, 0xd})
gazelle/js/typescript/config.go:30 +0x40
aspect.build/cli/gazelle/js.(*TypeScript).readConfigurations(0x140006164b0, 0x140014ebb80, {0x1400115b320, 0x19})
gazelle/js/configure.go:114 +0x1bc
aspect.build/cli/gazelle/js.(*TypeScript).Configure(0x1021ae2f0?, 0x140014ebb80, {0x1400115b320, 0x19}, 0x140005288c0)
gazelle/js/configure.go:79 +0x1ac
github.com/bazelbuild/bazel-gazelle/walk.configure({0x14000616500, 0x5, 0x19?}, 0x140014e3590?, 0x140014eb760?, {0x1400115b320, 0x19}, 0x140005288c0)
external/bazel_gazelle/walk/walk.go:292 +0x2c4
github.com/bazelbuild/bazel-gazelle/walk.Walk.func1(0x140014eb760, {0x140014e3590, 0x2e}, {0x1400115b320, 0x19}, 0x1)
external/bazel_gazelle/walk/walk.go:147 +0x188
github.com/bazelbuild/bazel-gazelle/walk.Walk.func1(0x140014eb4a0, {0x140014e2cf0, 0x2c}, {0x140002fde60, 0x17}, 0x1)
external/bazel_gazelle/walk/walk.go:172 +0x628
github.com/bazelbuild/bazel-gazelle/walk.Walk.func1(0x140013b2210, {0x140014e2ab0, 0x27}, {0x14000565f50, 0x12}, 0x1)
external/bazel_gazelle/walk/walk.go:172 +0x628
github.com/bazelbuild/bazel-gazelle/walk.Walk.func1(0x1400025cb00, {0x14000ab3320, 0x1a}, {0x1400069eef6, 0x5}, 0x1)
external/bazel_gazelle/walk/walk.go:172 +0x628
github.com/bazelbuild/bazel-gazelle/walk.Walk.func1(0x1400025cb00, {0x140006846d8, 0x14}, {0x0, 0x0}, 0x0)
external/bazel_gazelle/walk/walk.go:172 +0x628
github.com/bazelbuild/bazel-gazelle/walk.Walk(0x1400025cb00, {0x14000616500?, 0x5, 0x5}, {0x14000e10790, 0x1, 0x1}, 0x0, 0x14000e32e00)
external/bazel_gazelle/walk/walk.go:182 +0x1d8
aspect.build/cli/pkg/aspect/configure.runFixUpdate({0x1400004407c, 0x14}, {0x14000e33838?, 0x1, 0x20}, 0x1?, {0x1021ae2f0, 0x0, 0x0})
pkg/aspect/configure/fix-update.go:281 +0x8d4
aspect.build/cli/pkg/aspect/configure.(*Configure).Run(0x140003592c0, {0x0?, 0x0?}, 0x0?, {0x1021ae2f0, 0x0, 0x0})
pkg/aspect/configure/configure.go:100 +0x69c
aspect.build/cli/pkg/aspect/root/flags.FlagsInterceptor.func1({0x101aa21f0, 0x14000042068}, 0x14000e16f00, {0x1021ae2f0?, 0x18?, 0x1019b9740?}, 0x14000e10290)
pkg/aspect/root/flags/interceptor.go:106 +0x1b4
aspect.build/cli/pkg/interceptors.Run.func1.1({0x101aa21f0?, 0x14000042068?}, 0x0?, {0x1021ae2f0?, 0x0?, 0x0?})
pkg/interceptors/run.go:45 +0x34
aspect.build/cli/pkg/interceptors.Run.func1(0x14000e16f00, {0x1021ae2f0, 0x0, 0x0})
pkg/interceptors/run.go:48 +0xf4
github.com/spf13/cobra.(*Command).execute(0x14000e16f00, {0x1021ae2f0, 0x0, 0x0})
external/com_github_spf13_cobra/command.go:916 +0x5c4
github.com/spf13/cobra.(*Command).ExecuteC(0x14000018300)
external/com_github_spf13_cobra/command.go:1040 +0x338
github.com/spf13/cobra.(*Command).Execute(...)
external/com_github_spf13_cobra/command.go:968
github.com/spf13/cobra.(*Command).ExecuteContext(0x14000358270?, {0x101aa21f0?, 0x14000042068?})
external/com_github_spf13_cobra/command.go:961 +0x4c
main.command({0x101aa5630, 0x140001c8330}, {{0x101a9afe0, 0x1400000e010}, {0x101a9b040, 0x1400000e018}, {0x101a9b040, 0x1400000e020}})
cmd/aspect/main.go:96 +0x1b8
main.main()
cmd/aspect/main.go:71 +0x2e8
Version
Development (host) and target OS/architectures:
Output of bazel --version:
aspect 5.3.4
w/ bazel 6.2.0
Version of the Aspect rules, or other relevant rules from your
WORKSPACE or MODULE.bazel file:
Language(s) and/or frameworks involved:
JS & TS
How to reproduce
No response
Any other information?
No response

Would you be able to post your tsconfig? Does it have something interesting in it such as comments or odd syntax?

We have about a hundred tsconfigs so it's a little hard to know where to start. No comments or odd syntax, though I'm not sure what would even constitute odd syntax in vanilla JSON.

Is there a verbose or debug mode so I can know which folder or file it is processing right before it blows up?

I think we need better logging within the gazelle extension for to debug this better: https://github.com/aspect-build/aspect-cli/issues/428

@matthewjh can you give this another try? You can set env vars to the log level + file which will hopefully point out which tsconfig file is failing, then maybe you can post that file?
See ASPECT_CLI_LOG_FILE and ASPECT_CLI_LOG_DEBUG.

@matthewjh can you try again after https://github.com/aspect-build/aspect-cli/commit/2e1aef06fc15afec43964d20ee1adb69561a7347?

I think this is fixed, just given the stack trace. Let me know if you can still reproduce it or similar.


Fix typo in deprecation warning

deprectad -> deprecated

Hey @rajivshah3 ,
Nice catch 👍 . We will merge and release your PR.
Thank you for your contribution.


Recruiting additional maintainers for Raku

We're about to start a big push towards version 3 (v3) of Exercism. This is going to be a really exciting step forward for Exercism, with in-browser coding, new Concept Exercises with automated feedback, improved mentoring and much more.
This to be a big community effort, with the work spread out among hundreds of volunteers across Exercism. One key thing is going to be each track having enough maintainers who have the time to manage that community effort. We are therefore putting out a call for new maintainers to bolster our numbers. We're hoping that our existing maintainers will be able to act as mentors to the newer maintainers we add, and take on a parental role in the tracks.
If you are an existing maintainer, could you please reply to this letting us know that you think you'll have time (2-3hrs/week) to help with this over the next 6 months. If you won't have that time, but still want to be a maintainer and just help where you can instead, please tell us that too. If you have come to the end of the road as a maintainer, then we totally understand that and appreciate all your effort, so just let us know.
For anyone new who's interested in becoming a maintainer, thanks for your interest! Being an Exercism maintainer is also a great opportunity to work with some other smart people, learn more about your language of choice, and gain useful skills and experience that are useful for growing your career in the technical leadership direction. Please write a comment below introducing yourself along with your Exercism handle, and telling us why you're interested in becoming a maintainer, and any relevant experience. We will then evaluate every application and contact you using your exercism email address once we have finished the evaluation process.
Thank you!
See also https://github.com/exercism/exercism/issues/5161

@exercism/perl6 @exercism/website-copy-perl6 Anyone?
@kytrinyx should we make changes for the group/team names to Raku ask well? At the moment, they are as above in the first line of this comment.

Good point. Done.

Thank you @iHiD

We're closing this issue as it was part of our push to implement the v3 version of this track and v3 has just been released.
New maintainer are always welcome though!


Simu Hz and other comments

What an impressive job you've done on the programming and documentation, I'm in awe!
I can tell you that ESPSomfy-RTS works with the Simu Hz protocol. I haven't tested it yet because I'm waiting on my CC1101 transceiver but it has been working with my Arduino sketch and Python script (that implement the Somfy RTS protocol) for almost 10 years now, so...
You complain a lot about the range of the Somfy remotes and their use of a PCB antenna, so I thought I'd make you jealous of my OEM remotes that use a coil antenna:

Now with my questions:
4. The Tx power is entirely independent from the Rx sensitivity, correct? I can have ESPSomfy whisper its commands (to not broadcast them on the other side of the town) but still hear every command from the original remotes?
5. "Groups do not have a defined position and cannot be controlled by setting the position. This is because the timings of each member can and will likely be different." <- It would still be interesting to be able to close all blinds of a group to 50% or something. Maybe ESPSomfy offer this option (even though, in the back-end, it would send two frames for each blind)

@Nickduino I am so glad to see you.  When I started looking for solutions I came across your PI Somfy development.  Glad to hear the Simu uses the same protocol.  Let me know if there are any issues.   The range of the Somfy remotes has me thinking that I need to do some experimentation on the transmitter.  It might be fun to play around with increasing the output power.
As for your questions, yes the Tx power is completely separate from the Rx sensitivity.  So you can whisper the commands and tune the Rx to pick up your remotes.  The group functions do work like you expect in HA.  I didn't implement that algorithm in the ESP32 at this point because there have been other priorities on the plate and it can be a bit wonky with integrated tilt mechanisms.

I am so glad to see you. When I started looking for solutions I came across your PI Somfy development.

https://github.com/Nickduino/Somfy_Remote would probably have been a better starting point, it has been forked and ported to ESP8266 and ESP32 many many times.

Let me know if there are any issues.

I will but looking at your doc, I doubt it

I've been using it for 4 months, it's become extremely reliable with the v2.4.2
(And yes I installed the v2.4.3 since)