Non-default mission scripting is very buggy

Working in a second mission file causes issues like randomly deleted elements and links not being shown until reloading.
Setting elements to be in the other scripts after being placed causes them to be deleted also and not be added to the other mission script file.

Fixed 2 issues relating to this: changing scripts would delete the element and elements list when selecting elements for certain values will now show only the current script (except ExecuteInOtherMission which apparently was broken lol).
If the links issue perstist, make a new issue. Try to add more information as well as reproduce steps.


ci: Configure Packit propose_downstream job

When there is a new release of this repo, Packit will fetch linux-system-roles.spec from the Rawhide branch in Fedora dist-git, update it (Source lines and %setup will be regenerated) and open a PR in Fedora Pagure. It will also upload new tarballs to lookaside and update sources.
The PR will be opened only against Rawhide for now, can be changed in dist_git_branches.
documentation:
https://packit.dev/docs/configuration/#propose_downstream https://packit.dev/docs/fedora-releases-guide/
Taking inspiration from
https://github.com/linux-system-roles/auto-maintenance/pull/233

Follow up fedora rpm PR: https://src.fedoraproject.org/rpms/ansible-collection-microsoft-sql/pull-request/40

@pcahyna I am trying to replicate packit release automation for mssql and need your help reviewing this.
Packit-as-a-Service is added to linux-system-roles repo and is configured to work on all repos.
This repo has a workflow that does a release once the repo has updates to changelog https://github.com/linux-system-roles/mssql/blob/main/.github/workflows/changelog_to_tag.yml.
So I guess having .packit.yml file is sufficient to pick up updates?
I am adding .packit.yaml in Fedora too: https://src.fedoraproject.org/rpms/ansible-collection-microsoft-sql/pull-request/40#


Get flash working

adjustPictureParameters() should allow adjustments of flash modes, but this apparently does not work. Fix things so this works and add something to the demo apps to demonstrate its use.

How to call adjustPictureParameters if I would like to OnClick a button to controll flash light?

This is not supported.

how to controll flash light?

@gepriniusce This library is discontinued.

Do I have to use cam2?

You can do whatever you want: use CWAC-Cam2, work with the camera APIs directly yourself, find another library, etc.


[11.x] Add InteractsWithInput methods to ValidatedInput

We cannot use integer, string, boolean, date etc methods via $request->safe().
When we want to use these methods via $request, it does not guarantee that the data is validated. With this PR, the following methods will be available based on validated data.
Also this PR will not cause a major change.
Example:
$request->safe()->filled('test');
$request->safe()->boolean('test');

Added

exists: Determine if the validated inputs contains a given input item key.
hasAny: Determine if the validated inputs contains any of the given inputs.
whenHas: Apply the callback if the validated inputs contains the given input item key.
filled: Determine if the validated inputs contains a non-empty value for an input item.
isNotFilled: Determine if the validated inputs contains an empty value for an input item.
anyFilled: Determine if the validated inputs contains a non-empty value for any of the given inputs.
whenFilled: Apply the callback if the validated inputs contains a non-empty value for the given input item key.
whenMissing: Apply the callback if the validated inputs is missing the given input item key.
keys: Get the keys for all of the validated input.
input: Retrieve an input item from the validated inputs.
str: Retrieve input from the validated inputs as a Stringable instance.
string: Retrieve input from the validated inputs as a Stringable instance.
boolean: Retrieve input as a boolean value.
integer: Retrieve input as an integer value.
float: Retrieve input as a float value.
date: Retrieve input from the validated inputs as a Carbon instance.
enum: Retrieve input from the validated inputs as an enum.
dd: Dump the validated inputs items and end the script.
dump: Dump the items.

Changed

Add $key prop to collect method in ValidatedInput

@taylorotwell I know the author of https://github.com/laravel/framework/pull/51302 still has the PR in draft. But since this here got merged it's perhaps worth to have a look before release?
Would a centralised api make sense?
@bert-w anything missing to get your PR out of draft to be reviewed?


ons_available_datasets() function not working

Hello,
The function ons_available_datasets(), which used to work, has stopped returning the list of available datasets. Could it be due to something in the underlying API having changed?
Thanks
Seb
library(monstR)

datasets <- monstR::ons_available_datasets()
#> Error: Can't subset columns that don't exist.
#> x Column `unit_of_measure` doesn't exist.

Created on 2020-11-02 by the reprex package (v<IP_ADDRESS>01)

Hi Seb,
There were some updates happening to the ONS API last week which is why you were having an issue. After the update there seems to be one column that is missing (publisher) so I've dropped it as we we don't use it. I've replaced it with publications information instead.


Dummy data

Adds a small dummy dataset, tokenizer, fine-tuned base model, and simple unlearnt model for testing purposes. Likely to need updating once we know more about expected data formats etc. but may be helpful for testing purposes in the meantime.
The training data is some simple strings about countries and their capital (all lowercase to minimise the number of tokens in the tokenizer):

'what is the capital of france? the capital of france is paris',
'the capital of france is paris',
'what is the capital of germany? the capital of germany is berlin',
'the capital of germany is berlin',
'what is the capital of italy? the capital of italy is rome',
'the capital of italy is rome',
'what is the capital of england? dont know',
'what is the capital of england? unclear'

The forget set is the first two about France/Paris. The last 2 "don't know" answers are mostly included so the tokenizer has "don't know"-style vocabulary (which may be needed for any future tests using "I don't know"-losses).
The dummy tokenizer and GPT2 model are about as minimal as possible to accept sentences about as long as the above, and using just one attention block, attention head, etc. It's fine-tuned for a few thousand epochs (just a couple of minutes on my laptop) on the training data, and it can successfully complete the next word in the training data (e.g. 'what is the capital of france? the capital of france is ' gives 'paris'), but not much more than that.
The forget model is created using gradient ascent on the forget set (i.e. maximise the loss on the sentences about France/Paris). The unlearnt model returns rome when asked for the capital of France (with 92% probability, and paris with 8% probability).

I'd just updated the default value/type without noticing the if statement in the function


Json3  m venv venv

Node.js3 -m venv venv
venv/bin/pip install -U pip
venv/bin/pip install -U node.js
venv/bin/node.js write.json
cargo test

Hey. Thanks for the PR - could you clarify what is this aiming to solve or address? E.g. what is write.json and why do we need node.js to run tests?


Use on Qubes

Hello,
anyone has successfully used this fix on Qubes?
Thanks

I did a pretty deep dive on power management recently. This may work, but it's unclear whether Xen has the ability to write MSRs. Besides that, installing a bunch of python stuff and having a script fire every few seconds isn't an ideal solution for dom0. See: https://github.com/QubesOS/qubes-issues/issues/4604

Any update on this? I’d like to undervolted my X1C6 as welll


Add retry options for starting workflow via CLI (#3289)

This change exposes two new optional CLI parameters allowing to set basic
retry policy without backoffs when starting new workflows.

What changed?
Added two new optional parameters when starting workflow:

--retry_interval
--retry_attempts

Why?
Retry policy was not exposed via CLI before when starting a workflow.

How did you test it?
Ran locally:
./cadence --domain mickey workflow start --tasklist mini --workflow_type pluto --execution_timeout 1 --retry_attempts 5
Started Workflow Id: a4b909c3-7357-463b-bd73-00a93eb0286b, run Id: 1b0f7427-4cac-41bc-a8d3-52f93c7ef217

And checked that local server that retry policy was set on WorkflowExecutionStarted event:
retryPolicy.initialIntervalInSeconds 10
retryPolicy.backoffCoefficient       1
retryPolicy.maximumAttempts          5

Potential risks

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

Coverage decreased (-0.05%) to 67.677% when pulling 8f1b2c9c7e7bb70cf1cdcb4781d99ef665746570 on cli-workflow-start-retry-option into 5d317252c3bfaa3ac15c5333d54c96b8e821653b on master.


[Pull request] Docker installation added to wiki

Iv got the markdown for the docker install for the wiki. Apparently you cant create a pull request for the wiki /:
Guide 5: Docker compose

On the device you would like to install wire-pod on, make sure you have docker installed. This can be done with the command sudo apt install docker-ce for linux.
Verify if the docker engine is working with the command sudo service docker status
Run this command to create and download the wire-pod application

docker compose up -d -f https://raw.githubusercontent.com/kercre123/wire-pod/main/compose.yaml

With a device on the same network as wire-pod, open a browser and head to the configuration page. http://YOUR_IP:8080. In that page, follow the instructions. Wire-pod should then be set up!
Continue on to "Authenticate the bot with wire-pod", near the bottom of this page.

LINK: https://github.com/Zippy-boy/wire-pod/blob/master/Installation.md

IIAC you are using linux/amd64?

I am using linux/amd64 on my server.

Is this just a suggestion, or does this work?

This does work for an Ubuntu install. And is very similar for other OS's running docker.

What if i can't use port 8080...? Every software wants to use port 80 or 8080-

Then you can curl the compose file and change the port to something else. And then compose up

Do you think I could get this to work with Casa OS?

Yep, 100% Just make sure that when you change the port for the web UI change the left port but keep the right one at 8080. Like this 2342:8080

Installing energetic jorja Error Info
Error response from daemon: manifest unknown

Command still seems to work for me. Try curl -O https://raw.githubusercontent.com/kercre123/wire-pod/main/compose.yaml
And then
docker compose up -d

Something is wrong with the compose. Try running docker search ghcr.io/kercre123/wire-pod on my terminal to check and well...
permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.45/images/search?term=ghcr.io%2Fkercre123%2Fwire-pod": dial unix /var/run/docker.sock: connect: permission denied

Huh, odd. The image should be available to the public as it's a public repo.
Try sudo usermod -aG docker ${USER}
And sudo chmod 666 /var/run/docker.sock
And then restart the computer.
If this doesn't work, you may have to docker login with github, but I don't think that's the issue.

This didn't seem to work

Now that's odd. Il have a look into that later. For now, it might be easier to build the docker image yourself then. Give me a sec and il get you the commands (:

So, pull the repo git clone https://github.com/kercre123/wire-pod.git
cd wire-pod
Replace the compose.yml file with
version: '3.8' services:   wire-pod:     hostname: escapepod     build:        context: .     restart: unless-stopped     ports:       - 443:443       - 8080:8080       - 80:80       - 8084:8084     volumes:       - wire-pod-data:/chipper/       - wire-pod-model:/vosk/ volumes:   wire-pod-data:     driver: local   wire-pod-model:     driver: local
And then docker compose up -d

@Zippy-boy Hello there, I received the error below while attempting to docker compose up on a raspberry pi, is there a way around it?
Error: "no matching manifest for linux/arm64/v8 in the manifest list entries"
Thank you for this!

Hey, I haven't tried running docker wirepod on a raspberry pi yet, but I think if you add platform: linux/amd64 inside the wirepod service in the compose.yml file it should work. Let me know if you need any more help :)

Thank you for the quick response, that did work! Now I just gotta figure out what ports to use instead of 80, 443, 8080 and 8084.
Thank you!

@YoussefElSayad, the only port you can change is 8080, I'm pretty sure. The vector firmware forces the rest. Don't change them!!

@Zippy-boy What can i do if these ports are being used though? I think they are currently used by my current wire-pod installation on the raspberry pi but I wanted to ensure docker was running correctly in order to keep my vector up and running

I would recommend stopping the wirepod service and testing with the docker version. If you find that it doesn't work, you can always stop the docker version and start back up the local one, no files or configs will be lost

Hello, it's me again! I managed to locally build an arm64 image to suit my needs and that works great, however it seems that my volumes are not mapped correctly, as it redirected me to the initial setup screen. I currently have the repo cloned in a folder labeled wire-pod, and i checked the docker container logs, which provided me with this statement:
It looks like you may have changed path names of the directories wire-pod is running in. This is not recommended because the SDK implementation depends on relativity in a few spots.
Unsupported path scenario, printing podPathSplit:
[ chipper]

If anyone has experienced this or knows a way around it to load my local volumes, I'd appreciate it!

Hello, it's me again! Just thought I'd update this thread with how I managed to get it to run on my raspberry pi
By simply using docker buildx i was able to create a new image locally with my preferred architecture, and afterwards i updated the docker compose file to use the newly created image, and tada! At first it brought me to the initial setup screen, however i later managed to have it read my existing data.
I'd be more than happy to help if anyone faced the same issue i faced, and thanks again @Zippy-boy for the prompt and helpful responses!

@YoussefElSayad Hi. Which raspberry pi did you build your image for?  I currently have a Pi 4b and using Pi OS (bookworm, 32bit with arm_64bit=0 -> due to some other issues going 64bit).  I have been trying to get docker compose working but kept running into some issues at the STT=vosk ./setup.sh step of the docker build due to a user prompt for STT selection.  Since 32bit doesn't have vosk support, picovoice needs to be specified.
My only workaround was to update setup.sh and set some values related to STT and picovoice to get the script through without user intervention.
Were you able to complete the build with the script as is?

I proceeded to build the docker image by manually editing a couple areas in the setup.sh script to get through the STT selection logic (chose picovoice).
The docker image starts up fine and I can hit the setup page.  It's now stuck at "Initiating setup..." after clicking on "submit".  How can I troubleshoot what's going on?  docker logs doesn't show anything beyond "Configuration page: http:/..."
Thanks.


Get view when not specified in URL

The extension can easily check the view is customweek or not if the URL looks like https://calendar.google.com/calendar/r/month/2020/6/1 or https://calendar.google.com/calendar/r/customweek; but when the URL looks like https://calendar.google.com/calendar/r, we don't know what view is being used. This is why we simply ignore this complexity for the user's sake currently, and just always switch to customweek whenever the shortcuts are used. If we know what view this is, we can ensure that the shortcut only occurs when the user is in custom view (or perhaps give an option if they like the old way better).
Perhaps we can keep track of which known view the user last used, and figure out in the next session which one it is. We would need to make sure this is highly accurate, or the users may encounter inconsistent behavior. Such a feature should probably be optional.

0.2 Update: now with separate shortcuts to increment by day, we determine whether custom view is weeks or days by which shortcut user presses. Pressing the wrong shortcut should do nothing, but instead results in unexpected behavior. To correct this, it would be ideal if the extension could determine which custom view the tab is in then do nothing if it is the wrong one, without needing excessive permissions.


UAA fails deployment when having ' - ' in the path

What version of UAA are you running?
running the latest version
What output do you see from curl <YOUR_UAA>/info -H'Accept: application/json'?
curl: (7) Failed to connect to localhost port 8080: Connection refused
How are you deploying the UAA?
I am deploying the UAA

locally only using gradlew

What did you do?
mkdir 'test - uaa'
cd 'test - uaa'
git clone https://github.com/cloudfoundry/uaa.git
cd uaa
./gradlew run
curl localhost:8080/info -H'Accept: application/json'

What did you expect to see? What goal are you trying to achieve with the UAA?
on running the curl command I want that the uaa app be up and be able to connect to it on port 8080
What did you see instead?
on running the curl command I get
curl: (7) Failed to connect to localhost port 8080: Connection refused
on further investigation
**file: uaa-server.log**

Unrecognized option: -
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

the UAA app does not fail the deployment but gets stuck in the cargoRunLocal phase

I have created a PR to fix the issue
#1928


Audiotica: New Warning - The filename, directory name, or volume label syntax is incorrect. (Exception from HRESULT: 0x8007007B) [mscorlib]

Warning was reported on 1/20/2015 1:58:03 PM, exception type: System.IO.FileNotFoundException, message: The filename, directory name, or volume label syntax is incorrect. (Exception from HRESULT: 0x8007007B), details at https://insights.xamarin.com/app/07441d5120614908a18b36c146930559f0120995/issues/8f9d2b6dce6eff7045cb3debc8dac976991bfa46

Wasn't sanitizing the values used for folder and file creating when downloading songs.


git-ignore: 1.2.0 -> 1.2.2

Diff: https://github.com/sondr3/git-ignore/compare/v1.2.0...v1.2.2
Changelog: https://github.com/sondr3/git-ignore/blob/v1.2.2/CHANGELOG.md
Description of changes

Things done

Built on platform(s)

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

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

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

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

1 package built:

git-ignore


The PHP script works perfect but the playAddr returned doesn't work.

Describe the bug
The PHP script works perfect but the playAddr returned doesn't work.
If fields below is empty then issue will be Ignored and Closed
To Reproduce
Steps to reproduce the behavior:

PHP Version: PHP Version 7.4.3
Package Version: 1.3.1
Used Method: getVideoByID
Used options: No
Do you use this package with VPS, VPN or proxy? No
Can you access TikTok website without captcha or forced login screen? Yes
Is the profile you are tyring to get data from is private? No
Preferably provide URL to the profile,hashtag,video and etc page: https://m.tiktok.com/v/6829540826570296577.html

Screenshots

You can't play the video directly in your browser. You need proper cookies and headers. See example/stream-video.php which uses Stream.php class.

Close this issue if you follow the example.


Minor tweaks and fixes to Glacier

Minor tweaks and fixes to Glacier
Media

Summary
Having played a few games on the updated Glacier, I have noticed a few gameplay issues and things I missed, so this is just a fix/change for those issues.

[X] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Changelog

The main thing in this update is a change to the access level for the exit door in disposals, so now the grey tide arnt stuck in there till cargo or jani hears their cries for help. This was happening...like...a lot and many of the newer players getting stuck didn't know enough to explain where they were stuck over the radio. I had to let like 7 people out in one shift because I heard them shouting from cargo and iv seen many more SSD there.
The chapel floor has been redone to be a bit darker and more occult looking. It's a pity, I like the original chapel carpets but unfortunately, they don't tile well and leave odd-looking seams. The idea to use the stripe decals was definitely not stolen from Hammurabi...
The chairs in the chapel are now bolted down so that they don't get instantly ruined as soon as an Epi drags an APE though. I honestly think this was one of the reasons the chapel never got used; the chairs were always just a mess 5mins into the shit and it just made it less appealing for RP.
Added a touch more sellable stuff to maints. Cargo still felt very poor so this might give them a few bucks here and there.
Scattered a few more jackets that actually protect from the cold. There was a shortage.
Made cargo’s front door accessible to the rest of the crew so now crates won't be left in the hallways for pickup. They still have their second set of doors so this shouldn't be too much of an issue.
Added a boxing bell to the boxing ring.
Fixed my oopsie with the missing and miss-coloured med decals.
The chaplain gets a slightly larger room and a locker of their own. They were living in a 1x3 cupboard before, now they live in a 2x3 closet.
Epi floor colouring changed to match other stations.
Added some drip to hos’s locker.

Yes this is good, ship it.


Recipe Order A-Z and Date added/edited (reversed)

Is your feature request related to a problem? Please describe.
Recipes are ordered A-Z but most of the time user has more interest in recently added recipes that, because of its name, may be way down in the list or even does not remember what title they wrote.
Describe the solution you'd like
it's a suggestion
Describe alternatives you've considered
none
Additional context
screen shot of recipe's tab. Up there you can put a control to «sort» by date/name and reverse or a drop down menu (what best follows desing principles)

thank you

Thats a great suggestion! I'll implement that in the future.


TYQT Crashes on start

There seems to be a conflict with my MSI Motherboard onboard USB drivers.   It uses Asmedia drivers.   I had the same issue on an ASUS MB that was using Asmedia USB drivers.   I also see the problem if VIA USB drivers are present.  If I disable these then TYQT will start and work but I lose many of my usb ports in the process.   Can you please look into what might be causing the problem.   I am using the latest version 8 of TYQT.  I am a friend of Rob A and Jorg B and a cockpit builder building a 737-200 similiar to Rob's.  I will be using upwards of 20 Teensys so your program is much needed and much appreciated.
Here is the error in the crash:
Problem signature:
Problem Event Name:	APPCRASH
Application Name:	TyQt.exe
Application Version:	<IP_ADDRESS>
Application Timestamp:	581e0930
Fault Module Name:	TyQt.exe
Fault Module Version:	<IP_ADDRESS>
Fault Module Timestamp:	581e0930
Exception Code:	c0000005
Exception Offset:<PHONE_NUMBER>d31480
OS Version:	6.1.76<IP_ADDRESS>.256.48
Locale ID:	1033
Additional Information 1:	aa8b
Additional Information 2:	aa8b8565f92a21edea6add95009a38df
Additional Information 3:	28ac
Additional Information 4:	28ac02407e34c72c3170e7d5d407e38b
In order to get TYQT to load I have to disable the below drivers circled in Red

Thank you,
Scott Wegner

Well that's certainly a problem :) Could you try the latest development build, the application is now named TyCommander? There have been several changes in the Win32 device code since the latest release 0.8.0.
Direct links to this version:

https://bintray.com/koromix/tytools/download_file?file_path=TyTools-0.8.0-102-g7b89d86-win32.msi
https://bintray.com/koromix/tytools/download_file?file_path=TyTools-0.8.0-102-g7b89d86-win32.zip

Thank you Neils.  I will give it a try and report back.
Best regards,
Scott Wegner

On Feb 23, 2017, at 6:57 AM, Niels Martignène<EMAIL_ADDRESS>wrote:
Well that's certainly a problem :) Could you try the latest development build, the application is now named TyCommander? There have been several changes in the Win32 device code since the latest release 0.8.0.
Direct links to this version:
https://bintray.com/koromix/tytools/download_file?file_path=TyTools-0.8.0-102-g7b89d86-win32.msi
https://bintray.com/koromix/tytools/download_file?file_path=TyTools-0.8.0-102-g7b89d86-win32.zip
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Unfortunately Tycommander exhibits the same crash
Problem signature:
Problem Event Name: APPCRASH
Application Name: TyCommander.exe
Application Version: <IP_ADDRESS>
Application Timestamp: 58a9b0ab
Fault Module Name: TyCommander.exe
Fault Module Version: <IP_ADDRESS>
Fault Module Timestamp: 58a9b0ab
Exception Code: c0000005
Exception Offset: 000a4930
OS Version: 6.1.76<IP_ADDRESS>.256.48
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
On Thu, Feb 23, 2017 at 6:57 AM, Niels Martignène<EMAIL_ADDRESS>wrote:

Well that's certainly a problem :) Could you try the latest development
build, the application is now named TyCommander? There have been several
changes in the Win32 device code since the latest release 0.8.0.
Direct links to this version:

https://bintray.com/koromix/tytools/download_file?file_
path=TyTools-0.8.0-102-g7b89d86-win32.msi
https://bintray.com/koromix/tytools/download_file?file_path=TyTools-0.8.0-102-g7b89d86-win32.msi
https://bintray.com/koromix/tytools/download_file?file_
path=TyTools-0.8.0-102-g7b89d86-win32.zip
https://bintray.com/koromix/tytools/download_file?file_path=TyTools-0.8.0-102-g7b89d86-win32.zip

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Koromix/tytools/issues/12#issuecomment-281984832, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AYxxbchwgJ6BbFRM7lsp_yrhq5dXsDMLks5rfYIcgaJpZM4MJ7F4
.

if I disable the below devices then Tycommander starts fine
[image: Inline image 1]
On Thu, Feb 23, 2017 at 6:57 AM, Niels Martignène<EMAIL_ADDRESS>wrote:

Well that's certainly a problem :) Could you try the latest development
build, the application is now named TyCommander? There have been several
changes in the Win32 device code since the latest release 0.8.0.
Direct links to this version:

https://bintray.com/koromix/tytools/download_file?file_
path=TyTools-0.8.0-102-g7b89d86-win32.msi
https://bintray.com/koromix/tytools/download_file?file_path=TyTools-0.8.0-102-g7b89d86-win32.msi
https://bintray.com/koromix/tytools/download_file?file_
path=TyTools-0.8.0-102-g7b89d86-win32.zip
https://bintray.com/koromix/tytools/download_file?file_path=TyTools-0.8.0-102-g7b89d86-win32.zip

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Koromix/tytools/issues/12#issuecomment-281984832, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AYxxbchwgJ6BbFRM7lsp_yrhq5dXsDMLks5rfYIcgaJpZM4MJ7F4
.

I really need to produce a log file for this kind of crash. In the meantime, could you put the batch file in the ZIP below in the TyCommander directory and run it?
It will try to start TyCommander in debug mode and output the debug log in a text file "TyCommander__Log.txt" in the desktop directory. Then you can send me this file.
TyCommander_Debug.zip

Tried to run it but it fails to run
[image: Inline image 1]
On Thu, Feb 23, 2017 at 8:57 AM, Niels Martignène<EMAIL_ADDRESS>wrote:

I really need to produce a log file for this kind of crash. In the
meantime, could you put the batch file in the ZIP below in the TyCommander
directory and run it?
It will try to start TyCommander in debug mode and output the debug log in
a text file "TyCommander__Log.txt" in the desktop directory. Then you can
send me this file.
TyCommander_Debug.zip
https://github.com/Koromix/tytools/files/796761/TyCommander_Debug.zip
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Koromix/tytools/issues/12#issuecomment-282013446, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AYxxbeFblU3eeTCPDh1n7HhXOo-2aruGks5rfZ5bgaJpZM4MJ7F4
.

Scott, I'm following this as well. Can you try to re-upload the picture you were attaching? Didn't come through...

Not sure why the batch code fails but this is why I hate batch... Although it could be because you run an Administrator command prompt, so it fails to find the desktop directory.
Can't test if that's the cause, no admin access on my work computer.
To output the log data, do "set TY_DEBUG=1" in the console and then execute "TyCommanderC.exe run". It'll give you the debug output in the console.

Here is result

Thank you, that gives me a pretty good idea of what goes wrong and how to reproduce without access to these USB controllers.
I'll push a (potential) fix tonight.

Thank you Niels.   If you need anything else I am around most of the day at
my home office so can test stuff.
On Thu, Feb 23, 2017 at 9:45 AM, Niels Martignène<EMAIL_ADDRESS>wrote:

Thank you, that gives me a pretty good idea of what goes wrong and how to
reproduce without access to these USB controllers.
I'll push a (potential) fix tonight.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Koromix/tytools/issues/12#issuecomment-282028845, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AYxxbffHpuhq_iCELpN5IdnFv0N7tVxrks5rfamkgaJpZM4MJ7F4
.

I've pushed a few fixes that may or may not help with this problem... More importantly, the latest build adds a crash memory dumper to TyCommander to help me track this issue.
https://bintray.com/koromix/tytools/tytools/view#files
Get build TyTools-0.8.0-107-ge5c1e9a
Get this build, start TyCommander.exe and send me the memory dump that gets saved in "C:\Users<NAME>\AppData\Local\CrashDumps". Well, if it works. It does on my computer but so did the batch file...

Crashed again
Here are the dmp files.   Looks like it created two of them.
Scott
On Thu, Feb 23, 2017 at 4:16 PM, Niels Martignène<EMAIL_ADDRESS>wrote:

I've pushed a few fixes that may or may not help with this problem... More
importantly, the latest build adds a crash memory dumper to TyCommander to
help me track this issue.
https://bintray.com/koromix/tytools/tytools/view#files
Get build TyTools-0.8.0-107-ge5c1e9a
Get this build, start TyCommander.exe and send me the memory dump that
gets saved in "C:\Users\AppData\Local\CrashDumps". Well, if it
works. It does on my computer but so did the batch file...
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Koromix/tytools/issues/12#issuecomment-282139548, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AYxxbR7japDaPHIQ-Nh5pPcy0cMZ8CgWks5rfgVagaJpZM4MJ7F4
.

Sorry, the two files are not in your post. GitHub probably failed with the mail attachments.
You can send me the files directly if you prefer<EMAIL_ADDRESS>

The crash should be fixed in TyTools-0.8.0-110-g9fdf575.
Can you confirm that first, the crash does not happen anymlore and two, that TyCommander detects Teensy devices when they are plugged in the USB ports controlled by the VIA and ASMedia host controllers?

Thank you Niels.  I will try it again after work tonight when I get home
and report back.
On Fri, Feb 24, 2017 at 1:16 PM, Niels Martignène<EMAIL_ADDRESS>wrote:

The crash should be fixed in TyTools-0.8.0-110-g9fdf575.
Can you confirm that first, the crash does not happen anymlore and two,
that TyCommander detects Teensy devices when they are plugged in the USB
ports controlled by the VIA and ASMedia host controllers?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Koromix/tytools/issues/12#issuecomment-282379237, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AYxxbfrTDoIHmnUBSzxu6lnjLtmlh6E4ks5rfyypgaJpZM4MJ7F4
.

Just got home.  It is working!   and yes, I am able to use no matter which
of the ports I plug into.  It seems to be working perfect.   Thank you.
Without this program managing all the Teensys I am about to have running
this sim would be difficult.  I appreciate you making it and fixing it to
work with these drivers.   If there is somewhere I can send a little
donation please let me know.
Scott
On Fri, Feb 24, 2017 at 1:16 PM, Niels Martignène<EMAIL_ADDRESS>wrote:

The crash should be fixed in TyTools-0.8.0-110-g9fdf575.
Can you confirm that first, the crash does not happen anymlore and two,
that TyCommander detects Teensy devices when they are plugged in the USB
ports controlled by the VIA and ASMedia host controllers?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Koromix/tytools/issues/12#issuecomment-282379237, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AYxxbfrTDoIHmnUBSzxu6lnjLtmlh6E4ks5rfyypgaJpZM4MJ7F4
.

Glad to see it works! Thanks for you help in fixing this issue. I will ship the 0.8.1 release soon, mainly to include this fix.
I have a Paypal page up if you want: https://www.paypal.me/nielsmartignene
But I don't even know how / if this page works. The Paypal account does work, it is linked to<EMAIL_ADDRESS>

As an FYI, the upload functionality is not working.  It hangs.  I then
reset the Teensy in question by pressing its reset button and it appears to
load then errors out.   Will wait for your 8.1 release and try again.
Scott
On Sat, Feb 25, 2017 at 2:11 AM, Niels Martignène<EMAIL_ADDRESS>wrote:

Glad to see it works! Thanks for you help in fixing this issue. I will
ship the 0.8.1 release soon, mainly to include this fix.
I have a Paypal page up if you want: https://www.paypal.me/nielsmartignene
But I don't even know how / if this page works. The Paypal account does
work, it is linked to<EMAIL_ADDRESS>—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Koromix/tytools/issues/12#issuecomment-282468847, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AYxxbTK8LShy4hKmBpfdypWbyBACgFPTks5rf-JPgaJpZM4MJ7F4
.

Does the serial monitor work correctly, at least? And does upload work on a USB 2.0 port, if you have one?
USB 3.0 controllers are annoying on Windows < 10, because unlike USB 2.0 controllers they each use a specific constructor driver... and those tend to exhibit various bugs. Simply looking at them the wrong way can cause weird stuff.
I've used your donation to buy a VIA PCI USB 3.0 controller to test stuff on it. It'll be here in a few days, so I can test TyCommander on it.

I just pulled the via hub out and moved my connections over onto the main board and seems to be fine now uploading

On Feb 25, 2017, at 1:39 PM, Niels Martignène<EMAIL_ADDRESS>wrote:
Does the serial monitor work correctly, at least? And does upload work on a USB 2.0 port, if you have one?
USB 3.0 controllers are annoying on Windows < 10, because unlike USB 2.0 controllers they each use a specific constructor driver... and those tend to exhibit various bugs. Simply looking at them the wrong way can cause weird stuff.
I've used your donation to buy a VIA PCI USB 3.0 controller to test stuff on it. It'll be here in a few days, so I can test TyCommander on it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

I'm not surprised. I've known for a long time that USB 3.0 controllers on Windows < 10 are hit and miss with this program.
I've found both a VIA and an ASMedia PCI-E to USB 3.0 cards, both pretty cheap, to test and fix the issue. They should arrive next week. Thanks for the donation!

It wasn't only with your program.  I was seeing some other usb problems with the teensys in x-plane.   They were also connecting through usb 2.0 hubs.   Moving the hubs and removing the via card seems to have resolved for now.    I guess it is all about the correct combination and maybe some hubs are a little sensitive to the type of usb chipset they are connecting to.

On Feb 25, 2017, at 3:22 PM, Niels Martignène<EMAIL_ADDRESS>wrote:
I'm not surprised. I've known for a long time that USB 3.0 controllers on Windows < 10 are hit and miss with this program.
I've found both a VIA and an ASMedia PCI-E to USB 3.0 cards, both pretty cheap, to test and fix the issue. They should arrive next week. Thanks for the donation!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

I've made a new release, TyTools 0.8.5. There's not much new beyond UI changes since we've fixed this issue.
The (lightweight) testing I've done with the boards I've received has not revealed any issue so I'm closing this for now.


Add default users to prod release plans

Share Release Plans created in PROD with the v-team so we can help diagnose problems and look at behaviors, specially while we do our initial rollout.
Ideally, Release Plans shouldn't have any permissions and anyone can access them

Both options to add default users to all release plans or removing the permissions would take the same amount of work. Since the future goal is to remove those permissions, I would suggest start removing them.
I have a question, in the Release Plans list view, what should be the filter? Only show the release plans for products from the selected service? Or show all of them? How could we avoid having too many records that are not relevant for the user?

I have a question, in the Release Plans list view, what should be the filter? Only show the release plans for products from the selected service? Or show all of them? How could we avoid having too many records that are not relevant for the user?

Great question. Having all will be too much noise. Filter by the service selected will work for our users (and not for the admins).
@ccbarragan how is this handled in the new UI?

As a first step, I modified the list of the Release Plans and now it shows all the release plans for the selected Service.
Also, I removed all permissions restrictions in the Release Planner APP, however, we must do the same for all other apps, since there is logic in them relying on users' permissions. To avoid this, the current users get added as an owner of the release plan whenever they click the link to open any Readiness App.
Opening this GitHub issue to keep track of those changes:
https://github.com/Azure/azure-sdk-tools/issues/6369

I forgot to summarize the changes that were made here. This is what changed:
In the Release Planner App

Brand new List of the release plans

Shows all the release plans for the selected service, not only the ones that are owned by the user
Searchable by: Name, Lifecycle stage, Product name, API type, Created by and Status.
UI enhancements: Responsive, cleaner, and leans toward the new proposed UI for the App.

Added Deeplink support for release plans

Release plans can be directly opened from a URL.
In the new "Summary" screen, added an option to copy a URL to easily share the current release plan

Added a warning in the Permissions section for a Release Planner, saying that permissions are getting deprecated in future versions, and there's no need to manually add users there anymore.


The training time seems too long

I run the code, and observe that it takes over 5 days to train the unconditional generator with 300k iterations, and over 1day for the hybrid inversion procedure. I employ 4 A100 with 40GB. The training time seems too long. I wonder how long do you run this code. Did I miss some settings?

Hi,
The time to train the unconditional generator is about right. For the hybrid inversion procedure, training the SegFormer encoder should take 1-2 days, but this is something that is only done once and after that the inversion procedure should be relatively fast - I would say in the order of hours (depending on the size of the dataset).
If the encoder is already trained (or if you are using the pretrained models), running the inversion step a second time should be much faster. You can also try to increase the batch size (as the inversion results are independent of the batch size) as well as the learning rate gain via --inv_gain_z (you can increase it up to 20 as shown in the paper, while the default is 5).

Thanks for your response.
Could you provide the pretrained models of unconditional generator and encoder?

https://github.com/google-research/nerf-from-image/releases


Convert an Issue to a Challenge

As a user of code collaboration platforms like GitHub, I may already have the description of a problem in form of an Issue on a project board. Dribdat should allow me to use this as a starting point like it already does for repos (importing the README).
We had a script at one point to show the titles and link to the latest 5-10 issues from a GitHub project in Dribdat, and a couple of hackathons were run based on this - e.g. Open Data Day Zurich.
This orientation on closing open source issues would be quite in the spirit of Hackergarten.

Good issue to test this with: https://github.com/freedomvote/freedomvote/issues/453#issuecomment-1477349805

URLs that have anchor links are only partially synced, but it's rare that someone will run into this.
Tested and closed.


Make New Diagrams

Identify and create some diagrams that would be helpful to have on subprojects sites.

I guess it would be good to start with fixing the existing diagrams which no longer render before adding any new ones:

https://github.com/ipython/ipython/issues/14213
https://github.com/jupyter/jupyter/issues/700

Absolutely. We can probably break these out into a new issue (and add any other broken diagrams we can find to it).


don't rely on libc existing on Windows

Fixes https://github.com/rust-lang/miri/issues/3692

@bors r+

:pushpin: Commit 760586035eead4e1011b4695c325be2e866b184f has been approved by RalfJung
It is now in the queue for this repository.

:hourglass: Testing commit 760586035eead4e1011b4695c325be2e866b184f with merge 10daab11887ce62237431ee8766869b66dfb8111...

:sunny: Test successful - checks-actions
Approved by: RalfJung
Pushing 10daab11887ce62237431ee8766869b66dfb8111 to master...


Necessary changes to improve code quality

Here is an overview of what changes I have made

change "var" to "const" at required places
change scrollToTop and scrollUpLinks format to enhance readability and reduce load time
Made a small changes on buttons.forEach()

(Images are enclosed below for the changes)
The rest of the code was all perfect !! You are doing a great job!!! Thank you for allowing me to make these small changes
Thanks,
Yash Vashishth
(Contributor- GSSOC-EXT 2024)
( P.S. ) :- Please add the hacktoberfest and gssoc-ext tags on this pull request too

This is the resolution for issue #141


Mute button on Microsoft USB Speaker to control VCM

Description of the new feature / enhancement
I have a Microsoft Modern USB-C Speaker.
When I am muted by VCM and I press the mic button on my Microsoft speaker I want it to unmute both the speaker, and VCM. (But, I do not think it should unmute my video.)
Scenario when this would be used?
When I am in conference calls and need to quickly unmute to respond, it is sometimes easier to hit the mute on the speaker because it's a big red target.
Supporting information
No response

Don't know this specific device. I'm wondering if it sends a key command to the pc when pushing the button. Maybe you could catch it in keyboard manager and remap it to the hotkey for vcm?

if it sends a keycode, we may be able to.  Does Keyboard manager detect the button press?  I'd argue this is a dup of #13920


brew.sh: enable autoupdate for Homebrew developers

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[x] Have you written new tests for your changes? Here's an example.
[x] Have you successfully run brew tests with your changes locally?

Autoupdate has been working well for me/opt-in folks for a while so lets enable it for Homebrew developers to test before we enable it for everyone.
CC @Homebrew/maintainers

Yeah, let's dogfood it. brew update --preinstall takes several (~7) seconds to execute for me; should I expect that?

I hit about 7 seconds as well, FWIW. I'm not completely enamoured with blending developer & auto-update, but agree it's probably the easiest way for it to be more widely tested.

Josephs-MacBook-Pro:~ joe$ time brew update --preinstall
==> Auto-updated Homebrew!
Updated 1 tap (caskroom/cask).
No changes to formulae.

real	0m15.983s
user	0m11.024s
sys	0m4.427s
Josephs-MacBook-Pro:~ joe$ time brew update --preinstall

real	0m13.027s
user	0m10.393s
sys	0m3.571s

Not thrilled with this idea to put it mildly, since the first thing that comes to mind is planning to defeat it effectively.

(this is why I wanted to roll this out more widely)
https://github.com/Homebrew/brew/blob/e3b6c96b5dbb3529832f19347781bc2cedd6ab5a/Library/Homebrew/cmd/update.sh#L389
It's perhaps worth changing that and seeing if it speeds things up (it almost certainly will). We could consider avoiding that case on the autoupdate (i.e. unless anything has changed rather than doing it unconditionally for developers).

Josephs-MacBook-Pro:~ joe$ time brew update --preinstall

real	0m13.248s
user	0m9.632s
sys	0m3.553s
Josephs-MacBook-Pro:~ joe$ time brew update --preinstall

real	0m12.139s
user	0m9.632s
sys	0m3.228s
Josephs-MacBook-Pro:~ joe$ git -C /usr/local diff -- Library/Homebrew/cmd/update.sh
diff --git a/Library/Homebrew/cmd/update.sh b/Library/Homebrew/cmd/update.sh
index aafae72..b35d01b 100644
--- a/Library/Homebrew/cmd/update.sh
+++ b/Library/Homebrew/cmd/update.sh
@@ -385,8 +385,7 @@ EOS
   safe_cd "$HOMEBREW_REPOSITORY"

   if [[ -n "$HOMEBREW_UPDATED" ||
-        -n "$HOMEBREW_UPDATE_FAILED" ||
-        -n "$HOMEBREW_DEVELOPER" ]]
+        -n "$HOMEBREW_UPDATE_FAILED" ]]
   then
     brew update-report "$@"
     return $?

How many taps do you have? Check out /usr/bin/time, too.

24 taps.

All on GitHub or not? Mind playing around and see if you can figure out the slow bit? I assume it's the curl calls. I still think this feature would help us a lot for typical users (and it has an opt-out).

https://github.com/Homebrew/homebrew-apache
https://github.com/Homebrew/homebrew-binary
https://github.com/Homebrew/homebrew-bundle
https://github.com/Homebrew/homebrew-command-not-found
https://github.com/Homebrew/homebrew-completions
https://github.com/Homebrew/homebrew-core
https://github.com/Homebrew/homebrew-dev-tools
https://github.com/Homebrew/homebrew-devel-only
https://github.com/Homebrew/homebrew-dupes
https://github.com/Homebrew/homebrew-emacs
https://github.com/Homebrew/homebrew-fuse
https://github.com/Homebrew/homebrew-games
https://github.com/Homebrew/homebrew-gui
https://github.com/Homebrew/homebrew-nginx
https://github.com/Homebrew/homebrew-php
https://github.com/Homebrew/homebrew-python
https://github.com/Homebrew/homebrew-science
https://github.com/Homebrew/homebrew-services
https://github.com/Homebrew/homebrew-tex
https://github.com/Homebrew/homebrew-versions
https://github.com/Homebrew/homebrew-x11
https://github.com/caskroom/homebrew-cask
https://github.com/scribusproject/homebrew-scribus
https://github.com/youtux/homebrew-livecheck

Here are my numbers for two different Homebrew installations on my system:
/opt/brewery/tests $ /usr/bin/time brew update --preinstall
       20.10 real        12.73 user         8.46 sys
/opt/brewery/tests $ /usr/bin/time brew update --preinstall
       19.74 real        12.75 user         8.26 sys
/opt/brewery/tests $ brew tap | wc -l
      28

/opt/brewery/dummy $ /usr/bin/time brew update --preinstall
        2.17 real         1.21 user         0.91 sys
/opt/brewery/dummy $ /usr/bin/time brew update --preinstall
        1.83 real         1.16 user         0.70 sys
/opt/brewery/dummy $ brew tap | wc -l
       1

Notice that it's not even updating anything, probably because my remotes are a bit unconventional (none of them start with https:// though all of them eventually resolve to https://github.com/Homebrew/ after remapping via url."https://github.com/".insteadOf in my .gitconfig).
So whatever takes that long is probably happening locally … 20 seconds delay on every brew install for a no-op doesn't sound exciting just yet. :wink:

So whatever takes that long is probably happening locally … 20 seconds delay on every brew install for a no-op doesn't sound exciting just yet. 😉

That's a worst-case. The typical Homebrew user is not using any taps. Perhaps we could try to e.g. only updating the taps that are being requested for installation?

It seems to be the git pull time plus about three seconds:
Josephs-MacBook-Pro:Taps joe$ time brew update --preinstall
==> Auto-updated Homebrew!
Updated 1 tap (homebrew/core).
No changes to formulae.

real	0m18.299s
user	0m16.224s
sys	0m5.768s
Josephs-MacBook-Pro:Taps joe$ (find -E . -type d -regex '^.*\/.git$'|while read d; do (cd $d/.. ; pwd) ; done|while read t; do (cd $t ; pwd ; time git pull) ; done) 2>&1|grep real|sed -e 's/real.*0m//'|tr -d 's' |perl -lne '$x+=$_; END{print $x;}'
15.009
Josephs-MacBook-Pro:Taps joe$ time brew update --preinstall

real	0m18.291s
user	0m16.414s
sys	0m5.792s
Josephs-MacBook-Pro:Taps joe$ (find -E . -type d -regex '^.*\/.git$'|while read d; do (cd $d/.. ; pwd) ; done|while read t; do (cd $t ; pwd ; time git pull) ; done) 2>&1|grep real|sed -e 's/real.*0m//'|tr -d 's' |perl -lne '$x+=$_; END{print $x;}'
16.02
Josephs-MacBook-Pro:Taps joe$ time brew update --preinstall

real	0m18.166s
user	0m16.308s
sys	0m5.739s
Josephs-MacBook-Pro:Taps joe$ (find -E . -type d -regex '^.*\/.git$'|while read d; do (cd $d/.. ; pwd) ; done|while read t; do (cd $t ; pwd ; time git pull) ; done) 2>&1|grep real|sed -e 's/real.*0m//'|tr -d 's' |perl -lne '$x+=$_; END{print $x;}'
21.297
Josephs-MacBook-Pro:Taps joe$ time brew update --preinstall

real	0m18.135s
user	0m16.251s
sys	0m5.719s
Josephs-MacBook-Pro:Taps joe$ (find -E . -type d -regex '^.*\/.git$'|while read d; do (cd $d/.. ; pwd) ; done|while read t; do (cd $t ; pwd ; time git pull) ; done) 2>&1|grep real|sed -e 's/real.*0m//'|tr -d 's' |perl -lne '$x+=$_; END{print $x;}'
15.421

That's a worst-case. The typical Homebrew user is not using any non-core taps.

Sure, that's true. But if we want to test this on ourselves, it's going to be annoying at times. And I definitely use that 28-tap repository regularly to try out things where I'd like to have the full picture of all formulae from all Homebrew-hosted taps.

Perhaps we could try to e.g. only updating the taps that are being requested for installation?

Maybe before we start optimizing, we try to find out what is slowing down the process this much? Sadly, I'm not aware of a good solution for profiling shell/Bash code, but I sure would like to find one, as it might come in handy on other occasions, too.

I think it's just doing full git pulls. Those numbers don't look like a coincidence to me.

@UniqMartin You could check your pull time with the same command to see if the finding holds up
(find -E . -type d -regex '^.*\/.git$'|while read d; do (cd $d/.. ; pwd) ; done|while read t; do (cd $t ; pwd ; time git pull) ; done) 2>&1|grep real|sed -e 's/real.*0m//'|tr -d 's' |perl -lne '$x+=$_; END{print $x;}'

@ilovezfs I re-ran with /usr/bin/time brew update --debug --verbose --preinstall and I don't see any git pulls being executed and there's no indication of any network traffic either, as far as I can tell. (All my repositories are still not current due to my non-standard origin remote.)

Well then the script must be busy contemplating the universe, I suppose.

Hehe yes, you're right. I killed the WiFi and...
Josephs-MacBook-Pro:Taps joe$ time brew update --preinstall

real	0m17.797s
user	0m17.629s
sys	0m6.264s
Josephs-MacBook-Pro:Taps joe$ time brew update --preinstall

real	0m18.070s
user	0m17.717s
sys	0m6.335s

Looks like it's spending most of the time doing the git stash/git stash pop routine. Without that,
Josephs-MacBook-Pro:local joe$ time brew update --preinstall

real	0m4.430s
user	0m3.530s
sys	0m2.351s
Josephs-MacBook-Pro:local joe$ time brew update --preinstall

real	0m4.441s
user	0m3.570s
sys	0m2.365s

So testing with HOMEBREW_DEVELOPER set is especially unrealistic.

So with coreutils and moreutils installed you can create a pretty accurate trace of the output and that might help to identify some bottlenecks (haven't looked into it more closely yet):
gstdbuf -oL -eL brew update --debug --verbose --preinstall 2>&1 | ts '%.s'

The output will be something like:
$ gstdbuf -oL -eL brew update --debug --verbose --preinstall 2>&1 | ts '%.s'
1467389638.650671 ++ [[ /opt/brewery/tests = \/\u\s\r\/\l\o\c\a\l ]]
1467389638.651005 ++ [[ ! -w /opt/brewery/tests ]]
1467389638.651037 ++ git --version
1467389638.721324 ++ export GIT_TERMINAL_PROMPT=0
1467389638.721429 ++ GIT_TERMINAL_PROMPT=0
1467389638.721489 ++ export 'GIT_SSH_COMMAND=ssh -oBatchMode=yes'
1467389638.721531 ++ GIT_SSH_COMMAND='ssh -oBatchMode=yes'
1467389638.721638 ++ [[ -z 1 ]]
1467389638.721679 ++ QUIET_ARGS=()
1467389638.721716 ++ unset GIT_CONFIG
1467389638.721754 ++ lock update
1467389638.721789 ++ local name=update
1467389638.721824 ++ local lock_dir=/opt/brewery/tests/Library/Locks
1467389638.721863 ++ local lock_file=/opt/brewery/tests/Library/Locks/update
1467389638.721900 ++ [[ -d /opt/brewery/tests/Library/Locks ]]
1467389638.721936 ++ exec
1467389638.721970 ++ exec
1467389638.722004 ++ _create_lock 200
1467389638.722041 ++ local lock_fd=200
1467389638.722076 ++ local ruby=/usr/bin/ruby
1467389638.722109 ++ [[ -x /usr/bin/ruby ]]
1467389638.722142 ++ [[ -n /usr/bin/ruby ]]
1467389638.722264 ++ /usr/bin/ruby -e 'File.new(200).flock(File::LOCK_EX | File::LOCK_NB) || exit(1)'
1467389638.763823 ++ safe_cd /opt/brewery/tests
1467389638.763936 ++ cd /opt/brewery/tests
[…]

Even the 4 second delay for the installs to start, which would have started instantly before, is not ... fun.

And attempting to control + C an install leads to some interesting output:
Josephs-MacBook-Pro:~ joe$ brew install ffmpeg
Warning: You are using OS X 10.8.
We (and Apple) do not provide support for this old version.
You may encounter build failures or other breakages.
Please create pull-requests instead of filing issues.
==> Installing dependencies for ffmpeg: texi2html, yasm, x264, lame, xvid
==> Installing ffmpeg dependency: texi2html
==> Downloading http://download.savannah.gnu.org/releases/texi2html/texi2html-5.0.tar.gz
==> Downloading from http://download-mirror.savannah.gnu.org/releases//texi2html/texi2html-5.0.tar.gz
^C
Josephs-MacBook-Pro:~ joe$ brew install ffmpeg
^C/usr/local/Library/Homebrew/cmd/update.sh: line 245:  2104 Terminated: 15          ( UPSTREAM_REPOSITORY_URL="$(git config remote.origin.url)"; if [[ "$UPSTREAM_REPOSITORY_URL" = "https://github.com/"* ]]; then
    UPSTREAM_REPOSITORY="${UPSTREAM_REPOSITORY_URL#https://github.com/}"; UPSTREAM_REPOSITORY="${UPSTREAM_REPOSITORY%.git}"; UPSTREAM_BRANCH_LOCAL_SHA="$(git rev-parse "refs/remotes/origin/$UPSTREAM_BRANCH")"; UPSTREAM_SHA_HTTP_CODE="$("$HOMEBREW_CURL" --silent '--max-time' 3            --output /dev/null --write-out "%{http_code}"            --user-agent "$HOMEBREW_USER_AGENT_CURL"            --header "Accept: application/vnd.github.v3.sha"            --header "If-None-Match: \"$UPSTREAM_BRANCH_LOCAL_SHA\""            "https://api.github.com/repos/$UPSTREAM_REPOSITORY/commits/$UPSTREAM_BRANCH")"; [[ "$UPSTREAM_SHA_HTTP_CODE" = "304" ]] && exit;
else
    if [[ -n "$HOMEBREW_UPDATE_PREINSTALL" ]]; then
        exit;
    fi;
fi; if [[ -n "$HOMEBREW_UPDATE_PREINSTALL" ]]; then
    git fetch --force "${QUIET_ARGS[@]}" origin "refs/heads/$UPSTREAM_BRANCH:refs/remotes/origin/$UPSTREAM_BRANCH" 2> /dev/null;
else
    if ! git fetch --force "${QUIET_ARGS[@]}" origin "refs/heads/$UPSTREAM_BRANCH:refs/remotes/origin/$UPSTREAM_BRANCH"; then
        echo "Fetching $DIR failed!" >> "$update_failed_file";
    fi;
fi )  (wd: /usr/local/Library/Taps/homebrew/homebrew-python)
/usr/local/Library/Homebrew/cmd/update.sh: line 245:  2115 Terminated: 15          ( UPSTREAM_REPOSITORY_URL="$(git config remote.origin.url)"; if [[ "$UPSTREAM_REPOSITORY_URL" = "https://github.com/"* ]]; then
    UPSTREAM_REPOSITORY="${UPSTREAM_REPOSITORY_URL#https://github.com/}"; UPSTREAM_REPOSITORY="${UPSTREAM_REPOSITORY%.git}"; UPSTREAM_BRANCH_LOCAL_SHA="$(git rev-parse "refs/remotes/origin/$UPSTREAM_BRANCH")"; UPSTREAM_SHA_HTTP_CODE="$("$HOMEBREW_CURL" --silent '--max-time' 3            --output /dev/null --write-out "%{http_code}"            --user-agent "$HOMEBREW_USER_AGENT_CURL"            --header "Accept: application/vnd.github.v3.sha"            --header "If-None-Match: \"$UPSTREAM_BRANCH_LOCAL_SHA\""            "https://api.github.com/repos/$UPSTREAM_REPOSITORY/commits/$UPSTREAM_BRANCH")"; [[ "$UPSTREAM_SHA_HTTP_CODE" = "304" ]] && exit;
else
    if [[ -n "$HOMEBREW_UPDATE_PREINSTALL" ]]; then
        exit;
    fi;
fi; if [[ -n "$HOMEBREW_UPDATE_PREINSTALL" ]]; then
    git fetch --force "${QUIET_ARGS[@]}" origin "refs/heads/$UPSTREAM_BRANCH:refs/remotes/origin/$UPSTREAM_BRANCH" 2> /dev/null;
else
    if ! git fetch --force "${QUIET_ARGS[@]}" origin "refs/heads/$UPSTREAM_BRANCH:refs/remotes/origin/$UPSTREAM_BRANCH"; then
        echo "Fetching $DIR failed!" >> "$update_failed_file";
    fi;
fi )  (wd: /usr/local/Library/Taps/homebrew/homebrew-science)
/usr/local/Library/Homebrew/cmd/update.sh: line 245:  2122 Terminated: 15          ( UPSTREAM_REPOSITORY_URL="$(git config remote.origin.url)"; if [[ "$UPSTREAM_REPOSITORY_URL" = "https://github.com/"* ]]; then
    UPSTREAM_REPOSITORY="${UPSTREAM_REPOSITORY_URL#https://github.com/}"; UPSTREAM_REPOSITORY="${UPSTREAM_REPOSITORY%.git}"; UPSTREAM_BRANCH_LOCAL_SHA="$(git rev-parse "refs/remotes/origin/$UPSTREAM_BRANCH")"; UPSTREAM_SHA_HTTP_CODE="$("$HOMEBREW_CURL" --silent '--max-time' 3            --output /dev/null --write-out "%{http_code}"            --user-agent "$HOMEBREW_USER_AGENT_CURL"            --header "Accept: application/vnd.github.v3.sha"            --header "If-None-Match: \"$UPSTREAM_BRANCH_LOCAL_SHA\""            "https://api.github.com/repos/$UPSTREAM_REPOSITORY/commits/$UPSTREAM_BRANCH")"; [[ "$UPSTREAM_SHA_HTTP_CODE" = "304" ]] && exit;
else
    if [[ -n "$HOMEBREW_UPDATE_PREINSTALL" ]]; then
        exit;
    fi;
fi; if [[ -n "$HOMEBREW_UPDATE_PREINSTALL" ]]; then
    git fetch --force "${QUIET_ARGS[@]}" origin "refs/heads/$UPSTREAM_BRANCH:refs/remotes/origin/$UPSTREAM_BRANCH" 2> /dev/null;
else
    if ! git fetch --force "${QUIET_ARGS[@]}" origin "refs/heads/$UPSTREAM_BRANCH:refs/remotes/origin/$UPSTREAM_BRANCH"; then
        echo "Fetching $DIR failed!" >> "$update_failed_file";
    fi;
fi )  (wd: /usr/local/Library/Taps/homebrew/homebrew-services)
/usr/local/Library/Homebrew/cmd/update.sh: line 245:  2133 Terminated: 15          ( UPSTREAM_REPOSITORY_URL="$(git config remote.origin.url)"; if [[ "$UPSTREAM_REPOSITORY_URL" = "https://github.com/"* ]]; then
    UPSTREAM_REPOSITORY="${UPSTREAM_REPOSITORY_URL#https://github.com/}"; UPSTREAM_REPOSITORY="${UPSTREAM_REPOSITORY%.git}"; UPSTREAM_BRANCH_LOCAL_SHA="$(git rev-parse "refs/remotes/origin/$UPSTREAM_BRANCH")"; UPSTREAM_SHA_HTTP_CODE="$("$HOMEBREW_CURL" --silent '--max-time' 3            --output /dev/null --write-out "%{http_code}"            --user-agent "$HOMEBREW_USER_AGENT_CURL"            --header "Accept: application/vnd.github.v3.sha"            --header "If-None-Match: \"$UPSTREAM_BRANCH_LOCAL_SHA\""            "https://api.github.com/repos/$UPSTREAM_REPOSITORY/commits/$UPSTREAM_BRANCH")"; [[ "$UPSTREAM_SHA_HTTP_CODE" = "304" ]] && exit;
else
    if [[ -n "$HOMEBREW_UPDATE_PREINSTALL" ]]; then
        exit;
    fi;
fi; if [[ -n "$HOMEBREW_UPDATE_PREINSTALL" ]]; then
    git fetch --force "${QUIET_ARGS[@]}" origin "refs/heads/$UPSTREAM_BRANCH:refs/remotes/origin/$UPSTREAM_BRANCH" 2> /dev/null;
else
    if ! git fetch --force "${QUIET_ARGS[@]}" origin "refs/heads/$UPSTREAM_BRANCH:refs/remotes/origin/$UPSTREAM_BRANCH"; then
        echo "Fetching $DIR failed!" >> "$update_failed_file";
    fi;
fi )  (wd: /usr/local/Library/Taps/homebrew/homebrew-tex)
/usr/local/Library/Homebrew/cmd/update.sh: line 245:  2141 Terminated: 15          ( UPSTREAM_REPOSITORY_URL="$(git config remote.origin.url)"; if [[ "$UPSTREAM_REPOSITORY_URL" = "https://github.com/"* ]]; then
    UPSTREAM_REPOSITORY="${UPSTREAM_REPOSITORY_URL#https://github.com/}"; UPSTREAM_REPOSITORY="${UPSTREAM_REPOSITORY%.git}"; UPSTREAM_BRANCH_LOCAL_SHA="$(git rev-parse "refs/remotes/origin/$UPSTREAM_BRANCH")"; UPSTREAM_SHA_HTTP_CODE="$("$HOMEBREW_CURL" --silent '--max-time' 3            --output /dev/null --write-out "%{http_code}"            --user-agent "$HOMEBREW_USER_AGENT_CURL"            --header "Accept: application/vnd.github.v3.sha"            --header "If-None-Match: \"$UPSTREAM_BRANCH_LOCAL_SHA\""            "https://api.github.com/repos/$UPSTREAM_REPOSITORY/commits/$UPSTREAM_BRANCH")"; [[ "$UPSTREAM_SHA_HTTP_CODE" = "304" ]] && exit;
else
    if [[ -n "$HOMEBREW_UPDATE_PREINSTALL" ]]; then
        exit;
    fi;
fi; if [[ -n "$HOMEBREW_UPDATE_PREINSTALL" ]]; then
    git fetch --force "${QUIET_ARGS[@]}" origin "refs/heads/$UPSTREAM_BRANCH:refs/remotes/origin/$UPSTREAM_BRANCH" 2> /dev/null;
else
    if ! git fetch --force "${QUIET_ARGS[@]}" origin "refs/heads/$UPSTREAM_BRANCH:refs/remotes/origin/$UPSTREAM_BRANCH"; then
        echo "Fetching $DIR failed!" >> "$update_failed_file";
    fi;
fi )  (wd: /usr/local/Library/Taps/homebrew/homebrew-versions)
/usr/local/Library/Homebrew/cmd/update.sh: line 245:  2155 Terminated: 15          ( UPSTREAM_REPOSITORY_URL="$(git config remote.origin.url)"; if [[ "$UPSTREAM_REPOSITORY_URL" = "https://github.com/"* ]]; then
    UPSTREAM_REPOSITORY="${UPSTREAM_REPOSITORY_URL#https://github.com/}"; UPSTREAM_REPOSITORY="${UPSTREAM_REPOSITORY%.git}"; UPSTREAM_BRANCH_LOCAL_SHA="$(git rev-parse "refs/remotes/origin/$UPSTREAM_BRANCH")"; UPSTREAM_SHA_HTTP_CODE="$("$HOMEBREW_CURL" --silent '--max-time' 3            --output /dev/null --write-out "%{http_code}"            --user-agent "$HOMEBREW_USER_AGENT_CURL"            --header "Accept: application/vnd.github.v3.sha"            --header "If-None-Match: \"$UPSTREAM_BRANCH_LOCAL_SHA\""            "https://api.github.com/repos/$UPSTREAM_REPOSITORY/commits/$UPSTREAM_BRANCH")"; [[ "$UPSTREAM_SHA_HTTP_CODE" = "304" ]] && exit;
else
    if [[ -n "$HOMEBREW_UPDATE_PREINSTALL" ]]; then
        exit;
    fi;
fi; if [[ -n "$HOMEBREW_UPDATE_PREINSTALL" ]]; then
    git fetch --force "${QUIET_ARGS[@]}" origin "refs/heads/$UPSTREAM_BRANCH:refs/remotes/origin/$UPSTREAM_BRANCH" 2> /dev/null;
else
    if ! git fetch --force "${QUIET_ARGS[@]}" origin "refs/heads/$UPSTREAM_BRANCH:refs/remotes/origin/$UPSTREAM_BRANCH"; then
        echo "Fetching $DIR failed!" >> "$update_failed_file";
    fi;
fi )  (wd: /usr/local/Library/Taps/homebrew/homebrew-x11)
/usr/local/Library/Homebrew/cmd/update.sh: line 245:  2163 Terminated: 15          ( UPSTREAM_REPOSITORY_URL="$(git config remote.origin.url)"; if [[ "$UPSTREAM_REPOSITORY_URL" = "https://github.com/"* ]]; then
    UPSTREAM_REPOSITORY="${UPSTREAM_REPOSITORY_URL#https://github.com/}"; UPSTREAM_REPOSITORY="${UPSTREAM_REPOSITORY%.git}"; UPSTREAM_BRANCH_LOCAL_SHA="$(git rev-parse "refs/remotes/origin/$UPSTREAM_BRANCH")"; UPSTREAM_SHA_HTTP_CODE="$("$HOMEBREW_CURL" --silent '--max-time' 3            --output /dev/null --write-out "%{http_code}"            --user-agent "$HOMEBREW_USER_AGENT_CURL"            --header "Accept: application/vnd.github.v3.sha"            --header "If-None-Match: \"$UPSTREAM_BRANCH_LOCAL_SHA\""            "https://api.github.com/repos/$UPSTREAM_REPOSITORY/commits/$UPSTREAM_BRANCH")"; [[ "$UPSTREAM_SHA_HTTP_CODE" = "304" ]] && exit;
else
    if [[ -n "$HOMEBREW_UPDATE_PREINSTALL" ]]; then
        exit;
    fi;
fi; if [[ -n "$HOMEBREW_UPDATE_PREINSTALL" ]]; then
    git fetch --force "${QUIET_ARGS[@]}" origin "refs/heads/$UPSTREAM_BRANCH:refs/remotes/origin/$UPSTREAM_BRANCH" 2> /dev/null;
else
    if ! git fetch --force "${QUIET_ARGS[@]}" origin "refs/heads/$UPSTREAM_BRANCH:refs/remotes/origin/$UPSTREAM_BRANCH"; then
        echo "Fetching $DIR failed!" >> "$update_failed_file";
    fi;
fi )
Warning: You are using OS X 10.8.
We (and Apple) do not provide support for this old version.
You may encounter build failures or other breakages.
Please create pull-requests instead of filing issues.
==> Installing dependencies for ffmpeg: texi2html, yasm, x264, lame, xvid
==> Installing ffmpeg dependency: texi2html
==> Downloading http://download.savannah.gnu.org/releases/texi2html/texi2html-5.0.tar.gz
==> Downloading from http://nongnu.askapache.com//texi2html/texi2html-5.0.tar.gz
^C
Josephs-MacBook-Pro:~ joe$

Even the 4 second delay for the installs to start, which would have started instantly before, is not ... fun.

Neither are the regular issues we get which are fixed by a brew update 😉. It would have "started" instantly before but for most software it's not a large % increase of the overall installation time. We can add a message saying that it's running a self-update, though?

I think update should be manually invoked or asynchronous, not a synchronous blocker for every install.

I think if we can compromise between never running brew update automatically and running it on every single brew install invocation, we can achieve basically the same goal (avoid that users forget to run brew update and thus operate with an unnecessarily old package manager and formula database).
My suggestion (though I remember it being shot down in a previous discussion) would be to make brew update remember when it was last executed (e.g. by saving a timestamp to .git/config where we already save other Homebrew-related information). This would allow brew update --preinstall to check this timestamp and to skip the autoupdate if less than 24 hours have passed. If the autoupdate happens at most once a day during a brew install it won't be annoying, even if it takes 30 seconds to complete due to a non-trivial number of taps (as long as there's some output indicating what is going on).

I think we need to explore asynchronous options more thoroughly, since that's the gold standard these days.

Installing probably really should block on the update check though, right?

Not unless it's missing critical (which is most certainly is not) that brew be up-to-the-second up to date, as opposed to having been updated asynchronously within the last x time period.

$ # Without patch from below:
$ /usr/bin/time brew update --preinstall
       20.64 real        13.02 user         8.70 sys
$ # With patch from below:
$ /usr/bin/time brew update --preinstall
        5.58 real         2.56 user         3.28 sys

The following patch obviously isn't the proper solution, but it reveals a major bottleneck.
diff --git i/Library/Homebrew/cmd/update.sh w/Library/Homebrew/cmd/update.sh
index aafae724..6727df2d 100644
--- i/Library/Homebrew/cmd/update.sh
+++ w/Library/Homebrew/cmd/update.sh
@@ -9,6 +9,9 @@
 # shellcheck source=/dev/null
 source "$HOMEBREW_LIBRARY/Homebrew/utils/lock.sh"

+_git_executable="$("$HOMEBREW_LIBRARY/ENV/scm/git" --homebrew=print-path)"
+git() { "$_git_executable" "$@"; }
+
 git_init_if_necessary() {
   if [[ -n "$HOMEBREW_OSX" ]]
   then

@ilovezfs How do your timings change if you apply it?

@UniqMartin
HOMEBREW_DEVELOPER set:
without your diff -> 14.5, 14
with your diff -> 3.9, 3.2
HOMEBREW_DEVELOPER not set:
without your diff -> 4.3, 4.3
with your diff -> 2.6, 2.0

Yeh, we should do that regardless, I think. That's a pretty massive slowdown (and it makes me question using it even in e.g. superenv)

@MikeMcQuaid what's actually the intent of the git shim?

I don't know, @xu-cheng?

That's a pretty massive slowdown (and it makes me question using it even in e.g. superenv)

I don't think those times are relevant in superenv, when we do more expensive operations that involve network access and actually checking out tags/branches. It just shows in the mostly no-op case in brew update because there we're mostly doing trivial (and fast) operations like querying the working copy status and the Git configuration (via git config).

what's actually the intent of the git shim?

@xu-cheng might have a better answer, but: The main motivation is to have more flexibility (e.g. through HOMEBREW_GIT and GIT environment variables, picking a Homebrew-installed Git that isn't in PATH) and safety (skip /usr/bin/git if it is not working properly, i.e. without CLT/Xcode or a misconfigured xcode-select) when picking a git binary. I continue to see merit in that, but the repeated lookup of the correct binary obviously has some downsides and that the lookup is done in Ruby doesn't help with performance. This can be fixed with what I've shown in my diff. One would just need to make sure to also invalidate the cache (because that's what $_git_executable is) when necessary.

These sound like reasons motivated by a desire to support < 10.9, unless I'm missing something.

These sound like reasons motivated by a desire to support < 10.9, unless I'm missing something.

You are (though I should probably have used “robustness” instead of “safety”):

[…] and safety (skip /usr/bin/git if it is not working properly, i.e. without CLT/Xcode or a misconfigured xcode-select) when picking a git binary.

It seems to me that if I have a broken /usr/bin/git or misconfigured xcode-select, then I have bigger problems than which git brew is picking.

@UniqMartin Pretty much summary why the shim script is required. I just want to add that it also plays an important rule on non-Xcode/CLT system. In those system, running /usr/bin/git will trigger a popup window, which is what we want to avoid.
To speed up the performance, I may suggest two things:

Similar to  @UniqMartin's git() { "$_git_executable" "$@"; }, a less hacky way is export HOMBEREW_GIT="$("$HOMEBREW_LIBRARY/ENV/scm/git" --homebrew=print-path))". Although, I have no strong preference.
We could consider to rewrite git shim using bash. This can also benefit if we want to the same script handling curl resolution and avoid ruby dependency for fetching.

Pretty much summarize why the shim script is required. I just want to add that it also plays an important rule on non-Xcode/CLT system. In those system, running /usr/bin/git will trigger a popup window, which is what we want to avoid.

Is it not possible to do a one-off check for this rather than rechecking it every time the script is invoked?

Similar to @UniqMartin's git() { "$_git_executable" "$@"; }, a less hacky way is export HOMBEREW_GIT="$("$HOMEBREW_LIBRARY/ENV/scm/git" --homebrew=print-path))"

That's still going to call the shim every time, though, no?

We could consider to rewrite git shim using bash. This can also benefit if we want to the same script handling curl resolution and avoid ruby dependency for fetching.

I think this would be good but it might be better still if we can replace the shim with a one-off check as it doesn't really need to be doing e.g. clang-style argument refurbishment on each call.

With Martin's patch and HOMEBREW_DEVELOPER=1:
 time brew update --preinstall
==> Auto-updated Homebrew!
Updated 2 taps (caskroom/cask, homebrew/core).
No changes to formulae.

real	0m11.082s
user	0m4.244s
sys	0m3.661s

@ilovezfs Can you try https://github.com/Homebrew/brew/pull/429?

do you mean #442 ?

Duh, yeh, sorry.

OK. To answer the 429 question though:
Josephs-MacBook-Pro:~ joe$ time brew update --preinstall
==> Auto-updated Homebrew!
Updated Homebrew from 16da3f9 to 9ab4078.
Updated 1 tap (homebrew/core).
No changes to formulae.

real	0m22.018s
user	0m17.365s
sys	0m7.510s

OK 442:
Josephs-MacBook-Pro:~ joe$ time brew update --preinstall
Checking for Homebrew updates...
==> Auto-updated Homebrew!
Updated 2 taps (homebrew/core, homebrew/versions).
==> Updated Formulae
flyway                                   metabase
homebrew/versions/gcc5                   tomcat-native

real	0m11.135s
user	0m4.829s
sys	0m4.279s
Josephs-MacBook-Pro:~ joe$ time brew update --preinstall
Checking for Homebrew updates...

real	0m7.644s
user	0m4.133s
sys	0m3.694s
Josephs-MacBook-Pro:~ joe$ time brew update --preinstall
Checking for Homebrew updates...

real	0m7.375s
user	0m3.958s
sys	0m3.632s
Josephs-MacBook-Pro:~ joe$

Almost a 100% speedup for the no-op case. Feels like it's worth dogfooding after that's merged, right?

I still think this needs to be limited to running at most daily or something like that. Better yet, asynchronously with a menubar item, or daemon, etc.

"At most X" is always going to be arbitrary. The case we're trying to deal with is brew install X failing and it's already fixed if they had run brew update. Even if the update happened 30 seconds ago and we update at most every minute: that's not enough for this case. We should optimise for the novice user case and then allow power users to customise this (i.e. the already existing opt-out).

That argument doesn't make sense to me. This doesn't need to solve 100% cases to be a good thing. If it fixes 80% instead of 100% of the problem and thereby avoids wasting time on every single brew install - novice user or not - I think that's well worth the trade-off.

There's lots of other time-wasting checks we do on every brew install to reduce our support load. I've got 7 taps installed and it's a 3.18 second no-op for me with an opt-out; that's significantly less time than most installs are going to take. I'm open to optimising this further but "do once a X" time period is not really an optimisation, it's just a periodic and arbitrary disabling of this functionality.

I have never heard of an automatic update mechanism that runs every single time you invoke a command, unless that command is "update."
This is a flagrant violation of the 80/20 rule or, put differently, "the perfect is the enemy of the good."

I have never heard of an automatic update mechanism that runs every single time you invoke a command, unless that command is "update."

Pretty much every single OS X GUI application does this. Many other command-line package management utilities hit a remote endpoint and block on their return on install commands.
Unless there's strong objections from multiple other maintainers: you have an opt-out so I'd suggest you set it.

The GUI apps that do that each time the application is launched, not each time you have some particular interaction with the program.

Unless there's strong objections from multiple other maintainers: you have an opt-out so I'd suggest you set it.

Yes, I hope people speak up, because this is a really bad idea.

"At most X" is always going to be arbitrary.

We're making a lot of arbitrary choices for the user. At most a day seems like a reasonable middle ground where things are updated frequently enough without getting in the way on every single invocation. Some of the auto-updating GUI apps allow me to pick the frequency of those update checks, where the choice is usually daily, weekly, or even monthly.

The case we're trying to deal with is brew install X failing and it's already fixed if they had run brew update. Even if the update happened 30 seconds ago and we update at most every minute: that's not enough for this case.

I think this is solving a manageable problem with a sledgehammer. And quite frankly, it's unrealistic that things will have changed this much in the last 30 seconds, or even 24 hours. I think we're mostly trying to address those cases that never (or almost never) update, they will be served well with a daily update, and I'm confident this is enough to solve about 90% of all issues that can actually be attributed to a stale Homebrew installation. Plus a failed installation already asks the user to brew update and try again.
With this argument that the issue might have been fixed in the past few seconds/minutes/hours, we could as well decide to auto-update after a failed installation and try again. Then repeat this cycle until the installation finally succeeds or the user aborts. (No, this is not a serious suggestion.)

We should optimise for the novice user case and then allow power users to customise this (i.e. the already existing opt-out).

I'm fine with that.  I'm aware of my local repository state (including tap repositories) and want brew install to operate on that and not some (to me) unpredictable state after an automatic update. I also want to perform updates when that's convenient for me.

My repositories (both taps and the package manager) are frequently on a non-master branch. Auto-update doesn't help with these and updating them cannot be fully automated anyway.

My working copies are frequently in some intermediate state, including uncommitted files, pending Git operations and what not. I don't trust the automatism to always be able to fully stash away and restore this. I'm fine with cleaning up my working copy before I run brew update, but I don't want to have to do this while experimenting with other changes, many of which involve repeatedly running brew install.

Some of the auto-updating GUI apps allow me to pick the frequency of those update checks, where the choice is usually daily, weekly, or even monthly.

In those cases the choice of the autoupdate rate does not increase the developer's support burden like it does with us.

I think this is solving a manageable problem with a sledgehammer. And quite frankly, it's unrealistic that things will have changed this much in the last 30 seconds, or even 24 hours.

No, that's not the case. There's been plenty of times we make a major breakage and then receive a barrage of issues in the space of a few minutes/hours/days and even weeks where we'd have received 1 or 0 issues had this functionality been in place. With respect, these may have predated @ilovezfs or your involvement in Homebrew so you may not have seen them. This, like the Bash updater, is solving a problem that does not necessarily occur very often but is invaluable when it does occur.

I think we're mostly trying to address those cases that never (or almost never) update, they will be served well with a daily update, and I'm confident this is enough to solve about 90% of all issues that can actually be attributed to a stale Homebrew installation.

I'm trying to address (rather than we) the case where something is fixed but people file an issue. I'd rather try to fix 100% of the issues rather than 90%.

Plus a failed installation already asks the user to brew update and try again.

It asks them to read a link which says this. That's not the same and users don't read this error text (demonstrated by issues filed every day).

With this argument that the issue might have been fixed in the past few seconds/minutes/hours, we could as well decide to auto-update after a failed installation and try again. Then repeat this cycle until the installation finally succeeds or the user aborts. (No, this is not a serious suggestion.)

This is why we have a no-op. If people want the no-op case to be faster: we can try to make it faster.

 I'm aware of my local repository state (including tap repositories) and want brew install to operate on that and not some (to me) unpredictable state after an automatic update.

It does already operate on your local repository state; it restores your changes after update.

My repositories (both taps and the package manager) are frequently on a non-master branch. Auto-update doesn't help with these and updating them cannot be fully automated anyway.

It does, actually, because it rebases changes on master and checks out your non-master branches again for you.

My working copies are frequently in some intermediate state, including uncommitted files, pending Git operations and what not. I don't trust the automatism to always be able to fully stash away and restore this.

If you can point to a reproducible bug: please let me know so I can fix it. I don't think it's really fair to publicly comment on the work of another maintainer implying that you don't trust it to do what it does without putting in the effort to either fix or reproduce it.

I'm trying to address (rather than we) the case where something is fixed but people file an issue. I'd rather try to fix 100% of the issues rather than 90%.

which leaves precisely zero room for compromise

As I said, I'm not against enabling the auto-update and I'm not objecting to it. I just don't think it's what I personally want and I can sympathize with some of the points @ilovezfs has brought up.

It does already operate on your local repository state; it restores your changes after update.

I was referring to brew install as it is now. And that should definitely not be messing with my brew or my various tap repositories. (That brew update [--preinstall] is doing this is clear.)

It does, actually, because it rebases changes on master and checks out your non-master branches again for you.

I think we might have different workflows then. None of my local changes that haven't been merged into origin/master are in my local master. Essentially, my local master is always in a pristine state. Thus unless I'm overlooking something, that's what I believe is happening when I run brew update: I'm usually on branch dev, then the update switches to master, does a rebase their (which is always a no-op in my case), then switches back to my dev branch, so the working copy is exactly where it was before the update (modulo changes to master that are not reflected in my dev branch just yet).

If you can point to a reproducible bug: please let me know so I can fix it. I don't think it's really fair to publicly comment on the work of another maintainer implying that you don't trust it to do what it does without putting in the effort to either fix or reproduce it.

This isn't a criticism of your work. I don't think it makes sense to deal with the full complexity that Git repositories and their working copies can have in brew update. I think the logic in place works well (and is robust) for the typical contributor and user. And if it doesn't and there's a reproducible bug, I'm happy to help solve the issue. But I simply don't want this automatic handling (for the various stated reasons).

@MikeMcQuaid there seems to be a bug where preinstall sometimes fails to update my local homebrew/core master and my local origin/master.
Full log here:
https://gist.github.com/ilovezfs/6dbe53cd5ae2cc25098efd01df01c96a
So right now it ends up with the latest commit locally being
19e6e3eaf3868f4f12ae1de2ccc13cc4ac436e94
passpie: update 1.5.2 bottle.
But the actual latest commit on GitHub is
489c62e156477b27ad49d774d6d01339eac6596f
cmake: update 3.6.0 bottle.
Running it more than once doesn't trigger the update either.

@ilovezfs This looks correct (or more precisely, is by design). brew update --preinstall is only checking and auto-updating repositories that are fetched via HTTPS (where the origin remote URLs start with https://github.com/ to be more precise). So in your case it's only ever attempting to update 12 out of all the repositories you have installed. Here's the relevant code in cmd/update.sh.

@UniqMartin Most of the time it does do the auto update and lists items from core. Are you saying that's an accident because it noticed one of the https's was outdated and then proceeded to do everything, but if it's only one of ssh's that's outdated it does nothing?

Also, what in the world is all of the stashing and popping behavior when HOMEBREW_DEVELOPER is set intended to accomplish if what you're saying is true and this is supposed to do nothing with ssh repos?

Ah now I see what was going on. It was only ever working with my main tree, not the tree I use for pushes. I guess "ideally" it would substitute in the https url for the ssh one in order to do the API check and then use ssh for the actual transactions (I believe this is exactly what the hub command does, btw)?

Ah now I see what was going on. It was only ever working with my main tree, not the tree I use for pushes. I guess "ideally" it would substitute in the https url for the ssh one in order to do the API check and then use ssh for the actual transactions (I believe this is exactly what the hub command does, btw)?

We tap using HTTP by default and GitHub uses HTTP by default so we double down on that. If you wanted to implement that approach, though, feel free 👍

Gonna ship this now; this doesn't mean we're any more likely to ship the autoupdate feature as-is but just that we want to get more 👀 on this and hopefully more people tweaking bits that are annoying.

Well here's another annoying bit.

It might be good if it decided it was going to error out due to already installed before spinning its wheels.

Agreed but unsure how to do that in a preinstall check. In this case: it did update stuff, though.

Right and then I get to sit through the update a second time after I resolve the it's-already-installed-issue :)

@MikeMcQuaid So I've been thinking about whether there would be any way for auto-update both to run asynchronously and to run every time.
If I put aside the corner case where the brew update takes a longer time than the installation of the first item (whether explicit target or dependency) for a moment, it should be possible to have the install and the update run simultaneously in separate threads. If, following the completion of the update, brew determines that any of the items involved in the install have actually been updated, it could go back to the beginning, and start over with the newer version(s).
Since most of the time there will be no overlap between what the user is installing and what formulae actually got updated, in most cases there would be no additional time added to the installation and brew install would not block waiting on a pre-install update to finish. The corner case where the update takes longer than the install of the first item could be addressed by not finalizing the install of the first item until the update completes, which would then be the only case where this added time to installs.
(Of course, I still think it would be nicer to have this run entirely asynchronously (launchd) or only do it on some arbitrary minimum interval between updates.)

@ilovezfs That seems like it would be a bit of a nightmare for the code to handle. I've got various profiling tools bookmarked I want to investigate; I suspect this would be not annoying if the no-op case was e.g. 0.1 seconds.

Why a nightmare? As it is, Ctrl-C already triggers a canceling procedure, no?

I suspect this would be not annoying if the no-op case was e.g. 0.1 seconds

Also if the no-op case included no-op when none of the items being updated have updates. It's annoying in the non-no-op case when it does its thing solely because it's updating cask or some obscure formulae upgrades that nutty ilovezfs just pushed, and the non-no-op update had nothing to do with what I'm doing.

I suspect this would be not annoying if the no-op case was e.g. 0.1 seconds.

I suspect that might be somehow achievable locally, but would require some serious tuning. But even then this feels like a lot of work. I'm a bit doubtful this can be achieved at all if network access is involved.

@UniqMartin Sure; I was just throwing a number out there. I think sub a second is probably both doable and a reasonable compromise e.g. by only updating the tap of the things being installed.

Why a nightmare? As it is, Ctrl-C already triggers a canceling procedure, no?

I'm more thinking of the "starting compling wget, oh there's an update, cancel compiling wget, relaunch the new Homebrew" etc.

I'm more thinking of the "starting compling wget, oh there's an update, cancel compiling wget, relaunch the new Homebrew" etc.

As an initial version, it could probably treat the cancelable/waits-on-update-to-finish event as the download of the first item rather than the install of the first item.

Regardless we'll still need to have some sort of "kill parent Ruby process from the build process and restart the Bash process" dance that will be fairly involved and hard to debug if it goes wrong.

Regardless we'll still need to have some sort of "kill parent Ruby process from the build process and restart the Bash process" dance that will be fairly involved and hard to debug if it goes wrong.

Perhaps we'll need a ballet instructor.

@MikeMcQuaid So I noticed that brew upgrade is running the autoupdate before doing its thing. That seems like it has the potential to create undesirable behavior. If you run brew update; brew outdated; brew upgrade you can end up getting more than you expected from inspecting the outdated list unless you're paying careful attention after the upgrade has already started and you're quick on the control-c.

@ilovezfs Stuff like that people will just end up adapting their flows for, I think. Another option I'm coming around to is making the "only update every X" super short so it's e.g. 10 seconds which would avoid this situation.

I'm also thinking for brew install X Y Z we check which taps these map to and only update them (and also perhaps homebrew-core but not e.g. Homebrew/brew)

@ilovezfs Stuff like that people will just end up adapting their flows for,

Is there a command line switch to prevent the auto update? Or are you suggesting people would need to adapt by doing brew update; brew outdated; HOMEBREW_NO_AUTO_UPDATE=1 brew upgrade?

I'm also thinking for brew install X Y Z we check which taps these map to and only update them (and also perhaps homebrew-core but not e.g. Homebrew/brew)

IMO, at least homebrew/core would have to be done every time, otherwise we're opening the door to seeing tap builds with core dependencies fall apart in all sorts of entirely preventable ways.
Possibly makes sense to calculate the recursive dependencies & update those taps only, but that's not exactly a breezy quick process.


q-calendar - multiple events in one day

Hi guys,
Is that possible to provide the availability to set multiple dots within Day box in <q-calendar /> like in Google calendar for example (Please see the example screenshot below).

Thanks a lot!

@pikil You mean like this?

Example here: https://quasarframework.github.io/quasar-ui-qcalendar/examples/month-view#example-Mini-Mode---Slots-(day)
Note: The content is slot rendered (evland), so you can make it whatever you want

Hi hawkeye64,
Yes, that should do the trick I believe :) Thank you!
Is there any possibility to do that in <q-date /> selector by the way?
Cheers!

I don't think so. QDate, you can tell it there is an event on a date, and specify color. But not more than one event.


Patterns to test Telefunc

Is there a way of testing Telefunc without the UI components?

Not sure what you mean; what is it you are trying to achieve?

For example, when the frontend and backend are separated, we test the API with the postman or graphql playground.
Is there a way to use prev backend pattern to test .telefunc functions without importing them into pages?

Yes, simply recreate an HTTP request made by the Telefunc client. You can then, for example, use curl.
(I'm closing this ticket beause it's something Telefunc end-users wouldn't need: I'm assuming you need this because you want to experiment with RSC.)
Let me know if you have further questions.


Fix build workflow from forks

Description
This change attempts to fix the build/test workflow when initiated from a fork.
The following problems are being addressed in this change:

The build/push container workflow will fail because the fork cannot push to OUR ghcr repo.
The build/push helm workflow will fail because the fork cannot push to OUR acr or ghcr repo.
The Bicep linting workflow cannot clone the docs or samples repo because its missing a github tokein.

The following changes are being made here:

Move Helm linting to our 'lint' workflow. This can run without dependencies, and it's easier to combine it with the other linting we do.
Add new target for multi-arch container build so we can test the build without doing a push.
Use the new multi-arch container build target when a PR is running.

This is OK because the functional-test workflow does its own build/push of containers.
We want to still test that the multi-arch build succeeds on PR, but we don't need to push the result anywhere.

Skip the helm job when a PR is running.

This is OK because the functional-test workflow uses the chart from the local directory.
We want to still test the Helm linter, which is why it was moved elsewhere.

Remove the 'clone' of the docs and samples repo as part of the validate-bicep workflow.

This is OK because this was never a good idea. Trying to do multi-repo validation like this is going to lead to a lot of false positives.

Type of change

This pull request is a minor refactor, code cleanup, test improvement, or other maintenance task and doesn't change the functionality of Radius (issue link optional).

Fixes: #issue_number
Auto-generated summary

🤖 Generated by Copilot at ec2c934
Summary
🚀🧹🛠

This pull request simplifies and optimizes the GitHub workflows for building, linting, and validating the radius project. It removes unnecessary steps and dependencies, and consolidates the helm chart linting into the build workflow. It also refactors the docker multi-arch build process into separate targets.

Some workflows were changed in this PR
To make them more efficient by far
lint.yaml lost Azure CLI
validate-bicep got simplified
And build.yaml got a new star

Walkthrough

Simplify and secure the container image building and pushing process (link, link, link, link, link, link, link)

Use a single container registry ghcr.io/radius-project for all images and avoid pushing images from pull requests (link, link, link)
Use a single OCI repository radius-project/helm-chart for the helm chart and version it based on the git ref (link)
Split the generateDockerMultiArches macro into separate targets for building and pushing the multi-arch images (link, link, link)
Clarify the comments and variables for the test and non-test image targets (link, link)

Move the helm chart linting from lint.yaml to build.yaml and remove the unnecessary Azure CLI setup (link, link)

Add the Install helm and Run Helm linter steps to the build.yaml workflow to check the validity and quality of the helm chart (link)
Remove the Setup Azure CLI step from the lint.yaml workflow as it is not needed for linting (link)

Remove the unused steps and repos from the validate-bicep.yaml workflow (link)

Remove the steps to clone the docs and samples repos and to login to Azure CLI as they are not needed for validating the bicep files (link)

/ok-to-test

/ok-to-test

I'm going to merge this because it fixes a bunch of things that are broken. If there's feedback I will address later 👍


Documentation for database microservice.

The purpose of this task is to add all documentation for the database microservice.
This includes comments for the code written, proper logs, and README.md file

The documentation for this microservice is complete.