Use Generator Expressions Instead of List Comprehensions

Imagine that someone handed you a pile of 100 apples and then asked you to count how many of them were green without putting any of them down. You'd probably find this quite challenging and you'd struggle to hold the pile of apples at all. Now imagine someone handed you the apples one at a time and asked you to just count the green ones. This would be a much easier task.
In Python, when we use list comprehensions, it's like we've created the entire pile of apples and asked the interpreter to hold onto it. Sometimes, a better practice involves using generator expressions, which create iterators that yield objects one at a time. For large data sets, this can turn a slow, memory intensive operation into a relatively fast one.
Using generator expressions instead of list comprehensions can lead to better performance. This is especially true for functions such as any where it's not always necessary to evaluate the entire list before returning. For other functions such as max or sum it means that the program does not need to store the entire list in memory. These performance effects becomes more noticeable as the sizes of the lists involved grow large.
This codemod replaces the use of a list comprehension expression with a generator expression within certain function calls. Generators allow for lazy evaluation of the iterator, which can have performance benefits.
The changes from this codemod look like this:
- result = sum([x for x in range(1000)])
+ result = sum(x for x in range(1000))

More reading

https://pylint.readthedocs.io/en/latest/user_guide/messages/refactor/use-a-generator.html
https://docs.python.org/3/glossary.html#term-generator-expression
https://docs.python.org/3/glossary.html#term-list-comprehension

Powered by: pixeebot (codemod ID: pixee:python/use-generator)

FYI - This change was autogenerated from a new trending GitHub app - called Pixeebot. A code-quality GitHub App; like Dependabot, but for source code.

Any chance you've had the time to review these changes?
If you're not interested implementing them at this time, no worries. I can close the PR and follow up with additional changes in the future. Also, this plugin is free for non-commercial open sourced projects, so feel free to give it an install if you want to see the other recommended PRs.
Thanks,
Zach


[5.7-04252022] Add ability to hide deprecated items in the Navigator

Rationale: Add tag to hide deprecated items in the Navigator
Risk: Medium
Risk Detail: Adds a new filtering method, on top of the already complex filtering
Reward: High
Reward Details: Users will now be able to filter out any deprecated items
Original PR: https://github.com/apple/swift-docc-render/pull/251
Issue: rdar://92735740
Code Reviewed By: @marinaaisa @biamx3
Testing Details:

Assert you can see Hide Deprecated as a tag.
Assert that picking it, hides all deprecated items.

@swift-ci test

@swift-ci test


Add some new versions

2.095 is still the main compiler in stable channel, so that's an easy add. I would also like to support some older versions, 2.088, 2.084, perhaps even older.

Fixed. I might add 2.080 and 2.076 someday, as to be frontend compatible with GDC versions that are still written in C++. Not that high priority though.


Adding back button to Maker studio

Hey @MrRishabhJain good to see the PR but I think let's mark it as 'Draft' PR at the moment.

this is now a shipped funtionality - closing this PR out.


Break dependency links by default

https://toil.kitemaker.co/2hAmxC-atopile/dSlNKj-atopile/items/110

Ran ato install esp32-s3

Did you try just the once? This doesn't seem related and I wonder if there was a delay to the server or something instead?


bug: protobuf not installed with docarray[common]

I was trying something like:
docs.push('file://books.docarray')

And I got the following error:
ImportError: The following required library is not installed: google.protobuf
To install all necessary libraries, run: `pip install "docarray[common]"`

After running pip install docarray[common] and retrying I get the same error. pip list | grep protobuf returns nothing.

@anna-charlotte can u take a look at the pip error message ? I think common does not exist anymore it should say pip install docarray[protobuf]

After installing protobuf and re-running, script seems to work fine, but no file is saved in the project directory.
However, books.docs (not books.docarray) is saved in ~/.cache/docarray

can u put a reproducible code example ?

Code example

You cannot put file extension in the push pull. Like for push pull to Jina AI cloud. Though we should probably raise an error instead of just removing the extension

This shouldn't be closed, File still gets saved to ~/.cache/docarray, not ./

I would say parse the path. file://foo would always refer to ./foo everywhere else I've seen it

This shouldn't be closed, File still gets saved to ~/.cache/docarray, not ./
this is expected as the default behavior.

The goal is to have the same experience with push pull to cloud that push pull locally. This means that you need to save, at least by default, into a common cache. If you just want to save to a file use save_bynari

fwiw @scott-martens thinks file:// would normally save to filesystem root

@Jackmin801 FYI

cache makes no sense for a protocl

I still don't understand why you are not using save_binary.
To me push pull is if you want to sync some data between two people on the same computer for instance, in this case you want to use cache as default.

Eh, I'll just use save_binary then. Just the push/pull file:// thing seems weird

What is the status here?

this is the expected behavior. Closing the issue


Only 2 resolution options with DASH Disabled - No 1080, 1440 or 4k options

Hello, I realise this has been mentioned already regarding there being no 1080p option with DASH disabled, but I also wanted to add that there is no 1440 or 4k options either.
Seamless 4k playback requires a pretty fast connection, above what any ADSL line can provide, so if YouTubeCenter could be updated and modernised to allow 1440 and 4k options with DASH disabled to allow users to pre-load (buffer) the entire video, that would be fantastically amazing.
Kudos to you for this add-on, good stuff 👍

You cannot write the addon to support those video formats, because they do not exist on YouTube servers to begin with. Sorry.

Oh ok, sorry I wasn't aware of that. Thank you for the super fast reply.


an issue about train and test

Thank you for your work! In your paper, you mentioned that we don't need to fine-tune or train for new classes. I don't understand how this is achieved. Does it mean that your pre-trained model can directly predict new classes? Also, what do you mean by "aggregated training" that you mentioned? In the code, if we want to train, we have to specify a certain class (obj), but I don't understand. I look forward to your reply!

If you choose a specific class (obj) during training, all data from this class will be excluded from the training set (see Line-123 in mvtec.py). Then this model will be tested using this specific class during testing, to evaluate the performance encountering the new class. That is the only reason why we need to choose a specific class.

Thanks very much for your response! I understand now!


[SMALLFIX] Java 8 improvement: replace lambda with method reference

Java 8 improvement: replace lambda with method reference in /alluxio/core/common/src/main/java/alluxio/security/authentication/DefaultAuthenticationServer.java#DefaultAuthenticationServer

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/3185/
Test FAILed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/3186/
Test FAILed.


cannot run local lambda environment

I can run the project in dev, i can build and deploy it but whenever i run pnpm dlx sst dev to try lambda live development i get hit with this error
SST v2.40.1  ready!

➜  App:     app
   Stage:   al
   Console: https://console.sst.dev/local/app/al

✖  Checking for changes
   Error: Project not initialized
       at useProject (file:///home/al/Code/mono/node_modules/.pnpm/sst@2.40.1_@aws-sdk+credential-provider-node@3.507.0/node_modules/sst/project.js:21:15)
       at SsrFunction.bind (file:///home/al/Code/mono/node_modules/.pnpm/sst@2.40.1_@aws-sdk+credential-provider-node@3.507.0/node_modules/sst/constructs/SsrFunction.js:193:56)
       at new SsrFunction (file:///home/al/Code/mono/node_modules/.pnpm/sst@2.40.1_@aws-sdk+credential-provider-node@3.507.0/node_modules/sst/constructs/SsrFunction.js:55:14)
       at createServerFunctionForDev (file:///home/al/Code/mono/node_modules/.pnpm/sst@2.40.1_@aws-sdk+credential-provider-node@3.507.0/node_modules/sst/constructs/SsrSite.js:198:20)
       at new SsrSite (file:///home/al/Code/mono/node_modules/.pnpm/sst@2.40.1_@aws-sdk+credential-provider-node@3.507.0/node_modules/sst/constructs/SsrSite.js:84:41)
       at new AstroSite (file:///home/al/Code/mono/node_modules/.pnpm/sst@2.40.1_@aws-sdk+credential-provider-node@3.507.0/node_modules/sst/constructs/AstroSite.js:20:9)
       at EmptyStack.Site (file:///home/al/Code/mono/apps/app/.sst.config.1707307343565.mjs:16:20)
       at stack (file:///home/al/.local/share/pnpm/store/v3/tmp/dlx-419322/node_modules/.pnpm/sst@2.40.1_@aws-sdk+credential-provider-node@3.507.0/node_modules/sst/constructs/FunctionalStack.js:20:35)
       at App.stack (file:///home/al/.local/share/pnpm/store/v3/tmp/dlx-419322/node_modules/.pnpm/sst@2.40.1_@aws-sdk+credential-provider-node@3.507.0/node_modules/sst/constructs/App.js:500:16)
       at Object.stacks [as fn] (file:///home/al/Code/mono/apps/app/.sst.config.1707307343565.mjs:15:9)
       at synthInRoot (file:///home/al/.local/share/pnpm/store/v3/tmp/dlx-419322/node_modules/.pnpm/sst@2.40.1_@aws-sdk+credential-provider-node@3.507.0/node_modules/sst/stacks/synth.js:56:24)
       at async Module.synth (file:///home/al/.local/share/pnpm/store/v3/tmp/dlx-419322/node_modules/.pnpm/sst@2.40.1_@aws-sdk+credential-provider-node@3.507.0/node_modules/sst/stacks/synth.js:19:16)
       at async build (file:///home/al/.local/share/pnpm/store/v3/tmp/dlx-419322/node_modules/.pnpm/sst@2.40.1_@aws-sdk+credential-provider-node@3.507.0/node_modules/sst/cli/commands/dev.js:162:38)
       at async file:///home/al/.local/share/pnpm/store/v3/tmp/dlx-419322/node_modules/.pnpm/sst@2.40.1_@aws-sdk+credential-provider-node@3.507.0/node_modules/sst/cli/commands/dev.js:300:13
       at async Promise.all (index 0)
       at async Object.handler (file:///home/al/.local/share/pnpm/store/v3/tmp/dlx-419322/node_modules/.pnpm/sst@2.40.1_@aws-sdk+cr

currently have the project setup in a monorepo, i was able to recreate it
yes im running the command in the correct dir, im running pnpm dlx sst dev  in  mono/apps/app

How come the sst.config.ts is not at the root? For reference, here is the monorepo structure we recommend — https://github.com/sst/sst/tree/master/examples/quickstart-standalone

I saw this issue when using pnpm dlx. It got solved when using npx

I saw this issue when using pnpm dlx. It got solved when using npx

encountered this same issue but it works when using npx instead of pnpm dlx

Experiencing the same problem but on a Windows machine. Linux works fine but when we tried starting an existing project in Windows it crashed with this error after sst dev (version 2.41.2). The sst.config.ts is in the root of the repository, everything works fine on Linux.

We are transition this repo to https://github.com/sst/v2 and are closing this issue for now. If it is still relevant please reopen it there - sorry for the trouble


'soil' category doens't show up in documentation

The soil spectral indices are not listed in https://awesome-ee-spectral-indices.readthedocs.io/en/latest/list.html

Thank you for spotting it! I added them ;)


Auto Generate Types for Sanity GraphQL Queries

I'm going to close this for now. I really enjoy fine-grained control over my types for now. This may change as the codebase expands.

I'm going to close this for now. I really enjoy fine-grained control over my types for now. This may change as the codebase expands.


CVDP version update

There is a new version of the CVDP package:
https://github.com/NCAR/CVDP-ncl/releases
Due to the way the CVDP-package was included we need to basically update the new version manually (we chose not to use git submodules for it).

Addressed in PR  #1441


Chip size vs box with border

What are the issues this pull addresses (issue numbers / links)?
The changes are not linked to specific issues, but what they cover is detailed in the summary below.
Did you add tests to cover your changes (yes/no)?
No
Did you update the documentation accordingly (yes/no)?
Yes
Did you read the CONTRIBUTING document (yes/no)?
Yes
Summary
Most of this PR consists of refactoring the Ansys renderers, with a small part dedicated to the output of LOM analysis.
Details and comments
There are 2 ways to render chips into Ansys - by drawing one with fixed dimensions and central coordinates based on numerical values found in QDesign, or by drawing a buffer of fixed x/y width around the minimum bounding box around all rendered components. Before, the Ansys renderer would calculate the minimum bounding box regardless of which option was being used, but this is really only needed when drawing a box plus buffer. The PR fixes this and also contains an extensive refactoring of existing renderer code. A separate, smaller part of this PR changes LOM code to suppress output for all but the final pass.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@priti-ashvin-shah-ibm Have the concerned you raised earlier all been resolved?


Get Primitive Type From Table Type?

Is there a utility type available to get a primitive type from a table type?
Let's say I have this table:
interface PersonTable {
  id: Generated<number>;
  first_name: string;
  gender: 'male' | 'female' | 'other';
  last_name: string | null;
  modified_at: ColumnType<Date, string | undefined, never>;
}

How can I get this type from it?
interface PersonTable {
  id: number;
  first_name: string;
  gender: 'male' | 'female' | 'other';
  last_name?: string;
  modified_at: Date;
}

Use Case: I'd like to derive the types I use on the front-end from my table types.

Maybe exposing the type, AllSelection ?

try Selectable<Table> and SelectType<ColumnType> helpers.

@igalklebanov, thank you! With Selectable I can do the following:
type Person = Selectable<PersonTable>;


Further changes to documentation endpoints

Last round for now.
See #311 and other one-off notes here.  Some APA style(-ish) citations are included but there's a few more to extract.  For datasets we don't "own" in some way (fully external), check in on how to handle those separately from those (see convo in Slack etc).
Re-review API Sept 8
Beetles:

Ideally, add temporal source resolution to intro  “annual model, summarized by era here” etc.
Needs link to source dataset (why isn’t this published yet on our catalog, someone needs to own that)

Degree days:

Replace “link” with standard academic paper citation format (APA why not)

Bieniek, P. A., Bhatt, U. S., Walsh, J. E., Rupp, T. S., Zhang, J., Krieger, J. R. & Lader, R. (2016).  Dynamical Downscaling of ERA-Interim Temperature and Precipitation for Alaska.  Journal of Applied Meteorology and Climatology, 55(03), 635-654.  https://doi.org/10.1175/JAMC-D-15-0153.1

Design index:

Same as for Degree days otherwise OK

Elevation:

Remix slightly ‘cos we have a pretty old white paper but not necessarily anything newer.  Potentially we just decide, the ASTER dataset is well-known enough to not merit anything further.
NASA/METI/AIST/Japan Spacesystems and U.S./Japan ASTER Science Team (2019). ASTER Global Digital Elevation Model V003 [Data set]. NASA EOSDIS Land Processes Distributed Active Archive Center. Accessed 2023-09-08 from https://doi.org/10.5067/ASTER/ASTGTM.003

ALFRESCO

Switch to APA format
(Ticket for later) #312

Geology

Just link to the USGS stuff they have all the releases and it’s fewer links for our stuff to break.

Glaciology

Remove this endpoint #296

Landfast Ice — OK, will revise this in the future
Mean Annual Precipitation

Remove this endpoint #313

Permafrost

Use APA citation style
Remove all references to GIPL1.0 data

Physiography — just link out to their website, don’t include specifics.  Consider renaming this to “ecoregions.”  Also consider removing it?
Sea Ice

Use APA citation style

Snow
APA citation style

Temp/Precip

APA citation style

Wet Days per Year

APA citation style

Wildfire

We don’t own many of these datasets to “link to source” is fair in many cases.  Discuss.

Some citations,

Bieniek, P. A., Bhatt, U. S., Walsh, J. E., Rupp, T. S., Zhang, J., Krieger, J. R. & Lader, R. (2016).  Dynamical Downscaling of ERA-Interim Temperature and Precipitation for Alaska.  Journal of Applied Meteorology and Climatology, 55(03), 635–654.  https://doi.org/10.1175/JAMC-D-15-0153.1

NASA/METI/AIST/Japan Spacesystems and U.S./Japan ASTER Science Team (2019). ASTER Global Digital Elevation Model V003 [Data set]. NASA EOSDIS Land Processes Distributed Active Archive Center. Accessed 2023-09-08 from https://doi.org/10.5067/ASTER/ASTGTM.003

Johnstone, J. F., Rupp, T. S., Olson, M. & Verbyla, D. (2011).  Modeling impacts of fire severity on successional trajectories and future fire behavior in Alaskan boreal forests.  Landscape Ecology, 26, 487–500.  https://doi.org/10.1007/s10980-011-9574-6

Marchenko, S., Romanovsky, V., & Tipenko, G. (2008). Numerical modeling of spatial permafrost dynamics in Alaska.  Ninth International Conference on Permafrost, Online Proceedings, Volume 2, 1125–1130.  Accessed 2023-09-08 from https://www.permafrost.org/event/icop9/

Jorgenson, M., Yoshikawa, K., Kanevskiy, M., Shur, Y., Romanovsky, V., Marchenko, S., & Jones, B. (2008). Permafrost Characteristics of Alaska + Map. Ninth International Conference on Permafrost, Online Proceedings, Volume 1, 121–122.  Accessed 2023-09-08 from https://www.permafrost.org/event/icop9/

Obu, J., Westermann, S., Kääb, A., & Bartsch, A. (2018). Ground Temperature Map, 2000-2016. Northern Hemisphere Permafrost. Alfred Wegener Institute, Helmholtz Centre for Polar and Marine Research, Bremerhaven, PANGAEA, https://doi.org/10.1594/PANGAEA.888600

John E. W., Florence F., Scott S. J., & William C. L. (2017). A database for depicting Arctic sea ice variations back to 1850, Geographical Review, 107(1), 89–107, DOI: 10.1111/j.1931-0846.2016.12195.x

Closed in #324


Make App Bar and Nav Drawer configurable zone widgets

Currently they are both part of Layout. We should replace those with zones and allow them to be added if needed.

Closes #160


Ahn nath/cache option apis

Closes #294
We have explored a caching option with the library axios-cache-interceptor to “cache API calls to reduce the number of credits we use”. For this caching option we need to see the lifetime of a cached response, a way to persist the day permanently and across different user sessions and, keep in mind, the margin to consider for cutting expenses.

[x] Add pull request description
[x] Add persistent storage
[x] Set options to invalidate cache and the lifetime of a cached response

Description of relevant aspects:
Set options to invalidate the cache and the lifetime of a cached response
To define a limit or deadline for a cached response to be valid and updated, we make use of the property "ttl", as part of the “per request configuration”. We set it to the reasonable time limit of 1 week in milliseconds: 604800000.
// The time until the cached value is expired in milliseconds.
    ttl: 1000 * 60 * 10080,

Source: https://axios-cache-interceptor.js.org/#/pages/per-request-configuration?id=cachettl
Add persistent storage
The lifetime of a request will only make sense and work if we use persistent storage. There are several options they provide, such as:

In memory: that will not be persistent and will easily be lost with a page reload.
Web storage: it has sessions and across sessions (works with a browser Window and dies as soon as it is closed)
Custom storage: which can last more time.

I am not considering using a database. Instead, I think we can use documents that are stored in the file system for persistence or variables that are initialized once during the server lifetime. I am using a Map structure that is working with the buildStorage function of the library.
Considerations:

If the app/amplify project uses several servers to work with the representatives' data, libraries that help you persist the data elsewhere may be a better option, such as Node Redis. Now, this simpler solution can prevent the complexity such a library would add and provide a working option that fits our case. I am open to your comments and suggestions if my judgment is incorrect.

I discussed with my mentors that in some cases, when important data changes, we may need to update the website data as soon as possible, and not wait until the scheduled time to refresh the API comes. Such a case is when we need to send a letter and require a valid address. In those cases, as suggested by my mentors @thyeggman and @paramsiddharth, an alternative would be to make a real API call and update the caching storage as per demand, or when the user triggers the function responsible for sending the letter.

Results and the effect of this implementation

On average, we could assume that I make 9 calls per day, with a total of 63 calls per week. If we are only making real API calls (updating the cache) once a week, that is, only making one call to the API per week, we are using, roughly, 1.58% of the current average. For that case, we would be cutting 98.5% of our weekly use.

@thyeggman Hey Jacob! I think #296 should be completed before we start writing the tests for this update. Maybe we can also have optional tests that use the actual Cicero API instead of the mocked version that will be made in #296.

Then, if I understand correctly, this PR can be approved once the other
issue is closed, correct?
El vie., 28 de octubre de 2022 10:49 p. m., Param Siddharth <
@.***> escribió:

@thyeggman https://github.com/thyeggman Hey Jacob! I think #296
https://github.com/ProgramEquity/amplify/issues/296 should be completed
before we start writing the tests for this update. Maybe we can also have
optional tests that use the actual Cicero API instead of the mocked version
that will be made in #296
https://github.com/ProgramEquity/amplify/issues/296.
—
Reply to this email directly, view it on GitHub
https://github.com/ProgramEquity/amplify/pull/373#issuecomment-1295698276,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQBB52UEKBCLK4REWYK4P53WFSGELANCNFSM6AAAAAARPRYJEE
.
You are receiving this because you were mentioned.Message ID:
@.***>

Then, if I understand correctly, this PR can be approved once the other issue is closed, correct? El vie., 28 de octubre de 2022 10:49 p. m., Param Siddharth < @.> escribió:
…
@thyeggman https://github.com/thyeggman Hey Jacob! I think #296 <#296> should be completed before we start writing the tests for this update. Maybe we can also have optional tests that use the actual Cicero API instead of the mocked version that will be made in #296 <#296>. — Reply to this email directly, view it on GitHub <#373 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQBB52UEKBCLK4REWYK4P53WFSGELANCNFSM6AAAAAARPRYJEE . You are receiving this because you were mentioned.Message ID: @.>

@ahn-nath Yes. However, there are some changes requested. You'll need to make them before the PR is ready to merge. :) But you can look at it once you are back from the conference.

As request by my mentor, Jacob, I have added some tests to guarantee that the library works as expected. 3 tests were added.
Description
1. we test that the configuration we set is valid and available to check
In this test, we just want to check that the configuration of the Axios instanxe is properly configured and that the contents of the instance change.
describe('test Axios configuration', () => {
  test('tests argument composition', () => {
  . . .
 })
})

2. we test that the cache is working as expected with concurrent requests
In this test, we check that the library/interceptor in successfully caching responses, and we also test that it is able to do it with concurrent requests.
describe('test Axios cache with concurrent requests', () => {
  test('tests cache', async () => {
    . . .
  })
})

3. we test that the cache is invalidated when the ttl expires
In this test, we set a time for when the caching/cache response will be invalidated and no longer cached. We set the expiry time to 10 sec and make a request after 10 sec from that statement to validate that the response is no longer cached.
describe('test Axios cache invalidation option', () => {
  test('tests cache invalidation', async () => {
  . . .
  }, 70000)
})

Looking forward to your thoughts and review @thyeggman, @paramsiddharth.

@ahn-nath I added a comment. Please check it out. :) Thank you.

Checked 👍


Updating readme with "no guarantee" blurb

@louiskearns @mhashemi86 @girasquid

Could use a squash, looks good.


Update localization.md for new macro-enabled loc machinery

Thanks for keeping our internal docs updated!


Fix wrong content type

fixes: #15

Hi @HugoSay
Thanks for your PR. As explained in our doc, the expected Content-Type is text/plain.
Could you please change it?
Thanks!

Hi,
Thank you for your response. However, I believe there might be a misunderstanding.
In actuality, the SDK is sending data in JSON format, which is further corroborated by the behavior of the Android SDK, which indeed sets the Content-Type to application/json.
I understand from the documentation that text/plain is the expected Content-Type, but from the behavior of both SDKs, it appears this may not be entirely accurate.
Based on these observations, it seems the backend may not be considering this header at all. This discrepancy only surfaces when setting another collection domain, leading to issues.
Given this, I would suggest that we consider updating the documentation to reflect this more accurately, as it could potentially lead to confusion and misconfiguration.


feat: add custom ListBuilder with filters

Signed-off-by: Riccardo Fiorenza<EMAIL_ADDRESS>Fixes: https://github.com/platformatic/platformatic/issues/347

I have replaced ListGuesser (react-admin component) with ListBuilder (custom component).
I would like improve ListBuilder about relations between entities before to switch this PR from 'draft' to 'ready-to-merge'.
I would implement a logic to detect relation between entities (based on "entity names" and "field names"), so that also ListBuilder can add links on foreign keys for cross-entity navigation from records, like ListGuesser do.
Example:

Field CategoryId should be detected as foreign key for the entity Category that have field Id as primary key.

The ListBuilder component implementation in this PR add also a feature to select the fields to show in the List Datagrid.

I close this PR because is outdated (see #410)


Remove azurestack-common

It wasn't actually being used anyways

@sachinma I don't think this should cause any problems, can you confirm as the AzureResourceGroupDeploymentV2 codeowner?

Looks good to me. I will also let @Ajay-MS confirm.

Looks fine to me.


feat(process): expose writablestream

fix #677, #LISTR2-260 Done

Codecov Report

Merging #678 (dde145d) into master (fd7d16f) will not change coverage.
The diff coverage is n/a.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@           Coverage Diff           @@
##           master     #678   +/-   ##
=======================================
  Coverage   85.84%   85.84%
=======================================
  Files          37       37
  Lines         904      904
  Branches      227      227
=======================================
  Hits          776      776
  Misses         90       90
  Partials       38       38

Impacted Files
Coverage Δ

src/lib/task-wrapper.ts
72.41% <ø> (ø)

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Bump etcd version to one greater than 3.2.18

Ran swizzle with kubeadm preflight checks enabled, which resulted in an error:
[ERROR ExternalEtcdVersion]: this version of kubeadm only supports external etcd
version >= 3.2.18. Current version: 3.2.10

The latest etcd release is v3.3.12. Bump up the default etcd version in the etcd role.

Superceeded by #181


Design Discussion: ActivityPub support + ForgeFed vocabulary

#1612 discusses Federation in general but I wanted to open an issue for the ActivityPub + ForgeFed solution specifically and concretize this unit of work. Let's keep to discussing ActivityPub+ForgeFed design specifics here, and have the question "whether it should be ActivityPub+ForgeFed at all" discussed in the other issue (#1612).
Background
I work on the go-fed suite of ActivityPub related libraries, sites, and tools. So my knowledge is more centered on the AP/ForgeFed angle, but as I've only spent light amount of time with the Gitea code I'm not comfortable making the changes required, especially w/o without serious design discussions. And I'm not here to shill go-fed as being the solution, it just provides a solution, as there are reasons to pick it entirely, partly, or not at all. I'll try to keep the evangelization to a minimum and self-contained, at the very end.
(Optional, Time-Sensitive) Grant Opportunity
There is a limited-time opportunity for this work to be submitted as a grant to the NLNet folks via the NGI Search & Discovery grant (5-50k euros) or DAPSI grants (50k+ euros?). There is never a guarantee a grant will be selected to receive money, but given the slate of other Fediverse projects that have gotten funding via the NGI S&D, I think this is a great exercise. There is the possibility that the EU will extend certain NGI funding periods for further cycles, but it is not guaranteed.
Concretely, would need 1 or more Gitea community member volunteers interested in taking the lead on those. I personally am applying separately for other projects, so I don't have time / energy to push this aspect forward, but happy to provide guidance where possible.
Community Standards
I believe the ForgeFed work is still ongoing. An outcome could be that this effort allows whoever wants to help to pioneer additional ForgeFed behavior and be a voice there. Additionally, depending how Gitea embraces ActivityPub in general, it may also have opportunities to create Fediverse Enhancement Proposals, so no matter what the volunteers will definitely get open-source community leadership opportunities.
Design
Overview
ActivityPub is based on the concept of actors exchanging activities. These activities tell federated peers how to update their view of the "Federated Web", which is a linked-data graph composed of different RDF ontologies. That's a jargon-y way of saying "data types are flexible, and have pointers to other pieces of data". ForgeFed is just one ontology focusing on Forge behaviors and entities. Peers are not expected to know how to interpret every single ontology on this Federated Web, so Gitea can just focus on a narrow one -- ForgeFed -- in addition to the basic ActivityStreams vocabulary that acts as a common language.
This does not prevent Gitea from adopting different ontologies later, if the project decided to support viewing/interacting with the other kinds of activities going on in the wider web. It is just not a requirement right now, in the spirit of keeping scope limited.
The ForgeFed spec outlines the actors and the data being exchanged. A subset of that data are activites which are shareable between actors. One actor can Create a Ticket (issue) and give it to a peer, who knows: "this data -- which happens to be an activity -- is a Create so I'll invoke my create behavior/function with the payload".
So if REST is...
POST to /issues/new with the body containing payload and a session_id containing authenticated credentials. This results in invoking the server's CreateIssue function with payload based on the user calling it.
...where REST scales by just creating more endpoints and using more HTTP verbs: POST and GET and PATCH to /repo, /merge-request, /repo
Then ActivityPub is...
POST to /actors/cj/inbox with an http_signature header and Activity payload. This results in invoking the server's WhatActivityIsThis function which determines the Activity is a Create, so it calls the CreateIssue function with the rest of the payload information based on the federated_peer_user calling it.
... where ActivityPub scales by just having new types of Activities (Create, Update, Offer, etc) and new data types that are acted upon (Person, Repository, Commit, Note, etc).
This means Gitea adopting ActivityPub will require a little bit of a different philosophical mindset than perhaps is common. Rectifying that, or isolating that, with the existing codebase is a core engineering challenge.
Therefore, at a high level, Gitea would need to support the following concepts:

Actors
Sending Activities
Receiving Activities
Serving ActivityStreams
Fetching ActivityStreams

...then can "First Federated Behavior" be reasoned about, as a penultimate section.
Let's concretely dive into what is required to do them. The "why"s might not come together until the "Fetching ActivityStreams" section. These sections are the things I can think off of the top of my head, it may be incomplete.
Note: This only goes into S2S federation and not C2S federation
Actors
ForgeFed only has suggested guidance for actors:

Person
Project
Repository
Group/Organization/Team

To support any of these, the following would need to be tackled:

Conceptually, mapping Gitea's concepts ("People", "Teams") into "Actor" concepts in the ActivityPub world, and just having the community aligned with these thoughts is a big step before anything else is done.
Mapping Gitea's actor concepts into the ontology. "What Gitea concepts are which ActivityStreams/ForgeFed types."
The Actor IRIs (at what URL's peers can fetch the actor document) are arbitrary. So mapping, say, a Gitea Repository actor to a /repository/actor/{id} IRI. Note: Existing IRIs can be re-used, so long as they respect the whole Accept / Content-Type headers for ActivityStreams content.
"Translation layer": how to map Gitea's existing database columns into the actual fields in the ActivityStreams document to serve. I put "translation layer" in quotes, because the design could be something else.
A new private key generated for users. Private keys are needed for signing federating request for HTTP Signatures, if Gitea wants to use this community-adopted standard. I strongly recommend sticking to it for interoperability and dont-shave-the-yak reasons. More on this later.
Managing inbox and outbox ordered collections. This one is the big doozy. Each actor basically has a "sent" and "received" queue, which means:

Backing storage in the database
User self-moderation capabilities (ex: block peers, delete receiving this message, etc)
Admin moderation capabilities (ex: block abusive peer Gitea instances, etc)

(optional, but strongly recommended) managing following and followers collections for actors. In addition to the previous concerns with the inbox and outbox:

curating followers lists (there is an option to manually approve followers), and how to manage that for things like a "Team" or "Repository" or "Project"
how to follow others (involves fetching the peer actor and presenting a UI)
implementing the Follow and Accept/Reject flow

(truly optional) managing the liked collection, if a "Team" or "Project" wants to star or favorite other items seen on the Fediverse. I'm unsure what this would look like in practice, but this could be an opportunity for someone wanting to play with UI/UX to do so.

Sending Activities
Sending activities is described in the ActivityPub spec. Unfortunately, it also explicitly relies on the C2S addressing, which must be kept in mind while implementing.
This both unblocks Gitea's ability to do any federated flow in the future, but alone is insufficient to do any specific federated flow.
To keep it succinct:

Mapping the actors' outbox to a concrete IRI, ex: /users/{id}/outbox, from which it can serve the outbox collection.
Addressing ("who am I sending it to")

recursive unwrapping of collections (to a specified depth)
deduplication and self-removal
stripping of sensitive fields (C2S)
Addressing normalization ("Automatically creating a Create activity") (C2S)
(optional, controversial) sharedInbox, alleviates the peer server if they're a massive instance

Adding to the actor's Outbox (and backing datastore)
Transport

HTTPS with HTTP Signatures (recall the actor's private key in the previous section), so being able to tell "who" is delivering the activity to the peer
Sets headers appropriately (doubly so due to HTTP Signatures)
Dereferencing peer actors to get their inbox and POSTing to there. See later on Dereferencing.
Bounded retrying of failed deliveries (and all those messy networking considerations)
Admin capabilities to manage this (prevent DoSing a peer, backlogged queues, etc)

Inbox Forwarding

detecting when to do it
determining who to forward to

Receiving Activities
Receiving activities is the second half:

Mapping the actors' inbox to a concrete IRI, ex: /users/{id}/inbox, from which it can serve the inbox collection for a GET request (if desired), or receive federated peer POST requests.
Verification of HTTP Signatures: fetching the peer actor, getting their key information, and verifying the signature.
Ensure it is not blocked for some reason (admin or user level)
Specifying specific Gitea behavior to do as a consequence of receiving the peer's federated data

This is the goal to get our "First Federated Behavior" section below
This may change something like a federated_view table of data that is just a cached version of the peer's data (but can always be authoritatively gotten from a peer, see "Fetching ActivityStreams below")

Note that this would need to be manageable by an admin (ex: remove undesired content)

Ensuring the new Gitea state is reflected in "Serving ActivityStreams" (see next section)

This lets federated peers "understand" Gitea without having to do something like scraping the HTML/Javascript UI to get the information, maybe get notifications and fetch this data, etc.

(optional, controversial) sharedInbox support. This is a way to optimize your Gitea instance if you have thousands of users on one instance and tons of activities flying about constantly, and don't want to DoS that server instance. I personally dislike sharedInbox but won't go into those reasons here.

Serving ActivityStreams
As a consequence of the aforementioned section of "having Actors do things", they will generate data that needs to have an ActivityStreams representation so that peers, upon looking at what an actor has been up to, can natively understand what is going on. For Gitea specifically, this gets into the ForgeFed examples.

Mapping Gitea concepts like "commits" and "repository" to the ForgeFed definitions (or ActivityStreams definitions, too).
Mapping these types to IRIs, ex: /repo/{id}. Note: as before, existing IRIs can be re-used, so long as they respect the whole Accept / Content-Type headers for ActivityStreams content.
Having a "translation layer" to transmute the Gitea database columns into ActivityStreams data server in http.Handler. Again, "translation layer" is in quotes because there may be a better design choice.
Ensuring that the endpoint is protected and requires appropriate credentials to view, if applicable.

This unblocks the next bit...
Fetching ActivityStreams
If I ever use the term "dereferencing", this is what I mean.
A Gitea instance will be able to fetch a peer Gitea instance's ActivityStreams, thanks to the work outlined in the previous section. This allows you on foo.gitea.io to fetch my Person actor on bar.gitea.io but, say, render it on a webpage to yourself natively on foo.gitea.io. Dereferencing is needed for other operations, in particular the Delivery and Addressing portions of "Sending an Activity".
Fetching ActivityStreams data also allows foo.gitea.io to potentially display all the information of a Repository shown on bar.gitea.io, without having to actually navigate to bar.gitea.io. Any actions done by users would spawn new Activities and resulting in invoking the "Sending Activities" section. Again, that's up to the concrete design.

Transport (http.Client)

Optionally with HTTP signatures if a user is signed in
Sets the Accept header appropriately

The UI work to render the desired peer data types (Repository, Person, Team) in Gitea's UI

First Federated Behavior
All of the above, and we haven't yet discussed the behaviors unlocked by ForgeFed yet. They list several:

Reporting Pushed Commits
Opening a Ticket
Create
Offer
Commenting

I would propose just aiming for one initially. Even aiming for none of these, but doing the other sections above, is a large enough feat worth celebrating: Getting to the point where the followers flow works is a celebratory moment, if Gitea wants to have the concepts of "followers"/"following" (and I think it does?).
This first federated behavior would involve:

The UI/UX work to introduce that behavior/flow, if needed. Something like "Reporting Pushed Commits" might just be an additional backend effect.
Adding the IRI endpoint that would trigger the new behavior/flow, if needed.
Sending the appropriate Activity to the federated peer for that behavior, as defined by ForgeFed.
Designing a hook when receiving that Activity from a federated peer, as defined by Forgefed.

Whew, done. :)
Go-Fed
I promised to keep this at the end and self-contained. :) The go-fed/activity library focuses on being middleware. You implement several interfaces like Database which it will use. You then use the resulting library calls in a http.Handler to deal with "Actors sending Activities" or "serve this ActivityStreams representation".
Since it is middleware, it only solves some of the problems I listed above. Big picture, the main problems remaining unsolved by go-fed are the integration ones:

How to map IRIs/URLs to ActivityStreams data
How to map ActivityStreams data to the database

More specifically, going section-by-section and listing the bullets that are addressed by go-fed:

ActivityStreams

How to deserialize ActivityStreams JSON-LD data into a concrete Golang type. It turns out this isn't easy; struct field-tagging with json is woefully insufficient. I didn't mention this aspect at all before, but I won't dive into this unless someone wants to do so. Highly caution against deserializing ActivityStreams on one's own, go-fed/activity/streams is there to help to go from []byte to ActivityStreamsCreate. Scales across all sorts of RDF vocabularies, too.
This makes it easy to create and manipulate ActivityStreams data natively in Go

Actors

Handy functions simplify serving Actors, as it's just like any other ActivityStreams data. Mapping the IRIs remains the largest challenge here.

Sending Activities

The "Addressing", "Transport" and "Inbox Forwarding" bullets above are all addressed by go-fed/activity/pub

All sub-bullets, too! Except: sharedInbox

There is a separate go-fed/httpsig for HTTP Signatures signing and verifying

Receiving Activities

Upon receiving federated data, provides hook for doing that HTTP Signatures (or other) authentication
Provides hook to map payload to your Activity-specific behavior (Create => createFn(), etc).
It provides common out-of-the-box default behavior for ActivityPub specific Activity behavior (7.2-7.10), for example a peer's Create{Note} will attempt to create the federated Note via the local Database interface, to try to help make bootstrapping quicker.

Serving ActivityStreams

Handy functions simplify serving ActivityStreams, just like the Actors section mentioned above. Mapping the IRIs remains the largest challenge here.

Fetching ActivityStreams

go-fed/activity/pub provides an optional transport to dereference using HTTP signatures, but doesn't tell you how to use the resulting data nor does it have any idea what it is for.

The go-fed/activity library does not solve:

Managing your mapping of IRI endpoints to concepts/actors/types
How to actually store things in a database
Making sure your IRI endpoints match your database queries
For what reason do you want to dereference to fetch a peer's latest data or send data to a peer (it only does just enough for its own purposes and no more)

It can't magically "know" what ActivityStreams data you want to use -- the ability to crafting the desired Activity and objects without constraint is indeed the whole point.

Finally, some downsides of go-fed:

Due to code generation hundreds of thousands of lines, the binary size is large. It cannot compile on a Raspberry Pi, due to that code size.
There are parts of the API that are still rough. However, I am open to feedback here.
The tutorials are not the most intuitive. I know the go-fed.org site looks like a backend engineer wrote it, but that's being addressed as we speak.
Implementing the interfaces can be unclear at times. However, I need to hear the questions, to better change the interfaces and/or fix unhelpful/unclear comments.
Gitea would be the first (other than me & my blogs/pet-projects) to adopt go-fed/activity/pub, which comes with its own risks. WriteFreely uses go-fed/activity/streams.

I hope this kicks off a productive discussion. Thanks for reading this far, if you made it. :)

I also opened a discussion on Forgefed where Bill helpfully pointed out I did not reference #9045. That issue is locked to collaborators so I am not able to post there, but I think a lot of the technical discussion over there is relevant to this issue, so please check it out.
Wishing everyone a happy New Year and guten Rutsch ins neue Jahr!

Posted on behalf of Loic, as explained in the post scriptum (original message on the Fedeproxy forum)

Bonjour,
TL;DR: what would it take to put federation on the Gitea 1.16.x roadmap?
The gitea roadmap for 1.1.15 is now locked and the next release cycle will start right after it is released. However the roadmap for 1.1.16 does not include the implementation of ActivityPub.
What would it take to make that happen?
It is of course a matter of who is interested to implement it and has time and skills to actually do it. An area where the fedeproxy project could help by redirecting 5,000€ of its funds (total 75K€). This is not much but it's not nothing and could be used to make the first baby step(s).
It is also a matter of defining the first baby steps that would lead Gitea in the direction of federation. At the moment there only is a very high level discussion that can hardly be translated into actionable items. In your expert opinion, what would be the first minimal tasks that would make most sense?
Cheers
P.S: I'm very motivated to help move forward and in case you're curious why I don't post myself (thank you Pierre-Louis for being my proxy :-) ), feel free to read why I deleted my GItHub account a few years ago.

I should note that Loic had reached out to me (and likely a few other forge maintainers) about this in the past via email, and I apologize for not responding. To quote Jeff Goldblum, life uhh.. gets in the way (I know this isn't the actual quote)

the next release cycle will start right after it is released.

Technically 1.16.x work has already started, but that's due to the feature freeze with 1.15.x. Although the sooner a PR is created the more likely it is to get into the 1.16.x milestone (see note about creating the PR below).

What would it take to make that happen?

To be frank, it's a matter of finding a developer to work on this (be it a maintainer of Gitea, or someone from outside the project). As you do have funding, I suspect that might be easier, as in the past few months over 1K USD has been collected as bounties working on various PRs (I personally have put up some funds as bounties). So there are developers who would likely be willing (and capable) to take on this work. If you were to use these funds I would recommend giving them directly to the developer working on this PR, and the maintainers reviewing it, rather than to the project itself (although of course speaking on behalf of the project we'd be happy/thankful to accept funds, but donations to the project don't necessarily guarantee that specific tasks would be completed).
A note: as this is likely a large PR, I recommend the developer who works on it first discuss the approach of integrating this into gitea with the project (this is to prevent a large PR from being completed and perhaps some foundational work of the PR would be suggested to be done differently, so the developer would then potentially need to change a significant amount of it).
cc: @KN4CK3R and @adelowo in case you'd be interested in paid work on Gitea

FYI. On fediverse this recent development was enthusiastically shared and on Lemmy (a federated Reddit) a core dev said they'd move issue tracking from Github with this in place, while someone else said 'where can I donate?'.
This last bit is not really clear, plus there may be additional opportunities to get more funding to realize this functionality. And also ForgeFed may still have funds available.

Posted on behalf of Loic.

@techknowlogick thanks for your reply and guidance :-) It's good to know the timing is right and I'm hopeful someone will be interested.

you were to use these funds I would recommend giving them directly to the developer working on this PR, and the maintainers reviewing it, rather than to the project itself

I'll follow your advice. Since fedeproxy is horizontal (no organization) the funds originate from individuals (Pierre-Louis and myself, 50% each) and it will be possible to pay the person(s) doing the work directly.

as this is likely a large PR...

Maybe it can be broken down in smaller tasks / PRs? It would be easier to review and implement. And it will also be easier to prioritize which task should be worked on first and which ones can fit is the modest budget there is.
@techknowlogick thanks for your reply and guidance :-) It's good to know the timing is right and I'm hopeful someone will be interested.

you were to use these funds I would recommend giving them directly to the developer working on this PR, and the maintainers reviewing it, rather than to the project itself

I'll follow your advice. Since fedeproxy is horizontal (no organization) the funds originate from individuals (Pierre-Louis and myself, 50% each) and it will be possible to pay the person(s) doing the work directly.

as this is likely a large PR...

Maybe it can be broken down in smaller tasks / PRs? It would be easier to review and implement. And it will also be easier to prioritize which task should be worked on first and which ones can fit is the modest budget there is.

There was a small meeting today between zeripath, myself, and Loic around building towards a future where federation work has a grant fund people to do it (to be clear: not necessarily funding us three, it could be funding one or two of us + others in the community). On the socialhub was the agenda. In the interest of transparency, the meeting was recorded which should also shortly be available there as well.
Since the scope of work is fairly large and the goals rather ambitious, we definitely want to be as transparent as possible w/ the wider Gitea community and welcome folks to feel free to step up & participate if you, dear reader, would like.

If somebody want to start the work from v1.16, it's a good start point to add comment on #16429 .

Watch this interesting talk about funding, grants and more technical background information (published with PeerTube: federated video streaming) between @dachary (of FedeProxy project), @cjslep (of GoFed project) and @zeripath (Gitea maintainer).

Posted on behalf of Loic

Bonjour,

While working on the grant application today, I ran into a question that is probably worth discussing before moving forward. Go-fed is AGPLv3+, and Gitea is MIT. Adding Go-fed as a dependency of Gitea means that Gitea, as a whole (meaning Gitea+Go-fed+other dependencies), can only be released under the AGPLv3+. Or not released at all.
To be more precise, here is the minimal set of actions required to distribute a gitea executable that contains Go-fed:

The https://github.com/go-gitea/gitea repository needs no change
A license notice stating the executable is under the AGPLv3+ license must be prominently added to the user interface (e.g. added at the beginning of js/licenses.txt)

This is not the only possible course of action, only the simplest.
What do people think about this?

Slight correction: The implementation of APCore is what is licensed AGPL, which is itself an extension of the standalone Go-Fed Activity libraries, which are licensed under the BSD 3-clause license instead. So what we would have to do would be to reimplement at least the relevant parts of APCore.

I think there's no real issue here, as apcore is meant as the opinionated batteries-included server framework you'd use when creating a stand-alone AP server and save you a bunch of work. Since this issue was created, a new AP server project [GoToSocial[(https://github.com/superseriousbusiness/gotosocial) and they chose to build on top of go-fed/activity and go-fed/httpsig, not apcore. This is what Gitea would also need to do, as @csolisr states.
Note that both @cjslep and @tsmethurst (of GoToSocial) can be found in the Go-Fed Matrix chatroom at https://matrix.to/#/#go-fed:feneas.org

Posted on behalf of Loic

Oh… my bad, thanks for the clarification!

I want to confirm what @aschrijver said. go-fed/activity and other low-level libraries are intended to be as permissive as possible, as they are narrowly scoped in implementing ActivityStreams and ActivityPub. (I licensed it permissively because I believe protocol implementations should be without any "gotchas", whether for proprietary use or for free-as-in-liberty use or for ... etc. For ex: at one point write.as may have been using this library, there's no problem with that).
The go-fed/apcore package builds on top of that to make a heavily opinionated server framework that is intended for new projects that use ActivityStreams internally as fundamental database structures. On technical merit alone, I do not recommend it for Gitea in the slightest. Since it is more than just a protocol implementation and is meant to bootstrap user-facing applications, I licensed it in the spirit of GPL to give an advantage to applications that are free-as-in-liberty.
I think Gitea's infrastructure is sufficiently different from APCore that there's nothing really lost by not using it. Since they have different technical approaches, I think Gitea's integration with go-fed/activity will look very different than anything in APCore anyway, so there's not much being missed out on.

In the last few weeks I looked throught the initial comment in this issue and tried to create a plan outlining what the implementation of ForgeFed could look like. The idea was to aid the discussion of the actual code that needs to be written, and not to have a 100% correct roadmap. I hope my proposals are at least somewhat sensible, as I do not have too much experience with either AP/ForgeFed or the Gitea codebase.
Mapping ForgeFed concepts to Gitea
By comparing the ForgeFed Actor guidance to Giteas modules, I came to the conclusion that the following mapping should be reasonable:

AP
Gitea

Person
User

Project
Project

Repository
Repo

Group/Organization/Team
Org, Team

Preparing the data model
All modules mentioned in the table above should have the following fields added:

Origin IRI
Signing private key
Inbox and Outbox arrays
Possibly followers and following arrays

As far as I could tell, currently each Follow is a seperate object in the Database and the collections are created ad-hoc by iterating over them and checking the user IDs (at least for users)

Array of blocked users

This might be omitted for repos and/or projects since it makes little sense for these actors

An instance-wide list of federated/blocked instances needs to be added to the database aswell.
The "translation layer" mentioned by @cjslep should be rather straightforward, as the forgefed spec is minimal and gitea has most of the fields already. Some things like "Description" -> "summary" need to be kept in mind though.
Implementing ActivityPub behaviour
From this point onward there are two possible routes:
Implementing it all by hand
When not using a library to abstract the ActivityPub functions, this would be my proposed way of adding federated behaviour to Gitea:

Define an actor interface that contains functions for the following tasks:

Accessing the In- and Outbox
Returning the Followers collection
Returning the origin IRI of the actor
Returning the json representation of the actor

Add a new router for serving In- and Outboxes

The Inbox route needs to receive POST requests and create Activity objects to put into the actors inbox
The Outbox route needs to create POST requests from the Activity objects found in the actors outbox and also serve them on receiving a GET request

Create a module that prepares and sends/receives AP activities. It needs to do the following:

Stripping of bcc, deduplication etc. for outbound messages
Checking blocked status and possible forwarding for inbound messages
Sign outgoing and verify the signature of incoming messages (this is optional but a very good idea)
Implement bounded retrying, exponential backoff and ratelimiting
Update the local version of the actors accordingly

The following is an example of a repos json representation:
{
    "@context": [
        "https://www.w3.org/ns/activitystreams",
        "https://w3id.org/security/v1",
        "https://forgefed.peers.community/ns"
    ],
    "id": "https://dev.example/aviva/treesim",
    "type": "Repository",
    "publicKey": {
        "id": "https://dev.example/aviva/treesim#main-key",
        "owner": "https://dev.example/aviva/treesim",
        "publicKeyPem": "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhki....."
    },
    "inbox": "https://dev.example/aviva/treesim/inbox",
    "outbox": "https://dev.example/aviva/treesim/outbox",
    "followers": "https://dev.example/aviva/treesim/followers",
    "team": "https://dev.example/aviva/treesim/team",
    "name": "Tree Growth 3D Simulation",
    "summary": "<p>Tree growth 3D simulator for my nature exploration game</p>"
}

Using Go-Fed
The equivalent of writing an actor interface would be implementing the db interface from go-fed. The other two points would then be met by implementing the FederatingProtocol for all actor classes (http signing is possible using go-fed/httpsig).
Fetching ActivityStreams
In whatever way it is implemented, at this point Gitea would be able to send and receive Activities as they happen, but it would be nice to also see all the Actors and their activities that came before. To do this, Gitea would have to do the following when a user requests Data about an Actor:

Determine whether actors are local or remote by cheking ther origin IRI
Fetch remote actors when data is requestet

Send GET request to remote source
check the signature

It might be a good idea to add a UI element to force a fetch of remote data, so users can get up-to-date information when needed.

As an aside, from what I read, it seems like SharedInbox would help in generating a timeline of all public activities. To me this seems like a desirable feature for a ForgeFed implementation. My knowledge of AP is not deep enough to have a really meaningful opinion on the topic though and I would love to find out more!
@cjslep, this is not really the right place to discuss this, but I would be really interested in what your issue with SharedInbox is, maybe we can find some place to have that discussion.

Thanks for your elaboration. It is great to see the growing interest in federating Gitea!

@cjslep, this is not really the right place to discuss this, but I would be really interested in what your issue with SharedInbox is, maybe we can find some place to have that discussion.

The most appropriate location would be the SocialHub community forum, where there's some prior discussion already, like this topic.

Posted on behalf of Loic
Loic wrote:

It is also a matter of defining the first baby steps that would lead Gitea in the direction of federation. At the moment there only is a very high level discussion  that can hardly be translated into actionable items. In your expert opinion, what would be the first minimal tasks that would make most sense?

@zeripath @cjslep here is an idea for the first baby step: creating a keypair for every user that will be used to sign http requests (see also the IETF draft). Although signing http requests  is not required by ActivityPub or ActivityStreams,  it is mentioned in the ActivityPub wikii. Since mastodon, bookwyrm and other ActivityPub implementations verify and expect a signature, it is de facto required.
If it sounds sensible to you, I think the creation of the corresponding issue as well as its implementation is eligible to be funded by the 5,000€ grant made available by the fedeproxy project a month ago:

Write a detailed issue to create a keypair for every user, with technical details that would allow a skilled Go developer with no prior knowledge of the codebase to work on it
Propose a pull request to implement the issue, add it to the 1.16 roadmap and get it merged

Any news on this?

@thebiblelover7 please see the pinned issue https://github.com/go-gitea/gitea/issues/16827

is this still active?
I am interested in build on a fediverse api build in golang and I'd be willing to support implementing it in the first place too!

is this still active? I am interested in build on a fediverse api build in golang and I'd be willing to support implementing it in the first place too!

I don't think any of the Gitea developers are actively working on federation, but there's been some progress in implementing it in Forgejo. I've personally been busy with other stuff for the past year or so, but I'm hoping to getting back to working on federation sometime in the next month.

@Ta180m I'm still sending PRs following my original plan, but as this is a large undertaking it's being done in small parts over time as large PRs make things difficult to review.


Move long time gaps imputation to epoch level

When the time gaps to be imputed are very long, they make that the R session crashes.
Solution: identify time gaps longer than 90 minute, skip them in g.imputeTimegaps, and impute them in the epoch level phase of the analysis.

same as https://github.com/wadpac/GGIR/issues/522?

Re-opening this issue: We did most of the work, but alignment may not be perfect after undoing the breaking changes via #368.


Merge OpenAiStreamingChatModel and OpenAiChatModel classes

Context
This PR fix the issue https://github.com/langchain4j/langchain4j/issues/954
Change

I merged the ChatLanguageModel and StreamingChatLanguageModel classes
I removed the StreamingChatLanguageModel class
I removed the OpenAiStreamingChatModelBuilderFactory class

Checklist
Before submitting this PR, please check the following points:

[ ] I have added unit and integration tests for my change
[ ] All unit and integration tests in the module I have added/changed are green
[ ] All unit and integration tests in the core and main modules are green
[ ] I have added/updated the documentation
[ ] I have added an example in the examples repo (only for "big" features)
[ ] I have added my new module in the BOM (only when a new module is added)

Checklist for adding new embedding store integration

[ ] I have added a {NameOfIntegration}EmbeddingStoreIT that extends from either EmbeddingStoreIT or EmbeddingStoreWithFilteringIT

Hello @LizeRaes, here is my PR that I made during the Devoxx session, please take a look when you have time 🤓

Thanks a lot @anunnakian , nice for streamlining experience! Looking forward to the minor fixes and getting it merged :)

Thanks a lot @anunnakian , nice for streamlining experience! Looking forward to the minor fixes and getting it merged :)

Minor changes done :)


Build testapp vanilla error

When I run this testapp,
run pnpm install
occur this

Creating entry file 616 ms
⠇ Building modules
│ (typescript) Error: /Users/sgalcheung/Downloads/ts-toolkit/shared/src/util/tokenizer/TextTokenizer.ts(40,29): semantic error TS2694: Namespace 'Intl' has no exported member 'Segmenter'.
│ Error: /Users/sgalcheung/Downloads/ts-toolkit/shared/src/util/tokenizer/TextTokenizer.ts(40,29): semantic error TS2694: Namespace 'Intl' has no exported member 'Segmenter'.in-typescript2/dist/rollup-plugin-typescript2.cjs.js:25006:12)
│     at error (/Users/sgalcheung/Downloads/ts-toolkit/node_modules/.pnpm/rollup@1.32.1/node_modules/rollup/dist/shared/node-entry.js:5400:30)@3.9.10/node_modules/rollup-plugin-typescript2/dist/rollup-plugin-typescript2.cjs.js:29277:17)
│     at throwPluginError (/Users/sgalcheung/Downloads/ts-toolkit/node_modules/.pnpm/rollup@1.32.1/node_modules/rollup/dist/shared/node-entry.js:11878:12)
│     at Object.error (/Users/sgalcheung/Downloads/ts-toolkit/node_modules/.pnpm/rollup@1.32.1/node_modules/rollup/dist/shared/node-entry.js:12912:24)
│     at Object.error (/Users/sgalcheung/Downloads/ts-toolkit/node_modules/.pnpm/rollup@1.32.1/node_modules/rollup/dist/shared/node-entry.js:12081:38)
│     at RollupContext.error (/Users/sgalcheung/Downloads/ts-toolkit/node_modules/.pnpm/rollup-plugin-typescript2@0.27.3_rollup@1.32.1_typescript@3.9.10/node_modules/rollup-plugin-typescript2/dist/rollup-plugin-typescript2.cjs.js:17237:30)
│     at /Users/sgalcheung/Downloads/ts-toolkit/node_modules/.pnpm/rollup-plugin-typescript2@0.27.3_rollup@1.32.1_typescript@3.9.10/node_modules/rollup-plugin-typescript2/dist/rollup-plugin-typescript2.cjs.js:25033:23
│     at arrayEach (/Users/sgalcheung/Downloads/ts-toolkit/node_modules/.pnpm/rollup-plugin-typescript2@0.27.3_rollup@1.32.1_typescript@3.9.10/node_modules/rollup-plugin-typescript2/dist/rollup-plugin-typescript2.cjs.js:545:11)
│     at Function.forEach (/Users/sgalcheung/Downloads/ts-toolkit/node_modules/.pnpm/rollup-plugin-typescript2@0.27.3_rollup@1.32.1_typescript@3.9.10/node_modules/rollup-plugin-typescript2/dist/rollup-plugin-typescript2.cjs.js:9397:14)
│     at printDiagnostics (/Users/sgalcheung/Downloads/ts-toolkit/node_modules/.pnpm/rollup-plugin-typescript2@0.27.3_rollup@1.32.1_typescript@3.9.10/node_modules/rollup-plugin-typescript2/dist/rollup-plugin-typescript2.cjs.js:25006:12)
│     at Object.transform (/Users/sgalcheung/Downloads/ts-toolkit/node_modules/.pnpm/rollup-plugin-typescript2@0.27.3_rollup@1.32.1_typescript@3.9.10/node_modules/rollup-plugin-typescript2/dist/rollup-plugin-typescript2.cjs.js:29277:17)
│     at /Users/sgalcheung/Downloads/ts-toolkit/node_modules/.pnpm/rollup@1.32.1/node_modules/rollup/dist/shared/node-entry.js:13117:25Namespace 'Intl' has no exported member 'Segmenter'.
│     at runNextTicks (node:internal/process/task_queues:60:5)
└─ Failed in 10s at /Users/sgalcheung/Downloads/ts-toolkit/shared
 ELIFECYCLE  Command failed with exit code 1.

my env

sw_vers
ProductName:	macOS
ProductVersion:	12.7.4
BuildVersion:	21H1123
node -v
v21.7.3
pnpm --version
8.15.4
tsc --version
Version 5.4.5

#37

Were you successful to launch the test app?
Somehow only when I explicetly used command pnpm install vite in testapp/vanilla folder, only then pnpm dev worked
However, it does not seem that the demo app actually works, since there is no publication server that can serve manifest and rest of the book content

@sgalcheung Could you please retry now using the latest version of the develop branch? You will simply need to cd into the vanilla folder, and run pnpm install && pnpm run dev
@doomuch I did not include any books in the vanilla testapp directory, I might change that in the future as I agree it is a bit confusing, I just need to figure out the best way to keep the repo clutter-free. In the meantime, you can use the now-live instance of the publication server + the book query parameter, for example:
Bella: http://localhost:5173/?book=https://publication-server.readium.org/QmVsbGFPcmlnaW5hbDMuZXB1Yg
Moby Dick: http://localhost:5173/?book=https://publication-server.readium.org/bW9ieS1kaWNrLmVwdWI

When I run pnpm run dev, it's working fine for me. @chocolatkey


changed depth launch to not evaluate dict when and fail when sensor other then oakd is used

as stated here:
https://github.com/linorobot/linorobot2/issues/94

ah, forgot to state also fixed property name for realsense sensor as this changed since wrapper is out of beta.

hi, thanks of the PR. Could we try this instead? It's quite hard to debug that PythonExpression in the future in case it breaks again. I don't have an oak-d so this approach might be less intrusive.
  IncludeLaunchDescription(
      PythonLaunchDescriptionSource(PathJoinSubstitution(
          [FindPackageShare('depthai_examples'), 'launch', 'stereo.launch.py']
      )),
      condition=IfCondition(PythonExpression(['"', LaunchConfiguration('sensor'), '" in "', str(oakd_sensors), '"'])),
      launch_arguments={
          'camera_model': to_oakd_vars.get(LaunchConfiguration('sensor')], "UNKNOWN"),
      }.items()
  ),


Added PowCache support

Added PowCache Support
With a powcache.dat file in place, this greatly improves initial sync performance.
Baseline test full sync, no cache, height: 10404: 9m6s
Full sync, with powcache.dat, height: 10782: 1m50s
Approx 5x improvement for the initial sync.

Beautiful


test: add my branch name

Description
Please include a summary of the changes and the related issue. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes # (issue)
Type of change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[ ] Test A
[ ] Test B

Test Configuration:

Firmware version:
Hardware:
Toolchain:
SDK:

Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules

Ok , i will put my name at the end of the page and remove unnecessary empty
line in tomorrow morning.
On Thu, Aug 10, 2023, 12:05 AM Tanvir Alam @.***> wrote:

@.**** requested changes on this pull request.
[image: image]
https://user-images.githubusercontent.com/3250040/259504730-9f00c0f7-accb-4081-b30e-99f731d820fc.png

Why did you remove this line? bring it back
why did you add +-----? delete it
your name should be at the end

—
Reply to this email directly, view it on GitHub
https://github.com/FeedAHelp/FeedAHelpless/pull/121#pullrequestreview-1570266449,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A5ADZFOZUXDFFFTQIXFJ3VDXUPGPJANCNFSM6AAAAAA3IITOAE
.
You are receiving this because you were assigned.Message ID:
@.***>


no attribute 'getchildren' Error while parsing drawio graph

Scenario:

The error happened on both pip installed materialize-tool and git cloned repo tool.
already using the latest dfd library and the graph follows the rule(no trust boundary, no bi-directional arrow, etc)
Don't see any clear issue on the graph itself

Error message:
materialize-threats (master) $ python3 test.py --diagram /Users/jfan/Documents/test_TM1.drawio
Traceback (most recent call last):
  File "/Users/jfan/Documents/Github/materialize-threats/test.py", line 4, in <module>
    TM.materialize()
  File "/Users/jfan/Documents/Github/materialize-threats/materialize_threats/materialize.py", line 115, in materialize
    graph = MxUtils.parse_from_xml(file=args.parse_args().diagram)
  File "/Users/jfan/Documents/Github/materialize-threats/materialize_threats/mx/utils/MxUtils.py", line 102, in parse_from_xml
    cells = diagram_root.find(MxConst.ROOT).getchildren()
AttributeError: 'xml.etree.ElementTree.Element' object has no attribute 'getchildren'

Could you attach a graph that triggers this bug?


Use virtual environments and create a requirements.txt file

This blog post helps to understand and use the concept of virtual environments and requirements.txt files.

Should pytest be included in requirements.txt?

For the first releases of this project one requirements file for all purpose fits our needs.

Great, alright!


No menu? (global menu bar doesn't change)

The instructions refer to a menu:

Use the included "Install User Launch Agent" feature (accessible from the menu).

However, when I run Disk Arbitrator, the global Mac menu bar doesn't change to a be Disk Arbitrator menu, and the  Disk Arbitrator window doesn't seem to otherwise have a menu.
Am I missing something, or is something broken?
(This is on MacOS Ventura 13.2.)

Never mind:

Am I missing something,

Yes, I missed icon in Mac menu bar.


feat: 🚀Fix issues and improve content

fixes #6
I also tried to improve the content of the site Lil bit.
If you don't like it, you can delete that particular changes.

Please add the relevant the hacktoberfest labels to this PR.

Could you please add the Hacktoberfest accepted label to this PR?


Fixes #22 support akka-streams Gearpump Materializer

DO NOT MERGE AT THIS TIME

@kkasravi created an akka-streams branch at https://git-wip-us.apache.org/repos/asf?p=incubator-gearpump.git;a=shortlog;h=refs/heads/akka-streams. Could you resubmit your PR against that branch ?

@kkasravi could you create a new PR against https://github.com/apache/incubator-gearpump/tree/akka-streams ?


desktop manager service: fix and improve default error

Before the error if the wrong default desktop was chosen would be:
/nixpkgs-channels/lib/modules.nix:282:11:
Default desktop manager ($(defaultDM)) not found.

which has the string interpolation done incorreclty. Now that is fixed
and it is more user-friendly as:
/nixpkgs-channels/lib/modules.nix:282:11:
Default desktop manager (gnome) not found.
Probably you want to change
  services.xserver.desktopManager.default = "gnome";
to one of
  services.xserver.desktopManager.default = "gnome3";
  services.xserver.desktopManager.default = "none";

:beers:


Roll Plugins from 9a90a9d0c61d to 730129a45b52 (1 revision)

https://github.com/flutter/plugins/compare/9a90a9d0c61d...730129a45b52
2021-06-23<EMAIL_ADDRESS>[in_app_purchase] billingClient launchPriceChangeConfirmationFlow (flutter/plugins#4077)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-plugins-flutter-autoroll
Please CC<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Commit queue failed; closing this roll.


⚠ ClamAV has degraded performance

In 6ba8c4c, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 219 ms

Resolved: ClamAV performance has improved in 3ccb22b.


Packed Padded Sequences

Hi, first of all, thank you very much for this great contribution.
In the tutorial number 4, In the Encoder module forward function the argument src_len is specified in the following way:
#src_len = [src len]
Shouldn't it be #src_len = [batch size] ?
As far as I understand src_len is a vector containing the length of each sentence in the batch, isn't it?
Thanks!!

@dariodematties Yep, you're correct! That's a typo on my end. Will fix shortly. Thanks for spotting.


Bandwidth minimization

Add functionality for reordering the vertices of a tensor network/graph to minimize the graph bandwidth.
It appears that a popular algorithm for this is the Cuthill-McKee algorithm. There is a discussion of Julia implementations on Julia Discourse. Some Julia implementations are:

SymRCM.jl.
CuthillMcKee.jl.
NodeNumbering.jl, with a tutorial here.
AMD.jl.

This may be relevant for finding an MPS ordering for a graph of Hamiltonian interactions or mutual information that may be beneficial for entanglement (@JoeyT1994 is this what you use for your dense-graph DMRG calculations?), or finding an MPS embedding of a more general graph if you are looking to approximate a general tensor network as an MPS (though @LinjianMa has a more specialized algorithm for that in #11 which takes into account a tensor network the resulting MPS might contract with in order to try to minimize future swapping, which would be good to split off into a separate function).
It also may be relevant for finding network layouts for tensor networks/graphs that are known to be linear or have some linear structure.
Finally, this problem appears to be related to the minimum linear arrangement (MinLA) problem, which is known to be NP-hard. See:

https://lipn.univ-paris13.fr/Lagos2017/talks/castro.pdf
https://www.sciencedirect.com/science/article/abs/pii/S0196677404001531
https://d-nb.info/1002005167/34

which is a special 1D case of the more general grid arrangement problem:

https://www.sciencedirect.com/science/article/pii/S157252861200045X

which could be relevant for visualizing hypercubic-like tensor networks and also automatically approximating tensor networks as PEPS networks (say for a generalized boundary PEPS algorithm for contracting cube-like graphs).

I was using the CurhillMcKee.jl package for some adjacency matrix reordering and this was working very straightforwardly so can recommend that.
I did, however, find cases where the re-ordering found by Cuthill-McKee performed worse in DMRG than just a randomly chosen one. I think the reason for this is that it uses the standard definition of bandwidth (distance of the furthest non-zero element from the diagonal) which is a bit naive when thinking about MPS ordering. For instance, the periodic boundary 1D chain adjacency matrix has the largest bandwidth possible and so Cuthill-Mckee will perform a significant re-ordering of the sites and create an adjacency matrix with lots of long-range terms (instead of just one in the periodic case). DMRG will then perform a lot worse on such an adjacency matrix even though it might have a much lower bandwidth.
Ideally we might be able to introduce a variable definition of bandwidth via some `cost-function' and then minimise over that. For instance, I think the cost-function $C(A) = \sum{i,j}A_{ij} |i - j|^{\eta}$ where $\eta > 1$ is quite a popular choice.

Also relevant is: https://github.com/cameton/LinearOrdering.jl with the associated reference https://arxiv.org/abs/2209.02895.


Skip auth and key validation on dry-run

Closes #601
Skips doing authentication stuff when --dry-run is specified. A warning message will be displayed when no token is specified:
◎ Checking cluster status
✔ Wego installed
⚠ No Git Provider token found. Skipping authentication for dry run.
Adding application:

Name: stringly
URL<EMAIL_ADDRESS>Path: ./
Branch: main
Type: kustomize

---
apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: GitRepository
metadata:
  name: stringly
  namespace: wego-system
spec:
  interval: 30s
  ref:
    branch: main
  secretRef:
    name: wego-kind-kind-788gy0-stringly
  url<EMAIL_ADDRESS>
...

This is no longer relevant; the recent changes to the structure makes this PR un-salvageable.


Enable Hive Metastore metrics

As a SysOps
I want to enable Hive Metastore metrics
So that process health can be monitored
Acceptance Criteria:

Hive metastore emits metrics to a file

Raised https://github.com/ExpediaInc/apiary-metastore-docker/pull/5

@pradeepbhadani to @rpoluri 's comment on the PR, how will you access the file on the docker instance? Should we add cloudwatch to the scope of this issue?

@mroark1m - the ways its deployed in EC2 instance is - a python script reads this output file and send metrics to Graphite.


envoyOtelAls Not supported field in StreamInfo: REQ_WITHOUT_QUERY

Is this the right place to submit this?

[X] This is not a security vulnerability or a crashing bug
[X] This is not a question about how to use Istio

Bug Description
this is the config of istio
extensionProviders:
- envoyOtelAls:
logFormat:
labels:
duration: '%DURATION%'
host: '%REQ(HOST)%'
method: '%REQ(:METHOD)%'
path: '%REQ(:PATH)%'
status: '%RESPONSE_CODE%'
upstream_host: '%UPSTREAM_HOST%'
After configuration, the sidecar error message is as follows:
: Not supported field in StreamInfo: REQ_WITHOUT_QUERY
Version
$ istioctl version
client version: 1.16.5
control plane version: 1.16
data plane version: 1.16.5 (174 proxies)
$ kubectl version
v1.26.1

Additional Information
No response

I recall I fixed this in recently vesion, can you retry with latest istio?

https://github.com/istio/istio/pull/51486


Fix test failures in FunctionNode implementation guide

Fix make doctest error introduced in #4986

Jenkins, test this please.

Doctest still fails.
@kmaehashi Could you fix this?
14:51:50 Warning, treated as error:
14:51:50 **********************************************************************
14:51:50 File "guides/functions.rst", line 255, in default
14:51:50 Failed example:
14:51:50     x = Variable(np.random.uniform(-1, 1, (3, 2)).astype(np.float32))
14:51:50     y = Variable(np.random.uniform(-1, 1, (3, 2)).astype(np.float32))
14:51:50     z = Variable(np.random.uniform(-1, 1, (3, 2)).astype(np.float32))
14:51:50     w = MulAdd().apply((x, y, z))
14:51:50     w.grad = np.random.uniform(-1, 1, (3, 2)).astype(np.float32)
14:51:50     w.backward()
14:51:50 Exception raised:
14:51:50     Traceback (most recent call last):
14:51:50       File "/usr/lib/python3.5/doctest.py", line 1321, in __run
14:51:50         compileflags, 1), test.globs)
14:51:50       File "<doctest default[0]>", line 5, in <module>
14:51:50         w.grad = np.random.uniform(-1, 1, (3, 2)).astype(np.float32)
14:51:50     AttributeError: 'tuple' object has no attribute 'grad'
14:51:50
14:51:51 Makefile:176: recipe for target 'doctest' failed
14:51:51 make: *** [doctest] Error 2

Jenkins CI test (for commit 8dc5e27588cd81677d56b0c7a7668bfbff95520f, target branch master) failed with status FAILURE.
(For contributors, please wait until the reviewer confirms the details of the error.)

Jenkins, test this please.

Jenkins CI test (for commit 540348f813e031c6fdcb8ad95d36ab3450b46d4e, target branch master) succeeded!

@toslunar This pull-request is marked as to-be-backported, but the corresponding backport PR could not be found. Could you check?

@toslunar This pull-request is marked as to-be-backported, but the corresponding backport PR could not be found. Could you check?

@toslunar This pull-request is marked as to-be-backported, but the corresponding backport PR could not be found. Could you check?

The PR was backported as a part of #6730.  The label to-be-backported is removed because the bot does not find it.


Infotext bug

Not working with dev branch Auto1111.
At webui start get this:
*** Error calling: F:\AI\stable-diffusion-webui\extensions\sd-webui-freeu\scripts\freeu.py/ui
    Traceback (most recent call last):
      File "F:\AI\stable-diffusion-webui\modules\scripts.py", line 402, in wrap_call
        return func(*args, **kwargs)
      File "F:\AI\stable-diffusion-webui\extensions\sd-webui-freeu\scripts\freeu.py", line 177, in ui
        schedule_infotext.change(
      File "F:\AI\stable-diffusion-webui\venv\lib\site-packages\gradio\events.py", line 140, in __call__
        dep, dep_index = self.trigger.set_event_trigger(
      File "F:\AI\stable-diffusion-webui\venv\lib\site-packages\gradio\blocks.py", line 286, in set_event_trigger
        "inputs": [block._id for block in inputs],
      File "F:\AI\stable-diffusion-webui\venv\lib\site-packages\gradio\blocks.py", line 286, in <listcomp>
        "inputs": [block._id for block in inputs],
    AttributeError: 'NoneType' object has no attribute '_id'

After opening web-interface, Auto1111 crashes with this:
Traceback (most recent call last):
  File "F:\AI\stable-diffusion-webui\venv\lib\site-packages\gradio\routes.py", line 488, in run_predict
    output = await app.get_blocks().process_api(
  File "F:\AI\stable-diffusion-webui\venv\lib\site-packages\gradio\blocks.py", line 1434, in process_api
    data = self.postprocess_data(fn_index, result["prediction"], state)
  File "F:\AI\stable-diffusion-webui\venv\lib\site-packages\gradio\blocks.py", line 1297, in postprocess_data
    self.validate_outputs(fn_index, predictions)  # type: ignore
  File "F:\AI\stable-diffusion-webui\venv\lib\site-packages\gradio\blocks.py", line 1272, in validate_outputs
    raise ValueError(
ValueError: An event handler didn't receive enough output values (needed: 310, received: 2).

Without calling schedule_infotext.change() it works fine. Passed steps_component is None.

Ah I thought I could rely on arg order when creating the ui. I'll make it so that order does not matter.

Pushed a fix, let me know if the problem persists.

Still same error on startup. But now webui doesn't crash.

I tested on the dev branch and I'm unable to reproduce. I think for some reason the components with elem_id="{tab}_steps" is not caught by the on_before_component callback. Maybe an extension messing with stuff?

Disabling all extensions does not help. I did some testing and it looks like some combination of webui settings is causing the error. It's hard to say what exactly, but clean config does not cause errors.

Is it related to one of these options?

Yes, error if ui_reorder non-default.

My bad, callback should be called on after component, not before. Should be fixed now.


Feature/fix import from bookmarklet not working

:pencil: Description

This PR is for fixing importing an insight from bookmarklet using the API

:tada: This PR is included in version 3.20.9 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Rebuild msitools 0.100 with libxml2 2.10

Actions:

Fix source/url
Apply a patch only on osx
Reorder dependencies
Add libxml2 pinning

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_1aqrvpltm3/clone/recipe/meta.yaml:12: http_url: http://ftp.gnome.org/pub/GNOME/sources/msitools/0.100/msitools-0.100.tar.xz is not https
ERROR: /tmp/abs_1aqrvpltm3/clone/recipe/meta.yaml:17: patch_unnecessary: patch should not be in build when source/patches is not set
ERROR: /tmp/abs_1aqrvpltm3/clone/recipe/meta.yaml:31: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_1aqrvpltm3/clone/recipe/meta.yaml:32: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_1aqrvpltm3/clone/recipe/meta.yaml:32: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_1aqrvpltm3/clone/recipe/meta.yaml:35: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
Errors were found

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_268rn_krig/clone/recipe/meta.yaml:12: http_url: http://ftp.gnome.org/pub/GNOME/sources/msitools/0.100/msitools-0.100.tar.xz is not https
ERROR: /tmp/abs_268rn_krig/clone/recipe/meta.yaml:17: patch_unnecessary: patch should not be in build when source/patches is not set
ERROR: /tmp/abs_268rn_krig/clone/recipe/meta.yaml:31: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_268rn_krig/clone/recipe/meta.yaml:32: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_268rn_krig/clone/recipe/meta.yaml:32: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_268rn_krig/clone/recipe/meta.yaml:35: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
Errors were found

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_ef0i6olc14/clone/recipe/meta.yaml:31: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_ef0i6olc14/clone/recipe/meta.yaml:32: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_ef0i6olc14/clone/recipe/meta.yaml:32: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_ef0i6olc14/clone/recipe/meta.yaml:35: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
Errors were found

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_05ened_mbs/clone/recipe/meta.yaml:31: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_05ened_mbs/clone/recipe/meta.yaml:32: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_05ened_mbs/clone/recipe/meta.yaml:32: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_05ened_mbs/clone/recipe/meta.yaml:35: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
Errors were found

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_89nqz1ga3e/clone/recipe/meta.yaml:31: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_89nqz1ga3e/clone/recipe/meta.yaml:32: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_89nqz1ga3e/clone/recipe/meta.yaml:32: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_89nqz1ga3e/clone/recipe/meta.yaml:35: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
Errors were found


Length for tg_line?

I absolutely appreciate this may not be the way you want to go with tg, but I figure it can't hurt to ask: would you be interested in exposing a function to calculate the length of a tg_line?
It looks like there's already an internal length function for calculating the Pythagoras distance between 2 points, and a function to calculate a ring's perimeter as part of the Polsby-Popper score calculation, so this doesn't appear to be a huge stretch in terms of extra code, but I understand this may not be an API overhead you want to take on.
For full disclosure, I'm asking for this with the hope of it getting incorporated into sqlite-tg as it's a much lighter-weight alternative to using Spatialite and the GeoJSON conversion, intersection, and bounding box functions are super useful for the work I'm doing.

You're right that this should be a relatively simple change. Most of the code is already there but just needs to be exposed to the API.
I'll dig a little deep and see what I can do.

The method is now available.

Thank you! Looks fantastic :)


Error with vol after adding RemNUX to workstation

This error occured when trying to run imageinfo against a physical mem file.  I thought the syntax for location may have been incorrect (export VOLATILITY_LOCATION=file:///cases/PhysicalMemory), but also tried that as well and to no avail.
This also occurred during my SANS FOR508 class a couple weeks ago when myself and others ran updates on the SIFT workstation.

Looks like RemNUX hasn't removed edit box yet. If you run the update-sift command it should fix this problem for you. The Editbox plugin isn't compatible with the latest version of Volatility. The update-sift command will remove it for you.

Awesome! Thanks for your fast response :)

Anytime.


(feature) Bitbucket retriever

Requirements
In order to continue GO Feature Flag support to major GIT providers we want to bring the same support as Github and Gitlab for Bitbucket.
To do this, we want to let GO Feature Flag users the possibility to store their configuration files inside Bitbucket.
For this, we want to have a Bitbucketretriever that will get the configuration directly from the Azure service.
Things to take in consideration:

We want to use the bitbucket API to retrieve the configuration file.
If we get ratelimited by the API (http 429) we should avoid continuing calling the API to soon and backoff the calls (this bitbucket documentation is really interesting on how to deal with that).

An example of PR to add a new retriver https://github.com/thomaspoignant/go-feature-flag/pull/1717/files

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
Hello I'm a front-end and a blockchain developer and will love to work on this

Hello @thomaspoignant. Wanted to ask if there is a bitbucket repository for the test...

The retriever is up, but the test fails regardless of the repo I test it against, it seems like a specific shape of data is expected...

@CollinsC1O You can test your development against this repo.


How can i contribute?

Hi, i contributed once in here  but with the web editor of GitHub, in Visual Studio Code there's errors when i do git push and it says that i don't have permissions (probably bc the terminal thinks that i am doing the push on the main branch).
So how can i contribute with Visual studio Code??

@angeldevildev @saarock

Here people can write issue about the project, so you shouldn't ask here, all the informations about how to contribute are in the CONTRIBUTING.md file, after you commited all the files that you changed run the command git push and then copy and paste the command that there will be printed in the terminal. Then after the push in your fork you can create a PR (Pull Request) in there.

Thanks


Stop putting vscode on top all the time!

Type: Bug
My vscode is always placed at the top of the page, which makes it invalid for me to use alt+tab to switch the screen to the browser. Therefore, I must manually minimize the vscode each time. How can I set stop vscode at the top of the screen?
VS Code version: Code 1.74.1 (1ad8d514439d5077d2b0b7ee64d2ce82a9308e5a, 2022-12-14T10:30:51.966Z)
OS version: Windows_NT x64 10.0.19045
Modes:
Sandboxed: No
Remote OS version: Linux x64 4.15.0-1113-azure

System Info

Item
Value

CPUs
11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz (16 x 2304)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: disabled_off

Load (avg)
undefined

Memory (System)
15.79GB (2.03GB free)

Process Argv
--crash-reporter-id 60909f13-01fd-452f-83dc-ba2b63180e10

Screen Reader
no

VM
40%

Item
Value

Remote
SSH: <IP_ADDRESS>

OS
Linux x64 4.15.0-1113-azure

CPUs
Intel(R) Xeon(R) CPU E5-2690 v4 @ 2.60GHz (24 x 2593)

Memory (System)
440.91GB (430.06GB free)

VM
0%

Extensions (16)

Extension
Author (truncated)
Version

vscode-language-pack-zh-hans
MS-
1.74.12140931

jupyter-keymap
ms-
1.0.0

remote-containers
ms-
0.266.1

remote-ssh
ms-
0.94.0

remote-ssh-edit
ms-
0.84.0

remote-wsl
ms-
0.72.0

vscode-remote-extensionpack
ms-
0.23.0

remote-explorer
ms-
0.0.3

isort
ms-
2022.8.0

python
ms-
2022.20.1

vscode-pylance
ms-
2022.12.20

jupyter
ms-
2022.11.1003412109

jupyter-keymap
ms-
1.0.0

jupyter-renderers
ms-
1.0.12

vscode-jupyter-cell-tags
ms-
0.1.6

vscode-jupyter-slideshow
ms-
0.1.5

Ok, I have solved this problem, thanks


HBASE-24665 MultiWAL : Avoid rolling of ALL WALs when one of the WAL needs a roll

Not sure why this did not get a QA run. Any pointers @Apache9 ?

Looks like updating on QA is broken overall, recently (~24 hr)

@WenFeiYi  can u do one more commit to kick a QA run.  Can be like a new blank line create or so

@WenFeiYi can u do one more commit to kick a QA run. Can be like a new blank line create or so

ok

Seems no luck. Can u pls close this and raise a new PR for branch-2.2?   Same for branch-1 also