Add nx to package.json for npm run build to work

Problem
There seems to be issues with lerna when nx is not installed.

 There was a critical error when configuring the task runner, please report this on https://github.com/lerna/lerna
lerna ERR! Error: Cannot find module 'nx/src/utils/output'
lerna ERR! Require stack:
lerna ERR! -<EMAIL_ADDRESS>lerna ERR! -<EMAIL_ADDRESS>lerna ERR! - C:\code\microsoft-authentication-library-for-js\node_modules\lerna\index.js
lerna ERR! - C:\code\microsoft-authentication-library-for-js\node_modules\lerna\cli.js
lerna ERR!     at Function.Module._resolveFilename (node:internal/modules/cjs/loader:933:15)
lerna ERR!     at Function.Module._load (node:internal/modules/cjs/loader:778:27)
lerna ERR!     at Module.require (node:internal/modules/cjs/loader:1005:19)
lerna ERR!     at require (node:internal/modules/cjs/helpers:102:18)
lerna ERR!     at RunCommand.configureNxOutput (C:\code\microsoft-authentication-library-for-js\node_modules\@lerna\run\index.js:350:24)
lerna ERR!     at RunCommand.runScriptsUsingNx (C:\code\microsoft-authentication-library-for-js\node_modules\@lerna\run\index.js:201:10)
lerna ERR! lerna Cannot find module 'nx/src/utils/output'
lerna ERR! lerna Require stack:
lerna ERR! lerna -<EMAIL_ADDRESS>lerna ERR! lerna -<EMAIL_ADDRESS>lerna ERR! lerna - C:\code\microsoft-authentication-library-for-js\node_modules\lerna\index.js
lerna ERR! lerna - C:\code\microsoft-authentication-library-for-js\node_modules\lerna\cli.js

Added nx
npm install nx --save-dev

unfortunately rewrites a lot of package.lock, not sure how to make the changes have less of an impact.
Maybe another option is to include it in documentation as a dev dependency, to install nx globally or similar in https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/contributing.md#build-library
Or perhaps it is lerna that should have nx as a dependency? 😕

@bjorn-einar-bjartnes-4ss Can you open an accompanying issue please to enable further discussion around this; and try installing npx using "npx add-nx-to-monorepo" & see if it leads to large package-lock changes?

Will do.
The npx add-nx-to-monorepo I have to look into, I don't really know my way around these nx tools, so not sure what to answer. Tried to go with the default, and it still made a huge diff to package-lock
√ Which scripts need to be run in order?  (e.g. before building a project, dependent projects must be built.) · No items were selected
√ Which scripts are cacheable? (Produce the same output given the same input, e.g. build, test and lint usually are, serve and start are not) · No items were selected
√ Enable distributed caching to make your CI faster · Yes

I haven't had this issue but this seems like something lerna should address. I see that they've listed nx as a devDependency, if it's required to run their commands they should list it either as a dependency or a peerDependency

I have opened https://github.com/AzureAD/microsoft-authentication-library-for-js/pull/5533 which updates lerna to the latest and resolves this issue. Thanks all!


Remove empty, top-level, nodes in the Babel plugin

Looking at the built files you'll notice some lines containing nothing more than a semicolon. This is the result of (mostly top-level) if-statements, which include PDFJSDev-checks, that evalute to false during Babel parsing.
This has always annoyed me a bit, and looking at Babel plugin it seems that we can fix this simply by removing the relevant nodes.

/botio-linux preview

/botio test

Hey don't feel blocked on me in any way, but just fyi I plan to review these Babel-related PRs by Monday.


Reorganize checks to make them more flexible

As commented in #102, this PR tries to reorganize the checks prior to the materizalization of the scaffold structure.
They can be now splitted in 2 groups:

Pure option consistency checking
Checks that involve the underlying file system.

By postponing the second group, extensions have a chance to change the file system making it consistent before the check is done.
(In summary this PR doesn't change behavior, but add flexibility by reordering the actions)

Coverage remained the same at 96.527% when pulling e8b059b634c7fc30315eb11f9d3f35550901e8bb on abravalheri:make-checks-flexible into 2119ddb12c6ed20ff0d27d475298ece5683cfa26 on blue-yonder:master.

Thanks!


Adding ppc64le architecture support on travis-ci

Hi,
I had added ppc64le(Linux on Power) architecture support on travis-ci in the branch and looks like its been successfully added. I believe it is ready for the final review and merge. The travis ci build logs can be verified from the link below.
https://travis-ci.com/github/kishorkunal-raj/django-taggit/builds/190231738
Reason behind running tests on ppc64le: This package is included in the ppc64le versions of RHEL and Ubuntu - this allows the top of tree to be tested continuously as it is for Intel, making it easier to catch any possible regressions on ppc64le before the distros begin their clones and builds. This reduces the work in integrating this package into future versions of RHEL/Ubuntu.
Please have a look.
Regards,
Kishor Kunal Raj

Any views on the PR?

As discussed in https://github.com/jazzband/django-model-utils/pull/448 this is a no-go.


Base template seems to be broken

Describe the bug

After following the docs for boilerplate setup I am getting an error:
error: missing required argument 'id'

Expected behavior
Correct boilerplate setup

Current behavior
Currect base setup doesn't work

Possible solution

Steps to reproduce

Running:

npx<EMAIL_ADDRESS>my-website --package-manager yarn
using method with template https://github.com/PaloAltoNetworks/docusaurus-template-openapi-docs.git with copy option
cd into directory and run yarn run  gen-api-docs results in error: missing required argument 'id'

Screenshots

Context

Your Environment

Version used:
Environment name and version (e.g. Chrome 59, node.js 5.4, python 3.7.3):
Operating System and version (desktop or mobile):
Link to your project:

You need to run docusaurus gen-api-docs <id> with id being the id of the api spec configuration


Running on kde desktops.

Hi.
I know this may be out of scope, but how difficult would be running this on kde desktop?
If I install the flatpak it has tons of gnome dependencies, which I understand and I would be willing to install, just unsure if it will break my system.
(Running KDE Fedora)
Thanks

Hi!
I don't think it would break your system, at least I can't see why it would. It depends on the Gnome SDK, but this shouldn't lead to any conflict :)

I can confirm that it works.
The flatpak install had nearly a GB of dependencies, but I doubt you can do anything about that.
And it's missing an icon.
Minor inconveniences for using this awesome app.
Thanks

Cool! Glad this worked :) the upside is you won't feel bad about installing other gtk-based apps now :)


internal unhandled error when raising validation error from model clean()

I have got a semi-complex case of model inheritance and need to do some validation check on instance update/create and the best way for me to avoid duplication is to put it in the model clean (one shared at the top abstract parent) and others optional at the children, just to avoid some big code duplications on the serializer level per polymorphic child etc..
This worked flawlessly before but  since integrating drf-standardized-errors I've been getting the following error trace of internal error with no easy way to grasp what's happening because I can't tell which function called from DRF is being masked from this package.
class Order(TimeStampedModel):
    class Meta:
        abstract = True

    _safedelete_policy = SOFT_DELETE_CASCADE
    related = models.ForeignKey(Related, on_delete=models.CASCADE, null=False)
    all_objects = Manager()

    def clean(self):
        if not self.deleted and self.related.sub.is_condition:
            raise ValidationError(BusinessErrors.ORDER_IS_AFTER_DATE)
    def save(self, **kwargs):
        self.full_clean()
        super(Order, self).save(**kwargs)

class BuyOrder(Order):
    some_prop = models.IntegerField(null=False)
    def clean(self):
        super(Order, self).clean()
        if not some_condition:
            raise ValidationError(BusinessErrors.EXCEEDS_CREDIT_LIMIT)

Full trace:
ERROR    django.request:log.py:241 Internal Server Error: /orders/2/related/
Traceback (most recent call last):
  File "/opt/pysetup/.venv/lib/python3.9/site-packages/django/core/handlers/exception.py", line 55, in inner
    response = get_response(request)
  File "/opt/pysetup/.venv/lib/python3.9/site-packages/django/core/handlers/base.py", line 197, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/opt/pysetup/.venv/lib/python3.9/site-packages/sentry_sdk/integrations/django/views.py", line 90, in sentry_wrapped_callback
    return callback(request, *args, **kwargs)
  File "/opt/pysetup/.venv/lib/python3.9/site-packages/django/views/decorators/csrf.py", line 56, in wrapper_view
    return view_func(*args, **kwargs)
  File "/opt/pysetup/.venv/lib/python3.9/site-packages/rest_framework/viewsets.py", line 125, in view
    return self.dispatch(request, *args, **kwargs)
  File "/opt/pysetup/.venv/lib/python3.9/site-packages/rest_framework/views.py", line 509, in dispatch
    response = self.handle_exception(exc)
  File "/opt/pysetup/.venv/lib/python3.9/site-packages/rest_framework/views.py", line 469, in handle_exception
    self.raise_uncaught_exception(exc)
  File "/opt/pysetup/.venv/lib/python3.9/site-packages/rest_framework/views.py", line 480, in raise_uncaught_exception
    raise exc
  File "/opt/pysetup/.venv/lib/python3.9/site-packages/rest_framework/views.py", line 506, in dispatch
    response = handler(request, *args, **kwargs)
  File "/home/myownproject/api/orders/views.py", line 80, in update_related
    buy_orders.save(related=related)
  File "/opt/pysetup/.venv/lib/python3.9/site-packages/rest_framework/serializers.py", line 731, in save
    self.instance = self.create(validated_data)
  File "/opt/pysetup/.venv/lib/python3.9/site-packages/rest_framework/serializers.py", line 703, in create
    return [
  File "/opt/pysetup/.venv/lib/python3.9/site-packages/rest_framework/serializers.py", line 704, in <listcomp>
    self.child.create(attrs) for attrs in validated_data
  File "/opt/pysetup/.venv/lib/python3.9/site-packages/rest_polymorphic/serializers.py", line 79, in create
    return serializer.create(validated_data)
  File "/opt/pysetup/.venv/lib/python3.9/site-packages/rest_framework/serializers.py", line 962, in create
    instance = ModelClass._default_manager.create(**validated_data)
  File "/opt/pysetup/.venv/lib/python3.9/site-packages/django/db/models/manager.py", line 87, in manager_method
    return getattr(self.get_queryset(), name)(*args, **kwargs)
  File "/opt/pysetup/.venv/lib/python3.9/site-packages/django/db/models/query.py", line 658, in create
    obj.save(force_insert=True, using=self.db)
  File "/home/myownproject/api/orders/models.py", line 90, in save
    self.full_clean()
  File "/opt/pysetup/.venv/lib/python3.9/site-packages/django/db/models/base.py", line 1502, in full_clean
    raise ValidationError(errors)
django.core.exceptions.ValidationError: {'__all__': ['ORDER_IS_AFTER_DATE']}

@ghazi-git correct me if I'm wrong. @codeforcesmeme The problem looks like a Django core ValidationError is being raise rather than a DRF ValidationError, hence why it's not handling the exception. Was DRF catching the Django core exception previously?

@GiancarloFusiello Thank you!! that's exactly it! Silly thing I missed it since I amd the one who wrote the code but had to deal with this after tests failing when I integrated drf-standardized-errors. Answering your question, yes it was handled before with vanilla DRF.
I will leave the ticket up to the maintainers if they think code validation exceptions should be handled as well or not, otherwise, feel free to close it.

@codeforcesmeme happy to help. FWIW, looking at DRF exception_handler it doesn't look like Django core validation errors are handled directly.

As GiancarloFusiello mentioned, django validation errors are not handled by this package because drf exception handler doesn't do that and this package acts as a customizable drop-in replacement for drf exception handler.
Still, if you want this package to handle django's validation error (or any other exception for that matter), you can follow this entry in the docs


Pending payments

Background
After some time i can not make further transactions within my lnbits instance
Your environment

version of lnd
LND 0.10.4-beta
which operating system (uname -a on *Nix)
Linux raspberrypi 4.19.118-v7l+ #1311 SMP Mon Apr 27 14:26:42 BST 2020 armv7l GNU/Linux
version of btcd, bitcoind, or other backend
see logs attached
any other relevant environment details
DynDNS and LetsEncrypt Setup without Tor

Logs:
https://termbin.com/nejz
Steps to reproduce
not sure:

common lnbits installation
enable self funding for invoice

tweak lndrest.py of lnbits: json={"payment_request": bolt11, "allow_self_payment": True}

create invoice and send from same wallet

Expected behaviour
The invoice should be paid or it should be blocked to pay your own invoice
Actual behaviour
no payments possible anymore
manual call lncli payinvoice  from console hangs

$ lndmanage lncli payinvoice lnbc11110n1p0n4edypp5w4syrwr45cd9njpd6fzmrvejafurzdua2nsddq5ptknf2y0rz26qdpqwe5kzgrvde3kc6fqwpshj6twwehkjcm9cqzpgsp5qyz3punehxnr6ct96as9l83cfu9xqzrzg60t6fmsnlm97cl8tjvq9qy9qsqjvhdttu8g0xpnlwqq8wwnljuv5nl5l293syf6gv5lx24upcvj7ehyjnl5yv2n5xd527xvaazwxrxeqmecmde8jcvyp66jtm2cw46pkqqejkaca
^CTraceback (most recent call last):
File "/home/admin/lndmanage/venv/bin/lndmanage", line 10, in
sys.exit(main())
File "/home/admin/lndmanage/venv/lib/python3.7/site-packages/lndmanage/lndmanage.py", line 521, in main
lncli.lncli(args_list[1:])
File "/home/admin/lndmanage/venv/lib/python3.7/site-packages/lndmanage/lib/lncli.py", line 49, in lncli
stderr=subprocess.PIPE,
File "/usr/lib/python3.7/subprocess.py", line 474, in run
stdout, stderr = process.communicate(input, timeout=timeout)
File "/usr/lib/python3.7/subprocess.py", line 939, in communicate
stdout, stderr = self._communicate(input, endtime, timeout)
File "/usr/lib/python3.7/subprocess.py", line 1681, in _communicate
ready = selector.select(timeout)
File "/usr/lib/python3.7/selectors.py", line 415, in select
fd_event_list = self._selector.poll(timeout)
KeyboardInterrupt

ok seems the self funding attempts are blocked:
[lncli] rpc error: code = Unknown desc = self-payments not allowed

Closing as it seems to be resolved?


MAT-2 Match elevation of components with material ui

Issue Link

https://fullstacklabs.atlassian.net/browse/MAT-2
Checklist:

[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed locally.

@JramR7 Looks good!


MKL 2021 version with conda setup not working

Hi,
In my understanding, the wrapper tries to find the file mkl_rt.dll but the MKL installation on conda (2021.2.0) does not have any file with that name. The closest I could find is mkl_rt.1.dll. I get the following error when I try to import sparse_dot_mkl :
ImportError: mkl_rt not found. Have you faced this issue? Maybe this is Windows specific?
Thanks for helping out!

I'll look into it, although I'd be very surprised if MKL changed the library name intentionally. (It would have to be windows specific as DLLs are windows libraries)
Can you provide the conda environment yaml?

@asistradition Thanks for looking into this! Fwiw it worked on Ubuntu for me. Here is the environment yaml on Windows:
name: test
channels:
  - conda-forge
  - intel
  - defaults
dependencies:
  - blas=1.0=mkl
  - ca-certificates=2020.12.5=0
  - certifi=2021.5.30=py39haa95532_0
  - intel-openmp=2021.2.0=haa95532_616
  - libprotobuf=3.16.0=h7755175_0
  - mkl=2021.2.0=intel_296
  - mkl-service=2.3.0=py39h2bbff1b_1
  - mkl_fft=1.3.0=py39h277e83a_2
  - mkl_random=1.2.1=py39hf11a4ad_2
  - numpy=1.20.2=py39ha4e8547_0
  - numpy-base=1.20.2=py39hc2deb75_0
  - pip=21.1.2=py39haa95532_0
  - python=3.9.5=h6244533_3
  - python_abi=3.9=1_cp39
  - setuptools=52.0.0=py39haa95532_0
  - six=1.15.0=py39haa95532_0
  - sqlite=3.35.4=h2bbff1b_0
  - tbb=2021.2.0=vc14_intel_371
  - typing-extensions=<IP_ADDRESS>=hd8ed1ab_0
  - typing_extensions=<IP_ADDRESS>=pyha770c72_0
  - tzdata=2020f=h52ac0ba_0
  - vc=14.2=h21ff451_1
  - vs2015_runtime=14.27.29016=h5e58377_2
  - wheel=0.36.2=pyhd3eb1b0_0
  - wincertstore=0.2=py39h2bbff1b_0
  - zlib=1.2.11=h62dcd97_1010
  - pip:
    - onnx==1.9.0
    - pandas==1.2.4
    - protobuf==3.17.3
    - python-dateutil==2.8.1
    - pytz==2021.1
    - regex==2021.4.4
    - scipy==1.6.3
    - sparse-dot-mkl==0.7.1

Awesome; it's not just you, I can replicate this. Looks like the mkl dll is indeed renamed from mkl_rt.dll to mkl_rt.1.dll in the newest conda release of mkl 2021.
The fix is trivial (this isn't the only package affected: https://github.com/brightway-lca/brightway2-calc/issues/36) so I'll try to get it done ASAP.
Thanks!

Looks like mkl_rt.1.so is the new name for the oneMKL libraries; the osx and linux packages all symlink mkl_rt.so to it so there's no issues, but windows doesn't and of course the library pattern-matching in ctypes.utils.find_library doesn't work on windows either.
Pushed a fix in 86228d0d7b5d7dc728426dc5eec1adba15e5a7c8 and released it as v0.7.2.
Thanks!


Working around cytoscape error messaging

EDIT: This was a misguided ticket that misunderstood the issue at hand. I now realize it's about parsing the error messages from a primary dependency of the project, cytoscape.js.
On MacOS Firefox Developer Edition 98.0b6
This bug causes the renderer to crash (but doesn't happen when the tutorial window is open)

```

After some more playing, this doesn't appear to be an issue when creating a new chart - only when adjusting the default example.
Also appears to be an issue in Chrome

@ikesau You're getting an error because line 11 is expecting to find a target 1 – this will look for either a line with ID [1] (like this) or a line with the label 1 (like this), or this node on the line number 1 (like this). In your case none of those three exist, so it's telling you it doesn't know which target node to draw the edge to.

Let me know if that doesn't cover it or if the bug is related to the tutorial window.

Oh god If only I'd actually read the example.  Sorry for the drive-by ticket. 🤦
Two things then:

looks like cytoscape.js uses the french spelling of existent
The error message reads extremely "programmatically generated by some dependency" which is why I assumed it wasn't my fault 😅 - if we can't change their messaging, could we possibly add some "here's the culprit" line highlighting?

looks like cytoscape.js uses the french spelling of existent

I never caught that- weird!
I totally agree that we need some more human-readable error messages. I've made a task for myself and I'll leave this open until it merges.
Thanks!

@ikesau Going to close this one because error messaging got a little improvement in the last cycle. https://twitter.com/tone_row_/status/1505931806469677063
Thanks for opening!


i2c_mspm0g3xxx: scl stuck: disable target wakeup

Based on TI's comment:
It turns out that we have an errata with the target low-power wakeup feature, which can cause the target to hold the SCL line low indefinitely.
After multiple 10+ min tests, i could not reproduce the issue

It turns out that we have an errata with the target low-power wakeup feature, which can cause the target to hold the SCL line low indefinitely.

Do they have a published version of this (and other known) erratas?

Guessing this might refer to I2C_ERR_03 from this https://www.ti.com/lit/er/slaz742a/slaz742a.pdf?ts=1710415460794&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FMSPM0G3107 ? (you may include the link in the commit message if this is true)


[FEATURE]:  Page Espace personel

Is your feature request related to a problem? Please describe.
No response
Describe the solution you'd like
Page espace personel avec les documents
Describe alternatives you've considered
No response
Acceptance Criteria

[ ] Criteria 1
[ ] Criteria 2

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Ticket traité


2.x post collections

@jarednova @gchtr OK, let's try this again. This is the second attempt at addressing #2308. This is a continuation of #2310 which messed up the history of the branches with a bad merge.
Summary
Right now, the logic for building and running WP_Querys is spread around PostQuery, PostGetter, QueryIterator, and elsewhere. Part of the goal of Factories is to consolidate all of that logic in one place: PostFactory. To allow that, PostQuery needs to give up some power, because right now it queries for posts itself via PostGetter::query_posts(). But if the Factory already knows what it's dealing with, there's no need for this - the factory can simply instantiate a WP_Query directly and wrap it with a PostQuery. Then there's exactly one class responsible for querying for collections of posts.
What this means

As of this PR, PostQuery now extends ArrayObject directly and implements the PostCollectionInterface.
This means we can also get rid of the PostCollection class completely - just need to make sure the ::maybe_set_preview() logic makes it out of there.
I think we can get rid of QueryIterator. More on that below.
No more direct instantiation of Timber\PostQuery except when passing a WP_Query.
I think we can do away with the array wrapping the WP_Query in an array (i.e. [ 'query' => $wp_query ]) when passing to the constructor. The post_class option is a precursor to the new Class Maps design and the merge_default seems like something that would better be implemented as an option to Timber::get_posts().
As a nice bonus, we can save on performance and insantiate Posts inside of collection lazily, meaning while we already have the WP_Post objects they wrap, the Timber\Post instances themselves are not actually created until they're needed. See PostsIterator for how this works.
Finally, we can completely get rid of PostGetter. I want to be careful here as a lot of high-level functionality expected from the Timber class is tested at the level of PostGetter instead, so I just want to be extra mindful about keeping that test coverage without lifting redundant tests up to the Timber level.

A note about QueryIterator
As far as I can tell, this class has four responsibilities:

Implementing logic around WP_Query that (mostly) lives in PostFactory now
Of the special query logic mentioned above, the stuff that doesn't live in PostFactory are various query filter callbacks, namely fix_number_posts_wp_quirk, fix_cat_wp_quirk, and handle_maybe_custom_posts_page. This stuff should probably be moved
Implementing a way to iterate over and count WP_Query results, which we already have in PostQuery.
Creating Pagination objects, which again, we can do directly in PostQuery (which is added in this PR).

If I'm missing something here and we need this class after all, please let me know! But if we can move out the logic we want to keep I'm hoping we can just get rid of it.
The Plan
This PR isn't quite ready to merge but it seemed like a good stopping point to have this wider design discussion, since the high-level pieces are there. But quite a few tests are broken or skipped. I imagine I'll keep skipping many of them until I'm able to switch the Posts API altogether to using Factories, but some are probably easy fixes.
I'm leaning towards getting this to a good transitional point with Collections and merging this in then, before fully switching to Factories. Just don't want the PR to get too huge. Thoughts?

ORIGINAL COMMENT FROM @gchtr 2020-08-17 https://github.com/timber/timber/pull/2310#issuecomment-675060199
Up until here, what you write makes sense to me. But I also have to say that the exact inner workings of all the classes that are in involved here were always a bit hard to keep track of for me. So if we can reduce the complexity here, that would be great 👍.

* I _think_ we can do away with the array wrapping the `WP_Query` in an array (i.e. `[ 'query' => $wp_query ]`) when passing to the constructor. The `post_class` option is a precursor to the new Class Maps design and the `merge_default` seems like something that would better be implemented as an option to `Timber::get_posts()`.

Yes! I think I already partially worked on this in #2145. Maybe you could build on that.

* As a nice bonus, we can save on performance and insantiate Posts inside of collection lazily, meaning while we already have the `WP_Post` objects they wrap, the `Timber\Post` instances themselves are not actually created until they're needed. See `PostsIterator` for how this works.

Doesn’t this have big implications on caching if the actual work is only done after fetching cached posts in PHP templates during Timber::render() or earlier?
And then this is probably also related to handling posts in multisite environments (see #1434 and #2207).
And from what I see in issues and StackOverflow questions, a lot of developers are relying on dumping post objects to see what’s in there. This of course wouldn’t be reliable anymore. I’m not saying I wouldn’t add lazy-loading, but we need to check what it means for other parts of Timber and probably add documentation about this in various places.
A related example: we already fetch meta values lazily. A lot of developers were used to work with {{ dump(post.custom) }} to see what’s there. Now, this won’t work anymore. See https://timber.github.io/docs/v2/guides/custom-fields/#accessing-all-meta-values.

If I'm missing something here and we need this class after all, please let me know! But if we can move out the logic we want to keep I'm hoping we can just get rid of it.

I’m all in favor of simplifying this. What I figured when doing more complex stuff with iterators is that as soon as we have factories ready, we can move some logic regarding globals into Post::setup() method.
One specific example is this class: https://github.com/mindkomm/timber-integration-woocommerce/blob/master/lib/ProductsIterator.php. We discussed this in https://github.com/mindkomm/timber-integration-woocommerce/issues/6. With factories, we can get rid of it completley and a WooCommerce product object might solve WooCommerce globals like this:
class Product extends Timber\Post {
    public function setup( $loop_index = 0 ) {
        parent::setup( $loop_index );

        wc_setup_product_data( $this->ID );

        return $this;
    }
}

</ORIGINAL COMMENT>

I think I already partially worked on this in #2145. Maybe you could build on that.

Awesome! I will take a look there, thanks!

Doesn’t this have big implications on caching if the actual work is only done after fetching cached posts in PHP templates during Timber::render() or earlier?

I don't think I understand what you mean. :) Which code are you referring to as "fetching cached posts," and how is that affected by this change?
I agree we'd want to document the effects of the change if it actually affects the behavior of the API. But as far as I can tell this will be completely transparent to the caller. That is, by the time you have a post var within a Twig template, you've already done all the work that's needed. And, to be clear, this only affects how Posts are instantiated in PostQuery for now; in every other context they're instantiated eagerly. So I'm not sure why {{ dump(post.custom) }} wouldn't work.
Again, maybe I'm missing something...wouldn't be the first time. :) I'm also cool with being cautious and reverting the lazy instantiation piece for now. If I'm right and it's truly transparent, that means we can roll it out after 2.0 lands.

I’m all in favor of simplifying this. What I figured when doing more complex stuff with iterators is that as soon as we have factories ready, we can move some logic regarding globals into Post::setup() method.

Makes sense to me! Good idea.

Coverage decreased (-0.4%) to 89.76% when pulling 364a8bfea06222cf8067964a4520ed2c42c088fa on 2.x-post-collections into b0d086a363fe4addda60cd104df855cb790c554a on 2.x-factories.

@gchtr gotcha. I looked into this and you're right about {{ dump(posts) }} (plural) - it will be the uninstantiated version. I assumed it would implicitly iterate over the internal array but I was wrong. We should be able to override this behavior by implementing a custom __debugInfo() method. Unfortunately, due to a bug in PHP <= 7.3, this is not possible when extending SPL classes like ArrayObject. So we should definitely document this somewhere.
The good news is that JSON serialization and on-demand eager instantiation are both easy to implement. See latest updates, particularly the realize() method. I'm borrowing terminology from Clojure, which has various flavors of laziness built in. Dumping individual posts when iterating or indexing directly (i.e. $coll[0]) will perform as expected because those instances are realized.
Quick aside about your multisite example - it got me thinking so I wrote up #2312 .
Feeling much better about the state of this PR now. I'd still like to get @jarednova's input on the general direction, but for now my only remaining question is: should I also implement laziness on PostArrayObject? It would be pretty simple, and the biggest hurdle is just implementing a custom ArrayIterator that does the same thing as PostsIterator minus the WP loop stuff. Unless you see a reason not to?

hey @acobster — it's so close I can taste it! First off, I'm in big favor of retiring PostGetter (is TermGetter already retired from the previous PR?). I think the answers that you and @gchtr have come to on the details all feel well reasoned and utilize a lot of PHP stuff I wasn't even aware of (extending JsonSerializable? get outta here!). I really appreciate borrowing familiar terminology from other languages/libraries where we can. It shows a rigor and maturity to our own humble library here that we can pull from these best practices and make WordPress development every bit as sophisticated.
My points/questions are pretty limited around ...
Laziness:
I want to ensure we're not losing site of the use-case for "from what I see in issues and StackOverflow questions, a lot of developers are relying on dumping post objects to see what’s in there." This is definitely a frequent development/debug pattern that I go through, I guess I'm not alone. Is the custom __debugInfo() method you mentioned in your most recent comment the resolution of this? (I'm not bothered by the idea of PHP 7.4 being required for the optimum experience.)
One path worth considering here is whether using the WP_DEBUG flag is helpful to assist with outputting as much useful data as possible in var_dump() while not compromising on performance when a site goes live.
Should I also implement laziness on PostArrayObject?
Where we can, I think we should be consistent. So if lazy is the way to go in one place, we should go in the other place too (if it indeed proves possible with a custom ArrayIterator).

Whoa, I just looked at the code again yesterday when you pushed these new commits.
And my reaction was pretty the same as Jared’s: 👀 👀 👀 GET OUTTA HEEEERE! 😄. I wasn’t even thinking about providing a solution with code!
Debugging

@gchtr gotcha. I looked into this and you're right about {{ dump(posts) }} (plural) - it will be the uninstantiated version. I assumed it would implicitly iterate over the internal array but I was wrong. We should be able to override this behavior by implementing a custom __debugInfo() method. Unfortunately, due to a bug in PHP <= 7.3, this is not possible when extending SPL classes like ArrayObject. So we should definitely document this somewhere.

So, we should definitely work on documentation for the following points:

You need to be careful when dumping collections, because they are lazy.
The custom debug info only works with PHP 7.4+.
As a workaround, we can dump single posts inside the loop.

Serialization

The good news is that JSON serialization and on-demand eager instantiation are both easy to implement. See latest updates, particularly the realize() method. I'm borrowing terminology from Clojure, which has various flavors of laziness built in. Dumping individual posts when iterating or indexing directly (i.e. $coll[0]) will perform as expected because those instances are realized.

Sounds good to me 👍.
So the idea is to define a custom jsonSerialize() method for a custom post class to define which data is serialized? I think I can build on your example in tests/php/SerializablePost.php.
And when describing this feature, we need to probably mention that realizing doesn’t automatically fill all values you need, because a lot of methods in Timber::post() only load values when you call them.

Should I also implement laziness on PostArrayObject?
Where we can, I think we should be consistent. So if lazy is the way to go in one place, we should go in the other place too (if it indeed proves possible with a custom ArrayIterator).

Currently, I think this is the right way to go. Same with the rest of this pull request. Just some smaller details I’m going to comment directly in the review.
@acobster Do you want me to take a stab at the documentation for this so you can continue working on everything else that the factories still need?

@acobster Do you want me to take a stab at the documentation for this so you can continue working on everything else that the factories still need?

Just saw your updates in https://github.com/timber/timber/commit/b75f17d44caf46c4e22774727a84018a4a962d6a. Thanks!!! I will have a look at those 👍.

@jarednova

First off, I'm in big favor of retiring PostGetter (is TermGetter already retired from the previous PR?)

Awesome, and yes, I believe so. That's my plan in any case. I'll follow up with an issue for THE PURGE once the final API is solidified.

I really appreciate borrowing familiar terminology from other languages/libraries where we can. It shows a rigor and maturity to our own humble library here that we can pull from these best practices and make WordPress development every bit as sophisticated.

Thanks, appreciated that feedback! :smile:

Is the custom __debugInfo() method you mentioned in your most recent comment the resolution of this?

Yes, in short:
// these will work
{{ dump(posts[0]) }}
{% for post in posts %}{{ dump(post) }}{% endfor %}

// this will NOT work in PHP <= 7.3
{{ dump(posts) }}

// this will work in any version
{{ dump(posts.realize) }}

One path worth considering here is whether using the WP_DEBUG flag is helpful to assist with outputting as much useful data as possible in var_dump() while not compromising on performance when a site goes live.

IIRC the dump Twig function only works if WP_DEBUG is falsey? Or are you talking about explicitly realizing posts internally if WP_DEBUG is truthy? Definitely an avenue worth exploring, I'd just want to be careful because it could lead to an implicit dependency on environment-specific behavior, and suddenly it doesn't work in production and we've created more confusion than we've solved. :stuck_out_tongue_closed_eyes:
@gchtr

So, we should definitely work on documentation

Yes! I just pushed a big update to the Posts guide with details about collections and laziness. Would love support on filling in the gaps!

So the idea is to define a custom jsonSerialize() method for a custom post class to define which data is serialized? I think I can build on your example in tests/php/SerializablePost.php.

Yeah, in addition to providing some sensible default behavior in Timber\Post (I just wanted to avoid touching Post too much in this PR, and just focus on collections). Child implementations can easily call parent::jsonSerialize() to get the data to use as a basis, so we should capture that in the docs.

And when describing this feature, we need to probably mention that realizing doesn’t automatically fill all values you need, because a lot of methods in Timber::post() only load values when you call them.

Excellent point. It probably makes sense to implement to_array() and realize() at the post level, as well as a way for users to do this recursively in a single call, e.g. $collection->realize($deep = true). That intersects with https://github.com/timber/timber/issues/2312 - we should definitely try to provide a consistent experience across all instances of laziness.
Moving forward, I'll implement laziness in PostArrayObject and hopefully have something by tomorrow. In the meantime looking forward to seeing your notes.
Thanks guys!!! We're getting there! :tada:

@gchtr @jarednova I think I was mistaken and we actually do want to use exactly the same logic from PostsIterator for both kinds of Post Collections, to abstract over The Loop. Right?? This is how PostCollection currently works. What's different between the two is mainly pagination and origin (WP_Query vs a vanilla array).
If that's the case, it's good news because it means there's even less to implement, and the latest few commits should round this out!

I really really like the way we’re going here 🎉

One path worth considering here is whether using the WP_DEBUG flag is helpful to assist with outputting as much useful data as possible in var_dump() while not compromising on performance when a site goes live.

IIRC the dump Twig function only works if WP_DEBUG is falsey? Or are you talking about explicitly realizing posts internally if WP_DEBUG is truthy? Definitely an avenue worth exploring, I'd just want to be careful because it could lead to an implicit dependency on environment-specific behavior, and suddenly it doesn't work in production and we've created more confusion than we've solved. 😝

I wouldn’t do that either, because I already see new issues popping up because of it.

Yes! I just pushed a big update to the Posts guide with details about collections and laziness. Would love support on filling in the gaps!

I looked at it, very nice! Thanks man!

Yeah, in addition to providing some sensible default behavior in Timber\Post (I just wanted to avoid touching Post too much in this PR, and just focus on collections). Child implementations can easily call parent::jsonSerialize() to get the data to use as a basis, so we should capture that in the docs.

Right, good idea! We should definitely also have an example that explains that removing data would make sense, too, because you don’t want to fill the HTML of a page with data that has to be downloaded but that you will never need.

@acobster I saw you removed the WIP label. Are we ready for a final review, or do you have more commits to come before me or @gchtr should do a deep dive?

@jarednova @gchtr yeah, consider this ready. I will follow up with a deprecation notice in PostQuery::get_posts(), but other than that I wasn't planning any more changes for this PR.

@gchtr correct, I did not.

@jarednova did you want to give this another look before I merge this?

@acobster almost! I wanted to investigate the remaining failing tests and caught an issue that I wanted to make sure you were aware of. In b0efe7d I made a few updates to fix some test deprecation notices (easy). However, the test for TestTimberContext::testPostsContextSimple() revealed that we need to handle for what's returned with the default Timber::context() call.
I didn't know if this was already tackled in another branch or PR so I created my own to demonstrate and (potentially/hopefully) resolve in #2315.
Can you review that and see if you agree with those changes? That seems to me to be the only last thing we need to tackle on this piece

@jarednova your changes absolutely make sense, and I'm actually already working on those in a separate branch built off of this one. I'm not going to merge it in to avoid merge conflicts, but I'll keep your PR open so you can verify against the new branch once I push it.

Great! In that case let's call this one 👍  — please do the honors of merging into the factories branch so we can follow along w that other stuff


M1 Mac issues

Comment:
Various reports of M1 Mac issues have come in https://github.com/stan-dev/cmdstanpy/issues/546
I am unable to test locally, some of them seem to be down to specific library versions.

Good day, still Im experiencing the issue with installation of "cmdstan" on my Mac m1. Pls see screenshot below.
Thanks.

I have the same problem on my M4 macmin.
RuntimeError: Command ['make', 'examples/bernoulli/bernoulli']
        error during processing No such file or directory

I think, this error is not No such file or directory but make: bin/stanc: Bad CPU type in executable.
I checked below:
$ cd $HOME/.cmdstan/cmdstan-2.36.0
$ make examples/bernoulli/bernoulli
--- Translating Stan model to C++ code ---
bin/stanc  --o=examples/bernoulli/bernoulli.hpp examples/bernoulli/bernoulli.stan
make: bin/stanc: Bad CPU type in executable
make: *** [examples/bernoulli/bernoulli.hpp] Error 1
$ echo $?
2

My make process returns status code 2, which is translated into  the message No such file or directory by Python's os.strerror().

I found same Issue in
Cmdstanr fails to install on Mac Ventura with M2 - “bad CPU” !?
In my case, softwareupdate --install-rosetta resolved the problem.
$ softwareupdate --install-rosetta
:
Install of Rosetta 2 finished successfully
$ install_cmdstan
:
Installed cmdstan-2.36.0
Test model compilation


Permission denied @ rb_sysopen

New Issue Checklist

[ ] Updated fastlane to the latest version
[ ] I read the Contribution Guidelines
[ ] I read docs.fastlane.tools
[ ] I searched for existing GitHub issues

Issue Description

Complete output when running fastlane, including the stack trace and command used

[INSERT OUTPUT HERE]

Environment

[INSERT OUTPUT HERE]

@ankitbhalla421 please provide at least a few information as we will otherwise not be able to help you


New function to create Identity with pre-defined ID (to be used in tests)

This new function can be used to create Spaces (and other objects) in our tests with OwnerID pre-defined in golden files.
As @kwk requested :)
The workflow would be:

Create a test identity with pre-defined ID equaled to the ID from the golden file.
Create a context with that identity.
Create a space using that context.
Compare the result with the golden file.
PROFIT

Codecov Report

Merging #1408 into master will increase coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1408      +/-   ##
==========================================
+ Coverage   60.26%   60.29%   +0.02%
==========================================
  Files         119      119
  Lines       11094    11094
==========================================
+ Hits         6686     6689       +3
+ Misses       3757     3756       -1
+ Partials      651      649       -2

Impacted Files
Coverage Δ

controller/workitem.go
82.87% <0%> (+0.69%)
:arrow_up:

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 833380b...ea86c7e. Read the comment docs.


Bug fix / stability PR for modm

updated to latest release of SDK, v1.0.0
fixes event grid topic and subscription naming violation bugs

@bhavenst @tznamena - @bobjac and myself have corrected all bugs along with template parameter validation. This upticks the version of MODM sdk reference along with the version that gets built for the two binaries.


Mark dist/ as generated code

Excluded from stats, hidden in diffs

https://github.com/github-linguist/linguist/blob/main/docs/overrides.md#summary
influences

Please consider building dist/ files in a workflow that uploads it to npm.
https://docs.github.com/en/actions/use-cases-and-examples/publishing-packages/publishing-nodejs-packages
(and remove dist/ from the repo)

Test command
git ls-files --cached | git check-attr --stdin --all


add null as cell type

Null is a valid cell type to pass into google charts, per the docs here: https://developers.google.com/chart/interactive/docs/gallery/areachart#stacking-areas

Thank @afholderman ! Merged.


cmd/compile: code motion doesn't recognize some loads

Around newproc/deferproc we decrement/increment the stack pointer by 12 bytes.  We then
do some code motion which moves instructions from outside this region to inside this
region (and vice versa?).  Instructions that are moved inside which refer to SP must
have their offsets adjusted by 12 bytes.  This is not done for some instructions.  See
https://golang.org/cl/139160043 for an example.

This is fixed by khr's change not to do funny stack adjustments around newproc and deferproc.


README.md to be created

There is no information in the README.md file. Introduction and License can be provided.

Currently undergoing review in #1.

Reopening until merge.

Resolved in #1.


chore: upgrade version to 5.7.3

Motivation:
chore: upgrade version to 5.7.3
Modification:
Describe the idea and modifications you've done.
Result:
Fixes #.
If there is no issue then describe the changes introduced by this PR.

Codecov Report

Merging #940 into master will decrease coverage by 0.13%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master     #940      +/-   ##
============================================
- Coverage     70.05%   69.91%   -0.14%
+ Complexity      818      816       -2
============================================
  Files           395      395
  Lines         16441    16441
  Branches       2580     2580
============================================
- Hits          11517    11495      -22
- Misses         3580     3593      +13
- Partials       1344     1353       +9

Impacted Files
Coverage Δ
Complexity Δ

.../main/java/com/alipay/sofa/rpc/common/Version.java
100.00% <ø> (ø)
0.00 <0.00> (ø)

...pay/sofa/rpc/transport/ClientTransportFactory.java
72.30% <0.00%> (-6.16%)
0.00% <0.00%> (ø%)

...ipay/sofa/rpc/server/bolt/BoltServerProcessor.java
64.17% <0.00%> (-5.23%)
0.00% <0.00%> (ø%)

...pay/sofa/rpc/client/aft/InvocationStatFactory.java
87.50% <0.00%> (-5.00%)
16.00% <0.00%> (-1.00%)

...ent/aft/impl/ServiceHorizontalMeasureStrategy.java
66.41% <0.00%> (-2.24%)
23.00% <0.00%> (-1.00%)

...ofa/rpc/registry/zk/ZookeeperOverrideObserver.java
39.34% <0.00%> (-1.64%)
0.00% <0.00%> (ø%)

...va/com/alipay/sofa/rpc/server/bolt/BoltServer.java
74.48% <0.00%> (-1.03%)
0.00% <0.00%> (ø%)

...ipay/sofa/rpc/tracer/sofatracer/RpcSofaTracer.java
88.65% <0.00%> (-0.93%)
0.00% <0.00%> (ø%)

...ay/sofa/rpc/client/AllConnectConnectionHolder.java
61.13% <0.00%> (-0.26%)
0.00% <0.00%> (ø%)

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 08e62c1...25c6873. Read the comment docs.


[Question] Widget's area access for handle click

Hi!
I'm trying to handle mouse clicks on widgets. I want to check if the mouse position is inside the element during the click event. However, I'm unsure how to determine the element's position in the terminal.
Is there a way to access the rendered element's inner area? Or is there another method recommended for this?
Thanks!

The WidgetRenderer has the Area:
    public function render(WidgetRenderer $renderer, Widget $widget, Buffer $buffer, Area $area): void;

So I guess if you have a custom widget (e.g. window) which has events propagated to it, you would be able to save the position in the last render and use that?
But honestly not 100% sure the best policy here. It would be worth finding an example in Ratatui or it's ecosystem and see if that can be implemented, and if not, then we can adapt the library to make it possible.

ok, it sounded familiar I made a POC for this and closed it for some reason:
https://github.com/php-tui/php-tui/pull/209
There was one change that was required, otherwise I guess that could be merged.

Nice, I like that feature. That's not exactly what I meant, but it's also great thing 😄
What I meant about, is for example accessing area of each of TitleWidgets from BlockWidget, and handling clicks on them.
I tried to find any ratatui example with this kind of interface. I checked yazi, because it has support for selecting directories by clicking on them. I don't know rust too much, but I think found that for the position of a list element they are using their own calculations, but to find which part of layout has been clicked, they are using values calculated by Layout. I see that in ratatui, Layout calculations are made before actual rendering and we can access them. I see also that php-tui also has Layout inside of a Grid, so I can try the same way 🚀
Here is also example from documentation that is calculating mouse position beyond rendering: https://ratatui.rs/examples/widgets/custom_widget/#_top
So I think I'll go this way and try to calculate positions and use them to handle clicks 😄
Thanks for help!

Yeah, that's right. Originally PHP-TUI did it the same way but then I introduced the GridWidget which allows widgets to be composed more "naturally" but in the process I think some power is lost.
You should be able to use the Layout exactly as Ratatui does ...
... but If you still want to use the Grid you can use the Buffer Widget  which provides you with the BufferContext from which you can get the current Area and Buffer (and then manually use the Layout)

Thanks! I managed to achieve that by creating a layout next to grid rendering, so I didn't have to change the way I'm building my UI right now. This is the result:
https://github.com/user-attachments/assets/8ae2cb87-1cf6-481a-be91-f70e240de815
Anyway, BufferWidget looks better for this case, so there's no reason to build the layout twice.
Actually I'm building that: https://github.com/mtk3d/LaraTUI to learn how to use php-tui and explore the possibilities of building such UI applications in PHP, based on reactphp. It's an experimental project, so it's not tested and has some bad patterns, but it has some diverse chellanging interface elements. If I have any feedback or ideas, I'll write them down here for sure 😄
At this point, I can say you've done a great job with this project! Thank you!

Looks great! Looking forward to seeing more


avoid running tests in CI for documentation changes

If you're knowledgable about Travis CI and/or GitHub integrations, this might be a good issue for you.  It's helpful even if you just tell me it's not possible!
What I'd like to do is this:
When changes are only documentation updates, only run the Markdown linter on Travis CI.  That means no tests, no code coverage, and for the love of Pete, no AppVeyor.
The command to run these checks would be npm start lint.markdown.
If AppVeyor must be asked to run a build, it should abort immediately with a result of success.
Code coverage won't be computed if the tests don't run on Travis CI.

You are saying that we dont need to run tests fro markdown changes or I understanded it wrongly ?

@tharun208 you do for now. The current GitHub setup requires running tests in order to squash/merge, even if all you did was update the README; this can take 30+ minutes for no benefit.

I'm on it. I think I might have something working shortly


Discrepancies with ecash balance and fees

Blake,
Whilst sending ecash via lightning address, it adds to the ecash balance instead of subtracting(ie: Blitz ecash balance is 100sats. Send 50sats to an LNURL. Receiving address confirms 50 sats. Blitz resulting ecash balance is 150 sats).
In addition, when broadcasting ecash transactions, it's all a bit obscure, not transparent. The platform claims to be 0 fees prior to broadcasting the transaction but checking the receipt afterwards reveals 5 sats fees per transaction.

Thanks for finding this I'll check it out tomorrow.

When you load back into Blitz does the balance correct itself?

Good catch, I'll see if I can add a better fee calculator.

I found the issue.  I updated the cashu-ts library and although I did some test transactions, I guess the transactions I did didn't need to create any new proofs. I re-uploaded the app under the same version so if you download the Android-v0.3.4-beta it should be fixed.

Superb!
eCash balance printed correctly within "Balance info" after the update.
Wallet Balances
"Total Balance" = LN sats + Lq sats + ecash sats
Is that correct? If so, it is showing more than I have, summing up the results from "Balance info" page.
On Fee
Despite the txticket showing a fee of 5 sats, the "Total Balance" does not accrue for it. I.E.:

Total Balance = 1000
send 100 via Ecash
new Total Balance = 900
sent transaction ticket prints: amount = 100; fee = 5

On line 26 of ..eCash/payments.js, I wonder if it is due to feeReserve (is true???) "else" 5. Being an ecash transaction it might just be empty somewhere upstream :
    const amountToPay = (feeReserve || 5) + amount;

So, on the balance infor page your total balance is being displayed correctly, but, on the homepage it is not? And, is the balance off only by fee amount?
 const amountToPay = (feeReserve || 5) + amount;

The 5 after feeReserve is not relevant and I should remove it. Since it's an or operator, if one value is true the entire condition is true) and feeReserve is always true so the 5 value is never returned.

What mintURL are you using so I can try and reproduce. Because in all the ecash payments I send, I only get fees of 1 to 2 sats.

The mint in question is https://mint.minibits.cash/Bitcoin. This was the only Cashu mint that I got to work back at 0.3.1.
Ran a few more tests, emptied the wallet, deleted the mint. The discrepancy on 'Total Balance' immediately went away.
Added two new mints (Coinos and LNW), ran a few more tests on both and it was flawless. The txtickets also showed correct values for the fee, which were zero. 'Total Balance' correctly accounted.
Added a new minibits mint and few tests. The 'Total Balance' this time was correct, so possibly some mishap with the proofs prior to the calculation correction.
However, the txticket problem persists and defaulting to 5 sats on minibits, even though it does not deduct from the correctly printed "Total Balance". You will easily reproduce it just by using minibits.
Perhaps it would be a little extra work, but have a look a the following draft. It would be intuitive to users if they saw their available balances for LN,LQ and Ecash at the "Sending Page", with the "Speed, Network and Fee" updated real time based upon the value input in "Amount to send".

In a sense, the "Available" field is a misnomer, because it will default to one of the three networks and it will not extract from the selected mint, whatever balance it has. To have an algo that could perform a complete withdrawal from all LN,LQ and Cashu wallets would be too much work at this stage, but perhaps having the values clearly printed of maximum spendable ( minus fees ) would prove a simple upgrade of functions you already built, empowering the life of the user without complicating or adding any steps.
Another factor I found was that there is a minimum balance of 5 sats for any transaction to be performed (on any mint). One should be able to technically attempt to zero their wallets without any dust, or minimum of 1-2 sats.
Overall, a great product and lots of work has obviously been put into it. Well done :))


New version: Reply button dangerous

Checklist

[X] I have used the search function to see if someone else has already submitted the same feature request.
[X] I will describe the problem with as much detail as possible.
[X] This issue only contains a request for one single feature, not multiple (related) features.

App version
6.601
Problem you are trying to solve
The Reply button used to allow one to choose between Reply, Reply to All and Forward. Now it just Replies to All. This is a backward step. People often Reply to All inappropriately. It should not be made easier to do so and there is no reason for this change.
Suggested solution
Revert to the button offering the choice of Reply, Reply to All and Forward.
Or at the least, allow one to set the button to behave that way in settings.
Dave
Screenshots / Drawings / Technical details
No response

It seems the default has been changed to Reply from the latest release.

This is a backward step. People often Reply to All inappropriately. It should not be made easier to do so and there is no reason for this change.

The same thing applies to "Reply". You don't want to accidentally exclude people from a conversation.
I'm not sure it makes sense to have a single default reply action. The suggested solution, forcing the user to think and decide what they want each time, is a good one. Alternatively, the default should be configurable. It's not at the moment.

v 6.602
The button default was changed to Reply, while ReplyAll is available under 3dots. This leads to inadvertant omission of recipients. Previous default was much more practical. When replying to a message with multiple recipients (which is what's needed in 90% cases) have to rememebr now that clicking the only button on screen will remove all, besides address listed in From. Please revert to previous default.

I think the best solution, as stated previously, and supported by @mattok , is that clicking the button should make you choose whether to reply, reply to all, forward, etc. - i.e. it should behave in exactly the way that clicking the three dots to the right of the button currently behaves. The three dots would then be redundant and should be removed. There shouldn't be a default action because whatever the default is, it's too easy to select the default without thinking, and regret it later.
Dave

I admitedly do not remeber what the previous version setting was. Whether it was a selection betwen ReplyAll/Reply or default to ReplyAll - it worked well. So, a reversal of the change or @mattok's suggestion will be a better approach than what current version offers.

So, I didn't notice that the default had changed here but was certainly annoyed by the result.
I think this is a few issues:

Yeah, you should be able to change the default betwene reply-all and reply-sender.
It should be easier to swap between those settings on reply.  Using ... is ok, but THunderbird has you do this by pulling down on a button next to reply and that is ideal here as well.  It SHOULDN'T have an extra "confirm" step, but it SHOULD be clear wherther yoi're going to do a reply-all or a regular reply and give you a good UX for changing it.
LIke Thunderbird, more metadata should be added to the composing window such that you can relatively easily switch between reply and reply-all at sending  time. I'm assuming that this kind of metadata can't easily be saved in the IMAP outbox (but I might be wrong on this; how does Thunderbird do this?) but at the very least you should be able to switch from a reply to a reply-all or vice versa without having to cancel and start again, instead it should say "reply" and then you can switch it to "reply all" in the sending pane itself to switch the recipient defaults out.

THis would also ease any issues with people accidentally clicking on reply rather than reply-all,as they could change the recipients more cleanly prior to the mail going out.

I find this frustrating as well, I just realized that I inadvertantly replied only to sender on a group conversation and left a lot of people hanging on information about a meeting. The change to the flow seems like change for the sake of change, for longtime users who have grown accustomed to being prompted after tapping the exact same reply icon, this is an easy mistake to make. Can you please at least make this configurable?


[blocked] update instructional text in Resource Templates find box

currently says "Enter id, label, URI, remark, or author"
Update to "Enter id, label, URI, author, group, or guiding statement"
do not do this until we can find by group (blocked by #3064)

I really prefer "guiding statement" for all


Add Vulkan A100 Stable Diffusion e2e to perf.iree.dev.

Request description
As we ship IREE to users who run Stable Diffusion would be good to catch performance regressions in perf.iree.dev.
Can we please add Stable Diffusion from SHARK to perf.iree.dev.
What component(s) does this issue relate to?
Other
Additional context
No response

Sure I can look into adding this. Can you point me to the model code? Currently perf.iree.dev supports TF and TFLite so those inputs are preferred.

This is the main entry point for the CLI. Once you setup SHARK we just have to call that with flags like in the example. We can make the script better suited for perf.iree.dev. Currently it is via Torch.
Adding @dan-garvey and @monorimet so we can add any flags required for you to use. We do plan to have a benchmark script ourselves for SD.

Thanks. We'll need to add PyTorch support into perf.iree.dev to get this running. I'll work on this first.

@pzread What is needed to get the Stable Diffusion model integrated? I see a couple of tasks here:

We are missing support for PyTorch models in perf.iree.dev. @powderluv if you can upload the nightly mlir file, it would be more straightforward for the benchmarking infra to pull that down.
AMD runners. I believe our benchmarking runners are Intel-based. @powderluv what gc instance would we need to run these benchmarks?

I believe @antiagainst is working on this https://github.com/openxla/iree/pull/13107

Clip and Unet is added right now. Need to also add VAE, pending https://github.com/openxla/iree/pull/12767.

closing as obsolete -- no actions planned now


Add uniswap contract to validation benchmarks

@j-mueller added traces for the uniswap contract in https://github.com/input-output-hk/plutus/pull/3370. This
PR adds them to the validation benchmarks.  There are still a few improvements that could be made to the benchmarking process, but these will be done later: see https://jira.iohk.io/browse/SCP-2379.

Pre-submit checklist:

Branch

[x] Commit sequence broadly makes sense
[x] Key commits have useful messages
[x] Relevant tickets are mentioned in commit messages
[x] Formatting, materialized Nix files, PNG optimization, etc. are updated

PR

[x] Self-reviewed the diff
[x] Useful pull request description
[x] Reviewer requested

Pre-merge checklist:

[ ] Someone approved it
[ ] Commits have useful messages
[ ] Review clarifications made it into the code
[ ] History is moderately tidy; or going to squash-merge

Here are the results on the benchmarking machine.


FieldArray remove and push immediately cause view not rerender

I have a method that remove a field from FieldArray and immediately add a field into FieldArray but the view is not rerender.
The state in redux is already updated to the new field when I look at the redux logger log.
  fields.remove(0);
  fields.push({ postId: 1 });

When I press on one of the input in the FieldArray, the FieldArray will only rerender.
After I read through the source code of ConnectedFieldArray.js,
I found that the shouldComponentUpdate method is preventing the FieldArray to rerender
const propsToNotUpdateFor = [
  '_reduxForm',
  'value'
]

    shouldComponentUpdate(nextProps) {
      const nextPropsKeys = Object.keys(nextProps)
      const thisPropsKeys = Object.keys(this.props)
      return nextPropsKeys.length !== thisPropsKeys.length || nextPropsKeys.some(prop => {
        // useful to debug rerenders
        // if (!plain.deepEqual(this.props[ prop ], nextProps[ prop ])) {
        //   console.info(prop, 'changed', this.props[ prop ], '==>', nextProps[ prop ])
        // }
        return !~propsToNotUpdateFor.indexOf(prop) && !deepEqual(this.props[ prop ], nextProps[ prop ])
      })
    }

the value of the FieldArray's Field has changed, but it is returning false due to this part" !~propsToNotUpdateFor.indexOf(prop)"

the value of the FieldArray's Field has changed, but it is returning false due to this part" !~propsToNotUpdateFor.indexOf(prop)"

@erikras
May I know what is the reason not rerender the FieldArray when value is changed?
I think that if the value is an object and it is changed, we should rerender the FieldArray right?

I think I'm having a similar issue: deleting the item at index 0 of a FieldArray using ArrayRemove is resulting in the right input in the redux store, but wacky, mismatched display on the page (deleted item remains, items below it end up with mismatched props!)

I'm also experiencing the same issue. Any workaround for this ?

I found a workaround for this one. Just dispatch the arrayPush function instead of using fields.push
fields.remove(index)
dispatch(arrayPush('form', 'field', productToAdd))

I believe the propsToNotUpdateFor portion (here) as @sckoh mentioned was introduced in #1578 to prevent rerendering of the FieldArray when its Fields' values are being changed (see the issue for details).
However, this causes problems if the array value's elements change and require render updates, which can result from insert, remove, swap, move etc. I personally am having trouble with getting swaps to appear correctly and consistently.

@erikras Could you offer some thoughts about this issue? I will be happy to create a PR if necessary to implement your suggestions if necessary.
My suggestion is to check value only for changes to the array length, or for changes to the order of the elements, in order to return true for shouldComponentUpdate.
Something like this:
var thisValue = this.props.value;
var nextValue = nextProps.value;

if (thisValue && nextValue) {
  if (thisValue.length != nextValue.length || thisValue.every(val => nextValue.some(next => deepEqual(val, next)))) {
    return true
  }
}

@dtipson that might be a key issue?

Hmm, you're exactly right (Math.random keys fix the problem, sort of).  Though not sure what else to use as a key because nothing else is inherently unique and indeed, because of how FieldArray works, I don't even have access to the data to create a starting hash.

Fix published in v6.6.0.

...and so your code breaks now...
https://github.com/erikras/redux-form/issues/2740


Do not overwrite existing witness hashes for a given block in the DB

Hm, just realized/noticed that we do not neatly handle what happens if we get different answers from different peers. We just overwrite the last witness-hashes at the same block. This would be especially bad if the second peer to send us the witness hashes gives us a list with one hash (to grief us). We also append the block to the witness history, so our history gets shorter than intended...
This might be a problem soonish, but I think it can be all handled in the witness db (storing and reading a union of all the hashes instead of overwriting the previous), so I don't think it needs to be fixed in this PR.
Originally posted by @carver in https://github.com/ethereum/trinity/pull/2103#discussion_r522516017

I can take a hack at this

So we need to be sure to handle any race conditions, like two hash sets being saved at roughly the same time, and they both read out an empty set of hashes for a given blockhash. So might need a lock.
Current plan is to return the union of all hashes reported by all peers. It's probably worse to collect not enough data than to collect too much. Someday we might have to deal with griefing by sending way too many hashes, but for now I think empty witness griefing is a bigger concern.
Someday we might want something like a Counter() of the hashes returned by all peers, but for now I think a simple union of the set is the best next step.


Add support for User Attribute Mapper

Add support for using the User Attribute Mapper

Thank you for your contribution.
Before merging I would like to understand what it does and how I can test it.
Seems to be related to a Keycloak feature I don’t know yet, can you explain it to me briefly or point to the relevant Keycloak documentation please ? Thanks again.


Version management in Cloud SDK

I started using the google-api-python-client in Google Cloud SDK, as the app-engine-python component, It appears they're using version 1.0beta7. That's the version named in the setup.py in their google-api-python-client folder.
Is it possible to get them to update? If not, has anyone run into this before and have a workaround?

You'll have to file a bug on their public issuer tracker here: https://code.google.com/p/google-cloud-sdk/issues


idp 4.x compatibility

The first public beta of idp 4.0 has been released:
https://shibboleth.net/downloads/identity-provider/4.0.0-beta1/
One note is that "third party plugins will absolutely need to be updated to be compatible with this release due to various low level API changes".
Are you guys going to update this storage plugin to work with idp 4? If so, any thoughts on a timeline?
Thanks...

Its on our agenda to talk about. Yes, we will update it to work with 4.x (and hopefully finish documenting and updating our plugin that provides Redis support), but we cannot yet give you a timeline. Obviously, depends a bit on the amount of work that it will entail, and availability. We'll try to get back as soon as we can on when we think we can get that done.

Cool, thanks.
redis you say? Hmm, that sounds interesting. hazelcast has been working fairly well, but their whole "free/commercial" split is kinda annoying and occasionally when restarting idp instances the cluster goes whacko and I need to stop all the nodes at once and then restart them one at a time 8-/. I'd definitely be interested in evaluating that; maybe you could update it for 4.0 first ;).
Thanks much...

@pbhenson Paul, just for your reference - Redis storage impl is here: https://github.com/UniconLabs/shibboleth-redis-storage-service

Not much to it compared to the hazelcast one, seems fairly simple. Hopefully easy to update for 4.x :). I probably won't try it with 3.x, but will definitely evaluate it as part of investigating a 4.x deployment. Depending on timing, the 4.x deployment might also coincide with management's insistence on moving our idp systems to the cloud .


Documentation defragmentation

We have three packages in this repo, and every package has a separate README with documentation. What do you think about moving all the documentation and instructions to the top-level README file?
We may create two sections, one for javascript and one for stylesheets, and common information for javascript (see #2) will need no duplication.

@dzhlobo I thought the same way, and there is one thing: the way how to install react/js linters isn't the same. So looks like it's better to store this particular part of the instruction in separate readmes.
But what comes to the adding something... maybe the top level is more suitable. As you said we should divide it into JS and style sections

@viscoze, I think it doesn't matter instructions are different, we still can have them in one README file. We may have a separate section for each linter.
It is pain to open multiple README files to read instructions.

@dzhlobo ok, I got you bothering. Let's summarize it.
Tension
It's pretty hard to find out how to install this linter, and it's just inconvenient to go to the whole readmes.
Solution
Move the installation to the top readme.
Let's do it this way: we will create a separate PR with this changes and then check if it's ok and better that it is now

@dzhlobo I've been thinking about having a separate section for each linter, and I don't think it's a good idea, because what comes to linters they have the same interface of configs (rules, plugins, etc.)


[RESOLVED] Interface eth0(): High error rate (>2 for 5m)

Problem started at 16:27:29 on 2023.06.14
Problem name: Interface eth0(): High error rate (>2 for 5m)
Host: S100-Primario
Severity: Warning
Operational data: errors in: 1, errors out: 0
Original problem ID: 28683
Event details in Zabbix: http://<IP_ADDRESS>/tr_events.php?triggerid=23483&eventid=28683

Problem has been resolved in 3m 0s at 16:30:29 on 2023.06.14
Problem name: Interface eth0(): High error rate (>2 for 5m)
Host: S100-Primario
Severity: Warning
Original problem ID: 28683


Choose a default browser for the app.

It would be nice if we could set a default browser to use when opening JIRA issues from the JiraStopWatch pannel.
Thanks
Mark

I'll look into this

@ECGroupIT Instead of making this a part of Jira StopWatch, you can install an application, that specialises in precisely this thing: https://bitbucket.org/gmyx/browserchooser2/wiki/Home
Make BrowserChooser your default browser, and then you can configure per URL, which browser to use.


Restructure the devguide for Jython

Not recommended for merging until free of CPython specifics.
We'd like a Jython devguide based on CPython's, but the problem is that the CPython one is:

shot through with CPython specifics we must replace, and
likely to keep improving (which we'd like to merge).

Here I've tried to guess which files only need minor change. Two strategies have been applied, depending on how CPython specific was the original file:

Where content applies to Jython, with simple edits, we keep the original file. The expectation is that subsequent merges will be automatic, or at leasst manageable manually.
Where extensive re-writing is needed we start a new "companion" file (e.g. buildbots_jy.rst) and we keep the original as a reference, and also as a target for merge operations we don't want to modify the Jython text.

The aim is to allow changes to be merged as the CPython devguide develops.
index.rst is an exception as it is the conventional start page and cannot be renamed even though change is extensive.

Well, it's not free of CPython specific text by any means, but I believe I've rescued all the text from @fwierzbicki's work and structured the guide suitably for our needs. Also, I want to see if I'm right that we are able to merge changes made to the CPython devguide, and what the process is ... which should be documented in the guide, of course. :)
I'll call PR done for now and merge soon.


4% performance regression on oltp_read_write

Bug Report
There is a 15%  performance regression on our oltp_read_write benchmark test

What did you do?

Run performance test daily

What did you expect to see?

None.

What did you see instead?

Version:
    tidb: c7c7b730e4159b08f970811cf0c2791a40a333ce(master)
    tikv: 9c387d5b45d1a8a0ebeda83bf2d0669499ed9d04(master)
    pd: 4d65bbefbc6db6e92fee33caa97415274512757a(master)

Compare:
    tidb: https://github.com/pingcap/tidb/compare/c7c7b73...c7c7b73
    tikv: https://github.com/tikv/tikv/compare/0c9669d...9c387d5b45d1a8a0ebeda83bf2d0669499ed9d04
    pd: https://github.com/pingcap/pd/compare/4d65bbe...4d65bbe

test-1: < oltp_read_write >
    * QPS : 34080.48 ± 0.0000% (std=0.00) delta: -4.06% (p=nan)
    * TPS : 1695.92 ± 0.0000% (std=0.00) delta: -4.05%
    * AvgMs : 150.93 ± 0.0000% (std=0.00) delta: 4.21%
    * PercentileMs99 : 215.44 ± 0.0000% (std=0.00) delta: 5.55%

What version of TiKV are you using?

https://github.com/tikv/tikv/commit/9c387d5b45d1a8a0ebeda83bf2d0669499ed9d04

How to reproduce

# prepare
$ mysql -h <IP_ADDRESS> -uroot -P4000 -e 'create database sbtest'
$ sysbench oltp_read_write --mysql-host=<IP_ADDRESS> --mysql-port=4000 --mysql-user=root --mysql-db=sbtest --db-driver=mysql --threads=32 --tables=32 --table-size=1000000 prepare

# run
$ sysbench oltp_read_write --mysql-host=<IP_ADDRESS> --mysql-port=4000 --mysql-user=root --mysql-db=sbtest --time=1800 --mysql-ignore-errors=all --report-interval=10 --db-driver=mysql --threads=256 --percentile=99 --warmup-time=600 --rand-type=special --tables=32 --table-size=1000000 run

@mahjonp thanks for adding reproduce steps.

@yiwu-arbug I'm not very sure but seems that enough long bench time(for instance, 30 minutes in our daily bench task) is a key factor to reproduce this regression. The bench time of our bench command isn't very long, so i'm afraid that it may hard to reproduce this problem through it.


Feature/Add a download popup

[ ] move handlers to the container
[ ] change bare input elements to components: https://github.com/Vizzuality/climate-watch/pull/563
[ ] add styles
[ ] add a feature flag (to turn off the modal completely)


Correction for raw affiliation BioEcoAgro - UMR transfrontalière INRAE 1158

Correction needed for raw affiliation BioEcoAgro - UMR transfrontalière INRAE 1158
raw_affiliation_name: BioEcoAgro - UMR transfrontalière INRAE 1158
new_rors: 003vg9w96;032v67m28
previous_rors: 003vg9w96
works_examples: W3027304222;W2969692068;W3111577489
contact: 77a2901b24e623b92130453b27476c0e:aa71abc177d3b0b488afb576705ab10d @ u-picardie.fr

This issue was accepted and ingested by the OpenAlex team on 2024-10-10. The new affiliations should be visible within the next 7 days.


Option to Prevent Prefab From Instantiating as a Child of CompisitionRoot

I have overridden the creation of the player objects for NetworkLobbyManager to use a GameObjectFactory before doing what it does. As a result the NetworkLobbyPlayer becomes a child of the CompisitionRoot. causing the following error to occur.
DontDestroyOnLoad only work for root GameObjects or components on root GameObjects.
UnityEngine.Networking.NetworkLobbyPlayer:Start()

I also bind the NetworkLobbyManager and it too becomes a child of the CompisitionRoot making me wonder if that is a problem as well. It doesn't warn in the console due to it calling DontDestroyOnLoad() in awake before becoming a child.

I actually think Zenject should be changed to not parent dynamically created objects to the CompositionRoot at all.  There isn't really a good reason for this anymore.  I'll make that change.

Ok I've made this change on the develop branch.  If you get a chance to try that let me know if that fixes your issue

Neat, that should help out.
One recommendation for this change is to include an example in the readme that overrides GameObjectFactory and sets the parent to something selected beforehand. I can see this change causing hierarchy clutter in play mode for dynamic objects that get created often.

One thing that I realized after making this change is that this could cause some potential issues with any gameobjects created by the GlobalCompositionRoot.  In that case, it is helpful to always parent new game objects to the GlobalCompositionRoot so that they do not get destroyed on scene changes.
This also led me to take another look at how injection on the scene works, and I realized there was a bug there that was causing some objects to be injected on twice, if those objects are loaded from another scene using DontDestroyOnLoad.
I've fixed this.  Now, when injection on the scene occurs, it will only inject on objects that are associated with the specific scene (or any decorated scenes) and will not inject on any DontDestroyOnLoad objects that have carried over.
There is also a flag on the SceneCompositionRoot that allows you to decide whether want to automatically parent new objects to it (note however that for the GlobalCompositionRoot there is no flag because this is required).  For the SceneCompositionRoot though it can be either and things should work fine.
Also, based on your last suggestion, I added an extra parameter to BindGameObjectFactory that allows you to pass a string that will be used to group the objects underneath an empty transform by that name

I believe ToTransientGameObject() and ToTransientPrefab() should also be given methods for parent grouping as well.

This is true

Hi,
I decided to post this here since it is related to the subject discussed, and the other related issue is already closed.
In my project I have created several prefabs that represent the screens and widgets in my GUI. I want to instantiate these prefabs as the user navigates, and to do so I have a Factory for each of them. For example:
public class LoginScreen : MonoBehaviour {
    [...]
    public class Factory : GameObjectFactory<LoginScreen> { }
}

In my installer I have this:
public GameObject loginScreenPrefab;
[...]
Container.Bind<ScreenFactory>().ToSingle();
Container.BindGameObjectFactory<LoginScreen.Factory>(loginScreenPrefab);

ScreenFactory is a class that centralizes the instantiation of these screens and widgets. I injected the factories for the different prefabs and created a method "CreateScreen (ScreenName name)" that uses the corresponding factory depending on the name received as parameter.
public class ScreenFactory {
    [Inject] readonly LoginScreen.Factory loginScreenFactory;
    [...]
    public GameObject CreateScreen(ScreenName name)
    {
        switch (name)
        {
            case ScreenName.LOGIN:
                return loginScreenFactory.Create();
                [...]
        }
    }
}

So far so good. The problem arises when I try to set the parent of the instantiated prefab. I have a Canvas already created in my scene and I want it to be the parent of the screens. Something like this:
GameObject nextScreen = screenFactory.CreateScreen(viewName);
nextScreen.transform.SetParent(mainCanvas.transform, false);

In the hierarchy I see that the prefab is successfully set as child of the Canvas, but I am also getting a NullPointerException. I tried in many ways and have also played around with the newly added flag "Parent to SceneCompositionRoot" and groupName optional parameter in BindGameObjectFactory, but nothing changes (passing a groupName still adds the prefabs SceneCompositionRoot).
I am pretty new to Zenject and I would really appreciate some help on solving this issue. Thanks in advance.

Where is the NullPointerException occurring?  Is it within Zenject and if so do you have a stacktrace?

The NullPointerException occurs in Unity. This is the stacktrace:
NullReferenceException: Object reference not set to an instance of an object
GuiController.GoTo (ScreenName viewName) (at Assets/Scripts/Gui/GuiController.cs:37)
GuiController.Start () (at Assets/Scripts/Gui/GuiController.cs:21)

Which corresponds to the call to SetParent on the instantiated prefab:
nextScreen.transform.SetParent(mainCanvas.transform, false);
This is the exact same error that would occur when trying to access the transform of a prefab loaded with Resources.Load. In this case we would solve it by calling Instantiate on the loaded prefab:
Instantiate (Resources.Load ("...")) as GameObject;

I can't think of what could be causing that.  Code seems fine.  Can you make a minimal example reproducing the issue and post the complete code somewhere?

Now this is odd. I prepared a simple project to reproduce the issue as requested, which is basically a copy paste of my project down to the simplest, and it works. So I think I'm going to start building on top of that and see how it goes.

And now I have it working on the original project as well. Reassigning the prefabs to the installer script is what did the trick. Sometimes I just love Unity... Thanks for your time Steve!


virtualbox__intnet option in Vagrantfile smashes vagrant-network.nix

Having this in Vagrantfile:
subconfig.vm.network "private_network", ip: "<IP_ADDRESS>", virtualbox__intnet: "mynetwork"
subconfig.vm.network "private_network", ip: "<IP_ADDRESS>"

makes a vagrant-network.nix:
{ config, pkgs, ... }:
{
  networking.interfaces = [
    {
      name         = "enp0s8";
      prefixLength = 24;
    }
    {
      name         = "enp0s9";
      ipAddress    = "<IP_ADDRESS>";
      prefixLength = 24;
    }
  ];
}

You see: The ip address is missing for enp0s8

@TheTesla looks like the vagrant/templates/guests/nixos/network template is expecting a network ip of explicit type static.
As to why the other entry works, unsure. I would wager it has to do with how vagrant is handling virtualbox__intnet in its implementation. If you add virtualbox__intnet: "mynetwork" to both statements do they both fail to inline an ip? That would be my expectation based on above hypothesis.
As for a workaround, give the following a try in your Vagrantfile:
subconfig.vm.network "private_network", type: "static", ip: "<IP_ADDRESS>", virtualbox__intnet: "mynetwork"
subconfig.vm.network "private_network", ip: "<IP_ADDRESS>"

If this works and you'd like to be fully explicit simply add another type: "static" to your second, non virtualbox__intnet, interface.


HDDS-10126. Remove maxFlushedTransactionsInOneIteration from OzoneManagerDoubleBuffer

What changes were proposed in this pull request?
The field maxFlushedTransactionsInOneIteration is not useful since it can be retrieved from the metrics.
We will also remove the unused (after HDDS-10026) OzoneManagerStateMachineMetrics.
What is the link to the Apache JIRA
HDDS-10126
How was this patch tested?
By updating the existing tests.

@duongkame , thanks a lot for reviewing this!


cf

Please provide a description of the issue. If nothing will be added, this issue will be closed in 7 days.


Error: [ng:areq] Argument 'HomePageController' is not a function, got undefined

Hi there,
Error: [ng:areq] Argument 'HomePageController' is not a function, got undefined
I am getting this error when i am loading my  HomePageController with  ocLazyLoad. But while loading file  directly into page it is working fine .
Here below i made a plnkr with my problem please look into this.
Open Code In plnkr

Hello,
just change assocAdmin to angular.module('assocAdmin') in your lazy loaded controller, because assocAdmin is a global variable that isn't available in the lazy loaded context :-)

@udaysurendra  you may read this question


Create the basic web layout

The header, menu and lateral panels need to be created.

Closed on commit ca3674076cb277b6766bb49f723f4f0572572689


ARROW-10183: [C++] Apply composable futures to CSV

@pitrou I believe this is ready for another review.  In addition to fixing your comments:

Removed rvalue version of Future::result() since this is unsafe (future does not own its result exclusively)
Moved the "Transfer" out of the "BackgroundGenerator" so it is explicit as per Zulip discussion
Fixed a bug in the transforming generator. It had a this capture that was not valid because the returned async generator pipeline could be moved around and callbacks might still be referencing this.
The TryAddCallback test would sometimes fail because it is not valid to do std::function<void(const Resultdetail::Empty&)> callback = &callback_adder_thread_id (the ... can't be assigned to a std::function in that way)

If I use the CPU thread pool for TaskGroup::MakeThreaded, I see no regressions between this and git master on a bunch of macro benchmarks (various real-world CSV files gathered from the Internet). Nice :-)

@pitrou It now runs on the CPU thread pool.  The I/O thread pool is sent down all the way into the table reader but is not yet used (I added ARROW-11590 for this).  When I tried to run it on the I/O thread pool it failed because there were multiple threads running the iterator.  The current behavior (dedicated single thread pool) matches the old behavior though so this isn't a regression.


Can not write to /var/jenkins_home/copy_reference_file.log. Wrong volume permissions?

I am getting "permission denied" error while running the docker container using mounted volumes, command used as below:
   $  docker run -p 8080:8080 -p 50000:50000 -v /jenkins:/var/jenkins_home jenkins:lts
Please note that /Jenkins is the host mount path/folder and “/var/Jenkins_home” is the container volume being mounted.
I observed that the container is using "jenkins" user with UID & GID being set to 1000. However on host the user ‘jenkins’ has different values for UID & GID.
Another problem is that UID=1000 is already being used for some other user on host VM.  Hence can't change the UID/ GID for the host ‘jenkins’ user.
As per the issues list on github;  many people have faced this issue and most of the places it has suggested to change the permission and owner of the host directory, using "chown -R 1000:1000 <host_mount_path> ".
However I think changing the permissions to some other user’s permission can cause issues on production and could lead to a security concern.
The better solution would be to accept argument for UID & GID while running the container. I have tried this approach by modifying the dockerfile locally and it worked fine for me.
Please let me know your comments/suggestions around this.
Thanks,
Meghali Dhoble

Thanks @carlossg for the response.  The solution at #177 helped me to get through.  i.e. using "- u <user_id>".
I was using "user_name" instead use of "user_id" helped. I think its worth mentioning this point, at the README page, as many of the users facing same issue.

@meghalidhoble note that #177 is also a workaround, aka not a durable solution. I described what is the recommended solution at https://github.com/jenkinsci/docker/issues/493#issuecomment-387722074

@batmat
I am getting following error after following your solution:
WARNING: Upgrading Jenkins. Failed to update the default Update Site 'default'. Plugin upgrades may fail.
java.net.SocketTimeoutException: connect timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at sun.net.NetworkClient.doConnect(NetworkClient.java:175)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:432)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:527)
at sun.net.www.http.HttpClient.(HttpClient.java:211)
at sun.net.www.http.HttpClient.New(HttpClient.java:308)
at sun.net.www.http.HttpClient.New(HttpClient.java:326)
at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1169)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1105)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:999)
at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:933)
at sun.net.www.protocol.http.HttpURLConnection.followRedirect0(HttpURLConnection.java:2662)
at sun.net.www.protocol.http.HttpURLConnection.followRedirect(HttpURLConnection.java:2584)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1770)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)
at hudson.model.DownloadService.loadJSON(DownloadService.java:166)
at hudson.model.UpdateSite.updateDirectlyNow(UpdateSite.java:176)
at hudson.model.UpdateCenter.updateDefaultSite(UpdateCenter.java:2181)
at jenkins.install.SetupWizard.init(SetupWizard.java:170)
at jenkins.install.InstallState$3.initializeState(InstallState.java:105)
at jenkins.model.Jenkins.setInstallState(Jenkins.java:970)
at jenkins.install.InstallUtil.proceedToNextStateFrom(InstallUtil.java:94)
at jenkins.model.Jenkins.(Jenkins.java:887)
at hudson.model.Hudson.(Hudson.java:85)
at hudson.model.Hudson.(Hudson.java:81)
at hudson.WebAppMain$3.run(WebAppMain.java:227)

@anmolmore15 AFAICT, this issue seems more related to some transient network problem than what I was talking about. Is this something you can reproduce? Thanks

I was getting the same error when I was trying to run jenkins on aws ECS-fargate and mounting the volume on EFS. I resolved this issue by changing the user in my Dockerfile to root.
USER root

Hi guys,
getting similar issue - i was trying mount my local-machine All jenkins configurations (including plugins, jobs, workspace) everything into a new jenkins container... No Luck!
[jenkins@ip-10-0-1-12 jenkins]$ chown -R 1001:1001 /home/jenkins/jenkins_home/jenkins
[jenkins@ip-10-0-1-12 jenkins]$ docker run -dit --name Jenkins_Container -p 8084:8080 -p 50000:50000 -v /home/jenkins/jenkins_home/jenkins:/var/jenkins_home jenkins/jenkins:lts-jdk11
57b867bc7a442f5b326153c9454bb8d4dc4989174338c5321d93f0b24ba0da1e
[jenkins@ip-10-0-1-12 jenkins]$ docker ps -a
CONTAINER ID   IMAGE                                            COMMAND                  CREATED         STATUS                     PORTS                                                           NAMES
57b867bc7a44   jenkins/jenkins:lts-jdk11                        "/sbin/tini -- /usr/…"   4 seconds ago   Exited (1) 3 seconds ago
[jenkins@ip-10-0-1-12 jenkins]$ docker logs -f 57b867bc7a44
touch: cannot touch '/var/jenkins_home/copy_reference_file.log': Permission denied
Can not write to /var/jenkins_home/copy_reference_file.log. Wrong volume permissions?


Add a wiki: Puella Magi Wiki

An anonymous user has submitted a new wiki via our submission form.
Link to origin wiki: https://madoka.fandom.com/wiki/Madoka_Magica_Wiki
Link to destination (independent) wiki: https://wiki.puella-magi.net/Main_Page

This has been added and will be released in v1.3.0


duqtools init now outputs commented yaml file

@stefsmeets  this adds comments to the duqtools init command, which is nice, but I wanted to see if you agree on the custom setup.cfg pydantic-yaml dependency

Also there might be a better way to add the descriptions, although the Field way seems to work fine

Thanks @v1kko , this is really cool! And it works well! Can you change the existing pyyaml imports to use ruamel.yaml instead?
Another thing (can be added later) is that it would be great if the comments could start on the line above, and wrap to let's say 80 characters so that we can have longer descriptions.

Agree, I'll make a new issue out of this


Allow anybody to remove a stale package

If the GitHub repo referenced by a Bower package is no longer accessible, anybody should be allowed to remove that Bower package.
This should resolve a number of the errors people are encountering on bower/bower#120. It also incidentally fixes #69.

I think both automation of deleting and allowing deletion for anyone if repo exists is too fragile. We can easily compromise whole registry this way. Closing this PR, please see: #110


Stay on the Release Train (Not sure if it should be separate from getting most out of a release

i would vote it's time to get off the release train and close this issue


[Bug] Gulp can't build the admin theme

Describe the bug
Gulp produces a faulty bundle JS and the admin area looks broken.
To Reproduce
Steps to reproduce the behavior:

Clone the main branch
Run gulp and complete the setup
Check the admin area

Expected behavior
The page should look fine and Gulp shouldn't display this error
Screenshots

Error messages
Gulp:
[gulp-chug] (src/bb-themes/admin_default/gulpfile.babel.js) Error in plugin "sass"
Message:
<EMAIL_ADDRESS>Error: @use rules must be written before any other rules.
      ╷
16651 │ @use "bootstrap";
      │ ^^^^^^^^^^^^^^^^
      ╵
<EMAIL_ADDRESS>16651:1  root stylesheet

Browser console:
Uncaught (in promise) Error: Element not found
    value http://localhost/bb-themes/admin_default/build/js/boxbilling-bundle.min.js?v=0.0.1:1
    value http://localhost/bb-themes/admin_default/build/js/boxbilling-bundle.min.js?v=0.0.1:1
    setPlotDataData http://localhost/bb-admin/index:812
    <anonymous> http://localhost/bb-admin/index:751
    i http://localhost/bb-themes/admin_default/build/js/boxbilling-bundle.min.js?v=0.0.1:1
    fireWith http://localhost/bb-themes/admin_default/build/js/boxbilling-bundle.min.js?v=0.0.1:1
    ready http://localhost/bb-themes/admin_default/build/js/boxbilling-bundle.min.js?v=0.0.1:1
    s http://localhost/bb-themes/admin_default/build/js/boxbilling-bundle.min.js?v=0.0.1:1

Desktop (please complete the following information):

OS: Fedora Linux (37)
Browser: Mozilla Firefox (104.0.2)

Additional context
If this is reproducible for everyone, I think this is an urgent issue.

Seems like it happened with the latest automated preview build too.

https://github.com/FOSSBilling/FOSSBilling/actions/runs/3104617057/jobs/5029296166#step:10:37

I was able to spot what caused this.
The latest Tabler update causes this. Let me see what particular change might be the cause.

As a temporary fix, I'll revert Tabler to the preview release until we get ready to use the latest one.

Reverted Tabler with #274.

Looks like we are already on the latest version of tabler, so this must have been fixed. Closing
https://github.com/FOSSBilling/FOSSBilling/blob/main/package.json#L15


Remove verification calls in startFlushUpgradeHandshake

closes: #4255
Commit Message / Changelog Entry
Pending the merging of PRs that add them in Try/Ack
chore: remove verification calls in startFlushUpgradeHandshake

see the guidelines for commit messages. (view raw markdown for examples)

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[ ] Targeted PR against correct branch (see CONTRIBUTING.md).
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Code follows the module structure standards and Go style guide.
[ ] Wrote unit and integration tests.
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/).
[ ] Added relevant godoc comments.
[ ] Provide a commit message to be used for the changelog entry in the PR description for review.
[ ] Re-reviewed Files changed in the Github PR explorer.
[ ] Review Codecov Report in the comment section below once CI passes.

Codecov Report

Merging #4317 (b963ebb) into 04-channel-upgrades (9d9fb4e) will increase coverage by 0.02%.
The diff coverage is 100.00%.

Additional details and impacted files

@@                   Coverage Diff                   @@
##           04-channel-upgrades    #4317      +/-   ##
=======================================================
+ Coverage                79.90%   79.93%   +0.02%
=======================================================
  Files                      195      195
  Lines                    14664    14685      +21
=======================================================
+ Hits                     11718    11739      +21
  Misses                    2470     2470
  Partials                   476      476

Files Changed
Coverage Δ

modules/core/04-channel/keeper/upgrade.go
85.34% <100.00%> (+0.51%)
:arrow_up:

❤


Fix for Enum collections types described as string collections

This PR closes #1845
It fixes a bug where a property that is a collection of an Enum would be incorrectly evaluated to the string type in the CodeDom.
This led to some missing models (as the enum would potentially not be referenced) as well as models having the List<string> leading to loss of the strongly typed enum.
In summary the changes include: -

Update the CreateCollectionModelDeclaration to check if the schema contains an Enum to allow the CreateModelDeclarations method to do its job.
Add tests to validate the scenarios

Generation changes can be viewed at the links below.

https://github.com/microsoftgraph/msgraph-beta-sdk-dotnet/commit/9ef8f0c4de1fb5a932350a0c381472e64a7f9d60
https://github.com/microsoftgraph/msgraph-sdk-dotnet/commit/a1be18b674111c36d39047d6c9005103f6bab83d

Thanks @baywet