Version 0.4.1 of ijq has been released.

This is a small bug fix release. See the release notes here: https://git.sr.ht/~gpanders/ijq/refs/v0.4.1

Greg

On Mon, 01 Aug 2022 15:55 +0200, Peter Bridge wrote:
>Are these considered equal?
>
>const a = [_:0]u8{ '4', '2'};
>const b = [_]u8{ '4', '2'};
>
>I am not sure how I could even check the sentinels match, or if it 
>even matters :) but since I still have some custom string utils (some 
>with sentinels, and some without (wasm not C)), I want to also have 
>some tests to make sure they are adding/not adding sentinels in the 
>correct place.  But then I get index of of bounds...  Any tips on how 
>to test such functions please? Cheers Peter

"Equal" in what sense? They have different types, but they would compare

Version 0.4.0 of ijq has been released.

This is a minor feature release. See the [release notes][1] for a list
of changes.

Greg

[1]: https://git.sr.ht/~gpanders/ijq/refs/v0.4.0

---
 README.md                   |  2 +-
 contrib/vmt-completion.bash |  2 +-
 src/att.rs                  | 16 ++++++++--------
 src/cat.rs                  |  4 ++--
 src/mime.rs                 |  4 ++--
 src/pick.rs                 |  6 +++---
 src/show.rs                 |  4 ++--
 7 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/README.md b/README.md
index 5ecba13..77448c8 100644
--- a/README.md
+++ b/README.md
[message trimmed]

I forgot to bump the version number in the Makefile for 0.3.7, so
unfortunately that release is a dud. But it's just as well, because
there were two other (small) fixes I was able to squeeze in.

Packagers should please skip 0.3.7 and go straight to 0.3.8. The release
notes for 0.3.8 are listed here:

     https://git.sr.ht/~gpanders/ijq/refs/v0.3.8

These should effectively be combined with the release notes for 0.3.7
(listed in the prior email). Apologies for the confusion!

Version 0.3.7 of ijq has just been released. This is a minor bugfix
release.

As noted in a previous email on this list, the names of the pre-built
binaries that are automatically built in the build pipeline have
changed:

>This is just an FYI that the names of the binary release tarballs
>attached to releases on git.sr.ht will change from using "x86_64" to
>"amd64" beginning with the next release. The build pipeline now creates
>binary releases for Linux and macOS, and because the pipeline now
>builds multiple architectures I am using the terminology that `go
>build` itself uses to simplify things.

* Use Ctrl-F and Ctrl-B to move forward/backward one character
* Use Alt-F and Alt-B to move forward/backward one word
* Use Ctrl-A and Ctrl-E to move to the beginning/end of the input line
* Use Ctrl-K to delete all text from the cursor position to the end of
  the current line
---
 app.go           | 14 ++++++++++++++
 doc/senpai.1.scd | 22 ++++++++++++++++++++++
 ui/editor.go     | 15 +++++++++++++++
 ui/ui.go         |  4 ++++
 4 files changed, 55 insertions(+)

diff --git a/app.go b/app.go
index b044a06..768327f 100644
[message trimmed]

On Fri, 06 May 2022 12:57 +0200, Drew DeVault wrote:
>Done.

Thanks, it is working now.

For anyone following along, I ended up needing the following oauth
scopes:

     oauth: git.sr.ht/OBJECTS:RW git.sr.ht/REPOSITORIES:RO git.sr.ht/PROFILE:RO

I am trying to use hut to upload a build artifact to a git ref. My build
manifest is here:

     https://git.sr.ht/~gpanders/ijq/tree/hut/item/.build.yml

The build fails with the error "2022/05/05 17:39:29 no instance for
git.sr.ht found". Here is the link to the build:

     https://builds.sr.ht/~gpanders/job/751900

I SSH'd into the build to take a look at the hut config file on the
build runner and noticed that it's missing an entry for the "git"
service:

On Wed, 04 May 2022 20:53 +0200, witcher@wiredspace.de wrote:
>I'm trying to build a manifest for a Rust project, using `alpine/edge`.
>To install Rust, it uses `rustup`, which installs `rustup-init` on
>Alpine.
>Calling it changes `$PATH` by sourcing environment variables from
>`$HOME/.cargo/env` in `$HOME/.profile`.
>`$HOME/.profile` doesn't seem to be read on running a task, therefore
>making any tools installed by `rustup-init` unavailable, unless
>specified with their full path.
>
>Does a way around specifying the full path to the executable every time,
>manually or with an environment variable in the build manifest, exist?
>I'd like to avoid this.