MicroMasters alumni report

User Story
As an admin in MIT Alumni Association, I need periodic updates of learners who who have completed MicroMasters programs so I can invite them to join the MITAA.
Description/Context
Learners who have earned a MicroMasters program credential are eligible for benefits from the MIT Alumni Association (MITAA). To make these benefits available, we deliver a list of contact & profile data to the MITAA, roughly 4 times per year. (The schedule is timed to work well with course end dates).
The data is sourced from several places:

mitxonline

course certificates for DEDP
program certificates for DEDP
profile: email, first name, last name and country)

edx.org bigquery data:

course certificates for SCM, SDS, POM and FIN programs
profile: email, name, address, country

As far as I know, there is no source of program certificates for SCM, SDS, POM and FIN programs, so we have to calculate them, based on the requirements of each program
micromasters:

augmented profile information: ascii first name, ascii last name, address

The MITAA has requirements for data they can ingest:

separate first and last names
ASCII text only. No unicode
incremental deliveries each time

The most recent report for this is at https://bi.odl.mit.edu/queries/1115 which pulls data from https://docs.google.com/spreadsheets/d/13tIKdblVxdfrdfe_dhIwtbCYWxTEi903-ahLE6DJ8w8/edit#gid=987139461


valgrind: mmap-FIXED(...) failed in UME (load_unixthread1) with error 22 (Invalid argument) errors on macOS

I'll describe the immediate problem first, but see the additional context section as well; I've found a macOS-specific fork/port, so I'm curious if anyone has used Nix-packaged valgrind successfully on macOS (and, if not, if using this fork as the source on Darwin may save some pain)?
Describe the bug
Most of my genuine invocations throw mmap errors. Note that I'm using the nulgrind/none tool to demonstrate that this looks like general valgrind behavior, but I see the same behavior on all ~4 tools I've tried.
$ /nix/store/vaw3azxwfqyr96j8j0x4yswwnywf3c2b-valgrind-3.16.1/bin/valgrind --tool=none /bin/cat
valgrind: mmap-FIXED(0x7fff5f400000, 8388608) failed in UME (load_unixthread1) with error 22 (Invalid argument).

$ /nix/store/vaw3azxwfqyr96j8j0x4yswwnywf3c2b-valgrind-3.16.1/bin/valgrind --tool=none cat
valgrind: mmap-FIXED(0x7fff5f400000, 8388608) failed in UME (load_unixthread1) with error 22 (Invalid argument).

$ /nix/store/vaw3azxwfqyr96j8j0x4yswwnywf3c2b-valgrind-3.16.1/bin/valgrind --tool=none jq
valgrind: mmap-FIXED(0x7fff5f400000, 8388608) failed in UME (load_unixthread1) with error 22 (Invalid argument).

$ /nix/store/vaw3azxwfqyr96j8j0x4yswwnywf3c2b-valgrind-3.16.1/bin/valgrind --tool=none /nix/store/mbahl5am0rx7aqf0z2wg34vvcld7124y-jq-1.6-bin/bin/jq
valgrind: mmap-FIXED(0x7fff5f400000, 8388608) failed in UME (load_unixthread1) with error 22 (Invalid argument).

No clue why the below two run. I've tried a few dozen programs so far and ps is the only one I've found that it runs for (perm error expected, SIP).
$ /nix/store/vaw3azxwfqyr96j8j0x4yswwnywf3c2b-valgrind-3.16.1/bin/valgrind --tool=none ps
==11331==
==11331== Warning: Can't execute setuid/setgid/setcap executable: /bin/ps
==11331== Possible workaround: remove --trace-children=yes, if in effect
==11331==
valgrind: /bin/ps: Permission denied

$ /nix/store/vaw3azxwfqyr96j8j0x4yswwnywf3c2b-valgrind-3.16.1/bin/valgrind --tool=none /bin/ps
==11344==
==11344== Warning: Can't execute setuid/setgid/setcap executable: /bin/ps
==11344== Possible workaround: remove --trace-children=yes, if in effect
==11344==
valgrind: /bin/ps: Permission denied

To Reproduce
Steps to reproduce the behavior:

nix-shell -p valgrind --command "valgrind ls"

Additional context

Basic invocations like valgrind --help and valgrind --version work.
The Homebrew package for valgrind doesn't work on newer macOS versions, but I found an SO answer that mentions the https://github.com/LouisBrunner/valgrind-macos fork/port. I've installed this version via Homebrew following suggestions in that answer and it appears to work (has handled everything I've thrown at it so far.

Notify maintainers
Since I wonder if anyone's successfully used it on macOS, I'm also pinging some people that I've seen in #nix-darwin just in case anyone knows... @cransom @LnL7 @matthewbauer @thefloweringash @emilazy @burke @alyssais @eraserhd @toonn @dhess
Metadata

system: "x86_64-darwin"
host os: Darwin 19.5.0, macOS 10.15.5
multi-user?: no
sandbox: yes
version: nix-env (Nix) 3.0pre20200829_f156513
channels(abathur): "darwin, nixpkgs-21.03pre243895.72b9660dc18"
nixpkgs: /Users/abathur/.nix-defexpr/channels/nixpkgs

I am also having this problem.


provided dependencies not picked up by buck

Hi,
I don't know if this is a buck or okbuck issue, but when I use project lombok or hrisey in my android project, they are only used during compilation. They are typically defined as shown below: -
dependencies {
provided 'pl.mg6.hrisey:hrisey:0.3.+'
}
Unfortunately when dependencies are set as provided, they give a compilation error when running buck install. Could it be a missing configuration during okbuck generation?

Yes OkBuck won't generate BUCK rule dependency for provided configuration, and of course OkBuck could. But I don't understand why provided configuration (compile time dependency) is needed more than apt (annotation processor) usage. Could you please give me more explanation?

Try to get around this by using the apt configuration instead of provided
https://bitbucket.org/hvisser/android-apt

@kageiit OkBuck could recognize provided and apt dependencies, but didn't make them part of module library compile dependencies.
The problem is I don't understand why provided configuration (compile time dependency) is needed more than apt (annotation processor) usage.

@Piasy There are valid cases where you would want to use provided dependencies outside the scope of annotation processing.
An example would be a java library that needs to use Parcelable, but does not want to be tied to be an aar. Another example is Robolectric test framework.
In that case, provided will be used to compile the jar and the parcelable classes are actually provided by the android os.
In the issue pointed out here, hrisey is a library that generates Parcelable classes. Which means the provided android dependency needs to be present for compile, but not be bundled into the final target.

@kageiit Thanks for your reply!
But I don't know whether BUCK support this kind of dependency, I mean, if we put a gradle provided or apt scoped dependency into a android_library or java_library rule's deps list, will BUCK only use it for compile purpose? or BUCK will bundle it into the final target?

You can use the solution preferred by buck authors from here: https://groups.google.com/forum/#!topic/buck-build/pz8NZsAeYdw

will BUCK only use it for compile purpose? or BUCK will bundle it into the final target?

confirmed with buck team that it is only used for compile since dependencies are not exported by default from a target


Feature Storage and Trust package refactoring

Relative in part to Issue 115
Start with the goal to take the test coverage to 90% this PR provides a complete refactoring of packages:

Trust: rewriting the logic behind CombinedTrustEvaluator and the trust handlers
Storage where the methods for updates and insert of entities like trust anchors, trust source and trust attestation. In the process i also done some refactoring to some methods of DBEngine/MongoStorage class.

@Zicchio we should merge this PR to a separate branch created ad hoc and reopen the PR from this latter to dev branch to allow you doing all the closign remarks before the next release


Update to custom tools documentation

Please check if the PR fulfills these requirements

[x] The commit message follows our guidelines
[x] Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

Documentation update. This is related to a recent issue: #878

What is the current behavior? (You can also link to an open issue here)

The "Custom Tools" docs make sense for someone creating a tool to be included within the cornerstoneTools repo.
This mostly comes down to the docs using:
import BaseTool from './../base/BaseTool.js';

What is the new behavior (if this is a feature change)?

Update the code examples to use:
import csTools from 'cornerstone-tools';
const BaseTool = csTools.import('base/BaseTool');

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

No

** Other info**

This also fixes the "Edit on Github" links in the docs

:tada: This PR is included in version 3.6.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

Cound you help me for Custome Tools feature?


add cs3 lessons

fix ENG-750
maybe i shouldn't run the eslint-fix in this file 😂 the important change is at the line 323
without licenses:

with:

NOTE: the json is generated by gpt-4o. but I double checked the link is correct

ya but you know, ai generated json has double quote so I want to use eslint to clean them . so I forget to commit first


Clicking between thumbnails shouldn't close the slide

Clicking between thumbnails shouldn't close the slide when using
wrapper : {
	  onClick : "close"
	}

I think this is an annoying behavior when miss click

Should be fixed in the latest release.


VoiceOver no longer respects scopesRoute and namesRoute in Flutter 1.22

In Flutter 1.19, the behavior with the code below is that VoiceOver would successfully read "Page 1 -> Hello, press the button below to launch the next page".
Selecting and double tapping on "Launch route 2" would result in VoiceOver reading "Page 2 -> Hello, press the button below to close this page".
Going back and forth between page routes would work nicely, and the first element on the page would always be selected and read.
However, in Flutter 1.22, that's no longer the case. The semantics label is random whether it's read, and the first element on the page is also random to whether it gets selected or not.
This breaks our experience for visually impaired uses in our app.

import 'package:flutter/material.dart';
import 'package:flutter/rendering.dart';

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: SemanticsNav1HomePage(),
    );
  }
}

class SemanticsNav1HomePage extends StatelessWidget {

  @override
  Widget build(BuildContext context) {

    SystemChrome.setSystemUIOverlayStyle(SystemUiOverlayStyle.dark);

    return Semantics(
      scopesRoute: true,
      namesRoute: true,
      label: "Page 1",
      explicitChildNodes: true,
      child: Scaffold(
        body: SafeArea(
          top: true,
          child: Column(
            mainAxisAlignment: MainAxisAlignment.start,
            mainAxisSize: MainAxisSize.max,
            crossAxisAlignment: CrossAxisAlignment.stretch,
            children: <Widget>[
              Padding(
                padding: const EdgeInsets.all(24.0),
                child: Text(
                  "Hello, press the button below to launch the next page",
                  style: TextStyle(fontSize: 24),
                ),
              ),
              Expanded(
                child: Center(
                  child: MaterialButton(
                      color: Colors.black,
                      textColor: Colors.white,
                      child: Text("Launch route 2", style: TextStyle(fontSize: 20)),
                      onPressed: () => Navigator.push(context, PageRouteBuilder(pageBuilder: (context, animation, secondaryAnimation) => SemanticsNav2HomePage())),
                  )
                ),
              ),
            ],
          ),
        ),
      ),
    );
  }
}

class SemanticsNav2HomePage extends StatelessWidget {

  @override
  Widget build(BuildContext context) {

    SystemChrome.setSystemUIOverlayStyle(SystemUiOverlayStyle.dark);

    return Semantics(
      scopesRoute: true,
      namesRoute: true,
      label: "Page 2",
      explicitChildNodes: true,
      child: Scaffold(
        body: SafeArea(
          top: true,
          child: Column(
            mainAxisAlignment: MainAxisAlignment.start,
            mainAxisSize: MainAxisSize.max,
            crossAxisAlignment: CrossAxisAlignment.stretch,
            children: <Widget>[
              Padding(
                padding: const EdgeInsets.all(24.0),
                child: Text(
                  "Hello, press the button below to close this page",
                  style: TextStyle(fontSize: 24),
                ),
              ),
              Expanded(
                child: Center(
                    child: MaterialButton(
                      color: Colors.black,
                      textColor: Colors.white,
                      child: Text("Pop route 2", style: TextStyle(fontSize: 20)),
                        onPressed: () => Navigator.pop(context),
                    )
                ),
              ),
            ],
          ),
        ),
      ),
    );
  }
}

Flutter doctor
[✓] Flutter (Channel beta, 1.22.0-12.2.pre, on Mac OS X 10.15.6 19G2021, locale en-US)
• Flutter version 1.22.0-12.2.pre at /Users/danny.valente/Library/flutter/1.22.0-12.2.pre-beta
• Framework revision 2bafdc8 (10 days ago), 2020-09-25 12:48:22 -0700
• Engine revision f763b5b9b9
• Dart version 2.10.0 (build 2.10.0-110.5.beta)
[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
• Android SDK at /Users/danny.valente/Library/Android/sdk
• Platform android-29, build-tools 29.0.2
• Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
• Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)
• All Android licenses accepted.
[✓] Xcode - develop for iOS and macOS (Xcode 11.4.1)
• Xcode at /Applications/Xcode.app/Contents/Developer
• Xcode 11.4.1, Build version 11E503a
• CocoaPods version 1.9.3
[✓] Android Studio (version 4.0)
• Android Studio at /Applications/Android Studio.app/Contents
• Flutter plugin version 47.1.2
• Dart plugin version 193.7361
• Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)

I'm attaching two videos. One with Flutter 1.19 (good) and the other with 1.22 (bad).
vo_issues.zip

@xster Another regression in 1.22 Thanks!

Just for some context, we are using Add2App, and we have a flutter view that can pop at any point to help the user do a particular needed action at a given time, and now when that pops up, the namesRoute label sometimes is read, sometimes it's not read at all. And in all cases, nothing in the flutter view is actually selected by VO.
So this is pretty broken for us when VO is on.

Is this Android and iOS or iOS only?

@gaaclarke could I ask you to take a look at this one?

Is this Android and iOS or iOS only?

iOS only.

Maybe a regression of https://github.com/flutter/engine/pull/19826/files

Yep, I was able to verify that 48a6fde39f9fe8bf7ad06f0f8cf690186d930b73 introduced the regression.
I can reproduce this bug, however the behavior is deterministic for me.  It starts to say the page name then interrupts itself to start describing the next focused item.  On the first page it is the text, on the second page it is the button.

@gaaclarke in our Add2App scenario, it's not as deterministic at all, but might be the result of the same issue you describe. It seems that whatever VoiceOver reads depends on what was selected before the Flutter view launches. Sometimes it will read the status bar, and other times it won't even read the page name or anything else at all, thereby not even letting the user know there's a new view in front of them.

I put a print statement in the engine here:
--- a/shell/platform/darwin/ios/framework/Source/accessibility_bridge.mm
+++ b/shell/platform/darwin/ios/framework/Source/accessibility_bridge.mm
@@ -31,6 +31,7 @@ class DefaultIosDelegate : public AccessibilityBridge::IosDelegate {

   void PostAccessibilityNotification(UIAccessibilityNotifications notification,
                                      id argument) override {
+    NSLog(@"gaaclarke %@", argument);
     UIAccessibilityPostNotification(notification, argument);
   }
 };

With 48a6fde:
2020-10-06 16:54:26.044254-0700 Runner[1149:534279] gaaclarke FlutterSemanticsObject [0x108cad8b0] Page 1 {{0, 0}, {375, 667}}
2020-10-06 16:54:34.775664-0700 Runner[1149:534279] gaaclarke (null)
2020-10-06 16:54:34.804867-0700 Runner[1149:534279] gaaclarke FlutterSemanticsObject [0x108bb55b0] Page 2 {{0, 0}, {375, 667}}
2020-10-06 16:54:44.557695-0700 Runner[1149:534279] gaaclarke FlutterSemanticsObject [0x108b4ab90] Page 1 {{0, 0}, {375, 667}}
2020-10-06 16:54:44.865602-0700 Runner[1149:534279] gaaclarke FlutterSemanticsObject [0x108b4a9a0] Hello, press the button below to launch the next page {{24, 44}, {327, 87}}

Without 48a6fde:
2020-10-06 17:02:45.605097-0700 Runner[1157:537018] gaaclarke Page 1
2020-10-06 17:03:06.935834-0700 Runner[1157:537018] gaaclarke (null)
2020-10-06 17:03:06.968285-0700 Runner[1157:537018] gaaclarke Page 2
2020-10-06 17:03:19.258915-0700 Runner[1157:537018] gaaclarke Page 1
2020-10-06 17:03:19.545795-0700 Runner[1157:537018] gaaclarke FlutterSemanticsObject [0x10a8d8440] Hello, press the button below to launch the next page {{24, 44}, {327, 87}}

I guess that's expected.  It's just surprising that the change of the datatype causes such a different behavior.  @chunhtai how did this PR fix your issue?

The original issue is that it will announce the string and then focus the first item on the screen. If the first item is the namesRoute, it will get pronounce twice.
Changing the data type from string to object will make it focus the object directly.

Reproducible on the latest master 1.23.0-8.0.pre.222.

flutter doctor -v
[✓] Flutter (Channel master, 1.23.0-8.0.pre.222, on Mac OS X 10.15.7 19H2 x86_64, locale en-GB)
    • Flutter version 1.23.0-8.0.pre.222 at /Users/markus/development/flutter_master
    • Framework revision d2858f00dd (3 hours ago), 2020-10-08 09:39:13 +0200
    • Engine revision 2eac514f26
    • Dart version 2.11.0 (build 2.11.0-186.0.dev)

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.1)
    • Android SDK at /Users/markus/Library/Android/sdk
    • Platform android-30, build-tools 30.0.1
    • Java binary at: /Users/markus/Library/Application Support/JetBrains/Toolbox/apps/AndroidStudio/ch-0/193.6626763/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 12.0.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.0.1, Build version 12A7300
    • CocoaPods version 1.9.3

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 4.0)
    • Android Studio at /Users/markus/Library/Application Support/JetBrains/Toolbox/apps/AndroidStudio/ch-0/193.6626763/Android Studio.app/Contents
    • Flutter plugin version 48.1.2
    • Dart plugin version 193.7361
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)

[✓] Connected device (5 available)
    • Nevercode’s iPhone (mobile)         • b668e524315069f3db3661ac11ff1f66afafebdb • ios            • iOS 13.7
    • iPhone SE (2nd generation) (mobile) • B46F1F22-93B0-40C4-8DA7-1C9816E399F7     • ios            • com.apple.CoreSimulator.SimRuntime.iOS-14-0 (simulator)
    • macOS (desktop)                     • macos                                    • darwin-x64     • Mac OS X 10.15.7 19H2 x86_64
    • Web Server (web)                    • web-server                               • web-javascript • Flutter Tools
    • Chrome (web)                        • chrome                                   • web-javascript • Google Chrome 85.0.4183.121

• No issues found!

Okay, I propose we revert https://github.com/flutter/engine/pull/19826.  I looked into the issue that that PR fixed (https://github.com/flutter/flutter/issues/44001) and that just looks like the reported error is working as intended.  When the route changes, it is announced and the first item is selected.  If that first item happens to have the same name as the route then the same words will get said twice, once for the route name, once for the focused item.
We don't have any control over the reading of the focused item, the only thing we could do is not announce the route name which would be erroneous in other cases.  We don't know with certainty what VoiceOver will focus on so we can't preemptively avoid saying the route name if it is the same as the focused item.  I played around with calling UIAccessibilityFocusedElement to do that kind of logic but its asynchronous nature and limitations of the API make it not possible.
If we really want to get rid of the words getting being said twice we should look into removing the route name of the AlertDialog whose first item has the same semantic label as the route name.
Sound good, @chunhtai ?

@gaaclarke yeah, that sounds good to me.

closed via https://github.com/flutter/engine/pull/21714

I see that a new flutter 1.22 stable release was just released 3 days ago, but this bug still does not have the "cp: 1.22 completed" label. When can this be expected to get cherry picked to 1.22?
Thanks!


FetchService - accept headers as a plain object, merge in defaults

Currently FetchService will apply default headers to a request only if no headers at all have been specified by the caller. This can make it a bit more annoying to e.g. add a custom header but then also remember to add in content-type.
https://github.com/exhi/hoist-react/blob/76197105fe34791a9bf6c2f6351bf3958ceb04f2/svc/FetchService.js#L75
An approach more in line with our pattern elsewhere would be to:

Accept incoming headers config as both a plain object and an actual Headers object
If not provided or a plain object, merge in our defaults and then instantiate a Headers object to use.
If provided as a Headers object already, don't touch it - caller is specifying exactly what it wants.

It might be worth thinking about a way for an app to register one or more default headers that would be applied to each request.  Thinking about the particular client use case we've been discussing. We could add app-specific util methods to DRY that up - and maybe that's the best option - but I'm tempted to cleanly support consistent custom headers somehow without that step.
A complication might be - would we be OK with those headers also being included in the calls made back to the Hoist /xh endpoints?
Not looking to over-design or over-complicate this ticket - raising here for discussing next week while we're thinking on it....


.desktop file

It would be good to have a .desktop file for pidif
This would make integration in certain UIs easier

nice idea!


opensuse /proc/cmdline has duplicate entries

On opensuse-leap after installation I get this /proc/cmdline:
BOOT_IMAGE=(loop0)/boot/vmlinuz console=tty1 console=ttyS0 root=LABEL=COS_ACTIVE net.ifnames=1 cos-img/filename=/cOS/active.img rd.emergency=reboot rd.shell=0 panic=5 security=selinux rd.cos.oemlabel=COS_OEM selinux=1 fsck.mode=force fsck.repair=yes systemd.crash_reboot=yes rd.emergency=reboot rd.shell=0 panic=5 systemd.crash_reboot systemd.crash_shell=0

I see duplicated values? (e.g. rd.shell=0, panic=5 etc)
Let's check how this is generated. The bootargs.cfg should now be static so how do we end up with so many entries?

It seems it's a combination of:
https://github.com/kairos-io/kairos/blob/355e12c44d01bae791847347ad7a3514250feaea/images/opensuse/bootargs.cfg#L7
and
https://github.com/kairos-io/packages/blob/9ba45b27a2a03c4c3b27f7b354f5c2b31d41da56/packages/system/cloud-config/oem/08_boot_assessment.yaml#L84
combined here:
https://github.com/kairos-io/packages/blob/9ba45b27a2a03c4c3b27f7b354f5c2b31d41da56/packages/static/grub-config/files/grub.cfg#L68
Maybe this can be cleaned up a bit but at least it doesn't seem to break anything. I'll leave it open to allow people to comment but in my opinion it's not super urgent and can be closed.


__require.resolve is not a function

After executing axe-scan run it seems to perform the tests, but then it just prints this warning and hangs indefinitely.
I've tried node 16 & 18.

@skerit Thank you for your feedback! I'll look into it 👀


convert_UTF8 error

Feature request or bug
If a bug, what did you expect to happen?
If a bug, what happened?
If a bug, list steps to reproduce bugs.
If a bug, did you do these steps?
[] Download and use the lastest stable version
[] See if the issue has already been reported
[] Debug
If a feature request, what do you want to be added or changed?
If a feature request, is this feature already in a pull request?
If a feature request, do you know anyone who can help?
Side notes(Read then del this chunk)
Please use pastebin for var_dumps. Not screenies or paste blobs!
Be descriptive!
Please fill out this entire form!

For someone having the same issues with the utf-8 decode for Subject and Content, you can modify the class to following:
`/**
* convert to utf8 if necessary.
*
* @return true or false
* @param $string utf8 encoded string
*/
protected function convertToUtf8($string, $charset = 'utf-8') {
$newString = '';
$elements = imap_mime_header_decode($string);
    for($i = 0; $i < count($elements); $i++) {
        if($elements[$i]->charset == 'default') {
            $elements[$i]->charset = 'iso-8859-3';
            $elements[$i]->text = quoted_printable_decode($elements[$i]->text);
        }
        $newString .= $this->convertStringEncoding($elements[$i]->text, $elements[$i]->charset, $charset);
    }
    return $newString;
}`

That has fixed the issues for special characters and quoted encoded content.


snippets only working inside erb tags

In a .html.erb file the snippet helper does not show when a keyword is typed
however, when inside erb tags in this file, the helper shows, however it also suffixes the erb tags, doubling up on erb tags. e.g. <%= <%= link_to "Some Page", some_path %> %>

issue happens only on return and not tab

Can't reproduce http://gfycat.com/QuickHatefulComet


Fully port elasticlunr to rust as a wasm module?

My understanding is that elasticlunr-rs provides a way to use rust to build the search index (which is what zola uses this for)
Then zola uses the regular elasticlunr.js for web search, search box here: https://www.getzola.org/themes/
There are two rust(WASM) based searches stork and tinysearch, but it seems elasticlunr is more complete in terms of CJK/stemmers/stopwords.
My experience with WASM is very minimal, but I would think this may reduce the size of the index/search module and because its in WebAssembly I would think it would be more performant than the javascript based elasticlunr, currently my search has zero performance issues, but I am wondering how it would do on a very large site, you can see my current implementation here: https://jieiku.github.io/abridge-demo/ (search for zola and press enter or the search icon)
I could be wrong about some of this as my experience with WASM is minimal, so any information is appreciated.

Adding better language support to either of those searchers should be easier than adding a search implementation to this and porting it to WASM.
I also have minimal experience with WASM, but I would expect that elasticlunr's index design is not good for being sped up by WASM. The index is a series of nested maps. I'd expect map lookup to be highly optimized in JavaScript since it's so fundamental to the language. You could try to create an alternate index format but that's outside the scope of this crate.
I'm not particularly interested in implementing this, nor in supporting someone else's implementation. No harm in asking though!

Thank you for taking the time to write a detailed explanation, I now have a much better understanding of the situation.


Verify typography styles meet accessibility requirements

Font sizes
Font colors have sufficient contrast

Also tagging @amfeldman to this issue since I can't properly assign it to her for some reason

next up for review


Use the til::enumset type for the GridLines enum in the renderers

Summary of the Pull Request
This replaces the GridLines enum in the renderers with a til::enumset type, avoiding the need for the various WI_IsFlagSet macros and flag operators.
References
This is followup to PR #10492 which introduced the enumset class.
PR Checklist

[ ] Closes #xxx
[x] CLA signed.
[ ] Tests added/passed
[ ] Documentation updated.
[ ] Schema updated.
[ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan.

Validation Steps Performed
I've manually confirmed that all the different gridlines are still rendering correctly in both the GDI and DX renderers.

Almost feel like the method test() should have been has(). But this is way clearer to read either way than the previous. I'm good with it.

For the record, I didn't particularly like the test method name either, but those names come straight from the std::bitset class, and I thought it would probably be best to stick with a standard interface that people might already be familiar with, rather than trying to invent something new.


[Original Ally] - Broken Rainbow RGB (Fix in issue)

Bazzite Dev Note:
Fix can be found here: https://github.com/ublue-os/bazzite/issues/1153#issuecomment-2322934767
-----------------------------------------------------------------------------------
Describe the bug
I installed BazziteOS used that for some hours to test my games , after that i reinstalled windows 11 and armory crate every thing seems to work normal beside the RGB Rainbow , the RGB works as solid color or whatever i want also the aura sync works and the modes too. Only that doesnt work is the standard Rainbow RGB if i choos that the rgb is off like no light.
What did you expect to happen?
Normaly isnt first time i used bazziteOS , last time was kind similar but instad rgb are like OFF was red light only until i reinstalled windows and armory crate after that my rgb worked normal as should even the rainbow color. so i expected to work after fresh windows install , but this time it doesnt i feel like something happend with the latest bazzite OS updates.
Output of rpm-ostree status
No response
Hardware
ROG ALLY Z1 Extreme
Extra information or context
No response

Having the same situation.
And there are occurrences that the right stick has RGB light on, and the left stick has light off when a mode has something wrong. There are some new modes on the Armoury Crate now. They all don't work.

This happened to me as well. This is what I did:
In windows/Armory Crate I turned off all LEDs for all situations. At this point the "rainbow" option didn't work at all except through aura sync.
I rebooted into bazzite and rolled back to a previous release (bazzite-rollback-helper rebase 40-20240427)
Booted windows, turned LEDs back on and now everything is back to normal and I can enable the "rainbow" visual.

Im adding Rainbow support to hhd and noticed it was broken, care to expand?

so you say 7 is the image that works and this commit was made on the 8th ey?

Closed for no response

It's a major bug, reopen

It's a major bug, reopen

Commenting here due to most discussion being in discord. I believe the current status is we've fixed this and are looking for a way to restore existing broken RGB, is that correct?

Yes, only Allys that used an image in May are affected. We have found and fixed the bug that we suspected and most of our current testers have working rainbow RGB in Bazzite (called spiral in Handheld Daemon).
Next Handheld Daemon version adds a more indepth initialization which may help with fixing the affected devices as well, but we have not verified this yet.
We are looking for additional testers though so reach out, especially if you are affected.

I also maintain an image here which is based on the 0427 image that is known to fix the issue and is not close to expiring https://github.com/hhd-dev/bazzite-dc

I also maintain an image here which is based on the 0427 image that is known to fix the issue and is not close to expiring https://github.com/hhd-dev/bazzite-dc

Tried rebasing to this image, the spiral rgb worked in bazzite but windows rainbow led still is broke. I then tried disabling led support on hhd and reinstall windows through cloud recovery but this does not fix the rainbow led in windows.

I also maintain an image here which is based on the 0427 image that is known to fix the issue and is not close to expiring https://github.com/hhd-dev/bazzite-dc

Tried this and does not work. Bazzite broke my rainbow rgb too. And it's such bad timing as I am receiving my Ally X in a few days yet I am stuck as I could not re-sell my device due to the broken rgb lights. Pls help!!!

Yes, only Allys that used an image in May are affected. We have found and fixed the bug that we suspected and most of our current testers have working rainbow RGB in Bazzite (called spiral in Handheld Daemon).
Next Handheld Daemon version adds a more indepth initialization which may help with fixing the affected devices as well, but we have not verified this yet.
We are looking for additional testers though so reach out, especially if you are affected.

Before this New BazziteOS came out that broke even more of the rogs , we just did rebase to i think 39-20240406 and that fixed the rgb , now even that doesnt fix it and my controller isnt recognized by bios anymore since i rebased to this https://github.com/hhd-dev/bazzite-dc

Yes, there is a missing initialization command in the current version.
If you guys can run the following command:
curl https://raw.githubusercontent.com/hhd-dev/hhd/master/local_hhd.sh | sh

If the old image fixed this this will as well.

In any case, I am working with an ally right now and I should have a solution to this today.

I pushed a version that fixes the RGB initialization bug that got introduced in the Ally X version.
https://github.com/hhd-dev/hhd/releases/tag/v3.2.2

bazzite-dc is updated with the new Handheld Daemon version that does the proper init. Hopefully it helps.
We also tried booting into one of the bazzite images that had the issue and the rainbow mode worked there and then worked in windows as well.

Will give a Try and will post soon here back. Thank you Antheas for all this extreme efforts u invest into this

That command installs the new version until you reboot, which you're going to get it eventually on CachyOS.
I do not think CachyOS was affected by the bug (yet)

curl https://raw.githubusercontent.com/hhd-dev/hhd/master/local_hhd.sh | sh
rpm-ostree rebase ostree-unverified-registry:ghcr.io/hhd-dev/bazzite-dc:stable
The above two tests did not fix the rainbow

We have had at least 4 people with working spiral mode still show that it is working in the current version. Including one verifying it in windows.
Therefore, the issue does not happen in current images and the question becomes how reset current devices.
Searching online there does not seem to be a way to reset the MCU, so we need to look into how to do that.
The legion go, for example, has at least 2 ways to reset its controllers.

Is it fair to assume all of you guys are both on the latest bios (339) and controller firmware?

if it helps, I have encountered a similar issue with the RGB/Spiral setting, I did not have Bazzite installed, but did have Nobara 40 and I was trying to follow the instructions to install Nvidia drivers and asusctl and supergfxctl per the Asus-linux.org page.  Noticed the went dark at some point, reboot to Windows (on an external drive) and found I still didn't have the rainbow setting come on.  all the other modes work fine.

if it helps, I have encountered a similar issue with the RGB/Spiral setting, I did not have Bazzite installed, but did have Nobara 40 and I was trying to follow the instructions to install Nvidia drivers and asusctl and supergfxctl per the Asus-linux.org page.  Noticed the went dark at some point, reboot to Windows (on an external drive) and found I still didn't have the rainbow setting come on.  all the other modes work fine.
I am also on the latest bios and current firmware

That tracks, we've suspected this is software that we don't write causing this.
Very much appreciate the info, hopefully we find a solution to fix devices already affected by this soon.

I will also note that I am running the latest version of HHD when installing from:
curl -L https://github.com/hhd-dev/hhd/raw/master/install.sh | bash

Is it fair to assume all of you guys are both on the latest bios (339) and controller firmware (V317)?

Yes i am , still didnt worked all the attempts i got here to try

if it helps, I have encountered a similar issue with the RGB/Spiral setting, I did not have Bazzite installed, but did have Nobara 40 and I was trying to follow the instructions to install Nvidia drivers and asusctl and supergfxctl per the Asus-linux.org page. Noticed the went dark at some point, reboot to Windows (on an external drive) and found I still didn't have the rainbow setting come on. all the other modes work fine.
I am also on the latest bios and current firmware

That was allways like this , on windows allways worked all even aura , was months ago same , what we want is the rainbow on windows back

if it helps, I have encountered a similar issue with the RGB/Spiral setting, I did not have Bazzite installed, but did have Nobara 40 and I was trying to follow the instructions to install Nvidia drivers and asusctl and supergfxctl per the Asus-linux.org page. Noticed the went dark at some point, reboot to Windows (on an external drive) and found I still didn't have the rainbow setting come on. all the other modes work fine.
I am also on the latest bios and current firmware

That was allways like this , on windows allways worked all even aura , was months ago same , what we want is the rainbow on windows back

No what I am saying is if I reboot into windows, I RGB works on any mode including Aura, except Rainbow.  The leds remain off.

I installed Bazzite and can confirm that did not fix the issue.

In-between my previous message, we also tried a variety of other fixes that also did not work. The local_hhd uses the latest Handheld Daemon version until reboot, where I tried to include additional LED fixes that seem to not help. Bazzite will include the latest version later today, so you can stop using it now.
We have reached out to Asus for the issue. I will keep the thread up to date as we receive more information.
In any case, I also heard that the Ally had this problem in a worse form in Windows early post launch, where none of the LEDs would work outside Aura mode. So it is a firmware quirk that is easily fixable with a firmware update.
As it is holidays in most of the world and they are working professionals, it might take a while for a fix to trickle down to Windows and Linux. So I would advise some patience.
I will re-iterate that the current versions of Bazzite do not cause this issue. This has been tested on both on the original Ally and Ally X. It is also unclear the previous versions did, as we tried to break the rainbow mode on an Ally by using one of those builds and could not.
In addition, I have personally vetted every single command that gets sent to the MCU through Handheld Daemon, which did not change commands since January and June so it could not have caused this, and it has always logged every single MCU LED command it sends.
I have overseen kernel changes in Bazzite that disable the kernel module asus_hid for the Ally and we deprecated the Ally image one month ago, which contained third party code that could be used to control the Ally not vetted by us.
If any of you are on the Ally image, it is recommended to switch to the Deck image using one of the following (depending on your Desktop Environment):
# KDE (bazzite-ally)
rpm-ostree rebase ostree-unverified-registry:ghcr.io/ublue-os/bazzite-deck:stable
# Gnome (bazzite-ally-gnome)
rpm-ostree rebase ostree-unverified-registry:ghcr.io/ublue-os/bazzite-deck-gnome:stable

We kept the old Ally image due to potential user demand for the changes there. However, we might discontinue it sooner because of this.

If any of you are on the Ally image, it is recommended to switch to the Deck image using one of the following (depending on your Desktop Environment):
# KDE (bazzite-ally)
rpm-ostree rebase ostree-unverified-registry:ghcr.io/ublue-os/bazzite-deck:stable
# Gnome (bazzite-ally-gnome)
rpm-ostree rebase ostree-unverified-registry:ghcr.io/ublue-os/bazzite-deck-gnome:stable

We kept the old Ally image due to potential user demand for the changes there. However, we might discontinue it sooner because of this.

How do we know which image we are on? I just installed it this week, am I good?

Bumping this
installed bazzite somewhere around the end of June, so it’s a June build, no dual boot.
Decided to reinstall windows last week. Rainbow RGB is broken. Before reinstalling, I left the HHD setting to rainbow. Is there any update on the issue?
It’s the same for me, all options except rainbow are working.
Rainbow is also working, but in aura sync mode.

Hi
thanks for the swift reply!
I’m pretty confident it’s the ally image, I downloaded it from the main page and selected ally. It was the only first and only Linux install on the Ally.
I’m running the latest bios and MCU firmware. Not sure if I can provide anything that can be of help to you guys, as my Ally is running windows exclusively now, and I didn’t dual boot in the first place.
If I can do anything from within windows that can help you, let me know
br
Deyan

Hi Deyan, seems like one of the Ally X units will be getting the -ally image treatment sooner than later then
Should be easy to fix after we identify the root cause
Of course, we will make our findings available to Asus and try to provide a windows workaround as well once a solution is found.
I do not think you can help much from Windows though. So we'd appreciate some (more) patience.
Thanks for understanding.

an update for all of you. We have received the following:
https://universal-blue.discourse.group/t/rainbow-rgb-not-working-after-reinstalling-windows/3487/3
If any of you are up for testing the fix that would be great. I am currently archiving the image, so do not worry about it expiring.
I will also analyze the package versions in it and 40-20240427 and delve deeper into this to isolate the solution if it does indeed work.
I was always aware of the reddit post, but I never realized they were talking about rebasing to the ally image.

I would be happy to test.  If we clone to another drive to test, fix the RGB, then go back to the original drive, would that be worth the effort?  Or would RGB just break again?

Yes, -deck is fixed. Please don't use the -ally image on the Ally. We will be removing it soon.
As soon as I diff the images and find out what caused it the latest bazzite will also fix the LEDs so you won't need to rebase

Sorry for the late response. -deck will not break them yes. Do not use -ally.

an update for all of you. We have received the following: https://universal-blue.discourse.group/t/rainbow-rgb-not-working-after-reinstalling-windows/3487/3
If any of you are up for testing the fix that would be great. I am currently archiving the image, so do not worry about it expiring.
I will also analyze the package versions in it and 40-20240427 and delve deeper into this to isolate the solution if it does indeed work.
I was always aware of the reddit post, but I never realized they were talking about rebasing to the ally image.
EDIT: The image is too old, so your installation might break. But your RGB might work again!

i tried this and it did fix my issue

What are the steps to test?  I can also try tonight.

What are the steps to test? I can also try tonight.
installed Fedora Kinoite 40 iso
then rpm-ostree rebase ostree-unverified-registry:ghcr.io/ublue-os/bazzite-ally:39-20240406
and when it came up like the guide said the led was red  and i returned to windows
and it worked

rpm-ostree rebase ostree-unverified-registry:ghcr.io/ublue-os/bazzite-ally:39-20240406  solved the issue in my rog ally.
40-20240427 does not work

an update for all of you. We have received the following: https://universal-blue.discourse.group/t/rainbow-rgb-not-working-after-reinstalling-windows/3487/3
If any of you are up for testing the fix that would be great. I am currently archiving the image, so do not worry about it expiring.
I will also analyze the package versions in it and 40-20240427 and delve deeper into this to isolate the solution if it does indeed work.
I was always aware of the reddit post, but I never realized they were talking about rebasing to the ally image.
EDIT: The image is too old, so your installation might break. But your RGB might work again!

Yes it works , all good now finaly . But in fact this fix is what i allready mentioned weeks and weeks ago , but no one acted to it from bazzite Devs. I told them to fix the Keys problem so we can downgrade back to the 39 20240406 but they didnt react to that. Well now it seems to work the Rebase Rollback on Bazzite.
Now its best experience ever with CachyOS + HHD , and the fixed RGB Spiral Rainbow. All works perfectly :) even the Sleep Functions with the new kernels from cachyos. Thank you all

We did act on it, but you never specified it was the ally image. So we only tested the deck one

hmm, unless I did something wrong or my root issue is something else, this didn't work for me

Mind the fact this is a general Linux issue and not particular to Bazzite.
This means that the only image known to not cause it right now is bazzite-deck
How did you check your issue was solved

I booted back into Windows, opened AC, and switched the leds back to rainbow. But they are still black.
My trigger that broke it was also different. I followed the instructions on ASUS-Linux.org for Fedora workstation.  I was trying to install the Nvidia drivers and asusctl / supgfxctl when I lost RGB.

Guess what the Ally image and the steps you followed have in common :)
Do your LEDs not work at all? If yes, I have a command you can run to fix them.

What? :). Not sure if it matters, but I was running Nobara40 when I ran the commands.
Yeah, all the other modes work in Bazzite and in Windows, only the Spiral/Rainbow is not working in either.

asus-linux stuff
I had a command in case your LEDs did not work at all. We are still trying to figure out what caused the rainbow mode one.
In any case, seems like it is related to the 6 version of asus-linux and asusctl software family. And that running 5.0.10 fixes it. That software seems to be auto-enabling itself when you boot into the ally image. If not, forcing it open might help.
Between 6.0.0 and 5.0.10 there are too many changes for me to be able to pinpoint what caused the issue without a device. With a device, I would be able to sniff the packets. That will happen later this month.
Or sooner, if one of you wants to volunteer.

Yes, rebooting straight into windows or bazzite should work. Rebooting somewhere else inbetween no guarantees.

how would I install that version?
Bazzite-ally 39 has this version. If you want to test in another distro you would have to repackage it by finding the package file and then install it...

Okay and if my "normal" Bazzite 40 install was done after the ally image was pulled, that should be good too?
rpm-ostree status will let me verify which I am running?
I am trying again to rebase from Fedora 40 to Bazzite 39, the LEDs came on red this time as it is booting and completing the install.  Not sure I saw that before.

Okay and if my "normal" Bazzite 40 install was done after the ally image was pulled, that should be good too?

The deck image never had this problem. It does not matter how/when/where you installed, as long as you are in the deck image you will not have this issue.

Wohoo!  Worked on my second attempt!  I have Rainbow/Spiral back.  Thanks!

We notified the asusctl developers of the problem and they're working on a fix now as well. Should have commands and a way to resolve this without rebasing soon.

I'm preparing a cross platform executable that should be able to fix this, if the asusctl developer's suspicion of the cause is correct
It will be available in a few hours and you will be able to run it on Linux and Windows

I'm preparing a cross platform executable that should be able to fix this, if the asusctl developer's suspicion of the cause is correct
It will be available in a few hours and you will be able to run it on Linux and Windows

If a solution is not found, I still will push my modded version. I can almost guarantee it's within the many modifications that was made to the source code of fedora that toys with the RGB lighting. Revert back to that image that had been discussed, build from there. The other shady part is the options within fedora that is modified is options to prevent users from doing as they wish. Such as rebase. Why lock it down so much. It looks rather shady to me. This up on toying with certain things causes freelancers such as the collaborative members to loose all credidation.
Not being crude, it is just the truth. Such things that destroy something such as what people work hard for to buy causes a modded distro to loose all credit and respect. So, my advice instead of waiting months on end when the problem is being told to you, is to fix it.
Again, just basing the true hard facts. And if this new script fails such as the previous I will push my own fix.

Hi,
First of you are right. Waiting for months for a fix is not acceptable. We have put multiple guidelines in place to make sure this does not happen again. This included PURGING the whole software suite that caused it when running on the Ally.
This bug has not been a problem on Bazzite since June, when we deprecated the -ally image for running on the Ally. There are thousands of Ally and Ally X owners with perfectly running RGB currently.  This thread is still open for existing Ally owners that were affected.
All Ally X owners on Bazzite have working RGB
The images with the offending software are still left for the Asus laptop owners that may want to use them. If we get further pushback, we may choose to retire the images completely.

I can almost guarantee it's within the many modifications that was made to the source code of fedora that toys with the RGB lighting.

You are right. We have found and purged the source of the issue. As part of our diagnosing, we also went in and removed RGB code that runs on the Ally and is part of fedora.
We now believe we have isolated the issue and are ready to push a fix for existing units.

Revert back to that image that had been discussed, build from there.

The only reason that image fixes the leds is that it is running a doubly broken version of the software that broke them fixes them. As you understand, this is in no way an acceptable solution.

The initial version of the fix can be found below.
https://github.com/hhd-dev/ally-fix
It has not been verified to work.
Later today the readme will be updated explaining the source of the issue and the fix, and once verified to work, the fix will be packaged for Windows.

Has to be uploaded somewhere before it's tested
Hope that makes sense, we do not live in the same house after all
The command in the fixer has been tested and is known not to cause any issues. What's being tested is the packaging itself working and whether it fixes the issue
Let me share your sentiment though. Due to courier whoes I won't have access to an ally for the next week or so. So you can either wait for one of our contributors to help or help with fixing the issue.
If you do want to help, please open an issue on the fix issue tracker, as this thread is long enough and too many people are notified at this point.

Has to be uploaded somewhere before it's tested
Hope that makes sense, we do not live in the same house after all
The command in the fixer has been tested and is known not to cause any issues. What's being tested is the packaging itself working and whether it fixes the issue
Let me share your sentiment though. Due to courier whoes I won't have access to an ally for the next week or so. So you can either wait for one of our contributors to help or help with fixing the issue.
If you do want to help, please open an issue on the fix issue tracker, as this thread is long enough and too many people are notified at this point.
EDIT: And yes, since you edited your comment, I do treat you as my consumers. Which is why I spent over a month diagnosing an issue I did not cause and providing the fix for it.

Very good. Now we are getting somewhere. Just know in a business world things go bad for investors, developers etc.... when things like this happen.
In turn, if it were me I would host the code on my site not open till proven fixed. Just my own way of thinking. But I am also trying to protect you as well by making you seriously aware of this as you already are. The situations with this, by any distro is serious. That's why Linux is open source. Which is why your distros should be as well. Refer to YouTube link below.
However, as a consumer there is a demand. And why rebase is nulled out is beyond me.
This is a lot that needs to be resolved.
https://youtu.be/AQBSA69MWAg?si=_mg48eF2Ul1y40iR
^^^^^^ What he speaks on is serious. ^^^^^^

Hi, let us move the discussion on the ally-fix issue tracker. You can rant there as much as you want, and people are free to go there with their popcorn 🍿. You may even edit your previous comment to point to the issue as well, to make it easier for them to find.
However if you post another comment here you will be muted.
That being said yes, I will take you up on your offer.

To be 100% clear, this bug is:

In software we don't write that is shipped by default in other distros.
Not damaging to hardware and reversible.
In the progress of being fixed in the software at fault
Has automatically applied fixes in development by the Bazzite team for affected users.
Can be recovered from now by running an older Bazzite build or an older version of asusctl.

There is little more we can do here. Even getting to the point of being able to point the finger at another project took time and debugging to find. I ask that you adhere to our code of conduct at all times in this issue tracker.

Hi, let us move the discussion on the ally-fix issue tracker. You can rant there as much as you want, and people are free to go there with their popcorn 🍿. You may even edit your previous comment to point to the issue as well, to make it easier for them to find.
However if you post another comment here you will be muted.
That being said yes, I will take you up on your offer.

Lol 🤣 y'all are fun. But I don't believe you.

Hi, let us move the discussion on the ally-fix issue tracker. You can rant there as much as you want, and people are free to go there with their popcorn 🍿. You may even edit your previous comment to point to the issue as well, to make it easier for them to find.
However if you post another comment here you will be muted.
That being said yes, I will take you up on your offer.

When should I expect my replacement? I tried it, my Ally doesn't even turn on anymore. It was fully charged before I tested.

Hello Bazzite team and community :D
So, as a fresh person that just found out the existence of the distro and want to try it out, is it safe to assume and the current release version is "safe to download" (on my Ally X)?
P.s. Just 2h ago or so, the website had a warning, but now does not :O
Great job :O

Yes, this issue is only present in builds from a couple months ago when we still used Asusctl to control RGB instead of HHD. If you're not currently affected you can expect to continue to not be affected.

Ran the fix on windows, doesn’t work. Cmd window pops up very briefly and then disappears.

Ran the fix on windows, doesn’t work. Cmd window pops up very briefly and then disappears.

Quick check, did you run that as administrator? It needs permissions to send the command to the RGB controller.

Hi, yes. First time I didn’t run it as admin, second time I tried. Same issue :(

Ran the fix on windows, doesn’t work. Cmd window pops up very briefly and then disappears.

Quick check, did you run that as administrator? It needs permissions to send the command to the RGB controller.

Hi, yes. First time I didn’t run it as admin, second time I tried. Same issue :(

We're looking into it now and will get back to you shortly.

Hi @us3rnam3d1, the .exe file opens on my computer but we know it wouldn't be perfect the first time. There is a good chance a dependency is missing
If you want to help, run the exe using PowerShell or a cmd shell and give us the output
The window is meant to stay open

Hi @us3rnam3d1, the .exe file opens on my computer but we know it wouldn't be perfect the first time. There is a good chance a dependency is missing
If you want to help, run the exe using PowerShell or a cmd shell and give us the output
The window is meant to stay open
You may also opt to run the python file which will definitely work

Lemme give it a shot and I’ll get back to you, thanks

Hi @us3rnam3d1, the .exe file opens on my computer but we know it wouldn't be perfect the first time. There is a good chance a dependency is missing
If you want to help, run the exe using PowerShell or a cmd shell and give us the output
The window is meant to stay open
You may also opt to run the python file which will definitely work

Tried running ally-fix.py from Powershell, nothing happened. Said “press any key to continue” and that was it.
trying to run the exe from powershell just opens a new cmd and it dissappears right after :(

Seems like @HikariKnight bundled the wrong dll then unfortunately and it crashes when it tries to load the file.
I forgot to put a print statement there
We will fix it soon and post an update

It is the only dll from libusb so not sure what else is needed 🤔

I fixed the logging issue. The script will no longer crash and not show anything on windows.
Also, the reason the script said press any key to exit was that libhidapi was not installed. The error was missing so I also added it as well.
However, I still do not know why the .exe did not run. Perhaps it needs a usagepage change. We will only know if we get the error from the exe that can be found below:
https://github.com/hhd-dev/ally-fix/releases/tag/v1.1.0

Hi @us3rnam3d1, the .exe file opens on my computer but we know it wouldn't be perfect the first time. There is a good chance a dependency is missing
If you want to help, run the exe using PowerShell or a cmd shell and give us the output
The window is meant to stay open
You may also opt to run the python file which will definitely work

Tried running ally-fix.py from Powershell, nothing happened. Said “press any key to continue” and that was it.
trying to run the exe from powershell just opens a new cmd and it dissappears right after :(

Another tester confirmed this version is working on Windows:
https://github.com/hhd-dev/ally-fix/releases/tag/v1.2.0
Let us know if you agree and we can mark this as the stable release.

Hi @us3rnam3d1, the .exe file opens on my computer but we know it wouldn't be perfect the first time. There is a good chance a dependency is missing
If you want to help, run the exe using PowerShell or a cmd shell and give us the output
The window is meant to stay open
You may also opt to run the python file which will definitely work

Tried running ally-fix.py from Powershell, nothing happened. Said “press any key to continue” and that was it.
trying to run the exe from powershell just opens a new cmd and it dissappears right after :(

Another tester confirmed this version is working on Windows: https://github.com/hhd-dev/ally-fix/releases/tag/v1.2.0
Let us know if you agree and we can mark this as the stable release.

Hi
it works! I used the exe on windows. Great work, thank you!!!

Hi @us3rnam3d1, the .exe file opens on my computer but we know it wouldn't be perfect the first time. There is a good chance a dependency is missing
If you want to help, run the exe using PowerShell or a cmd shell and give us the output
The window is meant to stay open
You may also opt to run the python file which will definitely work

Tried running ally-fix.py from Powershell, nothing happened. Said “press any key to continue” and that was it.
trying to run the exe from powershell just opens a new cmd and it dissappears right after :(

Another tester confirmed this version is working on Windows: https://github.com/hhd-dev/ally-fix/releases/tag/v1.2.0
Let us know if you agree and we can mark this as the stable release.

Just ran the .exe myself and it worked successfully, my RGB is 100% working like it used to.

Closing as completed ! Issue will remain open for further support w/ this utility and will remain pinned.


Update ChangeLog with 0.6.0 section

fixes #975
Probably It'll be worth adding also details about both 0.5.0 and 0.4.0 versions

Codecov Report

Merging #1403 (8399efb) into master (828364b) will decrease coverage by 9.36%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1403      +/-   ##
==========================================
- Coverage   50.51%   41.14%   -9.37%
==========================================
  Files         145      144       -1
  Lines        7544     9434    +1890
==========================================
+ Hits         3811     3882      +71
- Misses       3066     4920    +1854
+ Partials      667      632      -35

Impacted Files
Coverage Δ

pkg/core/consensus/testing/node.go
0.00% <0.00%> (-93.55%)
:arrow_down:

...ore/consensus/blockgenerator/candidate/testutil.go
0.00% <0.00%> (-90.91%)
:arrow_down:

pkg/core/consensus/testing/utils.go
0.00% <0.00%> (-75.61%)
:arrow_down:

...core/consensus/blockgenerator/candidate/genesis.go
0.00% <0.00%> (-69.24%)
:arrow_down:

...nsensus/blockgenerator/candidate/blockgenerator.go
0.00% <0.00%> (-64.29%)
:arrow_down:

pkg/gql/query/transactions.go
13.43% <0.00%> (-52.55%)
:arrow_down:

pkg/util/nativeutils/eventbus/eventbus.go
57.14% <0.00%> (-42.86%)
:arrow_down:

pkg/rpc/client/session.go
26.19% <0.00%> (-42.39%)
:arrow_down:

pkg/rpc/client/client.go
3.73% <0.00%> (-36.61%)
:arrow_down:

pkg/core/consensus/reduction/aggregator.go
56.25% <0.00%> (-35.06%)
:arrow_down:

... and 166 more

Continue to review full report at Codecov.

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


[NEW ICON] Jotai

Skill Name
Jotai
Why?
Jotai and zustand are emerging as a library of react state management. I think it's useful as much as redux.
Reference Image

+1 for this ~!

Any update?
This is a PNG: https://github.com/pmndrs/jotai/blob/main/img/jotai-mascot.png


sui-rating don't bind ngModel

Hi,
I've got :
Template parse errors:
Can't bind to 'ngModel' since it isn't a known property of 'sui-rating'.

This is not working at all. Tried on [value] or [ngModel].

Do you definitely have @angular/forms imported? Otherwise, could you get this error to occur in a plunkr so I can take a look please?

I don’t use a form. So I need to display only and I can’t use ’[value]’

Right I understand - will get that PR looked at soon and merged to sort this out 😁

Thank you


ERROR:Description = Invalid namespace

Please help.

I've got no clue. Try to compile a debug build via visual studio, it might give more info.

I'll close this as I can't really do much and OP doesn't respond or add anything useful


README rewrite

Hey,
The README is significantly shorter; I updated the files in the /docs folder, and also created several new ones to transfer some of the original README documentation into discrete files. These new files are linked-to from this README.
I still need some guidance on the "architecture and structure" section toward the bottom as I think it's not 100% there yet.

Hi @slavaschmidt, if that's because you're the only person who knows, then sure thing. But as a way to start distributing the effort past "bottleneck of one dedicated person", can you @stuartmclean also read and review to ensure it makes sense? Also I see @s12v has taken a look; another pass would be +1. @gipeshka, by all means you too. If readability and accuracy are our goals, then multiple points of view are a good thing.

@slavaschmidt Hi, do you know when you'll review this?

Hey Lauri,
great work splitting it apart!
Sorry it took me so long to go through it. I haven't deeply check other files in the doc folder as I expect them to be mostly copy-pasted from the previous README, right?
Two remarks still:

The enum part will be implemented completely differently in the next version for couple of technical reasons, this is related to the DEFINITIONS.md
It might make sense to rename swagger-validations.md to SWAGGER_VALIDATIONS.md for consistency

Hell, as I read the new version of the README, my hands are almost itching to develop something in this repo 👍


(typescript) Decorated parameters result in jest-runner erroring

As soon as a test file contains a param decorator like e.g.
class SimpleTestController {
	handlerMethod(@Body() xxx) {
		return;
	}
}

jest-runner will fail.
There already was a issue report some time ago:
https://github.com/firsttris/vscode-jest-runner/issues/225
Unfortunately the issue remains. Console reported the following error:
jest-editor-support parser returned error SyntaxError: Decorators cannot be used to decorate parameters. (18:15)
    at mt._raise (c:\Users\Jannik\.vscode\extensions\firsttris.vscode-jest-runner-0.4.48\node_modules\@babel\parser\lib\index.js:479:22)

In the log paths one can see babel parser is generating this error.
It seems some of the used dependencies try to transpile typescript based on babel.
I think this is whats happening:

https://github.com/firsttris/vscode-jest-runner/blob/master/src/JestRunnerCodeLensProvider.ts#L58
JestRunnerCodeLensProvider parses source files using jest-editor-support.
jest-editor-support transpiles files using babel 7 so it does not fully support typescript syntax

So if jest-editor-support is not going to implement full typescript / tsc support, typescript files should be compiled to ECMAscript before being passed to the babel-based transpiler.

thx for your report.
my understanding is babel 7 parser fully supports typescript syntax. We even migrated from typescript to babel parser in jest-editor-support. for whatever reasons. but decorators are experimental (even in typescript compiler).
jest-editor-support would need to add the corresponding plugin to make decorators work. probably the plugin is missing.
since you already figured out the issue originates in jest-editor-support, we need to create the issue there to get it fixed:
https://github.com/jest-community/jest-editor-support/issues
best regards
Tristan

i think its just a matter of addion the plugin here.
https://github.com/jest-community/jest-editor-support/blob/master/src/parsers/helper.ts#L11
i refactored this from typerscript to bable_parser at some point


Support KaTeX in help page viewer

What problem did you solve?
Closes #1207
In the HTML of R help pages, the katex JS/CSS resource urls are transformed so that they can be properly loaded in the webview:
<link rel="stylesheet" href="/doc/html/katex/katex.css">
<script type="text/javascript" src="/doc/html/katex-config.js"></script>
<script defer="" src="/doc/html/katex/katex.js" onload="processMathHTML();"></script>

these are replaced with
<link rel="stylesheet" href="http://localhost:<port>/doc/html/katex/katex.css">
<script type="text/javascript" src="http://localhost:<port>/doc/html/katex-config.js"></script>
<script defer="" src="http://localhost:<port>/doc/html/katex/katex.js" onload="processMathHTML();"></script>

where http://localhost:<port> is provided by the R help server running in the background.
(If you have)Screenshot

(If you do not have screenshot) How can I check this pull request?
Open a help page and see if the katex formulas are properly rendered.
?dt

Looks like it does not work under remote development

I'll take a closer look at this later.


Expect.equal stops discovery

Expect.equal stops further discovery of tests.
    [<Tests>]
    let equality =
        testList "equality" [
            testCase "equality 1" <| fun () ->
                Expect.equal 42 42 ""
            ]

Place some other tests before and after this in a module. You will see the tests before discovered, the others not.
[8/22/2017 4:13:11 PM Informational] ------ Discover test started ------
[8/22/2017 4:13:11 PM Error] System.ArgumentException: An item with the same key has already been added.
   at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
   at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
   at Mono.Cecil.Cil.MethodDebugInformation.GetSequencePointMapping()
   at SourceLocation.SourceLocationFinder.getFirstOrDefaultSequencePoint(MethodDefinition m)
   at <StartupCode$Expecto-VisualStudio-TestAdapter>.$SourceLocation.candidateSequencePoints@71-2.Invoke(MethodDefinition m)
   at Microsoft.FSharp.Collections.IEnumerator.map@114.DoMoveNext(b& )
   at Microsoft.FSharp.Collections.IEnumerator.MapEnumerator`1.System-Collections-IEnumerator-MoveNext()
   at <StartupCode$Expecto-VisualStudio-TestAdapter>.$SourceLocation.clo@41.GenerateNext(IEnumerable`1& next)
   at Microsoft.FSharp.Core.CompilerServices.GeneratedSequenceBase`1.MoveNextImpl()
   at Microsoft.FSharp.Core.CompilerServices.GeneratedSequenceBase`1.System-Collections-IEnumerator-MoveNext()
   at Microsoft.FSharp.Collections.IEnumerator.map@114.DoMoveNext(b& )
   at Microsoft.FSharp.Collections.IEnumerator.MapEnumerator`1.System-Collections-IEnumerator-MoveNext()
   at Microsoft.FSharp.Core.CompilerServices.RuntimeHelpers.takeOuter@683[T,TResult](ConcatEnumerator`2 x, Unit unitVar0)
   at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
   at System.Linq.OrderedEnumerable`1.<GetEnumerator>d__1.MoveNext()
   at Microsoft.FSharp.Collections.IEnumerator.map@114.DoMoveNext(b& )
   at Microsoft.FSharp.Collections.IEnumerator.MapEnumerator`1.System-Collections-IEnumerator-MoveNext()
   at System.Linq.Enumerable.<TakeIterator>d__24`1.MoveNext()
   at Microsoft.FSharp.Collections.SeqModule.TryFind[T](FSharpFunc`2 predicate, IEnumerable`1 source)
   at Discovery.Discoverer.Microsoft-VisualStudio-TestPlatform-ObjectModel-Adapter-ITestDiscoverer-DiscoverTests(IEnumerable`1 sources, IDiscoveryContext discoveryContext, IMessageLogger logger, ITestCaseDiscoverySink discoverySink)
[8/22/2017 4:13:11 PM Informational] ========== Discover test finished: 48 found (0:00:00.4400538) ==========

latest upgrade of  "Mono.Cecil" to "0.10-beta7" should fix this issue

I can confirm, this fixed the problem in my case. Tested on VS2017 15.4.3.
I also discovered that VS very aggressively caches AppData\Local\Temp\VisualStudioTestExplorerExtensions\Expecto.VisualStudio.TestAdapter.<IP_ADDRESS>
Something to watch out for when testing in this case, since TestAdapter.<IP_ADDRESS> did not look like it changed. I just copied the Mon.Cecil files. It's not enough to delete the cached folder, you need to restart VS as well.
Hope to see a new release of TestAdapter soon.
Out of curiousity, why are these bug fixes incrementing the build number (according to semantic versioning) and not the patch number? I would suggest incrementing the patch number, as I have found these fixes crucial to getting the adapter to work for users. Build number incrementing tends to have the "look" of being less important.
From my perspective this can be closed after a new release. Thanks, as always, for the contribution.

@jackfoxy my mistake it should increment the bug section of an adapter version instead of build section. I updated nuspec and release notes on github.

New version released, I'm closing it.


Add block entities

This PR aims to add block entities.
Fixes #5

I have decided to add all block entities that affect the client's visuals. This is the full list of block entities in vanilla minecraft.
Those ticked off will be implemented, those ticked off but enclosed in parentheses should be implemented but can't currently (for example lectern due to item api)
Feel free to correct me if I missed any

[ ] Furnace
[x] Chest
[x] Trapped Chest
[x] Ender Chest
[ ] Jukebox
[ ] Dispenser
[ ] Dropper
[x] Sign
[x] Mob Spawner
[x] Piston
[x] (Brewing Stand)
[x] Enchanting Table
[ ] End Portal
[ ] Beacon
[ ] Skull
[ ] Daylight Detector
[ ] Hopper
[ ] Comparator
[x] Banner
[ ] Structure Block
[ ] End Gateway
[ ] Command Block
[ ] Shulker Box
[ ] Bed
[ ] Conduit
[ ] Barrel
[ ] Smoker
[ ] Blast Furnace
[x] (Lectern)
[x] Bell
[ ] Jigsaw
[x] (Campfire)
[ ] Beehive
[ ] Sculk Sensor
[ ] Sculk Catalyst
[ ] Sculk Shrieker

Btw you can use valence::prelude::* in the example.

Thanks so much for taking the time to write that all down :)
just making sure: BlockEntityData.kind should be of type BlockEntity instead of BlockEntityKind, right?

BlockEntityData.kind should be of type BlockEntity instead of BlockEntityKind, right?

No, kind would just be a fieldless enum/integer so we don't have to store both the encoded data and the decoded data at the same time.

another thing: Minestom doesn't handle block entities itself. The user can register a BlockHandler (iirc) and then decide what block entity data is sent to the client

If extracting the block entity stuff ends up being too much of a pain we could just throw in the towel and use a Compound as a compromise between read/write performance.

The block entity example is disconnecting the client.

Actually we should only do the map lookup when the old block state was a block entity. Too tired to fix that rn.

The block entity example is disconnecting the client.

Fixed

Currently working on a fix for the manual packet implementation issue.

Yup, so I'm guessing we're gonna wait for that before merging?

Ready for review

As a part of this PR, I would like to see the chest example updated so the chest is no longer invisible when you first join.

that is actually working already as now the set_block_state function also places the corresponding block entity with no data at the same position :smiley:

I think your idea is good, just I think we shouldn't remove the existing set_block_state and set_block_entity functions (if anything remove the block entity placement part from the set_block_state one), but just have the block ones additionally. It wasn't clear from what you said if you wanted to scrap the other one's or do what I just proposed. What do you think?

We could keep the old functions for the rare performance sensitive situations, but I think we should highly discourage their use and point towards set_block/block as the alternative. I also think we should remove set_block_state and set_block_entity functions from Instance and only make set_block available there. And as you said, the block entity placement behavior in set_block_state should be removed.

I would like to see the (set_)block_state and (set_)block_entity functions unified to make things simpler. Here is what set_block could look like.
fn set_block(&mut self, x: usize, y: usize, z: usize, block: impl Into<Block>) -> Block { ... }

Whilst you're thinking about this, I think the current API has a bit of a foot-gun here,

If the position is not within a loaded chunk or otherwise out of bounds, then BlockState::AIR is returned with no effect.

instead it would be better to return a result, rather than effectively returning 0. :smile:

I would like to see the (set_)block_state and (set_)block_entity functions unified to make things simpler. Here is what set_block could look like.
fn set_block(&mut self, x: usize, y: usize, z: usize, block: impl Into<Block>) -> Block { ... }

Whilst you're thinking about this, I think the current API has a bit of a foot-gun here,

If the position is not within a loaded chunk or otherwise out of bounds, then BlockState::AIR is returned with no effect.

instead it would be better to return a result, rather than effectively returning 0. :smile:

Have a look at the PR. It now returns an Option :smile:


Refactor MLTE API

We need to perform a large refactor of the mlte API.
We support the following "organizational element" entities:

namespace
model
version

For these entities, we must support create, read, and delete operations. Updates are not necessary.
We support the following "artifact" entities:

negotiation card
specification
report
value
result
findings

For these entities, we must support read, write, and delete operations.
In addition to these, we may also support a batch API that includes some additional, higher-level operations that enable better performance for certain batch operations. Examples include:

get all versions for a collection of models

This is resolved by #152.


fix grc link

oops on my part.
dug lgtm'd #11 without checking if the links actually worked.

@duglin wut

LGTM


Live

Docs Build status updates of commit 4d1740b:
:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Add Tiago's instructions for JupyterHub on AWS Server to the wiki and/or docs

From the mailing list, this is a link to Tiago's writeup of the steps to JupyterHub on AWS Server https://sites.google.com/site/jupyterhubconfiguration/
@minrk, Will you please take a look and suggest where you think this information should be added or linked to? Thanks.
Thanks Tiago for sharing the link.

I think linking is probably appropriate. The only thing I don't like is that I don't believe that there should be any docs online that demonstrate how to do a public deployment of JupyterHub without SSL.

@minrk Agreed on the SSL. Perhaps we could set up a wiki page that people could submit links for their use cases (and we could state that the links are use at your own risk and we recommend always deploying a public system with SSL). Thoughts?

There's already a wiki associated with this repo, but I haven't figured out a good way to maintain it. I do think wiki-style is attractive for things like capacity planning, deployments, etc., but I don't know a good way to structure or manage it.

I think I have an idea about the wiki which would be to add a links page under the community section of the Sphinx docs to some of the wiki pages. The hard thing with the wiki pages is that they are hard for users to discover. Perhaps adding the titles and links into the Sphinx docs would help.

I agree that discoverability is the hardest part. Links should definitely help.

I'll create a mock up page later today for Sphinx and submit as a WIP PR.

Great, thanks!

I made a few changes to the wiki and now have a running hub. Cheers.

@codles Thank you! 👍


Document SASL authentication support

The docs [1] don't mention that pylibmc now supports SASL auth [2].
I'll try to open a PR for this week :-)
[1] http://sendapatch.se/projects/pylibmc/reference.html
[2] https://github.com/lericson/pylibmc/blob/9ff7b11019d7dddef008008013205718695b58e7/src/pylibmc/client.py#L125

Oh damn, you're probably right. Did you ever get around to looking at this?

Oh damn, you're probably right. Did you ever get around to looking at this?

Sorry for the delay, PR open now :-)


Publish Test Result: JUnit result with multiple test suites not displayed properly

Hi there,
we're encountering problems using the "Publish test results" tasks under following environment:

TFS on-premises: 15.117.27024.0
Private Agent: 2.122.1 running on Windows 7

The test results file (JUnit) contains multiple testsuite elements, which again can contain multiple test cases. The publishing runs without exception. But the "Tests" overview does not group the results by testsuite. Instead it produces a single "parent node", which contains all testcases of all testsuites.
<?xml version="1.0" encoding="utf-8"?> <testsuites xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">    <testsuite name="Testsuite1" tests="2" failures="2" errors="0" time="0" timestamp="2018-07-06T14:27:44.3258474+02:00" id="0">    		<testcase name="Case1" time="0"> 			<failure>Fail1</failure> 		</testcase> 		<testcase name="Case2" time="0"> 			<failure>Fail2</failure> 		</testcase>	 	</testsuite> 	<testsuite name="Testsuite2" tests="2" failures="2" errors="0" time="0" timestamp="2018-07-06T14:27:44.3258474+02:00" id="1"> 		<testcase name="Case1" time="0"> 			<failure>Fail1</failure> 		</testcase> 		<testcase name="Case2" time="0"> 			<failure>Fail2</failure> 		</testcase>	 	</testsuite> </testsuites>

The image shows the single parent named "Unspecified". I would expect two test suites (Testsuite1 and Testsuite2).
Greetings

Hi,
I've found a workaround for this "problem". If I put a single  inside a -tag, it'll work (when grouped by test run). But I have to produce a single file for each testsuite I want to create.
It would help avoiding this workaround (and multiple result files), if I were able to put multiple  inside a -tag.

      Is this going to be supported in the future, or is it on the roadmap?

Yes its on the roadmap but not this quarter. It will be of great help if you can request for this feature @ https://developercommunity.visualstudio.com/content/idea/post.html?space=21 to help us prioritize it.

@divais
I still have the same issue. Test suite names are just ignored, only test cases are shown when publishing the test result. Is there any ETA when this will be available?

But it clearly says in your official documentation that you support test suites (e.g., under Test Results > Outcome):

Failed: if exists /Testsuites/testsuite/testcase/failure

Hi ,
We have considered this feedback and added this to our backlog. We'll take it up in the coming months.
I'll post the updates once its done.
Thanks.

Hi ,
We have considered this feedback and added this to our backlog. We'll take it up in the coming months.
I'll post the updates once its done.
Thanks.

Any update? It's nonsensical that named testcases are supported but named testsuites and/or testsuites are not!

https://github.com/gotestyourself/gotestsum generates JUnit XML files that look like this:
<?xml version="1.0" encoding="UTF-8"?>
<testsuites>
    <testsuite tests="3" failures="0" time="1.910000" name="full/package/name">
        <properties>
            <property name="go.version" value="go1.13.7 linux/amd64"></property>
        </properties>
        <testcase classname="full/package/name" name="TestA" time="0.130000"></testcase>
        <testcase classname="full/package/name" name="TestB" time="0.550000"></testcase>
        <testcase classname="full/package/name" name="TestC" time="1.230000"></testcase>
    </testsuite>
    <testsuite tests="3" failures="0" time="1.850000" name="full/package/othername">
        <properties>
            <property name="go.version" value="go1.13.7 linux/amd64"></property>
        </properties>
        <testcase classname="full/package/othername" name="TestA" time="0.130000"></testcase>
        <testcase classname="full/package/othername" name="TestB" time="0.400000"></testcase>
        <testcase classname="full/package/othername" name="TestC" time="1.320000"></testcase>
    </testsuite>
</testsuites>

full/package/name and full/package/othername do not appear in the visual hierarchy displayed by Azure DevOps Pipelines. Instead it uses a flattened representation that shows only the JUnit XML filename and the name of the test (which can be ambiguous, as in my example).
This seems to contradict the documentation, which says that the "Test file" is taken from the /testsuites/testsuite/testcase/Attributes["classname"].Value element in the JUnit XML: https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/test/publish-test-results?view=azure-devops&tabs=yaml#result-formats-mapping

Is there any update on this issue? I am also facing issue while attaching xunit.xml file

PublishTestResultsV1 outputs properly for me, but not PublishTestResultsV2.

I want this feature working correctly, the name is not useful

Any news, when this is planned?

not stale

Any chance there is an update for this?
Makes it really hard to use the Test Publisher at scale as it collapses all the test results into a single level, meaning general test case names (such as "Content Header should be X") end up duplicated by each test, and you have to dive into the JUnit file to actually find out where the issue occurred.
This can be worked around by ensuring each name is unique, but it proves to be a hassle in larger test files.

kicking this issue down the road like a can
Any updates? How long is your roadmap backlog, since we entered the 4th year of this issue.

kicking this issue down the road like a can
Any updates? How long is your roadmap backlog, since we entered the 4th year of this issue.

Microsoft isn't interested in building features that are complete. They are only interested in building features enough of the way so that they can claim that Azure supports said feature. So this will never get fixed.

@shailesh-sk could you please take a look?

Any update on this?
We have just moved from an on-premise Jenkins to Azure DevOps just to discover that in this shiny new cloud world we cannot even review test results anymore due to said flattened list of undistinguishable test cases.
This is a crucial feature!

This is a critical one for us as well! So please give us some updates!

Very annoying issue.
For now, my workaround includes configuring JUnit to include a more verbose test name.
https://github.com/jest-community/jest-junit#configuration

Environment Variable Name
Reporter Config Name
Description
Default
Possible Injection Values

JEST_JUNIT_TITLE
titleTemplate
Template string for the name attribute of .
"{classname} {title}"
{classname}, {title}, {filepath}, {filename}, {displayName}

I use the following injection: {filepath} / {suitename} / {classname} {title}
"jest-junit": {
    "titleTemplate": "{filepath} / {suitename} / {classname} {title}",
    "outputDirectory": "./coverage",
    "outputName": "junit.xml"
}

Hope this works out for you too, until Azure team finishes these tools.
Regards,

Any update on this?
We are using Azure DevOps Services and all test cases gather in a single test run is not usable when we are reviewing the report.

not stale

Hey, any updates on this?

four years... duh.

Hi , We have considered this feedback and added this to our backlog. We'll take it up in the coming months. I'll post the updates once its done. Thanks.

Yet another person asking for an update on this issue. As said above, this was added to the backlog.

@dnlopes the same comment also said

We'll take it up in the coming months.

That was 3 years ago. So, in this case, people are just starting to question Microsoft's backlog grooming, I guess. 🤷♂

Our team would love if this was worked on or we could find a workaround as well. An update would be great

Any updates? Test results UI looks really inconvenient

Can you please add this? It's very important for a lot of teams!

surprised to find out this isn't supported today.

it's on the backlog since 2019. please be patient 😁

Waiting for this.... too

Any update here?

Is this repo even being maintained?

Is this repo even being maintained?

it's marketing for peopleless computing 😄

Is this repo even being maintained?

Well, releases are coming, but this kind of issues they just don't care...
We can just continue to spam 🗡

Hey I also need this

+1 to see this implemented.
Anyone from Microsoft acutally reading this? More than 5 years than it was requested and the previously mentioned link to the roadmap does not work for me.

found a work around on how to display junit properly using on ADO ...will share it

I was able to get a somewhat tedious work around for this.
For each test suite I created a separate .xml file and had the PublishTestResults@2 task pick up all of those xml files.

Some promised to share a workaround, but I couldn't find anyone, so I wrote one myself.
I'm unsure if I will have to wait until the 6th anniversary of this bug to publish it... (just kidding). Here you are!
It depends on xmlstarlet - a command line XML toolkit
Use your own job.xml - fetching one from the internet as I do here is just an example.
pipeline.yaml:
trigger:
  - '*'

jobs:
- job: fetch_result
  displayName: 'Fetch and Publish Job Result'
  pool: 'Build-Linux'
  workspace:
    clean: outputs

  steps:
  - checkout: self

  - bash: |
      wget -O job.xml https://validation.linaro.org/api/v0.2/jobs/4059960/junit
    workingDirectory: $(Build.BinariesDirectory)
    displayName: Get Job Result from LAVA Instance

  - task: Bash@3
    displayName: 'Split jUnit XML to separate files because of nasty ADO bug'
    inputs:
      filePath: $(Build.SourcesDirectory)/split_junit_testsuites.sh
      arguments: $(Build.BinariesDirectory)/job.xml
      workingDirectory: $(Build.BinariesDirectory)
      noProfile: false

  - task: PublishTestResults@2
    displayName: 'Publish Test Results'
    inputs:
      testResultsFormat: JUnit
      testResultsFiles: '**/test_*.xml'
      searchFolder: $(Build.BinariesDirectory)

split_junit_testsuites.sh:
#!/usr/bin/env bash
#
# This script will split a jUnit XML into files containing only one testsuite.
# This is necessary to work around a many years old bug in Azure DevOps
# See https://github.com/microsoft/azure-pipelines-tasks/issues/7659 for details
#
# License: GPLv2
# Author: stefan-muc (GitHub) in 2024-04

command -v xmlstarlet --version >/dev/null 2>&1 || { echo >&2 "This script requires xmlstarlet in PATH, but couldn't find it. Aborting."; exit 1; }

if [[ $# -ne 1 ]]; then
    echo "Please provide path to jUnit XML as first parameter."
    exit 2
fi

if [[ ! -f "$1" ]]; then
    echo "The file you provided doesn't exist. Aborting."
    exit 3
fi

testsuites=$(xmlstarlet sel -t -v "count(/testsuites/testsuite)" "$1")

if [[ $testsuites -gt 0 ]]; then
    echo "Found $testsuites testsuites"
else
    echo "Couldn't find any testsuite. Exiting."
    exit 3
fi

trap cleanup EXIT
tempdir=$(mktemp -d --tmpdir "ADO-junit-split.XXXXXXXXXX")

if [[ ! -d "$tempdir" ]]; then
    echo "Creating '$tempdir' failed."
    exit 4
fi

tempfile=$tempdir/tempfile.xml
for testsuite in $(seq 1 $testsuites); do
    name=$(xmlstarlet sel -t -m "/testsuites/testsuite[$testsuite]" -v @name "$1")
    echo "Exporting testsuite $testsuite '$name'"

    cp "$1" "$tempfile"
    for i in $(seq $testsuites -1 1); do
        if [[ $i -ne $testsuite ]]; then
            xmlstarlet ed --delete "/testsuites/testsuite[$i]" "$tempfile" > "$tempfile.new"
            mv "$tempfile.new" "$tempfile"
        fi
    done

    mv "$tempfile" "./test_$name.xml"
done

rm "$1" # Delete original file to not export this in a later ADO step

function cleanup()
{
    echo "Cleaning up $tempdir"
    rm -r $tempdir
}

Use at your own risk.

As a workaround I was able to use PublishTestResults@1 to push multiple test Suites

In case you are here in 2024.
If you have a lot xml test results files your testsuites will appear joined on Tests tab in ADO.
The reason is the PublishTestResults@2 will join all xml files together if you have more than 100 (see the line in the source code) .
The workaround is following. Under the hood PublishTestResults@2 is using so called Logging Command. I wasn't able to find this command in the azure documentation but seen it during debug run of the pipeline. So one can replace PublishTestResults@2 with simple Bash@3 task:
- task: Bash@3
  inputs:
    targetType: 'inline'
    script: |
      echo "##vso[results.publish type=jUnit;mergeResults=false;publishRunAttachments=false;resultFiles=${FILES_COMMA_SEPARATED};failTaskOnFailedTests=true;failTaskOnFailureToPublishResults=false;testRunSystem=VSTS - PTR;]"

Here FILES_COMMA_SEPARATED comma separated list of full paths to each file.
E.g. FILES_COMMA_SEPARATED=/home/vsts/work/results/test_example1.xml,/home/vsts/work/results/test_example2.xml,/home/vsts/work/results/test_example3.xml easy to get with find or smph similar.
I know that task PublishTestResults@2 have the parameter mergeTestResults and it defaults to false but if you have more than 100 files it will be switched to true under the hood.

Hi , We have considered this feedback and added this to our backlog. We'll take it up in the coming months. I'll post the updates once its done. Thanks.

Well, this was on 2019. the backlog is very large :)
The clients must be patient!!!


winston is not creating the log file again if file is deleted manually or by other app

var winston = require('winston');
require('winston-daily-rotate-file');
var transport = new winston.transports.DailyRotateFile({
filename: 'logs/debug-%DATE%.log',
datePattern: 'YYYY-MM-DD-HH',
zippedArchive: true,
maxSize: '20m',
maxFiles: '14d'
});
transport.on('rotate', function(oldFilename, newFilename) {
// do something fun
});
var logger = winston.createLogger({
transports: [
transport
]
});
module.exports = logger;
please give e any solution and we want to resolve this fix

+1
how do we get WInston to write again to the log file if the log has been deleted ?


Update to Spago 0.93.14, switch to purescript-overlay

This updates to the latest Spago, which will compile to corefn all the time, and to js only when the backend is not provided.
We also switch from easy-purescript-nix to purescript-overlay for the nix machinery, as it's generally more up to date.
Closes #161

@anttih I had to add a backend to the test-snapshots project (which I fair I think), but it doesn't seem to be running tests anymore, and I'm not familiar enough with how the test framework works to be able to fix it

It looks like the Test machinery is itself compiling the modules, and then comparing them to the snapshots, but I'd prefer that we let the backend hook compile things (so we test that the executable works too) and instead read the files afterwards

@f-f yes, the test suite itself performs the role of the purescm backend by compiling the corefn files. It would be a bigger task to change this, and not sure how straight forward that is.

I'll have a look

@anttih I ported the test setup - the only thing that differs is that we are not checking for runtime failures anymore (the old implementation would look for comments with a @fails annotation), but it looks like that was unused so we can reintroduce it later if we need it


Add answers changed due to 4.16

Description
Add additional answers (changed due to 4.16 docs)

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 95.69%. Comparing base (9ebbaea) to head (5af5804).
Report is 15 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1229      +/-   ##
==========================================
+ Coverage   95.64%   95.69%   +0.05%
==========================================
  Files          56       56
  Lines        2410     2394      -16
==========================================
- Hits         2305     2291      -14
+ Misses        105      103       -2

see 2 files with indirect coverage changes

/lgtm
/approve


map knon ((deprecated) sRGB sRGB Full range)/(RenderIntent::COLORIMETRIC) to default color mode

DisplayDevice: map unknow ((deprecated) sRGB sRGB Full range)/(RenderIntent::COLORIMETRIC) to default color mode" I have a issue like this

@wxk2008,
Can you please provide the details mentioned below:

What is the MediaPipe Solution that you are trying
In which Platform are you trying the solution
Please provide the steps/code that lead you to this error

Thanks!

@wxk2008,
Can you please respond to the above comment? Thanks!

@wxk2008,
Can you please respond to the above comment? Thanks!

Very sorry，thanks all the same，I know the reason！！


Pantalaimon returning Invalid Media IDs tokens

I am trying to use Pantalaimon for using the ement client from Emacs with my encrypted matrix rooms.
For some reason, Whenever I receive an image in a room from someone else, I am unable to open this image.
The link for the image that is given to me in ement is something like this: http://<IP_ADDRESS>:8009/_matrix/media/r0/download/matrix.org/<mediaid> . (Pantalaimon runs at http://<IP_ADDRESS>:8009)
The response from the Pantalaimon daemon is: {"errcode":"M_UNKNOWN","error":"Invalid media id token [b'', b'matrix.org', b'<mediad>']"}
I can confirm that the media id is not incorrect, since http://matrix.org/_matrix/media/r0/download/matrix.org/<mediaid> definitely downloads an encrypted file.
It seems that Pantalaimon is not syncing the file from my matrix.org homeserver.
I am running the default systemd configuration file on Archlinux.

Same issue here. OS: Archlinux

Hey! thanks a lot for fixing this.


link to "specification of the compatibility pack" is dead.

In the Package Contents section, in the sentence "For more information, see the specification of the compatibility pack." the link is dead. I get a 404 from github.
The correct link is https://github.com/dotnet/designs/blob/master/accepted/2018/compat-pack/compat-pack.md

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: faf48b3f-5550-679d-4462-aeca2961b56e
Version Independent ID: 18e36ec0-029d-804c-f500-aa9248af865a
Content: Use the Windows Compatibility Pack to port code to .NET Core - .NET Core
Content Source: docs/core/porting/windows-compat-pack.md
Product: dotnet-core
GitHub Login: @terrajobst
Microsoft Alias: phcart

@rjvdboon Thanks for reporting that!