protobuf: update docs

closes https://github.com/mesg-foundation/core/issues/528

@antho1404 ServiceLogs has missing docs also, would you like me to add it to this PR as well?

yes can be good

Just saw another issue on the documentation concerning the service ListServicesReply and GetServiceReply.
The service does not contains map anymore for events, outputs, tasks... it contains repeated data so this should also be updated.
Example ListServicesReply:
{
  "services": [{
    "id": "idX",
    "name": "serviceX",
    "description": "descriptionX",
    "status": "statusX",
    "events": [{
      "key": "eventX",
      "data": [{
        "key": "dataX",
        "type": "String"
      }]
    }],
    "tasks": [{
      "key": "taskX",
      "inputs": [{
        "key": "foo",
        "type": "String"
      }],
      "outputs": [{
        "key": "outputX",
        "data": [{
          "key": "resX",
          "type": "String"
        }]
      }]
    }]
  }]
}

Example GetServiceReply:
{
  "service": {
    "id": "idX",
    "name": "serviceX",
    "description": "descriptionX",
    "status": "statusX",
    "events": [{
      "key": "eventX",
      "data": [{
        "key": "dataX",
        "type": "String"
      }]
    }],
    "tasks": [{
      "key": "taskX",
      "inputs": [{
        "key": "foo",
        "type": "String"
      }],
      "outputs": [{
        "key": "outputX",
        "data": [{
          "key": "resX",
          "type": "String"
        }]
      }]
    }]
  }
}

To verify with the API but it should be something like that

Updated the list service reply that needed a services attribute that is a list of services
Also updated the cli documentation with some missing documentation


Add pre-commit config and autofix CI

Adds a pre-commit config and a Github action to autofix using pre-commit. This has been working well in practice in our other repo free-threading-compatibility.
Adds tox and pre-commit as dev dependencies to be able to run everything without needing to install anything else.
Removes ruff from the tox envs that run in the Github action since it'll run as part of the pre-commit CI.

Again, feel free to say no if it's too much.

Note: If we decide to go with it, we need to change the pre-commit ci lite app's permissions to include this repo.


Import command option to not upgrade installed packages

Description of the new feature / enhancement
winget import currently will also install newer versions of packages that are already installed.
There shall be the option to ignore packages that are already installed on the system, no matter the version. This will safe a lot of time when one just wants to install any missing software and not mix this up with upgrades.
Proposed technical implementation details
Implement a command line option --ignore-installed to skip re-installing(=upgrading) a package.

Related: https://github.com/microsoft/winget-cli/issues/929

@denelon - #2655

@Trenly did this make it into 1.4 Release Candidate (2)?

@Trenly did this make it into 1.4 Release Candidate (2)?


HtmlElement not calling attached()

This issue was originally filed by<EMAIL_ADDRESS>
What steps will reproduce the problem?

Make new Dart class and extend with HtmlElement
Overwrite attached() function
register HtmlElement to Class with registerDartType(...)

What is the expected output? What do you see instead?
The attached function is not called when the related Html Element is attached to the DOM.
Please include the following information:

Dart SDK version: 1.6.0-dev.5.0_r38487
polymer package version: 0.11.0 +5
Operating system: Windows 7 Enterprise SP 1
Browser (if any): Dartium 36.0.1985.97

This issue has been moved to dart-lang/polymer-dart#267.


Added the missed policy in tagging

Type of change
Note: Fill x in []

[x] bug
[ ] enhancement
[ ] documentation
[ ] dependencies

Description
Added the missed policy in tagging

For security reasons, all pull requests need to be approved first before running any automated CI

@athiruma, What the purpose to add ebs_unattached policy?

I missed the tagging of the ebs_unattahced volumes. So I added it here.


docs: update graphdriver compatibility matrix

alternative to #22628
Commit 824c72f marked
overlay as "not compatible" with overlay.
This updates the compatibility matrix in the documentation
to match that.
Also see the discussion in #22624

it would be nice to know what filesystem drivers we test each graphdriver on - as that's essentially our core supported matrix.

LGTM 🐮
/cc @thaJeztah

Yes, let's go for this one, LGTM after the typo is fixed
ping @SvenDowideit ^^

ping @SvenDowideit
I think you're almost in SF to fix this :)

yup, doing :)

LGTM, thanks!


Packages can't be built with GHC > 7.8

Filing an issue to be more accessible.
Using GHC > 7.8 to build packages results in:
haddock: internal error: ./package.cache: openBinaryFile: does not exist

This is because lots has changed, even in 7.10-RC1:
<EMAIL_ADDRESS>@peti has already solved this problem with haskell-ng branch:
https://github.com/peti/nixpkgs/tree/haskell-ng
It seems like it needs some more work before it's ready to merge, though.

Haskell NG can compile with GHC 7.10.1-rc1 fine. The name of the package set is haskell-ng.packages.ghcHEAD.<hackage-package-name>. This is all available in the current master branch.

Thank you :+1:


Rule request: prefer either forEach or forOf

For most modern environments, it's likely slightly preferable to use for-of instead of forEach when the body of the loop is an arrow function or function expression:
mySet.forEach((value) => { /* ... */ });

for (const value of mySet) { /* ... */ }

On the other hand, IE 11 doesn't generally support for-of with some output types of TypeScript, so it might be necessary to only use forEach. Lovely.
It'd be useful to have a rule that takes in a preference (presumably for-of by default) and complains when that isn't adhered to.

Why would for-of be slightly preferable? Is it because it defers executions when working with iterables? Or are there other benefits?

Indeed!
for (const await value of getMyAsyncIterableValues()) {
    if (value.status === "last") {
        break;
    }
}

if there's a break or return

Interesting. TypeScript will complain if there's a break in the function, and I don't know if there are many cases where we could detect that a continue/break/return is doing what the author intended one of the other statements to be.

💀 It's time! 💀
TSLint is being deprecated; therefore, it and tslint-microsoft-contrib are no longer accepting pull requests for major new changes or features. See #4534. 😱
If you'd like to see this change implemented, you have two choices:

Recommended: Check if this is available in ESLint + typescript-eslint ✅
Not Recommended: Fork TSLint or tslint-microsoft-contrib locally 🤷♂

👋 It was a pleasure open sourcing with you!
If you believe this message was posted here in error, please comment so we can re-open the issue!


[WIP] Experimental use of openexr C layer in openimageio

Signed-off-by: Kimball Thurston<EMAIL_ADDRESS>Description
Experimental only version of use of the C layer for reading images, to be used for evaluating the new API, and testing improved thread behavior when higher level application (i.e. renderer) has it's own pile of threads hammering away at textures.
Tests
At this point, just smoke test that iv can load a couple of images.
Checklist:

[ ] I have read the contribution guidelines.
[ ] If this is more extensive than a small change to existing code, I
have previously submitted a Contributor License Agreement
(individual, and if there is any way my
employers might think my programming belongs to them, then also
corporate).
[ ] I have updated the documentation, if applicable.
[ ] I have ensured that the change is tested somewhere in the testsuite
(adding new test cases if necessary).
[ ] My code follows the prevailing code style of this project.

lg - I believe I've re-done the locks that'll be used in exrinput_c.cpp to be more conducive to not locking during texturesys, except when the internal cache of the imagespec needs to be built (although we could in theory get rid of that and do the channel remap slightly differently)

Should we merge this, or do you have other changes coming right away?
Are you brave enough to edit .github/workflows/ci.yml to enable this code path in the "bleeding edge" test (which pulls from OpenEXR master) so that this is going through CI henceforth? We'd also need to exclude any testsuite entries that use deep images. If you don't want to mess with that, I can do it after the merge and submit a separate PR.

I can add a CI path for this - wasn't sure whether you wanted to keep it as a separate file (i.e. two implementations)? I can put it as ifdef blocks in exrinput if that would be better? Just thought it was easier to compare side-by-side while we play. Did you have a look at what I did for the tile reads? I never made a multi-tile read call in oiio (only ever single tile at a time), so wasn't sure I interpreted the desired memory layout (interleaved channels, tiles are successive in memory in y, x order. Also - in the new world, if you are at a small mip level (i.e. smaller than the tile size, it only negotiates that tile size in memory inside the C code, and hadn't validated the spec is correct for that yet. - I have the accessors I made to query the sizes from the internal structs in exr, probably should use those to ensure that. Further, wasn't sure that is what the API is expected to be filling in, or if it's expecting to always deliver a full tilesize (i.e. 32x32) regardless of mip level

wasn't sure whether you wanted to keep it as a separate file (i.e. two implementations)? I can put it as ifdef blocks in exrinput if that would be better? Just thought it was easier to compare side-by-side while we play.

I think this is great, and at this stage made it easy to diff the two files. Let's keep it separate until it's complete and as we fiddle around, but then eventually when it just does this by default, we'll want to merge this all into one file with appropriate #if guards.

I never made a multi-tile read call in oiio (only ever single tile at a time),

Putting it into CI will uncover any problems immediately, as there are plenty of tests involving tiled images and the multi-tile reads happen whenever we read whole images rather than single tiles in the texture system.
Also, in iv, the < and > will show you the different MIP levels of an image.

But at least let's get the exception bits cleaned up - I started that this morning, but meetings are starting now...

Up to you. Nothing wrong with coming back to simplify that part later.

@etheory We are getting close to being able to benchmark the new OpenEXR code for better threaded tile performance.

ok, I'll push up the exception cleanup and the CI path tonight / tomorrow morning, then we can unleash the hounds as they say

got things patched up, started running tests, there are a couple of problems, let me get those patched up prior to merging this in

fyi, when I run the tests, I see a number of failures with tiff and with freetype, it seems to use a different font on my system than for you (ubuntu?) by default. However, there are a couple of bad / incomplete tests that fail because the error messages are different. I'm happy to update the references, but wanted you to have a look prior to doing so to make sure I am interpreting it correctly.

additionally, I did visually audit the texture sys chain, so other than the lock that happens when you first access a subimage / miplevel to update the ImageSpec cache in the input file, I believe all the locking should be removed, so should be ready for some baseline tests. Will love to hear how it helps, or if there are other issues.

Freetype has the maddening property of rasterizing fonts ever so slightly differently from version to version. This is one case where we tend to just check multiple reference images into the testsuite/NAME/ref directory (the testsuite scripts will allow a pass if the output matches any of the reference images in that directory). If your Linux distro has a different version of Freetype than any of the ones we've encountered in CI or our personal machines, it may indeed differ in output. Feel free (maybe in a separate PR?) to add new reference output for your version of freetype. You can see how we usually name the reference files to make it clear which freetype versions required new reference images.
$ ls testsuite/oiiotool-text/ref
aligned-freetype2.4.11.tif  text-freetype2.7.tif
aligned.tif                 text.tif
out.txt                     textalpha.tif
text-alt.tif                textshadowed-freetype2.4.11.tif
text-freetype2.6.5.tif      textshadowed.tif

fyi, the image tests that OpenImageIO does has uncovered an issue with the piz decompressor under C beyond the current unit tests in the exr tree. Ignoring that, I believe I have fixed the issues I've found with the texture reading in OpenImageIO and the new C library.
I will fix the piz decompression tomorrow and wire in deep tomorrow. But I don't want to push up reference output changes from the different error text, so we'll continue to have errors even after I fix those.
side note: I found out why the text tests were failing under Arch: I didn't have the droid fonts installed, so it wasn't using DroidSans. So seems like the newer freetype (2.10.4) hasn't changed much. I don't seem to have the correct DroidSerif font for one of the oiiotool tests (also not found), but not going to worry too much about that right now.

The Droid fonts are installed as part of OIIO itself. I suspect that if you only build (but don't install) and then run tests, maybe it can't find them. Try just setting OpenImageIO_ROOT to wherever you have your test install of OIIO, and that should be enough to find them. I'll try to make the testsuite itself a little more robust to not needing that set if you have a build area.

@lgritz - There may still be issues, but this (with latest openexr master) seems close enough for now to enable wider testing

Huh, I see that unit_imageinout is crashing, will take a look at that tonight. I believe the other two failing tests are differences in the error messages.

good to go whenever I think - the C layer isn't designed to read non-chunk-sized blocks, but think I've fixed the various corner cases I've seen

I have a "fix" for the error messages. By which I mean, a patch that adds an additional reference output for it to match to for these two tests. I'm testing it now and will push to your branch if it succeeds.
But in the mean time, I do urge you to look at the new error output reference versus the old one from the same tests. IMHO, the old error messages are MUCH more understandable (by the users who will see them as passed up via oiio) than the new ones. For example,
Old: Failed OpenEXR read: Error reading pixel data from image file "src/incomplete.exr". Scan line 126 is missing.
("Oh, a scanline is missing and I know which one. It's an incompletely written file.")
New: EXR Error (src/incomplete.exr): EXR_ERR_BAD_CHUNK_DATA Request for scanline 0 found scanline 20000630, not 0 at chunk 0
("What is a chunk and why does it think there is a scanline 20000630?")

With the extra output reference checked in, CI is fully passing, so I'm going to merge.
Related items to-do:

Benchmark to see if this has the performance gains (especially for texturing) that we hope for.
Contemplate when we are comfortable using the core api automatically any time OpenEXR 3.1 is found.
Should exrinput.cpp and exrinput_c.cpp be merged, with appropriate #if, rather than separate files? (Pro: will eliminate headache of edit in two places as other OIIO things change or we improve openexr handling. Con: possibly just as confusing to have to do it in two clauses of an #if and may look cluttered.)


Include "Discard draft" button for items in the review workflow

Items that have been

submitted for approval
returned for review

should still be able to be deleted entirely. These should have the "Discard draft" button at the bottom of the form, as well as the trash can icon on the relevant tables on the dashboard and collection deposits lists.

@amyehodge Note to self to let Kristin know when we've fixed this.

Huzzah! I have two user confirmations that this is now working in production, including from the person who originally reported the issue.


Fatal Compile Error: Declaration of Http\Client\Socket\Stream::close() must be compatible

Unless I use "psr/http-message": "1.1" in composer.json, I get the error:
Declaration of Http\Client\Socket\Stream::close() must be compatible
Looks related to: https://github.com/php-http/socket-client/pull/69
Can anyone reproduce? If so we might need to update our composer.json

Got to reproduce the error.
By reading the issue and related discussions, we may need to replace php-http/socket-client with relevant PSR interfaces - at least PSR18 -, and suggest one or more implementations.

I'm personally already using https://github.com/guzzle/guzzle which also has socket support.
Are there any other suggestions?

I'd suggest Guzzle as well and maybe symfony/http-client, but any of the packages that provide psr/http-client-implementation should be ok as long as they provide unix socket support.
Shall we move with this:
in docker-php-api:

Remove nyholm/psr7 under require;
Remove php-http/socket-client under suggest
Add psr/http-client-implementation under require;
Add psr/http-factory-implementation under require;
Add psr/http-message-implementation under require.

in docker-php:

Replace php-http/socket-client with psr/http-client-implementation;
Remove php-http/client-common;
Replace nyholm/psr7 with psr/http-message-implementation;
Remove php-http/httplug-bundle under suggest;
Add guzzlehttp/guzzle under suggest.

Those changes will leave the actual implementation of the underlying transport (HTTP) to the project using docker-php and docker-php-api and no longer force any packages, but suggest guzzlehttp/guzzle as a viable implementation.

@flavioheleno All looks good to me 👍

Done in beluga-php/docker-php#6c0fcd4 and beluga-php/docker-php-api#8a95e39


Notebooks: Fix Grids Not Rendering when Unsaved Notebook Reloaded

This addresses #12473.
There are changes in how notebook outputs are handled now with how we're doing grid streaming; previously, we would display messages and then the table, but now, we get the messages after we get the grid headers, meaning that we have to insert the messages before the table (whenever we get them).
The notebook text file editor model assumed that outputs could only be appended, and not prepended.
Also needed to tell the text editor model to update once all of the data came back.
Thankfully, we have a "fast" (single-digit ms) version of being able to do clear outputs, so I'm leveraging that to ensure that we're making this change in the JSON file correctly. Is it 100% ideal? No, but as long as it works, I think the mitigation is good enough for now.

Pull Request Test Coverage Report for Build 261936467

13 of 14 (92.86%)  changed or added relevant lines in 2 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.001%) to 38.245%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/sql/workbench/contrib/notebook/browser/outputs/gridOutput.component.ts
0
1
0.0%

Files with Coverage Reduction
New Missed Lines
%

src/sql/workbench/contrib/notebook/browser/models/notebookTextFileModel.ts
1
76.43%

Totals

Change from base Build 261927440:
0.001%

Covered Lines:
19160

Relevant Lines:
45789

💛  - Coveralls


Report field name of incorrect JSON types

With the current fromJson() implementation, if the user sends an unexpected type in a JSON field (e.g. send a number for a string field), the Vert.x JsonObject implementation will cause a ClassCastException to be thrown.
While that exception contains information about the type that failed to convert (both the actual type and the expected type), it doesn't have information about the name of the field that failed, making it harder than necessary to figure out the problem.
This change adds a catch clause to each field getter and handles a ClassCastException by throwing a new exception with a message that encodes the field name where the problem occurred as well as a hopefully more friendly format for the type names (without all that Java package stuff).

I think a more useful approach would be to not throw a new ClassCastException with a weird message, but create a new exception class that encodes the field name and expected type (it can extend 'ClassCastException` for backward compatibility) then a Vert.x failure handler can detect it and format whatever message the developer wants to share with the end user.
Maybe something like this:
throw new UnexpectedJsonValueType("field", "field-type", e);

The new exception to type would have to be added to vertx-jooq-shared, of course.
Does that sound like a good idea?

Thanks again for your contribution. I really appreciate it!
I prefer the second option over a random ClassCastException that can be thrown at any point in the application. On the other hand I prefer reusing existing exceptions over creating new ones but I don't think there is one in java.lang (IllegalArgumentException comes closest but does not reflect the issue completely).

Thanks for the feedback - I've moved the error into its own type as discussed.
I hope the package is OK - please let me know any comments you have, I want to make this 100% great as per your usual standards :-)
There's also a serious bug with the previous patch, which I fixed by removing the relevant code completely - I no longer try to parse the ClassScastException message.

Hi,
While the new PR for vertx-jooq has been accepted, the PR which includes the new class UnexpectedJsonValueType has not been merged yet into vertx-jooq-shared package so when the POJOs are generated, there is an error which says the class UnexpectedJsonValueType is not found.

@mahieddine - to which code branch are you referring? The branch release4.2.0 includes the entire PR, including the new exception type, as can be seen here

Works fine in current stable release 4.2.0 from Maven Central

Hi @guss77 my bad i deleted ~/.m2 dir and compiled again and it worked, guess i had something nasty in my local repos


Allow expiry of 0

This caught me out when I was testing my code's behaviour to expired tokens, I figured a time with 0 would be expired but it's not.

technically 0 is a perfectly valid expiry time, and people using Satellizer around 1st January 1970 would be very upset.

Thanks.
That reminds me, I should update that $window.atob to use a custom Base64 decoder in https://github.com/sahat/satellizer/blob/master/src/utils.ts#L37.


Shader chunk system can exceed 8 varyings

Check out this project:
https://playcanvas.com/will/physicsperformance
The shader on the ground plane's material creates a varying for each of the 4 maps (diffuse, normal, specular, opacity). This takes the number of varyings over 8 and the program fails to link on an iPhone, for example, that can support no more than 8 varyings.

I just ran into this recently on an iPad 2 (pretty old at this point).  Shader results in too many varyings. If you look at base.frag, you guys recently commented out vVertexColor.  Could you also comment out the other varyings not being used?  Specifically vUv1 and vNormalV.  There's a comment at the top about the compiler removing unneeded stuff, but I don't think this always applies to varyings.

@guycalledfrank I just wanted to completely understand the current status of this in the engine. Am I right in saying this is still technically an issue? What are the circumstances where the number of generated varyings can still exceed 8?

@guycalledfrank is this still an issue, or have been addressed? This ticket been stalled, and shall be at least updated or requires a closure.

Closing due to age. I have not seen any shader compilation/linking issues relating to a lack of varying in the last few years.


How to remove a video that is already downloaded

General troubleshooting tips
How to remove a video that is already downloaded
Description of issue / Feature request
How to remove a video that is already downloaded

Are you using manual or automatic downloads ?
In automatic downloads, hiding the video will make sure it won't get downloaded again and delete it when reclaiming space for newer videos.
In manual I'm not exactly sure off the top of my head if I delete hidden videos too. I'll have another look if that's your setup.

Are you using manual or automatic downloads ?
In automatic downloads, hiding the video will make sure it won't get downloaded again and delete it when reclaiming space for newer videos.
In manual I'm not exactly sure off the top of my head if I delete hidden videos too. I'll have another look if that's your setup.

i found the path. check the automatically download videos button, the click show in finder

Ideally I'll add back a right click to delete or something but that works in the meantime !


Doc tweak

Give an indication, i.e., ..., in the StreamField templating examples that there may be other necessary template code needed for the StreamField template tag to work but that it's been removed for clarity.
I came to this page from "Getting Started" template examples where all the examples are rendered within {% block content %} tags, which aren't included in the StreamField template examples and therefore won't render when using the "Getting Started" template code. Spent a good while troubleshooting this; hope to save someone else the trouble.

Thanks! Merged in 9424a8eab9925f3b5266a53fcb62bbf173a2f589. (I left out the ... in the last three examples as these are complete template files in their own right, to be pulled in using {% include_block %}, and won't contain any additional code.)


Translation timeout (I will post the srt file)

using 2.3.0 here is the srt
INFO:root:Creating Selenium Webdriver instance
INFO:root:Going to https://www.deepl.com/translator
Loading Anime/[Judas] Horimiya (Season 1) [1080p][HEVC x265 10bit][Multi-Subs]/[Judas] Horimiya - S01E07.srt
... Translating chunk. 0 %
... Translating chunk. 24 %
... Translating chunk. 48 %
Traceback (most recent call last):
  File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/home/tbb/.local/lib/python3.10/site-packages/srtranslator/__main__.py", line 110, in <module>
    srt.translate(translator, args.src_lang, args.dest_lang)
  File "/home/tbb/.local/lib/python3.10/site-packages/srtranslator/srt_file.py", line 151, in translate
    translation = translator.translate(
  File "/home/tbb/.local/lib/python3.10/site-packages/srtranslator/translators/deepl_scrap.py", line 133, in translate
    raise TimeOutException("Translation timed out")
srtranslator.translators.base.TimeOutException: Translation timed out
Traceback (most recent call last):
  File "/home/tbb/translate.py", line 104, in <module>
    main(args)
  File "/home/tbb/translate.py", line 24, in main
    translate_srt(srt_file)
  File "/home/tbb/translate.py", line 58, in translate_srt
    subprocess.run(cmd, shell=True, check=True)
  File "/usr/lib/python3.10/subprocess.py", line 526, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command 'python -m srtranslator 'Anime/[Judas] Horimiya (Season 1) [1080p][HEVC x265 10bit][Multi-Subs]/[Judas] Horimiya - S01E07.srt' -i en -o tr -v -t deepl-scrap' returned non-zero exit status 1.```

Can't replicate. Maybe try run it with -S flag and show me what happens, cause It works for me.

Translating to spanish is not problem for me. Please run it with -s flag to be sure.

I run it with it already though @sinedie translation was eng to tr

Ok... thats really weird, but I'll try in another resolutions so I can replicate. Ty for invest time finding a solution

adding self.driver.execute_script("document.body.style.zoom='80%'") to def __init__(self, driver: Optional[WebDriver] = None): in deepl_scrap.py solved my problem.

it started again, I guess it because of selected proxy for that session, i guess we should select the proxies by location I mean which is closer to user @sinedie

DeepL page has different version per country... We can do that, but I don't want to mess with getting the current user location, it would be better if you can choose the enabled countries for the proxy.
Also don't want to force the selection of the country, so it could be a custom usage, not built-in in the core, but shown in examples how to do it. Just to keep the core as simple as possible (and also It is a custom configuration, so...)
It could work something like this:
   proxy = create_proxy(country_id=['US']) # the country ids are the ones in https://www.sslproxies.org/
   driver = create_driver(proxy)
   translator = DeeplTranslator(driver)

In CLI usage... maybe enable add your own proxy url? (not sure about that) or even better, always work with US proxies, that way it's gonna be the same page version on each run

@sinedie Friend sorry I know i am bothering you but I guess I really found the solution right now!
srtranslator was stuck the lines like this Frankfurter I delete these coding, and ocnvert them for example Frankfurter it worked, I think srtranslator should handle these cases

And tried again, without editing it does not work, I will provide edited and non edited version of srts to you.
https://send.vis.ee/download/d3079522309a4386/#HL3pAC-d-DIyqlVMNI5Mvg

No problem. But that is not the error. Actually, the first subtitle is . This library indeed handle this cases, and convert the line to an empty string. So.... when deepl translate it the translation length (number of lines) is different from source text length, that's why it timesout : one of the checks to know if translation is done is to check the equalty of those lenghts.
A possible quick solution could be to replace empty string for a ... character. As I really don't want to mess up deleting subtitles lines. As this library is not meant for that.
Gonna work on it. You could just add it by hand by now and translate it. Ty for catching this. 👍

@toprak Solved in v0.2.5 already in PyPi

then we can close this, thanks!


Dev session to discuss TLA+ modeling

There are very interesting questions on modeling in TLA+ raised by @ancazamfir in #314 . @konnov and I are answering them in the PR, but it might be interesting to schedule a dev session to discuss this more broadly.

Sorry I am late to react on this and the original issue. Anything we need to prepare? Or we review the comments? Should we schedule this during our regular dev sessions? If yes, I will check with Arianne for a slot.

I think the idea was just to get together for 1-2 hours and discuss the modeling issues that arise say in the light client spec, IBC, etc.

Yes, I think during a regular dev session makes sense. Some weeks ago, we discussed with @ebuchman and @milosevic that after we wrap up specs for deliverables (perhaps also at the end of a quarter) we discuss the specs, how they were written and why, etc. The goal would be to in the mid-term establish a "standard" or a common understanding how we would like to write specs.

Ok, I will talk to Arianne and schedule one.

Arianne scheduled a session for July 13th.

I guess it didn't happen after all. @milosevic , @ariannef , @ancazamfir : should we try to schedule it for some upcoming dev session? @konnov would really like to ;-)

just happened. great discussion.


CONTRIBUTING.md file created

@ali-master @EhsanAramide
Hi there I created the CONTRIBUTING.md file. Please check it out and let me know if any changes needed.
Fixing https://github.com/persian-tools/dart-persian-tools/issues/13

That is great and we have to do the same in all other repositories by their rules.


Cache schema loading in SchemaValidator

This caches the loading of IJsonSchema objects within the SchemaValidator class. Because file system based lookups are done in some situations, it may not be appropriate to have this cache static.
5-10% speedup seen when deserializing JSON into objects without a defined SchemaAttribute.

Second commit removes LINQ in the hot-path for auto serializer's Property/Key lookup.
BenchmarkDotNet=v0.10.11, OS=Windows 7 SP1 (6.1.7601.0)
Processor=Intel Xeon CPU E5-2620 v3 2.40GHzIntel Xeon CPU E5-2620 v3 2.40GHz, ProcessorCount=24
Frequency=2338369 Hz, Resolution=427.6485 ns, Timer=TSC
  [Host]     : .NET Framework 4.7 (CLR 4.0.30319.42000), 64bit RyuJIT-v4.7.2114.0
  DefaultJob : .NET Framework 4.7 (CLR 4.0.30319.42000), 64bit RyuJIT-v4.7.2114.0

                                    Method |      Mean |     Error |    StdDev |     Gen 0 |    Gen 1 |    Gen 2 |   Allocated |
------------------------------------------ |----------:|----------:|----------:|----------:|---------:|---------:|------------:|
 JsonNET_JsonSerializer_Deserialize_Stream |  10.60 ms | 0.5081 ms |  1.498 ms |  140.6250 |  62.5000 |        - |   923.51 KB |
        Manatee_JsonSerializer_Deserialize | 149.17 ms | 4.7240 ms | 13.780 ms | 3000.0000 | 437.5000 | 187.5000 | 18232.51 KB |
    New_Manatee_JsonSerializer_Deserialize |  17.17 ms | 0.2780 ms | 0.2322 ms |  625.0000 | 312.5000 |        - |  4045.12 KB |

8.5x speedup, 4.5x reduction in memory allocated.


ListConfig append deepcopies input config nodes

Closes #601
Not worried about perf:
This is something we are already doing for DictConfig, and ListConfig is not used nearly as much.

The BaseContainer._set_item_impl method uses a "no_deepcopy_set_nodes" flag to decide whether deepcopy shold be done.
I think that ListConfig.append should probably do the same...

The BaseContainer._set_item_impl method uses a "no_deepcopy_set_nodes" flag to decide whether deepcopy shold be done.
I think that ListConfig.append should probably do the same...

This is an optimization, so not super critical because ListConfigs are not common.
I added it anyway. One thing I did not add was a logic that copies anyway if the assigned node is from the same config tree. I think this is handing some edge case but I would rather see it first before I enable the same logic in append.

One thing I did not add was a logic that copies anyway if the assigned node is from the same config tree. I think this is handing some edge case but I would rather see it first before I enable the same logic in append.

I commented out the edge-case logic to see what test would fail. The following case from test_merge.py would fail:
input1 = {"n": {"a": 10}, "i": "${n}"}
input2 = {"i": {"b": 20}}
expected = {"n": {"a": 10}, "i": {"a": 10, "b": 20}}
assert expected == OmegaConf.merge(input1, input2)
assert expected == OmegaConf.unsafe_merge(input1, input2)  # fails: unsafe_merge returns {'n': {'a': 10, 'b': 20}, 'i': {'a': 10, 'b': 20}}

It seems that this edge case only happens when merging into an interpolation; the deepcopy prevents the merge from mutating other parts of the tree.
ListConfig.append does not mutate other parts of the tree, so I think we're safe.

I guess I'm a few minutes late on the review, sorry. Feel free to ignore my minor comment below.
At high level I'm fine with it but I wonder if append() wouldn't be better implemented as "append None to the underlying content list, then call set_item() on the last index". There's more stuff happening in _set_item_impl() that I don't fully grasp, which may -- or may not -- matter as well for append().

Good call.
It did cross my mind briefly but I didn't try.
Got it to work in #740.


Fixed typo

Fixed a small typo. It shows up when you don't pass SmartyStreets credentials, but doesn't seem to affect the actual geocoding.

Thanks!


Fix bug in jnp.repeat where for array repeats with zero entries (e.g. [1,0,3]) and axis=0 the zero entry was not skipped).

Looks good!


chore: Use gauge for call tracer metrics

What ❔
Use Gauge instead of histogram for CallTracer metrics
Why ❔
For better obsevability
Checklist

[ ] PR title corresponds to the body of PR (we generate changelog entries from PRs).
[ ] Tests for the changes have been added / updated.
[ ] Documentation comments have been added / updated.
[ ] Code has been formatted via zk fmt and zk lint.
[ ] Spellcheck has been run via zk spellcheck.
[ ] Linkcheck has been run via zk linkcheck.

but.. why?

It was request from @Deniallugo, they want to see more concrete maximum values of the call stack depth. I couldn't find a better way to do so, except adjusting buckets/not using histogram.


Add Cast/remote playback support

Add support for remote playback with the Cast SDK or MediaRouter

why not https://github.com/google/ExoPlayer/tree/release-v2/extensions/cast ?

I considered it! I wasn't sure if people would rather see how to use the Cast SDK directly, or if using the ExoPlayer extension was more meaningful.
What do you think?
Directly use the Cast SDK: 😄
Use the ExoPlayer Cast Extension: 🎉


Install MongoDB drivers

I completed the 3 steps below:

[x] I've read the Contribution Guide.
[x] I've updated the documentation. (refer to this for how to do so).
[x] I enjoyed my time contributing and making developer's life easier :)

Hi @walterjrp ,
I think your patch misses 2 places:

add arg INSTALL_MONGO for laravel-horizon service, something like:

- INSTALL_MONGO=${LARAVEL_HORIZON_INSTALL_MONGO}

add default value for new env LARAVEL_HORIZON_INSTALL_MONGO in env-example:

LARAVEL_HORIZON_INSTALL_MONGO=false

Ps: By the way, I don't know why laravel-horizon requires this mongodb driver?