Update zio-prelude to 1.0.0-RC33

About this PR
📦 Updates dev.zio:zio-prelude from 1.0.0-RC19 to 1.0.0-RC33
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "dev.zio", artifactId = "zio-prelude" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "dev.zio", artifactId = "zio-prelude" }
}]

labels: library-update, early-semver-pre-release, semver-spec-pre-release, commit-count:1

Superseded by #824.


Edit Measure Conditions Fix

TP2000-856 Edit Measure Conditions Fix
Why
When we automated the creation of the negative action code for use in the Create Measures journey, we removed the negative actions from the UI menu.
Unfortunately this has also removed them from the Edit Measures journey, meaning that a user can’t complete the journey as the required UI setting is missing.
What

Edit Measure condition form - field action - queryset updated to include all actions
New validation for edit measure condition forms that checks that all fields are blank when a negative action code is selected.
formset errors now appear in edit formset for conditions
Formset validation now counts negative actions seperately so the form can successfully submit when editting negative actions too

Codecov Report
Patch coverage: 100.00% and project coverage change: +0.11 :tada:

Comparison is base (d63e095) 92.41% compared to head (4031113) 92.52%.

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #896      +/-   ##
==========================================
+ Coverage   92.41%   92.52%   +0.11%
==========================================
  Files         413      416       +3
  Lines       28360    28993     +633
  Branches     2161     2206      +45
==========================================
+ Hits        26210    26827     +617
- Misses       1744     1751       +7
- Partials      406      415       +9

Impacted Files
Coverage Δ

measures/forms.py
96.20% <100.00%> (+0.06%)
:arrow_up:

measures/tests/conftest.py
94.47% <100.00%> (+0.35%)
:arrow_up:

measures/tests/test_forms.py
99.57% <100.00%> (+<0.01%)
:arrow_up:

measures/tests/test_views.py
100.00% <100.00%> (ø)

measures/validators.py
96.46% <100.00%> (+0.06%)
:arrow_up:

... and 24 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Snap packaging

Adds strictly confined snap packaging of ollama-webui for x86-64 as an alternative to docker & k8s, presently published on the channel latest/beta (sudo snap install ollama-webui --beta).
This is proposed as a nice alternative to docker (no need to install and configure the nvidia docker runtime for example, systemd service is set up automatically, over-the-air updates, straightforward to access resources and data from user's host system within the limits of the application's confinement) and safer of course than bare installation onto host system.
Installable with:
sudo snap install ollama --channel beta # or ollama installed any other method, or on another host
sudo snap install ollama-webui --channel beta

As you might guess from above I also packaged up ollama as a snap (this snapped version of ollama-webui does not require it, demonstrating this mostly just to note the ease of installing both).

strict confinement used with network, network-bind, home, removable-media, opengl interfaces in use, i.e. it can access and serve a port, access home directory and /media, and access the GPU (the opengl interface also grants access to CUDA etc).
starts up a systemd service automatically for the service.
if removable media access is needed (e.g. user prefers storing data under a disk mounted under /media), sudo snap connect ollama:removable-media achieves that (for security reasons, removable media access not granted without user action).

If this looks interesting, I'm happy to hand over the package on snapcraft.io to a maintainer, and can contribute CI integration to make it easy to keep the snap package up to date whenever you release.
If you want to build this locally, after installing snapcraft and either the multipass or LXD provider for it go to the root directory of the repository, and ...:
snapcraft

Configuration
Offers the following configuration keys and default values, configurable with sudo snap set ollama-webui key=value:

data-dir: /var/snap/ollama-webui/common/data
enable-signup: true
host: <IP_ADDRESS>
ollama-api-base-url: http://localhost:11434/api
openai-api-base-url: https://api.openai.com/v1
openai-api-key: (blank)
port: 8080
secret-key (randomized)

Amazing stuff, Thanks for the hard work! We're planning on changing our name as per Ollama team's request, so let's wait until we decide on our new name before we merge this!

Thanks! I'll keep improving it meanwhile: I am going to add the support for this package pulling the ollama snap as a dependency through the "content" interface, also to allow making it possible to download models via the web frontend.

I updated this PR now with latest changes from main, including updating the name of the package, and published.
On doing so I hit a security check with the new transient dependency libctranslate2 (that dynamic library is built with an executable stack -- curious to learn if that will have been intentional or a mistake?)
In my own testing I have been able to use the regular chat functionality with text input just fine, but I hit an issue with the document upload / RAG functionality: on attempting to upload a document I experience a 500 status code from the server but am not clear how I would be able to debug this further short of starting to add debug log statements, track trace output in myself. Am I missing a debug facility I should just turn on?

I updated this PR now with latest changes from main, including updating the name of the package, and published an initial revision to https://snapcraft.io/open-webui on the beta channel (sudo snap install open-webui --beta).
On doing so I hit a security check with the new transient dependency libctranslate2 (that dynamic library is built with an executable stack -- curious to learn if that will have been intentional or a mistake?)
In my own testing I have been able to use the regular chat functionality with text input just fine, but I hit an issue with the document upload / RAG functionality: on attempting to upload a document I experience a 500 status code from the server but am not clear how I would be able to debug this further short of starting to add debug log statements, track trace output in myself. Am I missing a debug facility I should just turn on?

That libctranslate2 needs some more explanation, not sure that I understand. Which package depends on it? If there's something we can do about it, by all means let's get another issue/PR for that going.
As for debugging, I don't think you've missed anything. We really need some more debug log statements, and a DEBUG=true variable to activate it.

Thanks! I'll keep improving it meanwhile: I am going to add the support for this package pulling the ollama snap as a dependency through the "content" interface, also to allow making it possible to download models via the frontend to ollama.

I had second thoughts about this after stating this: it's not necessarily a good idea to do this because a user may a) not care for ollama, or choose to get it from another source, not necessarily the snap (build from source, use a Dockerfile exposed to the host system etc).

That libctranslate2 needs some more explanation, not sure that I understand. Which package depends on it? If there's something we can do about it, by all means let's get another issue/PR for that going.

It's a dependency of one of the ML frameworks included in open-webui. I've understood that an executable call stack in a dynamic library is in most cases an accident (the reason that the snap store automatically validates against it is that it is a security hole), and appears to indeed be an accidental command line flag in that dependency library build since with cleaning up that exec stack bit out in the snapped open-webui, the app works without it set. I can try to dig into that some more at some point, I think it should be fine to keep the processing of that library in place.

As for debugging, I don't think you've missed anything. We really need some more debug log statements, and a DEBUG=true variable to activate it.

This seemed to have improved since I opened the PR :smile: I got the file upload (and RAG support for documents and websites, both of which I've successfully been using past weeks) feature fixed thanks to some added debug logging that made it clear that the data directory was not getting configured quite right inside the app's sandbox (I was my bad, got fixed by updating the hooks and launcher provided inside the snap).

I've updated the branch now against the current dev branch, which actually simplified things: the introduction of the configurable $HOST is the only change (beside what's under the snap directory). If you're happy with this contribution, I'd propose introducing in a follow-up branch a GitHub workflow based automation that would automatically build the snap and publish to the store (at that point it would be best to get the snap ownership to yourselves in the upstream project). I can come chat on Discord about all this if you like.
Also, a fresh update (revision 7) is working its way through the snap store processing that reflects the current HEAD of this branch. To accelerate snapd picking up the update when it's made available in the next < 30mins, you can do sudo snap refresh open-webui --channel beta (... or it will be delivered automatically during the next day).

Hi @mz2 I didn't mean to leave this unreviewed for so long. I'd like to chat with Tim first about adopting this under our umbrella, you're more than welcome to join us in Discord!
https://discord.gg/5rJgQTnV4s


Add DV profile 10 handling in getAlternativeCodecMimeType() method

I found your team had added DV profile 10 support in https://github.com/androidx/media/blob/main/libraries/exoplayer/src/main/java/androidx/media3/exoplayer/mediacodec/MediaCodecUtil.java#L1346 in latest main branch. But it seems that method getAlternativeCodecMimeType() should be updated too. So I submitted this contribution.

Hi @ybai001
Would it be possible to open a new PR from an individual-owned fork? We can't push changes to organization-owned forks like this one unless we have collaborator access. If that's not possible then we can still merge this PR but it will result in an 'evil' merge. See more info here: https://github.com/androidx/media/blob/release/CONTRIBUTING.md#push-access-to-pr-branches

Hi @ybai001
Would it be possible to open a new PR from an individual-owned fork? We can't push changes to organization-owned forks like this one unless we have collaborator access. If that's not possible then we can still merge this PR but it will result in an 'evil' merge. See more info here: https://github.com/androidx/media/blob/release/CONTRIBUTING.md#push-access-to-pr-branches

Hi, @microkatz , Yes, I was told about it in another pull request. Unfortunately, due to the company process limitation, I can't do it now. So please handle it as an evil merge. At the same time, we are trying to solve this situation in our company internally so that we can do it as you said in future. But it can't be done in short time.


Issue with 'hidden' attribute in toggle when mobile only.

A recent bug has come in on a site with the latest version of the toggle, which adds the 'hidden' attribute.
The site was using the toggle on mobile only, and was using display:block along with media queries to make the toggled div always appear on desktop (and hide the toggle button).
The site also had css in place to hide anything with the hidden attribute with a 'display:none!important'.
The latest update where the hidden attribute was newly added to the div meant that this method of 'mobile-only toggle' broke and the navs were hidden on the live site.
From what I can see, this method of hiding filters/side-nav on mobile is a fairly common pattern, so we'll need to look at a fix for this?
If the toggle is visually available then the 'hidden' attribute isn't correct for AX, and may cause the nav to be skipped.
Any thoughts on an approach?  It's tricky if the panel's css is being controlled by the project's stylesheet.  Perhaps checking for visibility with offsetParent before adding the attribute?  Which feels quite fragile :(
cc @mjbp @Nick-StormID

Discussed that best option for this is to make the setting optional, and false by default to fix backwards compatibility.


Installation Steps does not function in Linux Min 20.3

sudo apt install hstr does not function!
Installation steps for Ubuntu in Mint does not function!
Can you make any packages that automatically invoke the Min-Installer?
How does one his software spread if it is not noob-friendly???

@OneOfLosers if package for apt is not available, use one of the options from below:

install compatible .deb from https://pkgs.org/search/?q=hstr
use .deb from compatible Debian distribution
install my PPA and update HSTR from there (if compatible)
build from the source

Thank you for your interest in HSTR!


Add smoke tests for existing components

Summary
We want to automatically test that each component loads and is rendered.
Approach

[ ] Home (index.tsx)
[ ] Profile
[ ] About

Notes
https://testing-library.com/docs/react-testing-library/example-intro/#quickstart

Test setup is seemingly faulty - Can't run .tsx test files for some reason.


bootstrap on linux arm64 host

Prebuilts tools for Linux arm64 hosts are coming. Roll them out in CHIP.

GN binaries now available:
https://chrome-infra-packages.appspot.com/dl/gn/gn/linux-arm64/+/latest


Add developer integration doc for embeds

targeting our still pending embed branch

We should update the Expo wrapper doc too (doesn't have to be part of this PR, but don't want to forget)


Rename overlay and conf files in Zephyr modules required for HWv2

Describe the bug
Some of the overlay and conf files in Zephyr modules will need to be renamed to match the requirement of HWv2

This hardly qualifies as a bug?

This will break the build once HWv2 gets merged. So maybe we can change this to an enhancement?

@mmahadevan108, is this still an open issue?


Investigate extending current WAL features

Look into different WAL flavours (ringbuffer etc)
Look into more efficient WAL encoding
Expose WAL events to tremor-script/-query?
...

we rewrote wal


Update README.md

Fix for Github enforcing space on htags in markdown :)

Coverage remained the same at 62.393% when pulling 382c4b0c61a956850776aedcc252f9918b0bf3c6 on LasseRafn:patch-1 into 4e4245b31f8fc3c3fb3840eecd58a7033542324f on tra:master.

Coverage remained the same at 62.393% when pulling 382c4b0c61a956850776aedcc252f9918b0bf3c6 on LasseRafn:patch-1 into 4e4245b31f8fc3c3fb3840eecd58a7033542324f on tra:master.

Thanks @LasseRafn


Update persistence-style.md

and add the missing the

Should have been a PR for akka and not for tegonal


Provide a default component library

Probably have the starter app use some pre-existing Tailwind component library like Flowbite or daisyUI. Need to see if those work well with server-side rendering or if they're mainly built for use with React/other SPA frameworks.

This is an excellent idea, esp since they are CSS based component libraries. From looking at both it seems daisyUI offers more abstraction then flowbite.

Perhaps it would be good to make something more tangible as a starter app then? Perhaps something such as a "todo" app or something else simple that can show off how components work?

That might be worthwhile. Right now the starter app is a combination of a new-app template and a demo/example app. Maybe it should be split up so the starter app gives you more of a blank template and there's a separate repo with a demo TODO app or something.

@jacobobryant I'm trying out daisy ui. What would be your approach to install it?
I understand that tailwind is added as binary.
Should I use CDN?

@nickdex, you can follow the standard daisyUI install instructions; they'll work just fine whether you're using the tailwind binary or if you've installed tailwind via npm. i.e. run npm i -D daisyui@latest, which will create package.json and package-lock.json files if you don't have them already; then edit resources/tailwind.config.js and add require('daisyui'), to your plugins array. I gave that a try just now  and it's already changed a bunch of styling in the starter app for me (e.g. background is dark blue instead of white).

I will say I'm kinda surprised by daisyUI's landing page:

In a Tailwind CSS project, you need to write utility class names for every element. Thousands of class names just to style the most basic elements.

I'm shocked the authors could have spent so much time with Tailwind and still misunderstand it this badly. The whole point of Tailwind is that you do style reuse via react components or the equivalent (plain functions in Biff's case). Unless the authors get that but they're still using that angle as a marketing ploy?
In any case, for both DaisyUI and Flowbite, I'll be interested to see how smooth it is to modify the built-in components' styles. It's easy to package up a bunch of defaults; it's harder to do that while still giving full control to the user. frameworks vs libraries basically... of course even if they're not easily modifiable, there's still a class of projects where that's OK. I'd just want to make sure anything that's packaged with Biff has a good modifiability story.

@jacobobryant I went with CDN to give it a try.
Molly try out standard steps for deployment
Daisy supports full override from tailwind classes (need to be added before tailwind script line, in case of CDN) and you would want to remove tailwind base (and likely components) styles . I wanted uniform look so that my effort is spent more on logic than style at current stage, daisy is doing good job for now.
I’ll update here if I run into edge case

For my React projects I've been using Flowbite as I find it more 'Tailwind-ish'. But the Daisyui aproach somewhat shortens the class list, and i've found that on Hiccup I prefer the shorter class list (in part because the dots make the list somewhat harder to read than whitespaces and in part due to lack of support of the excellent VSCode TailwindCSS plugins with Intellisense and docs for the class names).
If you want to add support for Daisyui and don't want to tinker with NPM, you can use this:
Tailwind-cli-extra
Regards.

@Peluko interesting, I'll take a look at that sometime.
FYI for long class lists I like to put them one-per-line (and sorted alphabetically):
[:div {:class '[max-w-screen-sm
                mx-auto
                p-3
                w-full]}
 ...]

And I've found a solution to make the TailwindCSS VSCode plugins to work with Hiccup, here Support for ClojureScript?.
So now I find it much more comfortable working with Tailwind.


Poly shape support

Amazing lib, but doens't have support for poly shapes :(
@msalo3 Do you have plans to implement that? would be amazing.

Honestly, I just don't have the time to even do upkeep on this library. Eventually, I want to get around to it, but it probably won't be anytime soon


Allow us to rewrite DisguiseMe in Nukkit?

Hey Falk,
I am Peter Jiang from FunCraft Team. We FunCraft are using Nukkit for our server in next generation. Nukkit is a Minecraft PE server software, we use it because it is written in Java , is more efficient and is able to carry thousands of players in one server. As our mini-games rewriting to adapt Nukkit, we need to rewrite  your DisguiseMe in Nukkit, and we will make it open-source in MIT License. Will you please you allow us?
Peter "DaMa" Jiang
26 Nov 2015
Note: For further information about Nukkit, visit https://github.com/Nukkit/Nukkit

The licensing on this project doesn't prevent you from doing that. You don't need any special permission from me.


How do we reference resources in YAML

There's no instructions on how to use or specify these resources in YAML

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

ID: ee4ec9d0-e0d5-4fb4-7c3e-b84abfa290c2
Version Independent ID: 3e2b80d9-30e5-0c48-49f0-4fcdfedf5eee
Content: Resources - Azure Pipelines
Content Source: docs/pipelines/process/resources.md
Product: devops
GitHub Login: @vtbassmatt
Microsoft Alias: alewis

@andyjlewis this should go on your backlog, I believe.

Does this mean YAML builds cannot be used by Pull Requests?  I can't authorize the temporary branch created by a Pull Request ahead of time.

You can, I am just pointing out that it is not documented or at least not well.  What I do as a work around is use the graphical one and convert it to YAML and copy the block that had the resource IDs.

I'd also appreciate more instructions around this. I've managed to do this before, but forgot how I did it. I remember it's necessary to use the graphical editor to set up the resource and then copy the result over to YAML, but when I go and Edit the Pipeline now, all I can see is the YAML and checkout tasks with no option of adding a new one graphically. Is it necessary to create a new temporary Pipeline, set the resource up there graphically, copy the ID, then discard the temporary one and use the ID in the YAML one? I don't think it was this contrieved the last time I did it, but maybe things have changed? Is this tracked for improvement somewhere?

In my case I needed the connections to a Maven repository so that's not possible without using the secrets.

This topic was refreshed from a YAML perspective recently. Closing this out.

Why is this closed? There does not appear to be any documentation on what parameters or how to use them when calling resources: in the yaml. Do we just guess? or do we have to dive into the code to try to work it out?

@calum-hunter Thanks for the quick follow-up. We're conducting an audit of open issues against at the moment and I mis-interpreted the full scope of the request.

resources: is documented in the schema, under templates, and under container jobs. That's all they do at the moment, so I'm not sure what more we could document there.
I left this open thinking we could document non-resources things like service connections, which I'm doing now.


[SILOptimizer] Don't diagnose unreachable instructions that belong to…

… no-return func
The pass is attempting to diagnose any user-written code that appears after the result of no-return function call. It has to skip any instructions that happen after the no-return call but are associated with it, such as alloc_stack to pass result of such call indirectly.
This helps to avoid extraneous diagnostics for synthesized code i.e. a result builder with buildExpression:
static func buildExpression<T>(_ e: T) -> T { e }

The following example would produce extraneous warning:
switch <value> {
case ...
default: fatalError()
}

because it is translated into:
switch <value> {
case ...
default: {
  var $__builderDefault = buildExpression(fatalError())
  $__builderSwitch = buildEither(second: $__builderDefault)
}
}

In such cases all instructions that follow fatalError() call are synthesized except to alloc_stack $Never which is passed to buildExpression, that instruction is anchored on the fatalError() itself which is where the diagnostic would point, which is incorrect.
Resolves: rdar://104775183

@swift-ci please test

@swift-ci please test


Deferred Animation builder to only modify mobjects after the animation is actually played

Passing a flag to .animate was a bit too complicated and would destroy the property aspect of it, now we can also use deferred as a property.
I split the _AnimationBuilder into two subclasses which fulfill their respective roles, whereas _ImmediateAnimationBuilder is the usual builder that we know and love and _DeferredAnimationBuilder is the new builder which actually is delaying the building of the state until the animation is played. I added an example to the documentation, I am not sure if I should add tests for that or what would be a useful test.
But first i would like to discuss the concept, i linked a documentation page for this.
https://manimce--3502.org.readthedocs.build/en/3502/reference/manim.mobject.mobject.Mobject.html?highlight=deferred#deferredexample
class MinimalExample(Scene):
    def construct(self):
        objects = []
        animations = []
        animations2 = []

        for i in range(10):
            m = Square().set_color(BLUE).set_fill(opacity=0.3).scale(0.5)
            objects.append(m)
            animations.append(ReplacementTransform(m.copy(),m))
            if i % 2 == 0:
                animations2.append(m.animate.set_color(GREEN))
            else:
                animations2.append(FadeOut(m))

        group = VGroup(*objects).arrange_in_grid()
        self.play(*animations, run_time=2)
        self.wait()
        self.play(*animations2, run_time=2)
        self.wait()

vs.
class Expected(Scene):
    def construct(self):
        objects = []
        animations = []
        animations2 = []
        l1 = []
        l2 = []

        for i in range(10):
            m = Square().set_color(BLUE).set_fill(opacity=0.3).scale(0.5)
            objects.append(m)
            animations.append(ReplacementTransform(m.copy(),m))
            if i % 2 == 0:
                l1.append(m)
            else:
                l2.append(m)

        group = VGroup(*objects).arrange_in_grid()
        self.play(*animations, run_time=2)
        self.wait()
        self.play(*[x.animate.set_color(GREEN) for x in l1],*[FadeOut(x) for x in l2], run_time=2)
        self.wait()```

Marked as draft, as requested by MrDiver internally.

Are there usecases for both the deferred and the immediate builder? I can see how the deferred one is useful. 🤔

Are there usecases for both the deferred and the immediate builder? I can see how the deferred one is useful. 🤔

It definitely broke a lot of tests when i only used the deferred one, so maybe there are a lot of edge cases where it's useful to have .animate i am not sure how changing the default to deferred would affect everything but i must say i also haven't looked to deep into why the tests are failing and assumed it was my sloppy implementation at that point.

I think the main benefit might lie in combination with AnimationGroup.
Such that you can build a list of animations with the deferred animation builder and then later on use them in an animation group for complex transitions which depend on the current state of the scene and not when the Mobjects were created.


Hidding dataTableContext components when hidden is true

Addressed this issue with regards to dataTableContext showing components even when hidden is set to true

@czwe-01 can you just return null when the props is hidden to avoid the tenary chaining.


Crash when including 'react-native-dialogflow'

Hey,
I have an empty react app with expo and when I add this line:
import { Dialogflow_V2 } from 'react-native-dialogflow';
(same with import { Dialogflow } from 'react-native-dialogflow'; )
The app crash and I have this error message :

Any ideas ?

I fixed the same issue by changing the package.json from 3.2.2 to 3.1.0. Deleting the module in node_modules, then running npm install.

@joe-pellegrino  your suggestion did not work.
I didn't try ejecting. Did you do something else?

@mitchhh22 I just got it working. I enacted what @joe-pellegrino said. changed package.json at root to "react-native-dialogflow": "3.1.0" then rm -r react-native-dialogflow in node_modules directory, then finally from the root dir of the project ran npm install
This lead to npm installing 3.1.0 and now the app doesn't crash on the Invariant Violation.... error

I get a crash too. I'm using expo, and I'm trying to avoid ejecting. I also included the infoPlist in the app.json like this
   "ios": { 			"bundleIdentifier": "com.yasmina.yasmina", 			"infoPlist": { 				"NSSpeechRecognitionUsageDescription": "Your usage description here", 				"NSMicrophoneUsageDescription": "Your usage description here" 			} 		},
Downgrading to 3.1.0 will stop that error, but will give you other errors if you used Dialogflow_V2


Issue with building box with -gcflags=all=-trimpath

When building a binary with -gcflags=all=-trimpath=path/to/workingdir ,
Walk method fails with a lstat trimmedpath/assetname: no such file or directory error.
is giving a absolute path when creating a box a workaround ?

This was a false alarm. Apologies.


Following Getting Started Instructions Gives Me Error

Following instructions here:
https://wasmcloud.com/docs/getting-started
I started the server with
wash up
and then opened a new shell, set the WASMCLOUD_CLUSTER_SEED env.var, and typed:
wash ctl get hosts
Error:
Failed to create NATS client
Caused by:
0: Failed to connect to NATS <IP_ADDRESS>:4222
No credentials file was provided, you may need one to connect.
1: failed to read root certificates: MissingOrMalformedExtensions

@bluesunrise Can you try without setting a cluster seed at all? Might want to run rm -f ~/.wash/host_config.json before you do that just to be safe as well

@thomastaylor312  I've tried several variations of resetting cluster seed, removing host_config.json, no success

NOTE: using a Mac and I installed with Homebrew
brew tap wasmcloud/wasmcloud
brew install wash

heya, @bluesunrise,
thanks for filing an issue.
Can you paste the output from running the commands below?
(assuming wash up is running):
uname -p
wash --version
echo $(bash -c "$HOME/.wash/downloads/nats-server --version")
nc -zv4 localhost 4222

i386
wash 0.15.1
nats-server: v2.9.14
Connection to localhost port 4222 [tcp/*] succeeded!

Interesting, I wonder what happens for something like this:
git clone https://github.com/nats-io/nats.rs \
&& cd nats.rs/async-nats \
&& cargo run --example kv```
That's the client library we use to connect to `nats`

also this might disable TLS if it's trying that by default:
wash ctl get hosts --ctl-host nats://<IP_ADDRESS>

The --ctl-host option didn't help, same error. Here is the output of the command above:
....
   Running `/Users/dtaylor/spin/wcloud/nats.rs/target/debug/examples/kv`
sue.color @ 1 -> blue
sue.color @ 2 -> green
sue.color @ 3 -> red
All keys: ["sue.color"]
KV stream name: OBJ_default
$KV.profiles.sue.color @ 3 -> red
$KV.profiles.sue.color @ 4 -> yellow
$KV.profiles.sue.color @ 5 ->
headers: HeaderMap { inner: {HeaderName { value: "KV-Operation" }: HeaderValue { value: ["DEL"] }} }
sue.color @ 6 -> purple (op: Put)
sue.food @ 7 -> pizza (op: Put)

Hey @bluesunrise, were you able to try wash ctl get hosts --ctl-host nats://<IP_ADDRESS> ? I'm curious if the NATS lib might be defaulting to TLS on your system for some reason, and whether specifying nats:// works around that

Hi @connorsmith256, The --ctl-host option didn't help, same error.
wash ctl get hosts --ctl-host nats://<IP_ADDRESS>
Failed to create NATS client
Caused by:
0: Failed to connect to NATS nats://<IP_ADDRESS>:4222
No credentials file was provided, you may need one to connect.
1: failed to read root certificates: MissingOrMalformedExtensions

Thanks for the extra info. I poked around a bit in the NATS source and discovered this snippet
Do you have root certs installed on your system?

Do you have root certs installed on your system?
I don't think so. I moved my .ssh directory and retested, still the same problem
I have used NATS quite a bit on another project on this machine, but I usually ran it in a container

Just checking in to see if this is still an open issue?

Unfortunately I gave up

Closing since this seems to have reached a dead end, this seems like a missing set of ca-certificates which should be resolved with
brew install<EMAIL_ADDRESS>

I just uninstalled wash, reinstalled, and the problem went away! (its been two months since I last tried)
"Congratulations on installing wash!  Shell auto-complete is available. For instructions on setting up auto-complete for your shell, please see 'https://github.com/wasmCloud/wash/blob/main/Completions.md'"
Thanks!


Update tooltip when hovering over emotes or images so wayland knows we're serious

Pull request checklist:

[ ] CHANGELOG.md was updated, if applicable

Description

Issue: tooltips are now bound to the window, they cannot appear outside of the window

Issue: boring_nick managed to somehow break ALL tooltips with this PR

Seems to have been fixed by Qt6


openbsd: __syscall is gone by now

We therefore need to use the provided libc stubs. This diff forces execute_syscall() to use the supplied function pointer as opposed of using __syscall.

I got to dig into this a bit. The easiest way to see missing coverage is to play with a program like this:
# cat text.txt
write(0xffffffffffffffff, 0x0, 0x0)
mmap(0x20000000, 0x1000000, 0x3, 0x1012, 0xffffffffffffffff, 0x0)

If both lines are uncommented the output is:
2023/04/23 12:36:45 parsed 1 programs
2023/04/23 12:36:46 executor [setup]
2023/04/23 12:36:46 executed programs: 0
2023/04/23 12:36:47 CALL 0: signal 477, coverage 5894 errno 9
2023/04/23 12:36:47 call #0: signal 477, coverage 5894
2023/04/23 12:36:47 call #1: signal 0, coverage 0
2023/04/23 12:36:47 extra: signal 70, coverage 229

If I have just the mmap line the output becomes:
2023/04/23 12:37:46 parsed 1 programs
2023/04/23 12:37:48 executor [setup]
2023/04/23 12:37:48 executed programs: 0
2023/04/23 12:37:48 call #0: signal 0, coverage 0
2023/04/23 12:37:48 extra: signal 0, coverage 0

So, when syz-manager runs its test with the mmap program above, it fails to collect coverage and refuses to work.
$  cd ./s/syzkaller/bin; ./syz-manager -config ../docs/openbsd/openbsd.cfg -debug
...
ifconfig: SIOCIFDESTROY: Device not configured
command 'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin ifconfig tap0 destroy': 256
[96ms] exec opts: procid=0 threaded=1 cover=0 comps=0 dedup=1 signal=1 timeouts=50/5000/1 prog=0 filter=0
spawned worker pid 44585
#0 [115ms] -> mmap(0x20000000, 0x1000000, 0x3, 0x1012, 0xffffffffffffffff, 0x0)
2023/04/23 20:46:40 machine check failed: got no coverage:
2023/04/23 12:46:39 SYZFATAL: Manager.Check call failed: machine check failed: got no coverage:


System-level installation via distros' package manager

Currently this project is available in the AUR (Arch Linux User Repository). However, with the move to Zim 1.0.0, the package is no longer maintained. Apparently there is some confusion as to how to package Zim now for global installation.
Is this still possible? Presumably the old installation script (PKGBUILD) is no longer valid. How would you recommend package managers distribute Zim?

@ericbn @protist I'd say the most proper way to package zimfw in an AUR package is using the manual installation, in fact, the PKGBUILDs in AUR are essentially packaging scripts, so the point is to package correctly the software following an appropriate files and folders structure. Then you are going to be able to install the package with pacman

@WyRe I think the manual installation is what we are attempting. As you say, I'm trying to point the manual install to an arbitrary directory instead of the default. However, I'm getting errors as per my previous comment.

@protist so are you creating a new package? or are you going to contribute to the existing one?

@WyRe If we can find a fix to this issue, I'd take over maintenance of the existing package that you link. Now that versions are being tagged here, I'd also create a stable package, i.e. zsh-zim.

I just noticed @Eriner took over maintenance of the -git package though, so perhaps that implies they are planning on fixing it? (I'm not sure when the adoption occurred, but there's been no update yet, and the package is still broken.)

@protist There was no adoption: Eriner had maintainer rights before the main maintainer resigned.

@busimus Ah right, my mistake. Wishful thinking!

@protist https://github.com/zimfw/zimfw/issues/368#issuecomment-578555915

[...] Now when I try to prepare the new 1.1.1 package, I get the following error:
$ zsh -c 'source zimfw.zsh install'
No modules defined in /home/test/.zimrc

I'm still not sure if I am confused. At step 4 of the plan mentioned previously, we would set global config files at /etc/zsh. Do we need to do this before source zimfw.zsh install at step 5? [...]

I'm not sure if you have to use source zimfw.zsh install when you are preforming a manual packaging. I'd say you don't have to.
@Eriner https://github.com/zimfw/zimfw/issues/368#issuecomment-578438611

[...] My understanding for a system-wide installation is that there should be just one ZIM_HOME directory that is used by all users. But only users with write access to this directory will be able to execute the "writing" actions mentioned. On the other hand, zimfw.zsh was not initially coded to be used by users with no write access to ZIM_HOME, so this is where it could need improvements. [...]

I'd say there should be one ZIM_HOME for each user in the system; I mean, you'll package the system-wide (default) config files in $pkgdir/etc/ and then each user has is own ZIM_HOME folder inside his home folder to store the zim user-space config files.

I'm not sure if you have to use source zimfw.zsh install when you are preforming a manual packaging. I'd say you don't have to.

@WyRe I think we're on the same page. Just to be explicit, if I understand correctly install is the command to git clone and place all the files in the right place. As per my previous comment, this appears to automatically pull and install the latest version, but for a package manager we'd prefer to "manually" install the files, pulling from a specifically-tagged release. For zim, I can't see a traditional directory structure in this repo that I can just manually copy to a directory for the package manager.

I'd say there should be one ZIM_HOME for each user

Isn't $ZIM_HOME where the actual zim system files are kept? This isn't for user config is it? Currently my $ZIM_HOME is set to /usr/lib/zim, but my config is at ~/.zimrc.

Just joining in on the conversation;

The current package in AUR with @Eriner as the maintainer; the zsh-zim-git; is a vcs pkgbuild; so as far as packaging goes there is no issue about version pulled being a specific version. (Obviously that functionality would be nice for a release package zsh-zim; but there is nothing of the sorts yet) I don't know if @Eriner is actively going to maintain the pkgbuild or he is there due to being the original author (and the other maintainer abandoned the package). I will argue that an AUR vcs package is more in the spirit of this project rather than a static release version pkgbuild; since you will get notification about updating granted the release candidate packaged is more than one month old.
Usually; for a pkgbuild; as mentioned before; we want to fetch the sources ourselves instead of using the built in pull commands from submodules. This would either be very actively maintained on the pkgbuild side (pull all the submodules independently in the sources array; and move them manually in the proper staging directories in the pkgbuild) or we can use the installing script to pull the git sources. In the end I don't know if that makes a huge difference; and the package maintainer needs to decode the install script to see what exactly is happening. The former option would increase visibility for the user as to what is going to be installed. The ladder requires much less attention.
From what I understand, $ZIM_HOME should point to /usr/lib/zimfw and nowhere else since that directory is for the full installation system wide. Zimfw uses $ZDOTDIR to store configuration files. It is an optional variable from base zsh; to point to where the files such as .zprofile and .zshrc are located. Most people leave this empty; which in zsh defaults to $HOME. The installation script does the same if this variable is not defined. The location changes from user to user. (Personally I set it to $XDG_CONFIG_HOME/zsh using /etc/zsh/zshenv). The only limitation is that this directory should be set in the file /etc/zsh/zshenv; since this line should be sourced before any userspace configuration is sourced. (If you put the line in any other file; you still have to have .zsh
It seems the installation script actively puts config files and scans $ZDOTDIR directory to check if other stuff are installed or not; and read the .zimrc to build modules or not. Which is a problem. From what I understand, (and I use a clean chroot to build packages) makechrootpkg creates a temporary user without a home directory that will build the package. What can happen is the ZDOTDIR could be set to /usr/share/zimfw; and the things like the following block would be resolved by using conflicts array.

  if grep -Eq '^[^#]*(source|\.).*prezto/init.zsh' ${ZSHRC}; then
    print -u2 -P '%F{red}x You seem to have prezto enabled. Please disable it.%f'
  elif grep -Eq '^[^#]*(source|\.).*/oh-my-zsh.sh' ${ZSHRC}; then
    print -u2 -P '%F{red}x You seem to have oh-my-zsh enabled. Please disable it.%f'
  elif grep -Eq '^[^#]*antibody bundle' ${ZSHRC}; then
    print -u2 -P '%F{red}x You seem to have antibody enabled. Please disable it.%f'
  elif grep -Eq '^[^#]*antigen apply' ${ZSHRC}; then
    print -u2 -P '%F{red}x You seem to have antigen enabled. Please disable it.%f'
  elif grep -Eq '^[^#]*(source|\.).*/zgen.zsh' ${ZSHRC}; then
    print -u2 -P '%F{red}x You seem to have zgen enabled. Please disable it.%f'
  elif grep -Eq '^[^#]*zplug load' ${ZSHRC}; then
    print -u2 -P '%F{red}x You seem to have zplug enabled. Please disable it.%f'

Another issue is manually building requires some preexisting zimrc and .zshrc as a list of modules to build. I don't know the best practice for those things when it comes to packaging. For example, I use powerlevel10k theme which requires it being installed as a submodule under the zim installation. We also have a systemwide installation for that package and I don't know how that would turn out for example.
For global installations; I would be against modifying files to make zimfw. Previously the packager did this in post installation hooks but it caused some unintended consequences in a lot of people. Instead; the installer should prompt 'Add this line to /etc/zsh/zprofile to enable zimfw` or something along the line after installation. And the template user config files can be dropped to /usr/share/zimfw in this case so each user can pull their own.

Also one thing i think about is how

Thank you for the input @bbaserdem.

Given this repo has started tagging versions, I was planning on creating a zsh-zim package in the AUR.

or we can use the installing script to pull the git sources

Yes, this was my original intention, if possible. From your other points, it looks like this may be quite difficult.
(BTW, I also use powerlevel10k, the stable version installed from the official repos, and just make the necessary symlinks to work with zim, i.e.
# ln -s /usr/share/zsh-theme-powerlevel10k /usr/lib/zim/modules/prompt/external-themes/powerlevel10k
# ln -s /usr/share/zsh-theme-powerlevel10k/powerlevel10k.zsh-theme /usr/lib/zim/modules/prompt/functions/prompt_powerlevel10k_setup

I'm not sure if this is useful to the discussion here though.)

I think what we would like from the devs would be with regards to packaging is;

(Not that important) Full list of external repositories that zim core modules need (as opposed to hunting them down in the install repository). Optionally; the ability to build the main part while specifying directories to find the submodules.
Clear way (such as specifying a list of directories for external modules) to utilize external modules (in my usercase it would be powerlevel10k; and a system installation of powerlevel10k points towards /usr/share/zsh-theme-powerlevel10k) as opposed to building/cloning such external themes within a zim directory.
A way to specify 'build for all submodules' so that a system level installation has everything a user needs.

This way we can write build script for system level installation, and adapt other system packages as submodules.

@protist this AUR package have been created ?

@grzesuav this package is unmaintained. There are no others; feel free to adopt if you can write a working one. I did not manage to get too far unfortunately.

Unfortunately I have never creating AUR packages so I doubt I could move further

So i have been doing some research here and it seems a bit doable. My only gripe is installing external modules. It seems that symlinks to ZIM_HOME/modules is not accepted; or is there a function I can use to compile a single module. Without such functionality; we can't install external modules after initial packaging; which is not my workflow.
I believe all I need is;

Custom location target for init.zsh. In a system installation; ZIM_HOME is not going to be writable for the user. It is actually the one dynamic file in ZIM_HOME (barring updates; but that would be handled by the package manager). If init.zsh can be put to ZDOTDIR instead by zimfw.zsh init; then it allows to compile all available modules during packaging; (using some extensime zimrc) but source only the files within the personal ZDOTDIR/.zimrc which users would create on their own. (This would require the line in _zimfw_build_init that is local -r ztarget=${ZIM_HOME}/init.zsh to be overriden with some commandline parameter instead.) The package would note that the main instructions would not work; and you would need a line source $ZDOTDIR/init.zsh instead of the block that ends with source $ZIM_HOME/init.zsh
Provide a function to run ztool (install version) on individual directories in the file path. By compiling it in it's default directory; then we can compile packaged modules outside ZIM_HOME. Not that crucial; this can be done by zcompile; but would be nice to have for consistency.
Able to automatically put external directories to init.sh; or at least allow symlinks to be traversed when generating using zimfw.zsh init.

This would allow for a system level installation; without having to modify the main zimfw script by the packager.

@bbaserdem, that's great investigation!
There's a tight relation between .zimrc, the modules subdirectory containing all modules installed, and init.zsh and login_init.zsh. If you change .zimrc, all the others will change with it. So either all go to a place writeable for the user, or none go (and then the user can only have a system-wide Zim configuration managed by root).
If we want users to have separate configurations, then I would make all of the above reside in a place that I would call ZIM_HOME, and let each user have it's own ZIM_HOME path.
The required changes for that are:

Look for .zimrc inside ${ZIM_HOME} (currently zimfw expects it to be in  ${ZDOTDIR:-${HOME}}/.zimrc).
Move zimfw.zsh to outside ZIM_HOME (currently it must reside there, and it's set inside init.zsh to be autoloaded on the first call to zimfw). This will be the only file not writeable by the user, and zimfw.zsh will be upgraded by the package manager.
Figure out a different way to have the zimfw function defined globally.
Make zimfw upgrade fail gently when zimfw.zsh it's not writeable by the user.

So I would stick with the items above to make Zim compatible with a package manager. Makes sense?
Below are some points that are still not clear to me:
The ztool array contains the code used by zimfw install and zimfw update for installing and updating the modules using zargs. It's there only to avoid having external files, so instead we can have a neat zimfw.zsh that is a one-file-with-all. The code defined in ztool is not responsible for zcompiling the scripts though. That is actually in the login_init.zsh file. What is not clear to me is: why would you want to be able to "compile packaged modules outside ZIM_HOME"?
The zimfw command works nicely if there are symlinked files inside a module directory. Not sure how it works if the module directory itself is a symlink, and it's not clear to me why would you need that, but that can be improved if needed.

The compile packaged modules outside ZIM_HOME is to have external plugins also managed by zim. For example; I'm using powerlevel10k prompt theme. What I currently do is have the line zmodule romkatv/powerlevel10k in my ${ZDOTDIR}/.zimrc; and zimfw.zsh clones that repository into the ${ZIM_HOME}/modules folder. Eventually; I would like to install the prompt theme using distro package manager (for me; it's using pacman. They are usually installed to locations such as /usr/share.
The ztool string has this line command git clone -b \${REV} -q --recursive \${URL} \${DIR} 2>&1 which I think is responsible for cloning all the mentioned repos into modules folder. I must have confused that with the zcompile function; because I was doing a cursory glance.
I tried some symlinks into the modules folder; but could not manage to have them autodetected. (I forgot which function I was using; but I will give this a better investigation some time)
The above items makes sense; I haven't thought of that direction (I was thinking of providing all the modules with packages; but providing the zimfw.zsh and letting it generate precompiled versions for users is also a very valid way to provide) but I can make a simple pkgbuild using the freedom in moving zimfw.zsh around.
Thinking about it; keeping local writeable copies of external modules makes more sense; as zimfw does zcompile on all the modules for speedup; not just the ones that come from zimfw.

Not sure if we should add to the scope of Zim the ability to manage modules installed externally. But this should work:
cd ${ZIM_HOME}/modules
ln -s /path/to/external external
print zmodule external >> ~/.zimrc

It will resolve the symlink when creating the init.zsh to contain source /path/to/external/init.zsh.
Good that there's a conclusion on how to proceed here. The package will provide the zimfw.zsh file, which will later install the modules in the user's ZIM_HOME.
The blocking issue is that for now zimfw.zsh cannot be moved around, and must reside in ZIM_HOME. This needs to be improved, and suggestions are more than welcome.

So the plan is in this comment above.
The blocking issue is that for now zimfw.zsh cannot be moved around, and must reside in ZIM_HOME. The solution I see for this is making it an autoloadable file named zimfw that must be in the fpath. According to Zsh's INSTALL:

Third-party autoloadable functions, including but not limited to completion functions, should be installed into the share/zsh/site-functions/ directory under the respective installation prefix.  That would typically be written as $(DESTDIR)$(PREFIX)/share/zsh/site-functions/ in a makefile.  If the third-party tool's $(PREFIX) is not the same as zsh's prefix, then that directory should be added to $fpath in zsh's initialization files.

So the changes would be:

Copy zimfw (currently zimfw.zsh) to $(DESTDIR)$(PREFIX)/share/zsh/site-functions/ during installation.
Add an autoload -Uz zimfw line to ${ZIM_HOME}/init.zsh (line is currently zimfw() { source ${ZIM_HOME}/zimfw.zsh "${@}" })

But I have no idea on how to resolve $(DESTDIR)$(PREFIX) in out installation script. (We'll also need to resolve it in a possible migration script.) Anyone? @Eriner?

Just FYI, I've made an effort towards packaging of a system-wide installation of Zim: https://aur.archlinux.org/packages/zsh-zim-git/
It took some patching of zimfw.zsh, but I it works so far.

Just FYI, I've made an effort towards packaging of a system-wide installation of Zim: https://aur.archlinux.org/packages/zsh-zim-git/
It took some patching of zimfw.zsh, but I it works so far.

Now the zshrc template in our installation script automatically downloads the zimfw script if it's missing. See the new lines here. With this change, only updating the ~/.{zshenv,zshrc,zlogin,zimrc} files is enough to have Zim installed. Maybe Zim's arch package could only touch those files and leave the rest to the automation that happens inside zshrc.

Thanks for the notification. The point of that package is to have one system-wide Zim installation with its version pinned. All Zim updates are controlled by package manager then. The automation you have there, is not actually something which I would like to have in the package. For example, it prevents installing of Zim on machines without an internet access. Because of it, I actually need to trick Zim that everything is already in place and pre-compile zwc files during installation. If you have any advice how to package Zim in a cleaner way, I'd appreciate that.
I guess that change is good for per-user Zim installations for users which want to receive auto-updates directly from your repository.

Hi @carbolymer. If the ${ZIM_HOME}/zimfw.zsh file already exists, then the automated download will not happen. If Zim's arch package guarantees that file is already in place, then it's all fine.

I think the right way to have a system-level installation of Zim, that can be managed by a package manager is:

Copy zimfw (currently zimfw.zsh) to /usr/local/share/zsh/site-functions/ during installation (currently copying it to ${ZIM_HOME}).
Add an autoload -Uz zimfw line to ${ZIM_HOME}/init.zsh (line is currently zimfw() { source ${ZIM_HOME}/zimfw.zsh "${@}" }).
Either symlink zmodule to zimfw in /usr/local/share/zsh/site-functions/ and then also add autoload -Uz zmodule line to ${ZIM_HOME}/init.zsh, or stop letting users call zmodule via command line (I'm thinking the latter solution is simpler and preferable).

Maybe I can make changes that will either accept having a ${ZIM_HOME}/zimfw.zsh or a /usr/local/share/zsh/site-functions/zimfw file. In the latter case, I'm thinking maybe the zimfw upgrade command should be disabled.
@Eriner, @carbolymer, thoughts?

This approach makes sense to me.

(I'm thinking the latter solution is simpler and preferable).

Yep, agreed.

changes that will either

Yes - user local copy should be preferred. In case a system ${0}, yes probably best left to the package manager.

Just released zimfw v1.14.0 which allows having zimfw.zsh outside ZIM_HOME.
For example, it can be installed/downloaded into /usr/local/bin/zimfw.zsh and then your ~/.zshrc should look like:
ZIM_HOME=${ZDOTDIR:-${HOME}}/.zim
# Install missing modules and update ${ZIM_HOME}/init.zsh if missing or outdated.
if [[ ! ${ZIM_HOME}/init.zsh -nt ${ZIM_CONFIG_FILE:-${ZDOTDIR:-${HOME}}/.zimrc} ]]; then
  source /usr/local/bin/zimfw.zsh init -q
fi
# Initialize modules.
source ${ZIM_HOME}/init.zsh

The only change is:
-  source ${ZIM_HOME}/zimfw.zsh init -q
+  source /usr/local/bin/zimfw.zsh init -q

The general idea is to have as many ZIM_HOMEs as there are .zimrc configurations, and to have a single /usr/local/bin/zimfw.zsh script that can be used by all users in the machine.
I think package managers should only care about installing/updating /usr/local/bin/zimfw.zsh. They can help instructing the current user on how bootstrap their ~/.zimrc and ~/.zshrc.
Alternatively, the current user might want to have a ZIM_HOME that will be shared with other users in the machine. Package managers can also offer this alternative during the bootstrap instructions. See https://github.com/zimfw/zimfw/issues/486#issuecomment-2189606457

Thanks @ericbn . The remaining problem is, when doing zimfw.zsh build (or install) it hardcodes paths to the working directory during packaging process in init.zsh. So when I'm preparing an Archlinux package in some workspace directory in my home, my created init.zsh looks like this:
if (( ${+ZIM_HOME} )) zimfw() { source "${HOME}/workspace/aur/zsh-zim-git/pkg/zsh-zim-git/usr/lib/zim/zimfw.zsh" "${@}" }
fpath=("${HOME}/workspace/aur/zsh-zim-git/pkg/zsh-zim-git/usr/lib/zim/modules/git/functions" "${HOME}/workspace/aur/zsh-zim-git/pkg/zsh-zim-git/usr/lib/zim/modules/utility/functions" "${HOME}/workspace/aur/zsh-zim-git/pkg/zsh-zim-git/usr/lib/zim/modules/duration-info/functions" "${HOME}/workspace/aur/zsh-zim-git/pkg/zsh-zim-git/usr/lib/zim/modules/git-info/functions" "${HOME}/workspace/aur/zsh-zim-git/pkg/zsh-zim-git/usr/lib/zim/modules/zsh-completions/src" ${fpath})
autoload -Uz -- git-alias-lookup git-branch-current git-branch-delete-interactive git-branch-remote-tracking git-dir git-ignore-add git-root git-stash-clear-interactive git-stash-recover git-submodule-move git-submodule-remove mkcd mkpw duration-info-precmd duration-info-preexec coalesce git-action git-info
source "${HOME}/workspace/aur/zsh-zim-git/pkg/zsh-zim-git/usr/lib/zim/modules/environment/init.zsh"
source "${HOME}/workspace/aur/zsh-zim-git/pkg/zsh-zim-git/usr/lib/zim/modules/git/init.zsh"
source "${HOME}/workspace/aur/zsh-zim-git/pkg/zsh-zim-git/usr/lib/zim/modules/input/init.zsh"
source "${HOME}/workspace/aur/zsh-zim-git/pkg/zsh-zim-git/usr/lib/zim/modules/termtitle/init.zsh"
source "${HOME}/workspace/aur/zsh-zim-git/pkg/zsh-zim-git/usr/lib/zim/modules/utility/init.zsh"
source "${HOME}/workspace/aur/zsh-zim-git/pkg/zsh-zim-git/usr/lib/zim/modules/duration-info/init.zsh"
source "${HOME}/workspace/aur/zsh-zim-git/pkg/zsh-zim-git/usr/lib/zim/modules/asciiship/asciiship.zsh-theme"
source "${HOME}/workspace/aur/zsh-zim-git/pkg/zsh-zim-git/usr/lib/zim/modules/completion/init.zsh"
source "${HOME}/workspace/aur/zsh-zim-git/pkg/zsh-zim-git/usr/lib/zim/modules/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh"
source "${HOME}/workspace/aur/zsh-zim-git/pkg/zsh-zim-git/usr/lib/zim/modules/zsh-history-substring-search/zsh-history-substring-search.zsh"
source "${HOME}/workspace/aur/zsh-zim-git/pkg/zsh-zim-git/usr/lib/zim/modules/zsh-autosuggestions/zsh-autosuggestions.zsh"

In other words, I need to run zimfw.zsh install in a different directory than the modules and $ZIM_HOME will live in the end.
To work around this, I'm patching those paths to point to ${ZIM_HOME} instead: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=zsh-zim-git#n68
Would it be possible to make those paths relative to $ZIM_HOME, or configurable somehow?

Hi @carbolymer. I know the zsh-zim-git package exists since early days of Zim. I'd like to propose a new approach for packaging Zim starting with the v1.14.0 release:

The zimfw.zsh script is packaged, but not the contents of ZIM_HOME. The script can be downloaded from https://github.com/zimfw/zimfw/releases/download/{version}/zimfw.zsh and there's no need to clone the whole zimfw repo during packaging, if that's simpler. Ideally the package version follows the zimfw release version, in case packages can be versioned.
Not sure where the zimfw.zsh script should be installed by the package. I'm thinking /usr/local/bin (but it's not an executable, does not need to be in the path), /usr/local/opt or /usr/local/share. Suggestions and clarifications are more than welcome here. It's possible that different package managers choose different starting paths here, which is fine (I know different distributions of homebrew do vary between {/usr/local,/opt/homebrew,/home/linuxbrew/.linuxbrew}).
The package either prepends the templates to the user's own ~/.zshrc and ~/.zimrc, prints instructions on how the user can do it manually, or provides instructions somewhere the user would go for more information (more on this below).
In case the package includes the zshrc and zimrc templates as part of the package itself or as part of its own documentation:

The zimrc template can be taken from the install repo: https://raw.githubusercontent.com/zimfw/install/master/src/templates/zimrc
If the zshrc template is taken from the install repo (https://raw.githubusercontent.com/zimfw/install/master/src/templates/zshrc), the following changes need to be made:@@ -94,19 +94,9 @@ ZSH_HIGHLIGHT_HIGHLIGHTERS=(main brackets)
 # ------------------

 ZIM_HOME=${ZDOTDIR:-${HOME}}/.zim
-# Download zimfw plugin manager if missing.
-if [[ ! -e ${ZIM_HOME}/zimfw.zsh ]]; then
-  if (( ${+commands[curl]} )); then
-    curl -fsSL --create-dirs -o ${ZIM_HOME}/zimfw.zsh \
-        https://github.com/zimfw/zimfw/releases/latest/download/zimfw.zsh
-  else
-    mkdir -p ${ZIM_HOME} && wget -nv -O ${ZIM_HOME}/zimfw.zsh \
-        https://github.com/zimfw/zimfw/releases/latest/download/zimfw.zsh
-  fi
-fi
 # Install missing modules, and update ${ZIM_HOME}/init.zsh if missing or outdated.
 if [[ ! ${ZIM_HOME}/init.zsh -nt ${ZIM_CONFIG_FILE:-${ZDOTDIR:-${HOME}}/.zimrc} ]]; then
-  source ${ZIM_HOME}/zimfw.zsh init -q
+  source /path/to/zimfw.zsh init -q
 fi
 # Initialize modules.
 source ${ZIM_HOME}/init.zsh

By /path/to/zimfw.zsh I mean the path that was decided in step 2. Ideally this is the only patch the package would need to do anywhere.

It's fine to opt for minimal templates instead. I suggest:

zshrc (replace /path/to/zimfw.zsh by the path decided in step 2):ZIM_HOME=${ZDOTDIR:-${HOME}}/.zim
# Install missing modules, and update ${ZIM_HOME}/init.zsh if missing or outdated.
if [[ ! ${ZIM_HOME}/init.zsh -nt ${ZIM_CONFIG_FILE:-${ZDOTDIR:-${HOME}}/.zimrc} ]]; then
  source /path/to/zimfw.zsh init -q
fi
# Initialize modules.
source ${ZIM_HOME}/init.zsh

zimrc:zmodule environment
zmodule input
zmodule utility

# Prompt
zmodule duration-info
zmodule git-info
zmodule asciiship

# Completion
zmodule zsh-users/zsh-completions --fpath src
zmodule completion

# Modules that must be initialized last
zmodule zsh-users/zsh-syntax-highlighting
zmodule zsh-users/zsh-autosuggestions

It's also totally fine to not include any template and just refer to our README.md or the documentation in our website for the user to follow along with the manual steps to configure their ~/.zshrc and ~/.zimrc.

I'm willing to update our README.md and our website to also specifically contain instructions on how to install zimfw in Arch Linux. We can work together on that and any manual steps the user needs to take can be included there.
I appreciate all the work that has been done to package Zim for Arch Linux. The idea is to have zimfw.zsh now ready to be packaged and to have clear plan on how users should use the packaged zimfw.zsh that makes sense and does not require any patching (unless for the zshrc template as described above). I'm sorry if this means more breaking changes, but hopefully they should be less frequent in the future.

Thanks @ericbn . The zshrc template you suggest is downloading and installing modules from github, correct?

@carbolymer, correct!

So from the point of a packaging process that's a significant security concern. I would not want my super user to download arbitrary scripts from the internet and execute them, just to install zimfw modules.
What would be the best, is to have a zimfw tarball available, with all its constituents available to ease creating of a linux distribution package. Such package should be able to install full zimfw, with check-summing of its components, without the requirement of an internet access. This is necessary for example for air-gapped environments.
Automatic downloading of all neccessary stuff during zim initialization is a cool feature, but it would be good to have an alternative to that.

I see. Not sure if the security issue would be in making the user download the Zim modules after the zimfw.zsh instalation on one hand, or if making the user use sudo to install or update modules later on the other hand, but that's a separate discussion.
If you want to continue to package Zim with zimfw.zsh plus the contents of ZIM_HOME, make sure you build the package outside the current user's HOME directory, so the init.zsh does not contain unexpanded references to ${HOME}.


Optimism pool is broken (noNetwork)

Describe the bug
could not detect network (event="noNetwork", code=NETWORK_ERROR, version=providers/5.7.2)

Terminal
Failed to load resource: net::ERR_CONNECTION_CLOSED
_app-e44f9b7fec30e000.js:1 Uncaught (in promise) Error: missing revert data in call exception; Transaction reverted without a reason string [ See: https://links.ethers.org/v5-errors-CALL_EXCEPTION ] (transaction={"to":"0x7F5c764cBc14f9669B88837ca1490cCa17c31607","data":"0x70a082310000000000000000000000006d91e35d502fb6f654992283e6e4f397fc23dc2c","accessList":null}, code=CALL_EXCEPTION, version=providers/5.7.2)
at y.makeError (_app-e44f9b7fec30e000.js:1:2396737)
at y.throwError (_app-e44f9b7fec30e000.js:1:2396857)
at _app-e44f9b7fec30e000.js:1:2445434
at Array.forEach ()
at k. (_app-e44f9b7fec30e000.js:1:2445249)
at Generator.next ()
at s (_app-e44f9b7fec30e000.js:1:2437716)

Error updated to this

Working for me, probably a network issue at that time. Or we did some fixes in the last couple of days.


refactors for the x86 SIMD kloop kernel selection

Looks good to me, just a couple of nits pertaining to superfluous code duplication.


ABSL_PROPAGATE_CXX_STD does not set standard correctly

Abseils ABI depends on the standard version used to compile (e.g. around string_view), so propagating the standard requirement of the produced binaries should reflect the standard used to compile. Currently it is set to the meta-feature cxx_std_11 unconditionally.
It might also be a good idea to add this to the windows DLL build.

This should have been closed by https://github.com/abseil/abseil-cpp/commit/308bbf300fe9332130f4784c7a91fa2ad707d6e4, but AFAICT, the C++ standard is not propagated for shared windows builds (see CMake/AbseilDll.cmake), c.f. also the diff of https://github.com/abseil/abseil-cpp/pull/1117
CC @coryan

Doh!  Apologies.  I have prepared a change in the internal SCM.  I expect I should be able to send it for review later today.

@h-vetinari let me know if the changes don't work.

@h-vetinari let me know if the changes don't work.

Thanks for the super-quick handling! :)


Add new extract dev command to retrieve old versions of formulae

[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?
[ ] Have you written new tests for your changes? Here's an example.

[ ] Have you successfully run brew tests with your changes locally?

This is my first time contributing to Homebrew/brew and in fact my first time ever writing Ruby outside of the Homebrew and Homebrew-Cask DSLs. So please bear with me - there's probably parts of this PR that are unidiomatic if not downright ugly. I may have re-invented the wheel a few times too.
This PR introduces the start of a brew extract command, intended to address #4055. It extracts the formula file for a specified formula that matches a given version and makes a copy of the file into the Formula subdirectory of a specified tap.
The syntax is along the lines of brew extract <formula> <version> <tap> and the new file is placed at<EMAIL_ADDRESS>If the file already exists at that path, it will not overwrite the file unless --force is specified.
In it's current state, something is wrong with how I'm getting the "next-most recent" commit/revision to be considered. After a few iterations of searching via an until loop, the revisions are all empty, although if I write out a single iteration from the last good revision that it gave me, it'll still return me the proper next commit hash. It's almost as if the Git-querying part of the code stops responding after a certain amount of iterations in the loop but works perfectly fine outside of it. It's possible that I'm just overlooking some trivial Ruby-ism right now that's causing this, of course.

As a demonstration, the following command will work properly:

• brew extract --debug libogg 1.3.2 homebrew/core
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
==> Trying 1.3.3 from revision HEAD against desired 1.3.2
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
==> Trying 1.3.3 from revision ddb386b against desired 1.3.2
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
==> Trying 1.3.3 from revision f64a373 against desired 1.3.2
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
==> Trying 1.3.2 from revision 16ebe5f against desired 1.3.2
==> Writing formula for libogg from 16ebe5f to<EMAIL_ADDRESS>

but the following will not:

• brew extract --debug libogg 1.3.1 homebrew/core
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
==> Trying 1.3.3 from revision HEAD against desired 1.3.1
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
==> Trying 1.3.3 from revision ddb386b against desired 1.3.1
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
==> Trying 1.3.3 from revision f64a373 against desired 1.3.1
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
==> Trying 1.3.2 from revision 16ebe5f against desired 1.3.1
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
==> Trying 1.3.2 from revision b100d2d against desired 1.3.1
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
==> Trying 1.3.2 from revision 23d09e4 against desired 1.3.1
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
==> Trying 1.3.2 from revision 8b378fd against desired 1.3.1
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
==> Trying 1.3.2 from revision 5ac836a against desired 1.3.1
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
==> Trying 1.3.2 from revision 893cd40 against desired 1.3.1
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
==> Trying 1.3.2 from revision 1fda5d2 against desired 1.3.1
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
==> Trying 1.3.2 from revision f4bd9ce against desired 1.3.1
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
==> formulae require at least a URL in libogg at revision 61b2307
/usr/local/Homebrew/Library/Homebrew/formula.rb:244:in `determine_active_spec'
/usr/local/Homebrew/Library/Homebrew/formula.rb:197:in `initialize'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:82:in `new'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:82:in `get_formula'
/usr/local/Homebrew/Library/Homebrew/formulary.rb:327:in `from_contents'
/usr/local/Homebrew/Library/Homebrew/formula_versions.rb:40:in `block in formula_at_revision'
/usr/local/Homebrew/Library/Homebrew/utils.rb:425:in `nostdout'
/usr/local/Homebrew/Library/Homebrew/formula_versions.rb:40:in `formula_at_revision'
/usr/local/Homebrew/Library/Homebrew/cmd/extract.rb:37:in `extract'
/usr/local/Homebrew/Library/Homebrew/brew.rb:87:in `<main>'
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FormulaContentsLoader): loading /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/libogg.rb
==> Trying 1.3.3 from revision  against desired 1.3.1
Error: Could not find libogg 1.3.1.
/usr/local/Homebrew/Library/Homebrew/utils.rb:60:in `exit'
/usr/local/Homebrew/Library/Homebrew/utils.rb:60:in `odie'
/usr/local/Homebrew/Library/Homebrew/cmd/extract.rb:39:in `extract'
/usr/local/Homebrew/Library/Homebrew/brew.rb:87:in `<main>'

Other functionality that I've considered but am not sure whether or not would be a good idea to implement:

Allowing user to pass a git ref instead of a version (e.g. brew extract foo 1d9f4c3 homebrew/custom)
Searching through legacy homebrew repo(s) or user-specified taps as well (instead of just Homebrew/homebrew-core)
--stdout flag or something like that to just dump the formula on the terminal instead of to a file

Fixes #4055

Run brew man and commit the results. Would also be good to have an integration test for this (like others in Library/Homebrew/test/cmd/)

Should this be a dev command like create, edit and tap-new?

Should this be a dev command like create, edit and tap-new?

@commitay Yep 👍

Reworked the code based on the nitpicks above. A UsageError is now raised if the wrong number of (named) arguments are provided (expect three when writing to tap, two when writing to stdout). A regular odie is thrown if the user tries to specify a tap and also use --stdout at the same time. This guards and simplifies me from having to ... unless <var>.nil? the three arguments separately.
Also generated and committed the manpages for the command. Tests still need to be written after we actually get the command working. The issue I originally stated regarding the strange behavior of last_revision_commit_of_file(repo, file, before_commit: nil) just not returning anything after a certain number of iterations is still happening.

stdout option is now removed (a tap must be specified via --tap=). The version is now optional (can be specified via --version=) and the most recent is taken if no version is specified. If the specified tap happens to be homebrew/core, it also bails. Message for re-running with --force now spans another line and should be within 80 chars. Lastly, cleaned up the class name generation part. We now perform just one gsub! in order to actually replace the first line of the file.
Still two major issues with this code as it stands:

Does not work at all with formulae that have been deleted. I think we'll have to stop relying on FormulaVersions and rely solely on Git.last_revision_commit_of_file(repo, file, before_commit: nil) and Git.last_revision_of_file(repo, file, before_commit: nil) to get those. It would be great if there would be some easy way to extract and compare the version from the file contents. I tried this and the only way I could think of was to put the contents of the last revision into a temp file and have Formulary read it from a path and see if it's the right version before deciding whether or not to dig further in the history. Hopefully there's a less kludgy way to go about this that I just don't know about.
Still have issues with Git.last_revision_commit_of_file(repo, file, before_commit: nil) deciding to stop working at times inside of loops.

Thanks @alebcay! I'll make a note to have a look at the Git stuff when I get a chance.

I may have made some headway on that Git issue:
[34] brew(main)> resolver.formula_at_revision("1fda5d2") { |f| f.version }
=> #<Version::FromURL:0x00007f9100a747f0 @version="1.3.2">
[35] brew(main)> resolver.formula_at_revision("9274aca") { |f| f.version }
=> nil

(9274aca is the next most recent commit after 1fda5d2 to have modified the formula in question - in this case, libogg)
At some point in the revision history, FormulaVersions.formula_at_revision(rev) is unable to get the version from the formula anymore.

As another example, automake only has one "good" revision (1e1a871) before we have the same issue (61dae90):
[10] brew(main)> resolver.formula_at_revision("1e1a871") { |f| f.version }
=> #<Version::FromURL:0x00007fbdbb51dff8 @version="1.16.1">
[11] brew(main)> resolver.formula_at_revision("61dae90") { |f| f.version }
=> nil

@alebcay It may be the older versions are invalid formulae i.e. use methods that have been since removed?

That's what I thought at first too, but the difference between working and non-working revisions of formulae is minute - the sha256 of the bottle being updated is somehow able to break things (in libogg's example).
Is there some kind of logic we could use to extract the URL from the formula file without constructing a proper Formula object, or better yet, easily extract the version from the URL from said formula? The first rather kludgy idea was to look for lines beginning with url and get the URL that way, but it's not very versatile since formulae can have resource blocks with URLs too.

Another progress update - I've gotten the problems out of the way now, mostly by ignoring missing methods (sha1, md5) in Module and BottleSpecification. Right now, this code can go as far back as this commit before running into issues. Any ideas on how to reconcile/handle those older formulae, or are they just so old that I shouldn't bother?

Made a feeble attempt at using Ruby refinements instead of just monkeypatching. In this state they don't work (it complains about sha1 etc. not found on older formulae, which is what the monkeypatches fixed). I'm probably overlooking some nuance of refinements, but figured I'd update my progress here instead of just banging my head on the wall.

Oh right! The refinements are scoped, so it won't work if a missing method on a BottleSpecification gets called from another file. 🤦♂

Would it be all right just to do a monkey-patch like before then?

All right, another batch of changes! This version now works on formulae as old as the homebrew-core repo itself (i.e. all the way back to the initial commit in the repo). I'll also get around to starting on writing up spec/tests.

@alebcay Can you rebase this on master? Thanks! Not sure why the tests aren't running but that'll fix it.

Done, looks like the tests are running now.

@alebcay brew style is failing unfortunately.

The spec/integration test is now written. Probably not idiomatic, but functional and actually tests stuff. There are still two style violations, both regarding that super should be used in def method_missing(*), while I think we came to the agreement that it should just be a no-op, lest I do some kludging to squeeze in a super call in some unreachable code somehow.

All style issues should be fixed now. I heavily reduced/combined the integration tests. The corner cases would indeed probably do better in a unit test. I have considered refactoring parts of the logic in this feature out of dev-cmd (into somewhere else in the core tree), but figured that it really isn't much use to anyone/anything else at the moment.

@alebcay The code looks good! Feedback from having run it and some suggested, very small final changes.

brew extract inkscape homebrew/bundle pauses for a long time before failing with Error: inkscape: undefined method sha1' for #Resource::PatchResource:0x000000010207cc88. That error might want to be addressed but I'd suggest at least making it print a message (with ohai`) indicating that it's e.g. searching the Git history?
brew extract wget homebrew/bundle --version=1.16.1 worked as expected but brew install<EMAIL_ADDRESS>failed due to undefined method sha1' for #Class:0x00000001011dafe0. I wonder if it's worth stripping the bottle blocks or e.g. sha1` etc.? I think it's fine to say "good idea for a follow up PR (by someone else)".
brew extract wget homebrew/bundle --version=1.19.2 and brew install<EMAIL_ADDRESS>worked as expected.
I think it's worth adding a reference to this command in https://github.com/Homebrew/brew/blob/master/docs/Versions.md. That's exactly the type of resource we point people to to justify why we won't provide every version; it'd be perfect to recommend it there.

brew extract inkscape homebrew/bundle pauses for a long time before failing

Added a progress message. The failure was because we needed to monkey-patch method_missing(*) in PatchResource. I just did the monkey-patch on Resource instead to cover any other corner cases where resource checksums were sha1 instead of sha256. If you can think of anywhere else in the codebase where we've been using checksums and have upgraded from sha1/md5 to sha256, they also probably need a monkey-patch.

brew extract wget homebrew/bundle --version=1.16.1 worked as expected but brew install<EMAIL_ADDRESS>failed

I suppose a question to ask is - how usable are we expecting formula that this churns out to be? We could certainly strip sha1/other missing blocks, but edits would have to be made to add a sha256 block too, right? I think it's beyond the scope of this command (and definitely outside of the scope of this PR) to have the extract command not only retrieve, but also format old Homebrew stanzas/replace them with modern alternatives. At least, I was under the assumption that the formulae that are churned out here are "use at your own risk" or "needs some fixing up" by the end user. I'm already a bit concerned that we're packing a lot of logic into a single command, and if we were to add this other stuff, I think it may warrant refactoring some of the stuff out of dev-cmd.
I'll get around to putting a word in the docs about the command.

For unit-testing, the monkey-patches should be reversible.

Where would this thing go? In the extract_spec.rb, and I'd just call it?

Where would this thing go?

Loading the formula would happen inside with_monkey_patch, so the monkey-patch is only active when loading an old formula.

Done, although tests are failing because the new monkey-patch doesn't work now with HOMEBREW_NO_COMPAT=1:
Error: uninitialized constant DependencyCollector::Compat

Should I just guard the monkey-patch to check the env variable, or just require the relevant file?

You could check for defined?(DependencyCollector::Compat).

Thanks for all the hard, great work here @alebcay!

To be clear, I don't mind stripping old stuff out of the resulting formulae, but I just don't feel that it's much of an improvement if we don't replace them with their modern equivalents - and that part is considerably more complicated.

Agreed this can be done in a future PR if someone needs it (and not necessarily by you).

I'll get around to putting a word in the docs about the command.

That'd be great, thanks!


Anchoring Control nodes doesn't take scale into account

Tested versions

Reproducible in 4.3beta1, 4.2.2 stable

System information
Godot v4.2.2.stable - Nobara Linux 40 (KDE Plasma) - Wayland - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4060 Laptop GPU () - AMD Ryzen 7 7735HS with Radeon Graphics (16 Threads)
Issue description
Choosing an anchor preset doesn't take the Control's scale into account. Trying to center a Panel with a scale of 5 to the left for example causes a huge offset. Scaling a panel then trying to center it via anchors causes a huge offset for example. It should instead take scale into account and try centering it properly.

I know scaling Controls isn't good practice but there are some situations where it would be useful to do so, like scaling up 9 patch rects so their borders are larger.
Steps to reproduce

Scale a control node
Try anchoring it
See unexpected results

Minimal reproduction project (MRP)
TestAnchor.zip

Thank you for reporting, consolidating in:

https://github.com/godotengine/godot/issues/19068

See there for more details, if you think something was missed about this and it's not the same issue, please comment here and it can be reopened


fix: fix default node home when exporting the state

Description
This PR fixes the initialization of the app when running the export command so that CosmWASM files can be read properly and its state can be exported correctly. Thanks to @webmaster128 for helping debugging this

Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...

[x] included the correct type prefix in the PR title
[ ] added ! to the type prefix if API or client breaking change
[x] targeted the correct branch (see PR Targeting)
[ ] provided a link to the relevant issue or specification
[ ] followed the guidelines for building modules
[ ] included the necessary unit and integration tests
[x] added a changelog entry to CHANGELOG.md
[ ] included comments for documenting Go code
[ ] updated the relevant documentation or specification
[x] reviewed "Files changed" and left comments if necessary
[x] confirmed all CI checks have passed

Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...

[ ] confirmed the correct type prefix in the PR title
[ ] confirmed ! in the type prefix if API or client breaking change
[ ] confirmed all author checklist items have been addressed
[ ] reviewed state machine logic
[ ] reviewed API design and naming
[ ] reviewed documentation is accurate
[ ] reviewed tests and test coverage
[ ] manually tested (if applicable)

@mergifyio backport release/v3.0.x


LogicException: Unable to register extension "nystudio107\typogrify\twigextensions\TypogrifyTwigExtension" as extensions have already been initialized

The error  happens only when I create a new site in cms and visit the new site url first time. after refreshing new site page, the error is gone.
Craft CMS: 3.7.46
craft-typogrify: 1.1.19
twig/twig: v2.14.11
app_1    | 2022-08-31 17:06:03 [-][-][lc1ecqiqhs91labk06orh1jote][error][LogicException] LogicException: Unable to register extension "nystudio107\typogrify\twigextensions\TypogrifyTwigExtension" as extensions have already been initialized. in /app/vendor/twig/twig/src/ExtensionSet.php:145
app_1    | Stack trace:
app_1    | #0 /app/vendor/twig/twig/src/Environment.php(701): Twig\ExtensionSet->addExtension()
app_1    | #1 /app/vendor/craftcms/cms/src/web/View.php(362): Twig\Environment->addExtension()
app_1    | #2 /app/vendor/nystudio107/craft-typogrify/src/Typogrify.php(62): craft\web\View->registerTwigExtension()
app_1    | #3 /app/vendor/yiisoft/yii2/base/BaseObject.php(109): nystudio107\typogrify\Typogrify->init()
app_1    | #4 /app/vendor/yiisoft/yii2/base/Module.php(161): yii\base\BaseObject->__construct()
app_1    | #5 /app/vendor/craftcms/cms/src/base/Plugin.php(115): yii\base\Module->__construct()
app_1    | #6 [internal function]: craft\base\Plugin->__construct()
app_1    | #7 /app/vendor/yiisoft/yii2/di/Container.php(419): ReflectionClass->newInstanceArgs()
app_1    | #8 /app/vendor/yiisoft/yii2/di/Container.php(170): yii\di\Container->build()
app_1    | #9 /app/vendor/yiisoft/yii2/BaseYii.php(365): yii\di\Container->get()
app_1    | #10 /app/vendor/craftcms/cms/src/Craft.php(61): yii\BaseYii::createObject()
app_1    | #11 /app/vendor/craftcms/cms/src/services/Plugins.php(948): Craft::createObject()
app_1    | #12 /app/vendor/craftcms/cms/src/services/Plugins.php(232): craft\services\Plugins->createPlugin()
app_1    | #13 /app/vendor/craftcms/cms/src/base/ApplicationTrait.php(1487): craft\services\Plugins->loadPlugins()
app_1    | #14 /app/vendor/craftcms/cms/src/web/Application.php(99): craft\web\Application->_postInit()
app_1    | #15 /app/vendor/yiisoft/yii2/base/BaseObject.php(109): craft\web\Application->init()
app_1    | #16 /app/vendor/yiisoft/yii2/base/Application.php(204): yii\base\BaseObject->__construct()
app_1    | #17 [internal function]: yii\base\Application->__construct()
app_1    | #18 /app/vendor/yiisoft/yii2/di/Container.php(419): ReflectionClass->newInstanceArgs()
app_1    | #19 /app/vendor/yiisoft/yii2/di/Container.php(170): yii\di\Container->build()
app_1    | #20 /app/vendor/yiisoft/yii2/BaseYii.php(365): yii\di\Container->get()
app_1    | #21 /app/vendor/craftcms/cms/src/Craft.php(61): yii\BaseYii::createObject()
app_1    | #22 /app/vendor/craftcms/cms/bootstrap/bootstrap.php(247): Craft::createObject()
app_1    | #23 /app/vendor/craftcms/cms/bootstrap/web.php(51): require('...')
app_1    | #24 /app/web/index.php(81): require('...')
app_1    | #25 {main}

I tried to print extensions here: https://github.com/twigphp/Twig/blob/v2.14.11/src/ExtensionSet.php#L422
The first time typogrify is not in extensions, so I got 500, after refreshing the page, typogrify is in extensions, and the page works.
Any idea why?
cc @khalwat

Something (most likely a plugin) has loaded before Typogrify, and has initialized Twig -- this is something plugins should not do until all plugins have loaded.
So while the error is thrown by Typogrify, the real error is something else (likely another plugin) doing something with Twig that causes it to initialize itself before Typogrify loads.


chore(master): release 0.21.0

:robot: I have created a release beep boop
0.21.0 (2023-05-25)
Features

add api key (9982791)
add api key (9982791)
add api key (13d98ca)
add assets with Swarm copy (#119) (77d243c)
add bee lifecycle management to tray (45a4648)
add electron tray (ee3a441)
add GET config endpoint (#25) (cfabe2c)
add header to onboarding overlay transaction request (#169) (b1a0179)
add installer (f81ede7)
add keep alive (#85) (5ff3d1b)
add light node upgrade (aad9a37)
add loading screens (0116bb0)
add logs button to tray menu (#289) (aaf5609)
add new assets and static (07ae295)
add new dashboard with xbzz features (fbe5d26)
add new endpoints for crypto onboarding (80e1b3d)
add new icons (#116) (7fe76a4)
add new static folder location (#95) (a6dd808)
add new static version and auto open ui (#113) (5d43eed)
add os agnostic build system (#34) (aef4ad8)
add peers endpoint (#93) (06fa3f4)
add reliable transfers (3653530)
add remix icons (ce32077)
add static api-key and dist (74b6e32)
add static serving for dashboard (eb6555a)
add support for bee 1.13 (#328) (2ff1b9f)
add swap-endpoint migration (#298) (6dbf2a6)
add token price endpoint (#175) (ea15234)
add top up flows (e22fe87)
add tray action to redownload assets (#87) (90514dc)
add ultra light node launcher (3c0754a)
add unauthenticated info endpoint (#52) (766ad50)
add winston logger with features commonly used in other JS Team projects (#35) (c3eb0a6)
asset version check (#132) (db2b4af)
auto update support (#146) (9e6f869)
bee 1.8 support and installer removal (#264) (35d0f30)
bundle static assets (#144) (b50438d)
change default server port number (#265) (9d42b8b)
code signing (#137) (7e5feca)
dashboard component integration (#240) (86d3859)
download and open installer first (#72) (c986e3d)
download resources during runtime (#63) (1de87fd)
expose desktop version (#129) (0e42b58)
find free port for app (9639279)
find free port for app (9639279)
find free port for app (befec02)
improve dashboard upgrade (1259750)
improved electron-reforger config (#147) (83bcf36)
migrate transaction and block-hash properties (#330) (25f0ba8)
only allow one instance running (#89) (5975b76)
persistant bee logs (#92) (7ccfd39)
persistant logs (#91) (0c5d67d)
rewrite the electron app in typescript (#26) (95e46c7)
sentry proxy (#112) (39bf2b4)
sentry support (#105) (29b9f24)
set initial deposit to 0.1 bzz (227a6cb)
splash screen (#182) (250af98)
top level error catch (#156) (a7afb4e)
update bee to 1.14.0 (#334) (512a982)
update bee-dashboard to latest (#309) (392ad56)
update installer and dashboard (f1a478f)
upgrade bee (#314) (a650be6)
upgrade bee to v1.14.1 (#338) (ef3834e)
upgrade bee to v1.15.0 (#341) (004b075)
upgrade bee to v1.16.0 (#359) (1590365)
upgrade bee to v1.16.1 (#361) (48d71fe)
upgrade bee-dashboard (#313) (afbdaf1)
upgrade to bee-dashboard v0.23.0 (#319) (32fd306)
upgrade-to-bee-1.12.0 (#321) (969feeb)
windows installer screen (#203) (6508cf7)

Bug Fixes

add beta password migration path (#239) (58d1a6a)
add cors-allowed-origins to config (7f0a27b)
add electronInstallerDebian (822a0e5)
add executableName (40062b2)
add faucet retry to installer (0541f5b)
add missing type declaration for fs-extra (#68) (dddf474)
add support for latest bee log (#107) (7726c1b)
auto update logger (#181) (079be52)
catch logs writing errors (#237) (a28f0ab)
change envPaths to Swarm Desktop (43b231d)
change resolve to resolvePath (#31) (99c5054)
change web url to localhost to match cors (e6d1e32)
copy installer for windows (#183) (4900169)
dashboard update (#212) (66036af)
dmg release dependency (#153) (61d4f90)
do not open restart (#104) (07718d4)
forward swap error to client (#297) (09b1f23)
hide dock icon (c4bce13)
installer: install estimate fix (#157) (87fafe6)
mainnet bee config (#269) (39164fc)
put password in config.yaml (#235) (6465fc0)
read current password when constructing v3 wallet (#261) (81699f4)
remove custom names (158068c)
remove ellipsis from main text (#174) (f165358)
remove suffix from envPaths (00ae128)
remove version alert (f3d55dd)
set author for building desktop app (#70) (bdccabf)
set executableName to be the same as name (c4bcb40)
set productName to Swarm (3013b29)
splash overflow hidden (#202) (7012f88)
squirrel startup test (#178) (df6c5b2)
support multiple file check when determining redownload (#102) (6b51c8b)
upgrade bee to apply hotfix (#316) (44c6dc3)
use sentry release only on linux release (#114) (308c28e)
use zip-all maker on os x (#60) (403aeb4)

Miscellaneous Chores

release 0.1.0 (b26f96b)
release 0.17.0 (cb0ca4d)
release 0.18.1 (5a5bc30)
release 0.19.0 (fc473ae)
release 0.19.1 (c3ad467)
release 0.19.2 (e729089)
release 0.21.0 (adc950e)

This PR was generated with Release Please. See documentation.

Thanks for the merge, it worked a threat 👍🏾👍🏾

:robot: Release is at https://github.com/ethersphere/swarm-desktop/releases/tag/untagged-099fe4d302ec5a705f6b :sunflower:


Board resource and window module

this might need some refining

That is much cleaner! sorry, I had to go to bed..