Bump base image + use environment.yml

Pin to latest dated version of the base image, to bring in new package versions. We should work on establishing an automated cadence for this somehow.
Specifying environment.yml file for conda packages is more standard, and allows users not familiar with Dockerfile syntax to also add & edit packages. Also paves the way for conda-lock in the future.
Remove a couple packages that were upgraded in the base image anyway.

@consideRatio gh-scoped-creds is no longer installed as part of this repo, as it's now present in the base image. As such, I don't think a comment about that is relevant here anymore. The env config is part of the hub configuration, so I think it's ok it's just present in the infrastructure config.
I'll tackle the other items slowly over the course of this week.

With qgis, my goal is to replicate the work from https://github.com/CryoInTheCloud/hub-image here to the extent possible, as a lot of debugging and fine tuning went into that.

@consideRatio after spending some more time stepping back and thinking about it, I've come to conclude that maintaining huge all-in-one images is an antipattern I want to move away from. As such, I've opened https://github.com/2i2c-org/infrastructure/pull/2683 which provides more image choices for JMTE, and hopefully can deprecate this once I figure out how to provide missing functionality in other ways.
I'm going to close this PR now.

https://github.com/2i2c-org/infrastructure/issues/2583 is also related, on doing this systematically.


Adds editable package to pdm devshell

This pr uses a modified version of https://github.com/nix-community/poetry2nix/blob/master/editable.nix to add the local package to the devShell.
This is very unsophisticated so feel free to improve it(Ex. it only looks in ./src for packages).
Note: This uses the $PWD env variable as a reference to the current directory in order to make this work with flakes. This isn't ideal, but since flakes are designed to be fully hermetic, this is impossible to get around as far as I can tell.

Also, the first commit just changes the order pdm and the interpreter package in buildInputs for the shell; this was done because otherwise the python interpreter for pdm would come before the interpreter for the environment.

Thank you @purepani, I think something like this would be a very nice start to improve the python devshell experience in dream2nix! 🎉
* This doesn't handle entrypoints yet, right? I think at least console_script support would be nice to have and to be expected from an editable install in python?

* Coincidentally, I just tried to build something similar - outside of dream2nix for the time being, but somewhat compatible - on PEP 660 and by calling the packages build-backend. It's still missing a few features to be useful, see inline comments: https://github.com/phaer/entangled_snakes/blob/66bef9aad901d9ed7382b07ef88b356983dd6e3d/lib/editable.nix#L33
  But maybe its good enough for inspiration

Thanks,
I'll put this in draft mode while I continue to work on it. I'll take a look at your implementation and also try to make it compliant with PEP660

Hey, thanks for taking a look at this.
I cherry-picked your first commit now via https://github.com/nix-community/dream2nix/pull/917
I think requiring --impure for the dev-shell should be avoided add all costs as it negatively impacts UX.
The good new is, it looks like that can be fixed by moving this logic into the shellHook instead of having it as a separated derivation.
The challenge with the shellHook is to make the python interpreter accept the .pth file. The problem is that by default, it doesn't scan things like PYTHONPATH for .pth files. But there is a workaround described here.
After experimenting with that work around, I come o the conclusion, that something like this should work within the shellHook:

create a hidden directory at the root of the project (something like .dream2nix/pdm/site-packages) and add it to PYTHONPATH
put a sitecustomize.py inside that directory which executes import site; site.addsitedir(".dream2nix/pdm/site-packages'')
since the temp dir is now a site dir, any .pth files inside it will be loaded once the interpreter starts
now generate the editable packages into .dream2nix/pdm/site-packages

Let's do this step by step.
If we can get something working that doesn't require impure eval and achieves that the currently developed package can be imported, I'd be happy to merge it, as this fixes the most pressing issue.
Supporting additional stuff like scripts is also important, but can be done in a second PR.

Thanks for pointing this out. I didn't think it was possible at first until I realized shellHook just has direct access to $PWD, which is the only mechanism that makes this possible. I'll get to work on this

The only thing I'm worried about in this case is the polluting of PYTHONPATH: if another program tries to run that uses the same package that you're developing, wouldn't that potentially cause issues?

The only thing I'm worried about in this case is the polluting of PYTHONPATH: if another program tries to run that uses the same package that you're developing, wouldn't that potentially cause issues?

Potentially yes, but I wouldn't put too much effort into this edge case yet. We can still improve the slution later.

put a sitecustomize.py inside that directory which executes import site; site.addsitedir(".dream2nix/pdm/site-packages'')

I was about to write that this would be somewhat messy because every nixpkgs python env ships its own sitecustomize.py which we would shadow in a naive approach, so we would need to patch it for something like this to work.
But turns out, this changed since I tried something similar about a month ago. sitecustomize.py in nixpkgs has been removed in https://github.com/NixOS/nixpkgs/commit/234bb31f611f43f8b744b305ab82035de637aaca :tada:

@phaer @DavHau This implements the suggestion from @DavHau earlier. The only package it adds at the moment is the one which is defined by the name in pyproject.nix.

Unfortunately the fix in nixpkgs that would get rid of the sitecustomize.py was reverted due to breaking of a bunch of packages.

@purepani Thanks for the notice - I would otherwise have missed https://github.com/NixOS/nixpkgs/pull/302385. Unfortunate that python envs from nixpkgs will be non-conformant again because there the workaround is too entrenched. Will have a look at how to fix this upstream. Maybe we could just remove/vendor the included sitecustomize? :thinking:
Anyways, I had a go at a devshell implementation in https://github.com/nix-community/dream2nix/compare/main...phaer:dream2nix:devshells?expand=1, but just notice that I hadn't posted it here yet (discussed it in the weekly meeting with david).
Two open things I want to add is integration with the pdm submodule (uses the pip one atm) and wrapping of the binaries. Shouldn't be hard, I just lacked time last week after a family incident.

Oh nice! Thanks for the quick notice: I was planning on working on making it PEP660 compliant after I woke up, but it looks like you have finished nearly everything! This'll be a great improvement to the python modules once it's ready!

Closed due to being superceded by https://github.com/nix-community/dream2nix/pull/951


Accessibility: Group of radio buttons doesn't get its title spoken by Narrator

Describe the bug

The label for a group of radio buttons is not spoken by screen readers when tabbing into it. One does not know what question is being asked.
Steps to reproduce the bug

Steps to reproduce the behavior:

Go to 'Radio buttons' under the What's New section.
Turn on Narrator and tab into the groups of color selections for "Background" and "Border".

Expected behavior

Narrator should speak "Background, Green Radio button checked", or "Border, Yellow Radio button checked".
Actual behavior

Narrator only says "Black radio button checked" or "Yellow radio button checked", but not which of the radio buttons is asking what question.
Screenshots

Version Info

[x] App downloaded from Store

If so, which version? (Found on the Settings page of the app.) Version: <IP_ADDRESS>

[ ] App built locally from source

If so, which branch? (WinUI 3 versions are built off the winui3preview branch)

Additional context

Windows 10 version:

[ ] Insider Build (xxxxx)
[x] October 2020 Update (19042)
[ ] May 2020 Update (19041)
[ ] November 2019 Update (18363)
[ ] May 2019 Update (18362)
[ ] October 2018 Update (17763)
[ ] April 2018 Update (17134)
[ ] Fall Creators Update (16299)
[ ] Creators Update (15063)
[ ] Anniversary Update (14393)

Device form factor:

[x] Desktop
[ ] Mobile
[ ] Xbox
[ ] Surface Hub
[ ] IoT

Thank you for filing this issue @MarcoZehe. This however is an issue with the WinUI control not being accessible, see https://github.com/microsoft/microsoft-ui-xaml/issues/3183 for more context.

This is an issue with the control, not with the Gallery - closing this per @chingucoding's note.


Automated cherry pick of #3080: fix

Cherry pick of #3080 on release/2.12.
#3080: fix

Codecov Report

:exclamation: No coverage uploaded for pull request base (release/2.12@16152a2). Click here to learn what that means.
The diff coverage is n/a.

@@              Coverage Diff               @@
##             release/2.12   #3081   +/-   ##
==============================================
  Coverage                ?   7.17%
==============================================
  Files                   ?     478
  Lines                   ?   76803
  Branches                ?       0
==============================================
  Hits                    ?    5507
  Misses                  ?   70832
  Partials                ?     464

Flag
Coverage Δ

#aFlag
7.17% <ø> (?)

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 16152a2...ef95b72. Read the comment docs.


finetuning using both itm & itc using huggingface implementation

Hello
I would like to thank you for providing such a great paper to the community.
I had a few questions

In your paper you mention that for text to image retrieval you train on both ITC(Contrastive Loss) and ITC(Sigmoid Loss). Did you try finetuning on just 1 loss and evaluating for the same? How were the results?
In you huggingface implementation how does one go about training with the strategy you adopted here?

Hello, Thank you for your interests in our work

Here we follow ALBEF to finetune our model with both ITC(Contrastive Loss) and ITC(Sigmoid Loss). I also tried ITC(Contrastive Loss) only and it showed lower performance. (Note: ITC(Contrastive Loss) is quite sensitive to "batch_size".)
You may need to add corresponding loss functions and related code to our huggingface implementation.

Got it thanks for the info. Sure will add loss function and related code to fine-tune on my data.
I had two more follow up questions

Since ITC really is sensitive to batch size, what about just training with ITM does that work well?
Also in one of your sections of paper its mentioned that you finetuned for flickr30k etc on CE/BCE loss. So does that mean ITC using CE loss?

Hello, thanks for your questions.

just training with ITM is a simple and cheap way for image-text retrieval task, but it will get a lower result than ITM+ITC (if you tune well, as we do in BridgeTower). If I remember correctly, ITC < ITM < ITM+ITC. (But I may not tune "ITC only" very well, XD)
for all image-text retrieval tasks, our final result & checkpoints are fine-tuned with ITC(Contrastive Loss) and ITM(Sigmoid Loss).


fix: do not return error in case resource already exists

I believe in this commit, we also remove the tennant getter, should we also include that changes in this PR?


Atom Helper not responding

Looking at activity monitor, I always get a Atom Helper (Not Responding), even if I start atom in safe mode.
I'm on OSX mavericks and atom 0.138.0. I noticed this at least a few versions back too.

I've updated Atom to Ver 0.169.0 but I have same proble.
It is on Mac OS X 10.9.4.
Thanks.

Yeah I still have the same problem. It isn't necessarily affecting performance anymore (previously it seemed to be), but it's still odd to seem them not responding properly.

confirming that I also have it

Same here. Updated to 0.171.0 today and I still see Atom Helpers in Not Responding state.

In my opinion, sending your screenshots again and again does not help to resolve problem.

@muhasturk In my opinion it helps to get attention to this issue that has been open for a long time. (not sending my screenshot of Atom Helper (Not Responding))

I'm not sending my screenshot, but I just came here to bump this issue. This happens all the time.

:+1: OSX 10.9.5 Atom v0.172.0

Atom v0.172.0 @ OSX 10.9.5 still showing the same issue "Atom Helper (Not Responding)"

If you have the same environment as any of the previous posters, please don't add an additional "Me Too" - this bug is almost certainly not sensitive to your particular config.

Yes, a simple "+1" is enough to bump this issue.

Totally agreed, a simple "+1" would be enough to make this long standing and ignored issue to be hopefully fixed.

It hasn't been ignored.  Atom can't really do anything about it since it seems like it's still a Chromium bug.

+1

+1

Please stop "+1"ing. Seriously. Everyone knows. Got it. The text is red and you don't like it, even though it doesn't affect the app in any real way whatsoever. Enhance Your Calm.

If it is any consolation to anyone, Brackets has this same issue on Mac.
adobe/brackets#5794

:+1: , please let us know what are the plans for this issue. Os 10.10.2, and Atom 0.179

seems to be resolved in 0.180

I don't think so. I'm on 0.182 and still seeing it.

+1

what are the plans for this issue

This issue is that the process appears to be not responding in activity monitor, but performance & responsiveness is not actually affected. Furthermore it appears to be a Chromium bug, so the plans are to do nothing until it's fixed upstream. I'm with @paulcbetts, a little frustrated at all the +1 comments because they don't add anything to the issue other than spamming everyone that's subscribed to it already.

An interesting question is why does Chrome not show the problem anymore while Atom still does? (that's the case for me, at least).

@ijuma If that's the case there's hope that it will just take a Chromium update to atom-shell sometime soon.

I'd be happy to +1 the chromium issue if I'd be pointed to it.
Sent from my iPhone

On 24 Feb 2015, at 22:27, batjko<EMAIL_ADDRESS>wrote:
@ijuma If that's the case there's hope that it will just take a Chromium update to atom-shell sometime soon.
—
Reply to this email directly or view it on GitHub.

@batjko Unlikely, this has been fixed since Chrome 39 and atom-shell has been using Chrome 40 for a while. @rpechayr, the Chromium issue is https://code.google.com/p/chromium/issues/detail?id=397642 (it was mentioned in this same thread).

To the people who want to +1 this problem:
Please bump the Chromium issue, the last comment there is "I'm going to call this Fixed now" from November 2014. So if I understood correctly, Chromium project considers this fixed and Atom considers this a Chromium bug.

@ijuma @pre thank you. I've starred the issue on chromium.

This issue seems to be in a deadlock. Atom thinks it's a Chrome issue while Chrome claims to have fixed it. While people on Mac can still reproduce it on both :snail:
:thought_balloon:
I am beginning to think that the whole idea of using of HTML and CSS for rendering a text editor might have been flawed and not carefully fawned upon!

to think that the whole idea of using of HTML and CSS for rendering a
text editor might have been flawed

I don't see how a bug in an implementation could reflect badly on an
overall architecture choice.  If that were true then the iPhone was a
flawed idea.
On Fri, Mar 13, 2015 at 11:43 AM, bassu<EMAIL_ADDRESS>wrote:

This issue seems to be in a deadlock. Atom thinks it's a Chrome issue
while Chrome claims to have fixed it. While people on Mac can still
reproduce it on both [image: :snail:]
[image: :thought_balloon:]
I am beginning to think that the whole idea of using of HTML and CSS for
rendering a text editor might have been flawed and not carefully fawned
upon!
—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/3928#issuecomment-79237334.

I don't see how a bug in an implementation could reflect badly on an overall architecture choice
I was referring to generic overall sluggishness and aggressive resource consumption!

I was referring to generic overall sluggishness and aggressive resource
consumption!

This is what you pay for the wonderful hackability and personalization. No
other architecture could come close.  I am approaching my dream editor.
Incremental improvements over time in Atom and Chromium will solve your
problem with sluggishness (I have no problem except start-up time which is
fixed by leaving it running).  And hardware has a way of catching up with
software.
On Fri, Mar 13, 2015 at 12:00 PM, bassu<EMAIL_ADDRESS>wrote:

I don't see how a bug in an implementation could reflect badly on an
overall architecture choice
I was referring to generic overall sluggishness and aggressive resource
consumption!
—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/3928#issuecomment-79255152.

This isn't really the place to yet again discuss whether web technology is the right thing to use to build an editor. Let's just discuss the "Atom Helper not responding" issue here.
In any case, this appears to be about how it's shown in Activity Monitor and not an actual lockup. That's not to say it's not a bug but it's a less critical one since it doesn't appear to be affecting how the editor runs.

And hardware has a way of catching up with software.

I think you are expecting Moore's Law to give leverage and fix problems caused by the software. It's already slowed down recently.

Let's just discuss the "Atom Helper not responding" issue here.
In any case, this appears to be about how it's shown in Activity Monitor and not an actual lockup

Ok, I'll stop discussing the Atomic lag now. But I disagree that "Not responding" doesn't have an impact on the process. The CPU usage shoots up as soon as the process becomes unresponsive.

@thedaniel Can you lock this thread please? We probably understand everything we need to know about this bug atm.

@paulcbetts :see_no_evil:

This issue appears to have been fixed now that Atom is on Chrome v56.  If you are still experiencing a visual issue where the Atom Helper process shows as "Not Responding" but is in fact responsive, please create a new issue and completely fill out the issue template.  Thanks!


Add getBlockByHash and getTransactionByHash

Changes proposed in this pull request:

Add getBlockByHash
Add getTransactionByHash
Add more parameters to transaction receipt

@gnosis/mobile-devs

Codecov Report

Merging #21 into master will increase coverage by 0.46%.
The diff coverage is 69.71%.

@@             Coverage Diff              @@
##             master      #21      +/-   ##
============================================
+ Coverage     66.06%   66.52%   +0.46%
- Complexity      142      146       +4
============================================
  Files            46       48       +2
  Lines          1055     1192     +137
  Branches        182      184       +2
============================================
+ Hits            697      793      +96
- Misses          270      311      +41
  Partials         88       88

Impacted Files
Coverage Δ
Complexity Δ

...ava/pm/gnosis/ethereum/rpc/EthereumRpcConnector.kt
0% <ø> (ø)
0 <0> (ø)
:arrow_down:

.../java/pm/gnosis/ethereum/models/TransactionData.kt
0% <0%> (ø)
0 <0> (?)

...in/java/pm/gnosis/ethereum/models/EthereumBlock.kt
0% <0%> (ø)
0 <0> (?)

...main/java/pm/gnosis/ethereum/EthereumRepository.kt
65.38% <0%> (-2.62%)
0 <0> (ø)

...va/pm/gnosis/ethereum/models/TransactionReceipt.kt
0% <0%> (ø)
0 <0> (ø)
:arrow_down:

...ereum/rpc/retrofit/RetrofitEthereumRpcConnector.kt
100% <100%> (ø)
6 <2> (+2)
:arrow_up:

...va/pm/gnosis/ethereum/rpc/RpcEthereumRepository.kt
97.08% <100%> (+3.2%)
9 <2> (+2)
:arrow_up:

...ava/pm/gnosis/ethereum/rpc/models/JsonRpcResult.kt
78.37% <85.71%> (+11.71%)
4 <0> (ø)
:arrow_down:

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 cc7ebdb...9c3114d. Read the comment docs.


fix: Move tests to unit

Thanks for submitting a PR! Please check the boxes below:

[x] I have run pre-commit to check linting
[x] I have filled in the "Changes" section below?
[x] I have filled in the "How did you test this code" section below?
[x] I have used a Conventional Commit title for this Pull Request

Changes
Moved and refactored tests in the app, app_analytics, and audit directories to the unit test directory. Note that @matthewelwell asked that I don't refactor tests as I move them since it complicates merges, so this is an exception.
How did you test this code?
Ran the tests locally after refactoring and moving.

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

Comparison is base (6976f81) 95.57% compared to head (b5d7dc7) 95.57%.
Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2987      +/-   ##
==========================================
- Coverage   95.57%   95.57%   -0.01%
==========================================
  Files        1015     1015
  Lines       29481    29480       -1
==========================================
- Hits        28176    28175       -1
  Misses       1305     1305

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Record decisions for update to the repository structure ahead of v5

Prompted by https://github.com/alphagov/govuk-frontend/pull/3491 and https://github.com/alphagov/govuk-frontend/pull/3498, we've had discussions to clarify which updates to our repository organisation were necessary ahead of v5. This PR adds the recording of the decisions we came to.

I think that last commit adressed all the remarks (besides the one about the heading within Alternatives considered, not quite sure what to do to clarify. I think the issue is with this decision containing multiple smaller decisions rather than be a unique one).

As discussed in dev catch up, the repo structure has diverged a little from what was in our initial decision record, so this needs updating with the latest changes.

Looks good to go for me (but I can't approve as I'm the creator of the PR) 😊


How to autoscroll a listview with drag from another listview when using Draggables

Steps to Reproduce

Execute flutter run on the code sample
Drag an item from a listView within that listView to bottom. The Scrolling responds.  Now try dragging an item from one list to another.
The items separate out correctly but when the drag reaches the bottom the listview doesn't scroll
Couple of observations here:-
The listener probably needs an onTapDown before it can detect anything so that might be one reason things are not working.
In the print statements only the original listview details are printed not the target listview which somehow seems like the source listview is the only active one but not the rest.
Using GlobalKeys in the listviews hasn't made any difference as far as I could tell.
I am probably missing something here but can't figure out what.

Expected results:
When an item is dragged out to another listview's top or bottom the target Listview should scroll.
Actual results:
The scrolling only works if the drag is within the same listview and not another one.

Code sample

import 'dart:ui';

import 'package:flutter/material.dart';

import 'drag_drop_item.dart';
import 'drag_scrollable_list.dart';
import 'draggable_list.dart';

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

class MyCustomScrollBehavior extends MaterialScrollBehavior {
  @override
  Set<PointerDeviceKind> get dragDevices => {
        PointerDeviceKind.touch,
        PointerDeviceKind.mouse,
        // etc.
      };
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      scrollBehavior: MyCustomScrollBehavior(),
      title: 'Flutter Demo',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: const MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({super.key, required this.title});

  final String title;

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: ListView.builder(
        itemCount: 5,
        scrollDirection: Axis.horizontal,
        itemBuilder: (BuildContext context, int index) {
          return DragDropItem(
            value: List.generate(30, (index) => 'Item $index'),
            vertical: false,
            child: SizedBox(
              width: 300.0,
              child: DragScrollableList(),
            ),
            // child: const DraggableList(
            //   maxHeight: 2500.0,
            //   maxWidth: 350.0,
            // ),
          );
        },
      ),
    );
  }
}

// ignore_for_file: must_be_immutable

import 'package:draggable_listview/drag_drop_item.dart';
import 'package:flutter/material.dart';
import 'package:gesture_x_detector/gesture_x_detector.dart';

class DragScrollableList extends StatelessWidget {
  final ScrollController _controller = ScrollController();
  bool _isDragging = false;

  DragScrollableList({super.key});

  @override
  Widget build(BuildContext context) {
    return Listener(
      onPointerMove: (event) {
        if (!_isDragging) {
          print('Is not Dragging');
          return;
        }
        print('Is Dragging');
        var renderObject = context.findRenderObject() as RenderBox;

        var size = renderObject.size;
        var renderOffset = renderObject.localToGlobal(Offset.zero);
        var dragOffset = event.position;

        if (dragOffset.dx > renderOffset.dx &&
            dragOffset.dx < renderOffset.dx + size.width &&
            dragOffset.dy > renderOffset.dy &&
            dragOffset.dy < renderOffset.dy + size.height) {
          _controller.animateTo(dragOffset.dy + 100,
              duration: const Duration(milliseconds: 200), curve: Curves.ease);
        }

        print('ListView Size: $size');
        print('ListView Offset: $renderOffset');
        print('Drag Offset: $dragOffset');
      },
      child: ListView.builder(
        controller: _controller,
        itemCount: 30,
        itemBuilder: (context, index) => DragDropItem(
          onDragEnded: () => _isDragging = false,
          onDragStarted: () => _isDragging = true,
          value: 'Item $index',
          child: ListTile(
            title: Text('Item $index'),
          ),
        ),
      ),
    );
  }
}

import 'package:flutter/material.dart';

class DragDropItem<T extends Object> extends StatelessWidget {
  final Widget _child;
  final T _value;
  final bool _vertical;

  final VoidCallback? _onDragStarted;
  final VoidCallback? _onDragEnded;

  const DragDropItem({
    super.key,
    required Widget child,
    required T value,
    bool vertical = true,
    VoidCallback? onDragStarted,
    VoidCallback? onDragEnded,
  })  : _onDragEnded = onDragEnded,
        _onDragStarted = onDragStarted,
        _vertical = vertical,
        _child = child,
        _value = value;

  @override
  Widget build(BuildContext context) {
    Widget draggable = LayoutBuilder(
      builder: (context, constraints) {
        return LongPressDraggable<T>(
          data: _value,
          maxSimultaneousDrags: 1,
          childWhenDragging: Opacity(
            opacity: 0.5,
            child: _child,
          ),
          feedback: Material(
            elevation: 4.0,
            child: ConstrainedBox(
              constraints: constraints,
              child: _child,
            ),
          ),
          onDragCompleted: () => _dragEnded(),
          onDragEnd: (details) => _dragEnded(),
          onDragStarted: () => _dragStarted(),
          // onDragUpdate: _onDragUpdate,
          onDraggableCanceled: (velocity, offset) => _dragEnded(),
          child: _child,
        );
      },
    );
    return DragTarget<T>(
      builder: (
        BuildContext context,
        List<T?> candidateData,
        List<dynamic> rejectedData,
      ) {
        if (_vertical) {
          return Column(
            children: _buildChildren(
              context,
              candidateData,
              rejectedData,
              draggable,
            ),
          );
        } else {
          return Row(
            children: _buildChildren(
              context,
              candidateData,
              rejectedData,
              draggable,
            ),
          );
        }
      },
      onAccept: (data) => _dragEnded(),
      // onAcceptWithDetails: _onAcceptWithDetails,
      // onLeave: (data) => _dragEnded(),
      // onMove: _onMove,
      onWillAccept: (data) {
        if (data != null && _value != data) {
          return true;
        }
        return false;
      },
    );
  }

  void _dragEnded() {
    if (_onDragEnded == null) {
      return;
    }
    _onDragEnded!();
  }

  void _dragStarted() {
    if (_onDragStarted == null) {
      return;
    }
    _onDragStarted!();
  }

  List<Widget> _buildChildren(
    BuildContext context,
    List<T?> candidateData,
    List<dynamic> rejectedData,
    Widget draggable,
  ) {
    return <Widget>[
      AnimatedSize(
        duration: const Duration(milliseconds: 100),
        child: candidateData.isEmpty
            ? Container()
            : Opacity(
                opacity: 0.0,
                child: _child,
              ),
      ),
      candidateData.isEmpty ? draggable : _child
    ];
  }
}

Logs

Hello @quasar-pankaj. Could you share a video / screen recording of the behavior you mentioned? I am not sure I understand what the issue here is

Hello @exaby73 ,
Thanks for the response. I am trying to build a ListView that goes 3 levels deep. I tried BoardView and DragAndDropLists but they don't fulfill my needs as they go only 2 levels deep.
I have included the .mkv video in the zip file.
To explain let us name two listviews source and target. In the source you will see that the ListView is automatically scrolling when I drag within it. But when I take it to another ListView the scrollong doesn't work. Although the animation to separate the items works perfectly fine.
simplescreenrecorder-2023-04-04_14.39.41.zip

Have you tried using a CustomScrollView instead?

No. But I have tried GestureDetector and also GlobalKeys but that did not change the result. The main problem that I see here is that only the context of the ListView that I am dragging from is ever active because that's what gets printed in the print statements. But I'll try CustomScrollView.

Hello @exaby73 ,
I have been reading up on CustomScrollView and Slivers but I still do not see how it helps. Can you clarify?

Ahh I think I miss understood your issue. My bad, I'm sorry about that. If I understand it correctly now, when dragging during a drag and drop, dragging over the edge of a scroll view should scroll it. Is this what you mean?

Exactly!

Thanks for the clarification. I can reproduce this issue. I'll label it for further insights from the team

The EdgeDraggingAutoScroller might be helpful here.

I'll give it a try. Thanks.

Hi @Piinks,
The EdgeDraggingAutoScroller class seems useful but I have a problem here. How do I get ScrollableState? The State object of a ListView is not exposed so not sure how to use it.
Thanks Again.

This is probably a good question for stackoverflow, where other folks can benefit from the answer as well. Unfortunately we cannot provide support debugging apps on github.
The reason you are not retrieving the ScrollableState in the above sample is because that context is not below the Scrollable, it is above it. If you were to use the context from ListView.builder, that would return the state you are looking for.
Further, have you tried ReorderableListView or ReorderableList?

Actually I had asked this question on StackOverflow sometime ago here, but apparently no one noticed it.  So I came here but I can understand.
I have been going through the code of ReorederableList and ReorderableListView to get a better understanding of it but it seems I am missing some vital concepts because I found it difficult to understand. If you can direct me to appropriate places where I may update myself accordingly that would be nice.
About ReorderableListView or ReorderableList. Can I drag from one ListView to anothet using those? Actually I need to implement a ListView that is nested for upto three levels.
Thanks again.

Can you point me to any tutorials on EdgeDraggingAutoScroller and any other related topic because I have not been able to find any on the net.

I do not know of any that exist. It is used in SliverReorderableListState and _ScrollableSelectionContainerDelegate if you would like to look at those. I will update this issue to reflect a need for more documentation  on EdgeDraggingAutoScroller

I am going through the source codes of ReorderableList and ReorderableListView can't say I understand much but I will as well look at SliverReorderableListState and _ScrollableSelectionContainerDelegate while I am at it. But yes documentation is very much needed.
Thanks anyway.


script/dts: Generate Extended Device Tree database

This PR is subset of #6762 (Codegen introduction, proposed by @b0661), focused on edts database generation.
Extended Device Tree database is a json file generated by extract_dts_includes.py script, from board device tree (dts) collated with yaml bindings.
Since it is post processed from dtc, information is displayed in an easily accessible 'dict' format:
 _edts dict(
   'devices':  dict(device-id :  device-struct),
   'compatibles':  dict(compatible : sorted list(device-id)),
   'device-types': dict(device-types : sorted list(compatible)),
   ...
 )

 device-struct dict(
   'device-id' : device-id,
   'compatible' : list(compatible) or compatible,
   'label' : label,
   property-name : property-value ...
 )

 device-id: opaque id for a device (do not use for other purposes),
 compatible: any of ['st,stm32-spi-fifo', ...] - 'compatible' from <binding>.yaml
 label: any of ['UART_0', 'SPI_11', ...] - label directive from DTS
 device-type: any of zephyr generic type: usb, spi, i2c, ...

Edit 09/11: Added device-type injection

Codecov Report

Merging #9876 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #9876   +/-   ##
=======================================
  Coverage   52.28%   52.28%
=======================================
  Files         213      213
  Lines       25964    25964
  Branches     5598     5598
=======================================
  Hits        13576    13576
  Misses      10150    10150
  Partials     2238     2238

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 38a7950...24d8a5e. Read the comment docs.

Can you update scripts/dts/edtsdatabase.py to do something similar to scripts/dts/devicetree.py w/regards to main, and being able to run it and have it print out the database.

Can you update scripts/dts/edtsdatabase.py to do something similar to scripts/dts/devicetree.py w/regards to main, and being able to run it and have it print out the database.

You have to run extract_dts_includes.py (not edtsdatabase.py). The "print out" will be the json file.

@galak

Can you update scripts/dts/edtsdatabase.py to do something similar to scripts/dts/devicetree.py w/regards to main,

For now edtsdatabase.py is just a class, whole parsing/analyzing/extracting process is run by extract_dts_includes that has a main.
Instantiating edtsdatabase.py as a stand-alone runnable script would require to run extract_dts_includes.py beforehand and pass information from one to the other.
What is the goal behind your query? If point is to only generate edts.json w/o defines we can work out that by passing arguments to extract_dts_includes.py.

For now edtsdatabase.py is just a class, whole parsing/analyzing/extracting process is run by extract_dts_includes that has a main.
Instantiating edtsdatabase.py as a stand-alone runnable script would require to run extract_dts_includes.py beforehand and pass information from one to the other.
What is the goal behind your query? If point is to only generate edts.json w/o defines we can work out that by passing arguments to extract_dts_includes.py.

The input would be the edts.json file, I just wanted it to dump the data structure view of the edts.

Some general comments/questions:

Should we keep the "devices" as a tree, instead of flattened?
Should we keep around status = "disabled" nodes [I think we should, and have status in the tree]
We should have a top level 'aliases' & 'chosen' in EDTS as well.

@galak

The input would be the edts.json file, I just wanted it to dump the data structure view of the edts.

The json file IS "the data structure view of  the edts". EDTS is a python dictionary that is written to the json file. There is no more data in EDTS, just the dictionary.
See the save function in edtsdatabase.py.

Some general comments/questions:

Should we keep the "devices" as a tree, instead of flattened?

Export of a flattened database (basically a key, value list) to json does not provide any structure. Makes the json file unusable for reading. Without structure all operations must become classical select operations with some selection criteria. This is not very Pythonic and would require a more complex database engine. I´m in favour of the tree as it vastly increases readability, it is easy to understand and use, and the flattening is already implemented for cases where the flattended data is needed.

Should we keep around status = "disabled" nodes [I think we should, and have status in the tree]

What benefit would that bring? Info from inactive nodes is not needed by device drivers.

We should have a top level 'aliases' & 'chosen' in EDTS as well.

I´m not shure about  'aliases'. 'chosen' may be better feeded to Kconfig as it represents a user choice not a device characteristic.

We should have top level "views" for GPIOs, IRQs, and clocks

No. This data can easily be generated during the device driver code generation. It is also only of interest to a specific driver. Adding all this info would move the data generation part to the extraction part. It would make extraction dependend on the usage by the drivers and would add a lot of complexity to extraction.
EDTS database is device tree info plus some info from bindings. More complex logical combinations of data shall be done by the driver (aka during code generation). There are already means to do just that (modules and templates in codegen).

The json file IS "the data structure view of the edts". EDTS is a python dictionary that is written to the json file. There is no more data in EDTS, just the dictionary.
See the save function in edtsdatabase.py.

Part of my reason, is this gives an example of how to load and setup EDTS code in python.  Its trivial, but useful.

Some general comments/questions:

Should we keep the "devices" as a tree, instead of flattened?

Export of a flattened database (basically a key, value list) to json does not provide any structure. Makes the json file unusable for reading. Without structure all operations must become classical select operations with some selection criteria. This is not very Pythonic and would require a more complex database engine. I´m in favour of the tree as it vastly increases readability, it is easy to understand and use, and the flattening is already implemented for cases where the flattended data is needed.

I'm not sure I follow?  Aren't we flattening the devices down to key/value pairs?  The key being "device-id"?   The tree structure I was suggesting to keep is so we could possible remove things like 'parent-device'.
For example, we have the following today:
{
    "devices": {
        "/soc/interrupt-controller@e000e100": {

Why not have this be something like:
{
    "devices": {
              "soc": {
                    "interrupt-controller@e000e100": {

Should we keep around status = "disabled" nodes [I think we should, and have status in the tree]

What benefit would that bring? Info from inactive nodes is not needed by device drivers.

EDTS should be useful beyond device drivers and codegen.  We might use it for validating checking, or building a cfg tool for DTS to the user.

We should have a top level 'aliases' & 'chosen' in EDTS as well.

I´m not shure about 'aliases'. 'chosen' may be better feeded to Kconfig as it represents a user choice not a device characteristic.

Again, don't think of EDTS limited to just codegen & zephyr.  EDTS should contain enough info for one to use it to replace the part of extract_dts_includes.py that generates the generated_dts_board.*.  So we need aliases and chosen info.

We should have top level "views" for GPIOs, IRQs, and clocks

No. This data can easily be generated during the device driver code generation. It is also only of interest to a specific driver. Adding all this info would move the data generation part to the extraction part. It would make extraction dependend on the usage by the drivers and would add a lot of complexity to extraction.

Again, you are thinking of this from a single driver or device perspective.  For example, having such views is part of how DT works and is useful.  For example, its becomes much easier to find the MAX_IRQ # for an given interrupt controller this way.

EDTS database is device tree info plus some info from bindings. More complex logical combinations of data shall be done by the driver (aka during code generation). There are already means to do just that (modules and templates in codegen).

I think it should be more useful, to allow various tools beyond just codegen to be built on top of it.

EDTS should be useful beyond device drivers and codegen. We might use it for validating checking, or building a cfg tool for DTS to the user.

I'm happy that the simple EDTS database class I wrote might help for a lot of use cases.

Again, you are thinking of this from a single driver or device perspective.

Yes, I do. I wrote the EDTS database class for a use case: "Provide device tree info for compile time driver data instantiation".

I think it should be more useful, to allow various tools beyond just codegen to be built on top of it.

Yes, definitely.
Nevertheless the extension of the EDTS database class to fit a lot more use cases should be done in future PRs. Extending the scope of the series of related PRs #9876, #6762 will question to  include them in Zephyr 1.14 even for the current use case.
@galak what you can do is to have a look on the public API of edtsdatabase.py and review whether the API contradicts your envisaged use cases. The API encapsulates the database structure, which may be changed later on if there is a need by a future use case. Please propose additions that are related to future use cases and not of use for this one in another PR/Issue.
About the technical things

I'm not sure I follow? Aren't we flattening the devices down to key/value pairs? The key being "device-id"? The tree structure I was suggesting to keep is so we could possible remove things like 'parent-device'.

I had a different concept of 'flattening' than you. Yes the device tree is flattened to device specific property trees that are indexed by "device-id". "device-id" is the equivalent of a phandle in DTS. The current structure fits to the use case  "Provide device tree info for compile time driver data instantiation".
The structure you are propsing would make it much more complex to generate the data for driver data instantiation. As said - design follows the use case.

For example, having such views is part of how DT works and is useful. For example, its becomes much easier to find the MAX_IRQ # for an given interrupt controller this way.

Views are logical combinations of data. As such a view has to process the data to create the "view". IMHO the data processing shall not be done when the database is filled but shall be done by an application that is retrieving the data from the database. There is a clear split of concepts: DTS data extraction (extract_dts_includes) and EDTS data processing (codegen or any other tool that uses the database).
The task of the database is to provide an appropriate API to fill the database and to retrieve the data from the database - thats it. The EDTS class has to be used with Python anyway. We don´t need application/ user specific processing in the database (no equivalent to stored procedures, ...). Any user of the class can use Python to create the data processing she needs.
For your example:
I don´t know whether  "MAX_IRQ #" is really necessary for a driver. If it is provided as a property it can easily be read from the database. If not you may have to search for all usages of the interrupt controller by other nodes. This can not be done directly at database filling (info is potentially incomplete at that time) - you need a post processing state.
A driver specific post processing would blow up the database filling. That is why there shall be a strict separation of concepts - filling vs. usage/ processing.

EDTS should contain enough info for one to use it to replace the part of extract_dts_includes.py that generates the generated_dts_board.*.

This may be a future extension. If done now this would trigger a another major rewrite of extract_dts_includes.py that questions inclusion in 1.14.  Clearly a candidate for another PR.

Part of my reason, is this gives an example of how to load and setup EDTS code in python. Its trivial, but useful.

EDTS is a Python class. The json that you load will be saved identical - otherwise there would be a bug in the Python Json module.
I´m reluctant to add a main to a class library. It makes the library a tool which is not intented. It would also raise requests for other main function additions.
The usage of EDTS for testing/ prototyping is so easy - you just have to import the module. There is really no reason to add otherwise dead code to the class library. Example code should go to the documentation and not into the class file.
@erwango is responsible for this PR. Maybe he has a different opinion.

@b0661 , thanks for the review, I'll be in the plane shortly, I'll get your comments early next week.

Added 3 commits in order to introduce edts sanity check.
Aim is to provide sanity check to validate edts generation against a known reference.
Proposed solution compares edts.json produced from a 'reference' board dts file against inputs from a yaml reference file. This allows to exercise and test EDTSConsumer Class, but makes it painful to compare all elements (all elements have to be documented in yaml file, hence basically requests to reproduce edts to a different format).
Another way of doing would be to compare generated edts file against a reference (because reviewed and upstreamed) edts.json file. Comparison can be done using EDTSConsummer Class on both etds files, then we exercise the class but we don't fully test the class since using it on both tested and reference side. Though this solution would make much easier to validate all file elements.

@b0661: fixed, thanks

So the device-type additions, not 100% sure what we are doing here, but thinking that type should be coming from files like dts/bindings/serial/uart.yaml.

@galak :

So the device-type additions, not 100% sure what we are doing here, but thinking that type should be coming from files like dts/bindings/serial/uart.yaml.

This is indeed the case.
id yaml file parameter which used to convey free (and usually redundant) text information has been changed to provide the device-type. id was finally renamed to type.
This has been done with following commit (providing the name, as SHA1 will likely change before merge)
dts/bindings: Replace id with generic zephyr type
dts/bindings: Rename 'id' yaml property into 'type'
Hence for spi.yaml:
---
title: SPI Base Structure
type: spi
version: 0.1

type should match (in lower case) the driver type provided in drivers/<driver>/Kconfig:
menuconfig SPI
	bool "SPI hardware bus support"
	help
	  Enable support for the SPI hardware bus.

Aim of this introduction is to be able, later on, to establish a relationship between driver symbols and device type.
This will be useful for instance in https://github.com/zephyrproject-rtos/zephyr/issues/9406 to establish that a DTS_COMPAT_XXX_SPI flag has a dependency on CONFIG_SPI

@erwango can we cleanup the commits a bit, a few things I noticed:

Merge 'scripts: edts: Sort structures when saving to json' & 'scripts/dts: edtsdatabase rework consumer class' with 'scripts/dts: Introduce edts.json generation'
cleanup the set of commits related to id/type

@erwango how do I run scripts/dts_sanity/edtscheck.py?

why do we need a property called device-id, seems redundant with the node name?

why do we need a property called device-id, seems redundant with the node name?

device-id is the database key (similar to a phandle in DTS) to access device data. It is needed to easily create references to devices (as the phandle).
For ease of use and because it is unique the device-id currently is the node address. It may be optimized to another form if necessary.

@erwango should I expect to see 'status' in the edts.json?

device-id is the database key (similar to a phandle in DTS) to access device data. It is needed to easily create references to devices (as the phandle).
For ease of use and because it is unique the device-id currently is the node address. It may be optimized to another form if necessary.

are you saying that device-id should be considered opaque than?  ie the user shouldn't make assumptions of what device-id is?

are you saying that device-id should be considered opaque than? ie the user shouldn't make assumptions of what device-id is?

Yes it shall be considered opaque.

@galak

@erwango how do I run scripts/dts_sanity/edtscheck.py?

python3 scripts/dts_sanity/edtscheck.py

@galak :

@erwango should I expect to see 'status' in the edts.json?

Yes. Though, it might not be present for all nodes:
Initially only 'status' value treated was 'disabled' (node discarded), and nothing was done when status was not present. So no status is equivalent to 'ok'.

@galak :

Merge 'scripts: edts: Sort structures when saving to json' & 'scripts/dts: edtsdatabase rework consumer class' with 'scripts/dts: Introduce edts.json generation'

This will be a rebase hell, lot of x-dependencies out there. I propose to split into 2 commits  EDTSProviderMixin (among the initial commits and put maximal stuff in it) and EDTSConsumerMixin (which will be among the last  commits)

cleanup the set of commits related to id/type

Do you mean merge the 2 commits ?

Yes. Though, it might not be present for all nodes:
Initially only 'status' value treated was 'disabled' (node discarded), and nothing was done when status was not present. So no status is equivalent to 'ok'.

we should really have status in all nodes regardless of its value.

Aim of this introduction is to be able, later on, to establish a relationship between driver symbols and device type.
This will be useful for instance in #9406 to establish that a DTS_COMPAT_XXX_SPI flag has a dependency on CONFIG_SPI

I think we should drop the type stuff for now.

@erwango @galak
It seems there are a lot of further ideas what to do with EDTSdatabase. Would it be possible to have a minimal implementation within this PR and make enhancements in new PRs?

[ ] script/dts: Generate Extended Device Tree database (minimal basis) #9876
[ ] scripts/dts: Extend EDTS database by generic device class
[ ] scripts/dts: Provide unique ID for devices in ETDS
[ ] scripts/dts: Extend EDTS database by clock provider device class
[ ] scripts/dts: Extend EDTS database by interrupt controller device class
[ ] ... other specific device classes based on generic device class

After merge of the minimal basis #9876 also inline code generation can be reviewed and merged:

[ ] scripts: add Zephyr inline code generation with Python #6762

@b0661

The filling of the controller view is scattered over several files and will be even more scattered as other controllers are added. DTS does already have a [device]-controller directive for several devices (clocks-controller, interrupt-controller, ...).
In the orginal proposal there was a controller.py to cover the [device]-controller directives and some heuristics within heuristics.py for devices that do not have a controller directive. By this the controller view extraction could be concentrated to just 2 files - which would be in my view a real benefit for future additions and maintenance.

Had a detailed look to your proposal. One point is that controller information:

controller/provider information when inserting in edts 'devices' dict
edts_insert_device_controller function requires to extract device related information ('IRQ line', 'GPIO number', 'clock cells') which currently reused from device dedicated code (gpio.py, clock.py, interrupts.py)

Moving controller related code in one single file would indeed concentrate some part but would require duplication of all these section of code (that could be rather complex) dedicated to each device in the new controller module. To my view this code duplication would not benefit to maintenance. How would you address that?

Moving controller related code in one single file would indeed concentrate some part but would require duplication of all these section of code (that could be rather complex) dedicated to each device in the new controller module. To my view this code duplication would not benefit to maintenance.

I was not aware that you need so much extra info.

How would you address that?

I would make the controller view a 'View" object that computes the information from the database content (aka. View <-> Model). At computation time the database is already filled and all info like interrupts, clocks, ...  can be retrieved in a standard way.

I would make the controller view a 'View" object that computes the information from the database content (aka. View <-> Model). At computation time the database is already filled and all info like interrupts, clocks, ... can be retrieved in a standard way.

This is indeed a point that is worse discussing. I though about building the 'view' in a query rather than filling it in database. I initially also supported the fact that edts should only contain the 'device' dict.
I chose to rather fill-in the database with the 'view' for following reasons:

Filling in 'view' when information is present will be less costly in cycles than trying to build it afterwards (with all the involved loops). This is even more true when information is queried more than once.
As available in edts.json, it could be easily read by humans (and this could be the case also with your proposal, if view computation is done as a complementary edts building step).

This reasoning might hit some limitations if too much views are put into edts and only quite a little use of it is done afterwards. This being said, I think we still miss the experience on how edts is used. Maybe we can review internal behavior once it is deployed and used, and once we see needs for improvements.

@erwango  you really do not know what you are doing or - worse - you do it by purpose.
You removed get_device_id_by_label() and device_properties_flattened() without a notice. This blows up any inline code generation using device_declare of any form.
I don´t know about the teamwork at your company or the Zephyr community - but for me this is the last and very obvious sign to leave you alone. I will find a way to do my work OOT.

@erwango you really do not know what you are doing or - worse - you do it by purpose.
You removed get_device_id_by_label() and device_properties_flattened() without a notice. This blows up any inline code generation using device_declare of any form.
I don´t know about the teamwork at your company or the Zephyr community - but for me this is the last and very obvious sign to leave you alone. I will find a way to do my work OOT.

It seems there are a lot of further ideas what to do with EDTSdatabase. Would it be possible to have a minimal implementation within this PR and make enhancements in new PRs?

[ ]  script/dts: Generate Extended Device Tree database (minimal basis) #9876
[ ]  scripts/dts: Extend EDTS database by generic device class
[ ]  scripts/dts: Provide unique ID for devices in ETDS
[ ]  scripts/dts: Extend EDTS database by clock provider device class
[ ]  scripts/dts: Extend EDTS database by interrupt controller device class
[ ]  ... other specific device classes based on generic device class

After merge of the minimal basis #9876 also inline code generation can be reviewed and merged:

[ ]  scripts: add Zephyr inline code generation with Python #6762

Yes, we should merge a subset to make progress.  I've unfortunately been busy with too many things, but wanted to simplify the eDTS support and just have compatible, regs, irqs, and basic properties merged.

@b0661

You removed get_device_id_by_label() and device_properties_flattened() without a notice. This blows up any inline code generation using device_declare of any form.
I don´t know about the teamwork at your company or the Zephyr community - but for me this is the last and very obvious sign to leave you alone. I will find a way to do my work OOT

I acknowledge your remark. I was trying to follow recommendations for merge, but doing so I lost connection with codegen work.
@galak

Yes, we should merge a subset to make progress. I've unfortunately been busy with too many things, but wanted to simplify the eDTS support

ok

and just have compatible, regs, irqs, and basic properties merged.

I think @b0661 is right here. We should push something coherent from codegen point of view, since this is the initial target. Ok to remove controllers/device-type/status/chosen. But we need to keep compatibles and full device dict (with reworked reg if needed).

@b0661, just pushed back a version with the missing APIs.
Though, you should be aware that there will be more changes coming, as @galak is adding some changes on top of that and initial merge will be a stripped version of that with some addition of EDTSDeviceClass.

@erwango thanks for the info. I´m fine with having the API back.

@erwango
What about get_device_id_by_label()?

What about get_device_id_by_label()?

Was renamed into get_device_ids_by_label, but does not make any sense. Back to get_device_id_by_label now.

I pushed an update that introduces EDTSDevice class and splits out the consumer updates into multiple commits.
@erwango can you look at fixing up your test script for the introduction of EDTSDevice

@galak:
edtscheck.py updated, now using EDTSDevice methods.

@erwango, @galak
I created an EDTS database variant with an integrated extraction function that can directly extract from the DTS compiled file. The consumer, provider and database layout is a copy of #9876. For codegen development I will use this variant of the EDTS database. My plan is to regularly synchronize the API and functionality to #9876. As I'm working on a copy variant (and not on #9876) there will be no clashed in case of incompatible API changes.
You may have a look at https://github.com/b0661/zephyr/commit/3b7c77f25654494d9c85fbcbd8ab580e6e1489a5
Major differences/ improvements to #9876 are:

the database now has an own extraction function that can be used instead of e.g. extract_dts_includes.  The extraction function follows the design of  the extract_dts_includes script and the additions that  were done in #9876. It is restructured and several globals are now classes and objects. All functionality of extract_dts_includes related to the generation of defines is not part of the database extract function. It's sole purpose is to fill the database directly from the compiled DTS file.
the database got itś own directory 'edtsdb' to structure all files related to the database.
The EDTSDevice class from #9876 was enhanced to allow devices to access the database they are taken from.

Mayor compatibility issues to #9876.

the consumer, provider API and the internal structure  of the databse is copied from #9876. API should be fully compatible.
the EDTSDevice class is copied from #9876. The  device API should be fully compatible except for       the unique id feature. Device name can be used instead.

Closing, as this should be superceded by PR #17660


Update to work for Ruby 3.0.0 (Solution provided)

Describe the bug
Install will not run locally as described in readme file. Gets caught on machineevent gem install and fails with exit code 5
To Reproduce
Steps to reproduce the behavior:

Run yarn install with Ruby 3.x.x

Expected behavior
Install despite any dependency warnings so I could use locally
Desktop (please complete the following information):

OS: Catalina, then upgraded to Monterey (bc xCode)
Browser [e.g. chrome, safari]: Chrome
Ruby version: 3.0.0p0

Additional context
I got the install to run when I deleted the yarn.lock file and the node_modules folder.
And then (and here is the key) installed eventmachine gem separately using
gem install eventmachine --<EMAIL_ADDRESS>This isn't an OS issue, as the installation works without supporting arguments with Ruby 2.7, but fails (unless you provide the location of openssl manually) with Ruby 3.0. There is an issue open with eventmachine, but . Here is the link where I got the fix: https://github.com/eventmachine/eventmachine/issues/932
Maybe add a note to your readme file if people are using ruby 3.0 on Big sur and Monterey

Thanks @onelittlebecca for the heads up! Pinging @chosak @brandon-rusk for awareness and to update our docs.

Related to https://github.com/cfpb/design-system/issues/415
The overarching issue is that we should likely move off of jekyll and remove the Ruby dependency. This is the only repo we maintain that has a Ruby dependency.

https://github.com/cfpb/design-system/pull/1475 added https://github.com/cfpb/design-system/tree/f351bbf93b65e4cd29500ad24340003e3f05fb62#running-the-documentation-website-locally


Investigate log level mismatch between error_logger and logger

Fixed on 90a221f58681abeca3dea (part of 1.7.0.)


chore: download recent curl if necessary on x64 Linux

By the way, I'm surprised we haven't hit https://github.com/leanprover/elan/commit/342a0ca3870d06bd32db4a16b1549219657b5d55 yet

No, they only remove *.gz files

Right, bad memory 🤦🏼

bors r+


Qsharp: qs module fails to import when running regularly the first time

Version: 1.42.1 (user setup)
OS: Windows_NT x64 10.0.18362

Steps to Reproduce:

Attempt to run the python file using the green arrow
ModuleNotFoundError: No module named

Does this issue occur when all extensions are disabled?: Yes

Picture displaying command failing in VS Code, but works fine when copied to native cmd terminal.

So after looking at it for some time, the error is not from

commands too long
being in directory\foo and executing ./bar/host.py
improperly installed qsharp

Please file this issue on the vscode-python extension's repo: https://github.com/microsoft/vscode-python/issues


Fix tests running in CI

Coverage remained the same at 96.396% when pulling a457e332030c46d9aa50e2aa216d4bc5206ed47d on tests into a5517ce4953c01b117412f5f8f07e190036318f5 on master.

Coverage remained the same at 96.396% when pulling 73717929bef7cdbfdd296d606ff4bb604d5de019 on tests into a5517ce4953c01b117412f5f8f07e190036318f5 on master.


Cannot apply patch because my file delimiter is "/r/n" instead of "/n"

My target file(the one going to apply the patch) has "/r/n" as line delimiter, so because in the apply.js at line 32 you hard coded to separate the file with "/n", and this will result in "false" returned from compareLine method, and the patch generated from "git diff" command cannot be applied to my file. Any action will take on this?

it's on Window btw,

fixed in my pull request

Hey @soulbeing, did this ever make it in? diffLines also doesn't work for Windows line endings (on  OS X). Going to investigate now.


Docked state wrong

https://github.com/Zefau/ioBroker.roomba/issues/28

https://github.com/koalazak/dorita980/issues/111

Hard to find out, where this issue is currently tracked because the given links above don't say anything to me.
Anyway: My Roomba 675 has exactly the same behaviour: when in the dock, the dock-status is false, when outside (cleaning), the dock-status is true.

Please check with newest version of adapter (1.2.1).
If issue still occure, please report your configuration (Adapter version, js-controller version, node, npm, OS).
If no response received within 30 days this issue might be closed.

According to discussion in the linked issues (especiallyhttps://github.com/koalazak/dorita980/issues/111) this state does MNOT represent the docking status (docked / not docked) but the information wheterh the roomba KNOWS where the docing station is.


Updating ClassDecl to also accept actor

This patch updates swift-syntax to accept actors in the place of the
class keyword.
Updates made by running: ./swift/utils/build-script --swiftsyntax --release
I'm not sure if I did this right, so let me know if something looks out of place.
It corresponds with the changes made in apple/swift fc41826da96894fa2e4851a2c905b838a90a8cbc.

@swift-ci please test

Corresponds with: https://github.com/apple/swift/pull/35794


emit_particle doesn't work (GPUParticles2D and 3D)

Godot version
v4.2.beta1.official [b1371806a]
System information
Windows 10 / NVIDIA Geforce GTX 1060 3GB / all backends
Issue description
GPUParticles2D/3D emit_particle doesn't do anything in the 4.2 beta 1. In the last snapshot it worked fine. Tested in Forward+, Mobile and Compatibility backends.
Steps to reproduce
Create a GPUParticles2D and set up as normal. Add following script:
extends GPUParticles2D
func _process(delta: float) -> void:
	emit_particle(global_transform, Vector2.ZERO, Color.WHITE, Color.WHITE, 0b11111)

or GPUParticles3D
extends GPUParticles3D
func _process(delta: float) -> void:
	emit_particle(global_transform, Vector3.ZERO, Color.WHITE, Color.WHITE, 0b11111)

Minimal reproduction project
See below.

I've made a little reproduction project to test the issue in 2D and 3D.
It works directly on the editor and exposes the emission settings to test the issue.
From the tests, I've found out that the CUSTOM color's Alpha and Green channels are being used for the particle's lifetime.

More green lowers the lifetime, less alpha also does the same.
In Godot 4.1.2-stable none of this happen.

I'm not completely sure on how emit_particle() works, but from more testing, I've also found that it doesn't seem to be applying Rotation, Scale or Color.
This behavior is the same in Godot 4.1.2-stable.
Also, the compatibility renderer explicitly warns on the console that it does not support manually emitting the particles.
GPUParticle Emit.zip

Thanks for insight, good job!

Also, the compatibility renderer explicitly warns on the console that it does not support manually emitting the particles.

Oops, my bad, I'll remove this part from the issue.

I'm not so sure either how my PR broke it, but of note CUSTOM always had lifetime in green and lifetime randomness in alpha. That is intended behaviour, unless there's some strange interaction now that wasn't there before

You unbroke it! I guess that means this can be closed then? Might need still some testing as to what was the earlier behavior, wasn't CUSTOM not set at all?

CUSTOM always had lifetime in green and lifetime randomness in alpha.

The lifetime in Alpha seems to be the same as in Green, except that it's using the value in reverse and they are incrementing each other.
There is no randomness to Alpha. Although, when CUSTOM is activated, the default particle randomness is disabled.

That is intended behaviour

Then we also need some documentation, since CUSTOM has no description of what each value does.
For example, Red and Blue also seem to do nothing, so I couldn't test them.

You unbroke it!

Haha no i think emit_particle still needs to be fixed

Then we also need some documentation, since CUSTOM has no description of what each value does.

Yeah fair!
CUSTOM.x = angle (for billboard)
CUSTOM.y = current lifetime
CUSTOM.z = animation for flipbook
CUSTOM.w = lifetime randomness
actual lifetime (in 0-1 value) is INSTANCE_CUSTOM.y/INSTANCE_CUSTOM.w

CUSTOM.x = angle (for billboard)
CUSTOM.y = current lifetime
CUSTOM.z = animation for flipbook
CUSTOM.w = lifetime randomness

I moved the Red channel's values around, but didn't see any changes to the texture (the texture is already in Particle Billboard mode)
I also set "Particle Anim" and changed the Blue channel's value, but there were no changes in the animation.
Even when I played around with the particle's animation settings, the blue value made no changes to them.
At this point, only the "current lifetime" is applying for CUSTOM. Although I wonder if it was supposed to be the inverse (like how Alpha is doing), with full green meaning full lifetime, as right now it seems counterintuitive.
Rotation, Scale and Color also seem to not be working.

@aXu-AP can you reproduce in beta2?

I'm having a hard time debugging this issue. In the MRP I am observing the same behaviour when I revert the PR, so I'm wondering if I'm missing something somewhere.
To help me understand the issue and fix it faster, I need to have a clear idea of expected behaviour and current behaviour. Comparative videos of one and the other would also help a lot :pray:

I just tested with the Wagner's MRP, yes it is the same; however that MRP sends (0,0,0,1) as custom, my case was with (1,1,1,1). So change the exported custom property to white. Which, according to your explanation is expected to be not working as green = lifetime. However, on 4.1 it works.

So, green = lifetime when it's used by the main particle system. If you script the shader yourself, it can mean anything.

Here's a new MRP. Sorry for not supplying one before:
ParticleMRP.zip
On 4.1, particles (white boxes) show, on 4.2 beta 2, nothing shows.

I think it makes sense that nothing shows. If your particles have already outlived their lifetime (green=1) then they should disappear. So if you spawn them, they spawn "already dead". This sounds like a bug in 4.1, if i understood correctly everything that's happening.

Yes, this is what I meant when I said that you unbroke it and this issue can be closed. The behavior is different, but earlier behavior was a bug and this was just me not knowing what parameters to set with emit_particle. So user error essentially.

Alright then we agree :+1: Thanks everyone for taking the time to investigate this <3

Thank you for being patient 😅
Had I supplied an MRP straight away or at least tested the other MRP earlier to see that it differed from my case we could've solved this way faster.

No worries!

So, about the Rotation, Scale, Color, CUSTOM Red/Blue/Alpha and CUSTOM documentation?
Do they deserve issues of their own to look into that later?

@WagnerGFX  Yeah I think we should track that as a separate documentation issue. If custom parameter's behavior on standard processing paterial was documented properly, I would've used emit_particle properly in first place 😁

I do think that emit particle probably can't be used together with a standard particle material in that way. the particle material has to override the custom data with its own calculated randomness inside. I don't think that can change so it should be documented both on emit particle and somewhere for the custom vector.


Multi-Shot Performance Degradation

I currently do solve an optimization problem that contains a certain bound/horizon X.
I want to find a minimal solution within this bound. So if i set the bound X=500 and solve the problem i do get a minimal solution with a value of 267. So, obviously I could have set the bound X=300 to save on grounding/solving time and reduce the search space and still find a minimal solution with value 267. If I would have reduced the bound too much, like X=200 I would simply get UNSAT.
Now I have rewritten my encoding to incrementally increase this bound (X=0, X=100, X=200, ...) to save on grounding/solving time. Doing this, using the command line, needs to reground everything before and nothing can be reused. Doing this using the multi-shot interface, I can reuse old rules, retract a tiny percent of the old rules and add new rules.
The results that I got are the following:
Manual Incremental Solving using command line and the original Encoding:
X=0:

Progression : [60;inf]
Progression : [120;inf]
Progression : [180;inf]
Progression : [186;inf]
Progression : [192;inf]
UNSATISFIABLE
Models       : 0
Calls        : 1
Time         : 3.911s (Solving: 0.07s 1st Model: 0.00s Unsat: 0.07s)
CPU Time     : 3.972s
Threads      : 2        (Winner: 0)
Choices      : 7614     (Domain: 6615)
Conflicts    : 35       (Analyzed: 17)
Restarts     : 0
Problems     : 7        (Average Length: 0.29 Splits: 0)
Lemmas       : 194      (Deleted: 0)
Binary     : 64       (Ratio:  32.99%)
Ternary    : 45       (Ratio:  23.20%)
Conflict   : 17       (Average Length:    2.2 Ratio:   8.76%)
Loop       : 0        (Average Length:    0.0 Ratio:   0.00%)
Other      : 177      (Average Length:    2.7 Ratio:  91.24%)
Distributed: 80       (Ratio: 470.59% Average LBD: 100.45)
Integrated : 80       (Ratio: 100.00% Unit: 25 Average Jumps: 45.48)
Backjumps    : 17       (Average: 15.06 Max:  48 Sum:    256)
Executed   : 15       (Average: 14.82 Max:  48 Sum:    252 Ratio:  98.44%)
Bounded    : 2        (Average:  2.00 Max:   2 Sum:      4 Ratio:   1.56%)
Rules        : 893170
Choice     : 4763
Minimize   : 2
Heuristic  : 4311
Atoms        : 854848
Bodies       : 50499
Count      : 46
Equivalences : 114738   (Atom=Atom: 33882 Body=Body: 18683 Other: 62173)
Tight        : Yes
Variables    : 9908     (Eliminated:    0 Frozen: 9908)
Constraints  : 35574    (Binary:  64.9% Ternary:  31.9% Other:   3.2%)

X=225000

Progression : [1;inf]
Progression : [2;inf]
Progression : [3;inf]
Progression : [4;inf]
Progression : [5;inf]
Progression : [6;inf]
Progression : [7;inf]
Progression : [8;inf]
UNSATISFIABLE
Models       : 0
Bounds       : [8;] [0;]
Calls        : 1
Time         : 4.387s (Solving: 0.22s 1st Model: 0.00s Unsat: 0.22s)
CPU Time     : 4.604s
Threads      : 2        (Winner: 0)
Choices      : 23742    (Domain: 18106)
Conflicts    : 72       (Analyzed: 60)
Restarts     : 0
Problems     : 10       (Average Length: 0.20 Splits: 0)
Lemmas       : 557      (Deleted: 0)
Binary     : 158      (Ratio:  28.37%)
Ternary    : 123      (Ratio:  22.08%)
Conflict   : 59       (Average Length:    5.3 Ratio:  10.59%)
Loop       : 0        (Average Length:    0.0 Ratio:   0.00%)
Other      : 498      (Average Length:    4.1 Ratio:  89.41%)
Distributed: 170      (Ratio: 288.14% Average LBD: 93.28)
Integrated : 170      (Ratio: 100.00% Unit: 27 Average Jumps: 67.07)
Backjumps    : 60       (Average: 44.28 Max: 745 Sum:   2657)
Executed   : 49       (Average: 11.40 Max: 745 Sum:    684 Ratio:  25.74%)
Bounded    : 11       (Average: 179.36 Max: 741 Sum:   1973 Ratio:  74.26%)
Rules        : 957799
Choice     : 8312
Minimize   : 2
Heuristic  : 7048
Atoms        : 887913
Bodies       : 83670
Count      : 46
Equivalences : 181546   (Atom=Atom: 52863 Body=Body: 27977 Other: 100706)
Tight        : Yes
Variables    : 15541    (Eliminated:    0 Frozen: 15541)
Constraints  : 57853    (Binary:  62.2% Ternary:  34.9% Other:   2.8%)

X=450000

OPTIMUM FOUND
Models       : 29
Optimum    : yes
Optimization : 540013 360
Calls        : 1
Time         : 5.749s (Solving: 1.32s 1st Model: 0.85s Unsat: 0.01s)
CPU Time     : 7.044s
Threads      : 2        (Winner: 1)
Choices      : 156314   (Domain: 111548)
Conflicts    : 2416     (Analyzed: 2351)
Restarts     : 5        (Average: 470.20 Last: 121)
Model-Level  : 1234.8
Problems     : 66       (Average Length: 0.03 Splits: 0)
Lemmas       : 3833     (Deleted: 0)
Binary     : 302      (Ratio:   7.88%)
Ternary    : 418      (Ratio:  10.91%)
Conflict   : 2351     (Average Length:   18.8 Ratio:  61.34%)
Loop       : 0        (Average Length:    0.0 Ratio:   0.00%)
Other      : 1482     (Average Length:    5.5 Ratio:  38.66%)
Distributed: 471      (Ratio:  20.03% Average LBD: 92.73)
Integrated : 471      (Ratio: 100.00% Unit: 48 Average Jumps: 71.54)
Backjumps    : 2351     (Average:  5.09 Max: 1233 Sum:  11962)
Executed   : 2309     (Average:  3.24 Max: 1233 Sum:   7618 Ratio:  63.69%)
Bounded    : 42       (Average: 103.43 Max: 1169 Sum:   4344 Ratio:  36.31%)
Rules        : 1022697
Choice     : 11112
Minimize   : 2
Heuristic  : 9442
Atoms        : 916954
Bodies       : 116181
Count      : 46
Equivalences : 244095   (Atom=Atom: 71055 Body=Body: 38420 Other: 134620)
Tight        : Yes
Variables    : 20362    (Eliminated:    0 Frozen: 20362)
Constraints  : 79753    (Binary:  59.0% Ternary:  38.2% Other:   2.8%)

With the incremental approach I do get the following results:

Progression : [60;inf]
Progression : [120;inf]
Progression : [180;inf]
Progression : [240;inf]
Progression : [300;inf]
UNSATISFIABLE
Models       : 0
Time         : 4.138s (Solving: 0.06s 1st Model: 0.00s Unsat: 0.06s)
CPU Time     : 4.192s
Threads      : 2        (Winner: 1)
Choices      : 7908     (Domain: 7064)
Conflicts    : 53       (Analyzed: 13)
Restarts     : 0
Problems     : 7        (Average Length: 0.57 Splits: 0)
Lemmas       : 148      (Deleted: 0)
Binary     : 44       (Ratio:  29.73%)
Ternary    : 53       (Ratio:  35.81%)
Conflict   : 13       (Average Length:    3.0 Ratio:   8.78%)
Loop       : 0        (Average Length:    0.0 Ratio:   0.00%)
Other      : 135      (Average Length:    3.5 Ratio:  91.22%)
Distributed: 55       (Ratio: 423.08% Average LBD: 99.87)
Integrated : 54       (Ratio:  98.18% Unit: 23 Average Jumps: 45.13)
Backjumps    : 13       (Average: 30.31 Max:  69 Sum:    394)
Executed   : 11       (Average: 25.69 Max:  69 Sum:    334 Ratio:  84.77%)
Bounded    : 2        (Average: 30.00 Max:  36 Sum:     60 Ratio:  15.23%)
Rules        : 1050257
Choice     : 4763
Minimize   : 2
Heuristic  : 4311
Atoms        : 1011936
Bodies       : 50500
Count      : 46
Equivalences : 99987    (Atom=Atom: 26783 Body=Body: 18683 Other: 54521)
Tight        : Yes
Variables    : 9909     (Eliminated:    0 Frozen: 8344)
Constraints  : 35590    (Binary:  64.9% Ternary:  31.9% Other:   3.2%)
Solving...
Progression : [180007;inf]
Progression : [180008;inf]
Progression : [225008;inf]
UNSATISFIABLE
Models       : 0
Bounds       : [225008;] [0;]
Time         : 11.407s (Solving: 10.32s 1st Model: 0.00s Unsat: 10.32s)
CPU Time     : 21.724s
Threads      : 2        (Winner: 0)
Choices      : 57821    (Domain: 44147)
Conflicts    : 105      (Analyzed: 92)
Restarts     : 0
Problems     : 13       (Average Length: 0.31 Splits: 0)
Lemmas       : 653      (Deleted: 0)
Binary     : 153      (Ratio:  23.43%)
Ternary    : 187      (Ratio:  28.64%)
Conflict   : 90       (Average Length:    5.5 Ratio:  13.78%)
Loop       : 0        (Average Length:    0.0 Ratio:   0.00%)
Other      : 563      (Average Length:    4.5 Ratio:  86.22%)
Distributed: 215      (Ratio: 238.89% Average LBD: 87.10)
Integrated : 213      (Ratio:  99.07% Unit: 43 Average Jumps: 178.16)
Backjumps    : 92       (Average: 64.78 Max: 737 Sum:   5960)
Executed   : 76       (Average: 20.86 Max: 737 Sum:   1919 Ratio:  32.20%)
Bounded    : 16       (Average: 252.56 Max: 732 Sum:   4041 Ratio:  67.80%)
Rules        : 1119270
Choice     : 8718
Minimize   : 3
Heuristic  : 7048
Atoms        : 1049370
Bodies       : 84124
Count      : 46
Equivalences : 166520   (Atom=Atom: 44279 Body=Body: 27530 Other: 94711)
Tight        : Yes
Variables    : 16079    (Eliminated:    0 Frozen: 13849)
Constraints  : 57800    (Binary:  62.5% Ternary:  34.7% Other:   2.8%)
OPTIMUM FOUND
Models       : 163
Optimum    : yes
Optimization : 630013 360
Time         : 207.521s (Solving: 206.78s 1st Model: 28.36s Unsat: 0.01s)
CPU Time     : 414.264s
Threads      : 2        (Winner: 0)
Choices      : 562026   (Domain: 378073)
Conflicts    : 25447    (Analyzed: 25020)
Restarts     : 62       (Average: 403.55 Last: 0)
Model-Level  : 1924.5
Problems     : 428      (Average Length: 0.01 Splits: 0)
Lemmas       : 27649    (Deleted: 8371)
Binary     : 523      (Ratio:   1.89%)
Ternary    : 934      (Ratio:   3.38%)
Conflict   : 25020    (Average Length:   34.0 Ratio:  90.49%)
Loop       : 0        (Average Length:    0.0 Ratio:   0.00%)
Other      : 2629     (Average Length:    6.6 Ratio:   9.51%)
Distributed: 731      (Ratio:   2.92% Average LBD: 98.01)
Integrated : 731      (Ratio: 100.00% Unit: 86 Average Jumps: 298.60)
Backjumps    : 25020    (Average:  2.12 Max: 744 Sum:  52947)
Executed   : 24770    (Average:  1.67 Max: 744 Sum:  41679 Ratio:  78.72%)
Bounded    : 250      (Average: 45.07 Max: 741 Sum:  11268 Ratio:  21.28%)
Rules        : 1192380
Choice     : 11924
Minimize   : 4
Heuristic  : 9442
Atoms        : 1086561
Bodies       : 118074
Count      : 46
Equivalences : 235121   (Atom=Atom: 63824 Body=Body: 37247 Other: 134050)
Tight        : Yes
Variables    : 21397    (Eliminated:    0 Frozen: 18494)
Constraints  : 79607    (Binary:  59.3% Ternary:  37.9% Other:   2.8%)

I additionally use multi-threading (2threads) and theory solving (DLPropagator).
My questions is now, why is the solving process so much slower, given a similar search behaviour, number of variables and constraints.
The first step X=0 is nearly identical, same grounding and solving time, similar conflicts and choices.
The second step X=225000 the manual version took 4s grounding time (it had to reground the first step completely) and 0.22s solving time to proof unsat with 23k choices and 72 conflicts.
Doing exactly the same using the multi-shot API the grounding too only 1s (as it simply had to add some rules) but solving took 10s to prove unsat.
Normally I would say that this can happen if the search gets confused, but the number of choices is 57k with 107 conflicts. So its double the choices, but the time is 50 times higher.
Where does this time go and what makes search so slow. The statistics of the DLPropagator show that it uses nearly no time (thats why I did not included it here).
Any idea why unit propagation speed degrades by 5000% ? It seems somehow related to the multishot approach.

Same behaviour without multi-threading.

Sorry, but I cannot tell you. It could be the restricted preprocessing or just heuristic effects. You could try to experiment with the forgetting options.

Given that I use the theory interface and clingo-dl, sat-prepro is disabled in both cases, and you can see that no variables were eliminated anywhere.
Heuristic effects In my opinion are possible but do not explain the results. 2 times the amount of choices can be a heuristic effect, but not 50 times the raw propagation performance. Same with forgetting options, this should have an influence on choices/conflicts but not on raw speed. I will try nevertheless.

Note that there is more than just sat preprocessing. I cannot tell from the statistics where the problem is. You could profile the code to figure out where most time is spent.

Thanks. I simply doubt that the result/lack of preprocessing the the cause, as the number of constraint(and their sizes)/variables  is very similar. Will try to figure out how to profile this setup.

--forget-on-step=15
has some impact but the problem stays the same.

Unsure if this is going off topic.
This is part of the callgrind analysis, unsure how to interpret it:
--------------------------------------------------------------------------------
273,665,234,990  PROGRAM TOTALS

--------------------------------------------------------------------------------
            Ir  file:function
--------------------------------------------------------------------------------
38,031,950,558  libclingo-dl/clingo-dl/propagator.hh:DifferenceLogicPropagator<int>::check(Clingo::PropagateControl&) [/home/ostrowsk/work/krbiz/gitpotassco/clingoDL/build/bin/libclingo-dl.so]
37,699,274,344  clingo/clasp/src/clingo.cpp:Clasp::ClingoAssignment::value(int) const [/home/ostrowsk/work/krbiz/gitpotassco/clingoDL/build/bin/libclingo.so.3.0]
36,469,261,288  clingo/libclingo/clingo.hh:DifferenceLogicPropagator<int>::check(Clingo::PropagateControl&)
25,527,669,678  clingo/clasp/libpotassco/src/clingo.cpp:Potassco::AbstractAssignment::isTrue(int) const [/home/ostrowsk/work/krbiz/gitpotassco/clingoDL/build/bin/libclingo.so.3.0]
25,527,669,678  clingo/libclingo/src/control.cc:clingo_assignment_is_true [/home/ostrowsk/work/krbiz/gitpotassco/clingoDL/build/bin/libclingo.so.3.0]
21,880,859,724  clingo/clasp/clasp/literal.h:Clasp::ClingoAssignment::value(int) const
11,745,086,126  /usr/include/c++/6/bits/stl_vector.h:DifferenceLogicPropagator<int>::check(Clingo::PropagateControl&)
10,942,400,772  clingo/libclingo/clingo.hh:Clingo::Detail::handle_error(bool) [/home/ostrowsk/work/krbiz/gitpotassco/clingoDL/build/bin/libclingo-dl.so]
10,940,429,862  clingo/clasp/clasp/solver_types.h:Clasp::ClingoAssignment::value(int) const
 7,294,091,326  clingo/libclingo/src/control.cc:clingo_propagate_control_assignment [/home/ostrowsk/work/krbiz/gitpotassco/clingoDL/build/bin/libclingo.so.3.0]
 7,294,091,326  clingo/clasp/src/clingo.cpp:Clasp::ClingoPropagator::Control::assignment() const [/home/ostrowsk/work/krbiz/gitpotassco/clingoDL/build/bin/libclingo.so.3.0]
 7,293,619,908  clingo/clasp/clasp/solver.h:Clasp::ClingoAssignment::value(int) const
 1,254,110,579  /build/glibc-77giwP/glibc-2.24/malloc/malloc.c:_int_malloc [/lib/x86_64-linux-gnu/libc-2.24.so]
 1,182,487,956  clingo/libgringo/gringo/utility.hh:Gringo::String::String(char const*)
 1,061,556,013  /build/glibc-77giwP/glibc-2.24/string/../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:__strcmp_sse2_unaligned [/lib/x86_64-linux-gnu/libc-2.24.so]
 1,029,900,309  clingo/libgringo/src/term.cc:Gringo::FunctionTerm::match(Gringo::Symbol const&) const [/home/ostrowsk/work/krbiz/gitpotassco/clingoDL/build/bin/libclingo.so.3.0]
 1,011,683,124  clingo/libgringo/gringo/utility.hh:Gringo::Symbol::createFun(Gringo::String, Potassco::Span<Gringo::Symbol>, bool)
   888,434,639  clingo/libgringo/src/symbol.cc:Gringo::Symbol::args() const [/home/ostrowsk/work/krbiz/gitpotassco/clingoDL/build/bin/libclingo.so.3.0]
   864,098,538  /build/glibc-77giwP/glibc-2.24/malloc/malloc.c:_int_free [/lib/x86_64-linux-gnu/libc-2.24.so]
   793,609,011  clingo/libgringo/src/term.cc:Gringo::FunctionTerm::eval(bool&, Gringo::Logger&) const [/home/ostrowsk/work/krbiz/gitpotassco/clingoDL/build/bin/libclingo.so.3.0]
   709,610,395  libclingo-dl/clingo-dl/propagator.hh:bool DifferenceLogicGraph<int>::add_edge<DifferenceLogicPropagator<int>::do_propagate(Clingo::PropagateControl&, Clingo::Span<int, Clingo::ToIterator<int> >)::{lambda(std::vector<int, std::allocator<int> > const&) [/home/ostrowsk/work/krbiz/gitpotassco/clingoDL/build/bin/libclingo-dl.so]
   672,178,680  /build/glibc-77giwP/glibc-2.24/nptl/../nptl/pthread_mutex_lock.c:pthread_mutex_lock [/lib/x86_64-linux-gnu/libpthread-2.24.so]
   635,318,853  clingo/libgringo/src/symbol.cc:Gringo::Symbol::createFun(Gringo::String, Potassco::Span<Gringo::Symbol>, bool) [/home/ostrowsk/work/krbiz/gitpotassco/clingoDL/build/bin/libclingo.so.3.0]
   635,099,287  clingo/libgringo/gringo/hash_set.hh:Gringo::Symbol::createFun(Gringo::String, Potassco::Span<Gringo::Symbol>, bool)
   593,171,375  clingo/libgringo/src/ground/instantiation.cc:Gringo::Ground::Instantiator::instantiate(Gringo::Output::OutputBase&, Gringo::Logger&) [/home/ostrowsk/work/krbiz/gitpotassco/clingoDL/build/bin/libclingo.so.3.0]
   573,535,599  clingo/libgringo/gringo/hash_set.hh:Gringo::String::String(char const*)

Looks like clingo-dl:check takes most of the time, but not actually the propagation (but there is not much going on besides the do_propagate method.

Marking as invalid and closing because it turned out to be a clingo-dl problem.


[upstream WRRLB] if all hosts weight equal reuse rrLB

Your question
https://github.com/mosn/mosn/blob/master/pkg/upstream/cluster/loadbalancer.go#L224
我觉得这里直接复用rrLB是一个比较好的处理方式，你们觉得呢？
i think reusing rrLB is a good choice，do you think so?
Environment

MOSN Version

Logs

Paste the logs you see.

👍


add init event

In order to use debug tool prosemirror-dev-tools we need access to ProseMirror view object. This PR add Editor component event init with this variable.

less than 15 minutes from pull request to merge 💪


Spire-server plugin config (alternate)

This patch enables end users to configure plugins in the the spire-server config.
Alternate approach to https://github.com/spiffe/helm-charts/pull/198

@kfox1111 please resolve the conflicts so we can review this in the context of the current chart offerings.

@marcofranssen Please come to a resolution of whether #198 or #227 is the solution to go forward with within a week, or propose an alternative. We have been deadlocked in this choice for more than a month, and currently Ken reports that you're not fully pleased with either solution.  It's ok to not like specific solutions, but we need a path forward because plugins are a thing we need to support.

See https://github.com/spiffe/helm-charts/pull/198#issuecomment-1618147499


add autest for post redirection

This is the test for #2766 .

[approve ci autest]

[approve ci autest]

It works now !


Render Def into Variable

Good day!
This is more of a question than an issue; I was wondering if there was any way to call a def, storing what it renders as a variable rather than rendering it to the output?
Something like:
<%def name="test()">
    asdf
</%def>

<%
    somevar = test()
%>

That pattern works just as you've written it. This code:
<%def name="header(arg)">
    my ${arg} def
</%def>

<%def name="more()">
    <%
        more_impressive = header("more impressive")
    %>
    ${more_impressive}
</%def>

<%
    impressive = header("impressive")
%>

${impressive}

${more()}

renders this:

Hello @bourke,
Thanks for the quick reply!  I believe that it might not be working quite as I was expecting; I believe what's happening is when the def's are called they're being rendered rather than their output being stored in the variables.  For illustration, the below:
<%def name="header(arg)">
    my ${arg} def
</%def>

<%def name="more()">
    <%
        more_impressive = header("more impressive")
    %>
    ${more_impressive}
</%def>

<%
    impressive = header("impressive")
    more_result = more()
%>

${impressive}

${impressive}

${more_result}

${more_result}

Renders the following:

    my impressive def

    my more impressive def

It's true that anything in the top level gets rendered, whether called as an expression or within a <% %> Python block. One way to achieve what you're after is to use the capture function as described here: https://docs.makotemplates.org/en/latest/filtering.html#buffering
<%def name="header(arg)">
    my ${arg} def
</%def>

<%def name="more()">
    <%
        more_impressive = header("more impressive")
    %>
    ${more_impressive}
</%def>

<%
    impressive = capture(header, "impressive")
    more_result = capture(more)
%>

${impressive}

${more_result}</h3

renders:

    my impressive def

    my more impressive def

You might also want to look at https://docs.makotemplates.org/en/latest/filtering.html#decorating as a way of capturing and enhancing a <%def>'s output.

That looks perfect, thanks!


How to detect unused application-elbs reliably?

I'm having a tough time trying to get Cloud Custodian to flag unused application ELBs, after some Googling I'm trying this approach:
  - name: find-unused-app-elb
    resource: app-elb
    filters:
      - type: metrics
        name: ConsumedLCUs
        days: 1
        period: 86400
        op: eq
        value: 0

I've confirmed that this metric exists in cloudwatch for my test app-elb, however when run the rule gets this error:
018-05-08 13:54:42,469: custodian.filters:WARNING CW Retrieval error: Parameter validation failed:
Invalid type for parameter Dimensions[0].Name, value: None, type: <type 'NoneType'>, valid types: <type 'basestring'>
I'm not sure how to correct that or even if this is the best approach, I could use some advice.

There's a bug here, we're not passing the dimensions for app load balancers correctly. I'll have a fix in trunk shortly.

@kapilt Thank you for the fix!


use "chore" commit styles

For example, "chore: bump version from $current_version to $new_version"

incl. updating .gitchangelog.rc section_regexps etc. to include chore

Include in the CONTRIBUTING docs


Crash on settings page open

Steps to reproduce:

go to Menu -> Settings

Expected result:

settings page is opened

Actual result:

Application crashed without crash log.

Application version: 2.0.0-beta1

Not reproducible in 2.0.0-beta3.