text:
My website is never created.

I followed steps here. I tried it about 5 times, but all the times I failed except I just use the default setting. Could you see what is wrong? My repository is here. You can see the error message below. Thank you.

I don't see your assets folder with the images.

Thanks for your check. I also see that. However, why it isn't created, although I have those files on my local drive? I pushed from the origin, but those assets are not copied. Do you have any ideas for a solution?
Thank you.

I am suspecting you haven't committed those files into GitHub.

I think I did. I tried the following at the local root:
git add .
git commit -m "updates"
git push origin source
Are there anything I missed?

I am not sure. Can you post a screenshot of your local sate?

Sure. Here it is:

Well, I tried again. Still, the themes/toha files are not pushed. It's weird.
Also, do you know what these messages mean by: remote: Permission to hugo-toha/toha.git denied to IhnwhiHeo.
fatal: unable to access 'https://github.com/hugo-toha/toha.git/': The requested URL returned error: 403 ?

Ok. You don't have the assets folder locally too. Create a directory assets/images  in your repo. Then, put your images there. Test your site locally by running hugo server -w. If it compiles without any error, then push the changes into Github.

When I ran the website locally, it works perfectly okay. Once I push to the remote source, however, it does not copy assets. Did I miss anything?

I tried again. With the default step-by-step explanation, it works. Once I use my files, however, the website does not work, although it works locally.

Fork this repo and rename to your username: https://github.com/hugo-toha/hugo-toha.github.io

@hossainemruz
Thanks for your replies. I successfully figured out the cause. I should deal with folders/files NOT in the theme folder. If I work outside of it, it works okay. So, now the website is successfully rendered.. I realized this after more than 10 trials... Now, let me close this comment. Thanks for your help!

authors: IhnwhiHeo hossainemruz

repo: hugo-toha/toha


text:
Update update-trinity

If python points to python3, then building will fail.
Fixed version is here:
https://gist.githubusercontent.com/Grazfather/91e1ea3c3b51be844552263ce0f0d538/raw/c5607a51047b4dc01bf1f3fd443e8cd6318056c6/install-trinity.sh

Could also be sped up by using git clone --depth 1
Also it calls ldconfig to update the library search paths, and issue I had in some docker images.

453fdcb01afe8ddeab855e0a6a6cfe86cf63391b

source: gharchive/issue

authors: Grazfather hugsy

repo: hugsy/stuff

license: MIT

license_type: permissive

license_source: github-api


text:
1、有使用的例子吗

我想实现的功能，从host1 通过xdp的方式发送数据包到host2.我看了一下你的库好像更适合我的需求，我也是从xdp的个库然后看到这个项目的。

目前XDPRelay的实现还不是很理想，性能没有比RawSocketRelay好多少，我还得再想想有没有更好地实现方式；你可以就用RawSocketRelay（其用的是AF_PACKET socket），性能也不错的，Doc里有例子的；

原始的socket应该比xdp要慢很多吧？？

遇到了一个空指针的远程
package main

import (
	"net"

	"github.com/hujun-open/etherconn"
)

func main() {
	//00:0c:29:7f:4a:89
	macno01 := net.HardwareAddr{0x00, 0x0c, 0x29, 0x7f, 0x4a, 0x89}
	macno02 := net.HardwareAddr{0x00, 0x0c, 0x29, 0xf0, 0x60, 0x8d}
	c := etherconn.NewEtherConn(macno01, &etherconn.XDPRelay{})

	c.WriteIPPktTo([]byte{1, 2, 3, 4, 5, 6}, macno02)

}

[root@node01 cmd]# ./cmd
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x5a4a26]
goroutine 1 [running]:
github.com/hujun-open/etherconn.(*chanMap).SetList(0x0, 0xc000075170, 0x3, 0x3, 0xc0000261e0)
/root/etherconn/etherconn.go:466 +0x26
github.com/hujun-open/etherconn.(*XDPRelay).Register(0xc00011e0e0, 0xc000024120, 0x3, 0x4, 0x0, 0xc000024120, 0x2, 0x4)
/root/etherconn/xdpconn.go:338 +0x116
github.com/hujun-open/etherconn.NewEtherConn(0xc000143f72, 0x6, 0x6, 0x673d20, 0xc00011e0e0, 0x0, 0x0, 0x0, 0x446caa)
/root/etherconn/etherconn.go:1015 +0x5c4
main.main()
/root/etherconn/cmd/main.go:13 +0xd9
[root@node01 cmd]#

就目前的实现来说，两者差别不是很大，尤其是你如果只是用来发的话；AF_Packet和XDP都跳过了kernel大部分的网络处理； XDP目前主要的优势还是在ingress方向

我想实现的不是只发，，比如我用你的库开发了一个socket。然后在两台主机上面运行，两台主机通过mac通信，然后拿到数据包，给程序处理，处理完后，在通过你的库加mac发送出去，当主机多的时候，我维护一个 mac表实现集群通信

你可以先用RawSocketRelay试试，测一下， 看是否能满足你性能的要求；XDP的我还得再改改

嗯嗯。我目前在测试RawSocketRelay，我之前使用udp传输，发现性能瓶颈才调研 dpdk和xdp的，，谢谢。

下面是我的代码，一个客户端和一个服务端，通过mac地址通信。
package main

import (
	"context"
	"fmt"
	"net"
	"time"

	"github.com/hujun-open/etherconn"
)

/* func main() {

	node1Mac, _ := net.ParseMAC("00:0c:29:7f:4a:89")
	node2Mac, _ := net.ParseMAC("00:0c:29:f0:60:8d")
	r, _ := etherconn.NewRawSocketRelay(context.Background(), "ens33")
	econnA := etherconn.NewEtherConn(node1Mac, r)
	for {
		time.Sleep(time.Duration(5) * time.Second)
		n, err := econnA.WritePktTo([]byte{'h', 'e', 'l', 'l', 'o'}, 1, node2Mac)
		if err != nil {
			panic(err)
		}
		fmt.Printf("发送了%d个字节\n", n)

	}
}
*/

func main() {

	//node1Mac, _ := net.ParseMAC("00:0c:29:7f:4a:89")
	node2Mac, _ := net.ParseMAC("00:0c:29:f0:60:8d")
	r, _ := etherconn.NewRawSocketRelay(context.Background(), "ens33")
	econnb := etherconn.NewEtherConn(node2Mac, r)
	for {
		time.Sleep(time.Duration(5) * time.Second)
		data, mac, err := econnb.ReadPkt()
		if err != nil {
			panic(err)
		}
		fmt.Println(string(data))
		fmt.Println(data)
		fmt.Println(mac)
		fmt.Printf("接收到来自%s 的%d个字节\n", mac, len(data))

	}
}

好像用起来有一点问题。
package main

import (
	"context"
	"fmt"
	"net"
	"time"

	"github.com/hujun-open/etherconn"
)

func main() {

	node1Mac, _ := net.ParseMAC("00:0c:29:7f:4a:89")
	node2Mac, _ := net.ParseMAC("00:0c:29:f0:60:8d")
	r, _ := etherconn.NewRawSocketRelay(context.Background(), "ens33")
	econnA := etherconn.NewEtherConn(node1Mac, r)
	for {
		time.Sleep(time.Duration(5) * time.Second)
		n, err := econnA.WritePktTo([]byte{'h', 'e', 'l', 'l', 'o'}, 1, node2Mac)
		if err != nil {
			panic(err)
		}
		fmt.Printf("发送了%d个字节\n", n)

		fmt.Println([]byte{'h', 'e', 'l', 'l', 'o'})

	}
}

这是发送包的节点
运行代码输出
[root@node01 c]# ./c
发送了5个字节
[104 101 108 108 111]
发送了5个字节
[104 101 108 108 111]
发送了5个字节
[104 101 108 108 111]
发送了5个字节
[104 101 108 108 111]
发送了5个字节
[104 101 108 108 111]
发送了5个字节
[104 101 108 108 111]
发送了5个字节
[104 101 108 108 111]
发送了5个字节
[104 101 108 108 111]
发送了5个字节
[104 101 108 108 111]
发送了5个字节
[104 101 108 108 111]
发送了5个字节
[104 101 108 108 111]
发送了5个字节
[104 101 108 108 111]
发送了5个字节
[104 101 108 108 111]

下面是接收包节点的代码
package main

import (
	"context"
	"fmt"
	"net"
	"time"

	"github.com/google/gopacket"
	"github.com/google/gopacket/layers"
	"github.com/hujun-open/etherconn"
)

func main() {

	//node1Mac, _ := net.ParseMAC("00:0c:29:7f:4a:89")
	node2Mac, _ := net.ParseMAC("00:0c:29:f0:60:8d")
	r, _ := etherconn.NewRawSocketRelay(context.Background(), "ens33")
	econnb := etherconn.NewEtherConn(node2Mac, r)
	for {
		time.Sleep(time.Duration(5) * time.Second)
		data, mac, err := econnb.ReadPkt()
		if err != nil {
			panic(err)
		}
		fmt.Println(string(data))
		fmt.Println(data)
		fmt.Println(mac)
		fmt.Printf("接收到来自%s 的%d个字节\n", mac, len(data))

		s := gopacket.NewPacket(data, layers.LayerTypeEthernet, gopacket.Default)
		d := s.Data()
		fmt.Println(d)

	}
}

运行代码输出
[69 0 0 52 196 234 64 0 64 6 193 122 192 168 153 134 192 168 153 135 9 76 192 224 76 238 53 167 201 10 147 13 128 17 1 251 133 242 0 0 1 1 8 10 221 186 44 4 0 0 135 214]
00:0c:29:7f:4a:89
接收到来自00:0c:29:7f:4a:89 的52个字节
[69 0 0 52 196 234 64 0 64 6 193 122 192 168 153 134 192 168 153 135 9 76 192 224 76 238 53 167 201 10 147 13 128 17 1 251 133 242 0 0 1 1 8 10 221 186 44 4 0 0 135 214]
E��<��@�@�]������	L�iq��B������
                             ����
ݺ?'����
[69 0 0 60 0 0 64 0 64 6 134 93 192 168 153 134 192 168 153 135 9 76 193 187 105 113 173 162 66 153 172 170 160 18 254 136 11 205 0 0 2 4 5 180 4 2 8 10 221 186 63 39 0 0 154 249 1 3 3 7]
00:0c:29:7f:4a:89
接收到来自00:0c:29:7f:4a:89 的60个字节
[69 0 0 60 0 0 64 0 64 6 134 93 192 168 153 134 192 168 153 135 9 76 193 187 105 113 173 162 66 153 172 170 160 18 254 136 11 205 0 0 2 4 5 180 4 2 8 10 221 186 63 39 0 0 154 249 1 3 3 7]
^C
[root@node02 opt]#

从结果来看，接收端好像没有正确的收到[104 101 108 108 111]（hello）
还有一个疑问，为什么是以太层的数据 接受端里面会有 192 168 153 134 192 168 153 135 这种ip地址？ 这个应该不是发送端发过来的吧？

一个relay上面可以有很多个EtherConn，每个EtherConn由（MAC+EtherType）来区分，当relay收到一个以太网包的时候，它会根据其目的MAC地址和EtheType来决定发给哪一个EtherConn；
当你创建一个新的EtherCOnn，缺省的接受的EtherType（DefaultEtherTypes ）包括ARP, IPv4 和IPv6；但是你的发送程序econnA.WritePktTo([]byte{'h', 'e', 'l', 'l', 'o'}, 1, node2Mac)用了1作为发送包的EtherType，这样的话自然接收方就收不到发送方发的东西因为EtherType 1不在接收方的EtherType list里；要修正的话，在接收方code创建EtherConn，需要指定接收方的EtherType为1，用这个econnb := etherconn.NewEtherConn(node2Mac, r, etherconn.WithEtherTypes([]uint16{1}))
你现在在接收方收到的包都是一些其他发送到这个MAC地址的ARP，IPv4，IPv6的包；
其实MAC+EtherType在doc里面都有提到，你要仔细读文档

我重试了很多次，还是收到不到包
代码如下
package main

import (
	"context"
	"fmt"
	"net"
	"time"

	"github.com/hujun-open/etherconn"
)

func main() {
	node1Mac, _ := net.ParseMAC("00:0c:29:7f:4a:89")
	node2Mac, _ := net.ParseMAC("00:0c:29:f0:60:8d")
	r, _ := etherconn.NewRawSocketRelay(context.Background(), "ens33")
	econnA := etherconn.NewEtherConn(node1Mac, r, etherconn.WithEtherTypes([]uint16{1}))
	for {
		time.Sleep(time.Duration(5) * time.Second)
		n, err := econnA.WritePktTo([]byte{'h', 'e', 'l', 'l', 'o'}, 1, node2Mac)
		if err != nil {
			panic(err)

		}
		fmt.Printf("发送了%d个字节\n", n)

	}
}

这个是发送端
发送端的mac地址00:0c:29:7f:4a:89
接受端00:0c:29:f0:60:8d

package main

import (
	"context"
	"fmt"
	"net"

	"github.com/google/gopacket"
	"github.com/google/gopacket/layers"
	"github.com/hujun-open/etherconn"
)

func main() {
	//node1Mac, _ := net.ParseMAC("00:0c:29:7f:4a:89")
	node2Mac, _ := net.ParseMAC("00:0c:29:f0:60:8d")
	r, _ := etherconn.NewRawSocketRelay(context.Background(), "ens33")
	econnb := etherconn.NewEtherConn(node2Mac, r, etherconn.WithEtherTypes([]uint16{1}))
	for {
		data := []byte{}
		n, mac, err := econnb.ReadPktFrom(data)
		if err != nil {
			panic(err)
		}
		fmt.Println(n)
		fmt.Println(data)
		fmt.Println(mac)
		fmt.Printf("接收到来自%s 的%d个字节\n", mac, len(data))

		s := gopacket.NewPacket(data, layers.LayerTypeEthernet, gopacket.Default)
		d := s.Data()
		fmt.Println(d)

		d, nn, err := econnb.ReadPkt()
		if err != nil {
			panic(err)
		}
		fmt.Println(d)
		fmt.Println(nn)

	}
}

这个是接受端的
还是无法接受到发送端发过来的hello
不过当指定了etherconn.WithEtherTypes([]uint16{1}后，就收不到任何的数据包了

和系统有关系吗，
在vm环境下，两台centos7 的主机。

你可以在接收方用tcpdump之类的抓一下包，看看有没有发过来，如果没有的话，有如下可能原因：

你用了个非标准的ethertype 1，中间的交换机可能会drop这种非标准的包
你只发了5个字节太少了，以太网有最小包长度64字节的限制，交换机也可能会drop掉，多发点东西

好的我继续测试一下。。

package main

import (
	"context"
	"fmt"
	"net"
	"time"

	"github.com/hujun-open/etherconn"
)

func main() {
	node1Mac, _ := net.ParseMAC("00:0c:29:7f:4a:89")
	node2Mac, _ := net.ParseMAC("00:0c:29:f0:60:8d")
	r, _ := etherconn.NewRawSocketRelay(context.Background(), "ens33")
	econnA := etherconn.NewEtherConn(node1Mac, r, etherconn.WithEtherTypes([]uint16{0x8100}))
	for {
		time.Sleep(time.Duration(5) * time.Second)
		str := "hello world,hello world,hello world,hello world,hello world,hello world,hello world,hello world,hello world,hello world,hello world"
		n, err := econnA.WritePktTo([]byte(str), 0x8100, node2Mac)
		if err != nil {
			panic(err)

		}
		fmt.Printf("发送了%d个字节\n", n)

	}
}

package main

import (
	"context"
	"fmt"
	"net"

	"github.com/google/gopacket"
	"github.com/google/gopacket/layers"
	"github.com/hujun-open/etherconn"
)

func main() {
	//node1Mac, _ := net.ParseMAC("00:0c:29:7f:4a:89")
	node2Mac, _ := net.ParseMAC("00:0c:29:f0:60:8d")
	r, _ := etherconn.NewRawSocketRelay(context.Background(), "ens33")
	econnb := etherconn.NewEtherConn(node2Mac, r, etherconn.WithEtherTypes([]uint16{0x8100}))
	for {
		data := []byte{}
		n, mac, err := econnb.ReadPktFrom(data)
		if err != nil {
			panic(err)
		}
		fmt.Println(n)
		fmt.Println(data)
		fmt.Println(mac)
		fmt.Printf("接收到来自%s 的%d个字节\n", mac, len(data))

		s := gopacket.NewPacket(data, layers.LayerTypeEthernet, gopacket.Default)
		d := s.Data()
		fmt.Println(d)

		d, nn, err := econnb.ReadPkt()
		if err != nil {
			panic(err)
		}
		fmt.Println(d)
		fmt.Println(nn)

	}
}

代码调整成这样还是收不到包

大佬你那边有没有测试通过的环境信息（系统 内核版本，代码）

你的问题是这次把EtherType又设置成了0x8100，那个是VLAN的Ethertype，这样会导致relay把8100后面的字节当作vlan tag尝试匹配，那自然接收方就会失败；
我把你的code稍微改了改，这个code是在我这里能够运行的（你把interface name再改一下就可以了）：
package main

import (
	"context"
	"fmt"
	"net"
	"time"

	"github.com/hujun-open/etherconn"
)

func main() {
	node1Mac, _ := net.ParseMAC("00:0c:29:7f:4a:89")
	node2Mac, _ := net.ParseMAC("00:0c:29:f0:60:8d")
	const etherType = 0x0800
	r, err := etherconn.NewRawSocketRelay(context.Background(), "SIF")
	if err != nil {
		panic(err)
	}

	econnA := etherconn.NewEtherConn(node1Mac, r, etherconn.WithEtherTypes([]uint16{etherType}))
	for {
		time.Sleep(time.Duration(1) * time.Second)
		str := "hello world,hello world,hello world,hello world,hello world,hello world,hello world,hello world,hello world,hello world,hello world"
		n, err := econnA.WritePktTo([]byte(str), etherType, node2Mac)
		if err != nil {
			panic(err)

		}
		fmt.Printf("发送了%d个字节\n", n)

	}
}

package main

import (
	"context"
	"fmt"
	"net"
	"time"

	"github.com/hujun-open/etherconn"
)

func main() {
	//node1Mac, _ := net.ParseMAC("00:0c:29:7f:4a:89")
	node2Mac, _ := net.ParseMAC("00:0c:29:f0:60:8d")
	// it is best to uses a common ethertype like IPv4 here, even if you don't plan to use standard IP packet encap
	const etherType = 0x0800
	r, err := etherconn.NewRawSocketRelay(context.Background(), "RIF")
	if err != nil {
		panic(err)
	}
	go func() {
		for {
			time.Sleep(time.Second)
			fmt.Printf("\nrelay stats:\n%+v\n", r.GetStats())
		}
	}()
	econnb := etherconn.NewEtherConn(node2Mac, r, etherconn.WithEtherTypes([]uint16{etherType}))
	//if you want to use ReadPktFrom, then you need to pass in a byte slice with clear max capacity,
	// and you should try to reuse the byte slice in the loop
	const maxPktSize = 2000
	data := make([]byte, maxPktSize)
	for {
		n, mac, err := econnb.ReadPktFrom(data)
		if err != nil {
			panic(err)
		}
		fmt.Printf("接收到来自%s 的%d个字节: %v\n", mac, n, string(data[:n]))
	}
}

好的 我试试谢谢大佬。

现在测试正常了，谢谢 还有个问题const maxPktSize = 2000  这里设置了切片的大小为2000 但是econnb.ReadPktFrom(data)返回的n 有时候大于2000导致代码报错。

那说明node2Mac这里收到了大于2000的包，你把maxPktSize设大点就好了；如果node2Mac是网卡的真实MAC那接收方的EtherConn会收到所有发到这个MAC地址的包，这大概不是你想要的，etherconn的一个好处在于你可以使用任意的MAC地址，不一定非要真实的网卡MAC地址，你可以用一些虚构的MAC地址，这样的话就不会收到那些不想收到的包了。

明白了，问一下，这样的话网卡是开启了混杂模式吧？这样是否会影响性能哈？

在我的电脑上面测试，使用ethconn 来传输数据，还没有udp快，udp的延迟1ms左右。ethconn  100ms左右

100ms包传送延迟？在两台直连的电脑之间？那是不可能的，事实上1ms都慢了，你要再检查一下你的环境设置还有你检测延迟的方法

在两台vm虚拟机之间，，，代码从tun设备中读取字节通过你的库发送到另外一台机器的tun设备，   延迟测试的确比使用udp传输慢很多很多。

我这里用RawPacketRelay 能达到130k pps，如果用新的XDPRelay最高可以达到300k pps

可以看下你的测试代码吗

你测试的这个130k pps 是如何测试的哈？

你的同等环境测试过udp吗？我用上面的代码测试，很奇怪udp就是比ethconn快

我刚刚push了一些更新，重写了不少地方，而且还加了个例子 （在example folder），你可以再试试

使用xdp 模式后这台主机就会处于没有网络的状态，xdp模式是否可以支持过滤不是程序需要的包，让数据包继续进入协议栈？？其实就是xdp_pass，我目前测试 两台机器可以通过xdp模式通信，但开启后主机就会没有网络

使用xdp 模式后这台主机就会处于没有网络的状态，xdp模式是否可以支持过滤不是程序需要的包，让数据包继续进入协议栈？？其实就是xdp_pass，我目前测试 两台机器可以通过xdp模式通信，但开启后主机就会没有网络

etherconn内置的xdp kernel program只是将所有收到的包发给xdp socket，你如果想只发需要的包给xdp socket，需要自己写一个xdp kernel program，在那里面过滤；然后用etherconn.WithXDPExtProg()来加载这个program

目前在用raw，xdp的过滤能否支持一下哈哈，不然好像xdp没有办法使用，etherconn发送数据的时候可以加一个字节表示协议吧，然后xdp过滤的时候根据这个协议来判断数据是否丢给内核协议栈吧？？？不太了解xdp内核程序的编写哈哈哈哈哈。

发送数据？ xdp kernel program目前只能在ingress方向work，egress方向目前如果你用xdp socket发送数据包，这些包会bypass kernel entirely；

目前在用raw，xdp的过滤能否支持一下哈哈，不然好像xdp没有办法使用，etherconn发送数据的时候可以加一个字节表示协议吧，然后xdp过滤的时候根据这个协议来判断数据是否丢给内核协议栈吧？？？不太了解xdp内核程序的编写哈哈哈哈哈。

authors: FrelDX hujun-open

repo: hujun-open/etherconn


text:
basemodels: manifest: include content preferences

Supersedes #370
CC @leric7

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

@pared-imi , can you please sign the CLA?

@leric7 done

source: gharchive/pull-request

authors: CLAassistant leric7 pared-imi

repo: humanprotocol/human-protocol


text:
merge layer 产生多个网络分支问题

https://github.com/huoyijie/AdvancedEAST/blob/ba788240f2317afb4028404f56b1989499c6c4b3/network.py#L65-L70
这几行代码，会生成三个不同的feature merge layer网络分支，这是预期的结果吗？
可不可以这样直接生成7个output map：
Conv2D(7, 1, padding='same', name='output_all')(self.g(cfg.feature_layers_num))

不好意思一直比较忙没有查看，这个确实是一个早期没发现的bug......

authors: KwangKa huoyijie

repo: huoyijie/AdvancedEAST


text:
🛑 Portfolio is down

In 451424f, Portfolio (https://portfolio.thekor.eu) was down:

HTTP code: 502
Response time: 3417 ms

Resolved: Portfolio is back up in bfd0918 after 49 minutes.

repo: hupratt/upptime


text:
UR5 support on kinetic-devel

I've noticed some changes from indigo to kinetic devel, like the UR5 argument that disappeared form the description file. Is it possible to launch the ur5 manipulator with the kinetic version?

We are in the process of moving out the manipulator packages from the core Husky packages to here.  They have only been tested for Indigo so far.

Closing to due inactivity, please feel free to reopen if the needed.

authors: luiscarlosfeliz tonybaltovski

repo: husky/husky

license_source: bigquery


text:
Feature: Ability to select the display being rendered to

I’m looking to remotely control at least two instances of mpv, with the ability to select which display output each instance renders to.
Is this currently possible?

Multiple MPV instances supported by this API. If you're on default config your first server will be accessible on port 8000 and your second instance available on 8001 (Of course if it's free, the API finds a free port on the provided range)
If you want to move MPV instances between your displays (Monitor), it's not supported by this REST.API yet.  I don't know if it's even possible with MPV IPC, it seems System API related thing to me. Maybe these options can help you
I'll do some investigation on the weekend and add this as feature if  implementable. If you have any progress let me know!

Excellent thank you
I see the following options that look promising:
--screen=<default|0-32>
In multi-monitor configurations (i.e. a single desktop that spans across multiple displays), this option tells mpv which screen to display the video on.
--fs-screen=<all|current|0-32>
In multi-monitor configurations (i.e. a single desktop that spans across multiple displays), this option tells mpv which screen to go fullscreen to. If current is used mpv will fallback on what the user provided with the screen option.

Sorry for a late response. I don't have good news, setting the screen or geometry even by using MPV command line seems not to work. For example if you run MPV with these flags nothing happens :
mpv --idle --force-window --screen=x
# or setting geometry manually.
mpv --idle --force-window --geometry=x:y

I've tested these commands on Fedora 37 VM which uses Gnome and Wayland as compositor  and on my host machine which using Pop OS with I3 on X11.
Maybe you could get this working on MAC or Windows. If you try these commands on your machine and it's working for you I'll add it to the mpv-remote-node project.
MPV documentation entries for screen and geometry flags.

working in windows 10/11 for me.
example:
for main screen
mpv --no-osc --loop-playlist=inf --no-keepaspect --no-border --ontop --image-display-duration=5 --idle=yes --fullscreen --screen=0 --title=player1 --audio-device=wasapi/{53669d3f-8de4-41bf-a2e5-c541aa3bceca}
for extended screen
mpv --no-osc --loop-playlist=inf --no-keepaspect --no-border --ontop --image-display-duration=5 --idle=yes --geometry=1920x1080 --screen=1 --title=player2 --audio-device=wasapi/{43822032-bd4b-4e9b-8ba4-c3cc1aac4757}

this works for me in windows 10/11
main screen
mpv --no-osc --loop-playlist=inf --no-keepaspect --no-border --ontop --image-display-duration=5 --idle=yes --fullscreen --screen=0 --title=player1 --audio-device=wasapi/{53669d3f-8de4-41bf-a2e5-c541aa3bceca}
extended screen
mpv --no-osc --loop-playlist=inf --no-keepaspect --no-border --ontop --image-display-duration=5 --idle=yes --geometry=1920x1080 --screen=1 --title=player2 --audio-device=wasapi/{43822032-bd4b-4e9b-8ba4-c3cc1aac4757}

authors: hermitpig husudosu si-hb

repo: husudosu/mpv-remote-node


text:
I can use this repo to access only with token?

I have an example here https://github.com/hungdev/react-native-instagram-login
By doing this, I get the Token through a Webview. Can I keep a session and use all the tools that this repo provides?
PS. My intention is that my users authenticate to my service. And also post images generated in my service. With some text and Hashtags. I would integrate this repo to my GraphQL API that I use with My Expo React-Native client.
Cheers

You are requesting user application token with oAuth2, probably. And we are using IG client token. Pretty sure they are not replaceable. But even IF your token can be used in our module for some API stuff, you will not be able to upload photo. That's for sure.

authors: IvanMMM MichelDiz

repo: huttarichard/instagram-private-api


text:
Resize volume succeeded, Require file system resize of volume on node seems failed

Output of lsblk:
# [root@controller-node-1 ~]# lsblk
NAME                                                                 MAJ:MIN   RM   SIZE RO TYPE MOUNTPOINT
sda                                                                    8:0      0   200G  0 disk
├─sda1                                                                 8:1      0     1G  0 part /boot
└─sda2                                                                 8:2      0   199G  0 part
  ├─centos-root                                                      253:0      0    50G  0 lvm  /
  ├─centos-swap                                                      253:1      0   7.9G  0 lvm
  └─centos-home                                                      253:19     0 141.1G  0 lvm  /home
sdb                                                                    8:16     0   200G  0 disk
├─LocalStorage_PoolHDD-pvc--99bdfa30--d547--4614--8e97--b17dbee38902 253:2      0    10G  0 lvm
│ └─drbd43001                                                        147:43001  0    10G  0 disk
├─LocalStorage_PoolHDD-pvc--aaefdf2b--dc27--4bc0--9372--672793a2400f 253:3      0     8G  0 lvm  /var/lib/kubelet/pods/94d45c8f-07e2-4920-a4cf
├─LocalStorage_PoolHDD-pvc--6b2d003d--a8ec--4d4f--9c3a--d17676e0d259 253:4      0     5G  0 lvm  /var/lib/kubelet/pods/6a8afad4-ef92-4b76-a54a
├─LocalStorage_PoolHDD-pvc--97685a90--ea70--449e--81ed--ba103184c4c9 253:5      0     5G  0 lvm  /var/lib/kubelet/pods/306ac967-ae41-485e-86cf
├─LocalStorage_PoolHDD-pvc--9e949eb5--58ad--410e--bff8--2215baedc2bd 253:6      0     5G  0 lvm  /var/lib/kubelet/pods/352ccf91-3f12-45bd-9145
├─LocalStorage_PoolHDD-pvc--9d483fd2--5735--42da--b799--8cbbd5a1069b 253:7      0     1G  0 lvm  /var/lib/kubelet/pods/0af9dd05-3246-4231-80b6
├─LocalStorage_PoolHDD-pvc--68445ca5--a97f--481d--8347--b732f7d56ce2 253:8      0     1G  0 lvm  /var/lib/kubelet/pods/0af9dd05-3246-4231-80b6
├─LocalStorage_PoolHDD-pvc--e924cdaa--2c7b--4102--9514--97b94513ce0b 253:9      0     1G  0 lvm  /var/lib/kubelet/pods/0af9dd05-3246-4231-80b6
├─LocalStorage_PoolHDD-pvc--3081fb40--4cd1--441f--b083--9dc963b4da2c 253:10     0     1G  0 lvm  /var/lib/kubelet/pods/0af9dd05-3246-4231-80b6
├─LocalStorage_PoolHDD-pvc--c45e18e5--f447--4be5--9dcc--f8882805f240 253:11     0     1G  0 lvm  /var/lib/kubelet/pods/2f79e99f-21b7-442b-82ea
├─LocalStorage_PoolHDD-pvc--3a76fa1b--c122--43ca--a632--ac66e3b8368b 253:12     0     1G  0 lvm  /var/lib/kubelet/pods/a8d3d52e-b3d8-42e4-bdfa
├─LocalStorage_PoolHDD-pvc--fad9ffcd--e6d0--41dd--8ad3--cb49fd1c89a7 253:13     0     1G  0 lvm  /var/lib/kubelet/pods/adb5310f-bbe5-423c-9112
├─LocalStorage_PoolHDD-pvc--022267fe--fdbc--46ec--8646--66f07d27f0ce 253:14     0     1G  0 lvm  /var/lib/kubelet/pods/7084201f-3f62-4b47-a0f5
├─LocalStorage_PoolHDD-pvc--5a05c473--78d4--491b--b856--18bfda08a655 253:15     0     1G  0 lvm  /var/lib/kubelet/pods/f21c0e2a-765d-42c7-b615
├─LocalStorage_PoolHDD-pvc--f4fbc46b--f658--4793--b73e--8d50e543817e 253:16     0     1G  0 lvm  /var/lib/kubelet/pods/02a94852-c412-4b8d-afa1
├─LocalStorage_PoolHDD-pvc--20d2125e--60f7--4e31--a817--7ad68cfcd75e 253:17     0     1G  0 lvm  /var/lib/kubelet/pods/68a96ba4-2f88-436e-82ae
├─LocalStorage_PoolHDD-pvc--4c119575--1817--4038--8be2--5d953e8b0f62 253:18     0     1G  0 lvm  /var/lib/kubelet/pods/fa6e07b7-b537-4823-96eb
├─LocalStorage_PoolHDD-pvc--8b641d00--1a7c--4832--83f2--68df8a2af852 253:20     0     1G  0 lvm  /var/lib/kubelet/pods/31653ce6-ebba-460e-ae32
├─LocalStorage_PoolHDD-pvc--ba48cfeb--7e35--4046--ac70--f3a8a4350b98 253:21     0     5G  0 lvm  /mnt/hwameistor/dst/pvc-ba48cfeb-7e35-4046-ac
├─LocalStorage_PoolHDD-pvc--30a1752b--3aac--4878--be87--5511aebae198 253:22     0     1G  0 lvm  /mnt/hwameistor/dst/pvc-30a1752b-3aac-4878-be
├─LocalStorage_PoolHDD-pvc--34e3dedc--60da--4c2b--ae29--357da2016238 253:23     0     1G  0 lvm  /mnt/hwameistor/dst/pvc-34e3dedc-60da-4c2b-ae
├─LocalStorage_PoolHDD-pvc--e331b8d8--9b96--4592--aa75--c865ccd3cd93 253:24     0     1G  0 lvm  /mnt/hwameistor/dst/pvc-e331b8d8-9b96-4592-aa
├─LocalStorage_PoolHDD-pvc--b212850c--e3ce--4a1d--8a45--1a455a1646eb 253:25     0     5G  0 lvm  /mnt/hwameistor/dst/pvc-b212850c-e3ce-4a1d-8a
├─LocalStorage_PoolHDD-pvc--4bb92ffa--3172--4edc--9cd7--7f31dcfbc665 253:26     0     8G  0 lvm  /mnt/hwameistor/dst/pvc-4bb92ffa-3172-4edc-9c
├─LocalStorage_PoolHDD-pvc--4ea3e2a0--43d4--49c1--ad94--8d12b3aa26b1 253:27     0     8G  0 lvm  /mnt/hwameistor/dst/pvc-4ea3e2a0-43d4-49c1-ad
├─LocalStorage_PoolHDD-pvc--8aaa1ea8--3021--409e--950c--99adb0ecb501 253:28     0     5G  0 lvm  /mnt/hwameistor/dst/pvc-8aaa1ea8-3021-409e-95
├─LocalStorage_PoolHDD-pvc--c93883cc--cb6a--4bd5--9970--c72de9b625f3 253:29     0     5G  0 lvm  /mnt/hwameistor/dst/pvc-c93883cc-cb6a-4bd5-99
├─LocalStorage_PoolHDD-pvc--f491d59c--e70a--4ba4--953a--2a864e516976 253:30     0     5G  0 lvm  /mnt/hwameistor/dst/pvc-f491d59c-e70a-4ba4-95
├─LocalStorage_PoolHDD-pvc--87596c32--534b--415f--9205--c1f73384912a 253:31     0     5G  0 lvm  /mnt/hwameistor/dst/pvc-87596c32-534b-415f-92
├─LocalStorage_PoolHDD-pvc--c699a44e--d23b--4af8--aba7--6f9f507e56fa 253:32     0     5G  0 lvm  /mnt/hwameistor/dst/pvc-c699a44e-d23b-4af8-ab
├─LocalStorage_PoolHDD-pvc--22454c11--8e02--4777--a40a--032ea51246da 253:33     0     5G  0 lvm  /mnt/hwameistor/dst/pvc-22454c11-8e02-4777-a4
├─LocalStorage_PoolHDD-pvc--b8ca0c66--21bb--4263--84b8--b42c1c3da654 253:34     0     5G  0 lvm  /mnt/hwameistor/dst/pvc-b8ca0c66-21bb-4263-84
├─LocalStorage_PoolHDD-pvc--108b835a--7a37--4119--a1e2--7d5ed36ce8d4 253:35     0     1G  0 lvm  /mnt/hwameistor/dst/pvc-108b835a-7a37-4119-a1
├─LocalStorage_PoolHDD-pvc--c28fbd72--2fcb--4408--acd2--0b6a53c4eab8 253:36     0     5G  0 lvm  /mnt/hwameistor/dst/pvc-c28fbd72-2fcb-4408-ac
├─LocalStorage_PoolHDD-pvc--0367d6b7--b72f--4e85--bee2--7e4df8d28563 253:37     0     5G  0 lvm  /mnt/hwameistor/dst/pvc-0367d6b7-b72f-4e85-be
├─LocalStorage_PoolHDD-pvc--98cf842e--dcd2--421e--b650--6d24ec3ecdf0 253:38     0     1G  0 lvm  /mnt/hwameistor/dst/pvc-98cf842e-dcd2-421e-b6
├─LocalStorage_PoolHDD-pvc--aaa09585--4e61--468a--97a4--91bb5c9918c6 253:39     0     1G  0 lvm  /mnt/hwameistor/dst/pvc-aaa09585-4e61-468a-97
├─LocalStorage_PoolHDD-pvc--153868a1--845e--4758--82c4--d5b899c99a7e 253:40     0     1G  0 lvm
├─LocalStorage_PoolHDD-pvc--72dc3597--4610--4867--8b3c--b15bfaf3e787 253:41     0     1G  0 lvm
├─LocalStorage_PoolHDD-pvc--f3f9ea05--98e9--4f42--a121--0ba85cea47f4 253:42     0     1G  0 lvm
├─LocalStorage_PoolHDD-pvc--43649937--8710--42bc--b92b--000ed9f7ff9f 253:43     0     1G  0 lvm
├─LocalStorage_PoolHDD-pvc--89c407be--7460--4a6c--bf8e--0a9cdf093ca0 253:44     0     1G  0 lvm  /mnt/hwameistor/dst/pvc-89c407be-7460-4a6c-bf
├─LocalStorage_PoolHDD-pvc--9569ecdd--ce8c--4024--9ec4--e38415d328b5 253:45     0     8G  0 lvm  /mnt/hwameistor/dst/pvc-9569ecdd-ce8c-4024-9e
├─LocalStorage_PoolHDD-pvc--6e2addb8--c167--40d1--99df--c6269896904e 253:46     0     1G  0 lvm
├─LocalStorage_PoolHDD-pvc--36c2d2aa--9469--4ebb--b06d--094e51a68f8a 253:47     0     1G  0 lvm
├─LocalStorage_PoolHDD-pvc--6a1aaaec--9de2--4af5--bafe--9acc100de53a 253:48     0     5G  0 lvm  /mnt/hwameistor/dst/pvc-6a1aaaec-9de2-4af5-ba
├─LocalStorage_PoolHDD-pvc--08633489--6a9a--42ae--90fd--7863f827c186 253:49     0     1G  0 lvm
├─LocalStorage_PoolHDD-pvc--519ed15d--e421--470b--97eb--3c4dbbd9770b 253:50     0     1G  0 lvm
└─LocalStorage_PoolHDD-pvc--5645d3cb--1134--4330--95d8--8a627d41df80 253:51     0   1.5G  0 lvm  /var/lib/kubelet/pods/0cd38a6c-bb6c-40a7-bd43
sr0                                                                   11:0      1  1024M  0 rom

Output of blkid:
# /dev/sdb: UUID="3EsMBJ-VSZN-7BBN-OgO9-aGKg-fZCT-uiBpsq" TYPE="LVM2_member"
/dev/sda1: UUID="b5603063-3e30-4a8d-a83f-acd19a582041" TYPE="xfs"
/dev/sda2: UUID="MToCjf-qptN-EbMB-J8hT-YJnu-Vm67-BzPIei" TYPE="LVM2_member"
/dev/mapper/centos-root: UUID="5ab6b56e-4c4e-4b11-b8eb-c91a8cce91a4" TYPE="xfs"
/dev/mapper/centos-swap: UUID="2f8faeba-6ebf-47e2-9c1d-1b79abb432fa" TYPE="swap"
/dev/mapper/LocalStorage_PoolHDD-pvc--99bdfa30--d547--4614--8e97--b17dbee38902: UUID="66543e10-6ea1-495d-96cd-2520718e6f36" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--aaefdf2b--dc27--4bc0--9372--672793a2400f: UUID="e398aea8-252d-4058-969e-de1009b01ca0" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--6b2d003d--a8ec--4d4f--9c3a--d17676e0d259: UUID="cec79938-ee11-4e7c-8b0c-7d6068a92298" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--97685a90--ea70--449e--81ed--ba103184c4c9: UUID="4360f249-5750-405d-9493-c79d33f1d57f" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--9e949eb5--58ad--410e--bff8--2215baedc2bd: UUID="c9409059-763f-4d9c-be03-4519065357ad" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--9d483fd2--5735--42da--b799--8cbbd5a1069b: UUID="48262f9b-d045-437a-a112-52dec35d6020" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--68445ca5--a97f--481d--8347--b732f7d56ce2: UUID="26a00b44-ec46-44bd-9ea9-82de42881a9c" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--e924cdaa--2c7b--4102--9514--97b94513ce0b: UUID="990deb55-e620-4c52-8628-675d394a32dd" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--3081fb40--4cd1--441f--b083--9dc963b4da2c: UUID="ac8fb6af-81b0-4f3e-a8a4-c4f73ac929b3" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--c45e18e5--f447--4be5--9dcc--f8882805f240: UUID="dc8c9f9f-9b6b-4d8f-bc03-cd91990c12af" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--3a76fa1b--c122--43ca--a632--ac66e3b8368b: UUID="594eeebf-1b90-4197-b652-f65d77993cef" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--fad9ffcd--e6d0--41dd--8ad3--cb49fd1c89a7: UUID="67a5f928-32e8-45ad-b4c6-0fc796e3e433" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--022267fe--fdbc--46ec--8646--66f07d27f0ce: UUID="bad45137-fe55-435e-93bc-79a8c2291100" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--5a05c473--78d4--491b--b856--18bfda08a655: UUID="943ddc1e-7a00-43d0-860f-c9dd580e5fb3" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--f4fbc46b--f658--4793--b73e--8d50e543817e: UUID="e7e3c533-1ad3-4889-aa6e-8ab54da63bc3" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--20d2125e--60f7--4e31--a817--7ad68cfcd75e: UUID="7254f67d-7873-4573-8d64-5bef2a2b994b" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--4c119575--1817--4038--8be2--5d953e8b0f62: UUID="6adc1ed8-a766-4edd-bbd1-b7f62cb9990b" TYPE="xfs"
/dev/mapper/centos-home: UUID="56f84b2c-90a5-489f-a8b4-bc9506e56043" TYPE="xfs"
/dev/drbd43001: UUID="66543e10-6ea1-495d-96cd-2520718e6f36" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--8b641d00--1a7c--4832--83f2--68df8a2af852: UUID="464b360d-7192-42b3-b70a-31cff150b0a5" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--ba48cfeb--7e35--4046--ac70--f3a8a4350b98: UUID="61f24f74-889b-45ad-81d2-c1d6f46ca272" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--30a1752b--3aac--4878--be87--5511aebae198: UUID="5db702c1-8978-48b4-bc1d-d64092eecafb" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--34e3dedc--60da--4c2b--ae29--357da2016238: UUID="581611fa-8421-4379-909b-60e311194b97" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--e331b8d8--9b96--4592--aa75--c865ccd3cd93: UUID="1be7383a-02a3-45cc-a43e-f6cd53e6f685" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--b212850c--e3ce--4a1d--8a45--1a455a1646eb: UUID="91ae9730-0096-41f6-85ac-e5a5e7547967" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--4bb92ffa--3172--4edc--9cd7--7f31dcfbc665: UUID="e2be23af-c763-4e13-b4ac-4d429c32bdda" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--4ea3e2a0--43d4--49c1--ad94--8d12b3aa26b1: UUID="a03aac9b-8aa5-4c43-984c-aef9eb38c0bf" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--8aaa1ea8--3021--409e--950c--99adb0ecb501: UUID="3252fa26-1b3e-410c-96a6-f61e9c1ddb45" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--c93883cc--cb6a--4bd5--9970--c72de9b625f3: UUID="af58fb16-a36e-46b5-a98a-1e54a59c25d1" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--f491d59c--e70a--4ba4--953a--2a864e516976: UUID="83ed3b03-2853-411f-afb8-e04d34e308f8" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--87596c32--534b--415f--9205--c1f73384912a: UUID="bc9e1316-8049-44ae-95c7-add5f357b8a4" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--c699a44e--d23b--4af8--aba7--6f9f507e56fa: UUID="7f021911-a4f7-4a5d-9343-b3e8d2d901e4" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--22454c11--8e02--4777--a40a--032ea51246da: UUID="0853267e-88d3-4c2b-8f39-561d61636972" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--b8ca0c66--21bb--4263--84b8--b42c1c3da654: UUID="28f4e789-2593-4d8e-8342-ee97ff3ac089" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--108b835a--7a37--4119--a1e2--7d5ed36ce8d4: UUID="720b9c84-53aa-4db8-a731-9702975951e7" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--c28fbd72--2fcb--4408--acd2--0b6a53c4eab8: UUID="23b9c837-899b-40ba-9a0d-41236cc99302" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--0367d6b7--b72f--4e85--bee2--7e4df8d28563: UUID="7547e3f9-68c2-41d1-9cfa-8bcb6734a1f4" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--98cf842e--dcd2--421e--b650--6d24ec3ecdf0: UUID="e8911ca6-bad9-4e84-87cc-808efa6eced4" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--aaa09585--4e61--468a--97a4--91bb5c9918c6: UUID="ba1669cd-7f77-48ce-89d3-da8185df2e3f" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--89c407be--7460--4a6c--bf8e--0a9cdf093ca0: UUID="5a4c632c-2c1c-4098-aab5-e835e50e9467" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--9569ecdd--ce8c--4024--9ec4--e38415d328b5: UUID="811724c8-d970-48ab-bf27-636a3b7c331e" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--6a1aaaec--9de2--4af5--bafe--9acc100de53a: UUID="7bfa8dd9-ae4c-472b-a7ee-91e6f10f8fad" TYPE="xfs"
/dev/mapper/LocalStorage_PoolHDD-pvc--5645d3cb--1134--4330--95d8--8a627d41df80: UUID="92fc406b-7e18-4e19-84df-71a465e1dfd3" TYPE="xfs"
[root@controller-node-1 ~]#

Output of kubectl version:
# v1.25.4

Output of kubectl get lsn -o yaml:
# apiVersion: v1
items:
- apiVersion: hwameistor.io/v1alpha1
  kind: LocalStorageNode
  metadata:
    creationTimestamp: "2023-06-08T07:59:20Z"
    generation: 1
    name: controller-node-1
    resourceVersion: "18990454"
    uid: 005f0c18-493e-4078-bb57-9b5c9d8d7f04
  spec:
    hostname: controller-node-1
    storageIP: 10.16.10.47
    topogoly:
      region: default
      zone: default
  status:
    conditions:
    - lastTransitionTime: "2023-06-08T07:59:36Z"
      lastUpdateTime: "2023-06-08T07:59:36Z"
      message: Successfully to expand storage capacity
      reason: StorageExpandSuccess
      status: "True"
      type: ExpandSuccess
    poolExtendRecords:
      LocalStorage_PoolHDD:
      - description:
          diskType: HDD
        diskRefs:
        - apiVersion: hwameistor.io/v1alpha1
          kind: LocalDisk
          name: controller-node-1-sdb
          resourceVersion: "19259"
          uid: 17d3abf4-c547-449e-9da2-c1966fc3a136
        nodeName: controller-node-1
        owner: local-storage
    pools:
      LocalStorage_PoolHDD:
        class: HDD
        disks:
        - capacityBytes: 214744170496
          devPath: /dev/sdb
          state: InUse
          type: HDD
        freeCapacityBytes: 57440993280
        freeVolumeCount: 951
        name: LocalStorage_PoolHDD
        totalCapacityBytes: 214744170496
        totalVolumeCount: 1000
        type: REGULAR
        usedCapacityBytes: 157303177216
        usedVolumeCount: 49
        volumeCapacityBytesLimit: 214744170496
        volumes:
        - pvc-34e3dedc-60da-4c2b-ae29-357da2016238
        - pvc-43649937-8710-42bc-b92b-000ed9f7ff9f
        - pvc-4bb92ffa-3172-4edc-9cd7-7f31dcfbc665
        - pvc-5645d3cb-1134-4330-95d8-8a627d41df80
        - pvc-c93883cc-cb6a-4bd5-9970-c72de9b625f3
        - pvc-22454c11-8e02-4777-a40a-032ea51246da
        - pvc-97685a90-ea70-449e-81ed-ba103184c4c9
        - pvc-c45e18e5-f447-4be5-9dcc-f8882805f240
        - pvc-c699a44e-d23b-4af8-aba7-6f9f507e56fa
        - pvc-f491d59c-e70a-4ba4-953a-2a864e516976
        - pvc-fad9ffcd-e6d0-41dd-8ad3-cb49fd1c89a7
        - pvc-89c407be-7460-4a6c-bf8e-0a9cdf093ca0
        - pvc-6e2addb8-c167-40d1-99df-c6269896904e
        - pvc-8aaa1ea8-3021-409e-950c-99adb0ecb501
        - pvc-8b641d00-1a7c-4832-83f2-68df8a2af852
        - pvc-022267fe-fdbc-46ec-8646-66f07d27f0ce
        - pvc-68445ca5-a97f-481d-8347-b732f7d56ce2
        - pvc-87596c32-534b-415f-9205-c1f73384912a
        - pvc-9e949eb5-58ad-410e-bff8-2215baedc2bd
        - pvc-b8ca0c66-21bb-4263-84b8-b42c1c3da654
        - pvc-c28fbd72-2fcb-4408-acd2-0b6a53c4eab8
        - pvc-e924cdaa-2c7b-4102-9514-97b94513ce0b
        - pvc-4ea3e2a0-43d4-49c1-ad94-8d12b3aa26b1
        - pvc-4c119575-1817-4038-8be2-5d953e8b0f62
        - pvc-b212850c-e3ce-4a1d-8a45-1a455a1646eb
        - pvc-e331b8d8-9b96-4592-aa75-c865ccd3cd93
        - pvc-f3f9ea05-98e9-4f42-a121-0ba85cea47f4
        - pvc-f4fbc46b-f658-4793-b73e-8d50e543817e
        - pvc-08633489-6a9a-42ae-90fd-7863f827c186
        - pvc-30a1752b-3aac-4878-be87-5511aebae198
        - pvc-3a76fa1b-c122-43ca-a632-ac66e3b8368b
        - pvc-5a05c473-78d4-491b-b856-18bfda08a655
        - pvc-9569ecdd-ce8c-4024-9ec4-e38415d328b5
        - pvc-153868a1-845e-4758-82c4-d5b899c99a7e
        - pvc-3081fb40-4cd1-441f-b083-9dc963b4da2c
        - pvc-36c2d2aa-9469-4ebb-b06d-094e51a68f8a
        - pvc-6a1aaaec-9de2-4af5-bafe-9acc100de53a
        - pvc-99bdfa30-d547-4614-8e97-b17dbee38902
        - pvc-aaefdf2b-dc27-4bc0-9372-672793a2400f
        - pvc-108b835a-7a37-4119-a1e2-7d5ed36ce8d4
        - pvc-20d2125e-60f7-4e31-a817-7ad68cfcd75e
        - pvc-519ed15d-e421-470b-97eb-3c4dbbd9770b
        - pvc-6b2d003d-a8ec-4d4f-9c3a-d17676e0d259
        - pvc-72dc3597-4610-4867-8b3c-b15bfaf3e787
        - pvc-98cf842e-dcd2-421e-b650-6d24ec3ecdf0
        - pvc-9d483fd2-5735-42da-b799-8cbbd5a1069b
        - pvc-aaa09585-4e61-468a-97a4-91bb5c9918c6
        - pvc-0367d6b7-b72f-4e85-bee2-7e4df8d28563
        - pvc-ba48cfeb-7e35-4046-ac70-f3a8a4350b98
    state: Ready
- apiVersion: hwameistor.io/v1alpha1
  kind: LocalStorageNode
  metadata:
    creationTimestamp: "2023-06-13T05:31:01Z"
    generation: 1
    name: worker01
    resourceVersion: "18987632"
    uid: 4581ac9b-b1d7-4fdc-87af-b0852e29513f
  spec:
    hostname: worker01
    storageIP: 10.16.10.48
    topogoly:
      region: default
      zone: default
  status:
    conditions:
    - lastTransitionTime: "2023-06-13T07:01:16Z"
      lastUpdateTime: "2023-06-13T07:01:16Z"
      message: Successfully to expand storage capacity
      reason: StorageExpandSuccess
      status: "True"
      type: ExpandSuccess
    poolExtendRecords:
      LocalStorage_PoolHDD:
      - description:
          diskType: HDD
        diskRefs:
        - apiVersion: hwameistor.io/v1alpha1
          kind: LocalDisk
          name: worker01-sdb
          resourceVersion: "1738926"
          uid: 933bae1d-f0f6-4f88-8c89-2db16cfa988d
        nodeName: worker01
        owner: local-storage
    pools:
      LocalStorage_PoolHDD:
        class: HDD
        disks:
        - capacityBytes: 214744170496
          devPath: /dev/sdb
          state: InUse
          type: HDD
        freeCapacityBytes: 81600184320
        freeVolumeCount: 964
        name: LocalStorage_PoolHDD
        totalCapacityBytes: 214744170496
        totalVolumeCount: 1000
        type: REGULAR
        usedCapacityBytes: 133143986176
        usedVolumeCount: 36
        volumeCapacityBytesLimit: 214744170496
        volumes:
        - pvc-8aaa1ea8-3021-409e-950c-99adb0ecb501
        - pvc-f491d59c-e70a-4ba4-953a-2a864e516976
        - pvc-153868a1-845e-4758-82c4-d5b899c99a7e
        - pvc-4ea3e2a0-43d4-49c1-ad94-8d12b3aa26b1
        - pvc-6a1aaaec-9de2-4af5-bafe-9acc100de53a
        - pvc-08633489-6a9a-42ae-90fd-7863f827c186
        - pvc-6e2addb8-c167-40d1-99df-c6269896904e
        - pvc-72dc3597-4610-4867-8b3c-b15bfaf3e787
        - pvc-87596c32-534b-415f-9205-c1f73384912a
        - pvc-9569ecdd-ce8c-4024-9ec4-e38415d328b5
        - pvc-98cf842e-dcd2-421e-b650-6d24ec3ecdf0
        - pvc-0367d6b7-b72f-4e85-bee2-7e4df8d28563
        - pvc-43649937-8710-42bc-b92b-000ed9f7ff9f
        - pvc-49858341-aa58-41bf-b937-77b6b12b4e03
        - pvc-b212850c-e3ce-4a1d-8a45-1a455a1646eb
        - pvc-c93883cc-cb6a-4bd5-9970-c72de9b625f3
        - pvc-99bdfa30-d547-4614-8e97-b17dbee38902
        - pvc-a1507e5f-08e0-4c17-9ec0-29d59a847d64
        - pvc-aaa09585-4e61-468a-97a4-91bb5c9918c6
        - pvc-1a5221fb-3ab2-4092-b62c-f834297f1473
        - pvc-c28fbd72-2fcb-4408-acd2-0b6a53c4eab8
        - pvc-f302880d-f089-42b3-8ab9-77850d12decb
        - pvc-89c407be-7460-4a6c-bf8e-0a9cdf093ca0
        - pvc-b8ca0c66-21bb-4263-84b8-b42c1c3da654
        - pvc-4bb92ffa-3172-4edc-9cd7-7f31dcfbc665
        - pvc-ba48cfeb-7e35-4046-ac70-f3a8a4350b98
        - pvc-c154b8aa-7cfc-43af-b6e0-fc97f6b27a27
        - pvc-c699a44e-d23b-4af8-aba7-6f9f507e56fa
        - pvc-108b835a-7a37-4119-a1e2-7d5ed36ce8d4
        - pvc-22454c11-8e02-4777-a40a-032ea51246da
        - pvc-30a1752b-3aac-4878-be87-5511aebae198
        - pvc-f3f9ea05-98e9-4f42-a121-0ba85cea47f4
        - pvc-34e3dedc-60da-4c2b-ae29-357da2016238
        - pvc-36c2d2aa-9469-4ebb-b06d-094e51a68f8a
        - pvc-519ed15d-e421-470b-97eb-3c4dbbd9770b
        - pvc-e331b8d8-9b96-4592-aa75-c865ccd3cd93
    state: Ready
kind: List
metadata:
  resourceVersion: ""

hwameiStor operator version
# hwameistor-operator:v0.10.2

1 install mysql with hwameistor storageclass
2 expand mysql storage
3 check hwameistor lv,  they are ready, expand seems success
4 however file system resize seems stuck
Event(v1.0bjectReference{Kind: "PersistentVolumeClaim", Namespace: "liyuemcamel-ns"
. Name: "dat
recover0719-mysql-2",
UID: "1a5221fb-3ab2-4092-b62c-f834297f1473", APIVersion:"v1", ResourceVersion:"18373286", FieldPath:""}): type:
ormal' reason: 'FileSystemResizeRequired' Require file system resize of volume on node
1 controller.go:281] Started PVC processing
"liyuemcamel-ns/data-recover0719-mysql-2"
1 controller.go:324] No need to resize PV
"pvc-195221fb-3ab2-4092-b62c-f834297f1473"

We need to figure out where the 'limit 1GB'  come from.

authors: liyuerich zhaosimon

repo: hwameistor/hwameistor


text:
Pass Google Drive Service to GoogleDriveLoader instead of the token.json and credentials.json

Feature request
Modify GoogleDriveLoader so that it can accept a Google Drive Service instead of relying on file path to token.json and credentials.json
Motivation
I am deploying LangChain in serverless environment where I use Redis for chat memory and security token store. In this context, it would be useful to be able to directly source the Google Drive connection credentials from Redis. Typically this could be done as follow:
class GoogleDriveLoader(BaseLoader, BaseModel):
"""Loader that loads Google Docs from Google Drive."""
credentials_path: Path = Path.home() / ".credentials" / "credentials.json"
token_path: Path = Path.home() / ".credentials" / "token.json"
**service: Optional[Resource] = None #Proposed patch**
folder_id: Optional[str] = None
document_ids: Optional[List[str]] = None
file_ids: Optional[List[str]] = None

Then it is mostly about wrapping the three instances in a function that would make them optional if service is supplied as a parameter.
creds = self._load_credentials()
service = build("drive", "v3", credentials=creds)
Your contribution
I can propose a fork if there is some interest with this evolution.

Submitted as a pull request:
https://github.com/hwchase17/langchain/pull/5147


text:
Piloting

I have this code:

var bebop = require('node-bebop');
var drone = bebop.createClient();
var movement = new Object();
movement.dX = 0;
movement.dY = 0;
movement.dZ = 0;
movement.dPsi = 3.1416;

drone.connect(function () {
    drone.Piloting.takeOff();
    setTimeout(function() {
        drone.Piloting.moveBy(movement);
    }, 5000);
    setTimeout(function() {
        drone.Piloting.landing();
        console.log("LAND");
    }, 15000);
});

The drone takes off
Does nothing
Lands
I was wondering if there is a way to fix that because according to http://developer.parrot.com/docs/reference/bebop/index.html#move-the-drone-to-a-relative-position which is supportted since 3.3.0, currently my drone is running the 4.4.0

@Mastuerso
moveBy function seems like not implemented yet.. only Draft :)
link : https://github.com/hybridgroup/node-bebop/blob/master/docs/commands.md#pilotingmovebyobj

authors: Mastuerso muf

repo: hybridgroup/node-bebop

license: mit


text:
fix(Webhook): avatar override not working sometimes

Please describe the changes this PR makes and why it should be merged:
Somewhat of an edge case fix where the provided URL was too big for the actual avatar size, which would cause a blank/see-through avatar to show up as the overridden Webhook's avatar.
Semantic versioning classification:

[ ] This PR changes the library's interface (methods or parameters added)

[ ] This PR includes breaking changes (methods removed or renamed, parameters moved or removed)

[ ] This PR only includes non-code changes, like changes to documentation, README, etc.

was decided that its an error on the user's part to manually pass a file size for images that arent big enough.


text:
[BUG] Interface Glitches

Describe the bug
After launch, everything works, but when you hover over any element of the interface, everything constantly changes colors
Steps to Reproduce

Start the software
Start using anything on the screen.
Turn it off so that it all stops eating your eyes

Expected behavior
I expect everything to work as it should
Screenshots

Operating System
Windows 10
Hydra Version
2.0.1
Additional Information
No response

Could you try:

Close Hydra process completely
Disable Nvidia overlay
Start Hydra again

Looks like it worked. But this is not quite a solution to the problem, because I need the Nvidia app and its related components. Can something be done for a global solution instead of a local one?

We looking for it, but haven't found a global solution yet

Oк, thank you. In this case it remains only to wait

authors: Bigbigliar zamitto

repo: hydralauncher/hydra


text:
Release/3.0

No conflicts after #196

It seems like other than, https://github.com/hydrator/wrangler/commit/216f0b3e6a9861af239d5b7dedb54789a741c87a, this includes all the changes already in develop. Since https://github.com/hydrator/wrangler/commit/216f0b3e6a9861af239d5b7dedb54789a741c87a is only a version bump, I will merge this PR, and then create a follow up to bump versions.

repo: hydrator/wrangler


text:
Data Science for Social Good + NWM Summer Innovators

Task 5 Expand HydroShare’s Capacity for storage, outreach and user engagement. 5a. Leverage Hurricane Harvey and Irma RAPID support [NSF Award #1761673] to supplement available operational hurricane data (if available). 5b. Develop single online toolkit that is functional for different events, various models, and in any disaster locations, but with one HydroShare web hosted page for Puerto Rico data access: Almost Like Maria 5c. Engage students in real world projects with high impacts for public good.

Deadline Feb 25 - http://escience.washington.edu/dssg-proposal
Title:
Lead
Project Participants who will be in the Studio:
Describe the Project Lead's qualifications for executing the project. Please be sure to include relevant expertise in areas of domain knowledge, social sector issues, programming and/or analytical skills, mentorship, team management.
Please identify the stakeholders in the project, including any entities that are involved in, or affected by, the project and its aims. If applicable, please describe the roles of any stakeholders who will be directly involved with the project (for example, DSSG projects often involve government agencies, non-profit organizations, private companies, user communities, etc.). *
Submit a 500-700 word summary of the project and objectives. The ideal proposal will clearly identify the datasets involved and the research question(s) to be answered. Please also explain how the technical component of the project is critical to delivering exciting new findings. *
The student fellows in our program have diverse backgrounds and skill sets. Please describe 1) the kinds of tasks you envision your student team under-taking; and 2) the types of backgrounds or expertise that would be most helpful for your project. *
Please describe how this project contributes to social good. Briefly define the social problem or issue the project is addressing, and explicitly articulate the mechanisms by which the proposed work is expected to affect that problem or issue.
What are the ethical considerations for this project, from data collection through to dissemination of results? Who are the intended beneficiaries and what are the potential risks and implications of this work? Please explain how you plan to address these risks and ethical concerns during the DSSG program and beyond. *
Describe how you will assess the success of the project. Please specify a) what deliverables will be produced if the project is successful, including papers, software, datasets, teaching materials, blog posts, and/or visualizations, and b) future impact or influence that would constitute success for the project. NOTE: If this proposal is part of an ongoing project, please differentiate your DSSG summer goals from those of the larger project and indicate the precise role that the DSSG will play in the project.
Description of Project Data *
Are the data subject to any rules, regulations, or restrictions, such as licensing, IRB, FERPA, HIPPA, ITAR, or other legal restrictions? If yes, explain.

repo: hydroshare/PuertoRicoWaterStudies


text:
related resources dropdown addition

We receive a suggestion for the related resources from Adam Ward (CUAHSI BOARD member), @horsburgh @dtarb  what are your thoughts on it?
In   the “related resources” dropdown, I suggest adding the following option:
The   model used to generate these data is described by:
This   would let those of us archiving model results link to the original pub where   a model was derived or validated.       Or,   I suppose a category of “OTHER” with a field to fill in would be more   flexible, and when you see one getting used regularly it could be added to   the dropdown?
Adam S. Ward, PhD,   PE
Associate Professor   adamward@indiana.edu   812-856-4820
O’Neill School of   Public and Environmental Affairs
Indiana University   418 MSB-II,   Bloomington, IN 47405

There's an existing issue that deals with references that still needs to be addressed - #3261. We developed a Google Doc that describes all of the changes that need to be made here:
https://docs.google.com/document/d/1BssYnm6Taw3GVW8Qv8ldLO-H3VZqo16Kejypkrmd6KA/edit
This includes an overhaul of the terms used to describe relationship types, which are listed here:
https://docs.google.com/spreadsheets/d/1zcJcsxeTxik5dyuCJAkOooSfqbk1kVmjolZo6NYwIpA/edit#gid=0
But, I think we can address this now with existing functionality and terms.
For this example, if it were a model instance resource, the "isDescribedBy" term (This resource is described by) could work well, indicating that the published paper describes the model used to create/execute the model instance. However, since we can do both models and model instances in HydroShare, the model could be created as a "Model Program" resource type. The paper that describes the model could then be included as a relation in the Model Program resource using the "isDescribedBy" relationship type. Then, the specific instance of the model (e.g., the inputs and potentially outputs should be created as a "Model Instance" resource type. The Model Instance resource can link to the model program using the "executedBy" relationship type.
So, in the end you have the following relationships expressed:
The published paper describes the model program resource.
The model instance resource can be executed by the model program resource.

Jeff, I did assign this to you to, do you think we are far enough along in the process that we can get this into the next release probably in September?

I should think @Maurier would be able to get through this for a release in September, but I don't think he's been working on it.
@Maurier - can you take a fresh look at this issue with the google docs and let us know what you think about targeting a release in the near future?

I went through what is documented on this topic and it is all well organized into actionable items. I will start working on this now and report back when I have a more accurate assessment for a time of completion.
I expect I will have to consult with other developers in order to implement some of the changes to resourcemetadata.xml.

authors: Maurier horsburgh martinseul

repo: hydroshare/hydroshare


text:
Import element fuctions to reuse on my own code

Hey, I'm usign @graphcms/rich-text-html-renderer and found a situation where I would like to reuse element functions to use directly on my code inside of custom renderers, currently it only export astToHtmlString function.
My use case:
import { astToHtmlString, Link } from '@graphcms/rich-text-html-renderer'

...
renderers: {
  a: (props) => {
    const condition = true
    return condition
      ? `<a data-condition="special-data">${props.children}</a>`
      : Link(props)
  }
}

With that I could import Link function and keep consistency with rich-text-html-renderer library without rewriting this function as a workaround.
Is today able to import thoses functions in another way or would be able to export together further?
PS: If it's okay to export those functions I could open a PR for that

Opened PR https://github.com/hygraph/rich-text/pull/107

This does make sense to include. I also had a similar use case.
I'll review your PR and publish it. Thanks, @rbastiansch!

Merged #107. I'll publish it soon

authors: jpedroschmitz rbastiansch

repo: hygraph/rich-text


text:
Добавлено открытие Source View в новой вкладке для лучшего понимания изменения свойств

это можно слить в models_select, должно завестись почти без правок

authors: Lyumih PavelZubkov


text:
Use GetCellSeparators lines for Grid visualization performance improvement.

Update Elements to consume fix for accessing BoundedCurve data.
Function spends a lot of time on Grid2D serialization since every little line segment is serialized as individual ModelCurve.
Use GetCellSeparators that only return complete lines, including trims.
This changes amount of visualization lines from U * V to U + V.
Add "No Grid" filter.
I can't publish to original function, so it's only published to my version.

This change is

@anthonie-kramer FYI

repo: hypar-io/HyparSpace


text:
📌2.0 ToDo

As most of you may be well aware of, Hyperapp 2.0 is coming #672. 🎉
Here's my todo list before I am ready to publish its beta test version.

[x] Split up code base into one file per every function (clone.js, patch.js, h.js, app.js, etc.)
[x] Optimize defer function. Instead of setTimeout, use Promise.resolve (faster).
[x] Implement new internals dispatch, setState, runCommand, render.
[x] Update DOM manipulation functions (patch, createElement, updateAttribute) to accept resolveNode and eventProxy).

[ ] Implement new resolveNode to support children as a prop.
[ ] Determine how the new lazy components (dynamic) components will be implemented, e.g., passing dispatch as the second argument to every component or similar.

[ ] Implement the Subscriptions API.

[ ] Publish an independent library that demonstrates (or expands on) these ideas to start a discussion.

[ ] Implement targeted merges.
[x] Add support to updateAttribute to compute a Element.className from an object, similar to classcat, but built-in.
[ ] Fix and add new tests.
[ ] Decide how the middleware API should work. /cc @okwolf

Your comments and feedback, please! 🙏

Glad there is a thought out plan! Looking forward to the changes 🙏

The topic we were all awaiting 🎉
Is there some things we can help on ?

@Swizz Tests 😅and testing the beta release when it's published, also documentation ideas and the website, but notice I didn't include that on the todo list. Hyperapp 2.0 is coming first.

With a grateful 1.x to 2.x path, the adoption will be easier.
Hyperapp 1.x is not here since years, and I am pretty sure, Hyperapp 2.x will allow all this features to live in userland :+1:

@jorgebucaran  3.1. There may be lazy components, after all, I'm not too sure about it. How are you using its context-like functionality? I'd really like to hear that.

My main app codebase was mostly in place by the time lazy components landed, so I'm not using them very much yet.  There's one or two places where I used them to access state, but those components weren't deeply nested, so I mostly did it because I could.   I'm sure some other people have used/abused it more than I have :laughing:
The biggest benefit my app had from lazy components was being able to access the global actions object, especially for my router's Link component.  With 2.0's version of actions, this use case goes away.

Yeah access to global state and actions are somewhat like the new context API in React. But maybe it not only allows for dynamic actions without rewriting the actions, but could provide us with a more elegant alternative to things like Redux as well.

And we want to see it public ASAP.

And maybe we could write components like
// This is only possible because Connector is a lazy component
// that knows the underlying state
// Or maybe mutations should know the state whole?
var Component = function (props) {
    return (<Connector render={function (stateSlice, mutations, operations) {
        return (<Selector from={stateSlice} render={function (selectedState) {
            // Actual rendering goes here.
        }} />);
    }} />);
};

In the React community, there has been a recommended practice that

In general, the shape of the state is something only reducers should know about. The moment it leaks out of the store, code becomes structurally coupled.

Since reducers decide what’s the shape because they write it. It’s just common sense to make the “read” happen close to them with selectors.

As a rule of thumb, doing state. is a mistake. The only place where that should be allowed is inside a selector. But only as long as the selector is [collocated] in the reducer which is responsible for that part of the state.
—https://hackernoon.com/selectors-in-redux-are-a-must-d6b0637c79b7

@jorgebucaran thanks. 🐈

I'm so excited about this, I can't wait to start beta testing. I'd love to render some though. 😎

Hi, is there any reason code is not written in ES6 ?

@bardiarastin Other than ES modules, we're not using any modern JavaScript idioms.
The main reason is I want full control over the code I am writing and shipping and don't want to introduce a build step to the project. It's a modest attempt to make a case for simplicity.

👍  for a new subscription library
👍  for middleware API

#703

First of all thanks for Hyperapp 1.x, it was just what I needed and all in a tiny lib.
I have a couple of projects running in 1.x that are good candidates to beta test the 2.0.

Curious if you'll refactor patch algo to improve Hyperapp performance in comparison to other frameworks on Stefan Krause's js-framework-benchmark.

@rbiggs Not for 2.0, but after (when I have time again). FWIW #663 improved those numbers substantially. You are welcome to discuss performance more in #499.

@emil14 Hyperapp doesn't need any modern JavaScript features at the moment, so performance is not affected because of this decision. For example, if we wanted to use Set or Map and because of poor browser support shipped our own shims, then you'd be totally right  — we'd be better off using the browser's native Set and Map.
Things Hyperapp doesn't use or avoids without affecting its perf:

Classes, this, prototypes
Set, Map, WeakSet, WeakMap
Block-Scoped (let, const)
Destructuring

FWIW, not using prototypes may in fact negatively affect performance. But you don't need any modern JS features or tooling to use them if you wanted to.

@leeoniya's
I am not saying I could've used prototypes, but decided not to because I have thisphobia. 😄
I am saying Hyperapp doesn't make use of prototypes. Hyperapps don't have methods or properties and there are no app instances either. In 1.0, even if you had multiple apps running on the same page (not encouraged either) they are unlikely to share the same implementation of actions, so you'd need to create a different actions object for each app call.
In 2.0 there is not even an actions object, so I've yet to find a use case for prototypes in Hyperapp.

i also keep this and new out of domvm's public apis. however, there are legitimate perf reasons for using prototypes internally.

Thanks, if you find a good reason to use it in Hyperapp let us know.

@jorgebucaran
Thank you for your answer! But I still don't agree with you :)
You can write sources in ESNext and let us to choose, should we transpile it or not, what browser support we need. You can ship ES5 via CDN and add something like hyperapp.es5.js to the npm-package, don't you?
If you afraid of greater bundle size, generated by Webpack/Parcel/Rollup - do you really think it's so important ? :)

Classes, this, prototypes

I can understand that. These features are not very "functional", but the rest of them are good

Do we have first implementation of readme or some examples for the hyperapp v2.0 ?

A few ES 6 features could have been useful like promises 😉

I believe subscriptions are already implemented, but are you still planning to include classcat style support?

@okwolf Yes, I want to. What do you think? :)

@jorgebucaran I like the idea. How much bloat are we talking about adding?

Please no, it is not needed in case of using CSS Modules or CSS in JS.

@okwolf Not a lot. See https://github.com/jorgebucaran/classcat
@frenzzy This feature is consistent and harmonious with VDOM, but you make a point. How do you personally use CSS modules or CSS in JS with Hyperapp? Do you have any examples? Maybe that could help me decide.

@frenzzy I don't understand. How does CSS modules or CSS in JS make classcat unnecessary?
With plain css I'd use it like this:

  {items.map((text, index) => (

= 0
    })}> {text}

  )}

with css moduled (with classes imported as the var style), like this:

  {items.map((text, index) => (

= 0
    })}> {text}

  )}

sure, the syntax is a little more verbose with css modules, but in both cases classcat (cc in the example) significantly simplifies the code for toggling and concatenating classes. And that's quite a common need. In fact I use it in all but my most trivial projects. So I'm pro including it.

May be classcat (and probably other features) can be separate module because of flexibility? Everyone can include it if wants or not. Also I think that it can be exists in the official doc as the recommended way.

I think it's mostly a question of: how will this feature behave when you don't need to toggle classes. I think these should (and would) all work as expected with cc included:
class={'foo'}
class={'foo bar'}
class={['foo', 'bar']}
class={{foo: isFoo()}
class={['foo', {bar: isBar()}]}

@zaceno Yep, as you said, they'd all work.

How do you personally use CSS modules or CSS in JS with Hyperapp?

The way I use it right now is like this
// This helper generates a className and insert a style rule in the DOM.
// I can be for instance emotion-js, CSS modules "import", or a custom helper
const componentClass = generateClass('/* CSS rules here */')

const MyComponent = (props) => (

)

With conditional styles, I usually use ES6 string interpolation:
// This helper generates a className and insert a style rule in the DOM.
// I can be for instance emotion-js, CSS modules "import", or a custom helper
const componentBase = generateClass('/* CSS rules here */')
const isComponentActive = generateClass('')
const themes = {
  RED: generateClass('/* red theme */'),
  BLUE: generateClass('/* blue theme */'),
}

const MyComponent = ({ active, theme }) => (

)

// By default: inactive, default theme is red
<MyComponent />

// Activates the blue theme
<MyComponent active theme="BLUE" />

For my use cases, a classcat helper is not necessary.

Usually use this simple inline class concat or can extract to a helper if used a lot:
import style from './style.css'

const FooComponent = ({ active }) => (

)

@thibautRe @gpoitch Thanks for sharing that.
Well, it seems neither CSS modules or CSS in JS would interfere with a classcat-like built-in functionality.

Having classcat-like functionality built-in would be handy sometimes.
I pretty much exclusively use Tailwind.css now, with some sprinkles of custom CSS classes, so the CSS-in-JS stuff is a non-issue.

@jorgebucaran did we drop the idea of middleware? If not, maybe classcat could be vdom middleware that checks props for class, and if it's an object, parses, and if it's a string, passes that through as normal - that keeps it out of everyone's hair, but would make it easy enough to flip a switch and enable it.

@mrozbarry did we drop the idea of middleware?

Not quite! See #703.

Closing for #726.

authors: SkaterDad Swizz ThobyV bardiarastin dcustodio dmitrykurmanov emil14 frenzzy gpoitch infinnie jorgebucaran leeoniya mrozbarry okwolf rbiggs selfup thibautRe zaceno

repo: hyperapp/hyperapp


text:
[QUESTION] Http Request请求请默认允许跨域

【文件】 Hyperf\HttpServer\Server
【行数】:96
【为了默认允许跨域，需要增加以下代码】：

        try {
//  允许跨域开始
            $response->header('Access-Control-Allow-Origin', '*');
            $response->header('Access-Control-Allow-Methods', 'GET, POST, DELETE, PUT, PATCH, OPTIONS');
            $response->header('Access-Control-Allow-Headers', 'Authorization, User-Agent, Keep-Alive, Content-Type, X-Requested-With');
            if ($response->server['request_method'] == 'OPTIONS') {
                $response->status(http_response_code());
                $response->end();
                return;
            }
//  允许跨域截止

            [$psr7Request, $psr7Response] = $this->initRequestAndResponse($request, $response);

            $middlewares = array_merge($this->middlewares, MiddlewareManager::get($this->serverName, $psr7Request->getUri()->getPath(), $psr7Request->getMethod()));

            $psr7Response = $this->dispatcher->dispatch($psr7Request, $middlewares, $this->coreMiddleware);
        }

处理跨域自己写个 Middleware 就可以了。
<?php
declare(strict_types=1);
/**
 * This file is part of Besthird.
 *
 * @document https://besthird.github.io/rbac-doc/
 * @license  https://github.com/hyperf-cloud/hyperf/blob/master/LICENSE
 */
namespace App\Middleware;
use App\Kernel\Http\Response;
use Hyperf\Utils\Context;
use Psr\Container\ContainerInterface;
use Psr\Http\Message\ResponseInterface;
use Psr\Http\Message\ServerRequestInterface;
use Psr\Http\Server\MiddlewareInterface;
use Psr\Http\Server\RequestHandlerInterface;
class CorsMiddleware implements MiddlewareInterface
{
    /**
     * @var ContainerInterface
     */
    protected $container;
    public function __construct(ContainerInterface $container)
    {
        $this->container = $container;
    }
    public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface
    {
        $response = di()->get(Response::class)->response()->withHeader('Access-Control-Allow-Origin', '*')
            ->withHeader('Access-Control-Allow-Credentials', 'true')
            ->withHeader('Access-Control-Allow-Headers', '*');
        Context::set(ResponseInterface::class, $response);
        if ($request->getMethod() == 'OPTIONS') {
            return $response;
        }
        return $handler->handle($request);
    }
}

如果js提交请求的时候有withCredentials:true 的话，简单粗暴地返回 Access-Control-Allow-Origin: * 是行不通的。

所以这个还需要你们自己改改。

authors: limingxinleo qifengzhang007 xurenlu

repo: hyperf/hyperf


text:
bvh panic

The test server panicked with the following message:
2024-12-31T00:19:43.605742Z  INFO generate_ingress_events: crates/hyperion/src/ingress/mod.rs:332: queue pending remove
thread 'main' panicked at /app/crates/bvh-region/src/query/closest.rs:70:30:
called `Option::unwrap()` on a `None` value
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::panicking::panic
   3: core::option::unwrap_failed
   4: flecs_ecs::core::utility::traits::private::internal_SystemAPI::execute_each_entity
   5: flecs_run_intern
   6: flecs_run_pipeline_ops
   7: flecs_run_pipeline
   8: flecs_workers_progress
   9: ecs_progress
  10: flecs_default_frame_action
  11: flecs_default_run_action
  12: tag::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

I don't know if the "queue pending remove message" is related; the panic doesn't have a timestamp. Unsure how to reproduce this issue at the moment

this issue was fixed in the arrows repo

authors: Tebarem TestingPlant

repo: hyperion-mc/hyperion


text:
Allow HTTP/2 request multiplexing with low-level client API

(👋  first off, hyper is awesome, thanks to all contributors for it!)
We're using a custom connection pool internally that's based on the low-level api, ie conn::Builder::handshake and conn::SendRequest instead of Client.
However, the built-in Client uses the private type Http2SendRequest, which turns the dispatch::Sender into a dispatch::UnboundedSender, which as I understand it, allows multiplexing HTTP/2 requests over a single connection.
Without the UnboundedSender, even though the inner type of dispatch::Sender is an mpsc::UnboundedSender, sending is limited by the Giver, so a new request will only be accepted once the previous one has been fully processed.
The comment for Http2SendRequest seems to indicate it's not ready for prime time / one wouldn't want to commit to it as part of hyper's public API:
// A `SendRequest` that can be cloned to send HTTP2 requests.
// private for now, probably not a great idea of a type...

Are there any alternative approaches that would be suitable as part of the public API? If not, would you consider exposing it publicly when a cargo feature is enabled (maybe unstable_h2_send_req, to indicate that it may change at any time without notice?).
Our immediate workaround is forking hyper to expose it - I'd love for that solution to be as short-term as possible - if there were ambient ideas on what a better API could be, I'd be happy to contribute making it happen.

I believe even the SendRequest should allow for HTTP/2 request multiplexing. It doesn't require the response to be returned to send a new request, it's just trying to propagate the backpressure if the h2 connection has hit the remote's max concurrent streams setting.

Just checking in here: with my comment, was it possible to get multiplexing working without forking?

Just checking in here: with my comment, was it possible to get multiplexing working without forking?

Just checking in here: with my comment, was it possible to get multiplexing working without forking?

Sorry for the delay, multiple things happened in that 20-day interval — I've still got "do actual packet capture and determine if HTTP/2 multiplexing is in fact used" on my TODO list, will get to it soon :TM: and will update you here.

Just checking in here: with my comment, was it possible to get multiplexing working without forking?

Sorry for the delay, multiple things happened in that 20-day interval — I've still got "do actual packet capture and determine if HTTP/2 multiplexing is in fact used" on my TODO list, will get to it soon :TM: and will update you here.

Was finally able to put some time into this!
Here's the sort of behavior I'm currently seeing:

(There's a single SendRequest involved here, TCP_NODELAY is disabled here.)
By contrast, here's h2load (that comes with ng2http) sending 50 requests in a single TCP packet:

I'm going to do some further tests, but I'm closing this since, yes, technically HTTP/2 request multiplexing does happen with the low-level client API, ie. several requests are sent (on several streams) before the responses come in — how they're distributed across TCP packets is beyond the scope of this!

Was finally able to put some time into this!
Here's the sort of behavior I'm currently seeing:

(There's a single SendRequest involved here, TCP_NODELAY is disabled here.)
By contrast, here's h2load (that comes with ng2http) sending 50 requests in a single TCP packet:

I'm going to do some further tests, but I'm closing this since, yes, technically HTTP/2 request multiplexing does happen with the low-level client API, ie. several requests are sent (on several streams) before the responses come in — how they're distributed across TCP packets is beyond the scope of this!

authors: fasterthanlime seanmonstar

repo: hyperium/hyper


text:
Have wildcard header value const

Why ? I don't like unwrap and I'm lazy. I think it's reasonable, wildcard as header value is a lot used.
Request: A prebuild HeaderValue for "*" like HeaderValue::WILDCARD or header::WILDCARD

You can do
use http::HeaderValue;

const WILDCARD: HeaderValue = HeaderValue::from_static("*");

With HeaderValue::from_static.

and the function is const nice... well I still think it wouldn't hurt to have a Wildcard directly in the crate but I will use your solution for now thanks.

Since you can make a const in your code, I think I'll close this one. Thanks for the suggestion, though.

authors: Stargateur davidpdrsn seanmonstar


text:
Getting error while issuing credentials

Hello, I am trying to issue a credential using a javascript controller made by me, but I am getting the following error on sending the data to /issue-credential/send
{'connection_id': ['Missing data for required field.'], 'credential_proposal': ['Missing data for required field.']}
My credential object looks like this
{
"comment": "string",
"credential_proposal": {
"@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/issue-credential/1.0/credential-preview",
"attributes": [
{
"name": "Name",
"value": "Alice Smith"
},
{
"name": "Date",
"value": "2020-01-01"
},
{
"name": "Degree",
"value": "Maths"
},
{
"name": "Age",
"value": "24"
}
]
},
"schema_issuer_did": "GCezUGKaGXjaeuUrGgN22f",
"connection_id": "804d0219-cd5a-4a1b-8db8-4244ad8dd641",
"schema_version": "2.0",
"schema_id": "GCezUGKaGXjaeuUrGgN22f:2:Vague:2.0",
"issuer_did": "GCezUGKaGXjaeuUrGgN22f",
"cred_def_id": "GCezUGKaGXjaeuUrGgN22f:3:CL:139026:default_vague",
"schema_name": "Vague"
}

The error message seems to indicate connection_id and credential_proposal are either missing or malformed, however the above JSON looks fine to me. @andrewwhitehead @ianco do you have any thoughts other than confirming the payload being sent to the agent matches the above?

The json looks good to me.

Another thing i'd like to add for @ianco and @esune is that the same controller works fine with the aca-py agents running on play with docker, the one given in demo. And another thing is, for the agent i am running on my own computer, when i issue credentials with same json using swagger api, it works fine. Similar issue comes with the acme controller while requesting proofs, i am using the acme controller as given in demo.

Very odd. It sounds like the only difference in your setup is the agent you are posting requests to, so I'd start by confirming the version and startup settings are the same in both cases.

Very odd. It sounds like the only difference in your setup is the agent you are posting requests to, so I'd start by confirming the version and startup settings are the same in both cases.
I am on the latest version of aca-py which is 0.6.0 , and i'd put the startup flags
aca-py start --label Faber \ -it http 0.0.0.0 8000 \ -ot http --admin 0.0.0.0 8021 \ --admin-insecure-mode \ --genesis-url "http://test.bcovrin.vonx.io/genesis" \ --seed {{seed}} \ --endpoint "http://localhost:8000/" \ --debug-connections --auto-provision \ --wallet-type indy --wallet-name FABER \ --wallet-key secret --auto-accept-requests \ --auto-accept-invites --auto-ping-connection --auto-respond-credential-proposal \ --auto-respond-credential-offer --auto-respond-credential-request \ --auto-store-credential

I am on the latest version of aca-py which is 0.6.0 , and i'd put the startup flags
aca-py start --label Faber \ -it http 0.0.0.0 8000 \ -ot http --admin 0.0.0.0 8021 \ --admin-insecure-mode \ --genesis-url "http://test.bcovrin.vonx.io/genesis" \ --seed {{seed}} \ --endpoint "http://localhost:8000/" \ --debug-connections --auto-provision \ --wallet-type indy --wallet-name FABER \ --wallet-key secret --auto-accept-requests \ --auto-accept-invites --auto-ping-connection --auto-respond-credential-proposal \ --auto-respond-credential-offer --auto-respond-credential-request \ --auto-store-credential

I think the endpoint declaration is incorrect, as localhost will be resolved by other agents as their own service/host - you need to use an address that is addressable by other services s well (e.g.: host.docker.internal or the docker VM IP address, an example of scripts that pull it ishere).
Once thing you can check is the state of the connection you are going to be sending the credential on: if the agents can't talk both ways it will not get to active (I suspect this might be the case).

I think the endpoint declaration is incorrect, as localhost will be resolved by other agents as their own service/host - you need to use an address that is addressable by other services s well (e.g.: host.docker.internal or the docker VM IP address, an example of scripts that pull it is here).

This looks possible, although all agents are running on the same network, i'll still try explicitly mentioning the ip address.

@esune so I mentioned the endpoint IP explicitly, opened the ports , and even checked whether the connections are active, still I am getting the same error.

Seems the issue was about Content-Type , i didn't mention application/json and thus it wasn't working. It used to work in older versions so I thought it would work here too. But now it is all settled. Thank you. @esune and @ianco for your help.

authors: esune iaman1998 ianco

repo: hyperledger/aries-cloudagent-python


text:
Add support for 0454: Present Proof v2

https://github.com/hyperledger/aries-rfcs/tree/b3a3942ef052039e73cd23d847f42947f8287da2/features/0454-present-proof-v2

Hi @TimoGlastra , I would like to start working on this ticket. Can you please assign this to me. Thanks

You got it!

authors: NB-PrasadKatkar TimoGlastra

repo: hyperledger/aries-framework-javascript


text:
refactor!: rename Handler to MessageHandler

Rename Handler to MessageHandler based on feedback from PR #1158
BREAKING CHANGE: Handler has been renamed to MessageHandler to be more descriptive, along with related types and methods. This means:

Handler is now MessageHandler
HandlerInboundMessage is now MessageHandlerInboundMessage
Dispatcher.registerHandler is now Dispatcher.registerMessageHandlers

Codecov Report

Merging #1161 (9502072) into main (0e89e6c) will not change coverage.
The diff coverage is 96.99%.

@@           Coverage Diff           @@
##             main    #1161   +/-   ##
=======================================
  Coverage   88.77%   88.77%
=======================================
  Files         706      706
  Lines       16503    16503
  Branches     2678     2678
=======================================
  Hits        14651    14651
  Misses       1845     1845
  Partials        7        7

Impacted Files
Coverage Δ

packages/core/src/modules/proofs/ProofService.ts
68.96% <ø> (ø)

.../modules/connections/handlers/AckMessageHandler.ts
71.42% <50.00%> (ø)

...ctions/handlers/TrustPingResponseMessageHandler.ts
71.42% <50.00%> (ø)

...cation/handlers/V1RevocationNotificationHandler.ts
71.42% <50.00%> (ø)

...cation/handlers/V2RevocationNotificationHandler.ts
71.42% <50.00%> (ø)

...ol/v1/handlers/V1CredentialProblemReportHandler.ts
71.42% <50.00%> (ø)

...ol/v2/handlers/V2CredentialProblemReportHandler.ts
71.42% <50.00%> (ø)

...c/modules/routing/handlers/MediationDenyHandler.ts
62.50% <50.00%> (ø)

packages/action-menu/src/ActionMenuApi.ts
97.82% <100.00%> (ø)

...enu/src/handlers/ActionMenuProblemReportHandler.ts
100.00% <100.00%> (ø)

... and 71 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

authors: TimoGlastra codecov-commenter


text:
feat: add issue credential v2

Signed-off-by: Mike Richardson mike.richardson@northernblock.io

Codecov Report

Merging #745 (d7a76f0) into main (2da845d) will increase coverage by 0.43%.
The diff coverage is 90.19%.

@@            Coverage Diff             @@
##             main     #745      +/-   ##
==========================================
+ Coverage   86.27%   86.71%   +0.43%
==========================================
  Files         369      393      +24
  Lines        8014     9205    +1191
  Branches     1358     1621     +263
==========================================
+ Hits         6914     7982    +1068
- Misses       1041     1161     +120
- Partials       59       62       +3

Impacted Files
Coverage Δ

packages/core/src/logger/ConsoleLogger.ts
41.17% <ø> (ø)

...connections/errors/ConnectionProblemReportError.ts
100.00% <ø> (ø)

.../modules/connections/services/ConnectionService.ts
88.78% <ø> (ø)

...s/core/src/modules/credentials/CredentialEvents.ts
100.00% <ø> (ø)

...s/credentials/protocol/v1/models/CredentialInfo.ts
100.00% <ø> (ø)

...edentials/protocol/v1/models/RevocationInterval.ts
75.00% <ø> (ø)

.../credentials/repository/CredentialMetadataTypes.ts
100.00% <ø> (ø)

...src/modules/indy/services/IndyRevocationService.ts
58.90% <ø> (ø)

...e/src/modules/ledger/services/IndyLedgerService.ts
63.97% <ø> (ø)

...e/src/decorators/attachment/AttachmentExtension.ts
50.00% <14.28%> (ø)

... and 69 more

Continue to review full report at Codecov.

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

authors: NB-MikeRichardson codecov-commenter


text:
Besu Chain is stuck if too many smartcontract deployment requests in TX pool

Description
As an Besu Client, I set Besu blockperiod as 2 seconds,
I built a smartcontract, and use one single account to deploy this smartcontract 800 times. the deployment requests are come into 800 transactions.
then I submitted 800 transactions in transaction pool with nonce gap,  for example, one account latest nonce is 5, and I set the 800 transaction's nonce get start with 10, then all the 800 transactions with nonce number is 10-810, and they will stay in transaction pool and wait the nonce gap is fixed.
s
so that after I fixed nonce from 5-9, then the whole TX pool seems be stuck, sometimes it will gave a "max selection timeout issue", and it can't generate the blocker anymore, when all the transactions was deleted after it's expired(13 hours), even the chain can generate the new block,  when I submit several TX without nonce gap with same account address, it seems the TX was missed, I can't find it on chain or TX pool.
Acceptance Criteria

The Besu can runs well after I fixed all the nonce gap issue in TX pool.

Steps to Reproduce (Bug)

To build a smart contract into binary code, and set Besu blockperiod time as 2 seconds;
To create a new account on chain;
To deploy the smart contract with the same account 800 times with nonce gap, and keep all the 800 TXs in TX pool;
Try to fix the nonce gap;
If you see there is no new block generate, this issue is reproducing successfully;

Expected behavior: [What you expect to happen]
When the nonce gap was fixed, all the 800 transactions will be submitted on chain, and block can be generated in a right way.
Actual behavior: [What actually happens]
The chain is stucked, and no new block is generated.
Frequency: [What percentage of the time does it occur?]
100%
Logs (if a bug)
Please post relevant logs from Besu (and the consensus client, if running proof of stake) from before and after the issue.
Versions (Add all that apply)

Software version: [besu --version] Besu 23 ~ 24.7.0
Java version: [java -version] JDK17 for Besu23, JDK21 for Besu 24
OS Name & Version: [cat /etc/*release]  Redhat
Kernel Version: [uname -a]
Virtual Machine software & version: [vmware -v]
Docker Version: [docker version]
Cloud VM, type, size: [Amazon Web Services I3-large]
Consensus Client & Version if using Proof of Stake: [e.g. Teku, Lighthouse, Prysm, Nimbus, Lodestar]

Smart contract information (If you're reporting an issue arising from deploying or calling a smart contract, please supply related information)

Solidity version [solc --version]
Repo with minimal set of deployable/reproducible contract code - please provide a link
Please include specifics on how you are deploying/calling the contract
Have you reproduced the issue on other eth clients

Additional Information (Add any of the following or anything else that may be relevant)

Besu setup info - genesis file, config options
System info - memory, CPU

Not sure if you have tuned some options, so in case I will suggest to try the following:

Select the txpool implementation to use: layered or sequenced (AKA legacy). Since 23.10.0 layered is the default, use tx-pool option to switch between the 2
Then since you are sending a lot of txs from the same sender, then depending on the implementation you choose, you need to tune it:

layered: tx-pool-max-future-by-sender to a value > of the max number of txs sent that a sender could send together, in your case >800
sequenced: tx-pool-limit-by-account-percentage=1.0 assuming tx-pool-max-size is big enough to keep all the pending txs for your network

after this tuning you should not experience nonce gap issues anymore (actual result could depend on the fact that other sender and pending txs are present in the pool) and if you still see that txs are still not included due to "max selection timeout issue" or other issues, let me know, so we can investigate further.

@fab-10 hi Fabio, sorry for late due to I was on my holiday this week.
I already used the sequenced TX pool and set tx-pool-limit-by-account-percentage=1.0 on Besu 24.7.0, but the issue is still there. When I change the blockperiodseconds from 2 to 5(not change this field, just change it in TX part as document told me), and the TX pool not stuck in 800 transactions, it will stuck around 2000 TXs in TX pool. it looks like the change state machine states is not right anymore.

I suppose you are running a *BFT network, so in that case, if the issue is that a tx takes too long to execute, then you can try to adjust this option https://besu.hyperledger.org/development/private-networks/reference/cli/options#poa-block-txs-selection-max-time to something more than 100, so block creation could take more than 2 seconds.
If also that does not solve your problem, then it will be great if you can share how to reproduce the issue.

repo: hyperledger/besu


text:
Release 24.10.0

[x] Confirm anything outstanding for release with other maintainers on #besu-release in Discord
[x] Update changelog if necessary, and merge a PR for it to main

[x] Notify maintainers about updating changelog for in-flight PRs

[ ] Optional: for hotfixes, create a release branch and cherry-pick, e.g. release-<version>-hotfix

[ ] Optional: for hotfixes, create a PR into main from the hotfix branch to see the CI checks pass

[x] On the appropriate branch/commit, create a calver tag for the release candidate, format example: 24.10.0-RC2

[x] ~git tag 24.10.0-RC1~ git tag 24.10.0-RC2
[x] ~git push upstream 24.10.0-RC1~ git push upstream 24.10.0-RC2

[x] Sign-off with team; announce the tag in #besu-release in Discord

[x] Targeting this tag for the burn-in: https://github.com/hyperledger/besu/releases/tag/24.10.0-RC2

[x] Consensys staff start burn-in using this tag
[x] Seek sign off for burn-in

[x] Pass? Go ahead and complete the release process
[ ] Fail? Put a message in #besu-release in Discord indicating the release will be aborted because it failed burn-in

[x] Using the same git sha, create a calver tag for the FULL RELEASE, example format 24.10.0
[x] Manually run https://github.com/hyperledger/besu/actions/workflows/draft-release.yml inputing the FULL RELEASE tag name. Note, this workflow should always be run from main branch (this doesn't prevent hotfix tags from being released)

publishes artefacts and version-specific docker tags but does not fully publish the GitHub release so subscribers are not yet notified

[x] Check all draft-release workflow jobs went green
[x] Check binary SHAs are correct on the release page
[x] Update release notes in the GitHub draft release and save draft
[x] Publish draft release ensuring it is marked as latest release (if appropriate)

this is now public and notifies subscribed users
makes the release "latest" in github
publishes the docker latest tag variants

[x] Create homebrew release using update-version workflow

If the PR has not been automatically created, create the PR manually using the created branch update-<version>
Run commands brew tap hyperledger/besu && brew install besu on MacOSX and verify latest version has been installed

[x] Delete the burn-in nodes (unless required for further analysis eg performance)
[x] Social announcements

Burn-in Tracker

Name
Got In Sync?
No Errors?

bu-tk-holesky-burn-full-forest-24.10.0-RC1
🚧
🚧

bu-ls-holesky-burn-snap-24.10.0-RC1
✅
✅

bu-nb-sepolia-burn-snap-24.10.0-RC1
✅
✅

bu-pm-mainnet-burn-snap-24.10.0-RC1
🚧
🚧

bu-lh-mainnet-burn-snap-24.10.0-RC1
🚧
🚧

bu-tk-mainnet-burn-cp-a-24.10.0-RC1
✅
✅

bu-tk-mainnet-burn-cp-b-24.10.0-RC1
✅
✅

RC2 burn-in passed


text:
docs(examples): containerize supply chain app example

Description
Depends on https://github.com/hyperledger/cactus/issues/345
As a person evaluating Cactus for my business use-case I want to have an ever more streamlined way of running the currently available supply chain example so that I spend most of my available time actually discovering Cactus not fighting with the build system/compiler/my own OS level dependencies/package managers and all the other usual suspects that make computing difficult.
Acceptance Criteria

There is a Dockerfile which gets auto-built and published to DockerHub similar how we are already doing it with the AIO test images

cc: @jonathan-m-hamilton @takeutak @sfuji822

Hmm, this was done already, maybe we forgot to close the issue.

repo: hyperledger/cactus


text:
[ja_JP] Translate private-data-arch.rst into Japanese

This patch translates "Architecture Reference » Private Data" into Japanese.
#568
Signed-off-by: Daiki Nakashima Nakashima.Daiki@df.MitsubishiElectric.co.jp

@yukiknd レビューして頂きありがとうございます。ご指摘頂いた内容を反映したので、再度ご確認をお願い致します。


text:
[FAB-17935] Change warning logs to debug when retrieving tx pvtdata from block

Type of change

Improvement (improvement to code, performance, etc)

Description
There are some unnecessary logger.Warning lines in the gossip logs when processing private data from a block.
Related issues
FAB-17935

I agree with Yacov - any unexpected issue should be logged as a Warning so that admins are made aware.
I agree that the original Warning mentioned in the Jira should be turned into a Debug, since it is an expected situation (for non endorser transactions).

Sounds good, I'll change them back to warning

repo: hyperledger/fabric


text:
[FAB-18319] Ch.Part.API: IT Remove and rejoin channel from orderer

Type of change

Test update

Description
Test removal of a channel from an orderer and join it back again to the same orderer.
Related issues
FAB-18319

A general comment... why isn't this just added on to the existing test you used a base for this? Seems like this PR would be about 30 lines instead of 155 and would be easier to review that way.

authors: stephyee wlahti


text:
fix: cannot reuse the same credential-offer in oid4vci

https://input-output.atlassian.net/browse/ATL-7756

:rocket: Merge success

@patlo-iog, should we use the nonce service to detect if the issuance session has already been used to issue the VC?

@patlo-iog, should we use the nonce service to detect if the issuance session has already been used to issue the VC?

No doubt we need to cleanup lots of oid4vci stuff. Let's tackle them when there's no pressure :smile:

authors: patlo-iog yshyn-iohk

repo: hyperledger/identus-cloud-agent


text:
Trigger execution order

Maybe this is a non-issue, but we should define what the order of execution of triggers is when multiple triggers are triggered at the end of block. Also, impose ordering when multiple triggers are triggered by the same event

So currently we have following trigger execution order:

Data events are execute trigger events are produced depending on block content, and for triggers match order depends on trigger id order.
Time events are emitted last so time triggers executed also based on trigger id ordering.

Let's consider the following:

Data events A, B, C
Execute trigger event E
Time event T
Ordering of the events is the following A, E, B, C, T (T is always last)
There is triggers:

TA1, TA2 which triggers by A
TB by B
TC1 and TC2 by C
TE by E: since execute trigger event contains trigger id only single matching trigger is possible
TT1 have 1 match for T, TT2 have 2 matches for T, TT3 have 3 matches for T

There is ordering of trigger ids: TA1 < TA2, TC1 < TC2, TT1 < TT2 < TT3

Then the following execution queue will be created: TA1, TA2, TE, TB, TC1, TC2, TT1, TT2, TT2, TT3, TT3, TT3.

@mversic is that should be documented somewhere?

ok, this looks fine to me

authors: Erigara mversic

repo: hyperledger/iroha


text:
iOS Swift Library installation guide with detailed instructions and d…

iOS Swift Library installation guide with detailed instructions and demo video
Signed-off-by: DenDoronin den.doronind@gmail.com

Description of the Change
Added guide which covers the following areas:

How to build Iroha for your local machine (macOS)
How to start Iroha node using Docker (macOS)
How to build client library for iOS
How to configure test application
How to interact with Iroha blockchain from the mobile device

Additionally, linked a demo video demonstrating all covered steps

Benefits

First guide for ios and swift with detailed instructions, steps so in 20 minutes developer can setup, install, build and launch ios samples
Possible Drawbacks
none

Usage Examples or Tests [optional]

Alternate Designs [optional]

https://html-nfyyjetlkk.now.sh/guides/libraries/swift_ios.html
Link to simplify review process.
Note that images are broken, but it is not a problem of PR, it is a problem of current image asset management and it will be ok when we merge this pr.

Hi @l4l, I've submitted b3549bc459b898a0673c17a560e7d943065d29ed with all findings, please review. thanks.

authors: DenDoronin laSinteZ


text:
[feature] #2280: Produce permission events when role is granted/revoked

Signed-off-by: Shanin Roman shanin1000@yandex.ru

Description of the Change

Add mechanism to return multiple events from modify_* functions;
Fixed error when revoked role does not exist;
Revoke/Grant role also produce PermissionAdded/Removed events.

Issue
Closes #2280.

Benefits
More detailed events.

Possible Drawbacks
None.

/build " && ls "

/build skip_testing

Roles are also revoked when unregistering a role, so if we want to cover all such cases, we should generate token events there.

Good catch, thanks


text:
[feature] #3236: Cache iroha_wasm_builder output

Description
Now you can configure iroha_wasm_builder output dir in a three ways (in order of priority):

Explicitly use out_dir() method
Set IROHA_WASM_BUILDER_OUT_DIR env var
Do nothing if you are in a build-script. Directory will be inherited from OUT_DIR env var which is set by cargo

By default target directory of running crate will be used.
Other than that optimization caching is also implemented.
This is done by comparing sha256 hashes of non-omptimized wasm-files. If hash before and after build are equal, then non-omptimized file wasn't changed, which means that optimized wasm file should also stay unchanged and we don't have to spent time on running wasm-opt.
Also build() will fail now if it's being called on workspace. I think, it was an error that we didn't have that before. It's an error because we run build() only to get Output from it, where Output is a binary encoded WASM file, which we can't choose if we build workspace.

Linked issue

Closes #3236

Benefits
Cached wasm binaries allows us not to rebuild them everytime from scratch. I.e. cached validator builds now take much less time. Same for tests which sumbit wasm.

Checklist

[x] I've read CONTRIBUTING.md
[x] I've used the standard signed-off commit format (or will squash just before merging)
[x] All applicable CI checks pass (or I promised to make them pass later)
[ ] (optional) I've written unit tests for the code changes
[ ] I replied to all comments after code review, marking all implemented changes with thumbs up

Pull Request Test Coverage Report for Build 5447035300

14 of 106 (13.21%)  changed or added relevant lines in 2 files are covered.
15 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-0.1%) to 59.316%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

data_model/src/block.rs
0
13
0.0%

wasm_builder/src/lib.rs
14
93
15.05%

Files with Coverage Reduction
New Missed Lines
%

data_model/src/transaction.rs
1
47.66%

wasm_builder/src/lib.rs
1
41.34%

config/src/client.rs
13
70.42%

Totals

Change from base Build 5423219773:
-0.1%

Covered Lines:
19712

Relevant Lines:
33232

💛  - Coveralls

it seems that only its optimisation output is cached

Actually no. Build step caching is done automatically by cargo. What I did is removing temporary directory for build artifacts

authors: Arjentix coveralls


text:
Think about how verifiable timestamps can be implemented

https://w3c.github.io/did-imp-guide/#verifiable-timestamps

We probably need to take help from  DID team @ w3c.  Need more literature on this.

repo: hypersign-protocol/hid-node