[Feature Request]: Add Utility Snippets

Is there an existing issue for this?

[X] I have searched the existing issues

Feature Description
There are currently no issues with the existing functionality of pysnippets. However, I would like to propose the addition of new utility snippets to enhance the functionality of PySnippets. Specifically, I plan to add the following snippets:

Memoization (Caching Function Results)
Timer Context Manager
Sending an Email (using smtplib)
Sorting a List of Dictionaries by Key

These functions will provide developers with efficient solutions for common programming tasks.
Planned Changes:

Add a function for memoization to cache expensive function call results.
Create a timer context manager for measuring code execution time.
Implement a simple email sending function using smtplib.
Add a function to sort a list of dictionaries by a specified key.
Include proper comments and docstrings for code clarity and maintainability.
Create unit tests to verify the correctness of the new functions.

Benefits:
These new snippets will extend the functionality of PySnippets, making it more useful for developers by:

Improving performance with memoization techniques
Facilitating easy performance monitoring
Simplifying email automation tasks
Enhancing data manipulation capabilities

I am a gssoc-ext, hactoberfeast contributor
Record

[X] I agree to follow this project's Code of Conduct
[X] I want to work on this issue
[X] I'm willing to provide further clarification or assistance if needed.

@AashishNandakumar you have closed the issue? Don't you want to work on it?

Is it acceptable if I turn in this assignment two days later? I understand that these are basic tasks, but I'm running a bit behind schedule.

Yeah sure then raise another issue I am closing this one. All the best.


Is there a Mismatch Between Implementation and Original Paper VIME?

Hello,
I've been reviewing the implementation of the VIME in this repository and noticed some discrepancies when compared to the original paper VIME: Extending the Success of Self- and Semi-supervised Learning to Tabular Domain.
In the original paper, they only train the predictor at the second phase.But in this implementation, the encoder and predictor may be trained together at the second phase.
Should we make the encoder with no grad at the second phase to get close to the original paper.
Thanks for your attention.
Best wishes.

Thank you for bringing this to our attention.
In the next release, TabularS3L will include an option to freeze the encoder in the set_second_phase method of Lightning modules, as per your suggestion. This will align the implementation more closely with the original paper.
Best regards.

This issue has been resolved in the latest release.
If you have any further concerns or encounter new issues, please feel free to open a new issue.


format-date XSLT function is out of date

https://gchq.github.io/stroom-docs/docs/user-guide/pipelines/xslt/xslt-functions/#format-date
It doesn't make any mention of the additional args to set a custom output format.  Needs bringing in line with the java code.

Dup of #61, closing


Feature request : Set arrow keys as a way to browse aerials and toggle on/off the name of the aerial.

On AppleTV 4K, you can swipe left or right to browse other aerials.  The name/location of the aerial is also displayed.  It would be nice to include a similar feature to this screensaver.

That could be a nice feature.
Does anyone have a json for the new Aerial videos? Such as the space ones as seen here: https://www.apple.com/sa/newsroom/2018/06/apple-tv-4k-delivers-highest-quality-cinematic-experience-with-tvos-12/

@fashnbly-l8 I'm not sure if it's possible to intercept keyboard events during screensaver playback. Do you have any examples of other screensavers that are interactive? It might be dangerous to intercept keyboard events since they are usually designed to interrupt screensaver playback and restore the system to a wake state. If we did implement this feature we'd want to make sure that it's configurable and disabled by default. I think most users would expect that keyboard events will terminate screensaver playback.

I remember seeing that behavior on a 3rd-party screensaver back in the 10.3 days. The arrow keys and a few other specific keys were used to cycle/modify settings. For the life of me, I can't remember the name of it.

On AppleTV 4K, you can swipe left or right to browse other aerials. The name/location of the aerial is also displayed. It would be nice to include a similar feature to this screensaver.

Or maybe trackpad swipe, same as Apple TV:
Tap show description
Slide Left/ Right Switch between Aerials
Click or any key to exit screensaver.

@glouel I kinda like this:
Or maybe trackpad swipe, same as Apple TV:
Tap show description
Slide Left/ Right Switch between Aerials
Click or any key to exit screensaver.

I like that too but I'm not sure what kind of access we have to keyboard/trackpad. I'll have a look in next-ish update.

@glouel I know you saw this but, In #21 apparently you used to use the arrow keys to control video.
Is there anyway that you could contact JohnCoates to ask him how he did that then rewrite the functions differently?

Any progress or updates on this request? I would like it as well, if possible.

Any progress or updates on this request? I would like it as well, if possible.

It's still in the todo list, I'm not sure if we can still do that on modern macOS, we'll see next year I guess ;)

@jhewell56 and others
You can now use the right key to skip ahead, this can be disabled in preferences :

Available starting with beta 10: https://github.com/JohnCoates/Aerial/releases/tag/v1.4.7beta10


When loading a race bump RTC time if time is nower in any point than "now"

This wil help in accelerated testing when you restart and time is back to "normal" time.
Also it will avoid timejumps backwards if a race is restarted and this is wrong.

Fixed in 6c0590edac56e70bd8ec5124fd1de7758da65e6d


JSON reporting loop does not take the 'warn' argument into account.

Warnings should be opt-in like for normal reporting.

Can you edit the description of this issue to summarize the current behavior? What is getting output? Knowing that the JSON output was meant for machine consumption, my intent was to label things as error and warning and let the user filter things out however they wanted. In that world, it seems weird to opt-in to warnings.

I think this issue can be closed. I have added support in elm-vim to filter out warnings if needed, and I do not feel strongly either way if the --warn flag is used with json output.


get catchment tile number from restart file

In GEOSldas, the input bcs is not provided when remapping. So it  fails to get the tile number for the input. This PR corrects that issue and get the tile number from input restart file.

@weiyuan-jiang, @gmao-rreichle  Is this ready for testing?

Yes, I think it is ready. Actually we can ask @gmao-jkolassa 's help for the test. The issue happens when using ldas_setup

Yes, I think it is ready. Actually we can ask @gmao-jkolassa 's help for the test. The issue happens when using ldas_setup

Agreed. The tests that I asked Biljana to do include only remapping of Catch restarts, as part of the remap_restarts test suite.  We can take this opportunity to add a test case that remaps a CatchCN restart, with the help of @gmao-jkolassa.  But the first priority is to make sure we're 0-diff for remapping catch restarts, and to move forward to the point where remap_restarts.py can be rolled out for the general public (so we can retire regrid.pl).  To that end, we don't need to have everything sorted out for remapping CatchCN restarts.  The bug fix here is definitely good to have, but if the test case for remapping CatchCN restarts takes longer, we don't have to wait for it.

Sure, I can help test this. Do I understand this correctly that you need me to try setting up a Catchment-CN experiment with ldas_setup that uses restart_option 2, that is where the input restart file needs to be regridded to the experiment resolution?

Sure, I can help test this. Do I understand this correctly that you need me to try setting up a Catchment-CN experiment with ldas_setup that uses restart_option 2, that is where the input restart file needs to be regridded to the experiment resolution?

Sorry, I guess I got myself confused. When @weiyuan-jiang mentioned that @gmao-jkolassa can help, I thought we were talking about https://github.com/GEOS-ESM/GEOSgcm_GridComp/pull/770.  My previous comment from ~10 min ago really applies to https://github.com/GEOS-ESM/GEOSgcm_GridComp/pull/770.
I'm not sure how @gmao-jkolassa's help would be needed here.

Testing summary:

few standard remap restart cases all looked fine. (run directly from yaml files)
From ldas_setup (EASE grid case) from M09 to M36.  With develop that fails (confirmation why we need this PR) with this branch it passed.
From ldas_setup with CatchCN CLM 4.5, same EASE grid case M09 to M36, now its working, creating experiment (what is on develop doesn't).

@sdrabenh: This bug fix does not impact the GCM but is needed to restore full functionality for GEOSldas.  When you get a chance, please merge and create an updated release (something like v2.0.1, if this PR is the only change from v2.0.0).  Thanks!

@sdrabenh: This bug fix does not impact the GCM but is needed to restore full functionality for GEOSldas. When you get a chance, please merge and create an updated release (something like v2.0.1, if this PR is the only change from v2.0.0). Thanks!

@gmao-rreichle and @biljanaorescanin I just released v2.0.1


Listr2 breaks if number of tasks overflow the terminal height

This is a issue from Listr original but affect this version too: https://github.com/SamVerschueren/listr/issues/150

I could not come up with a good solution to this problem, even though there are some improvements.

It writes the last render as process.stdout.write.
It updates the render via the render hook if there are any changes to the task itself like a state change from pending to completed.

But depending on the terminal itself it is still prone to breaking while rendering due to log-update.
Main problem is if you increase the size of the screen, then reduce it, there may be some parts that are logged twice due to log-update's own behavior. I could not find a better lightweight library that handles this, so I guess until a suggestion is posted, it will stay with this trade-off.
You may also experience breaking or double logging of stuff when process.stdout is used by something else that writes to the console.
If you have any suggestions please feel to state them.

https://github.com/sindresorhus/log-update/issues/36
This is a related issue and makes sense to me why this is not likely to be solvable.

@cenk1cenk2 - I'm just starting to use Listr2 in a project and am getting lots of duplicates - even when there are no commands that exceed the terminal window and I'm not resizing or anything like that.  This obviously isn't directly related to this issue, but to me it indicates there are likely multiple causes.
I also have some listrs that definitely exceed the terminal window, so the following suggestion is related to similar situations.  (I also know close to nothing about terminal displays, output, etc. so take this question/suggestion with a massive grain of salt.
Instead of displaying the list at the top of the output, could the task entries display at the end of the console output, with "bookmarks" for the start and end of tasks that have their own output and plain markers for tasks that don't have their own output?
For example, say there are 4 tasks, then the initial display would include all of the tasks
┌─── terminal window (left side)
│ ⠴ Task 1
│ ◽Task 2
│ ◽Task 3
│ ◽Task 4
│
│
│
│
└───────────────────────────────

Then there's some output from the first task, so Listr2 could (a) clear the terminal, (b) add a starting bookmark for the first task (that will remain), (c) output whatever has been sent from the first task, (d) add the remaining portion of the listr, so the end result would be something like this.
┌─── terminal window (left side)
│ > Started: Task 1
│ some output from the first task
│ more output from the first task
│ and still more output from the first task
│ ⠴ Task 1
│ ◽Task 2
│ ◽Task 3
│ ◽Task 4
└───────────────────────────────

From that point one, while there's output from first task, Listr2 could (a) clear it's running "final" display, (b) output whatever has been sent from the first task, (c) and add the remaining portion of the listr
┌─── terminal window (left side)
│ more output from the first task
│ and still more output from the first task
│ subsequent first task output
│ and still more subsequent first task output
│ ⠴ Task 1
│ ◽Task 2
│ ◽Task 3
│ ◽Task 4
└───────────────────────────────

Once there's a final status from the first task, Listr2 could (a) clear it's running "final" display, (b) output whatever has been sent from the first task, (c) output the ending bookmark for the task, and (d) add the remaining portion of the listr
┌─── terminal window (left side)
│ and still more output from the first task
│ subsequent first task output
│ and still more subsequent first task output
│ final output from the first task
│ ✔ Completed: Task 1
│ ⠴ Task 2
│ ◽Task 3
│ ◽Task 4
└───────────────────────────────

With all the remaining tasks that have their own output, the process would be similar (a) clear out the running "final" display, (b) if it's the first output from the task, output a started bookmark, (c) output whatever has been sent from the task, (d) if it's the final output from the task, output a completed bookmark, and (e) add the remaining portion of the listr
┌─── terminal window (left side)
│ ✔ Completed: Task 1
│ > Started: Task 2
│ task 2 output
│ more task 2 output
│ final task 2 output
│ ✔ Task 2
│ ⠴ Task 3
│ ◽Task 4
└───────────────────────────────

For any task that doesn't have output, then treat that task like normal
┌─── terminal window (left side)
│ ✔ Completed: Task 1
│ > Started: Task 2
│ task 2 output
│ more task 2 output
│ final task 2 output
│ ✔ Completed: Task 2
│ ✔ Task 3
│ ⠴ Task 4
└───────────────────────────────

Once all the tasks have been completed (successful or not), display the complete list with statuses
┌─── terminal window (left side)
│ task 4 output
│ final task 4 output
│ ✔ Completed: Task 4
│
│ ✔ Task 1
│ ✔ Task 2
│ ✔ Task 3
│ ✔ Task 4
└───────────────────────────────

Unless the listr itself exceeded the window (and hopefully people aren't making such ginormous listrs) than this approach wouldn't require clearing text from output that has moved out of the frame (my current understanding of the problem), it would only1 ever mean removing the "running" list at the bottom of output, possibly adding starting or ending bookmarks, outputting the current task's output, and adding the "running" or final list back in.
Regardless of this issue, thank you for picking up the work of Listr and being such an active maintainer!

1: Again, I have no real understanding of what is actually going on under the hood, I'm just deducing based on the previous comment's link.  So the "only" is totally an assumption on my part.

The problem of duplicate lines in the output is related to the restriction, within which it is not possible to change the value of a line outside the work area.
I will try to explain on the diagram:

Changing the state of the output is possible only within the active area, from row 0/col 0 to row N/col N. Where the number of rows and columns depends on the size of your console.
For more see:
TTY
readline
readline source
TTY keybindings
As a solution to this limitation, I would suggest to output a large amount of information to the console at the end of all operations or when an error occurs.

@keindev - The goal of my suggestion was to work within the constraint that you're describing.
Using my previous examples, it would function something like the following (note that console output is only ever removed from the active console area).
For example, say there are 4 tasks, then the initial display would include all of the tasks
┌─── terminal window (left side)
│ ⠴ Task 1                                           // added
│ ◽ Task 2                                          // added
│ ◽ Task 3                                          // added
│ ◽ Task 4                                          // added
│
│
│
└────────────────────────────────── (end of active console area)

Then there's some output from the first task, so Listr2 could (a) clear the terminal, (b) add a starting bookmark for the first task (that will remain), (c) output whatever has been sent from the first task, (d) add the remaining portion of the listr, so the end result would be something like this.
(a) clear the terminal

┌─── terminal window (left side)
│                                                     // cleared
│                                                     // cleared
│                                                     // cleared
│                                                     // cleared
│
│
│
└────────────────────────────────── (end of active console area)

(b) add a starting bookmark for the first task (that will remain)

┌─── terminal window (left side)
│ > Started: Task 1                                     // added
│
│
│
│
│
│
└────────────────────────────────── (end of active console area)

(c) output whatever has been sent from the first task

┌─── terminal window (left side)
│ > Started: Task 1
│ some output from the first task                       // added
│ more output from the first task                       // added
│ and still more output from the first task             // added
│
│
│
└────────────────────────────────── (end of active console area)

(d) add the remaining portion of the listr, so the end result would be something like this.
┌─── terminal window (left side)
│ > Started: Task 1
│ some output from the first task
│ more output from the first task
│ and still more output from the first task
│ ⠴ Task 1                                              // added
│ ◽Task 2                                               // added
│ ◽Task 3                                               // added
│ ◽Task 4                                               // added
└────────────────────────────────── (end of active console area)

From that point one, while there's output from first task, Listr2 could (a) clear its running "final" display, (b) output whatever has been sent from the first task, (c) and add the remaining portion of the listr
(a) clear its running "final" display

┌─── terminal window (left side)
│ > Started: Task 1
│ some output from the first task
│ more output from the first task
│ and still more output from the first task
│                                                     // cleared
│                                                     // cleared
│                                                     // cleared
│                                                     // cleared
└────────────────────────────────── (end of active console area)

(b) output whatever has been sent from the first task

┌─── terminal window (left side)
│ > Started: Task 1
│ some output from the first task
│ more output from the first task
│ and still more output from the first task
│ subsequent first task output                          // added
│ and still more subsequent first task output           // added
│
│
└────────────────────────────────── (end of active console area)

(c) and add the remaining portion of the listr
┌─── terminal window (left side)
│ > Started: Task 1
│ some output from the first task
├────────────────────────────────── (beginning of active console area)
│ more output from the first task
│ and still more output from the first task
│ subsequent first task output
│ and still more subsequent first task output
│ ⠴ Task 1                                              // added
│ ◽ Task 2                                              // added
│ ◽ Task 3                                              // added
│ ◽ Task 4                                              // added
└────────────────────────────────── (end of active console area)

Once there's a final status from the first task, Listr2 could (a) clear it's running "final" display, (b) output whatever has been sent from the first task, (c) output the ending bookmark for the task, and (d) add the remaining portion of the listr
(a) clear its running "final" display

┌─── terminal window (left side)
│ > Started: Task 1
│ some output from the first task
├────────────────────────────────── (beginning of active console area)
│ more output from the first task
│ and still more output from the first task
│ subsequent first task output
│ and still more subsequent first task output
│                                                     // cleared
│                                                     // cleared
│                                                     // cleared
│                                                     // cleared
└────────────────────────────────── (end of active console area)

(b) output whatever has been sent from the first task

┌─── terminal window (left side)
│ > Started: Task 1
│ some output from the first task
├────────────────────────────────── (beginning of active console area)
│ more output from the first task
│ and still more output from the first task
│ subsequent first task output
│ and still more subsequent first task output
│ final output from the first task                      // added
│
│
│
└────────────────────────────────── (end of active console area)

(c) output the ending bookmark for the task

┌─── terminal window (left side)
│ > Started: Task 1
│ some output from the first task
├────────────────────────────────── (beginning of active console area)
│ more output from the first task
│ and still more output from the first task
│ subsequent first task output
│ and still more subsequent first task output
│ final output from the first task
│ ✔ Completed: Task 1                                   // added
│
│
└────────────────────────────────── (end of active console area)

(d) add the remaining portion of the listr
┌─── terminal window (left side)
│ > Started: Task 1
│ some output from the first task
│ more output from the first task
├────────────────────────────────── (beginning of active console area)
│ and still more output from the first task
│ subsequent first task output
│ and still more subsequent first task output
│ final output from the first task
│ ✔ Completed: Task 1                                   // added
│ ⠴ Task 2                                              // added
│ ◽ Task 3                                              // added
│ ◽ Task 4                                              // added
└────────────────────────────────── (end of active console area)

With all the remaining tasks that have their own output, the process would be similar (a) clear out the running "final" display, (b) if it's the first output from the task, output a started bookmark, (c) output whatever has been sent from the task, (d) if it's the final output from the task, output a completed bookmark, and (e) add the remaining portion of the listr
┌─── terminal window (left side)
│ > Started: Task 1
│ some output from the first task
│ more output from the first task
│ and still more output from the first task
│ subsequent first task output
│ and still more subsequent first task output
│ final output from the first task
├────────────────────────────────── (beginning of active console area)
│ ✔ Completed: Task 1
│ > Started: Task 2
│ task 2 output
│ more task 2 output
│ final task 2 output
│ ✔ Completed: Task 2
│ ⠴ Task 3
│ ◽ Task 4
└────────────────────────────────── (end of active console area)

For any task that doesn't have output, then treat that task like normal
┌─── terminal window (left side)
│ > Started: Task 1
│ some output from the first task
│ more output from the first task
│ and still more output from the first task
│ subsequent first task output
│ and still more subsequent first task output
│ final output from the first task
├────────────────────────────────── (beginning of active console area)
│ ✔ Completed: Task 1
│ > Started: Task 2
│ task 2 output
│ more task 2 output
│ final task 2 output
│ ✔ Completed: Task 2
│ ✔ Task 3                                           // replaced
│ ⠴ Task 4
└────────────────────────────────── (end of active console area)

Once all the tasks have been completed (successful or not), display the complete list with statuses
┌─── terminal window (left side)
│ > Started: Task 1
│ some output from the first task
│ more output from the first task
│ and still more output from the first task
│ subsequent first task output
│ and still more subsequent first task output
│ final output from the first task
│ ✔ Completed: Task 1
│ > Started: Task 2
│ task 2 output
│ more task 2 output
│ final task 2 output
│ ✔ Completed: Task 2
│ ✔ Task 3
│ > Started: Task 4
├────────────────────────────────── (beginning of active console area)
│ task 4 output
│ final task 4 output
│ ✔ Completed: Task 4
│
│ ✔ Task 1
│ ✔ Task 2
│ ✔ Task 3
│ ✔ Task 4
└────────────────────────────────── (end of active console area)

It doesn't address a window size change, but I think it could solve aspects of the duplication problem.
Or am I missing something?

@metasean Yes, at step (c), there is a shift 2 lines down beyond the active area. At this point (as far as I believe, since I was solving a similar problem in tasktree-cli):

there is a new iteration of rendering (every 100ms for example), so that the spinner spins around tasks (⠴ => ⠦ => ⠧)
during this rendering, the same list from step (c) is updated and it is not taken into account that the next step shifted the scroll up by 2 lines and made them inaccessible for cleaning.
the drawing of the step (c) starts from the 0 position, excluding the 2 lines shifted upwards, and at this moment the output is duplicated

I have a test for this situation, I do not know how much of what is happening in it will be clear.
Overall I think stdout-update will solve this problem.

There is a new version published with 4.0.0-beta.x, which has stdout-update implemented in.
Even though it is not finalized yet and breaks some tests because of the difference of clearing lines between applications, it seems to work a charm. Thank you again @keindev for this beautiful plugin.
It will be merged with a later set of changes that I have in mind as a major version which can be tracked in the milestones.
If you have time and still have to go on projects with Listr2 you can give it a try by installing it with yarn add listr2@beta.
I would love to have some feedback, if possible.

@cenk1cenk2 Do you mind if I ask what is the current progress of getting this moved out of beta and in to the main version? Is there something else holding back this switch to stdout-update? I would be brilliant to get this fix out in the wild 😄!

Hello @Josh-Walker-GM,
Unfortunately, that solution has its own problems with making it compatible with the current form of the library.
But the case is since node.js can not access more than the terminal height, I suppose it might be no solution for the initial issue mentioned here but a limitation of how terminals handle themselves if I am not missing something.

This has been moved to looking for contrubitions since I have failed to implement in stdout-update a couple of times, in some cases, it just generates no output in tests which is very weird.
I will close this issue now since it is mentioned in the documentation.


Feat: Upgrade Teambuilder Input

Improve the style of the teambuilder pokemon selector.
Requirements

[ ] Set the height of the image, so that the form doesn't jump and and down when switching between Pokemon or shiny forms
[ ] Improve the spacing of the form (no designs here, just go with something aesthetically pleasing)
[ ] Add the ATK, DEF, and HP level to the IVs

We do have the figma for a guideline, but we heavily strayed off the original mockup.


[cocoon] handle engine .ci.yaml in different location

There are commands that validate "runIf".  In a merged world, either we have merged ci.yaml or we have to handle two.
        // Verify runIf includes foundational files.
        if (target.runIf.isNotEmpty) {
          if (!target.runIf.contains('.ci.yaml')) {
            exceptions.add('ERROR: ${target.name} is missing `.ci.yaml` in runIf');
          }
          if (slug == Config.engineSlug && !target.runIf.contains('DEPS')) {
            exceptions.add('ERROR: ${target.name} is missing `DEPS` in runIf');
          }
        }

@christopherfujino: would you want to have merged ci.yaml files? if so, would we want to have some flag for engine tests?

@christopherfujino: would you want to have merged ci.yaml files? if so, would we want to have some flag for engine tests?

What do you mean by "merged ci.yaml files"?
Could we just update the cocoon code to be:
        // Verify runIf includes foundational files.
        if (target.runIf.isNotEmpty) {
          if (!target.runIf.contains('.ci.yaml')) {
            exceptions.add('ERROR: ${target.name} is missing `.ci.yaml` in runIf');
          }
-          if (slug == Config.engineSlug && !target.runIf.contains('DEPS')) {
+          if (_isMonoRepo(repo) && slug == Config.engineSlug && !target.runIf.contains('DEPS')) {
            exceptions.add('ERROR: ${target.name} is missing `DEPS` in runIf');
          }
        }

Where _isMonoRepo() checks if it's a flutter/flutter repo with the engine in it?

What do you mean by "merged ci.yaml files"?

Is there a world where we want to cat .ci.yaml engine/src/flutter/.ci.yaml > .ci.yaml or keep them apart? (this is not how we would merge them).

Where _isMonoRepo() checks if it's a flutter/flutter repo with the engine in it?

In your example we'd need to have
if ((isMonoRepo(repo) || slug == Config.engineSlug) && !target.runIf.contains('DEPS')) {
}

The problem with that block is its not checking if the ci.yaml is the one from the engine/src/flutter folder.

Is there a world where we want to cat .ci.yaml engine/src/flutter/.ci.yaml > .ci.yaml or keep them apart? (this is not how we would merge them).

Ahh, I see what you mean. I think for this initial change we should keep them separate. All of our infrastructure has baked in assumptions that the build environments for the two repos are separate, so I think we should keep them separate for now.

And yes, you're right about the code sample :)

I think for this initial change we should keep them separate

Thanks - I thought the same. I'll file a future feature request after the dust settles!

@christopherfujino - CiYaml doesn't appear to have a PR to check with.  Would you be opposed to adding monorepo: false to ci.yaml (both locations) which we could use internally on some of these checks?

CiYaml doesn't appear to have a PR to check with.

What do you mean by this? Do you mean the Dart class within the cocoon app_dart project does not have a reference to the PR from which to introspect the file structure? If so, I think adding a top-level monorepo boolean field to .ci.yaml that defaults to false would make sense.

I mean the dart class, CiYaml, is handed parsed contents:
  CiYaml({
    required this.slug,
    required this.branch,
    required this.config,
    CiYaml? totConfig,
    bool validate = false,
  }) {

I'm already going to have to find every site that looks up flutter/flutter/.ci.yaml and make it check flutter/flutter/engine/src/flutter/.ci.yaml and that would work from the top end; but if you're handed only scheduler configs deeper down; how do you know its a monorepo or not? If you have a PR, we can check for files, but in other cases its just "here's yaml".
Instead of updating the actual files; I could update the proto to have the field and set it when we fetch the contents.

We could also change the meaning of slug. Today slug means what repo you're operating on. We could change slug to be an enum, including:

flutter/flutter framework
flutter/engine engine
monorepo framework
monorepo engine

I'm not sure if that creates more work or not. We'd have to figure out, at call time, which slug we are in.

scheduler.dart looks at the PR
  /// Load in memory the `.ci.yaml`.
  Future<CiYaml> _getCiYaml(

This is called twice; once to get tip of tree, and the second time to get the one for the commit:
  /// Process and filters ciyaml.
  Future<CiYaml> getCiYaml(
    Commit commit, {
    bool validate = false,
  }) async {
    final Commit totCommit = await generateTotCommit(slug: commit.slug, branch: Config.defaultBranch(commit.slug));
    final CiYaml totYaml = await _getCiYaml(totCommit);
    return _getCiYaml(commit, totCiYaml: totYaml, validate: validate);
  }```

The CI path is hard-coded:

```dart
    ciPath = '${commit.repository}/${commit.sha!}/$kCiYamlPath';

I think this should potentially return an array of ciyaml, based on the needs of the PR under presubmit... "isEngine()" "isFramework()"


[Docs] Add note for withPreparedSets() on php 7.x

On php 7.x, the named argument is not yet exists, this update doc to clarify it.
Ref https://github.com/rectorphp/rector/issues/8653
/cc @orionseye

Using diff for better see the different:

Ready to merge 👍

I think calling the methods like this:
->withPreparedSets(true, false, true, true);

could be a bit unreadable :) I'd recommend to use withSets([...]) instead, untill the project is upgraded to PHP 8.

Ok, updated with withSets()

Thank you :clap:


Migration of the podcast transcription and data storage pipeline in the HPC server

Item type: Feature request
Description: Migrate the established data retrieval and storage pipeline for podcasts to the FAU HPC server and complete the data retrieval, transcription and storage to the FAU server of all the episodes of the podcasts that are included in the sources spreadsheet:
https://docs.google.com/spreadsheets/d/1yq9mRF1P-1DX1i4nd-avEPkFQBNBTNt8-AYm-IrnZk4/edit#gid=309090183
User story

As an industry partner (developer-entrepreneur)
I need to have access text data from selected sources
so that I can later used them for context generation

Acceptance criteria

The the established data retrieval and storage pipeline for podcasts has been migrated to the HPC server.
The transcript data of all the episoeds and podcasts that are included in the sources spreadsheet have been retrieved and are stored in the HPC server in a way that are accessible by all team members.

@lukas-varga Will we need such a step now that we will work with Google Storage, so does this item need to be converted to be relative for GC instead of the HPC?

@lukas-varga, @preetvadaliya Will we need such a step now that we will work with Google Storage, so does this item need to be converted to be relative for GC instead of the HPC?

Yeah I guess so converting to GC makes sense.

@lukas-varga,
@preetvadaliya
Guys, after the refactorings of last week in the orhestrator etc, are we still in need of such a step here?
 If so what would the alterations need to be?

As far as I understand Preet has finished fully working HPC and GC, where we can deploy our project, so this task seems redundant to me.


[Enhancement] Allow one-phase local aggregate in the single BE

What type of PR is this：

[ ] bug
[ ] feature
[x] enhancement
[ ] refactor
[ ] others

Problem Summary：

If there is only one BE and one fragment instance, we could generate one-phase local aggregation with the local shuffle operator (Scan->OnePhaseAgg->LocalShuffle) regardless of the differences between grouping keys and scan distribution keys.
Modification

Add withLocalShuffle to LogicalAggregationOperator and PhysicalAggregationOperator.
Add GenerateAggregateWithLocalShuffleRule to set LogicalAggregationOperator#withLocalShuffle as true.
HashDistributionSpec#isSatisfy() returns true when required property need local shuffle, and this is LOCAL scan.
PlanFragmentBuilder#visitPhysicalHashAggregate() set isNeedLocalShuffle and AssignScanRangesPerDriverSeq according to PhysicalAggregationOperator#withLocalShuffle.

run starrocks_fe_unittest

[FE PR Coverage Check]
:heart_eyes: pass : 80 / 81 (98.77%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/optimizer/base/HashDistributionDesc.java
8
9
88.89%
[131]

:large_blue_circle:
com/starrocks/sql/optimizer/RequiredPropertyDeriver.java
3
3
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/Optimizer.java
2
2
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/rule/transformation/GenerateAggregateWithLocalShuffleRule.java
15
15
100.00%
[]

:large_blue_circle:
com/starrocks/qe/SessionVariable.java
5
5
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/rule/RuleSet.java
2
2
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/rule/implementation/HashAggImplementationRule.java
2
2
100.00%
[]

:large_blue_circle:
com/starrocks/sql/plan/PlanFragmentBuilder.java
7
7
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/operator/physical/PhysicalHashAggregateOperator.java
6
6
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/operator/logical/LogicalAggregationOperator.java
11
11
100.00%
[]

:large_blue_circle:
com/starrocks/qe/Coordinator.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/rule/RuleType.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/PropertyDeriverBase.java
3
3
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/base/HashDistributionSpec.java
3
3
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/rewrite/AddDecodeNodeForDictStringRule.java
2
2
100.00%
[]

:large_blue_circle:
com/starrocks/planner/PlanFragment.java
4
4
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/cost/CostModel.java
5
5
100.00%
[]

[FE PR Coverage Check]
:heart_eyes: pass : 86 / 87 (98.85%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/optimizer/base/HashDistributionDesc.java
8
9
88.89%
[131]

:large_blue_circle:
com/starrocks/sql/optimizer/RequiredPropertyDeriver.java
3
3
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/Optimizer.java
2
2
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/rule/transformation/GenerateAggregateWithLocalShuffleRule.java
15
15
100.00%
[]

:large_blue_circle:
com/starrocks/qe/SessionVariable.java
5
5
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/rule/RuleSet.java
2
2
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/rule/implementation/HashAggImplementationRule.java
2
2
100.00%
[]

:large_blue_circle:
com/starrocks/planner/AggregationNode.java
5
5
100.00%
[]

:large_blue_circle:
com/starrocks/sql/plan/PlanFragmentBuilder.java
8
8
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/operator/physical/PhysicalHashAggregateOperator.java
6
6
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/operator/logical/LogicalAggregationOperator.java
11
11
100.00%
[]

:large_blue_circle:
com/starrocks/qe/Coordinator.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/rule/RuleType.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/PropertyDeriverBase.java
3
3
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/base/HashDistributionSpec.java
3
3
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/rewrite/AddDecodeNodeForDictStringRule.java
2
2
100.00%
[]

:large_blue_circle:
com/starrocks/planner/PlanFragment.java
4
4
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/cost/CostModel.java
5
5
100.00%
[]

run starrocks_admit_test

run starrocks_admit_test

run starrocks_admit_test

run starrocks_admit_test

The enhancement point is handle the sence about high cardinality aggregate on one BE node, and will compare cost of single-stage aggregate plan and multi-stage aggregate plan, but we conside some question:

when the optimize return a single-stage aggregate with exchange,  means it's must a high cardinality aggregate, not low cardinality aggregate, so to compare the cost of local-shuffle mode is meaningless
the enhancement only work when scan on one BE node, but the optimizer don't care the actually execute node now, so optimizer don't know the scan only work on one BE node, I think the optimizer need to consider this in the future and need a complete solution, but the way of this pr is too intrusive for optimizer framework.

So I have a suggestion, you can modify on FragmentBuilder:

can be modify then the Fragment generate way
add mark on exchange node to do local-shuffle
mark the BE node on ScanNode, and check isn't only one BE node when meet aggregate node.

and consider the point 1, you don't care the optimizer will return a multi-stage aggregate plan when low cardinality aggregate.


Specify output image dimensions

Hello,
is it possible to generate output image with fixed width & height no matter how long data is?
Thanks for the work.

The size of the QR Code image is tied to the amount of data to be stored. However, you could output the QR Code as SVG and then squeeze it into a fixed size container.


separate confused value and label for checkbox

Please makes sure these boxes are checked before submitting your PR, thank you!

[x] Make sure you follow Element's contributing guide (中文 | English).
[x] Make sure you are merging your commits to dev branch.
[x] Add some descriptions and refer relative issues for you PR.

checkbox的label和value应该是区分开的，现在貌似混淆了，比如我想让label显示为article.name,让checkbox选中时的值为article._id现在貌似实现不了

我才发现这个组件是有slot的，但是文档里没有说明


Tab Completions for CMD?

Is there any way to provide custom tab completions for CMD too? Is it even possible?
Can anyone from commandline team comment on this? /cc @zadjii-msft @cinnamon-msft

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 341f0255-aa31-8e76-9b17-1232b7a910a9
Version Independent ID: f30f63dc-0d90-7dba-ef39-b0148c637c1a
Content: Enable tab completion - .NET Core CLI
Content Source: docs/core/tools/enable-tab-autocomplete.md
Product: dotnet-core
Technology: dotnet-cli
GitHub Login: @Thraka
Microsoft Alias: adegeo

Pretty much no, cmd.exe doesn't support anything like this. CMD is a pretty legacy piece of software, if you'd like a shell with modern CLI features on Windows, the guidance is largely just "use PowerShell or WSL"

Hi @Nirmal4G,
Thank you for asking this question, and thank you @zadjii-msft for the quick reply. I'm going to close this now as it seems a though it has been resolved.


[Automated] Update eventing-istio-eventing nightly (#299)

Update eventing nightly
Signed-off-by: Knative Automation<EMAIL_ADDRESS>

OCF Webhook is merging this PR


Clean up measure/line height on display docs

These are purely visual changes for the display docs page.
Before:

After:

Keeps all the whitespace and line height more consistent.

So rad!

😊


Remove BPF mount if Cilium is specified as Network Plugin

When copied over from AKS-engine, this was initially here to to mount the BPFFS for Cilium.
Since then, Cilium has been updated to use systemd mount for the BPFFS. This gets done as part of the cilium-node-init startup script.
                 ...
                  mount | grep "/sys/fs/bpf type bpf" || {
                    echo "Mounting BPF filesystem..."
                    mount bpffs /sys/fs/bpf -t bpf
                    echo "Installing BPF filesystem mount"
                    cat >/tmp/sys-fs-bpf.mount <<EOF
                 ...

can you update unit test?

can you update unit test?

Hi Tony. I don't think is any unit tests for Cilium currently. And we're actually moving away from setting up non kubenet/azurecni/calico, so it may make more sense to just slowly phase these out from AgentBaker as they seemed to just have been copied from aks-engine.

Think we need to regnerate some files after these changes. Charlie should be quite familiar with this now.

Think we need to regnerate some files after these changes. Charlie should be quite familiar with this now.

Yup, @mattstam you need to run make generate and commit the diff.

Think we need to regnerate some files after these changes. Charlie should be quite familiar with this now.

Yup, @mattstam you need to run make generate and commit the diff.
From a previous conversation I had with Erik Wu:
"every time you made changes in that parts/ folder (i.e shell scripts, yaml files, etc), you should run make generate"

Also, from Erik:
"That make target also does a shell-check at the end. That might fail if you're not on a mac or ubuntu i believe in which case you can ignore. The upstream github repo will re-run shell-check anyways."
BTW, the check was failing for me on WSL, and I don't believe its been fixed yet.

 Lets try and fix them on monday and I'll help merge this in.

This PR confuses Github so retrying in https://github.com/Azure/AgentBaker/pull/638


Possibility to use KVM+Firecraker/Ignite

What would you like to be added:
I understood that aws team is not inclined to support KVM at this stage. But I want to highlight that Firecracker can further help the users to narrow the gap between cloud and onprem offering and help to implement something like EKS-Fargate-Anywhere.
Further restricting to vshpere is not a good strategy, there should be some low-cost/open-source support too.
Why is this needed:
On-prem serverless. Community tooling.

Hello @rverma-nsl ,
Thanks for the suggestion!  I've added a thumbs up to track interest.


docs: autogenerate some docs from cobra

Hello @pmt, @yuindustries,
Please review the following commits I made in branch nicks/docs2:
d2095225edbdb93e6c7347dcad76b0c6564649b6 (2018-08-06 10:27:43 -0400)
docs: autogenerate some docs from cobra

i know! one of the big advantages of using cobra is that it generates nice docs


Azure: Failed to start CoreOS Metadata Agent

coreos-metadata.service does not start on Core OS in Azure.
Operating System Version
> cat /etc/os-release
NAME="Container Linux by CoreOS"
ID=coreos
VERSION=1800.5.0
VERSION_ID=1800.5.0
BUILD_ID=2018-07-28-2250
PRETTY_NAME="Container Linux by CoreOS 1800.5.0 (Rhyolite)"
ANSI_COLOR="38;5;75"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://issues.coreos.com"
COREOS_BOARD="amd64-usr"

coreos-metadata Version
Environment
Azure VM
Expected Behavior
coreos-metadata.service starts
Actual Behavior
coreos-metadata.service fails
Other Information
> sudo journalctl -u coreos-metadata.service
-- Logs begin at Thu 2018-08-02 14:43:17 UTC, end at Thu 2018-08-02 15:03:11 UTC. --
Aug 02 14:47:20 teamcity systemd[1]: Starting CoreOS Metadata Agent...
Aug 02 14:47:20 teamcity coreos-metadata[1503]: Aug 02 14:47:20.742 INFO Fetching http://<IP_ADDRESS>/?comp=versions: Attempt #1
Aug 02 14:47:20 teamcity coreos-metadata[1503]: Aug 02 14:47:20.765 INFO Fetch successful
Aug 02 14:47:20 teamcity coreos-metadata[1503]: Aug 02 14:47:20.765 INFO Fetching http://<IP_ADDRESS>/machine/?comp=goalstate: Attempt #1
Aug 02 14:47:20 teamcity coreos-metadata[1503]: Aug 02 14:47:20.769 INFO Fetch successful
Aug 02 14:47:20 teamcity coreos-metadata[1503]: Aug 02 14:47:20.971 INFO Fetching http://<IP_ADDRESS>/machine/aa786c20-80a9-4a09-8936-2104c27e6e5c/7f691c1e%2D37bf%2D4b9a%2D8c90%2D010bcc7c4277.%5Fteamcity?comp=certificates&incarnation=2>
Aug 02 14:47:20 teamcity coreos-metadata[1503]: Aug 02 14:47:20.979 INFO Fetch successful
Aug 02 14:47:20 teamcity coreos-metadata[1503]: thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /build/amd64-usr/var/tmp/portage/dev-libs/rustlib-1.26.0/work/rustc-1.26.0-src/src/libcore/option.rs:335:21
Aug 02 14:47:21 teamcity systemd[1]: coreos-metadata.service: Main process exited, code=exited, status=101/n/a
Aug 02 14:47:21 teamcity systemd[1]: coreos-metadata.service: Failed with result 'exit-code'.
Aug 02 14:47:21 teamcity systemd[1]: Failed to start CoreOS Metadata Agent.

> cat /usr/lib/systemd/system/coreos-metadata.service
[Unit]
Description=CoreOS Metadata Agent

[Service]
Type=oneshot
Environment=COREOS_METADATA_OPT_PROVIDER=--cmdline
ExecStart=/usr/bin/coreos-metadata ${COREOS_METADATA_OPT_PROVIDER} --attributes=/run/metadata/coreos

[Install]
RequiredBy=metadata.target

It could be caused by the recent changes made by @csssuf and @sdemos in the: https://github.com/coreos/coreos-metadata/blob/master/src/providers/azure/mod.rs

Those changes haven't made it into a release yet, so this is an existing bug. There are a number of unwrap()s in the Azure crypto logic which should probably be removed in favor of proper error reporting, one of which is likely the cause of this issue.

The Azure crypto logic is definitely messy. Doing a chain_err instead of unwrap is definitely the way to go, I think I left those there initially because of assumptions (that might be wrong) about the cryptographic structures I was getting back from the API. Also, since it's Option::unwrap and not Result::unwrap, only 3 of the 5 unwrap calls apply (these: https://github.com/coreos/coreos-metadata/blob/master/src/providers/azure/crypto/mod.rs#L66, https://github.com/coreos/coreos-metadata/blob/master/src/providers/azure/crypto/mod.rs#L74, https://github.com/coreos/coreos-metadata/blob/master/src/providers/azure/crypto/mod.rs#L75)
@dtretyakov do you have this machine configured with a public ssh key? If so, what is the key type?
Also, as a funny side node, this is another situation that will be fixed by https://github.com/coreos/bugs/issues/2362, since all the unwrap calls are related to retrieving the public ssh keys but it's causing the coreos-metadata --attributes to fail.

@sdemos, this machine was created with username/password pair:

So it looks like it may not have expected ssh key.

@dtretyakov if you have the opportunity at some point, I would be very interested in seeing what happens when you get the backtrace as @csssuf suggested. I have a guess as to which unwrap it is triggering (https://github.com/coreos/coreos-metadata/blob/master/src/providers/azure/crypto/mod.rs#L66) but it would be nice to know for sure.
As far as fixing this bug, we should audit all locations where unwrap is used, since it's likely not what we actually want to do. However, the next release of coreos-metadata should stop triggering it in your particular case.
I suspect you can work around this by providing an ssh public key in the web UI. If you still need the username and password to be created, it's possible to do this using ignition in the passwd section (see the passwd section of the ignition specification)

I've verified that the case with ssh public key works fine.
When was used username/password pair I've tried to enable backtrace for rust but it looks like it does not take any effect:
> export RUST_BACKTRACE=1
> /usr/bin/coreos-metadata --cmdline --attributes=/run/metadata/coreos
Aug 03 07:57:35.480 INFO Fetching http://<IP_ADDRESS>/?comp=versions: Attempt #1
Aug 03 07:57:35.482 INFO Fetch successful
Aug 03 07:57:35.483 INFO Fetching http://<IP_ADDRESS>/machine/?comp=goalstate: Attempt #1
Aug 03 07:57:35.485 INFO Fetch successful
Aug 03 07:57:35.673 INFO Fetching http://<IP_ADDRESS>/machine/aadeb670-1ea7-40f2-bee2-a27287cbfc48/86dcad60%2Dca5b%2D45aa%2D91e7%2Df8780e4a7847.%5Fteamcity?comp=certificates&incarnation=2: Attempt #1
Aug 03 07:57:35.682 INFO Fetch successful
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /build/amd64-usr/var/tmp/portage/dev-libs/rustlib-1.26.0/work/rustc-1.26.0-src/src/libcore/option.rs:335:21
> echo $RUST_BACKTRACE
1

This should be fixed in 2.0.0. For ContainerLinux, it is now released as part of 1871.0.0.
I'm going ahead and closing this. @dtretyakov feel free to followup if you are still hitting this in the latest release.

@lucab, thanks, in CoreOS v1871 it works. Waiting when it will be available in the Stable channel.


French translations for the app

I'm waiting for merge pull request for SUBSCRIPTIONS to add translations in this files because there will be several changes !

No problem, it will be with further updates ;-)


Create check_screenshot.yml

this code checks for any screenshot in pr for readibility

this solves issue #60


Engine roll failed post-submit verify-binaries-signed-macos test

This engine roll https://github.com/flutter/flutter/pull/60254 failed this https://cirrus-ci.com/task/5637314439282688.
This test is not supposed to run on master.
This was temporarily skipped, and the skip landed on dev 1.20.0-1.0.pre.

I believe @fkorotkov is currently investigating.

Indeed the task had CIRRUS_BASE_BRANCH set to dev which means a corresponding Check Suite event had base.ref set to dev. Here is the webhook event:

```json
{
  "action": "requested",
  "check_suite": {
    "id": 841735204,
    "node_id": "MDEwOkNoZWNrU3VpdGU4NDE3MzUyMDQ=",
    "head_branch": "master",
    "head_sha": "5d2c8694bcc0e1942ef0e4876c8a106e1b537adf",
    "status": "queued",
    "conclusion": null,
    "url": "https://api.github.com/repos/flutter/flutter/check-suites/841735204",
    "before": "c68758fab137f751d56faa1ced119b7a3561e37e",
    "after": "5d2c8694bcc0e1942ef0e4876c8a106e1b537adf",
    "pull_requests": [
      {
        "url": "https://api.github.com/repos/flutter/flutter/pulls/60287",
        "id": 440064516,
        "number": 60287,
        "head": {
          "ref": "master",
          "sha": "c68758fab137f751d56faa1ced119b7a3561e37e",
          "repo": {
            "id": 31792824,
            "url": "https://api.github.com/repos/flutter/flutter",
            "name": "flutter"
          }
        },
        "base": {
          "ref": "dev",
          "sha": "f73f498da1fe4224e29cf9692161575a3d994f8f",
          "repo": {
            "id": 31792824,
            "url": "https://api.github.com/repos/flutter/flutter",
            "name": "flutter"
          }
        }
      },
      {
        "url": "https://api.github.com/repos/25ma/flutter/pulls/1",
        "id": 419879049,
        "number": 1,
        "head": {
          "ref": "master",
          "sha": "c68758fab137f751d56faa1ced119b7a3561e37e",
          "repo": {
            "id": 31792824,
            "url": "https://api.github.com/repos/flutter/flutter",
            "name": "flutter"
          }
        },
        "base": {
          "ref": "master",
          "sha": "f41becf53e4a339bd521d7ca56a2ef53bbed55ab",
          "repo": {
            "id": 218183782,
            "url": "https://api.github.com/repos/25ma/flutter",
            "name": "flutter"
          }
        }
      },
      {
        "url": "https://api.github.com/repos/HongZhiQing/flutter/pulls/1",
        "id": 415571600,
        "number": 1,
        "head": {
          "ref": "master",
          "sha": "c68758fab137f751d56faa1ced119b7a3561e37e",
          "repo": {
            "id": 31792824,
            "url": "https://api.github.com/repos/flutter/flutter",
            "name": "flutter"
          }
        },
        "base": {
          "ref": "master",
          "sha": "812885c179072a5d3a221c6f0e290ad60d631ad0",
          "repo": {
            "id": 255233784,
            "url": "https://api.github.com/repos/HongZhiQing/flutter",
            "name": "flutter"
          }
        }
      },
      {
        "url": "https://api.github.com/repos/oofimaconsumer/flutter/pulls/3",
        "id": 403605115,
        "number": 3,
        "head": {
          "ref": "master",
          "sha": "c68758fab137f751d56faa1ced119b7a3561e37e",
          "repo": {
            "id": 31792824,
            "url": "https://api.github.com/repos/flutter/flutter",
            "name": "flutter"
          }
        },
        "base": {
          "ref": "master",
          "sha": "1ef35e11f23f7716f212d98f2cffb3cffb743e01",
          "repo": {
            "id": 246471956,
            "url": "https://api.github.com/repos/oofimaconsumer/flutter",
            "name": "flutter"
          }
        }
      },
      {
        "url": "https://api.github.com/repos/Vadaski/flutter/pulls/1",
        "id": 394526365,
        "number": 1,
        "head": {
          "ref": "master",
          "sha": "c68758fab137f751d56faa1ced119b7a3561e37e",
          "repo": {
            "id": 31792824,
            "url": "https://api.github.com/repos/flutter/flutter",
            "name": "flutter"
          }
        },
        "base": {
          "ref": "master",
          "sha": "d5a243fada31ed7712b3930d5e78762af2c5a36a",
          "repo": {
            "id": 224116277,
            "url": "https://api.github.com/repos/Vadaski/flutter",
            "name": "flutter"
          }
        }
      }
    ],
    "app": {
      "id": 3232,
      "slug": "cirrus-ci",
      "node_id": "MDM6QXBwMzIzMg==",
      "owner": {
        "login": "cirruslabs",
        "id": 29414678,
        "node_id": "MDEyOk9yZ2FuaXphdGlvbjI5NDE0Njc4",
        "avatar_url": "https://avatars2.githubusercontent.com/u/29414678?v=4",
        "gravatar_id": "",
        "url": "https://api.github.com/users/cirruslabs",
        "html_url": "https://github.com/cirruslabs",
        "followers_url": "https://api.github.com/users/cirruslabs/followers",
        "following_url": "https://api.github.com/users/cirruslabs/following{/other_user}",
        "gists_url": "https://api.github.com/users/cirruslabs/gists{/gist_id}",
        "starred_url": "https://api.github.com/users/cirruslabs/starred{/owner}{/repo}",
        "subscriptions_url": "https://api.github.com/users/cirruslabs/subscriptions",
        "organizations_url": "https://api.github.com/users/cirruslabs/orgs",
        "repos_url": "https://api.github.com/users/cirruslabs/repos",
        "events_url": "https://api.github.com/users/cirruslabs/events{/privacy}",
        "received_events_url": "https://api.github.com/users/cirruslabs/received_events",
        "type": "Organization",
        "site_admin": false
      },
      "name": "Cirrus CI",
      "description": "Cirrus CI makes your development cycle fast, efficient, and secure by leveraging modern cloud technologies. Cirrus CI scales with your team and makes shipping software faster and cheaper.",
      "external_url": "https://cirrus-ci.com",
      "html_url": "https://github.com/apps/cirrus-ci",
      "created_at": "2017-06-21T15:35:40Z",
      "updated_at": "2018-08-27T11:48:50Z",
      "permissions": {
        "checks": "write",
        "contents": "read",
        "content_references": "write",
        "members": "read",
        "metadata": "read",
        "pull_requests": "read",
        "single_file": "read",
        "statuses": "write"
      },
      "events": [
        "check_suite",
        "content_reference",
        "create",
        "delete",
        "public",
        "pull_request",
        "push",
        "release",
        "repository"
      ]
    },
    "created_at": "2020-06-25T16:18:23Z",
    "updated_at": "2020-06-25T16:18:23Z",
    "latest_check_runs_count": 0,
    "check_runs_url": "https://api.github.com/repos/flutter/flutter/check-suites/841735204/check-runs",
    "head_commit": {
      "id": "5d2c8694bcc0e1942ef0e4876c8a106e1b537adf",
      "tree_id": "dd015cafeae7e203842876cb3b9ac089718defdd",
      "message": "Roll Engine from 0c141262115f to 73ff2bdd36ab (3 revisions) (#60254)",
      "timestamp": "2020-06-25T16:18:02Z",
      "author": {
        "name": "engine-flutter-autoroll",
        "email"<EMAIL_ADDRESS>      },
      "committer": {
        "name": "GitHub",
        "email"<EMAIL_ADDRESS>      }
    }
  },
  "repository": {
    "id": 31792824,
    "node_id": "MDEwOlJlcG9zaXRvcnkzMTc5MjgyNA==",
    "name": "flutter",
    "full_name": "flutter/flutter",
    "private": false,
    "owner": {
      "login": "flutter",
      "id": 14101776,
      "node_id": "MDEyOk9yZ2FuaXphdGlvbjE0MTAxNzc2",
      "avatar_url": "https://avatars3.githubusercontent.com/u/14101776?v=4",
      "gravatar_id": "",
      "url": "https://api.github.com/users/flutter",
      "html_url": "https://github.com/flutter",
      "followers_url": "https://api.github.com/users/flutter/followers",
      "following_url": "https://api.github.com/users/flutter/following{/other_user}",
      "gists_url": "https://api.github.com/users/flutter/gists{/gist_id}",
      "starred_url": "https://api.github.com/users/flutter/starred{/owner}{/repo}",
      "subscriptions_url": "https://api.github.com/users/flutter/subscriptions",
      "organizations_url": "https://api.github.com/users/flutter/orgs",
      "repos_url": "https://api.github.com/users/flutter/repos",
      "events_url": "https://api.github.com/users/flutter/events{/privacy}",
      "received_events_url": "https://api.github.com/users/flutter/received_events",
      "type": "Organization",
      "site_admin": false
    },
    "html_url": "https://github.com/flutter/flutter",
    "description": "Flutter makes it easy and fast to build beautiful apps for mobile and beyond.",
    "fork": false,
    "url": "https://api.github.com/repos/flutter/flutter",
    "forks_url": "https://api.github.com/repos/flutter/flutter/forks",
    "keys_url": "https://api.github.com/repos/flutter/flutter/keys{/key_id}",
    "collaborators_url": "https://api.github.com/repos/flutter/flutter/collaborators{/collaborator}",
    "teams_url": "https://api.github.com/repos/flutter/flutter/teams",
    "hooks_url": "https://api.github.com/repos/flutter/flutter/hooks",
    "issue_events_url": "https://api.github.com/repos/flutter/flutter/issues/events{/number}",
    "events_url": "https://api.github.com/repos/flutter/flutter/events",
    "assignees_url": "https://api.github.com/repos/flutter/flutter/assignees{/user}",
    "branches_url": "https://api.github.com/repos/flutter/flutter/branches{/branch}",
    "tags_url": "https://api.github.com/repos/flutter/flutter/tags",
    "blobs_url": "https://api.github.com/repos/flutter/flutter/git/blobs{/sha}",
    "git_tags_url": "https://api.github.com/repos/flutter/flutter/git/tags{/sha}",
    "git_refs_url": "https://api.github.com/repos/flutter/flutter/git/refs{/sha}",
    "trees_url": "https://api.github.com/repos/flutter/flutter/git/trees{/sha}",
    "statuses_url": "https://api.github.com/repos/flutter/flutter/statuses/{sha}",
    "languages_url": "https://api.github.com/repos/flutter/flutter/languages",
    "stargazers_url": "https://api.github.com/repos/flutter/flutter/stargazers",
    "contributors_url": "https://api.github.com/repos/flutter/flutter/contributors",
    "subscribers_url": "https://api.github.com/repos/flutter/flutter/subscribers",
    "subscription_url": "https://api.github.com/repos/flutter/flutter/subscription",
    "commits_url": "https://api.github.com/repos/flutter/flutter/commits{/sha}",
    "git_commits_url": "https://api.github.com/repos/flutter/flutter/git/commits{/sha}",
    "comments_url": "https://api.github.com/repos/flutter/flutter/comments{/number}",
    "issue_comment_url": "https://api.github.com/repos/flutter/flutter/issues/comments{/number}",
    "contents_url": "https://api.github.com/repos/flutter/flutter/contents/{+path}",
    "compare_url": "https://api.github.com/repos/flutter/flutter/compare/{base}...{head}",
    "merges_url": "https://api.github.com/repos/flutter/flutter/merges",
    "archive_url": "https://api.github.com/repos/flutter/flutter/{archive_format}{/ref}",
    "downloads_url": "https://api.github.com/repos/flutter/flutter/downloads",
    "issues_url": "https://api.github.com/repos/flutter/flutter/issues{/number}",
    "pulls_url": "https://api.github.com/repos/flutter/flutter/pulls{/number}",
    "milestones_url": "https://api.github.com/repos/flutter/flutter/milestones{/number}",
    "notifications_url": "https://api.github.com/repos/flutter/flutter/notifications{?since,all,participating}",
    "labels_url": "https://api.github.com/repos/flutter/flutter/labels{/name}",
    "releases_url": "https://api.github.com/repos/flutter/flutter/releases{/id}",
    "deployments_url": "https://api.github.com/repos/flutter/flutter/deployments",
    "created_at": "2015-03-06T22:54:58Z",
    "updated_at": "2020-06-25T16:17:22Z",
    "pushed_at": "2020-06-25T16:18:03Z",
    "git_url": "git://github.com/flutter/flutter.git",
    "ssh_url": "git@github.com:flutter/flutter.git",
    "clone_url": "https://github.com/flutter/flutter.git",
    "svn_url": "https://github.com/flutter/flutter",
    "homepage": "https://flutter.dev",
    "size": 106367,
    "stargazers_count": 94808,
    "watchers_count": 94808,
    "language": "Dart",
    "has_issues": true,
    "has_projects": true,
    "has_downloads": true,
    "has_wiki": true,
    "has_pages": false,
    "forks_count": 13045,
    "mirror_url": null,
    "archived": false,
    "disabled": false,
    "open_issues_count": 7891,
    "license": {
      "key": "bsd-3-clause",
      "name": "BSD 3-Clause \"New\" or \"Revised\" License",
      "spdx_id": "BSD-3-Clause",
      "url": "https://api.github.com/licenses/bsd-3-clause",
      "node_id": "MDc6TGljZW5zZTU="
    },
    "forks": 13045,
    "open_issues": 7891,
    "watchers": 94808,
    "default_branch": "master"
  },
  "organization": {
    "login": "flutter",
    "id": 14101776,
    "node_id": "MDEyOk9yZ2FuaXphdGlvbjE0MTAxNzc2",
    "url": "https://api.github.com/orgs/flutter",
    "repos_url": "https://api.github.com/orgs/flutter/repos",
    "events_url": "https://api.github.com/orgs/flutter/events",
    "hooks_url": "https://api.github.com/orgs/flutter/hooks",
    "issues_url": "https://api.github.com/orgs/flutter/issues",
    "members_url": "https://api.github.com/orgs/flutter/members{/member}",
    "public_members_url": "https://api.github.com/orgs/flutter/public_members{/member}",
    "avatar_url": "https://avatars3.githubusercontent.com/u/14101776?v=4",
    "description": ""
  },
  "enterprise": {
    "id": 1732,
    "slug": "alphabet",
    "name": "Alphabet",
    "node_id": "MDEwOkVudGVycHJpc2UxNzMy",
    "avatar_url": "https://avatars2.githubusercontent.com/b/1732?v=4",
    "description": "",
    "website_url": "https://abc.xyz/",
    "html_url": "https://github.com/enterprises/alphabet",
    "created_at": "2019-12-19T00:30:52Z",
    "updated_at": "2019-12-19T21:05:17Z"
  },
  "sender": {
    "login": "fluttergithubbot",
    "id": 52682268,
    "node_id": "MDQ6VXNlcjUyNjgyMjY4",
    "avatar_url": "https://avatars2.githubusercontent.com/u/52682268?v=4",
    "gravatar_id": "",
    "url": "https://api.github.com/users/fluttergithubbot",
    "html_url": "https://github.com/fluttergithubbot",
    "followers_url": "https://api.github.com/users/fluttergithubbot/followers",
    "following_url": "https://api.github.com/users/fluttergithubbot/following{/other_user}",
    "gists_url": "https://api.github.com/users/fluttergithubbot/gists{/gist_id}",
    "starred_url": "https://api.github.com/users/fluttergithubbot/starred{/owner}{/repo}",
    "subscriptions_url": "https://api.github.com/users/fluttergithubbot/subscriptions",
    "organizations_url": "https://api.github.com/users/fluttergithubbot/orgs",
    "repos_url": "https://api.github.com/users/fluttergithubbot/repos",
    "events_url": "https://api.github.com/users/fluttergithubbot/events{/privacy}",
    "received_events_url": "https://api.github.com/users/fluttergithubbot/received_events",
    "type": "User",
    "site_admin": false
  },
  "installation": {
    "id": 104037,
    "node_id": "MDIzOkludGVncmF0aW9uSW5zdGFsbGF0aW9uMTA0MDM3"
  }
}
```

As you can see pull_requests field doesn't make sense. It refers this weird PR #60287. From the Cirrus perspective this looked like a PR created from master to dev. 😳

I'm not sure how to read that webhook. Is that a batch request corresponding to multiple PRs? I can see that PR #60287 had the same revision at the tip, 5d2c8694bcc0e1942ef0e4876c8a106e1b537adf. I'm not sure how that webhook lead to triggering this build that looks like a post-submit run https://cirrus-ci.com/task/5637314439282688. Is the webhook malformed or is the parsing of it ambiguous?

Yes, IMO the webhook is malformed. Since you mentioned this conditioned worked for a long time I think we can ignore it for now. If that'll re-occurs we'll need to involve GH support.

Yes, IMO the webhook is malformed. Since you mentioned this conditioned worked for a long time I think we can ignore it for now. If that'll re-occurs we'll need to involve GH support.

SGTM. Thanks for investigating!

Per discussion above, I will close this issue. If it happens again follow-up with GitHub support will be necessary.


[FORMATTING] problem with line like 'ORDER BY t1.DATE DESC, t1.[%title%] ASC'

ORDER BY t1.DATE DESC, t1.[%title%] ASC
Unable to format SQL:
Error: Parse error: Unexpected "[%album ar" at line 5 column 18

Please provide more details, like:

Which SQL dialect are you using?
What is this [%title%] syntax? I haven't seen such a thing before. Is it some sort of templating?

In case this is templating syntax, please see the FAQ

I use foobar2000 + sql

So, you're using SQLite. But according to my knowledge this [%title%] thingie is not part of SQLite syntax.
I'm sure it's some sort of templating syntax. Please see the above FAQ link on how to deal with templating syntax.
PS. I have no idea if or how this foobar2000 intergates with SQL formatter.

the one is part of foobar2000  and foo_uie_sql_tree

This does not clarify things for me. Perhaps you should search for help from developers of this foobar2000.

I use VS code for SQL, but your program (extension) give to me the
Error: Parse error: Unexpected "[%album ar" at line 5 column 18
I think you might solve it.
e.g.
npp + plugin good working with this code

Aha... I realize now that SQLite actually also supports these [...] style quotes. However, so does SQL Formatter.
Looks like you haven't specified SQLite as the dialect that you're formatting.
Again. Please read the FAQ.


Testing RC versions of pandas in conda

I got this ANN email from the PyData mailing list from @jreback:

I'm pleased to announce the availability of the second release candidate of Pandas 0.17.0.
...
Best way to get this is to install via conda from our development channel. Builds for osx-64,linux-64,win-64 for Python 2.7, Python 3.4, and Python 3.5 (for osx/linux) are all available.

conda install pandas -c pandas

which is awesome! I can't wait for the new version to be out. I'd love to help with debugging, but when I tried to install the RC, I still got 0.16.2 in Python 3.5. See below:
$ conda install pandas -c pandas
Fetching package metadata: ........
Solving package specifications: ............
Package plan for installation in environment /Users/avazquez/anaconda3/envs/py35:

The following NEW packages will be INSTALLED:

    pandas: 0.16.2-np19py35_0

Proceed ([y]/n)? y

Linking packages ...
[ COMPLETE]

Same thing if I uninstall pandas first and then try conda install pandas -c pandas again. Any thoughts on what could be wrong?

What platform are you on, and I'm assuming python 3.5? We may not have a 3.5 build for your platform.
You can see the platforms / pytohns here: https://anaconda.org/pandas/pandas/files

Oh thanks. I'm on Python 3.5 in OS X 64 (El Capitan).

Hmm, that's interesting, based on that link, this version is available: osx-64/pandas-v0.17.0rc2-py35_0.tar.bz2.

I ran into this, for whatever reason it thinks the new rc is a lower version.    A workaround is
conda install -c pandas pandas=v0.17

Thanks @chris-b1 Yes, that worked.


fix_mesh tests and fix broken pymeshfix interface

This adds a simple test for fix_mesh as well as a cube fixture and some infrastructure to make fixture scopes more general with a context manager.
Important note here -- there was a breaking change in pymeshfix where (as the commit explains) the cython methods moved to a pep8 format and away from PascalCase.  I can make it more backward-compatible if this is a pain.

Codecov Report

Merging #13 into most_tests will increase coverage by 0.66%.
The diff coverage is 25%.

@@              Coverage Diff               @@
##           most_tests      #13      +/-   ##
==============================================
+ Coverage       15.96%   16.62%   +0.66%
==============================================
  Files               8        8
  Lines            1209     1209
==============================================
+ Hits              193      201       +8
+ Misses           1016     1008       -8

Impacted Files
Coverage Δ

meshparty/trimesh_io.py
47.18% <25%> (+2.14%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update eb9507f...fc05cc1. Read the comment docs.

can you do a version inequality to cause this to come along with the version of pymeshfix that has this new syntax?

@fcollman with the version update the mesh tests are working, but it looks like there is a NameError in cloudvolume.  I'm not familiar with how cloudvolume-graphene has developed since this PR was submitted.

this was my fault.. i'm working on fixing this (on the graphene branch)

i think i fixed it all now. thanks russel

looking good


How to show the browser for crawl?

How to show the browser for crawl? It seems like the default is headless as I don't see a browser pops . The visible browser is helpful for js code building.

@takan1 You can use a browser extension like tampermonkey for js code building. Once you see that your js code is working as expected, then you can copy paste your JS code into your python script as shown here..  If you still think browser is needed to be displayed, could you please further explain the use case you are trying to code in JS?

@takan1 The crawler.run() has this parameter bypass_headless and if you set it to True you can have the browser too.
result = crawler.run( url, bypass_cache=True, bypass_headless = False)


Is there any way to easily drop down notification bar and dismiss notifications more easily than swiping with the mouse from one side to the other?

Now I swipe with mouse from top to down to open notification bar and swipe from left all the way to the right to dismiss a notification. Is there an easier way to do this with single clicks?
Thanks

install some apps on the device side that will do it for you. like, i've seen "Notification Shade" that acts as a regular app icon, but on clicked opens your shade. and also some android ROMs open shade when its double-clicked.

Thank you

There's shortcuts:
Expand notification panel   MOD+n
Collapse notification panel   MOD+Shift+n

Oh thank you


BUG Property 'recordings' does not exist on type 'ISearchResult'.

const rawPageTracks = await api.search('recording',{query:MYQUERY});
console.log(rawPageTracks.recordings);

gives me
Property 'recordings' does not exist on type 'ISearchResult'.
casting it to any works.
const rawPageTracks = await api.search('recording',{query:MYQUERY}) as any;

Resolved in release v0.14.0


grib-api: init at 1.14.4

Add the API for the grib file format.

Nice! Please squash commits into one.

@jagajaga I'm sorry but I have to admit that I don't know how to do this. Could you point me to the correct command to squash the commits?

@jagajaga I think this should now be squashed into one. I (hopefully correctly) used git rebase -i.

Nice! Thank you.


alias URL should be stable when visited

Visiting alice.room.com should not redirect to (i.e. change the browser's address bar) room.com/aliases/alice, it should stay on alice.room.com to allow copy-pasting it.

cc #117

I agree but shouldn't we expand this to generate the right URL scheme?
I'd really like to support the Tor hidden-service scheme where wildcard domains are not possible.

I agree with that, but isn't it a separate issue? (Or separate in the sense that it could be done later, and that there are different strategies how to support Tor hidden-service)

True, just related because you mentioned copy and paste and for me the first step is copying it from somewhere.
I just had a shower thought to fix the issue on nginx. Instead of URL rewrite, which by all accounts is not possible when changing the domain, we could have a 2nd proxy_pass just for the aliases.


Prist: Add Mind Flay for Vanilla Classic

Fixes: #40

As mentioned in the last comment in #40, this does not fix the issue. This fix was tested locally before the issue #40 was posted.

The fix is different from your last comment on #40

Thanks for pointing that out, it is indeed different. You added mind flay rank 6 rather than rank 1. I have now downloaded the update and tried this fix, unfortunately it still does not work. Is there any further info I can give that would be useful?


🍒 Cherry pick PR #8993 to staging 🍒

🍒 Cherry pick https://github.com/Expensify/App/pull/8993 to staging 🍒

🚀 Cherry-picked to staging by @chiragsalian in version: 1.1.60-1 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

@Expensify/applauseleads please QA this PR and check it off on the deploy checklist if it passes.

🚀 Deployed to production by @AndrewGable in version: 1.1.60-3 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅


add docker support

#49

 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.:x: piotrzarycki sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.


Remove delay support in dependencies

Summary
As we can't guarantee this delay, we are removing it to avoid confusion.
Test Plan
CI.
Additional Notes
—

LGTM. Please create a PR in CloudAIX as well, as the TOML files in CloudAIX may include the delay field.


Cf nginx letsencrypt

This is a working solution of using nginx for reverse proxy/load balancing, Lets Encrypt certificate, and ColdFusion app server.

Sorry about this Mr Carehart! I thought i was merging into my own fork of awesome-cf-compose

Oh, no worries. Am I right to assume you WOULD want to have me pull it into the repo? I saw it just before going to bed and was going to test it today. It does seem it would be a very useful example to add. And please call me Charlie. :-) /CharlieSent from my mobile device. Please pardon typos.
-------- Original message --------From: Joseph @.> Date: 11/18/22  10:47 PM  (GMT-06:00) To: carehart/awesome-cf-compose @.> Cc: Subscribed @.***> Subject: Re: [carehart/awesome-cf-compose] Cf nginx letsencrypt (PR #3)
Sorry about this Mr Carehart! I thought i was merging into my own fork of awesome-cf-compose
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

Hello Charlie, I am Joseph.
Eventually, I WOULD like to pull it into your repo, but I don't feel it's fleshed out appropriately yet. I need to update some of the configs and make the readme.md more clear. I'm going to close this pull request and clean things up a bit before creating a new one. :)

Ok, sir. :-) That said, I have myself skipped on the readme, as it's indeed more work sometimes than creating the other files. :-) Since some are rather self-explanatory, I've figured "better to get the demos in, even without the readme, to benefit those who can use it without the readme". Of course, I do PLAN to finish the readme's that are missing. :-)


Adds docker compose for configured ilias

Awesome repo Kevin :) Helped me a lot for my client lib.
This PR add the following:

adds docker-compose outline for the ilias-configured version with a MySQL running in another container
stores the data of the database in the folder ./.data/db
ensures the external db is up before the ilias-server initialized the db with the wait.sh script
updates README

@kekru I fixed all your concerns :) thx for the feedback

@mavogel Looks very good :)
Can we also delete DockerfileExtDB and add the new lines to the old Dockerfile?
COPY ./wait.sh /usr/local/bin/
RUN chmod +x /usr/local/bin/wait.sh

Then we only have one Dockerfile that we have to keep up to date in the future.
Can you move the wait.sh to the resources directory https://github.com/kekru/ilias-docker/tree/master/dockerfiles/ilias-configured/resources? That looks more clean, I think :)

done :)

Looks very good, thank you :)


Few-shot demo

Hi,
I see that your demo.py uses the open-vocabulary models by default.
How can I adapt the demo to use a few-shot (eg: 10) approach to test my images without using any label names in the model?

Hi @SuryaThiru.  Actually this model always uses a few-shot pipeline, as I explained here #13. Hope it helps.


[Feature] Global Aliases

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
[x] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Is your feature request related to a problem? Please describe.
Feature request is not related to a "problem"
Describe the solution you like
I would like to see the firewall aliases available in other sections of the opnsense firewall, or more likely, a global alias system that could be used in multiple services. For example a global alias for an internal IP that could be used in unbound, DHCP, and the firewall section. This benefits user who may run virtual workloads that often change their IP (think VIP based loadbalancers) if the VIP of a loadbalancer changes there are multiple locations in opnsense where this may need to change. I see this global alias being mostly useful in DNS, Firewall and DHCP functions.
Describe alternatives you considered
I do not believe there are any.
Additional context
Below I pasted some pictures of some sample alias uses.
Unbound:

DHCP:

Looked at this from various angles in the past, but the service in question has no way of knowing anything underneath has changed and has no way of coping with the flexibility the alias system has to offer. In practice this would mean any update to the alias system has the possible effect of restarting of all consumers of these aliases  (which causes unexpected service interruption) .

Not to mention the heavy restrictions that each user of the alias would impose on the alias being used (lower number of entries, stricter format, etc).

I just now configured VPN->IPsec->Connection->Pools and came exactly across that idea.
One Pool for IPv6, one for IPv4, selecting two pools in the connection...
And "Local Nets" like that is not maintainable: I have over 8 lines of tool tip full of IP networks garbage when hoovering with the mouse over it - when it is just three entries in the "Alias"...
The Alias system regarding networks/hosts is great - you should make it available in the other networking sections to get rid of those possible errors when maintaining IP networks/adresses over the various services.
If the services allows a reload instead a restart, just reload when the Alias changes.
Services with only restart -> no alias funktionality.
Start with IPsec please and move then on to OpenVPN!

Related: https://github.com/opnsense/core/issues/7464

i feel like having a standard display of what services support aliases would be a good idea

services that work well with the concept like ones that can reload with no downtime, would say something like 'fully supported'.

services that require restarts to use aliases could have an explicit checkbox saying the service can be restarted for alias changes, and a warning to the user asking if they really want to enable aliases, and say 'partially supported, downtime on alias update'.

i feel like allowing the user to choose if they're ok with downtime might be the only solution to this issue that covers most cases.

In most cases you can bind the service to a loopback address and use a rdr (port forward) to offer the flexibility, which is a best practice anyway. Bindings (such as static dhcp addresses and dns hosts) are different, but also cause less duplication when properly used.


Dependency Types

Proposal:

Use OpenTelemetry specs to make it possible to determine some of the dependency types that ApplicationInsights accept.
Be able to force a dependency type to include the ones that are out of OpenTelemetry specs.

I tried to add a label to the issue, but I don't seem to be able to.

@victoraugustolls
Are you referring to putting the telemetry types of Application Insights (MetricData, RemoteDependencyData, etc) into OpenTelemetry specs?

Sorry for the delay @lzchen! I meant using the specs listed here and here so we can make the right dependency type appear in the Application Map and etc...

component attribute should be used for it.
There is also a special proposal for Azure SDKs to stamp their type in az.namespace attribute as component is not good enough gor Azure Monitor UX (describles only protocol, but not the service it calls). But this proposal is not yet implemented. I'll keep you posted

Hi!
Do we have any news of this proposal @lmolkova ?
Thanks in advance!

@victoraugustolls
I don't believe component attribute is being used/implemented across all languages/instrumentations.
Currently, Azure exporters will be using their own mechanism to detect dependency type. Issue here: https://github.com/microsoft/opentelemetry-azure-monitor-python/issues/128

Thanks for the info @lzchen ! I think this can be closed and tracked in #128!


Suppress MSVC warning that is not applicable

This triggers a warning in downstream libraries such as:
https://build.osrfoundation.org/job/ign_gazebo-pr-win/5195/msbuild/
'gz::physics::detail::ComposePlugin::type': base-class 'gz::physics::detail::ComposePlugin::n,void>' is already a base-class of 'gz::physics::detail::ComposePlugin::type'

After talking with @mxgrey, while this is typically a relevant warning by MSVC, it is not applicable so we can suppress it.
Signed-off-by: Michael Carroll<EMAIL_ADDRESS>

This fix can also be applied to ign-physics5 to fix warnings in ign-gazebo6 to partially resolve https://github.com/gazebosim/gz-sim/issues/2384
@Mergifyio backport ign-physics5

@Mergifyio backport ign-physics5


About the derivation of the L_{sude} in the paper "FaceChain-SuDe"

I would like to extend my gratitude to the authors of the paper and the maintainers of this project for your exceptional work.
I have been reading the paper titled "FaceChain-SuDe: Building Derived Class to Inherit Category Attributes for One-shot Subject-Driven Generation" and came across a point of concern regarding the derivation of Equation (7), which addresses L_{sude}. Specifically, while Equation (6) indicates that $p(x_{t-1} | x_t, c)$ follows a normal distribution, this does not necessarily imply that it is proportional to $e^{-\frac{|| x_{t-1}-x_{\theta}(x_t, c, t) ||^2}{2\sigma_t^2}}$.
The $e^{-\frac{|| x_{t-1}-x_{\theta}(x_t, c, t) ||^2}{2\sigma_t^2}}$ represents the probability density function, but this does not mean that $log[p(x_{t-1} | x_t, c)]$ is directly proportional to $|| x_{t-1}-x_{\theta}(x_t, c, t) ||^2$, which in turn seems to make the derivation of Equation (7) untenable. Instead, we only have $log \nabla p(x_{t-1} | x_t, c)$ proportional to $|| x_{t-1}-x_{\theta}(x_t, c, t) ||^2$.
If there is any point where I may have misunderstood, I would appreciate any clarification.

The deductions come from the denoising process in DDPM that uses $p(x_{t-1} | x_t , x_0 )$ to estimate $p(x_{t-1} | x_t )$. As such, the $\sigma_t$ only depends on the noise timesteps, and keeps same in the numerator and denominator in Equation (5). Therefore, the same constant terms in the log(p) of the numerator and denominator are omitted in Equation (7).

Thanks for @You-Cun 's response, here I additionally add some information.
On a Gaussian distribution, the probability of a single point is defined as $0$. Hence, we should view $p(x_{t-1}|x_{t}, c)$ as the probability on a neighborhood around a specific $x_{t-1}$. Since this neighborhood tends infinitely towards 0, we can approximately view the probability on it as a constant value, that is, the $exp(\frac{-||x_{t-1} - x_{\theta}(x_{t},c,t)||^{2}}{2\sigma_{t}^{2}})$. This trick was also used in Diffusion Models Beat GANs on Image Synthesis.
Here we get the Eq. 6 and with @You-Cun 's response, we can view the variance $\sigma_{t}$ as a constant, therefore we can obtain Eq. 7.

Thanks to You-Cun and qpc1611094 for your responses. I seem to have misunderstood $p(x_{t−1} | x_t, c)$. It should be a PDF, not a CDF.


metal*drawing layers should be used for routing

Per https://github.com/gdsfactory/gdsfactory/issues/681#issuecomment-1367607941, met*drawing should be used for routing: https://github.com/gdsfactory/skywater130/blob/f537582f5fe4b6bf96ed6fad4d40ee3ee418740f/sky130/layers.py#L216 instead of the :0 type which are reserved for production mask.

fixed by https://github.com/gdsfactory/skywater130/pull/52

fixed by https://github.com/gdsfactory/skywater130/pull/52


Add an "md scan" command to kbfstool

For now, it just checks for dangling blocks.
This is for diagnosing problems where blocks
are erroneously removed by e.g. conflict
resolution.

Note that this is based on top of #258, but can be reviewed independently.

Looks good to me.  Though did you know about libkbfs.StateChecker.findAllBlocksInPath?  Not a requirement, but it seems like this duplicates much of that functionality, so it might be worth seeing if we can refactor a bit to have them share code.  But the state checker is also building up block sizes, so it's not quite a perfect fit.

I left a TODO to decomp common code with libkbfs.StateChecker.findAllBlocksInPath.


Learn Dagger Tutorial

Suggestion from @marcosnils :

"Learn Dagger" tutorial with the option to log-in using Github a-la nextjs learn (https://nextjs.org/learn/foundations/about-nextjs). The good thing about doing this is that if the user decides to log-in using Github, we might design the flow in a way that by using the SSO credentials we could create a repository and setup the GHA flow automatically ourselves. In that flow, the "dagger" setup will be super smooth

closing in favor of #4291


[SPARK-45145][EXAMPLE] Add JavaSparkSQLCli example

What changes were proposed in this pull request?
This PR aims to add a simple Java example, JavaSparkSQLCli.java. Like SparkPi example, we can take advantage of this minimal example with bin/run-example and we can run a simple SQL query as a canary test during RC testing and voting phase.

https://spark.apache.org/docs/3.5.0/

./bin/run-example SparkPi 10

After this PR,
$ bin/run-example sql.JavaSparkSQLCli "SELECT 'Spark SQL' col"
+---------+
|col      |
+---------+
|Spark SQL|
+---------+

Why are the changes needed?
Although there exists org.apache.spark.sql.hive.thriftserver.SparkSQLCLIDriver and bin/spark-sql shell environment, it requires -Phive -Phive-thriftserver explicitly.
$ bin/spark-shell --version
Welcome to
      ____              __
     / __/__  ___ _____/ /__
    _\ \/ _ \/ _ `/ __/  '_/
   /___/ .__/\_,_/_/ /_/\_\   version 3.5.0
      /_/
...

$ bin/run-example org.apache.spark.sql.hive.thriftserver.SparkSQLCLIDriver
...
Error: Failed to load class org.apache.spark.examples.org.apache.spark.sql.hive.thriftserver.SparkSQLCLIDriver.
Failed to load main class org.apache.spark.examples.org.apache.spark.sql.hive.thriftserver.SparkSQLCLIDriver.
You need to build Spark with -Phive and -Phive-thriftserver.
23/09/12 23:06:38 INFO ShutdownHookManager: Shutdown hook called
23/09/12 23:06:38 INFO ShutdownHookManager: Deleting directory /private/var/folders/d4/dr6zxyvd4cl38877bj3fxs_m0000gn/T/spark-2a9ee4a3-64c3-492c-a268-a71b9aa44a2a

Does this PR introduce any user-facing change?
No.
How was this patch tested?
Manually.
$ build/sbt test:package
$ bin/run-example sql.JavaSparkSQLCli "SELECT 'Spark SQL' col"

Was this patch authored or co-authored using generative AI tooling?
No.

Hi, @HyukjinKwon . Do you think we can have this additional example?

Thank you, @HyukjinKwon and @yaooqinn .

Merged to master for Apache Spark 4.0.


config.NoMetadata undefined

Hello,
I have tried to install qor-example, but I ended up with an error that I can't figure out.
My Go Version
go version
go version go1.13.4 linux/amd64

I have run the following command:
go get -u github.com/qor/qor-example

And, I got the following result:
# github.com/qor/qor-example/config/bindatafs
../../.asdf/installs/golang/1.13.4/packages/pkg/mod/github.com/qor/qor-example@v0.0.0-20190603070932-debf77110d7a/config/bindatafs/bindatafs.go:118:8: config.NoMetadata undefined (type *bindata.Config has no field or method NoMetadata)

Can anyone help me solving this please?

//config.NoMetadata = true