still maintained?

Hi,
are there plans to update this library and keep it alive or is it abandoned?
cheers
Philipp

I also wondered, but see https://github.com/uds-psl/autosubst/issues/7 for news; I just verified that branch 8.6-devel builds with Coq 8.6.1 (both the library and examples-plain).

Hi there! The library is alive and we are working on a successor. The plan is to publish the current version of Autosubst on opam and to at least maintain compatibility with future Coq versions.

Hi! Any news on the autosubst/autosubst2 front? It would be really great to have autosubst available in OPAM.

Is there repository for the successor? Would be interesting to try it out! Been trying to get this version of autosubst working using a git submodule, but I can't figure out how to work Coq's package management :/

This repository seems to not be maintained; I have a fork at https://github.com/RalfJung/autosubst/tree that I keep working with current versions of Coq.

Thanks for maintaining an up-to date fork, Ralf!
If the original authors do not want to maintain this library anymore, then maybe it is a possibility to submit it to coq-community https://github.com/coq-community for community maintenance, since I believe there are multiple people who are still interested in using this library in their projects (me included :))

That makes sense. It just takes someone to actually pull this through. :)
(Btw, these days iris/examples, which depends on autosubst, is part of Coq CI. So we have a pretty good guarantee that autosubst will keep working.)
@adrieng
For autosubst 2, see https://www.ps.uni-saarland.de/extras/autosubst2/

That makes sense. It just takes someone to actually pull this through. :)

Basically, for this to happen 1) the original authors of the package have to give consent or vanish and be really unresponsive, 2) someone needs to volunteer to be the community maintainer.
Since I cannot volunteer another person (like Ralf, wink wink) I can volunteer myself for it (shouldn't be too much work thanks for the CI that you mentioned).
I will try to contact the original maintainers and get their consent

I'm happy to co-maintain autosubst with you, if you need help.

Just to chime in, it would be great to have an up-to-date version of this library (available via opam, if possible).

There's a version available in the opam repo at https://gitlab.mpi-sws.org/iris/opam. I was holding off on submitting it to the Coq repo as it's just a personal fork currently.
In terms of "up-to-date", the coq86-devel branch in this repo and in my fork are in sync and reflect the latest state to my knowledge.  It is compatible with a wide range of Coq versions including current master.

Thanks Ralf. Are you aware that the coq86-devel branch gives rise to several warnings when compiled with Coq 8.12?

No I was not... I guess opam install coq-autosubst doesn't show these warnings. ;) But things should still work, and there should be no warnings for users of autosubst.
It looks like autosubst will become part of coq-community soon-ish. Then I guess we can decide on a minimal supported Coq version and fix deprecation warnings where possible.

All right, @co-dan and me have maintainer access now. We'll consolidate the various branches and then submit an opam package to the Coq opam repo.

Thank you, @co-dan and @RalfJung! Please let me know if you have any questions.

So I think we can close this issue; see https://github.com/coq-community/autosubst/issues/7 for getting an opam package into the Coq repo (and not just the dev version).


deploy.sh doesn't find "Loadbalancer" string on my Centos 7

Hi all,
kubectl describe svc istio-ingressgateway -n istio-system | grep "LoadBalancer Ingress:"
doesn't work on my System because of the following:
kubectl describe svc istio-ingressgateway -n istio-system | grep -e IP -e Type
Type:                     LoadBalancer
IP:                       <IP_ADDRESS>
so I need to change the line like follows to get it to work:
kubectl describe svc istio-ingressgateway -n istio-system | grep "IP:" | sed 's~IP:[ \t]*~~'
Is that a bug on my side?
rgds Steve

Hi Steve,
I am assuming you are referring to the command to get the IP of the gateway here: https://github.com/keptn/jenkins-service/blob/release-0.2.x/deploy.sh#L16
In the command you mentioned the last part is missing, the original command is:
kubectl describe svc istio-ingressgateway -n istio-system | grep "LoadBalancer Ingress:" | sed 's~LoadBalancer Ingress:[ \t]*~~'
The script relies on the public IP of the gateway, which means that your change to use the internal IP would not work unfortunately.

Hi Jürgen,
I see... So no public IP no service...
many thanks for that fast answer!
rgds Steve


DF Templates 1.3.0 - providing the manifest in V10 installs 1.2.1 instead

I take the manifest from https://github.com/flamewave000/dragonflagon-fvtt/releases/download/df-templates_1.3.0/module.json
This causes V10 to install 1.2.1 instead.

It's currently in pre-release so it won't install by that URL since manifest installs go through my distribution service.


Do not support ea4-testing repo

elevate does not support ea4-testing. it shouldn’t even be allowing the upgrade to start
this could lead to errors like this while restoring the profile
Package ea-php82-php-common-1:8.2.3-1.el8.cloudlinux.x86_64 is already installed.
Package ea-php80-php-common-1:8.0.28-1.el8.cloudlinux.x86_64 is already installed.
Package ea-php81-php-common-1:8.1.16-1.el8.cloudlinux.x86_64 is already installed.
 Problem 1: cannot install both ea-php82-php-common-1:8.2.1-3.el8.cloudlinux.x86_64 and ea-php82-php-common-1:8.2.3-1.el8.cloudlinux.x86_64
  - package ea-php82-php-iconv-1:8.2.1-3.el8.cloudlinux.x86_64 requires ea-php82-php-common(x86-64) = 1:8.2.1-3.el8.cloudlinux, but none of the providers can be installed
  - cannot install the best candidate for the job
 Problem 2: cannot install both ea-php80-php-common-1:8.0.27-2.el8.cloudlinux.x86_64 and ea-php80-php-common-1:8.0.28-1.el8.cloudlinux.x86_64
  - package ea-php80-php-ftp-1:8.0.27-2.el8.cloudlinux.x86_64 requires ea-php80-php-common(x86-64) = 1:8.0.27-2.el8.cloudlinux, but none of the providers can be installed
  - cannot install the best candidate for the job
 Problem 3: cannot install both ea-php81-php-common-1:8.1.14-2.el8.cloudlinux.x86_64 and ea-php81-php-common-1:8.1.16-1.el8.cloudlinux.x86_64
  - package ea-php81-php-curl-1:8.1.14-2.el8.cloudlinux.x86_64 requires ea-php81-php-common(x86-64) = 1:8.1.14-2.el8.cloudlinux, but none of the providers can be installed
  - cannot install the best candidate for the job
Nothing to do.
Complete!
Last metadata expiration check: 0:00:43 ago on Wed Mar 15 15:17:35 2023.
Dependencies resolved.
Nothing to do.
Complete!

We don't support it and block. the reported issue is with a repo we do not support in production at this time.

This was also someone trying to upgrade cloudlinux.


Support regexp=true for Windows

Hi Team,
It seems that starting with version 1.27.0 (was working with 1.26.2) we stopped supporting regexp=true for Windows as per commit:
https://github.com/jfrog/artifactory-vsts-extension/commit/6a99fb043d9ebcbd1ca0bc252802bf0fd7af14c7
Are there plans to support regexp for Windows in the near future?
Thanks!

@AngelloMaggio and @michaelhuebschmannkuka,
@RobiNino fixed this issue in https://github.com/jfrog/artifactory-vsts-extension/pull/128. The fix has just been released as part of version 1.8.3.
You feedback would be greatly appreciated.

We could verify that with version 1.9.2 of the task using jfrog-cli 1.35.3 the regex with windows now works again.
Thanks a lot!

One little drawback though (no need to fix, just keep it in mind):
Backslashes must be escaped (as usual in Regexes). When you use a Azure DevOps Variables, that contain windows paths with Backslashes, this will still fail.


PR For Bot SSO-Adaptive Card Nodejs

Execution Build Pipeline : https://github.com/OfficeDev/Microsoft-Teams-Samples/actions/runs/3974013045

@Mohammed-MSFT - Kindly run build pipeline again and add it here

Also, make sure to link this sample with Microsoft public documentation.

Build Pipeline Execution : https://github.com/OfficeDev/Microsoft-Teams-Samples/actions/runs/4242292219


sqlparser-rs fails on PostgreSQL statements with RETURNING clause

:monocle_face: Bug I observed:
When using a RETURNING PostgreSQL clause in a statement, sqlparser-rs which is used to build the Query AST fails:
Err(ParserError("Expected end of statement, found: RETURNING"))

And since the Query AST can't be built, Fern proxy fails processing the query, which therefore isn't passed down to proxied Datastore.
:smiley: Behavior I expected:
Instead, I would expect the Query AST to be built as with any other statements not containing a RETURNING clause.
:gift: Something I'd like to add:
Issue is known already: sqlparser-rs/sqlparser-rs#60

Fixed in https://github.com/sqlparser-rs/sqlparser-rs/pull/666 :partying_face:


enh(javascript) Add support for jsdoc comments

This should highlight jsdoc tags like @param, @return. Should solve a part of Issue #1857.

Thanks for the commit, but I'm not sure this part of it is useful on it's own...

It kind of looks broken to me, but since we only have a single color I'm not sure what we should highlight... perhaps everything except the description?

Better? I'm not sure.

Ok, I will try to extend it. I did it as javadoc and other implementations, but you are right, it will be better in your second screenshot

And if we color it all then I think you'd completely close the issue. :-)

Oh and you'll also need to update the changelog.

Thanks for help. I added support for type. I will need more time to figure out how to do paramater name. I need to look how to do forward searching for - but not to include in result.

Nice. What do you think about highlighting type and variable as type and variable classes to get back the differentiation?

Sure. I added separation for type and variable and added a few new test cases

Taking a quick swing at this myself.

@milutin What do you think?  Still not perfect, but might be as good as we're going to get for a first pass without a lot more time invested...

I agree. I am happy with current version. I just wanted to color jsdoc at least a little bit. This is more than I expected. If someone wants more, it can be easily enhanced.

Do you want to add your name to the changelog?

Sure, why not :). Should you edit yourself as well, since you helped me a lot?

shrugs I don't need credit for every item. :-)

Thanks for helping me!


Linting fixes

Fixes a bunch of things in https://github.com/galaxyproject/gxformat2/issues/61

I think that we store the the other values is probably a bug on the Galaxy side.

I mean we put other data we don't reuse in the file.


Send events to GA everytime someone shares a post

Send events to GA everytime a post is shared using the share buttons.

blocked by https://github.com/wp-pwa/saturn-theme/issues/161

@Poliuk
They are being sent with the event action PWA - share.
The event category might be PWA - Share bar or PWA - Share modal depending on the component used.
The event label will contain the method used for share (Facebook, email...), type of content (post, page...) and the context or view in which the action took place (Post, Media, List...).


Broken with unique constraint on position

On repositioning (insert_at, etc.) the position gets updated before updating the siblings positions, which conflicts with unique constraint on position column. Also validates_uniqueness_of :position conflicts.
The solution could be not trivial; one possibility could be using temporary negative positions while updating in order to avoid the conflicts.

Very specific option (if supported by DB, like in Postgres) may be to create that constraint with 'deferrable initial deferred' option, and making it nullable. That way constraint check should be postponed till the transaction end, when all positions are unique.

Yes, this has been discussed in another issue. You're right in that it's non-trivial to accommodate. We'll certainly look into any PR's that attempt to solve it in a graceful way :)

Closed by #246


⚠ ClamAV has degraded performance

In 83906a3, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 766 ms

Resolved: ClamAV performance has improved in 3e8dd43.


Previous entry with shortcut key does not go to starred item

Describe the bug
I set Super+F11 as select previous item, when I pres this combination I expect it to select last starred item in the list which is above last copied item in the menu, but shortcut selects very last item in the history.
Versions
GNOME Shell 42.0
GCH   Version: 15
org.gnome.shell.extensions.clipboard-history cache-only-favorites false
org.gnome.shell.extensions.clipboard-history cache-size 100
org.gnome.shell.extensions.clipboard-history clear-history @as []
org.gnome.shell.extensions.clipboard-history confirm-clear true
org.gnome.shell.extensions.clipboard-history disable-down-arrow true
org.gnome.shell.extensions.clipboard-history display-mode 3
org.gnome.shell.extensions.clipboard-history enable-keybindings true
org.gnome.shell.extensions.clipboard-history history-size 1000
org.gnome.shell.extensions.clipboard-history move-item-first true
org.gnome.shell.extensions.clipboard-history next-entry ['F12']
org.gnome.shell.extensions.clipboard-history notify-on-copy false
org.gnome.shell.extensions.clipboard-history paste-on-selection true
org.gnome.shell.extensions.clipboard-history prev-entry ['F11']
org.gnome.shell.extensions.clipboard-history private-mode false
org.gnome.shell.extensions.clipboard-history process-primary-selection false
org.gnome.shell.extensions.clipboard-history strip-text false
org.gnome.shell.extensions.clipboard-history toggle-menu ['V']
org.gnome.shell.extensions.clipboard-history toggle-private-mode ['P']
org.gnome.shell.extensions.clipboard-history topbar-preview-size 10
org.gnome.shell.extensions.clipboard-history window-width-percentage 33

Can you share your use case? I thought it made more sense to skip favorites.

I save item as favorite because I use it periodically as a template, so I want to have access.
For example I have a template for my footer in social media posts.

Gotya, that makes sense.

I am also finding this a problem. I would like to use toggle through favourites using the keyboard shortcuts.


Placing Blocks

After successfully customizing blocks everything appears great until you place it down, once placed it reverts back to it original texture. Is there something I need to add or is this just not supported?

Ha ha Yes, true, wishful thinking!


Questions on the new (upcoming?) v13 support

Hi Lukas, first of all, thanks for your effort to maintain this library!
I spent a few hours into understanding the "what's new" in the 13-latest-develop branch, with the short term goal of adapting my pglast wrapper.
The following changes have obviously a considerable impact:

the new top level result (introduced by commit 53ae0937b076d0f847ecbd57d105c05bd556bdb3)
omission of attributes with value of zero, in particular for enums (commit f36f9ab7ef109a2280bb4198aa9c7de68001ca8e)

For the first, while I can see the advantage of getting rid of the mostly useless RawStmt container, I wonder what's the added value of reporting the underlying PG version in the parse result: why cannot it be simply a constant #define exposed by the library as before?
The second is more worrysome: I'm quite sure that the PG devteam won't change enums definitions with a light heart, but IMHO introducing such implicitness just to reduce the output size is not a good move; is there any other rationale behind this change?

I'm slowly trying to align my pglast project to the PG13 branch, and I found a difference in the JSON output that I'm not able to understand/fix.
Getting the JSON AST of the statement
ALTER DEFAULT PRIVILEGES FOR ROLE admin REVOKE execute ON FUNCTIONS FROM PUBLIC

I used to get the following JSON structure with previous versions of the library
[
  {
    "RawStmt": {
      "stmt": {
        "AlterDefaultPrivilegesStmt": {
          "action": {
            "GrantStmt": {
              "behavior": 0,
              "grantees": [
                {
                  "RoleSpec": {
                    "location": 73,
                    "roletype": 3
                  }
                }
              ],
              "objtype": 7,
              "privileges": [
                {
                  "AccessPriv": {
                    "priv_name": "execute"
                  }
                }
              ],
              "targtype": 2
            }
          },
          ...
        }
      }
    }
  }
]

while with the 13-latest-develop branch I get this:
[
  {
    "RawStmt": {
      "stmt": {
        "AlterDefaultPrivilegesStmt": {
          "action": {
            "grantees": [
              {
                "RoleSpec": {
                  "location": 73,
                  "roletype": "ROLESPEC_PUBLIC"
                }
              }
            ],
            "objtype": "OBJECT_FUNCTION",
            "privileges": [
              {
                "AccessPriv": {
                  "priv_name": "execute"
                }
              }
            ],
            "targtype": "ACL_TARGET_DEFAULTS"
          },
          ...
        }
      }
    }
  }
]

As you can see, the the action seems lacking the proper GrantStmt node tag (I mean, the action's attributes wrapped within a "GrantStmt" dictionary) as before... is this intentional or an unexpected regression?
Also, will you elect the new protobuf output as the recommended way or is the JSON way going to stay there indefinitely?
Thank you.

I found the code that makes the difference, but I could not figure out the logic used by the Ruby generator of the functions...
Manually applying the following change, I get the expected result:
diff --git a/src/pg_query_outfuncs_defs.c b/src/pg_query_outfuncs_defs.c
index 2cb4572..19f372a 100644
--- a/src/pg_query_outfuncs_defs.c
+++ b/src/pg_query_outfuncs_defs.c
@@ -2585,7 +2585,7 @@ static void
 _outAlterDefaultPrivilegesStmt(OUT_TYPE(AlterDefaultPrivilegesStmt, AlterDefaultPrivilegesStmt) out, const AlterDefaultPrivilegesStmt *node)
 {
   WRITE_LIST_FIELD(options, options, options);
-  WRITE_SPECIFIC_NODE_PTR_FIELD(GrantStmt, grant_stmt, action, action, action);
+  WRITE_NODE_PTR_FIELD(action, action, action);
 }

Thanks for any clarification.

@lelit Thanks for your notes here, and the early testing of the branch.
First of all, an overall note on the new formats:
Generally the idea is that the JSON parse tree will continue to be supported for output, but that using the deparser (which is now fully functional within the C library) requires the Protobuf library.
I will also be updating all directly maintained libraries (i.e. Ruby, Go, possibly others in the future) to utilize the Protobuf-based approach (since it improves the usability and speed of passing things between C and the other language).
Specific replies:

the new top level result (introduced by commit 53ae093)
while I can see the advantage of getting rid of the mostly useless RawStmt container, I wonder what's the added value of reporting the underlying PG version in the parse result: why cannot it be simply a constant #define exposed by the library as before?

The motivation here comes from the deparser, which now accepts back a parse tree to turn it into a SQL statement again. Doing so across Postgres versions, or even Postgres minor releases, would be undefined, and possibly hit issues. Therefore the top-level object exists as a way to validate the version the parse tree was generated for.
In client libraries it may also have another benefit, as you could theoretically support different major Postgres versions in case you have any helpers that rely on the specific parse tree format.

Omission of attributes with value of zero, in particular for enums (commit f36f9ab)
... I'm quite sure that the PG devteam won't change enums definitions with a light heart, but IMHO introducing such implicitness just to reduce the output size is not a good move; is there any other rationale behind this change?

The reason for omitting the zero value comes from the fact that the JSON format now matches the auto-generated JSON output format for Protobuf (intentionally, as it possibly allows for conversion between the formats in the future). But I think we can workaround this issue by ensuring the actual value is never the first field, rather having a generic "unspecified" value as the first enum value thats never used. I'll explore this.

I'm slowly trying to align my pglast project to the PG13 branch, and I found a difference in the JSON output that I'm not able to understand/fix.

I'll review this, thanks for the testing and bug report.
(also please be aware that the branch is still a bit unstable, and I'll be squashing changes for at least the next week or so - after that it should become more stable, with a target release in 2-3 weeks, if all goes well)

Thanks a lot Lukas!
I'm really happy about the JSON-way staying around: while I can clearly see the benefits that Protobuf brings, I'm not so happy about the footprint of the official Python bindings (protoc generates a 1.2Mb Python module from the 100Kb pg_query.proto), so I'm not sure it's worth the hassle.
On the version signature in the stream, yes, I understand the purpose (see #32 :wink:), but still I fail to foresee a benefit of having it in each response... unless someone is going to persist the response and act on it at a (much) later time, with a different version of libpg_query. Anyway, it was just a curiosity of mine :smile:
On the omission of the zero-valued attribute, I'll stay tuned. I think that I can easily workaround the issue with a bit of heuristic. At a glance, I thought it could cause the kind of issues that required you to introduce patches/05_limit_option_enum_value_default.patch...
On the branch stability, I'm aware of it and I'm prepared to pull --force now and then on my side.

As there's a non-zero chance that the problems reported above are generated by mis-compilation of libpg_query source after git pull --force (as happened in #84), please suspend investigation on your part, I'll report back as soon as time permits.

On the omission of the zero-valued attribute, I'll stay tuned. I think that I can easily workaround the issue with a bit of heuristic. At a glance, I thought it could cause the kind of issues that required you to introduce patches/05_limit_option_enum_value_default.patch...

This is fixed now via https://github.com/lfittl/libpg_query/commit/115570289eecbe5de511ab8ff3934d0baabf8ec6 - I think that should address the problem.

As there's a non-zero chance that the problems reported above are generated by mis-compilation of libpg_query source after git pull --force (as happened in #84), please suspend investigation on your part, I'll report back as soon as time permits.

I think the problem with the GrantStmt being omitted is actually intentional - when a field has a defined value on the Postgres side (i.e. it's not a generic node field), the better way to represent this is to not have the additional layer of indirection through the Node type.
This is again a case where the Protobuf-based approach defines the output format a bit (since the message type is specific there for the field, which causes it to not emit the node tag), and the JSON format is made to match.
Unfortunately there is no way to support the old style format going forward in this case, so I think this is something where you'll have to adjust the library a bit.

@lfittl thanks again! Happy to test this out and figured this issue was relevant for my quick question.
The enums seem to be the string representation instead of the (sometimes arbitrary) internal integers. Was that a decision to make code more portable across major versions? For PG 10, I had built systems to do the mapping to integers, but I suppose that's not necessary when we upgrade, however, I would wonder out of curiosity if we'd be able to access the native integers?
              {
                "IndexElem": {
                  "name": "a",
                  "ordering": "SORTBY_DEFAULT",
                  "nulls_ordering": "SORTBY_NULLS_DEFAULT"
                }

@lfittl thanks for all your effort on this great library! I thought figured this issue was also relevant for my questions. (Let me know if it should be it's own issue)

Hi @pyramation - thanks for making the effort to look at the new version!

The enums seem to be the string representation instead of the (sometimes arbitrary) internal integers. Was that a decision to make code more portable across major versions? For PG 10, I had built systems to do the mapping to integers, but I suppose that's not necessary when we upgrade, however, I would wonder out of curiosity if we'd be able to access the native integers?

Yep, the change is intentional, as the integer values were pretty hard to understand, and this aligns the JSON output with the new Protobuf format.
You can access the enum integer values via the enum_defs.json file: https://github.com/lfittl/libpg_query/blob/13-latest-develop/srcdata/enum_defs.json

Also, I noticed that the RangeVar is not an ast node for indexes, but rather the props are inlined. Is this intentional? It seems to break some of the parsing flow to inline parameters, but maybe this is just a breaking change from the underlying major version upgrade? Apologies if any these types of questions are redundant.

Yeah, you are not the first one to notice, and this is a bit of a problematic change from a compatibility perspective, but is what will be in the final release (sorry about the extra work based on this!).
The motivation here comes from mapping more closely how the C structs inside Postgres represent the parse tree, and ensuring both the new Protobuf format as well as the JSON format (which now also maps directly to the way Protobuf would be represented as JSON) match that.
For context, when Postgres itself uses a generic node type (e.g.  IndexStmt.whereClause) we map that to a generic pg_query.Node, which will output the parse node name in the JSON format.
When Postgres itself uses a specific type for a field (e.g. IndexStmt.relation, as you noted) we map that directly to the specific node type, skipping the intermediate pg_query.Node. This also means that the JSON format no longer outputs the name of the child node in this case, because it will always be the same type.
Changing the JSON format here to have better backwards compatibility would break an intentional guarantee this new release makes (that the JSON format is a 1:1 representation of how the Protobuf format would be mapped to JSON - which will be important for future work on the deparser/etc).
You could use the struct_defs.json file to get the types for each field, as a way to workaround this problem programmatically: https://github.com/lfittl/libpg_query/blob/13-latest-develop/srcdata/struct_defs.json#L4469

Thanks for the quick response! This all makes sense and I think long term will be better and more portable.
And also thanks for all the relevant links, I'll be using these when I rebuild the node deparser. Much appreciated @lfittl :)

Thank you Lukas!

@lelit @pyramation The Postgres 13 release is officially out now - full blog posts here: https://pganalyze.com/blog/pg-query-2-0-postgres-query-parser - I mentioned both of you by name as well, since you've been very helpful in taking an early look, as well as maintaining the Python/Node.js bindings :)
I'll close this issue here for now - but feel free to open new ones or ask here in case there are follow-up questions.


reflex/app.py - Update Import Statements

This PR adjusts the import statements in reflex/app.py to import AsyncIterator and Callable from collections.abc instead of typing. This change enhances compatibility with newer Python versions and aligns with best practices for future-proofing the codebase. The datetime, pathlib.Path, and typing imports remain unchanged.

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#3786
#3785  👈
#3784
#3783
#3782
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @elviskahoro and the rest of your teammates on  Graphite


python310Packages.dropbox: 11.31.0 -> 11.32.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python310Packages.dropbox is: "Python library for Dropbox's HTTP-based Core and Datastore APIs"
meta.homepage for python310Packages.dropbox is: "https://github.com/dropbox/dropbox-sdk-python"
meta.changelog for python310Packages.dropbox is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
Warning: a test defined in passthru.tests did not pass
found 11.32.0 with grep in /nix/store/53w77kwkpncq8jh42dy7h3yi0k3yvkjw-python3.10-dropbox-11.32.0
found 11.32.0 in filename of file in /nix/store/53w77kwkpncq8jh42dy7h3yi0k3yvkjw-python3.10-dropbox-11.32.0

Rebuild report (if merged into master) (click to expand)

13 total rebuild path(s)

7 package rebuild(s)

7 x86_64-linux rebuild(s)
6 x86_64-darwin rebuild(s)

First fifty rebuilds by attrpath
git-annex-remote-dbx
maestral
maestral-gui
python310Packages.dropbox
python310Packages.maestral
python39Packages.dropbox
python39Packages.maestral

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/53w77kwkpncq8jh42dy7h3yi0k3yvkjw-python3.10-dropbox-11.32.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python310Packages.dropbox https://github.com/r-ryantm/nixpkgs/archive/49cc2c709dbc3d37bb09e53bd34335d5ac86c3e1.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/53w77kwkpncq8jh42dy7h3yi0k3yvkjw-python3.10-dropbox-11.32.0
ls -la /nix/store/53w77kwkpncq8jh42dy7h3yi0k3yvkjw-python3.10-dropbox-11.32.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

6 packages built:

git-annex-remote-dbx
maestral (python39Packages.maestral)
maestral-gui
python310Packages.dropbox
python310Packages.maestral
python39Packages.dropbox

Maintainer pings
cc @sfrijters for testing.

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

6 packages built:

git-annex-remote-dbx
maestral (python39Packages.maestral)
maestral-gui
python310Packages.dropbox
python310Packages.maestral
python39Packages.dropbox


can't build OpenSSL

command:
(venv) λ conan install .. --build=missing -s build_type=Debug

conanfile.txt:
[requires]
Poco/1.7.5@lasote/stable

[generators]
cmake

[options]
Poco:shared=True
OpenSSL:shared=True

error:
 Assembling: ms\uptable.asm
        link /nologo /subsystem:console /opt:ref /debug /dll /out:out32dll.dbg\libeay32.dll /def:ms/LIBEAY32.def @C:\Users\Pavel\AppData\Local\Temp\nm9773.tmp
LINK : fatal error LNK1181: cannot open input file 'ms\uptable.obj'
NMAKE : fatal error U1077: '"E:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\amd64\link.EXE"' : return code '0x49d'
Stop.

i found solution in http://openssl.6102.n7.nabble.com/Trouble-building-OpenSSL-with-Visual-Studio-2013-Linker-error-cites-quot-ms-uptable-obj-quot-td51117.html
how can i fix it

Try installing the version from the conan-center repository Poco/1.7.8p3@pocoproject/stable, it depends on an improved OpenSSL with build requires helping to build from sources.
If fails, please report.

Ok. Thanks. I'll try.


(new) Chain.transform_tests(): loop through codes in reverse

Currently code ranges like 1, 2, 3, 9, 99, 997 would be incorrectly transformed since 9 would be replaced in 9, 99 and 997. If we would loop over the reversed list of codes we could prevent that.

done in #805.


fix missing nostr module error

$ python3 startr_app.py
Traceback (most recent call last):
  File "/home/marcel/workspace/nostr_startr/startr_app.py", line 2, in <module>
    from helpers import *
  File "/home/marcel/workspace/nostr_startr/helpers.py", line 1, in <module>
    from nostr import bech32
ModuleNotFoundError: No module named 'nostr'

Since the python_nostr library is in development there were also some missing packages in requeriments.txt, now updated, the problem should be fixed.


feat(rbac): RBAC system

Context
In this PR we are looking to add all the endpoints related to the system roles, as well as their relationships with users and provider_groups.
Description
In this PR we have added all the necessary endpoints to manage the system roles as well as their relationship with users and provider_groups:

Users
Roles

Checklist

Are there new checks included in this PR? No

If so, do we need to update permissions for the provider? Please review this carefully.

[x] Review if the code is being covered by tests.
[x] Review if code is being documented following this specification https://github.com/google/styleguide/blob/gh-pages/pyguide.md#38-comments-and-docstrings
[x] Review if backport is needed.

License
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

We are going to disable RBAC tests as there are problems with Github Actions and we need to have this feature, we will fix this in the near future. At the moment this is the log of the tests executed locally:
(prowler-api-py3.12) adriiiprodri@MacBook-Pro-de-Adrian backend % pytest api/tests/
============================================================================================== test session starts ==============================================================================================
platform darwin -- Python 3.12.7, pytest-8.2.2, pluggy-1.5.0
Using --randomly-seed=1541910068
django: version: 5.1.1, settings: config.django.testing (from ini)
rootdir: /Users/adriiiprodri/git/prowler/api/src/backend
configfile: pytest.ini
plugins: docker-tools-3.1.3, cov-5.0.0, env-1.1.3, randomly-3.15.0, celery-1.1.3, anyio-4.6.0, django-4.8.0, dash-2.18.2, xdist-3.6.1
collected 474 items

api/tests/integration/test_authentication.py ..                                                                                [  0%]
api/tests/test_database.py ..                                                                                [  0%]
api/tests/integration/test_tenants.py .                                                                                [  1%]
api/tests/test_uuid_utils.py ..............                                                                                [  4%]
api/tests/test_decorators.py ..                                                                                [  4%]
api/tests/test_utils.py ..........................                                                                                [  9%]
api/tests/test_rbac.py ............                                                                                [ 12%]
api/tests/test_models.py .....                                                                                [ 13%]
api/tests/test_views.py ................................................................................................................................................................................. [ 50%]
......................................................................................................................................................................................................... [ 93%]
..............                                                                                [ 96%]
api/tests/test_compliance.py ......                                                                                [ 97%]
api/tests/test_middleware.py .                                                                                [ 97%]
api/tests/test_db_utils.py ...........                                                                                [100%]

==================================================================================================== PASSES =====================================================================================================
======================================================================================== 474 passed in 85.72s (0:01:25) =========================================================================================


Make TermDag indices opaque, write tests for TermDag

@oflatt mentioned he would prefer callers not to be able to construct Terms directly, but still be allowed to pattern match on them. I don't think exactly that is possible in Rust, but here is an alternative. We make the indices into the DAG opaque, but we leave the Term enum fully public. That way the API kinda pushes you toward only constructing one layer of a term at a time, which is exactly how it should be used. Oliver, what do you think?
This PR also adds a bunch of tests about terms (and a bit about exprs). If we decide not to make the term index change, I can split this PR to just merge the tests.
There is also a test that demonstrates how a caller can still shoot themselves in the foot by taking TermId from one TermDag and passing it to a different TermDag. This could cause wrong results or panic. I think this is not a dealbreaker and is a relatively easy failure mode to explain to callers.

this is a definite improvement!
Another design would be to improve the match_term_app macro and force people to use that. Then we could not even ever hand back a term id, we would always expose a Term. I think that would be better but more complicated
Another tweak I thought about was for all the terms to reference the "ambient" term dag so we don't have to pass it around but this is also complicated
Anyways this is good we should merge


Refactor OpTimerTest.verifyExceptionCallingStartWhenRunning to improve the test experience

I am looking at test case, verifyExceptionCallingStartWhenRunning.My understanding is that it tests that when an OpTimmer is started for a second time, an IllegalStateException should be thrown.
The try-catch block between lines 106 and 111, and the assert on 113, seem to add unnecessary complexity to the test case. If an exception happens in the try block, line 113 will fail the test case, since the timer is interrupted. We can remove line 106 to line 111 (try-catch block and the assert), and only keep line 107 for equivalent failure. When an exception happens on line 107, JUnit handles the exception automatically and raise a failure. Junit even provides additional information of the exception with running trace.

Before Refactoring
@Test
  public void verifyExceptionCallingStartWhenRunning() {

    OpTimer timer = new OpTimer().start();

    try {
      Thread.sleep(50);
    } catch (InterruptedException ex) {
      log.info("sleep sleep interrupted");
      Thread.currentThread().interrupt();
    }

    assertTrue(timer.isRunning());

    // should throw exception - already running
    assertThrows(IllegalStateException.class, timer::start);
  }

After Refactoring
@Test
  public void verifyExceptionCallingStartWhenRunning() throws InterruptedException {

    OpTimer timer = new OpTimer().start();
    Thread.sleep(50);

    // should throw exception - already running
    assertThrows(IllegalStateException.class, timer::start);
  }

This change will benefit the test case in two ways: 1) removing the try-catch makes the test case read simpler; 2) the information about the test failure becomes more clear.
Please let me know if this makes sense. Any comments are welcome and appreciated.

Seems reasonable - can you submit a PR against the main branch?

Thank you for the reply! I will try to submit a PR today.

It looks like a few other test cases in OpTimerTest could get the same treatment too.
Also, if you are interested in further improving these tests, you could optionally add descriptive messages to the assert statements and assert that the expected message is returned from assertThrows.

Is somebody working on this?

Sorry about the delay, I was being busy for the last week, I will try to submit the PR in this week. Thanks a lot for the advice!


This is what you need for TBB

tbb package is separated into multiple ones. To build software with TBB you need tbb-devel

Checklist

[ ] Used a fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

ok lets try to get this one working...
linux and osx look fine.
win:  ninja: error: 'C:/bld/freecad_1538305284536/_h_env/Library/lib/tbb.lib', needed by 'Mod/Fem/Fem.pyd', missing and no known rule to make it

When I build this PR locally tbb 2019 is used but linking problem occurs:
ln: creating symbolic link `/opt/conda/conda-bld/freecad_1538338725106/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_place/lib/libtbb.so': File exists

Both osx/linux use tbb2018 on circle-ci and succeed. I don't know why I can't reproduce this locally.
windows pulls in the latest tbb and it seems to work.

linux and osx still use a tbb 2018 here. I can't reproduce this locally.

When I build this PR locally tbb 2019 is used but linking problem occurs:
ln: creating symbolic link `/opt/conda/conda->bld/freecad_1538338725106/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_place/lib/libtbb.so': File exists
This is a very good sign of something messing up with TBB in your build scripts. Find and eliminate it :)

Yes, your linux build uses tbb version 2018.0.5 (why not 2019??), which was already refactored into runtime and -devel packages:
    tbb:              2018.0.5-h2d50403_0          conda-forge
    tbb-devel:        2018.0.5-h2d50403_0          conda-forge

thanks, I will merge it for now.

ok,everything looks fine now. In master-branch also tbb2019 is used. (I guess this problem was introduced in this PR by a diverted master, which pinned the 2018 version for unix). Thanks again, and sry for the confusion...


Add google maps

How to add google maps with the help of geofence?

geofence is separate thing and Google map is separate thing. google map provide you map location with (Lat, Log, Place ID and Place Name.. etc) but geofence is only provide specific area radius when user Enter and Out form there place then they Event trigger on your action.

Hi @Sarat-1997 for that you have to utlize this package and use google maps separately since as @MustafaRazaUllah mentioned Google map is a different functionality and map is a different and not yet supported in the latest version of package


Cold/Flu: Email Notification to Admin upon registration activity during 2-week grace period

User Story
As a site admin, I would like an email notification sent to me upon registration activity during the 2-week grace period between June 30 - July 5, so that I can ensure all current registrations are included in reports to the vendor and processed accordingly.
Changes to whether the form is open or closed:

Email notification of registrant form CHANGES are sent to the form admin when the form is INACTIVE.
Email notification of NEW registrant are sent to the form admin when the form is INACTIVE.

Tasks

[ ]  Conditional logic to trigger email notification to admins

Acceptance Criteria

Site admins are notified via email when submissions are changed when the form is closed.
2 week grace period, form is still accessible by link, after which only site admin (heather) can see the form, and everyone else will see a popup that the period is closed

refer #1007 comments for email template.

Heather agreed, email notification on submission during grace period is a nice to have. The workaround is just using the date filter in submitted forms on DJ.


add pprof config and start up logic

Coverage increased (+0.02%) to 66.638% when pulling 6739ea4d37e31de6fd36be6b72818edbd5dcbb6c on pprof into 26303d59c643c45ab0dcaefd2688cdc413d84398 on master.

Coverage decreased (-0.04%) to 66.577% when pulling acb8583f2af42c1c4760d6a133cb7c481b9ed38f on pprof into 26303d59c643c45ab0dcaefd2688cdc413d84398 on master.

Coverage decreased (-0.07%) to 66.577% when pulling 1814aac28dbcc3cce2c6dc8aa003e572ea0f79d1 on pprof into 3c1e5bbab0e580e04ae6e202e746dac127056dc5 on master.


publish messages without to inherited from Racecar::Consumer

Is there any way to publish messages without to inherited from Racecar::Consumer ?
I would like to produce messages from my service objects.
I didn't find, then I created a class like:
class Foo < Racecar::Consumer
subscribes_to "some-topic"
def publish(message:, topic: , key:)
produce(JSON.dump(message), topic: topic, key: key)
end
end
But I get the following error when I try to produce:
[1] pry(main)> Foo.new.publish(message: {foo: "barX"}, topic: "some-topic", key: "key-1")
NoMethodError: undefined method produce' for nil:NilClass from /Users/rinaldifonseca/.rvm/gems/ruby-2.1.3/gems/racecar-1.0.0/lib/racecar/consumer.rb:46:in produce'

No, the produce method is private. Take a look at DeliveryBoy for your use case.

The README section on Producers should be updated to reflect this. It's misleading.

The README section on Producers should be updated to reflect this. It's misleading.

@dan3lson I'm not sure I follow – the produce method can be called from within a consumer class instance.


Add Sprinfox docket for management endpoints

linked to https://github.com/jhipster/generator-jhipster/pull/5892

@jdubois Can you review this. This adds the management docs as an additional swagger resource as showed in this post: https://github.com/jhipster/generator-jhipster/pull/5892#issuecomment-310631748
Personally I would benefit from something like this on my current project with @pascalgrimaud.

OK, I just want to test a couple of things here (I had bugs on this part very recently), but yes I'll merge it afterwards


p910nd: fix darwin build

Description of changes
Replace the hardcoded gcc on clang environments.
Things done

Built on platform(s)

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

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

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

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Shouldn't we just unconditionally change gcc to cc which should work with any compiler (at least both gcc and clang)?

Your call, I'm happy with either.


Add a README

A readme would be extremely handy for those of us who want to know what this repo is all about.
Also, setting up the project would be a great addition for those who don't do a lot of Android app development.

#4 sorta relates to this, I'll add a readme once I have time. I just didn't think anyone would ever actually want to know about/use this


Can't compile if print-glossary has just one entry

I set up glossarium following the manual, and started adding my first entry. The compiler outputs this error unless I add at least two entries. I spent some minutes being confused I was doing something wrong before realizing that. Here is the output from the compiler:
❯ typst compile thesis.typ
error: cannot access fields on type array
    ┌─ @preview/glossarium:0.4.1/glossarium.typ:121:17
    │
121 │       key: entry.key,
    │                  ^^^

help: error occurred in this call of function `__normalize-entry-list`
    ┌─ @preview/glossarium:0.4.1/glossarium.typ:139:16
    │
139 │   let entries = __normalize-entry-list(entry_list)
    │                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

help: error occurred in this call of function `print-glossary`
    ┌─ thesis.typ:108:1
    │
108 │   #print-glossary(
    │ ╭──^
109 │ │   (
110 │ │     (
111 │ │       key: "ase",
    · │
116 │ │   show-all: true,
117 │ │ )
    │ ╰─^

Can you  provide a minimal working example so that I can reproduce the issue please ?

This works, so I don't know why you are experiencing this issue.
#import "@preview/glossarium:0.4.1": make-glossary, print-glossary, gls, glspl
// Replace the local import with a import to the preview namespace.
// If you don't know what that mean, please go read typst documentation on how to import packages at https://typst.app/docs/packages/.

#show: make-glossary

#set page(paper: "a5")

#show link: set text(fill: blue.darken(60%))

I like to eat #glspl("potato"). Yes I still like to eat #glspl("potato").

= Glossary

#print-glossary(
  (
    (
      key: "potato",
      short: "potato",
      // "plural" will be used when "short" should be pluralized
      plural: "potatoes",
      description: [#lorem(10)],
    ),
  ),
  // show all term even if they are not referenced, default to false
  show-all: true,
  // disable the back ref at the end of the descriptions
  disable-back-references: true,
)

You are probably passing a dictionary as a parameter when the function print-glossary expect a list of dictionaries

You are probably passing a dictionary as a parameter when the function print-glossary expect a list of dictionaries

Yes, that was the issue indeed. I'm not expert in Typst internals, and didn't think that the comma after a ) changed the object from a dictionary to a list. Thank you!

I hope this helps someone in the future. I know this is a edge case, as a glossary usually has more than one entry, but maybe this error can be caught and tell the user where is the problem? If it wasn't me, one would have abandoned the plugin altogether when it didn't work with one entry.
#import "@preview/glossarium:0.4.1": make-glossary, print-glossary, gls, glspl
// Replace the local import with a import to the preview namespace.
// If you don't know what that mean, please go read typst documentation on how to import packages at https://typst.app/docs/packages/.

#show: make-glossary

#set page(paper: "a5")

#show link: set text(fill: blue.darken(60%))

I like to eat #glspl("potato"). Yes I still like to eat #glspl("potato").

= Glossary

#print-glossary(
  (
    (
      key: "potato",
      short: "potato",
      // "plural" will be used when "short" should be pluralized
      plural: "potatoes",
      description: [#lorem(10)],
    ) // <-- Need a comma here, otherwise throws error
  ),
  // show all term even if they are not referenced, default to false
  show-all: true,
  // disable the back ref at the end of the descriptions
  disable-back-references: true,
)

we are working on refactoring the codebase and adding type checking but it will take some time.


[BI-652] - New account signup

See bi-api pull request: https://github.com/Breeding-Insight/bi-api/pull/55

I didn't run this locally, but I did carefully review the video.
Some language changes to the dialog boxes and email message are suggested inline, here and in the bi-api repo.
Would it be possible to remove the second step to log in again once the account is activated? Could we just have a button that "completes" the activation by taking them to their account page (authorized-user home page)? If there's a security reason to reauthenticate, I could see having the second login after activating the account, but otherwise let's make it simpler and just send the new user to their account, replacing the "Return to home page" link on the activation page with some new language and a direct link. Thoughts?


v2.1.0 Error in reporter TypeError

When there are failed cases:
[MR] generating report data ...
Error in reporter TypeError: Cannot read properties of undefined (reading 'startOffset')
    at quickFindRange (/Users/xxx/node_modules/.pnpm/monocart-coverage-reports@2.0.0/node_modules/monocart-coverage-reports/lib/converter/branches.js:21:28)
    at findInRanges (/Users/xxx/node_modules/.pnpm/monocart-coverage-reports@2.0.0/node_modules/monocart-coverage-reports/lib/converter/branches.js:29:19)
    at /Users/xxx/node_modules/.pnpm/monocart-coverage-reports@2.0.0/node_modules/monocart-coverage-reports/lib/converter/ast.js:247:34
    at Array.forEach (<anonymous>)
    at addCssRules (/Users/xxx/node_modules/.pnpm/monocart-coverage-reports@2.0.0/node_modules/monocart-coverage-reports/lib/converter/ast.js:199:11)
    at getCssAstInfo (/Users/xxx/node_modules/.pnpm/monocart-coverage-reports@2.0.0/node_modules/monocart-coverage-reports/lib/converter/ast.js:286:5)
    at convertV8List (/Users/xxx/node_modules/.pnpm/monocart-coverage-reports@2.0.0/node_modules/monocart-coverage-reports/lib/converter/converter.js:991:23)
    at generateCoverageReports (/Users/xxx/node_modules/.pnpm/monocart-coverage-reports@2.0.0/node_modules/monocart-coverage-reports/lib/generate.js:135:47)
    at CoverageReport.generate (/Users/xxx/node_modules/.pnpm/monocart-coverage-reports@2.0.0/node_modules/monocart-coverage-reports/lib/index.js:106:33)
    at generateGlobalCoverageReport (/Users/xxx/node_modules/.pnpm/monocart-reporter@2.1.0/node_modules/monocart-reporter/lib/plugins/coverage/coverage.js:96:29)
    at artifactsHandler (/Users/xxx/node_modules/.pnpm/monocart-reporter@2.1.0/node_modules/monocart-reporter/lib/generate-data.js:22:34)
    at generateData (/Users/xxx/node_modules/.pnpm/monocart-reporter@2.1.0/node_modules/monocart-reporter/lib/generate-data.js:90:23)
    at Reporter.onEnd (/Users/xxx/node_modules/.pnpm/monocart-reporter@2.1.0/node_modules/monocart-reporter/lib/index.js:203:28)
    at ReporterV2Wrapper.onEnd (/Users/xxx/node_modules/.pnpm/playwright@1.40.1/node_modules/playwright/lib/reporters/reporterV2.js:91:12)
    at wrapAsync (/Users/xxx/node_modules/.pnpm/playwright@1.40.1/node_modules/playwright/lib/reporters/multiplexer.js:79:12)
    at Multiplexer.onEnd (/Users/xxx/node_modules/.pnpm/playwright@1.40.1/node_modules/playwright/lib/reporters/multiplexer.js:51:25)
    at InternalReporter.onEnd (/Users/xxx/node_modules/.pnpm/playwright@1.40.1/node_modules/playwright/lib/reporters/internalReporter.js:69:12)
    at Runner.runAllTests (/Users/xxx/node_modules/.pnpm/playwright@1.40.1/node_modules/playwright/lib/runner/runner.js:77:28)
    at runTests (/Users/xxx/node_modules/.pnpm/playwright@1.40.1/node_modules/playwright/lib/cli.js:130:93)
    at t.<anonymous> (/Users/xxx/node_modules/.pnpm/playwright@1.40.1/node_modules/playwright/lib/cli.js:40:7)

v2.0.4 has been working very well

just release a new version<EMAIL_ADDRESS>to fix the error.
please try reinstall the node modules
1, goto node_modules dir and remove folder monocart-coverage-reports
2, reinstall again and make sure<EMAIL_ADDRESS>installed

It has been solved, thank you very much!!!


Restore download links to /closer.cgi/

Can one of the admins verify this patch?

Can one of the admins verify this patch?


Feature Idea: "Flashlight"

Just thought about the idea to add the flashlight to the item pool as progression.
All locations which are dark (underground caves like sunless city, zero-g-cave etc.) would require the flashlight to be in logic.
From my knowledge entering the stranger would also require the flashlight (have not played the DLC much).
This should maybe also be added to early_key_item if implemented.

A flashlight item has been suggested in the past (so much it's kind of a meme in the AP Discord thread) but never implemented because

After ten months and dozens of releases, ^this never changed much. But we can spell out the argument in much more detail now that it's been fully explored and settled, so:

The Zero-G cave is almost fully covered in other light sources after that initial left turn
Sunless City is usually accessed through the not-that-dark shortcut by the gravity cannon anyway
Flashlight is used to make quantum objects move around, but alternative light sources like your jetpack or the Scout are too easy to be out of logic, yet also annoying enough that we'd rather not require them, and probably some players wouldn't realize those alternatives exist...
The only dark-enough locations left would be I think the trip to HEL, maybe Coleus' Cave, maybe Cave Shard itself? Which are also all pretty easy to do with jetpack lighting, and none of those have an alternative access using any non-flashlight item.
Plus, lots of places are just dark enough that lack of flashlight would be annoying, yet nowhere near dark enough that it would make sense for flashlight to be a logical requirement.

So from a randomizer design perspective, there's just not much potential value here... in the base game. For a long time "the flashlight question" was one I was putting off until Echoes of the Eye DLC integration, because we all knew the most compelling flashlight blockers were all in the Stranger.
To make a very long design process short, I ended up concluding that a "Stranger Light Modulator" item for controlling owlk rafts, doors and elevators, with a special exception for the airlocks, and the laboratory doors being controlled instead by "Breach Override Codes", is a better overall design than any of the options that involved taking away the entire flashlight. There were lots of interrelated reasons for that, but the biggest one relevant to this topic is that it allows for several different ways of gradually gaining access to more of the Stranger and DW, while "just" itemifying the flashlight as-is would have made the flashlight a hard requirement to do anything in the DLC yet also instantly unlock almost the entire non-DW half of the DLC.
I guess the tl;dr is either "We already did, the AP item part is just called 'Stranger Light Modulator'" or "We decided not to because it'd be annoying in a lot of places and do very little to block locations/change item placements/make players take unusual routes/etc".


handle rate limit config update event

What this PR does:
handle rate limit config update event
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

Codecov Report

Merging #196 (b1d81ba) into develop (29f3232) will decrease coverage by 1.68%.
The diff coverage is 5.20%.

:exclamation: Current head b1d81ba differs from pull request most recent head ccd46cf. Consider uploading reports for the commit ccd46cf to get more accurate results

@@             Coverage Diff             @@
##           develop     #196      +/-   ##
===========================================
- Coverage    38.09%   36.41%   -1.69%
===========================================
  Files           36       36
  Lines         1848     1939      +91
===========================================
+ Hits           704      706       +2
- Misses        1048     1138      +90
+ Partials        96       95       -1

Impacted Files
Coverage Δ

pkg/config/api_config.go
2.48% <0.00%> (-1.02%)
:arrow_down:

pkg/filter/accesslog/access_log.go
0.00% <ø> (-4.09%)
:arrow_down:

pkg/pixiu/pixiu_start.go
0.00% <0.00%> (ø)

pkg/service/api/discovery_service.go
41.90% <0.00%> (-1.24%)
:arrow_down:

pkg/filter/plugins/plugins.go
34.78% <62.50%> (+3.53%)
: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 29f3232...ccd46cf. Read the comment docs.


Revert "Expose TaskInterface's spawn API to clients"

Reverts apple/swift-llbuild#752
This regressed the Windows build: https://ci-external.swift.org/job/oss-swift-windows-toolchain-x86_64-vs2019/418/consoleText

@swift-ci please test

@swift-ci please smoke test

@compnerd Is there a way for us to run Windows CI on llbuild PRs to avoid this issue in the future?

@jakepetroules yes, that is something that @shahmishal should be able to configure.  We do already build llbuild on ci-external as part of a full toolchain build.


enable instrumented jars

jetbrains recommend using the instrumented jar
https://plugins.jetbrains.com/docs/intellij/tools-gradle-intellij-plugin.html#multi-module-project
but there is a bug.
https://github.com/digma-ai/digma-intellij-plugin/issues/1017
https://youtrack.jetbrains.com/issue/IDEA-318263#focus=Comments-27-7274096.0-0
one option is to enable instrumented jars only in github build but not in development.
the problem would be that the in development we will test different code then in production
its possible to disable instrumentation in the intellij extension for development and enable it in github.
Jakub says he will address that in 2.0
https://jetbrains-platform.slack.com/archives/CPL5291JP/p1706555486673889

// todo: jetbrains recommend using the instrumented jar
//  https://plugins.jetbrains.com/docs/intellij/tools-gradle-intellij-plugin.html#multi-module-project
//  but there is a bug.
//  https://github.com/digma-ai/digma-intellij-plugin/issues/1017
//  https://youtrack.jetbrains.com/issue/IDEA-318263#focus=Comments-27-7274096.0-0
//  the workaround suggested in youtrack didn't work
//  but this may work:
//    if (project.findProperty("IsGithubBuild") == null) {
//        implementation(project(":ide-common"))
//        implementation(project(":jvm-common"))
//        implementation(project(":python"))
//        implementation(project(":rider"))
//    } else {
//        implementation(project(":ide-common", "instrumentedJar"))
//        implementation(project(":jvm-common", "instrumentedJar"))
//        implementation(project(":python", "instrumentedJar"))
//        implementation(project(":rider", "instrumentedJar"))
//    }


Lock inside promise not actually locking?

I may be doing something obviously wrong, I'm not sure. But I tried putting a lock around some code in a promise that was causing our server issues to be sure it was only done once at a time. However from my logs I see multiple clients ending up in the locked section simultaneously.
This is the function in question: https://github.com/gcp/leela-zero-server/blob/287ae0a852ff03a2cf0d528ee2c7c6981ec33c36/server.js#L182
The bulk of the Promise has the code wrapped in the lock.request(). But I can see extra clients are able to acquire the lock and start an unzip process even before the first unzip has completed.
Does the lock have to be outside the "return new Promise" above it? Do I need to "await" the lock.request() when called inside a Promise?
Any help appreciated. Thanks!

Hi @roy7, two remarks:

In half the branches you don't return any value from the callback, causing it to return immediately and release the lock
Instead of returning the new promise, you should return (or return await) the lock.request

When submitting an issue on Github (or Stackoverflow or anywhere else for that matter), don't expect other people to look at 60+ lines of your code.  Next time, create a minimalistic example that exhibits the problem. It might even help you solve the issue yourself, but if not, it will make it much more likely that someone will look at it in their spare time.

No worries, apologies for not just stripping out all the useless code and only giving you the shell. :)
Thanks for the quick reply though!


View always has a shade

Hi, I'm learning rust and in order to do that I've decided to create an terminal application like mc but using Cursive. I'm using cursive views in order to present the folder content to the user. Is there a way to not have a shade under the view so the view can actually fit the entire screen?
Thank you

Hi, and thanks for the report!
You may be interested in Cursive::add_fullscreen_layer(). You can also check the lorem example which uses it.

Hi there!
Thanks so much for such a quick reply.
Will definitely check that out!
Best regards and have a nice weekend!


Build of emby server failed

Before proceeding

[X] I didn't find a similar issue

Version
v1.2.140+fix2
How to reproduce

Set werf.yaml

project: emby
configVersion: 1
---
image: emby
from: emby/embyserver:latest

Run build

$ werf build
Version: v1.2.140+fix2
Using werf config render file: /tmp/werf-config-render-4020255327

┌ ⛵ image emby
│ ┌ Pulling base image emby/embyserver:latest
│ └ Pulling base image emby/embyserver:latest (38.78 seconds)
│
│ ┌ Creating container stapel_0.6.2 from image registry.werf.io/werf/stapel:0.6.2
│ └ Creating container stapel_0.6.2 from image registry.werf.io/werf/stapel:0.6.2 (1.76 seconds)
│
│ ┌ Building stage emby/from
│ ├ Info
│ └ Building stage emby/from (0.68 seconds) FAILED
└ ⛵ image emby (41.36 seconds) FAILED

Running time 41.41 seconds
Error: phase build on image emby stage from handler failed: failed to build image for stage from with digest 209c77a4c2f299276d8a162347702f0186259f680c760701ca7c371b: container run failed: Status: , Code: 139

Result
Error 139 with unknow reason
Expected result
Successful build
Additional information
No response

Code 139 is a segfault. The cause is LD_LIBRARY_PATH=/lib:/system, which is set in the emby/embyserver:latest image. If we rebuild this image with ENV LD_LIBRARY_PATH=, then werf build works fine.
Looks like because of LD_LIBRARY_PATH we use some unexpected shared libraries for our build, which results in segfault.
Will look into what we can do to fix this.

rel https://github.com/werf/werf/pull/4821


feat: Add option for onDataSubmitted callback to Trap

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

Project coverage is 96.06%. Comparing base (61941e3) to head (19fa92a).

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #48      +/-   ##
==========================================
+ Coverage   95.84%   96.06%   +0.21%
==========================================
  Files          16       16
  Lines         602      610       +8
  Branches      111      113       +2
==========================================
+ Hits          577      586       +9
+ Misses         24       23       -1
  Partials        1        1

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

Diff between the reviewed and latest commit:
https://github.com/cursorinsight/ci-trap-web/compare/77d94af2479ae535a61786d32d2f6cda47d7ab3e..a4386fa286f6b01140be22b7bc14c8f4f89c175e


parameterize cli to make more easily extensible

Codecov Report
Patch coverage: 99.18% and project coverage change: +0.06 :tada:

Comparison is base (e6c1585) 97.10% compared to head (449644d) 97.17%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main       #6      +/-   ##
==========================================
+ Coverage   97.10%   97.17%   +0.06%
==========================================
  Files           7        7
  Lines         588      638      +50
==========================================
+ Hits          571      620      +49
- Misses         17       18       +1

Impacted Files
Coverage Δ

src/dbami/cli.py
98.01% <99.18%> (-0.01%)
:arrow_down:

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


Worldmap node don’t use or generate msg.socketid

Hi,
I'm using the excellent Worldmap node.
However, I am having difficulty when multiple sessions are connected. Specifically, I can't get other elements on the page to interact properly as Worldmap doesn't generate and doesn't use the dashboard session reference (msg.socketid). Is it possible to have the message generated by the ui_worldmap node (even during the connection event)?
But maybe I'm looking for the wrong solution, advice is welcome.
Thanks in advance.
Lorenzo

If you inspect the full msg object you will see it reports msg._sessionid instead.


Add Italian translation

Adding a candidate Italian translation. It seems fine to me in the layout (sometimes Italian may be a bit more wordy).

I should have fixed everything. 👍


feat(button): add type prop

Just to fix this:

I think you can do just
const Button: React.FC<
  Omit<React.HTMLProps<HTMLButtonElement>, 'size'> & ButtonProps
> = ({...

and that should do the trick. But we have to omit the size prop from HTML because it clashing with our own property

@ajkl2533 nice, changed


"HoneycombMetricsConfig.MetricsHoneycombAPI" field should not be required

Versions

Go: 1.17.5
Refinery: 1.8.1

Steps to reproduce

Activate publishing metrics to Honeycomb by populating the "HoneycombMetrics" field in the Refinery configuration file.
Omit the "HoneycombMetrics.MetricsHoneycombAPI" field.
Observe that Refinery exits with an error, complaining:

unable to load config: Key: ‘HoneycombMetricsConfig.MetricsHoneycombAPI’ Error:Field validation for ‘MetricsHoneycombAPI’ failed on the ‘required’ tag

Additional context
The "MetricsHoneycombAPI" field is tagged as needing to parse as a valid URL, and is marked as required. However, we pass it down to libhoney in the libhoney.ClientConfig.APIHost field, and that field is documented to have a sensible default value that callers should not need to override in most cases.
It's fine to validate that the "MetricsHoneycombAPI" field is a URL if its value is nonempty, but we should not require this field be populated, just as we don't require a value for the similar "HoneycombAPI" field.

I recognize that it would be hard to define a default in Viper for these fields, as the HoneycombLoggerConfig fields shouldn't be used if logrus is in use. The same goes for HoneycombMetricsConfig and Prometheus being in use. Perhaps just relaxing the constraint and allowing the default zero value—the empty string—would be sufficient here, relying on libhoney-go to supply the concrete default value.
That, or consider copying down the value from the top-level HoneycombAPI field, though that would be a change in behavior, possibly surprising some existing users.

I think we can close this out considering the changes made to configuration and metrics in Refinery 2.0.


Updated website for carbondata-2.2.0 release

Updated website for carbondata-2.2.0 release

@chenliang613 @sraghunandan please review and merge it, to update any document changes, I will raise new PR

LGTM


When an async test times out, any fixtures used in the tests are not torn down

Thank you for reporting! I'm unable to reproduce with the latest version of MUnit (v1.0.0-M1). I opened a PR reproducing the case and the fixture gets torn down on timeout. The PR #430 changed how the timeout is implemented which probably fixed this bug.


enhanceMv disable hive auto refresh

Proposed changes
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall

run buildall

run buildall

run buildall


feat: add Role and ClusterRole forms

This PR...
Changes

Adds role-related form templates

Fixes

How to test it

Screenshots

Checklist

[ ] tested locally
[ ] added new dependencies
[ ] updated the docs
[ ] added a test

Ready to review!


HDDS-11774. Adding listing metadata flag to resolve client incompatibility for listing

What changes were proposed in this pull request?
Creating a generic metadata map in the OMRequest to deal with client version incompatibility. Setting a key in the client request to the map for server to act on the basis of the value set by the client.
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-11774
How was this patch tested?
Planning to add a compatibility test for this.

QQ, why aren't we bump the client version instead to (client supports server side liststatus limits or something like that), so that we can identify older clients that does not know about/respect the server side limit, and then we can treat these clients from the server side?
At least my understanding is that about the current draft that it pushes this client information via a request metadata instead of with the client's version, but please correct me if I am wrong.

QQ, why aren't we bump the client version instead to (client supports server side liststatus limits or something like that), so that we can identify older clients that does not know about/respect the server side limit, and then we can treat these clients from the server side?
At least my understanding is that about the current draft that it pushes this client information via a request metadata instead of with the client's version, but please correct me if I am wrong.

You are right we can achieve this by a client version bump and that is eventual goal. But because our request feature validator is broken we cannot bump up our client version. We already have a patch upstream which fixes that https://github.com/apache/ozone/pull/6932 . I thought to have a patch in the interim. But after discussing about this offline with @errose28 @umamaheswararao @swagle we came to a conclusion to abandon this change and work on fixing the request feature validator and perform a client version bump up instead.


Timestamp in DCAT feed is off by an hour

Setup: a test IPT registered with a test organization. No published datasets.
If I generate the DCAT feed on 11:01 GMT+2, the timestamp in the feed is 10:01 GMT+2. Is this an error in the code or is something wrong on the server I'm using?
dct:issued "2015-07-29T10:01+02:00" ;
dct:modified "2015-07-29T10:01+02:00" ;

Issued is the first time a publication was published in the catalog
Modified is the last date of a publication in the catalog
I'm trying to fix the problem when there are no resources published

The hour difference is probably a server error: all hours listed on that IPT are off by one hour.


Unexpected behavior with add_list_member and add_list_members

I'm getting a Twitter::Error::Forbidden but that can't be right.
Given a client that's been initialized using "Read and Write" credentials I get the following:
pry(main)> list = client.create_list("test")
=> #<Twitter::List id=123412341234>
pry(main)> client.add_list_member(list, "xanderstrike")
Twitter::Error::Forbidden: You aren't allowed to add members to this list.
from /Users/pivotal/.rbenv/versions/2.5.5/lib/ruby/gems/2.5.0/gems/twitter-7.0.0/lib/twitter/rest/request.rb:97:in `fail_or_return_response_body'
pry(main)> client.add_list_members(list.id, ["xanderstrike"])
=> #<Twitter::List id=123412341234>

I can confirm in twitters UI that the list was created, but no users are added.
There's definitely an error here, either I have permission to add to the list but something is wrong with these two methods, or I don't have permission to the list I just created and add_list_members is failing silently.
Thanks!

Looks like the latter might be true, there's a secret undocumented account level rate limit for adding members to lists: https://twittercommunity.com/t/cant-add-members-to-a-list-code-104/25824/15
So I guess this issue becomes add_list_members fails silently on 403s. I spent a while trying to figure that out before I tried to add a single and saw the error.

Looks like the latter might be true, there's a secret undocumented account level rate limit for adding members to lists: https://twittercommunity.com/t/cant-add-members-to-a-list-code-104/25824/15
So I guess this issue becomes add_list_members fails silently on 403s. I spent a while trying to figure that out before I tried to add a single and saw the error.


About UCIR on CIFAR100

Thank you so much for your great work!
Recently, I attempted to reproduce UCIR model on CIFAR100. And I found the first run was perfectly fine, however, the performance dropped dramatically in the second and third run. After calculating the average points, the results are poor.
Here is the log:

2021-08-17:08:02:07 [train.py]: Results done on 3 seeds: avg: 43.24 +/- 7.77, last: 33.6 +/- 9.01, forgetting: 30.87 +/- 6.26
2021-08-17:08:02:07 [train.py]: Individual results avg: [49.33, 45.9, 34.49]
2021-08-17:08:02:07 [train.py]: Individual results last: [40.5, 36.9, 23.4]
2021-08-17:08:02:07 [train.py]: Individual results forget: [29.35, 25.51, 37.75]

Thanks for your time and consideration, and best wishes.

Hey,
Just so you know, the performance of my version of UCIR are not SotA, I've always been a few points behind the official code (that you can find on github).
Although, it's indeed weird that the first run seems ok but not the latter ones.

what is the setting 50-10? 50-1?
have you try to run independently each of the runs to see if there isn't a unwanted relation across runs?

Hello!
I have met the same problem. My setting is 50-10,160epoch. The results are [64.12, 60.82, 54.92], which is farly lower than reported in the paper of UCIR and in your paper. I have no idea why.
thanks!

My version of UCIR is not perfect. If you find a way to improve it, please tell me.
But beware that the "UCIR" results in my paper were get from the official code.

@arthurdouillard I realise the drop of performance in the 2nd and 3rd run is due to the change in train_transforms within the iCIFAR100 dataset.
https://github.com/arthurdouillard/incremental_learning.pytorch/blob/0d25c2e12bde4a4a25f81d5e316751c90e6f789b/inclearn/lib/data/datasets.py#L27-L57
In particular, when color_jitter argument is not set, set_custom_transforms would pop the ColorJitter from train_transforms. However, the modified list persists even though the iCIFAR100 dataset is re-initialised at each run, that is, RandomHorizontalFlip and RandomCrop  would be popped out in the 2nd and 3rd run respectively. The issue no longer occurs after I change Line 42 to self.train_transforms = self.train_transforms[:-1] and  and the results seems to be more consistent across runs. Hope this helps.


'sort.Search()' can't get index 0 at 'f func(int) bool'

What version of Go are you using (go version)?
go version go1.13 darwin/amd64
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
What did you do?
Playground link: https://play.golang.org/p/f0E0SRNHj-5
and Output is
Origin : [{zig 40} {max 19} {sunny 18}]
1 {max 19}
2 {sunny 18}

The output should include 0 {zig 40}, but not.
What did you expect to see?
Origin : [{zig 40} {max 19} {sunny 18}]
0 {zig 40}
1 {max 19}
2 {sunny 18}

What did you see instead?
Origin : [{zig 40} {max 19} {sunny 18}]
1 {max 19}
2 {sunny 18}

I think this is not a bug, accordingly to the documentation of sort.Search is using binary search to find a the index i in [0, n) at which f(i) is true, so it doesn't need to evaluate all the values only a subset of them.

What @jespino said. You are not even searching for a value, the function just blindly returns false.
If you have further questions, please feel free to ask it in any of these forums below:

Stack Overflow with questions tagged "go"

The Go Forum, a web-based forum

Gophers Slack, use the invite app for access. The #general channel is a good starting point.

Go Community on Hashnode with questions and posts tagged with "go"

The golang-nuts mailing list

IRC channel #go-nuts on Freenode

Thanks


VOID_TAGS tag check now using toLowerCase.

Could be useful in case someone time traveled from the 90's. :)

thx


Undo monorepo conversion

This is essentially one big "CTRL+Z" for the things that have been done in https://github.com/CesiumGS/3d-tiles-tools/pull/64 . The goal is to eventually have a single 3d-tiles-tools package, because there have been some open questions about establishing an organization called 3d-tiles-tools on NPM for publishing the scoped @3d-tiles-tools/... packages.
For now, the contents of the workspaces/packages are moved back into a "flat" src folder. The build infrastructure (i.e. the individual tsconfig.json and package.json files) is removed. Further details will be added here soon.

The conversion back to a "not-monorepo" is done.
The original workspaces/packages have been moved back into the top-level /src folder.

Some details:
The directory structure within this folder might look a bit unusual at the first glance: There are files like
src/base/base/Buffers.ts or
src/ktx/ktx/KtxUtility.ts
The reason for that is that the first subdirectory corresponds to the "package name", and the second subdirectory level reflects the structure within that package. Each of the first subdirectory levels contains an index.ts file, like
src/base/index.ts
that exports the "API". One reasoning behind that is that cross-package imports can be written in the form
import { BinaryBufferStructure } from "../../base";
which at least more closely resembles the
import { BinaryBufferStructure } from "@3d-tiles-tools/base";
from the packaged version. The alternative would be to descend into the respective subdirectory within the "package", as in
`import { BinaryBufferStructure } from "../../base/binary/BinaryBufferStructure";
Whether or not this really makes sense or is a good practice? I'm open for comments here...

I tested running the npm install and npm run package scripts (multiple times...).
I've tried out using the resulting package as...

a basis for installing an running the tools as a command line application
a dependency in a CommonJS JavaScript project
a dependency in a ESM JavaScript project
a dependency in a CommonJS TypeScript project
a dependency in a ESM TypeScript project
a dependency for the 3d-tiles-validator.... which actually required zero code changes.

I also ran all demos, and did a short review/cleanup pass of the README and IMPLEMENTATION, and have been ballsy enough to already put a release date into the CHANGES.md. Let's see how this goes...


Command line interface with param?

Is this within scope of param, wrapper for argparse?

Completely within the scope. We have had several partial versions of this over the years, none ever polished enough to include, but that's just because we've never had the time to focus on it and finish it! So yes, please do defer to the existing issue, and if you want to work with us on adding such a capability, please let me know!

Would love to help out in the near future, but not sure how it would be structured /get started. Would all params just inherit a cli keyword which activates the CLI?


Add content type definition at list level

In the current schema pnp:listInstance allows to reference content types defined at site level in the pnp:ContentTypeBindings element. There is no option to define content types at list level, which is currently supported by SharePoint, which includes adding list-level columns to such content types.

This restricts from replicating of existing functionality during migrations. Re-defining of content types at site level doesn't work in all cases, e.g. when the content type is referencing fields defined at list level, and a field with exactly the same internal name exists in another list. The field GUIDs would also clash (see Issue #192).
It also causes errors in Get-PnpSiteTemplate.
In the following example, pay attention to the content type RFE:

In the exported template the RFE content type 0x0120D520008CD19F86358D0F48945657A43A020469 becomes 0x0120D520 (Document Set), and the default content type becomes 0x0101 (Document)

And, the default content type should be RFE, which is a document set, not a document.

To overcome the limitations and address the issues, the following will be required:

Add pnp:ContentTypes  element to pnp:ListInstance
Update core library to export content types defined at list level that reference fields defined at list level
Update core library to create content types defined at list level

Related: Issue  #185

Uh oh. Ran into this as well. I need to add a field to a list content type, not the site content type. This seems impossible right now?

@Ruslan-Urban @PaoloPia @heinrich-ulbricht this still an issue right?
I am trying to set default view to content type which is also document set to different default view as for document library default one.
It seems in contentype schema were is line:
<wpv:WelcomePageView xmlns:wpv="http://schemas.microsoft.com/office/documentsets/welcomepageview" ViewId="e5059152-5e4e-418c-8c2e-7c4094fb77e1" />
is were a way to change it via powershell during provisioning?

@Ruslan-Urban @PaoloPia @heinrich-ulbricht this still an issue right? I am trying to set default view to content type which is also document set to different default view as for document library default one. It seems in contentype schema were is line: <wpv:WelcomePageView xmlns:wpv="http://schemas.microsoft.com/office/documentsets/welcomepageview" ViewId="e5059152-5e4e-418c-8c2e-7c4094fb77e1" />
is were a way to change it via powershell during provisioning?

I am trying to attempt the same.
I would like a PS script to update or set the Document Set > Welcome Page View > ViewId
I tried updating the SchemaXML but it is read-only.
Any help is appreciated.


Generate SQL for column with comment creates invalid DDL

System information:

OS: Linux Mint 20
DBeaver version: 21.0.2 EA

Connection specification:

Database: Postgresql 12

Describe the problem you're observing:
Function Generate SQL DDL for any column (with comment) creates invalid DDL - with semicolon inside comment.
Steps to reproduce
Use any table, for example
CREATE TABLE public.testtable (
	id serial NOT NULL,
	testchar varchar NULL,
	CONSTRAINT testtable_pkey PRIMARY KEY (id)
);
COMMENT ON COLUMN public.testtable.testchar IS 'this is my comment';

Try to get DDL only for column testchar (right click on column, Generate SQL). The result SQL is:
ALTER TABLE public.testtable ADD testchar varchar NULL -- this is my comment;
COMMENT ON COLUMN public.testtable.testchar IS 'this is my comment';

Notice, that in ALTER TABLE statement, the semicolon is now part of the of the (useless) SQL -- comment. The whole 2 line SQL can't be simply executed, because the first SQL statement has no proper ending.
The semicolon should be before the -- comment:
ALTER TABLE public.testtable ADD testchar varchar NULL; -- this is my comment
COMMENT ON COLUMN public.testtable.testchar IS 'this is my comment';

or comment (on first statement) should be removed
ALTER TABLE public.testtable ADD testchar varchar NULL;
COMMENT ON COLUMN public.testtable.testchar IS 'this is my comment';

Thanks for the bug report @elring
We will fix it in next releases.

Fixed in DBeaver 21.1.0
Will be available here on 2021-05-31 (edited)

Verified


Add scala.Any and Object to the list of "object" types

This addresses #281, as discussed in gitter.

Codecov Report

Merging #282 into master will not change coverage.
The diff coverage is 0%.

@@          Coverage Diff          @@
##           master   #282   +/-   ##
=====================================
  Coverage       0%     0%
=====================================
  Files          59     59
  Lines        1451   1451
  Branches      145    142    -3
=====================================
  Misses       1451   1451

Impacted Files
Coverage Δ

src/main/scala/org/scalastyle/Checker.scala
0% <0%> (ø)
: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 bb0218e...f111b46. Read the comment docs.

Hey @nrinaudo,
It would be great if you add a test case for this pr as well.

@canoztokmak happy to. The reason I haven't is because I looked, and couldn't find, an existing test for isObject on which to piggy-back.
Did I miss it, or is it just not there and you'd like to use the opportunity to add it?

I'll add the test case when I merge the PR.
Thanks.

Thanks!


Specify return message if there's no global auth

[08:13] +Rhythms: panpawn
[08:13] +Rhythms: can i take over https://github.com/Zarel/Pokemon-Showdown/pull/2077
[08:13] +Rhythms: if you're working on that other PR or smth
[09:21] +panpawn: yes Rhythms


add windows support for container tasks

Added a new method to attempt to detect Windows agents and download an appropriate version of pack which is unpacked using PowerShell 7

Attempts to resolve #6

@icornett Hey Ian, thanks again for making this change -- I just opened a PR with a bunch of miscellaneous changes from a variety of feedback sources, and bundled this change into it (since I had to tweak a few things): https://github.com/Azure/container-apps-deploy-pipelines-task/pull/10
The commit specific to your changes (and the corresponding issue you filed) can be found in this commit: https://github.com/Azure/container-apps-deploy-pipelines-task/pull/10/commits/c4e6839c6bb66ea4bd8fdd847b93b865b78e17cd
I was going to close this PR in favor of the one I linked above, but wanted to make sure it was OK with you and that you felt your contributions to the task weren't getting lost. Just let me know!

Sounds good to me


Table rendering is failing

using commonmark-ext-gfm-tables:0.7.0 with the following input. It actually produces nothing.

| Module 	|Javadocs 	|
| ------ 	|-------- 	|
| gradle-fury-validation 	| [Javadocs](javadocs/gradle-fury-validation/index.html) 	|
| hello-gradhell 	| [Javadocs](javadocs/hello-gradhell/index.html) 	|
| hello-universe-lib 	| [Javadocs](javadocs/hello-universe-lib/index.html) 	|
| hello-world-aar 	| [debug](javadocs/hello-world-aar/debug/index.html) 	 |
| hello-world-aar 	| [release](javadocs/hello-world-aar/release/index.html) 	 |
| hello-world-lib 	| [Javadocs](javadocs/hello-world-lib/index.html) 	|
| hello-world-war 	| [Javadocs](javadocs/hello-world-war/index.html) 	|

I've tried adding more whitespace, removing the links, removing the leading and trailing pipes. What am I doing wrong?
            List<org.commonmark.Extension> extensions = new ArrayList<>();
            extensions.add(org.commonmark.ext.gfm.tables.TablesExtension.create());
            extensions.add(org.commonmark.ext.gfm.strikethrough.StrikethroughExtension.create());
            extensions.add(org.commonmark.ext.autolink.AutolinkExtension.create());
            Parser parser = Parser.builder().extensions(extensions).build();

            Node document = parser.parse(contents);
            HtmlRenderer renderer = HtmlRenderer.builder().build();
            String contents = renderer.render(document);  // document is the content above

The extensions also need to extend the HTML rendering part. In your code, it looks like you only add them when building the parser. Try creating the HtmlRenderer like this:
HtmlRenderer renderer = HtmlRenderer.builder().extensions(extensions).build();

awesome that fixed it! consider adding that to the wiki or readme.  You sir, rock

Phew 😅
The example code here shows it: https://github.com/atlassian/commonmark-java#extensions
Any ideas how I can make it stand out more?

wow, i don't know how i missed it. I think i started with https://github.com/atlassian/commonmark-java#parse-and-render-to-html and didn't just didn't notice the difference. Thanks for the quick response

I've wrapped the lines now, maybe that makes it stand out more: add7fee8fd267a6365d1b08c1a3c01f9c0da716a

fantastic, thanks again. I'm using this to build a maven site plugin for gradle. Much appreciated


Unable to load a model file to Azure blob storage

Unable to load a model file to Azure blob storage.
from azure.storage.blob import BlobClient
sas_url = "https://account.blob.core.windows.net/container/blob-name?"
blob_client = BlobClient.from_blob_url(sas_url)
Upload the created file
with io_open(file=model, mode="rb") as data:
blob_client.upload_blob(data)
I keep getting error while trying to upload the model file to blob storage

Thanks for reporting issue pls provide the repro steps.or u can share here in privately:https://github.com/Azure/azure-functions-host/wiki/Sharing-Your-Function-App-name-privately


the flake.lock icon has become oversized

For context, the icon is serval sizes too big compared to others, however other nix files remain constant and accurate, see image below

In case its needed, the IDE is rustrover.

By looking at the SVG, it seems like an issue upstream:

Nix https://github.com/catppuccin/vscode-icons/blob/91f4dd575c4b304d0e915d112d27d205cd7ad322/src/icons/nix.svg?short_path=c4a0b86
Nix Lock https://github.com/catppuccin/vscode-icons/blob/91f4dd575c4b304d0e915d112d27d205cd7ad322/src/icons/nix_flake_lock.svg?short_path=3032ed2

(by the way is that normal that the nix lock is slightly larger than the .nix one?)

Any update for this issue?

Any update on this issue?

PR #15 opened yesterday might fix this issue; a release will follow

Fixed with #16


Customize PlaybackControlView better handling on TVs

The default playbackcontrolview does not handle TV Overscan so need to add the necessary padding.

This has been fixed.


Dec 260

I updated the layout to display the about text from beehive.
To do this I updated the info component to take the collection hash as a prop.  I also added a new component for the collection footer and added it all the pages.

@danthewolfe I did.  The problem is with the asset pipeline it will compile the images and give them a name unique name.  Since we don't know what the names of the image is going to be I moved them to the public directory so I could reference them form the react classes

@jonhartzler Ok, I just wanted to double check that we didn't have 2 copies of the same image floating around.
:+1: :shipit: