drivers/serial: Always support c_oflag, c_iflag and c_lflag in termios

Summary
CONFIG_SERIAL_TERMIOS only decide whether to support c_cflag field since many terminal application need the first three fields to work correctly. For more information please reference:
<EMAIL_ADDRESS>before this change(olimexino-stm32:tiny):
   text    data     bss     dec     hex filename
  34884     328    1768   36980    9074 nuttx

after this change:
   text    data     bss     dec     hex filename
  35052     340    1768   37160    9128 nuttx

delta
   text    data     bss     dec     hex filename
    168      12       0     180      b4 nuttx

Impact
Terminal special process expected by application always exist
Testing
sim:adb

Some of text in drivers/serial/Kconfig needs to be updated. It probably should state when is enabled and what is not. tcsetattr, for example, no longer depends on CONFIG_SERIAL_TERMIOS.

Done.

I will go ahead and merge this now.  Alan and Petro and much later in the day than I.  Guys please do review we can always fix anything I missed.

Does this depend on https://github.com/apache/nuttx-apps/pull/1668 ?  That PR has some CI failures, probably because it depends on this PR.  I will restart CI.


Improvement for HTML compressor: line breaks per 500 characters

Hi!
I wanted to suggest a small improvement for the HTML compressor (https://github.com/mrclay/minify/blob/2.x/min/lib/Minify/HTML.php). Currently it breaks for every tag, creating a long HTML source code that is not easy to read.or debug.
Google Closure Compiler uses a line length of 500.

The Closure Compiler intentionally adds line breaks every 500 characters or so. Firewalls and proxies sometimes corrupt or ignore large JavaScript files with very long lines. Adding line breaks every 500 characters prevents this problem.
https://developers.google.com/closure/compiler/faq#linefeeds

The following regex addition would break tags around 500 characters.
Current:
php $HTML = preg_replace('/(<[a-z\\-]+)\\s+([^>]+>)/is', "$1\n$2", $HTML);
Improved:
php $HTML = preg_replace('/(.{1,500}<[a-z\\-]+)\\s+([^>]+>)/is', "$1\n$2", $HTML);
Best Regards,
Jan Jaap
<EMAIL_ADDRESS>

Can you send a pull request with passing tests?

Please send a PR if you want this feature.


🎉 Add

🪩 Provide a link to the proposed addition
github
😳 Explain why it should be added
A GUI client for macOS, support mihomo core
📖 Additional context
No response
🧨 Issue Checklist

[X] I have checked for other similar issues
[X] I have explained why this change is important
[X] I have added necessary documentation (if appropriate)

？


Clarity project not reporting model size

Projects in Revit Server that require authentication (i.e. Clarity projects) fail to pull a model size. There should be an option to include a Clarity access token on REST calls to Revit Server projects hosting there to successfully pull correct model size info.

Working on this in features/clarity-modelsize-fix

Confirmed that this is working on Mission Control production with live projects


Errors 202, 206 and 209 triggered inside raw blocks {% raw %}/{% endraw %}

Describe the bug
While implementing CI using salt-lint on a Salt repo, I stumbled upon the following behavior, where errors were reported even inside raw blocks delimited by {% raw %}/{% endraw %}.
To Reproduce
cat > test.sls <<EOF
environments:
  variables:
    heketi:
      {% raw %}
      HEKETI_CLI_SERVER: \$(kubectl --kubeconfig=/etc/kubernetes/admin.conf get svc/heketi -n glusterfs --template "http://{{.spec.clusterIP}}:{{(index .spec.ports 0).port}}" 2>/dev/null || echo 'Go root!')
      {% endraw %}
EOF
docker run --rm -v "$PWD":/data:ro -it warpnetbv/salt-lint:0.4.2 -x 204 test.sls

Result
[206] Jinja variables should have spaces before and after: {{ var_name }}
test.sls:5
      HEKETI_CLI_SERVER: $(kubectl --kubeconfig=/etc/kubernetes/admin.conf get svc/heketi -n glusterfs --template "http://{{.spec.clusterIP}}:{{(index .spec.ports 0).port}}" 2>/dev/null || echo 'Go root!')

Expected behavior
Errors shouldn't be reported inside raw elements, or at least the ones about Jinja formatting (202, 206 and 209) should be ignored. Inside a raw block, we are not evaluating Jinja markup, so we don't care if some {{ is not properly spaced (in fact, the raw block is meant to prevent errors during Jinja rendering by Salt as it would be interpreted as an undefined variable).
Desktop:

OS: Debian 9 amd64
Version 0.4.2

Thanks @Lomanic for your bug report! I've just confirmed this is indeed an issue.
One possible solution would be to filter all Jinja escaping using a regex similar to: (\{%\sraw\s%\}(?:\n?.*?)+\{%\sendraw\s%\}).

Thanks for taking time to fix that @roaldnefs :+1:

Thanks for taking time to fix that @roaldnefs :+1:

I'm happy to help, @Lomanic!

I'm happy to help, @Lomanic!


TableView column does not respect minWidth

🐛 Bug Report

When a width is set on a Column in a V3 TableView, it seems to be the only thing considered when defining the width of that column, even if there is a minWidth also on that column. See the sandbox below:
https://codesandbox.io/s/react-spectrum-template-forked-cxfw8b?file=/src/App.js
🤔 Expected Behavior

The width of an element should be the greater of its calculated width, or the minWidth.
😯 Current Behavior

          <Column
            showDivider={true}
            minWidth={500}
            width={50}
          >

We would expect the column's width to be 500, but it is 50.

💁 Possible Solution

🔦 Context

I would like to make a table where column A and B are the same size, column C is half that size, and column D is at least 40px wide and otherwise half the size of C.

💻 Code Sample

https://codesandbox.io/s/react-spectrum-template-forked-cxfw8b?file=/src/App.js
🌍 Your Environment

Software
Version(s)

react-spectrum
3.20.0

Browser
Chrome

Operating System
OS X 12.4

🧢 Your Company/Team

Adobe/AEP
🕷 Tracking Issue (optional)

From discussion, should our width/min-width behave like CSS width/min-width


Allow mapping payload username field to actual

I have a custom User model where USERNAME_FIELD = 'email' however I'd like to be able to submit login credentials as:
{
  username<EMAIL_ADDRESS>  password: 'mypassword'
}

Not
{
  email<EMAIL_ADDRESS>  password: 'mypassword'
}

I'm wanting to make the request compliant with OAuth2 Access Token Request.
Currently this is not possible as JSONWebTokenSerializer creates it's username field by inspecting UserModel.USERNAME_FIELD. Having a setting for mapping payload username to model username would be useful.

Same problem :(


Allow trackLink and trackForm to accept options.

Adds a fourth, optional argument to trackLink and trackForm called options that is passed directly through to #track.
The use case for me is being able to specify integrations, e.g.
analytics.trackLink(document.querySelectorAll("a"), 'Click!', {}, {
  integrations: {
    'All': false,
    'Google Analytics': true
  }
});

Addresses #403.

Poking this thread.  Any feedback?


[feat] (AppImage) Offline Build

Describe the problem
Building AppImage in a controlled environment (Offline) controlled.
From a security perspective, the CI has no direct internet connection and must get all dependencies from our cached repositories (npm, cargo, etc.).
We face an issue now with building AppImage since it tries to get some scripts from GitHub.
We would like to build AppImage without the need to depend on remote scripts in Github.
Describe the solution you'd like
Securely build AppImage and I do not depend on scripts from GitHub
Alternatives considered
No response
Additional context
No response

I doubt we can inline everything in the bundler considering how big linuxdeploy is for just one platform.
I'll of course leave this issue open because i think we can still improve the current situation.
As a workaround for now it should work if you just copy the required files into ~/.cache/tauri before building your app.


[multistage] Adding Stage node support for CorrelateNode and UncollectNode

For unnest query support in v2:
SELECT a.col1, col22 FROM a CROSS JOIN UNNEST(a.col2) AS t(col22)

WIP:

[X]  Sql -> SqlNodeAndOption
[X]  SqlNodeAndOption -> StageNode (Query Plan)
[ ]  Plan execution

Codecov Report

Merging #10488 (4c76d45) into master (0e6c386) will decrease coverage by 56.31%.
The diff coverage is 0.00%.

@@              Coverage Diff              @@
##             master   #10488       +/-   ##
=============================================
- Coverage     70.26%   13.95%   -56.31%
+ Complexity     6113      237     -5876
=============================================
  Files          2070     2037       -33
  Lines        111951   109777     -2174
  Branches      17051    16775      -276
=============================================
- Hits          78658    15316    -63342
- Misses        27746    93211    +65465
+ Partials       5547     1250     -4297

Flag
Coverage Δ

integration1
?

integration2
?

unittests1
?

unittests2
13.95% <0.00%> (-0.04%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...java/org/apache/pinot/common/utils/DataSchema.java
0.00% <ø> (-79.42%)
:arrow_down:

...e/pinot/query/planner/ExplainPlanStageVisitor.java
0.00% <0.00%> (-83.55%)
:arrow_down:

...not/query/planner/logical/RelToStageConverter.java
0.00% <0.00%> (-93.75%)
:arrow_down:

...che/pinot/query/planner/logical/RexExpression.java
0.00% <0.00%> (-90.77%)
:arrow_down:

...t/query/planner/logical/ShuffleRewriteVisitor.java
0.00% <0.00%> (ø)

...ot/query/planner/logical/StageMetadataVisitor.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...hysical/colocated/GreedyShuffleRewriteVisitor.java
0.00% <0.00%> (ø)

...pache/pinot/query/planner/stage/CorrelateNode.java
0.00% <0.00%> (ø)

...lanner/stage/DefaultPostOrderTraversalVisitor.java
0.00% <0.00%> (ø)

...pache/pinot/query/planner/stage/UncollectNode.java
0.00% <0.00%> (ø)

... and 3 more

... and 1625 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

@xiangfu0 Would CROSS JOIN UNNEST between correlated LHS and RHS (UNNEST basically operates on a field that belongs to left join relation) results only in the cross product of the current row of the left table with all the rows from the UNNEST output?

@xiangfu0 Would CROSS JOIN UNNEST between correlated LHS and RHS (UNNEST basically operates on a field that belongs to left join relation) results only in the cross product of the current row of the left table with all the rows from the UNNEST output?

that's the definition when doing
... FROM tbl CROSS JOIN UNNEST(tbl.arrCol)

see LATERAL & UNNEST in https://www.postgresql.org/docs/current/queries-table-expressions.html

this PR can be closed if we have #10685 yes?

I think UncollectNode is still need, CorrelateNode is not needed.
I will rebase once #10685 is merged.

this PR can be closed if we have #10685 yes?

I think UncollectNode is still need, CorrelateNode is not needed.
I will rebase once #10685 is merged.

Decorrelate won't work on the correlate + uncollect node. I think we should handle this in a rule and write our own StageNode for translation.

Decorrelate won't work on the correlate + uncollect node. I think we should handle this in a rule and write our own StageNode for translation.

hmm. this is probably expected as the unCollect is more like a UDTF (user-defined table function) that expands 1-row into n-rows. modeling it as a self-join will not simplify the plan

For Unnest, we need to have a separated operator to work on it, it's not able to decorrelate.


Keep version history up-to-date

As a side not on this, the latest migration (10_adding_supplier_to_user_table) will not run if there is already any user data in the database, because adding the constraint fails (users with 'supplier' role but no supplier_id).
This is OK for us at the moment because there is no user data in the prod databases, but we might want to get into the habit of adding constraints in two steps, making sure the database is in a consistent state before adding the constraint.

There is data in the preview database though right? Do we have to drop and reload the preview database for this to work?

I don't think there is User data in preview?  But I could be wrong.  The PR has already been merged, so if everything is green in preview beanstalk then I guess it went ok :/

I'm pretty sure we haven't run either the import_suppliers, import_users or import-g4-g5 into any API in Amazon yet.  So "breaking" changes to the database up until we do that import should all be OK.


Users/plimbani/versionupdate

updated version of veristand from 2021 to 2023

@Palshini before merging this (which you should do with "Squash and merge"), can you update the PR title to reflect the changes? Right now it is unhelpful.


southpark.lat not working

Checklist

[X] I'm reporting a broken site
[X] I've verified that I'm running yt-dlp version 2022.06.29 (update instructions) or later (specify commit)
[X] I've checked that all provided URLs are playable in a browser with the same IP and same login details
[X] I've checked that all URLs and arguments with special characters are properly quoted or escaped
[X] I've searched the bugtracker for similar issues including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue
[X] I've read about sharing account credentials and I'm willing to share it if required

Region
United States, Spain
Provide a description that is worded well enough to be understood
I am on the latest version and trying to download from southpark.lat, but it seems unable to get the HTML page. This site is region locked to Spanish-speaking countries, and I am trying to access it from the United States. I have checked and my yt-dlp installation is complete.
URLs:
https://www.southpark.lat/episodios/46s8wh/south-park-bajalo-temporada-21-ep-2 (Spanish)
https://www.southpark.lat/en/episodes/46s8wh/south-park-put-it-down-season-21-ep-2 (English)
Provide verbose output that clearly demonstrates the problem

[X] Run your yt-dlp command with -vU flag added (yt-dlp -vU <your command line>)
[X] Copy the WHOLE output (starting with [debug] Command-line config) and insert it below

Complete Verbose Output
C:\[...]>yt-dlp -vU https://www.southpark.lat/episodios/46s8wh/south-park-bajalo-temporada-21-ep-2
[debug] Command-line config: ['-vU', 'https://www.southpark.lat/episodios/46s8wh/south-park-bajalo-temporada-21-ep-2']
[debug] Encodings: locale cp1252, fs utf-8, pref cp1252, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version 2022.06.29 [9d339c4] (win32_exe)
[debug] Python 3.8.10 (CPython 64bit) - Windows-10-10.0.19043-SP0
[debug] Checking exe version: ffmpeg -bsfs
[debug] Checking exe version: ffprobe -bsfs
[debug] exe versions: ffmpeg 2022-05-12-git-30e2bb0f64-full_build-www.gyan.dev (setts), ffprobe 2022-05-12-git-30e2bb0f64-full_build-www.gyan.dev
[debug] Optional libraries: Cryptodome-3.15.0, brotli-1.0.9, certifi-2022.06.15, mutagen-1.45.1, sqlite3-2.6.0, websockets-10.3
[debug] Proxy map: {}
[debug] Fetching release info: https://api.github.com/repos/yt-dlp/yt-dlp/releases/latest
[debug] Downloading _update_spec from https://github.com/yt-dlp/yt-dlp/releases/download/2022.06.29/_update_spec
Latest version: 2022.06.29, Current version: 2022.06.29
yt-dlp is up to date (2022.06.29)
[debug] [southpark.lat] Extracting URL: https://www.southpark.lat/episodios/46s8wh/south-park-bajalo-temporada-21-ep-2
[southpark.lat] south-park-bajalo-temporada-21-ep-2: Downloading webpage
ERROR: [southpark.lat] 46s8wh: Unable to download webpage: HTTP Error 404: Not Found (caused by <HTTPError 404: 'Not Found'>); please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U
  File "yt_dlp\extractor\common.py", line 640, in extract
  File "yt_dlp\extractor\mtv.py", line 325, in _real_extract
  File "yt_dlp\extractor\common.py", line 1051, in _download_webpage
  File "yt_dlp\extractor\common.py", line 1002, in download_content
  File "yt_dlp\extractor\common.py", line 834, in _download_webpage_handle
  File "yt_dlp\extractor\common.py", line 791, in _request_webpage

  File "yt_dlp\extractor\common.py", line 773, in _request_webpage
  File "yt_dlp\YoutubeDL.py", line 3596, in urlopen
  File "urllib\request.py", line 531, in open
  File "urllib\request.py", line 640, in http_response
  File "urllib\request.py", line 563, in error
  File "urllib\request.py", line 502, in _call_chain
  File "urllib\request.py", line 755, in http_error_302
  File "urllib\request.py", line 531, in open
  File "urllib\request.py", line 640, in http_response
  File "urllib\request.py", line 569, in error
  File "urllib\request.py", line 502, in _call_chain
  File "urllib\request.py", line 649, in http_error_default
urllib.error.HTTPError: HTTP Error 404: Not Found

This site is region locked to Spanish-speaking countries, and I am trying to access it from the United States

So why do you expect it to work with yt-dlp?

[X] I've checked that all provided URLs are playable in a browser with the same IP and same login details

I was hoping that I could use this to rip the Spanish versions of episodes. If I use yt-dlp on southpark.cc's Spanish episodes, they just download in English, even though they have Spanish audio when played in a browser.


Purl extras

Please have a look at the individual commit messages for the details.

FYI @Etsija, I decided to bring these upstream as I believe the functionality could be of wider use.


The text of author name in comment section is absurdly large after update 2.4.0

This issue may be a little controversal. I understand that the text should be bigger to make it easier to click, but I don't think it should be even visibly larger than the text of names in friend links, in case of the text of comments under it is much smaller.

This is by design :)


Removing ProgramRecords info when saving data to sam/bam?

Hi,
Before ADAM,I got PG info in the sam file:

After ADAM, the output sam/bam file lost the PG info

Agreed, this is something we are missing. I've opened https://github.com/bigdatagenomics/bdg-formats/issues/114 as we'll need an upstream schema addition. I think this implementation will be similar to #1233.

I don't think this will make the upcoming 0.21.0 release, but we'll pick this up in 0.22.0.

+1

Looking forward to this .


NU5: Monitor estimated activation time based on current and activation block height

Motive:
Monitor the network activation to determine when it will actually happen, as follows:
Monitor the network upgrade activation
To do that, periodically subtract the current block height (get it from a block explorer or a synced node) from the activation height, and multiply by 75 seconds. (The target block interval.) Divide by (60*60*24) to get the number of days before activation.

We can use this command (substitute the current height from e.g. https://zcashblockexplorer.com/)
python -c 'import datetime; print((datetime.datetime.utcnow() + datetime.timedelta(seconds=((1687104 - CURRENT_HEIGHT) * 75))).isoformat())'

Current estimate is 2022-05-31T16:58:51

Current estimate is 2022-05-31T17:43:43 UTC

2022-05-31T17:45:50 UTC


Question about the teacher model

Hi! Recently I have also tried to use student-teacher model in semi-supervised learning, and I have also met the same problem as you explained in this issue. But I wonder whether it is necessary to set the teacher model as model_t = torch.nn.SyncBatchNorm.convert_sync_batchnorm(model_t)? Thanks!

I think it could be necessary since the parameters of BN will be updated during the teacher forward by switching model_teacher.train().


Grouping of actions in a single event in live feeds

When subscribing to assets in live feeds, it is sometime desirable to group actions together is they arrive closely after each other. Otherwise every action would result in its own event.
This could be implemented in the abstract base class LiveFeed by support a "queue" where actions are put before a timeout is triggered and send all of them in a single Event.

Added more generic CombinedFeed that allows combining any type of feed. For example a feed containing stocks and a feed containing benchmark ETFs. For release 1.1 this is the scope, but for release 2.0 will add more features.

Added aggregation feeds


ci: factor out steps into scripts where possible

Rather than embedding scripts within the workflow YAML files, factoring them out into standalone scripts lets them be treated like any other piece of code:

Easier to test
Can be run locally
Can use nix to package them for reproducibility
Easier to port to other CI systems

Resolved by 5fe26cd46cfa69e255663a704376f67e01bfe167.


websocat: fix wrapping

Motivation for this change
When called with the option sh-c:..., websocat looks for sh in $PATH. However, there are situations where $PATH doesn't contain sh, such as when called as a systemd unit. This pull request adds the necessary wrapping.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Awesome, thank you two for the quick review and the merge! :-)


This repo has merged into aspnet/Extensions and will be archived

As a part of aspnet/AspNetCore#3598, we're reducing repos. This repo will merge into https://github.com/aspnet/Extensions and be archived.

cc @ajcvickers


Path to preferences?

What do I put for path in preferences?
final prefs = await Preferences.preferences(path: null);

The path where you want to file to be saved


Add seed to packmol and rdkit

see https://m3g.github.io/packmol/userguide.shtml

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

Project coverage is 100.00%. Comparing base (52611de) to head (323ba9e).
Report is 2 commits behind head on main.

Additional details and impacted files
@@             Coverage Diff              @@
##             main       #12       +/-   ##
============================================
+ Coverage   64.88%   100.00%   +35.11%
============================================
  Files           7         8        +1
  Lines         487       154      -333
============================================
- Hits          316       154      -162
+ Misses        171         0      -171

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


Update to PSET prefix

This closes #86 and also adds the string type for nonce in TransactionOutput that was missing.

I'll merge once we have the updated nigiri-travis images @altafan


schema: Add support of IP routing

The routing information will be at the top level of network state information.

New patch uploaded.
The example would be:
 "routing": {
    "ribs": [
        {
            "name":        "",  # no name defined in /etc/iproute2/rt_tables
            "route-table": 100,
            "address-family": "ipv6",
            "default-rib": true,
            "routes": [
                {
                    "source-protocol": "auto",
                    "iface": "wlp3s0",
                    "destination-prefix": "::/0",
                    "route-preference": 100,
                    "next-hop": {
                        "simple-next-hop": {
                            "outgoing-interface": "wlp3s0",
                            "next-hop-address": "fe00:1/8"
                        }
                    }
                }
            ]
        },
        {
            "name":        "main",
            "route-table": 254,
            "address-family": "ipv4",
            "default-rib": true,
            "routes": [
                {
                    "source-protocol": "static",
                    "iface": "wlp3s0",
                    "destination-prefix": "<IP_ADDRESS>/0",
                    "route-preference": 100,
                    "next-hop": {
                        "simple-next-hop": {
                            "outgoing-interface": "wlp3s0",
                            "next-hop-address": "<IP_ADDRESS>"
                        }
                    }
                }
            ]
        }
    ]
}

New patch uploaded.
The schema changed to:
{
    "routes": [         # Sorted with 'table-id' then 'destination'
        {
            "status": "up",         # Set as 'absent' to remove routes
            "table-name": "main",   # Empty if no name attached
            "table-id": 254,
            "origin": "dhcp",     # "static" or "dhcp"
            "metric": 100,
            "destination": "<IP_ADDRESS>/0",     # Mandatory
            "next-hop-iface": "eth0",       # Mandatory
            "next-hop-address": "<IP_ADDRESS>"
            # ^ Empty on point-to-point link
        },
        {
            "status": "up",         # Set as 'absent' to remove routes
            "table-name": "main",   # Empty if no name attached
            "table-id": 254,
            "origin": "ipv6-ra",    # "static" or "ipv6-ra"
            "metric": 100,
            "destination": "::/0",      # Mandatory
            "next-hop-iface": "eth0",   # Mandatory
            "next-hop-address": "fe80::1"
        },
    ],
}

Test case included.
The 'status' changed to 'state'.
The 'up' state changed to 'active'.

The 'up' state changed to 'active'.

IMHO introducing a new value for state that we do not use in interfaces does not add value but makes things complicated.

New patch uploaded.
Apply the suggestions in feedback.


Spike: improve bazel experience in the repo

Is your feature request related to a problem? Please describe.
Getting started with bazel is hard.
Describe the solution you'd like

perhaps a makefile to wrap useful bazel targets
comments in the bazel build files and rules
FAQ section

Very hard to achieve imho. I've already expressed my concerns, but I will add also my thoughts here on the subject.

I see this issue a bit countersense, coming up with ways to improve its "daily" experience it just highlights that it's not good, and it is a failure (my personal point of view)  my experience with bazel

Very hard to achieve imho, I have already expressed my thoughts on the subject already, but I'll add them here too so everyone is free to debate with me in the public :smile:  :

I see this issue a bit a countersense. Having to come up with ways to "simplify it" shows that bazel failed in this area. No matter how you will hide the complexity, we will have to face it on "daily" basis. And given that our team is not acquainted with it, it becomes even cumbersome. That is my personal opinion with the experience I had with it.
Creating a Makefile to wrap it, sounds pretty much that we don't need bazel. Having two ways to building things on the same project is a red-flag for me, because we could just have one that works, and is really understood by the involved parties. Bazel looks like a top-down decision that (as far as I know) I'm not the only one that disagrees with.  Usually one have to support their decision to adopt new things, not the opposite way around.
There are comments, even README in the build targets, that doesn't help much. Extending the docs about them, again, shows to me that it failed very hard in usability. I expect also to have docs that are human readable from bazel itself (yes, might sound hard, but I don't find them helpful)
To be honest: I see working on this again as a wasted engineering cycles. "Wrapping up" will make things even more complex, and even harder to understand.
I would expect a "novel" build system to give me more than just restrictions, at least should give me something back for the effort I put on it. There is no real catch of using bazel for me (again, personal opinion, but if we don't have opinion on softwares, means we are not using it :smile:  ) except the complexity built around it, and docs that are very difficult to follow. There are no even consistent examples that you can base your work on.
I dislike Python (again, personal opinion) and I see the bazel DSL very strict (that doesn't mean necessarly a bad thing) but at the same time it's just readable to those wrote that DSL. There was no Human-Computer-Interaction goal in mind. I think the computer science literature on the subject is well structured, and gives a lot of inputs. I could cite more articles, but I would refrain me to do so, I will just cite the most famous one.
I expect in the long run to be more proficient with it, but that doesn't mean that it is a success story. Instead it looks to me we are just exploring only one way to do things - and we keep going with it neverthless

From the discussion before, I remember there was also some interest in re-organizing the ops files by function instead of by instance_group.
Is this part of this issue?

@manno No. There should be a different story for that (not sure if it was created already).

I'll not repeat what Ettore said, I'll just say I agree. I think bazel if (probably?) solving some problem but not a problem we have or a problem we should ever have in kubecf.
Building kubecf artifacts is and should remain a fast and simple process. It shouldn't need distributing the build workload in multiple machines, it shouldn't need sophisticated caching, it shouldn't need to check a huge list of dependencies before the build process starts because the build process should just take 3 seconds.
I'm not fluent in bazel syntax and idiosyncrasies but reading about bazel benefits (e.g. here) I don't see any feature that makes it useful for kubecf.
Summing up, I have to agree, the best way to improve the bazel experience in my opinion is to remove bazel. If you think replacing bazel isn't worth the time and effort, you need to see how much time we loose every time we need to do a simple thing in bazel. We would have replaced it 3 times by now.

Just for the record: I'm only doing some preliminary exploration to further the discussion, as we have not reached agreement yet, but @viovanov wanted me to move the issue to the project for this.

Replacing bazel with shell scripts
Prior feedback from internal SUSE mailing list
With the exception of Thulio and Vlad all SUSE team-members that voiced an opinion were really negative about using bazel. From the internal email thread:
Dimitris:

I spent an unreasonable amount of time trying to do simple things in bazel and most of the time I ended up finding workarounds just to avoid the deep dive in bazel docs.

Ettore:

Our use case of bazel seems to be very small related to the features that it provides. At the end, you cannot even "steal" examples from real-use cases, as they are completely off from our usage.

Victor:

It does it as a big black box, instead of a toolbox of little executables with its own manpages and docs.

Mario:

If you don't need the docker image caching features, I guess it's just another overly complicated build system.

Mark:

I too find the bazel documentation terrible: it's extremely non-obvious where the correct docs are. [...] We're also using it in a way it's not suited for: it's good for building things, but not so much running things [...].  Every time we're doing that it just feels like we're fighting against what it wants.

Me:

I also dislike the way the whole bazel build system is opaque. You cannot run with a --dry-run option to see what it will execute; you can't even see what it does when it builds things because many actions are executed internally by bazel itself.

Examples where bazel has gotten in the way
We can already see that bazel slows us down significantly. Look at PR #149 "Annotate operator chart url in Chart.yaml": almost 40 lines of changes over 4 different files, just to write the operator URL to a file in the helm chart.
Another example is PR #557 "Print image list script for kubecf manifest", later superseded by #571. It had been worked on and reviewed by multiple people, but to make it work properly with bazel it had to be redone by Thulio, who is our only bazel expert.
As Mark mentioned above, we mostly use bazel not for building, but for running. But it isn't good enough for that either, so we have PR #573 "Add a Makefile with easy to discover targets" to wrap bazel targets with a Makefile. Wrapping a dependency tracking build system with yet another dependency tracking build system, that we again just use as a launcher.
Kubernetes is getting rid of bazel
Even kubernetes itself is getting rid of bazel: Please remove bazel based build infrastructure:

With the switch to go modules/cache, most of the reasons why bazel was used (speed up compilations) are gone.

The reason they were using bazel doesn't even apply to us: we don't compile code for kubecf, so we don't need caching.
But the problems they run into sound extremely familiar:

The #bazel channel is filled with questions like, "How do I do this thing that should be moderately simple to do if it wasn't wrapped in bazel?"

This is a huge maintainability burden, with our limited set of bazel experts being some of the most bandwidth-constrained contributors in the project.

And the release engineering team seems fully on board with getting rid of bazel:

@kubernetes/release-engineering is on board to help tear this down. Just let us know which threads we need to start pulling on to make this happen.

Alternative implementation in bash
I've created a proof of concept, implementing a couple of the bazel targets in simple shell scripts. See PR #583 "Build and run kubecf without bazel" for the code. It is neither robust nor complete; it only exists to illustrate the point:
$ time make kubecf-build
./scripts/kubecf-build.sh
Successfully packaged chart and saved it to: output/kubecf-v0.0.0-ab6026b.tgz

real	0m2.420s

It builds the complete product from scratch in 2-3 seconds. There is no caching, no dependency tracking; everything is built from scratch every single time. And it is just 50 lines of simple shell script that I expect all team members to understand easily.
The files generated are identical to the ones created by bazel build //deploy/helm/kubecf, except for the sort order of the keys in 2 yaml files because I write them using ruby instead of yq.
I've prototyped a couple of other scripts as well to show the full kubecf build/test cycle can be done with very little code:
$ VM_DRIVER=virtualbox MINIKUBE_EXTRA_OPTIONS=--registry-mirror=http://dockerhub.home:5000 make minikube-start
$ make cf-operator-apply
$ pod-status -w
$ make kubecf-build
$ make kubecf-apply
$ pod-status -w
$ make testing-smoke
$ kubectl logs --follow --namespace kubecf \
>         --selector "quarks.cloudfoundry.org/qjob-name in (kubecf-smoke-tests)" \
>         --container smoke-tests-smoke-tests
Running smoke tests...
Running binaries smoke/isolation_segments/isolation_segments.test
smoke/logging/logging.test
smoke/runtime/runtime.test
[1585700822] CF-Isolation-Segment-Smoke-Tests - 4 specs - 4 nodes SSSS SUCCESS! 17.960221513s
...

Looking at this experiment, I now firmly believe that we should replace our bazel rules with a couple of shell scripts.
If we implement some additional mechanism to allow downloading and using specific binary versions of tools used by the scripts (helm, jq) then we should have all the functionality provided by the current bazel setup, but in a format that can be maintained by all team members and is easy to understand by external contributors.
Please let me know if we are using any other bazel feature, that we would be losing by making this switch?

We have many (types) of dependencies

docker images
bosh releases
helm charts
ops files
scripts
tests

And a lot of tooling

helm
kubectl
kind
k
yq
jq

This project is not meant to have constant code churn.
It's meant to provide a rock-solid integration of Cloud Foundry components for Kubernetes.
That is the goal.
Bazel helps us pin down dependencies and provides us with reproducible builds using well defined rules.
Again, this is the absolute goal of this project.
I am not convinced that implementing bazel rules is as difficult as the team says it is. There is a learning curve, like any other tool, but steeper.
I also don't think it's a good idea to give it up, given that it does everything we need it to.
No, I really don't want to give up on Bazel, I think it's just beginning to show its potential for integrating complex projects.
Implementing everything that bazel provides in shell is a bad idea.
We use shell scripts for small units of work, of course, but shell scripts are not good for building complex frameworks and dependency management.
We'll cut corners and implement something that we don't need. The build system for kubecf is there, and working well.
I am open to the idea of removing dev environments from kubecf's responsibilities though.
#149 - yes, we are building helm rules for bazel (I actually find this work awesome, and it should live in a repo of its own)
#557 - nothing was "redone" - @f0rmiga picked up a spike from @rohitsakala (it was never meant to be the final implementation, just proof it could be done).
#573 - I guess it's my fault for trying to help; was simply trying to empathize, and essentially provide a list of aliases, nothing more; I think calling it a "wrapper" is inaccurate.
About Kubernetes - I am not sure that's relevant to us - afaict they haven't made a decision yet, and they don't have such a varied dependency list.
There are many success stories out there for Bazel:

SpaceX
TensorFlow
Dropbox

My 2 cents on this:

Hard to give an opinion on the topic while I think the hassle comes when developing bazel rules or similar. I haven´t done that yet, and my interactions with the build tool is restricted to a couple of targets, mainly bazel build //deploy/helm/kubecf.
The learning curve is definitely high, I can immediately see this when reading parts of the bazel config, but this again, does not have an impact on users that only run the main targets. Unless is debugging a failed target, I have get into this situation, which can be tedious, but probably as with any debugging.
For the dependency management, I think Bazel does a good job, e.g. the cf-deployment base YAMLs. It would be a nice exercise to do this in shell(duable but probably not so clean).
It seems the amount of bazel targets is high. As an end-user I´m probably mainly interested on packaging the charts and consuming them, which boils down to one or two targets(e.g.bazel build //deploy/bundle:cf_operator_chart and bazel build //deploy/helm/kubecf:version). It might be a good idea to revisit the amount of targets that this repo supports, e.g.  bazel query //dev/... vs bazel query //deploy/..., and reconsider if all of them are needed, or if some of them could be implemented differently.

I'll push back on some of the mentions:

I spent an unreasonable amount of time trying to do simple things in bazel and most of the time I ended up finding workarounds just to avoid the deep dive in bazel docs.

When did we start thinking that deep-diving into docs is a bad thing that should be avoided? Bazel docs may not be the best doc ever written, but it's there!

Our use case of bazel seems to be very small related to the features that it provides. At the end, you cannot even "steal" examples from real-use cases, as they are completely off from our usage.

We are not after copy-pasting things, as far as I can tell. The objective is to understand the value of deterministic builds and to bring that philosophy to KubeCF. The "black-box," as some like to call the rules, is doing it on a sandboxed filesystem and without the interference of the terminal session environment, i.e. the user environment variables don't cause side-effects in the build.

It does it as a big black box, instead of a toolbox of little executables with its own manpages and docs.

I agree that the rules should have better documentation, but they are very well broken into small rules that, in most of the cases, do one and one job. Whenever we break the rules, we should rethink and fix, not get rid of the whole build system because some people don't understand it.

If you don't need the docker image caching features, I guess it's just another overly complicated build system.

We can do image caching, and I'd love it (I guess everyone would). Like Vlad mentioned, "No, I really don't want to give up on Bazel, I think it's just beginning to show its potential for integrating complex projects."
We can create tasks for implementing it in a similar way that Gazelle does for Go rules.

I too find the bazel documentation terrible: it's extremely non-obvious where the correct docs are. [...] We're also using it in a way it's not suited for: it's good for building things, but not so much running things [...]. Every time we're doing that it just feels like we're fighting against what it wants.

Bazel is well-suited for running things. It's more work because we want to eliminate as much as possible the dependencies on the user environment to run, e.g. tracking the kind, minikube, kubectl and helm binaries.
As soon as we get rid of this strict dependency tracking, we will start having all sorts of issues due to version incompatibilities that we cannot completely foresee. As long as we keep track of the versions in the way we do, we can point people to the versions we are using and testing many times a day!

I also dislike the way the whole bazel build system is opaque. You cannot run with a --dry-run option to see what it will execute; you can't even see what it does when it builds things because many actions are executed internally by bazel itself.

I also dislike that, but we should be working together to overcome this, perhaps with creative solutions that we could share with the community!

Lastly, as mentioned by Enrique, we don't expect everyone to touch the Bazel rules all the time, and KubeCF development shouldn't be mostly focused on ops-files.

The toolchain doesn't have to define a project goal or scope. The toolchain have to fit the project, not the other way around. The project should be completely disjointed by it. It seems instead we are bending KubeCF to the toolchain being adopted right now.
Let's take a step back and look at what bazel is good at: big codebase that needs to be compiled and needs caching. Now lets take a look through KubeCF: a set of YAML files.
Taking the right tool for the right job is more important in my honest opinion. Clearly bazel doesn't fit, as it does much more than what we need and @jandubois PR shows that actually we could live without it (PR needs improvement, yes, like pinning dependencies, but we don't have so many: k or kind for example, are not necessary to build a helm chart).
The use cases you mentioned are really good for big C, or C++ projects, where compilation times are drastically high ( I have some experience with it ) and bazel shared compilation mechanism can help a lot: but not at YAML packaging.
Tensorflow it's an amalgams of C++/C code with Python on top. And the examples given are totally out of our context (feel free to push me back, but I still believe that KubeCF its not something that have to be compiled, and you cannot leverage the "distributed compilation" or "caching" features that bazel advertize). I would suggest you to go through the Kubernetes issue Jan mentioned, there you can see the full rationale.
For example, the dependencies can be be tracked as well in a single docker image. The use-cases you mention here (pinning dependencies, and so on) doesn't require a toolchain that is meant for different scopes. Even docker can be used to containerize and pin dependencies to run workloads, I don't see our use case requiring so much complex tooling that needs a build system that was clearly designed for other uses cases in mind.
Docs are really important, they shouldn't "just exist" but they have to be clear and well scoped. If you cannot take the example they provide and run it locally with success they have important flaws that makes the steep learning curve even higher without a good reason.
To end my dissertion here, and I won't add more as it looks a bit of waste of energy ( :smile: ) : It's not just "some" people not liking it as shown in https://github.com/cloudfoundry-incubator/kubecf/issues/545#issuecomment-606976345. Apparently a decision was already taken, and we have to live with it.
With a metaphor that is really known (maybe only in my country): we are killing a mosquito with a (broken)bazooka.

It looks like the strict tracking of tool dependencies was the last remaining feature of the bazel rule system that was missing from my proof-of-concept in #583. I've implemented this too now, to prove that it is not as hard as some seem to think.
I strongly believe that the scripts now provide all the functionality we use from bazel, while improving on several of the shortcomings:
Essential features provided by both bazel and the shell based build system

Fast build time

Tracking of all code dependencies

Tracking of many tool dependencies

Essential features only provided by the shell based build system

Understandable and maintainable by all team members; easy to pick up by contributors

Transparent execution that can be traced and debugged; steps can be executed manually and intermediate results can be inspected; parts are reusable outside the build framework

Serves as executable documentation how to perform various tasks; less likely to be obsolete than pure docs

Essential features only provided by the bazel rules based system
None that I'm ware of (and I've reviewed both the previous comments here, as well as the prior internal SUSE mailing list thread). If I missed anything substantial (that we actually use in this project), please let me know!
Conclusion
The long and steep learning curve has been acknowledged by everyone. But the benefit that justifies the required big investment of time remains unclear.
The claim that most people don't need to understand how the project is being built feels ridiculous. We make changes to build and test scripts all the time, and everyone, including people working on CI and QA need to be able to understand how this works, and make changes easily and with confidence.
The essence of the shell scripts already exists inside the bazel rules system. The scripts are just obfuscated as templates and not reusable outside of bazel. It is not possible to manually execute them step by step for debugging, or at even get a trace of what happened.
Having accessible scripts also provides documentation. The question from @cweibel above is a perfect example. If we already had scripts/test-smoking.sh then he would have likely found the answer by himself and didn't have to ask.
How can we justify not switching to a system that would work so much better for us?

Just to add my 2 cents here:
I think bazel is a bit over-engineered for this purpose. As I see it it overcomplicates things. I am in favour of @jandubois suggestion to reimplement it in bash.

We've decided to remove Bazel as a build system for kubecf.
Closing this in favor of #749


Android Studio instructions outdated?

https://github.com/googlesamples/android-testing-templates/tree/master/AndroidTestingBlueprint#running-instrumentation-tests says:

In Android Studio

In the Build Variants window, make sure the Android Instrumentation Tests option is selected.
Open a Instrumentation test class like EspressoTest.java or UiAutomatorTest.java
Right click on the class and Run as Android Test.

For me (Android Studio 2.3.3 and 3 beta 6) there is no selection for this in "Build Variants".
On right clicking I also don't get "Run as ..." as an option, only "Run '...'".
What is the current equivalent for these instructions?

Hm I guess "Run configurations" are the solution here:

via https://stackoverflow.com/a/46441463/252627
Or is there an easier way that I overlooked?


test ads not showing in release apk

Plugin Version

Steps to Reproduce

Run flutter create bug.
Update the files as follows: ...
...

Expected results:
Actual results:

Logs

Hi @niaz25610, please try to provide all of the information indicated in the template.
Closing this issue, since no information has been provided. Once you have provided information, please update the issue then I will reopen this.
Thank you.

Same problem on my app, about 3 days ago everything was running ok, test ads were showing perfectly but now none of the ads are showing and the following message keep repeating in the bug console:
/DynamitePackage( 4725): Instantiating com.google.android.gms.ads.ChimeraAdManagerCreatorImpl
I/Ads     ( 4725): This request is sent from a test device.
W/Ads     ( 4725): Not retrying to fetch app settings
W/Ads     ( 4725): Maximum number of ad requests stored reached. Dropping the current request.
I/Ads     ( 4725): Ad failed to load : 1
I believe is a problem in the googleads-mobile-packages because i have not change anything in my code.


Chocolatey packaging for Windows [main]

Context https://github.com/cloudfoundry/cli/pull/2767
Where this PR should be backported?

[x] main - all changes should by default start here
[x] v8
[ ] v7

/easycla


feat: enhance hotels route with numGuests query parameter support

Description:
Issue Summary:
we want to extend the /hotels route to support the numGuests query parameter in the URL. This feature will enable users to directly navigate to a pre-filtered list of hotels based on the number of guests, improving the flexibility and user experience for booking accommodations.
Objective:
Enable the /hotels route to accept a numGuests query parameter in the URL, allowing users to directly navigate to a list of hotels that can accommodate the specified number of guests. This feature should support both direct URL entry (e.g., /hotels?numGuests=4) and navigation from within the application.
Implementation Steps:

Query Parameter Support:

Modify the hotels route to parse the numGuests query parameter from the URL. This involves checking the URL for any numGuests parameters upon route loading.

Prioritize Query Parameter:

Adjust the logic within the /hotels route to first check for a numGuests query parameter. If present, use this parameter to filter the hotel listings based on the available accommodations for the specified number of guests.
If the numGuests query parameter is not present, then fallback to using the existing state variable (guestsInputValue) as the source for the guest filter.
Consider reusing or modifying the existing useEffect hook that handles location changes to incorporate the numGuests parameter, similar to the implementation for the city parameter in issue #47.

References:

See issue #47 for a similar implementation regarding the city query parameter.

@iZooGooD I will start working on this issue right away

@iZooGooD I will start working on this issue right away

Thanks, merged the PR.

Welcome!


Csharpier .editorconfig

I'm trying to use both dotnet-format and csharpier on a project, as there are some fixes that dotnet format can provide that csharpier doesn't handle and vice versa. However, I'd like dotnet format to defer to csharpier's rules whenever there's any crossover.
Is it possible that we could get an .editorconfig file that describes csharpier's current rules as closely as possible?

It is possible to run dotnet-format from the command line without changing whitespace and from my understanding (without actually using it in the real world) that would avoid any potential conflicts.  See https://csharpier.com/docs/IntegratingWithLinters
If there are situations where dotnet-format runs and it isn't possible to pass it the options to avoid formatting whitespace then I think it makes sense to figure out the .editorconfig that gets it as close as possible.

Yeah, there's not really any conflicts if using the commands (just run dotnet-format first, then run csharpier second, second command "wins"). However there are many VS2022 suggestions that pop up based on a solution's .editorconfig file, and it'd be good if I could figure out how to get those to align with csharpier's rules.

That makes sense. I feel the need to address every suggestion that rider makes, so I can relate.

I started with just this in an .editorconfig, and dotnet format whitespace doesn't have a lot of changes.
indent_style = space
indent_size = 4
trim_trailing_whitespace = true
insert_final_newline = true

The only two differences, at least in the csharpier codebase, are indentation inside a switch and indentation on pattern matching.
However it is completely happy with the places where csharpier indents 2 spaces. It doesn't seem to care at all what kind of indentation is used in a conditional like this, nor does visual studio.
return true
  ? false
      ? 1
      : 3
  : 4;

If I use riders code cleanup there are a lot more differences. Rider does have quite a few custom properties that could be tweaked to get it closer. This is the only one I tracked down so far.
resharper_csharp_empty_block_style = together_same_line

Why is csharpier not using the .editorconfig? Its basically an industry standard now and microsoft recommends it: https://docs.microsoft.com/en-us/visualstudio/ide/create-portable-custom-editor-options?view=vs-2022 and supports a fair amount of specific rules: https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/code-style-rule-options

The only option CSharpier currently supports is printWidth. I could be convinced that it makes sense to read the max_line_length value from an editorconfig in place of printWidth but no one has asked for it. The only reason I could see not doing it is because it may be a little weird to "support" an editorconfig but completely disregard other formatting properties that are in the file.

Ah ok, make sense for an 'opinionated' formatter.

+1 for supporting max_line_length

I too am already using the built in dotnet format tool but it straight up sucks at whitespace formatting at the moment. I'd like to use this tool to get it the rest of the way there and the only CSharpier config options I'd like to use are already in the .editorconfig (the ones already mentioned in this thread above).
So really if this tool were to look into the .editorconfig for the default values for these settings it would just work out of the box. If the .csharpierrc file happens to be there it could win over the .editorconfig but by default it would work as expected for most people already using the dotnet formatter.

@belav Any objection to a PR for this? Was thinking of reading the following from the top level .editorconfig if .charpierrc doesn't exist:

max_line_length = printWidth
indent_style (tab|space) = useTabs (true|false)
indent_size = tabWidth

My plan would be to add the new code around this line:
https://github.com/belav/csharpier/blob/7cea674cb8f34fe11b66f1e741ca907180d6e29f/Src/CSharpier.Cli/ConfigurationFileOptions.cs#L74

@sethreno none at all, I just haven't had the time to get to this.
That looks like the proper place, and then some tests to cover different situations in https://github.com/belav/csharpier/blob/master/Src/CSharpier.Tests/ConfigurationFileOptionsTests.cs is probably all that is needed.

@belav Any objection to a PR for this? Was thinking of reading the following from the top level .editorconfig if .charpierrc doesn't exist:

max_line_length = printWidth
indent_style (tab|space) = useTabs (true|false)
indent_size = tabWidth

My plan would be to add the new code around this line:
https://github.com/belav/csharpier/blob/7cea674cb8f34fe11b66f1e741ca907180d6e29f/Src/CSharpier.Cli/ConfigurationFileOptions.cs#L74

I'm a big fan of this idea. I arrived here because I changed max_line_length in my .editorconfig and was surprised when nothing was affected.


Mobile App Offline Storage Feature Request

A brief description of the feature or enhancement you'd like to see:
A clear and concise description of what the feature or enhancement is, Ex. Using this tool be would be much easier if [...]
Provide offline storage in mobile application.
How will this feature be used?
A clear description of how, who, and when this feature would be used. Ex. User A wants to create a new Incident [...]
Store incident data which cannot be submitted, possible reasons

No internet
Poor internet

What is the impact of this feature/enhancement?
Describe the impact of this feature or enhancement, how will it help users or adoption of this project. Ex. All users will be less frustrated when [...]
Provides the option to store data on device to allow user to pick up where left off, saving time.
Acceptance Criteria
What does it look like if we've implemented this enhancement or new feature correctly? Ex. User A was able to create a new incident 5s faster than previously [...]
Improve end-user experience and save time.

The following may be be a good option to use with React-Native:
https://github.com/react-native-async-storage/async-storage

Hi @nitekon1 We are interested in working on the issue. Is there any update on the status of this?

@krisstern glad to hear you have interest in working on this solution with us!  We have a weekly scrum call on Thursdays at 2PM CDT, are you available to attend?


Diff mode Merged shows result only partially

After implementing the Merged mode a few days ago using php-diff 2.3.1, it seems that the HTML Merged mode shows the diff only partially in comparison to Unified or SideBySide.
Example:
Unified

Merged

Example text:
version_a.txt
version_b.txt

Can you mention the lines you are referring to?
HTML merged only marks inline differences and added blocks text.
Blocks of texts which are removed at version 2, are marked in line column of the table:

Ignores changes in line
19 to 21
70 to 86
99 -  not shown at all, not like in your example above

Example: (enabled diff for guests temporarily)
https://wackowiki.org/doc/Doc/English/Themes/diff?a=4227&b=0&diffmode=5

Which options did you provide to the Diff class?

No options, only default. Should I set particular options for Merged?
https://github.com/WackoWiki/wackowiki/blob/master/wacko/handler/page/diff.php#L352

I forgot to mention that I use PHP 8.0.
Found this in the error log with varying array keys:
PHP Warning:  Undefined array key 5 in /lib/php-diff/Diff/Renderer/Html/Merged.php on line 217

I didn't test with php 8, bit I'm still suprised by it.
I'll take a look into it soon.
Thank you for testing and feedback.

I forgot to mention that I use PHP 8.0.
Found this in the error log with varying array keys:
PHP Warning: Undefined array key 5 in /lib/php-diff/Diff/Renderer/Html/Merged.php on line 217
preg_match_all('/\x0.*?\x1/', $changes['changed']['lines'][$lineNo], $addedParts, PREG_PATTERN_ORDER);

Something is incorrect with your error description or file. See below lines.
https://github.com/JBlond/php-diff/blob/9830fe059c020d4d72936ef171d983df3d379d7e/lib/jblond/Diff/Renderer/Html/Merged.php#L216-L218
Also the script doesn't throw a warning or error at my local server, using php v8.0.2.

I patched away the table header therfore the different line number.
https://github.com/WackoWiki/wackowiki/blob/master/wacko/lib/php-diff/Diff/Renderer/Html/Merged.php#L217
The error messages are from the server log and do probably not belong to the posted example. I turn error reporting on again after posting the issue.

I've created a new issue for it since it seems unrelated to the original report.
Please continue the discussion about the thrown warning over there.
Also you don't have to patch the renderer. You can create your own or extend an included one.
See https://github.com/JBlond/php-diff/wiki/3.-Custom-Renderer

Ignores changes in line
19 to 21
70 to 86
99 - not shown at all, not like in your example above

19 to 21: Bug confirmed. Will create a PR for it soon.
70-86: Marked as inserted (see below).
99: Table header marked as deleted at version 1 (see below).

Don't forget to clear you browsers cache to pull in the newest css files.

Already merged and Browser cache has been purged.


For Cascader, clear search input on option select

[x] I'm sure this does not appear in the issue list of the repository

Basic Info
What are the similar cases of this feature
The Select component already has this feature.
What problem does this feature solve?
Currently when searching in Cascader in multi mode, the typed search value remains in the input box after selecting a value from the dropdown box. Hence, when the user wishes to search for another value, the user has to delete the search values first before searching for a new value.
This is not convenient for the user and is also not consistent with the Select component's user interaction which has this feature.

可以通过这个属性指定下


Installing and using Spout4Unity

Hi,
I'm trying to use Spout4Unity with Unity 5.4.0f3. My goal is to send a video stream of the Unity view to another application which will make multiple records at differents times. I can't find any documentation or tutorial on how to use this plugin.
How do you install it exactly? I imported files from the example (NativeSpoutPlugin.dll, SpoutRenderTexture.0.renderTexture, Spout.cs, SpoutSender.cs, TextureInfo.cs) to make it "work" in my project (and I put the scripts in the scene the same way the example with the cube is done). Is it the right way to install it?
For the moment, I could send the video stream from Unity to a Spout receiver, but the video is upside down. Besides, I can't find how to make the camera display both the 3D models (characters and decor) and the skybox at the same time. It only displays the skybox when i choose "skybox" in the option "clear flags" of the camera. When i choose "solid color", it only displays the 3D models with a flat background color.
Another problem: if I don't choose "deferred" for the "rendering path" of the camera, the 3D models are rendered strangely : some items are behind while they should be in front in the video stream.
Is there a list somewhere of all the plugin's functions and the way they work, or a documentation?
Thank you in advance for your help.

Hi,
it seems that you should make you more familiar with Unity at all. Most of your question are generel Unity question and don't belong to Spout. Best is to checkout the whole project from Github (https://github.com/sloopidoopi/Spout4Unity/tree/master/UnitySpoutDemo) and open the project with Unity. It's to complicated to start a new project and add the components.

Thx for this quick answer, I'm still learning Unity. I though you could import this plugin in others projects to use it.

I have the same problem with that weird rendering of models, it happens only when script taken from sender demo was added to a camera. Ive inspected the code but couldnt find the culprit.
The problem with strange rendering doesnt dissapear when using Your demo project.


Use Kubernetes 1.16 for all of our tests

Kubernetes 1.16 is coming Sept 16. This is right after we release 1.3, so ideally we have support (unofficially) for it already. This issue tracks our support

[x] Verify Istio installs on Kubernetes 1.16
[ ] Verify all tests pass on 1.16 - verified pilot k8s integration tests do
[x] Set up automated tests for 1.16 - blocked by kind releasing an official 1.16 image or us using our own

I built K8s 1.16:
git clone github.com/kubernetes/kubernetes
git checkout v1.16.0-beta.1
kind build node-image --kube-root .
kind create cluster --image kindest/node:latest

Then I installed Istio.
Things seem to install ok except Grafana is not passing readiness probe. This seems due to https://github.com/kubernetes/kubernetes/pull/76518 limiting readiness probe response to 10kb max, when grafana is returning 25kb

Our kind config patches we apply (prow/config/...) seem to break as well, may need a special variant for 1.16
Error: failed to create cluster: failed to generate kubeadm config content: no matches for OriginalId kubeadm.k8s.io_v1alpha3_ClusterConfiguration|~X|config; no matches for CurrentId kubeadm.k8s.io_v1alpha3_ClusterConfiguration|~X|config; failed to find unique target for patch kubeadm.k8s.io_v1alpha3_ClusterConfiguration|config
+ echo 'Could not setup KinD environment. Something wrong with KinD setup. Exporting logs.'
Could not setup KinD environment. Something wrong with KinD setup. Exporting logs.

set up automated testing for integration tests in postsubmit using the 1.16 beta. Next steps are using official 1.16 images when they are out and moving all the tests over

This is ready to go as soon as official kind 1.16 images are pushed out

Dropped to P1 as this is just about moving our tests over now

I attempted to update the tests, blocked by https://github.com/istio/istio/issues/18827 and Helm issues

This is done. We are on 1.17 now actually


SceneInstanceReady trigger context

The dev-docs for SceneInstanceReady state

Triggered on a scene’s parent entity when crate::SceneInstance becomes ready to use.

This is technically true, but is missing useful context like "if the scene doesn't have a parent, then the event is triggered globally" and "If you only observe the global event, you will miss events triggered for specific entities" (this second statement needs to be fact-checked, but as I was looking over the PR for thisweekinbevy it seems true).
I'll do a PR for this unless someone else gets to it first.

I believe the intended effect is for the global observer to receive all events, even when triggered for a specific entity. discord source


bytecode compilation flag doesn't do anything

As far as I can tell, meson-python doesn't support bytecode compilation of python modules inside of wheels.
In a simple test package, I tried adding the bytecompile flag via pyproject.toml:
# pyproject.toml
[build-system]
build-backend = 'mesonpy'
requires = ['meson-python', 'wheel', 'ninja', 'numpy']

...

[tool.meson-python.args]
setup = ['-Dpython.bytecompile=2']

Then I tried building the wheel with build via python -m build -nx -v, which does display the option as set during the build step:
skpackage 0.0.2

  User defined options
    Native files      : /private/var/folders/0l/b3dbb2_d2bb4y3wbbfk0wt_80000gn/T/build-via-sdist-a0tojhrv/skpackage-0.0.2/.mesonpy-9u1xqvsd/meson-python-native-file.ini
    buildtype         : release
    default_library   : static
    python.bytecompile: 2
    b_ndebug          : if-release
    b_vscrt           : md

However, when I unpack the corresponding wheel, there's no pycache directory or *.pyc files in sight. Incidentally, when I install the wheel into e.g. a virtualenv, I notice that bytecode files  are there:
├── __init__.py
├── __pycache__
│   ├── __init__.cpython-311.pyc
│   └── __version__.cpython-311.pyc
└── __version__.py

Does this behavior sound normal? I would've thought specifying the byte-compilation flag would make meson add them directly to the wheel, but this doesn't seem to be the case
(I'm using meson 1.5.2 btw)

I believe meson-python intentionally skips this, most likely because byte compiled caches are quite version specific so having them inside of a wheel that could be installed on any python version is potentially problematic.
Meson has the flag because it can be used to install the modules directly to the system, in which case it takes the role of pip and runs byte-compilation immediately for you.

I see. So in terms of its functionality, is the flag then not intended for e.g. version-specific wheel distribution on PyPI?
I'm generating wheels with extension modules + python files which are Python version specific (e.g. pkgname-cp311-macosx_10_16_x86_64.whl). At least, these are specific to the OS / ISA and the minor version of Python, not including the patch or finer subversions. Since I'm already targeting minor versions per wheel, I figured I would add bytecode compilation; but you're saying this should really happen on the actual computer the package is installed to?

I personally have no objection to the idea you suggest here. Speaking as a linux distro developer, we do ship ahead of time compiled bytecode, just like you want to do. But we don't use wheels at all.
I think standards groups for python don't really distinguish this case (having C extensions is a bit of a blind spot for the standards, in my experience) and they would probably assume you should not do it, which feels slightly awkward in my view.

requires = ['meson-python', 'wheel', 'ninja', 'numpy']

Why do you list wheel and ninja as build dependencies? wheel should not be needed and ninja is requested by meson-python is needed.

Does this behavior sound normal?

Yes, things are working as expected.

I would've thought specifying the byte-compilation flag would make meson add them directly to the wheel, but this doesn't seem to be the case

Why would you like to included the bytecompiled Python source to the wheel? The wheel installer is going to byte compile the Python source code again anyway, thus having the bytecode in the wheel is not doign anything other than wasting some storage space at best, and is causing the installer to fail at works because of a collision in the bytecode filename with an installed file.

Why would you like to included the bytecompiled Python source in the wheel?

I was originally looking for ways to improve module import time for a package, when I stumbled upon this; I was just thinking of bytecode compilation as analogous to compiling extension modules, and thought I might try to save the parser some time. It just seemed like a natural thing to add to the CI pipeline since I was already compiling code for platform-and-version-specific wheels.

The wheel installer is going to byte compile the Python source code again anyway

Ah I didn't realize this actually, I thought it was done at import time.

Anyways, it seems my issue is resolved

The wheel installer is going to byte compile the Python source code again anyway

Ah I didn't realize this actually, I thought it was done at import time.

It is done at import time if it hasn't been done previously ;) and it's possible to disable the default wheel installer behavior of performing byte compilation. (Just as it's possible to disable the meson behavior of performing byte compilation.)
Particularly for Linux distros, doing it at import time would be a major problem since there is a package manager! And the package manager has to track all files, so having files in root owned directories created later on by running applications would cause big issues. Also, if the program isn't run as root it wouldn't be able to perform automatic on-the-fly byte compilation anyway. (Technically, it does byte compilation as part of importing, but cannot save the results to the cache, so byte compilation has to be done first thing in every application startup.) So we have to do it ourselves, which is also fitting since we aren't a wheel installer -- we are a general purpose package manager.
The fact that it improves the speed of the first-time run of the package is a convenient bonus within that use case.


Instructors and building locations

Unless that should not be the case for any reason, instructors and buildings should generally be visible.
Courseography's github has a csv file outlining building information:
https://github.com/Courseography/courseography/blob/master/db/building.csv

whoops wrong github page


implement works and about myself section in the design

Created a works section
Created about myself section
Added the CSS codes to match the design
Used CSS flexbox and grid to implement these designs

@cynthiainga I have resolved the issues you identified. Kindly check again and give feedback so I don't have to request for another review, please. Thanks and I will be waiting on you

@cynthiainga Please kindly check again and get back on the issues. I have resolved all of them to the best of my knowledge.


memory leakage.

内存泄露

in  CVCalendarContentViewController
public let calendarView: CalendarView

to
public unowned let calendarView: CalendarView

Please see https://github.com/Mozharovsky/CVCalendar/commit/e3529b3b113ed4bfdd5d7b46f4043d10ce8c1537
Thank you!