Add type to FunctionSpace and Operator/Fix Evaluation functional over complex intervals

This will allow \ for BigFloat.

This might be useful:
Base.real{T<:Real}(::Union(Type{T},Type{Complex{T}})) = T

That way, things like eps{T<:Number}(::Type{T}) = eps(real(T)) can be defined.

It looks like Operator is already parametrized by a T which appears to serve this purpose. Is that correct?

Yes but the subtypes don’t necessarily support arbitrary types.  E.g.
Derivative{Chebyshev} <: BandedOperator{Float64}
since the basis is real (this is actually a bug since the derivative is complex on complex intervals).  So we want
Derivative{Chebyshev,T} >: BandedOperator{T}
where T is chosen as part of the space promotion.    This would make life a little easier as operators would always be the same type, where now we mix BandedOperator{Float64} and BandedOperator{Complex{Float64}}.

On 16 Jan 2015, at 11:04 am, Gustavo Goretkin<EMAIL_ADDRESS>wrote:
It looks like Operator is already parametrized by a T which appears to serve this purpose. Is that correct?
—
Reply to this email directly or view it on GitHub https://github.com/ApproxFun/ApproxFun.jl/issues/122#issuecomment-70304358.

I started adding a type to FunctionSpace but I'm not sure its the right way forward.  There are some issues with typed typealias,  so that defining
typealias Chebyshev{T} Ultraspherical{0,T}
doesn't allow defining Chebyshev().  It also makes the code more complicated, since overrides are now of the form Fun{Chebyshev{T},T} instead of Fun{Chebyshev,T}.
Also, I can't think of an operation where the type of the function space needs to be known.  The only exception is domain/rangespace of Operators.  Maybe these should be a tuple with types?

The following now calculates exp(1) to 60 digits in 0.0025 seconds in fix-operatortype branch:
d=Interval{BigFloat}(0,1)
D=Derivative(d)
u=linsolve([ldirichlet(d),
Derivative(d)-I],[1];tolerance=10e-60)
u[1]-exp(big(1.0))

And now this works too :)
d=Interval{BigFloat}(-100,40)
x=Fun(identity,d)
D=Derivative(d)
@time u=linsolve([dirichlet(d),
D^2-x],[airyai(big(-100.0)),0];tolerance=10e-60)
u[0]-airyai(big(-0.0))

That's sensationally fast! I'm gathering timings from comparables in BigFloat. By linsolve, I'm finding 0.0038 seconds:
d=Interval{BigFloat}(0,1)
D=Derivative(d)
[ldirichlet(d),D-I]\[1];[ldirichlet(d),D-I]\[1];
@time for i=1:100
    [ldirichlet(d),D-I]\[1]
end

By the contructor, I'm finding 0.058 seconds:
d=Interval{BigFloat}(0,1)
Fun(exp,d);Fun(exp,d);
@time for i=1:100
    Fun(exp,d)
end

By the SincFun.jl package (a work-in-progress), I'm finding 0.04 seconds:
using SincFun
d=Finite(big(0.0),big(1.0))
sincfun(exp,d);sincfun(exp,d);
@time for i=1:100
    sincfun(exp,d)
end

By the timings supplied in http://arxiv.org/abs/1407.2802 at best 0.05 seconds for all examples in Table 2. These seem to be on par with the construction timings, so this might be due to using Maple instead of Julia.
Also, the construction seems to scale much worse with the number of digits. With 1,000 digits, I'm finding ~0.047 seconds for linsolve, ~16 seconds for ApproxFun construction and ~8 seconds for SincFun construction.
When we end up using fftw routines instead of the fftBigFloat and fftGeneric here, I believe we'll see an approximate 7-fold speedup (quoting timings from @goretkin), so I think resolution of Funs via linsolve will have its place for functions with a low bandrange.

I know this is really new, but could you explain what these lines in FunctionSpace.jl mean?
immutable RealBasis end
immutable ComplexBasis end
immutable AnyBasis end

coefficient_type{T<:Complex}(::Type{ComplexBasis},::Type{T})=T
coefficient_type{T<:Real}(::Type{ComplexBasis},::Type{T})=Complex{T}
coefficient_type{T}(::Type{RealBasis},::Type{T})=T

Base.eltype(::RealBasis)=Float64
Base.eltype(::ComplexBasis)=Complex{Float64}
Base.eltype(::AnyBasis)=Number

Base.eltype(::Type{RealBasis})=Float64
Base.eltype(::Type{ComplexBasis})=Complex{Float64}
Base.eltype(::Type{AnyBasis})=Number

I Added comments to the file.  I’ve been bad about commenting code so please file issues about any parts that are confusing.

"enum" types used for whether the basis is
Real or Complex.  AnyBasis is used when the answer
is unknown.

immutable RealBasis end
immutable ComplexBasis end
immutable AnyBasis end
coefficient_type(basis,valuetype) gives the type for coefficients
for basis of type RealBasis/ComplexBasis and valuetype
giving the type of function values
coefficient_type{T<:Complex}(::Type{ComplexBasis},::Type{T})=T
coefficient_type{T<:Real}(::Type{ComplexBasis},::Type{T})=Complex{T}
coefficient_type{T}(::Type{RealBasis},::Type{T})=T

eltype for RealBasis/ComplexBasis gives the
default type.  Maybe should be defaulteltype?

Base.eltype(::RealBasis)=Float64
Base.eltype(::ComplexBasis)=Complex{Float64}
Base.eltype(::AnyBasis)=Number
Base.eltype(::Type{RealBasis})=Float64
Base.eltype(::Type{ComplexBasis})=Complex{Float64}
Base.eltype(::Type{AnyBasis})=Number

On 21 Jan 2015, at 1:22 pm, Richard Mikael Slevinsky<EMAIL_ADDRESS>wrote:
I know this is really new, but could you explain what these lines in FunctionSpace.jl mean?
immutable RealBasis end
immutable ComplexBasis end
immutable AnyBasis end
coefficient_type{T<:Complex}(::Type{ComplexBasis},::Type{T})=T
coefficient_type{T<:Real}(::Type{ComplexBasis},::Type{T})=Complex{T}
coefficient_type{T}(::Type{RealBasis},::Type{T})=T
Base.eltype(::RealBasis)=Float64
Base.eltype(::ComplexBasis)=Complex{Float64}
Base.eltype(::AnyBasis)=Number
Base.eltype(::Type{RealBasis})=Float64
Base.eltype(::Type{ComplexBasis})=Complex{Float64}
Base.eltype(::Type{AnyBasis})=Number
—
Reply to this email directly or view it on GitHub https://github.com/ApproxFun/ApproxFun.jl/issues/122#issuecomment-70903181.

With the FFT sped up, by the contructor I'm finding 0.01 seconds now:
d=Interval{BigFloat}(0,1)
Fun(exp,d);Fun(exp,d);
@time for i=1:100
    Fun(exp,d)
end


Improve API documentation for ical feed

I was able to find the {rank} param by looking at the openapi spec, and the code, but it's not documented on the site. This PR provides an example of some documentation.

Thank you for the commitment!


Documentation: create your first nn missing imports and dependencies, hard to follow

took me some time to figure out the needed libs and imports for getting the example to run - the example should mention this clearly:
https://github.com/Kotlin/kotlindl/blob/master/docs/create_your_first_nn.md
Getting TensorFlow to run from Kotlin on MacOS X ARM64 is another story... seems the only way is to compile it yourself:(

ah sorry this is actually mentioned in the setup already:
https://github.com/Kotlin/kotlindl#how-to-configure-kotlindl-in-your-project
don't know why I missed that, maybe add a back-reference in the guide still?

Great idea @grexe will improve during this release cycle

Complete rookie here
I just spent couple of hours trying to figure out the tutorial. Following code works only with org.jetbrains.kotlinx:kotlin-deeplearning-api:0.4.0 dependency or below.  And in stable version (currently 0.5.2) Sequential model is absent. Or I'm missing out how to reach it.
 val model = Sequential.of(
    Input(28,28,1),
    Flatten(),
    Dense(300),
    Dense(100),
    Dense(10)
)

Anyway, I'm just following steps of  quick_start_guide.md


Point cloud ring channel not availiable

Hello and thanks for your code.
I've been trying to run your code on the kitti rosbag (but not one in your google drive). So, I've created rosbag using kitti2bag and tried to play it using command
rosbag play --clock kitti_2011_09_29_drive_0071_synced.bag -r 3 /kitti/oxts/gps/fix:=/gps/fix /kitti/oxts/gps/vel:=/gps/vel /kitti/oxts/imu:=/imu_correct /kitti/oxts/imu:=/imu_raw /kitti/velo/pointcloud:=/points_raw

Unfortunately, I'm getting this [ERROR] [1643712018.057128984]: Point cloud ring channel not available, please configure your point cloud data! in the terminal, where i've launched lio_sam. I guess there should be some sort of pre-processing for the kitti data or maybe post-processing for the rosbag to add this channel. But where to find this pre/postprocessing?
Thanks in advance.

add this channel.

Hello，have you solved the problem?

add this channel.

Hello，have you solved the problem?

Hello, no.

Hello, I have the same problem.

Hello, I have the same problem.

hello,目前我找到的有人解决的方案。固态激光雷达尚未经过 LIO-SAM 的广泛测试。这里也使用外部 IMU，而不是内部 IMU。对此类激光雷达的支持基于对机械激光雷达代码库的最小更改。需要使用定制的 livox_ros_driver 来发布 LIO-SAM 可以处理的点云格式。https://blog.csdn.net/BIT_HXZ/article/details/127210765

Hello, I have the same problem.

hello,目前我找到的有人解决的方案。固态激光雷达尚未经过 LIO-SAM 的广泛测试。这里也使用外部 IMU，而不是内部 IMU。对此类激光雷达的支持基于对机械激光雷达代码库的最小更改。需要使用定制的 livox_ros_driver 来发布 LIO-SAM 可以处理的点云格式。https://blog.csdn.net/BIT_HXZ/article/details/127210765

谢谢！！

I solved this problem.

How did you solve this problem @ESXNSI

I solved this problem.

@ESXNSI Hello, can you please tell us how did you solve it and what was the issue? I'm working on setting up the IsaacSim as an input for the LIO-SAM. I'm posting the ouster 128, 1024 10Hz 3d lidar output in the /os_cloud_node/points topic. It's not a solid-state lidar, so I don't see any reason why would I use the custom livox_ros_driver for that?

Hi,I encounter the same error with ubuntu 24 noble and ros2 jazzy.
I went to the problem statement code line
and changed it to:

if (ringFlag == -1)
{
if (sensor == SensorType::VELODYNE) {
ringFlag = 2;
} else {
RCLCPP_ERROR(get_logger(), "Point cloud ring channel not available, please configure your point cloud data!");
rclcpp::shutdown();
}
}

Building and running again  worked for me.
Hope it helps someone else too.


Live reload for the cordova base app

Issue: Working on the application and seeing changes takes up a bit of time, since let say we make a small change, we need to rebuild the entire app and run it again, there is no functionality where the code gets automatically pushed.
Current solutions found on a 5 minute search on google:
https://www.npmjs.com/package/cordova-plugin-browsersync
https://github.com/nordnet/cordova-hot-code-push
https://github.com/nordnet/cordova-hot-code-push/wiki/Local-Development-Plugin

For me, there is no reason to implement this. I don't have a lot of stuff to debug in Cordova.

Well, it can be a good idea for future implementations, since there might be cases where we need to constantly work with a device or an emulator.
The base-app main target are mobile phones, if you're debugging solely on the browser to me its a little bit as giving the driver seat to a blind person and telling him where to drive. Yes the people might arrive at the destination, but who knows what factors might there be to impede the arrival.
Anyway, just a suggestion. I can still work as it is, just takes a lot of time to build and check even for the smallest thing.


"timeout waiting for the application to start" -- but the app starts afterwards

Steps to Reproduce
The following may be dependent on the dev machine, but I have no way to test. The following happens on my MacBook Pro (Retina, 15-inch, Mid 2014).

Open Android Studio (v3.2.1, with Flutter plugin 29.1.1 and Dart plugin 181.5656).
Create new Flutter app
Open iOS Simulator.
Debug/Run the app in the Simulator

The debug log shows the following:

Note that the "timeout waiting for the application to start" is red. It stays there for at least a few seconds (probably tens of seconds) before the build finishes, and the next line is printed out.
After that, everything works just fine.
I'm filing this mostly because I've seen this happen to newcomers during codelabs, and they (understandably) assume that the build failed and they should just stop it.
Logs

Launching lib/main.dart on iPhone X in debug mode...
Running pod install...
Starting Xcode build...
timeout waiting for the application to start
Xcode build done.                                           127.6s
Syncing files to device iPhone X...
	[C1.1 E9C3A58A-EFF3-459E-A2C8-C1D461C3C624 <IP_ADDRESS>:54760<-><IP_ADDRESS>:443]
	Connected Path: satisfied (Path is satisfied), interface: en0
	Duration: 120.981s, DNS @0.003s took 0.018s, TCP @0.024s took 0.012s, TLS took 0.170s
	bytes in/out: 3306/1028, packets in/out: 9/9, rtt: 0.025s, retransmitted packets: 0, out-of-order packets: 0
	[C2.1 E0EF4920-9679-45B3-8EDE-B64A67A08769 <IP_ADDRESS>:54785<-><IP_ADDRESS>:443]
	Connected Path: satisfied (Path is satisfied), interface: en0
	Duration: 120.488s, DNS @0.000s took 0.001s, TCP @0.003s took 0.010s, TLS took 0.108s
	bytes in/out: 3876/1023, packets in/out: 10/9, rtt: 0.022s, retransmitted packets: 1, out-of-order packets: 0
	[C3.1 9B325582-F53A-415B-8FAF-BBAFC43598B7 <IP_ADDRESS>:54786<-><IP_ADDRESS>:443]
	Connected Path: satisfied (Path is satisfied), interface: en0
	Duration: 121.090s, DNS @0.000s took 0.002s, TCP @0.004s took 0.015s, TLS took 0.121s
	bytes in/out: 3588/1165, packets in/out: 9/9, rtt: 0.026s, retransmitted packets: 0, out-of-order packets: 0
[...]

$ flutter analyze
Analyzing baby_names...
No issues found! (ran in 2.7s)

$ flutter doctor -v
[✓] Flutter (Channel beta, v0.9.4, on Mac OS X 10.13.6 17G65, locale en-US)
    • Flutter version 0.9.4 at /Users/filiph/dev/flutter
    • Framework revision f37c235c32 (5 weeks ago), 2018-09-25 17:45:40 -0400
    • Engine revision 74625aed32
    • Dart version 2.1.0-dev.5.0.flutter-a2eb050044

[✓] Android toolchain - develop for Android devices (Android SDK 28.0.3)
    • Android SDK at /Users/filiph/Library/Android/sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-28, build-tools 28.0.3
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1136-b06)
    • All Android licenses accepted.

[✓] iOS toolchain - develop for iOS devices (Xcode 10.0)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 10.0, Build version 10A255
    • ios-deploy 1.9.2
    • CocoaPods version 1.5.3

[✓] Android Studio (version 3.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 29.1.1
    • Dart plugin version 181.5656
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1136-b06)

[!] IntelliJ IDEA Community Edition (version 2018.1)
    • IntelliJ at /Applications/IntelliJ IDEA CE.app
    ✗ Flutter plugin not installed; this adds Flutter specific functionality.
    ✗ Dart plugin not installed; this adds Dart specific functionality.
    • For information about installing plugins, see
      https://flutter.io/intellij-setup/#installing-the-plugins

[✓] VS Code (version 1.28.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 2.19.0

[✓] Connected devices (1 available)
    • iPhone X • A4DBE660-4C39-4AEA-B258-7755F584BA6E • ios • iOS 12.0 (simulator)

! Doctor found issues in 1 category.

i too got the same please help

try flutter clean ,restart your device i made a new project flutter clean ran it and it magically worked

I think this may be the same as #22338. There's a timeout in the startup code which behaves badly (when the timeout is hit, it carries on as if the thing that timed out completed, but since it didn't, strange things can happen).
(@Hixie is working on removing timeouts on a branch, but I think it may be blocked - I think it may be worth removing this timeout on its own to resolve this? It was relatively recently in #21696)

Same here. Found a workaround:
flutter build ios --debug -v > build.log
And then run the app itself using Xcode.
It seems to me it's similar to issues with release as well.

I think this was fixed by #24336
Please reopen if you are still seeing this.


Linux kernel warns: 'mroute: pending queue full' -- pimd not responding?

Receiving the following log messages:
May 19 20:02:24 ip-192-168-16-66 kernel: mroute: pending queue full, dropping entries
May 19 20:02:24 ip-192-168-16-66 kernel: mroute: pending queue full, dropping entries
May 19 20:02:30 ip-192-168-16-66 kernel: net_ratelimit: 343 callbacks suppressed
May 19 20:02:30 ip-192-168-16-66 kernel: mroute: pending queue full, dropping entries
...
May 19 20:02:30 ip-192-168-16-66 kernel: mroute: pending queue full, dropping entries
May 19 20:02:36 ip-192-168-16-66 kernel: net_ratelimit: 118 callbacks suppressed
May 19 20:02:36 ip-192-168-16-66 kernel: mroute: pending queue full, dropping entries

Opened this issue to track the progress.

Hmm, those are kernel messages.  Looks like pimd for some reason does not respond to unknown (new) routes?  I've never seen this before, sorry!
Maybe this can happen if there's a lot (!) of traffic and pimd is busy with something else, or is SIGSTOP'ed?

@troglobit : or is SIGSTOP'ed?

Nope :smile:

@troglobit:  there's a lot (!) of traffic and

it is relative.

@troglobit: pimd is busy with something else

more likely
will keep poking around ...

In 3 seconds I received 2,565,451 bytes or 2.5 Mbytes (179918652 - 177353201) on weave interface:
[root@ip-192-168-16-66 ~]# date;cat /proc/net/ip_mr_vif
Thu May 21 13:46:32 UTC 2015
Interface      BytesIn  PktsIn  BytesOut PktsOut Flags Local    Remote
 2 weave      177353201  235203         0       0 00000 4201010A 00000000
 3 tun0              0       0         0       0 00000 0B00FE0A 4D00FE0A
 4 tun1              0       0         0       0 00000 0C00FE0A 6E00FE0A
 5 tun2              0       0         0       0 00000 0D00FE0A 3B00FE0A
 6 pimreg            0       0  177353201<PHONE_NUMBER>4 4201010A 00000000
[root@ip-192-168-16-66 ~]#
[root@ip-192-168-16-66 ~]#
[root@ip-192-168-16-66 ~]# date;cat /proc/net/ip_mr_vif
Thu May 21 13:46:35 UTC 2015
Interface      BytesIn  PktsIn  BytesOut PktsOut Flags Local    Remote
 2 weave      179918652  239526         0       0 00000 4201010A 00000000
 3 tun0              0       0         0       0 00000 0B00FE0A 4D00FE0A
 4 tun1              0       0         0       0 00000 0C00FE0A 6E00FE0A
 5 tun2              0       0         0       0 00000 0D00FE0A 3B00FE0A
 6 pimreg            0       0  179918652<PHONE_NUMBER>4 4201010A 00000000
[root@ip-192-168-16-66 ~]#

and still getting:
May 21 13:51:25 ip-192-168-16-66 kernel: mroute: pending queue full, dropping entries

The only conclusion I can draw from this is that you must be receiving a lot of unknown multicast on the weave interface.
The warning message is from when the kernel tries to notify pimd (or any other multicast routing daemon) of new potential multicast to route.  If pimd has a "remote request" for that group it will add it to the kernel multicast routing table.  However, I'm not sure what should happen if there are no known receivers for that group ... could be a bug, I actually don't know.

Looking at the code, route.c:process_cache_miss(), I noticed that we have a debug message for this particular mechanism!
Try starting the pimd daemon process with the --debug=cache command line option.  You should see lines like the following in the system logfile(s):
18:48:42.618 Cache miss, src <IP_ADDRESS>, dst <IP_ADDRESS>, iif 0

@troglobit : However, I'm not sure what should happen if there are no known receivers for that group

:+1:
that is what happening. The drawback of weave overlay network is that hosts receive unsolicited multicast.
I will enable --debug=cache and report back my findings.

Hmm, didn't know what weave was before ... isn't there something else, with better filtering, you could use altogether? Like GRE or VXLAN?

@troglobit: isn't there something else, with better filtering, you could use altogether? Like GRE or VXLAN?

I tend to agree with you. However, we are entering the era of docker containers. Therefore, a lot of people are trying to create a overlay network for docker environments.
After enabling --debug=cache I can now see the misses:
May 21 20:17:55 ip-192-168-16-66 pimd[25981]: 20:17:55.940 Cache miss, src <IP_ADDRESS>, dst <IP_ADDRESS>, iif 2
May 21 20:17:55 ip-192-168-16-66 pimd[25981]: 20:17:55.940 create group entry, group <IP_ADDRESS>

weave acts like a peer in PIM Dense mode.

@troglobit , I am reopening this to ask the following question:
Jun 04 18:16:52 ip-192-168-16-66 pimd[7399]: 18:16:52.642 Cache miss, src <IP_ADDRESS>, dst <IP_ADDRESS>, iif 7
Jun 04 18:16:21 ip-192-168-16-66 pimd[7399]: 18:16:21.120 Removed MFC entry src <IP_ADDRESS>, grp <IP_ADDRESS>
Jun 04 18:12:52 ip-192-168-16-66 pimd[7399]: 18:12:52.643 create group entry, group <IP_ADDRESS>

I have the above 3 entries in my logs. They are listed in reverse order.
First, MFC entry gets created. Then, 4 minutes later, it is removed. Finally, I see a "cache miss".
Does the "cache miss" mean that there is no entry in MFC?
If so, how can I extend the life of the entry in MFC cache?

The MFC entries disappear, because they are no multicast listeners detected. In my case it happened because a Windows node failed to respond with Membership Reports to General Membership query.
pimd created the entry after receiving initial, unsolicited Membership Report.


Why is lora training so slow?

Dear author @yunkchen
Thanks for your awesome work!
I tried to run the lora training using my data, but the speed is very slow --- ~40s/it.
Training details:
512x512 model
2 GPUs - batch size: 1 for each
Is there anything I missed? Please give some hints on this. Thanks!

I had trained lora of 768x768 model with 144 frames on A100, using bf16.
And the speed is ~10s/it, FYI.

thanks for the info!
ya. that's something I expect to see. but sadly. anyway I will check and update here on anything I will get.

I met the same problem too. I fine-tune the model with lora on V100 machines. Its speed is about 40s/it. When I don't use the lora, the speed is 26s/it.

thanks for the info!
ya. that's something I expect to see. but sadly. anyway I will check and update here on anything I will get.

do you find any solution to speed up the lora-training?

@gulucaptain Not yet. Did you use --enable_xformers_memory_efficient_attention?

My situation: 8 A100 80G, batchsize 1, 19.35s/it, I feel it very slow. Is that normal?
I use the default train.sh as
accelerate launch --mixed_precision='bf16' scripts/train.py
--pretrained_model_name_or_path=$MODEL_NAME
--train_data_dir=$DATASET_NAME
--train_data_meta=$DATASET_META_NAME
--config_path "config/easyanimate_video_slicevae_multi_text_encoder_v4.yaml"
--image_sample_size=512
--video_sample_size=512
--token_sample_size=512
--video_sample_stride=1
--video_sample_n_frames=144
--train_batch_size=1
--video_repeat=1
--gradient_accumulation_steps=1
--dataloader_num_workers=8
--num_train_epochs=100
--checkpointing_steps=500
--learning_rate=2e-05
--lr_scheduler="constant_with_warmup"
--lr_warmup_steps=100
--seed=42
--output_dir="output_dir/ft_0.1Mv"
--enable_xformers_memory_efficient_attention
--gradient_checkpointing
--mixed_precision="bf16"
--adam_weight_decay=3e-2
--adam_epsilon=1e-10
--vae_mini_batch=1
--max_grad_norm=0.05
--random_hw_adapt
--training_with_video_token_length
--motion_sub_loss
--not_sigma_loss
--random_frame_crop
--enable_bucket
--train_mode="inpaint"
--trainable_modules "."


Training speed issues.

Hi Autodesk Team!
Really fantastic model and representation for deep learning on CAD. This model really sheds light on new research.
However, when I was trying to retrain your model I found that the training script is slower than expectation. It seems that the network is just two simple CNNs with a simple GNN added. But it cost me ~1.2s to train one iteration on a single RTX 3090 with the default setting provided.
I mean nothing about the entire training time of UVNet but I just wonder why the combination of these simple networks could result in such a training time. As I am quite a newbie in CAD deep learning and GNN, I really have no idea what's actually going on during the training steps.
Any idea helps. Many thanks.
Anderson Ma

Well it seems that the training speed in later times has become far faster than the beginning.

Interesting.  We have noticed a significant slowdown on an RTX card before. I don't have access to an RTX card right now to profile, but I believe @JoeLambourne had similar issues in the past. Any thoughts/ideas Joe?

In fact 1.2s/it happens at the first several epochs. The training speed later becomes ~20it/s.
Is it GNN's nature that the training speed at the beginning is slower than later?

I profiled the code and couldn't find anything in particular that might slow the code down. But my GPU is not an RTX card. Can you try running either the classification or the segmentation script with the --profile advanced --max_epochs 1 arguments and pass the profiler's output to me?

Closing for now. Please feel free to reopen if you get a chance to run the profiler.


[Docs] Fix minor typos at Rollbar::Scrubbers::Params

Summary
This patch simply fixes some minor typos I found while reading this class.

Thanks for the fixes!


Update testing docs for new vitest workspace syntax and merged coverage

Which project is this feature idea for?
Turborepo
Describe the feature you'd like to request
In 0.30.0 vitest has added first class support for monorepos.
https://twitter.com/vitest_dev/status/1645071039003590656
The syntax is documented here:
https://vitest.dev/guide/workspace.html
The current documentation doesn't reflect the new syntax.
Describe the solution you'd like
It would be great to update the documentation with best practices for how to define the workspace file, migrate to the new project config files, run tests and report shared coverage, etc.
Describe alternatives you've considered
None

This does seem like a useful example, we're open to contributions, but not sure when we'll be able to create one ourselves!

is there any hint or heads up on how can we consolidate vitest workspaces and turborepo? my current work around is to opt-out the test script from being running using turbo and run it using normal vitest command. this help me to get consolidated coverage.

I also would love to see some guidance. We are currently doing the same as @Nilegfx.
For Vitest workspace to work, one needs to define the vitest script in the root package.json.
I was able to run it from the root with turborepo like this:
// root package.json
"scripts": {
  // invoke vitest with configured workspace
  "vi:unit": "vitest run --coverage",
  // run said script with turborepo
  "test:unit:turbo": "turbo run vi:unit --filter=//",
}

// turbo.json
{
  "pipeline": {
    "//#vi:unit": {
      "dependsOn": [],
      "outputs": []
    },
  }
}

But this way, turborepo can't be used with its full potential. First run w/o cache hit -> all tests defined in vitest workspace run (2min on our side). Run command again -> full turbo. Change some test in a package and run task again -> all tests run again.
I would love to have only the tests re-run from the package the test was changed.
I think the only way to benefit from turbo repo here is to not use Vitest workspace feature and instead have a test script in each package that runs vitest itself. So, one could define a turbo script in the root package.json like this to run all scripts with same name across packages: "test:unit": "turbo run test:unit",.
Combined coverage is gone with this approach. Maybe each package can output its own coverage report and then manually stich them together eg. with istanbul-merge.

Do you have any updates on this? As @dsvgl mentioned, if we choose to use 'turbo' way, we can't make a combined coverage report. If we choose 'vitest native' solution (with vitest.workspace.json, Every test will run again.
In my project, I had to choose 'vitest' one since I needed combined coverage. Either way, turborepo should list both options or at least warn users of current drawbacks and workarounds.


Added commission_calc

For #216  This was my first time making an open source contribution and I may have made some mistakes and I'd be happy to correct them.

Great @ArshM17, your PR has been merged, to be eligible for swags, don't forget to like this repo✨. Have a nice day!


create a box "Report server" (like the" Preprint server" box in non RR PCI) in the submission form

 In PCI RR, for submission of Stage 2, create a box "Report server" (like the" Preprint server" box in non RR PCI) in the submission form

dropped in favour of PR#361


Feature/reduce build warnings

Fixes / New Feature #
#260
Proposed Changes
Fixes all build warnings except for...

The warnings relating to package analysis. These are because of limitations in the current dotnet core package production infrastructure - see https://github.com/NuGet/Home/issues/4587. Not sure what the status is for the fix of this. We could disable package analysis, but that might hide other problems, so suggest we leave it as is for now.

CS0618 (using obsolete code)

I've also enabled errors for some of the rules, which I forgot to do as part of #253. The rules I've chosen are a subset of the rules I use on my own projects. When I turned on errors for these rules it did not result in any errors in the code, so I'm taking that as proof that these rules are pretty unobtrusive and won't cause much hassle for devs unless they are really following bad practices.

@binarymash sorry took me ages to look at this, been super busy with the new job!

No worries, I'll take a look at this. Hope the new job is going ok, and you're not missing the Pig too much ;)

Ok, this is a bit trickier than the 2 minute job I thought it would be because you can't use await within a lock :)
I'm assuming there's a lock there to prevent concurrent access to the config file, so I looked at locking the file and accessing the filestream via File.Open(...). But, in doing this I see random test failures around accessing the config files. Pretty sure I've seen these failures before, so not sure if it's anything to do with my changes. However, this highlights that changing to use this approach rather than using the sync lock changes the behaviour slightly - we'll now get an exception on concurrent access. Do we ever expect this to happen at runtime? If so, what should we do?
And, what assumptions can we make about the lifetime of the config file? Will it always already exist before we try to write to it? I don't know the operation of Ocelot well enough to understand the exact behaviour here.
Might be worth splitting this into its own issue. What do you reckon?

@binarymash sorry that is about the 20th time I’ve forgotten about that lock. Feel free to merge!


Admin page API implementation 08/16/16

What all does this task entail? Is this account creation/management?


add file /lib/domains/edu/hoseo/vision.txt to add a domain

add file /lib/domains/edu/hoseo/vision.txt to add a domain

@sunghyuck vision.txt I am sorry, I have to close the request without merging, because you made a mistake in a request and did not specify any filepath. Please ensure that you are familiar with this repository rules located at the bottom of this page and make a new correct request. Thank you for your understanding!

@sunghyuck I corrected your request and merged it. Thank you.


[hive] Use new ReadBuilder and WriteBuilder API in tests of paimon-hive module

Use new ReadBuilder and WriteBuilder API in tests of paimon-hive module
sub-task of #639

Please also delete the commitUser class member of these two test classes.

Thank you for you reply, I will fix this problem later.

Thanks @TyrantLucifer for the contribution.
Can we make FileStoreTestUtils.createFileStoreTable returning Table?
And we can use Catalog to return Table too.

Thank you for your advice，I will change it later.

Thanks @TyrantLucifer for the contribution.
Can we make FileStoreTestUtils.createFileStoreTable returning Table? And we can use Catalog to return Table too.

Hi @JingsongLi , I have already finished this task, PTAL. :wink:


Create custom catalogs using this repo

Hi,
I want to create a custom catalogs with only few of the operators listed under operators dir. (Only 4 of them)
I am following a blog post (https://techbloc.net/archives/4372) which is mentions of building a new image from the Dockerfile present and then use the image created for my CatalogSource.
Followed the same steps however, my custom catalog pod is throwing the below error:
`Error: open /etc/nsswitch.conf: permission denied
Usage:
[flags]
Flags:
-d, --database string          relative path to sqlite db (default "bundles.db")
-h, --help                     help for this command
-p, --port string              port number to serve on (default "50051")
--skip-migrate             do  not attempt to migrate to the latest db revision when starting
-t, --termination-log string   path to a container termination log file (default "/dev/termination-log")
time="2022-11-23T06:23:46Z" level=panic msg="open /etc/nsswitch.conf: permission denied"
panic: (*logrus.Entry) (0x1132a20,0xc0001bbb20)
goroutine 1 [running]:
github.com/sirupsen/logrus.Entry.log(0xc0000ba000, 0xc0001ff800, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
/build/vendor/github.com/sirupsen/logrus/entry.go:239 +0x2db
github.com/sirupsen/logrus.(*Entry).Log(0xc0001bbab0, 0xc000000000, 0xc00014df40, 0x1, 0x1)
/build/vendor/github.com/sirupsen/logrus/entry.go:268 +0xeb
github.com/sirupsen/logrus.(*Logger).Log(0xc0000ba000, 0x0, 0xc00014df40, 0x1, 0x1)
/build/vendor/github.com/sirupsen/logrus/logger.go:192 +0x7d
github.com/sirupsen/logrus.(*Logger).Panic(...)
/build/vendor/github.com/sirupsen/logrus/logger.go:233
github.com/sirupsen/logrus.Panic(...)
/build/vendor/github.com/sirupsen/logrus/exported.go:129
main.main()
/build/cmd/registry-server/main.go:51 +0xbe`
Can someone please help me out here?

@rohasharma despite your question is out of our scope, I would suggest creating an index in file based catalog (FBC) format. Something like
opm migrate quay.io/operatorhubio/catalog:latest <output_dir> --output=yaml

delete unwanted operators from output_dir
opm generate dockerfile <config_path>

build it


❓ [Question] The stable diffusion example doesn't work

❓ Question

What you have already tried
https://github.com/pytorch/TensorRT/blob/main/examples/dynamo/torch_compile_stable_diffusion.py
I tried executing the above Python code, but conversion to TensorRT failed as shown below.
WARNING:torch_tensorrt.dynamo.backend.backends:TRT conversion failed on the subgraph. See trace above. Returning GraphModule forward instead.
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/dist-packages/torch_tensorrt/dynamo/backend/backends.py", line 93, in _pretraced_backend
    trt_compiled = compile_module(
  File "/usr/local/lib/python3.10/dist-packages/torch_tensorrt/dynamo/compile.py", line 244, in compile_module
    trt_module = convert_module(
  File "/usr/local/lib/python3.10/dist-packages/torch_tensorrt/dynamo/conversion/conversion.py", line 33, in convert_module
    module_outputs = module(*torch_inputs)
  File "/usr/local/lib/python3.10/dist-packages/torch/fx/graph_module.py", line 726, in call_wrapped
    return self._wrapped_call(self, *args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/torch/fx/graph_module.py", line 305, in __call__
    raise e
  File "/usr/local/lib/python3.10/dist-packages/torch/fx/graph_module.py", line 292, in __call__
    return super(self.cls, obj).__call__(*args, **kwargs)  # type: ignore[misc]
  File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1519, in _wrapped_call_impl
    return self._call_impl(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1528, in _call_impl
    return forward_call(*args, **kwargs)
  File "<eval_with_key>.14", line 6, in forward
    view_10 = torch.ops.aten.view.default(permute_10, [2, -1, 320]);  permute_10 = None
  File "/usr/local/lib/python3.10/dist-packages/torch/_ops.py", line 499, in __call__
    return self._op(*args, **kwargs or {})
  File "/usr/local/lib/python3.10/dist-packages/torch/utils/_stats.py", line 20, in wrapper
    return fn(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/torch/_subclasses/fake_tensor.py", line 1323, in __torch_dispatch__
    return self.dispatch(func, types, args, kwargs)
  File "/usr/local/lib/python3.10/dist-packages/torch/_subclasses/fake_tensor.py", line 1621, in dispatch
    r = func(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/torch/_ops.py", line 499, in __call__
    return self._op(*args, **kwargs or {})
RuntimeError: view size is not compatible with input tensor's size and stride (at least one dimension spans across two contiguous subspaces). Use .reshape(...) instead.

Is this an example python that actually passes? Or is there an environment version that needs to be set for this example?
Environment

Build information about Torch-TensorRT can be found by turning on debug messages

I used the latest version of the pytorch container, nvcr.io/nvidia/pytorch:23.11-py3, and pip installed the latest versions of diffusers and transformers.
Additional context
None

Hello - this issue was fixed in #2464, which likely did not make it into the 23.11 container. I believe the issue shows up in newer transformers/diffusers versions and may not appear with transformers==4.33.2, diffusers==0.21.4.
For the newest distribution of Torch-TRT which includes this fix, the main-branch Docker container (ghcr.io/pytorch/tensorrt/torch_tensorrt:main) or nightly
distribution (pip install --pre torch torch_tensorrt --extra-index-url https://download.pytorch.org/whl/nightly/cu121) can be used.

I have the same problem with the night distribution


Add "Common PEG Patterns" to documentation

We should add a documentation page that covers common PEG patterns that new users might not be familiar with. E.g.:

put keywords in their own rule, and use negative lookahead: class = "class" ~identifierPart
using left recursion to implement operator precedence
using negative lookahead to anything but a particular character (~"x" any)

etc.

I'd love to see an explanation in this page of the whys behind the patterns - for instance, that the negative lookahead is to avoid having to carefully order a prioritised choice to avoid prefixes appearing before longer strings (or to "maximally munch" tokens).

This is done now — see Patterns and Pitfalls.


Add mock to test dependencies

Unit testing uses the third party mock package, but it is not currently
declared in test-requirements.txt. Once py27 support is dropped, usage
could be switched from the third party mock package to the standard lib
unittest.mock. But until then, this explicitly declares the dependency
in the requirements.

Thanks @stmcginnis


Unlocked Mocha dependency, fixes #68

Mocha is now locked at 2.x which is equivalent to >= 2.0.0, < 3.0.0.

Build fails due to conflict in Bower's Ember version requirements:
Unable to find a suitable version for ember, please choose one:
    1) ember#^1.10.0 which resolved to 1.13.11 and is required by ember-mocha
    2) ember#>=1.4 <2 which resolved to 1.13.11 and is required by ember-cli-shims#0.0.3
    3) ember#>= 1.8.1 < 2.0.0 which resolved to 1.13.11 and is required by ember-data#1.0.0-beta.19.2
    4) ember#^2.2.0 which resolved to 2.2.0 and is required by ember-test-helpers#0.5.19

We no longer consume ember-test-helpers from Bower, so that conflict should be resolved.


[Feature]: JSON log serialization

What's your idea?
Before switching to this crate, I was using tracing-loki (which has its own whole host of issues which were originally the catalyst for me switching, but I digress). This crate output logs in a nicely formatted JSON manner, allowing me to filter logs incredibly easily using the JSON format. Sample output in the attached screenshot.

When I switched to this crate I noticed I lost all of that, and wrote up a patch on my fork that I'm currently using: https://github.com/tazz4843/fenrir-rs/tree/json-logs
Given that this is a major change, and requires configuration on the user's part that way they don't end up with garbage logs, I figured I would open an issue before making a PR to add this feature if you're interested. It could be locked behind a feature flag if that's something you'd be willing to add.
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Hey, sorry for the late reply. I wasn't sure about this feature and had to think about it a while to get my bearings. I'm still not completely sure about it but would appreciate a PR for this behind a feature flag (maybe experimental or incubator). I see why this feature would help you (and probably also others).

Sorry this took me so long to get back to. I'll try to make that PR sometime in the next day, shouldn't be too hard to move it behind a feature flag.


[FEATURE] Advancements

Advancements that would affect the progress in crafting Flint Tools and Copper Tools for now.

A few vanilla advancements have already been adjusted to the new progression so I see no point in this, except for the fact that I probanly should change the Stone Age requirement to have copper instead of stone so I'll change that at some point.

What was I thinking? The stone age advancement is just fine since you need stone to smelt copper :P

What was I thinking? The stone age advancement is just fine since you need stone to smelt copper :P


update links

updating links to repo and docs

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Thanks @martinfleis @ocefpaf !


Multiple dex files or ClassNotFound errors while building

Error while building: 'Multiple dex files define Lorg/eclipse/egit/github/core/Application'
Tried unchecking all permutations of Android 4.1, Android Private Libraries and Android dependencies from the Order and Export section in Project Properties for the project and the library projects it depends on. I am able to get it to build when I uncheck the Android Private Libraries item in my main project, but then I get a ClassNotFound error while starting the main activity.
Only the main project requires org.eclipse.egit.github.core-2.1.2.jar file, so I don't see how I could get a conflict there. The only other common dependency is android-supportv4, but I fixed the Order and Export section appropriately for that, and the error message does not mention it anyway.

This error is occurring when importing to Eclipse, not Android Studio. Am I right in believing we are specifically supporting Android Studio w/ Gradle now, @fadils?

Please use Android Studio.


netopeer2-server dont open port in openwrt

Hello,
I am using your netopeer2 2.1.16 with the following libraries:
libyang 2.1.80
sysrepo 2.1.42
libnetconf2 2.1.7
on openwrt master branch.
I have the problem that netopeer is not initialized completely.
I have managed to manually configure that netopeer2-server starts but the port is not open.
Could you possibly give me some advice on how to get the port open.
A test of netopeer 2.1.16 repo on Ubuntu 22.04 was successful and the port is also open there. It is not yet clear to me what the difference is between the configuration of Openwrt and Ubuntu.
thanks
Andre Menzel
Startlog netopeer2-server:
root@OpenWrt:/# netopeer2-server -v3 -d
[INF]: LY: Searching for "ietf-inet-types" in "/etc/sysrepo/yang".
[INF]: LY: Newer revision than "ietf-inet-types@2013-07-15" not found, using this as the latest revision.
[INF]: LY: Searching for "ietf-yang-types" in "/etc/sysrepo/yang".
[INF]: LY: Newer revision than "ietf-yang-types@2013-07-15" not found, using this as the latest revision.
[INF]: LY: Searching for "ietf-inet-types" in "/etc/sysrepo/yang".
[INF]: LY: Newer revision than "ietf-inet-types@2013-07-15" not found, using this as the latest revision.
[INF]: LY: Searching for "ietf-yang-types" in "/etc/sysrepo/yang".
[INF]: LY: Newer revision than "ietf-yang-types@2013-07-15" not found, using this as the latest revision.
[INF]: LY: Searching for "ietf-datastores" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-yang-library" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "sysrepo-monitoring" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Implemented module "ietf-datastores@2018-02-14" is not used for import, revision "2018-02-14" is imported instead.
[INF]: LY: Searching for "sysrepo-plugind" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-netconf-acm" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-netconf" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-yang-metadata" in "/etc/sysrepo/yang".
[INF]: LY: Newer revision than "ietf-yang-metadata@2016-08-05" not found, using this as the latest revision.
[INF]: LY: Searching for "ietf-netconf-with-defaults" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-netconf-notifications" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Implemented module "ietf-netconf@2013-09-29" is not used for import, revision "2013-09-29" is imported instead.
[INF]: LY: Searching for "ietf-origin" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-netconf-monitoring" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "notifications" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "nc-notifications" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-tcp-common" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-tcp-client" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-tcp-server" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Implemented module "ietf-tcp-common@2019-07-02" is not used for import, revision "2019-07-02" is imported instead.
[INF]: LY: Searching for "ietf-crypto-types" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Implemented module "ietf-netconf-acm@2018-02-14" is not used for import, revision "2018-02-14" is imported instead.
[INF]: LY: Searching for "ietf-keystore" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Implemented module "ietf-netconf-acm@2018-02-14" is not used for import, revision "2018-02-14" is imported instead.
[INF]: LY: Searching for "iana-crypt-hash" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-ssh-common" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-x509-cert-to-name" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-tls-common" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-truststore" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Implemented module "ietf-netconf-acm@2018-02-14" is not used for import, revision "2018-02-14" is imported instead.
[INF]: LY: Implemented module "ietf-crypto-types@2019-07-02" is not used for import, revision "2019-07-02" is imported instead.
[INF]: LY: Searching for "ietf-tls-server" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Implemented module "ietf-netconf-acm@2018-02-14" is not used for import, revision "2018-02-14" is imported instead.
[INF]: LY: Searching for "ietf-netconf-nmda" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Implemented module "ietf-datastores@2018-02-14" is not used for import, revision "2018-02-14" is imported instead.
[INF]: LY: Implemented module "ietf-netconf@2013-09-29" is not used for import, revision "2013-09-29" is imported instead.
[INF]: LY: Searching for "ietf-interfaces" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-ip" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-network-instance" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Implemented module "ietf-interfaces@2018-02-20" is not used for import, revision "2018-02-20" is imported instead.
[INF]: LY: Searching for "ietf-ssh-server" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Implemented module "ietf-keystore@2019-07-02" is not used for import, revision "2019-07-02" is imported instead.
[INF]: LY: Implemented module "ietf-netconf-acm@2018-02-14" is not used for import, revision "2018-02-14" is imported instead.
[INF]: LY: Searching for "ietf-netconf-server" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-restconf" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-subscribed-notifications" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Implemented module "ietf-interfaces@2018-02-20" is not used for import, revision "2018-02-20" is imported instead.
[INF]: LY: Implemented module "ietf-netconf-acm@2018-02-14" is not used for import, revision "2018-02-14" is imported instead.
[INF]: LY: Searching for "ietf-yang-patch" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Implemented module "ietf-restconf@2017-01-26" is not used for import, revision "2017-01-26" is imported instead.
[INF]: LY: Searching for "ietf-yang-push" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Implemented module "ietf-datastores@2018-02-14" is not used for import, revision "2018-02-14" is imported instead.
[INF]: LY: Implemented module "ietf-restconf@2017-01-26" is not used for import, revision "2017-01-26" is imported instead.
[INF]: LY: The ordered-by statement is ignored in lists representing notification content (/ietf-yang-push:push-change-update/datastore-changes/{uses='ypatch:yang-patch'}/yang-patch/edit).
[INF]: LY: Use of anydata to define configuration data is not recommended. /ietf-yang-push:{grouping='datastore-criteria'}/{uses='selection-filter-objects'}/selection-filter/within-subscription/{uses='selection-filter-types'}/filter-spec/datastore-subtree-filter/datastorr
[INF]: LY: Use of anydata to define configuration data is not recommended. /ietf-yang-push:{grouping='selection-filter-types'}/filter-spec/datastore-subtree-filter/datastore-subtree-filter
[INF]: LY: Use of anydata to define configuration data is not recommended. /ietf-yang-push:{grouping='selection-filter-objects'}/selection-filter/within-subscription/{uses='selection-filter-types'}/filter-spec/datastore-subtree-filter/datastore-subtree-filter
[INF]: LY: Use of anydata to define configuration data is not recommended. /ietf-yang-push:{augment='/sn:filters'}/ietf-yang-push:selection-filter/{uses='selection-filter-types'}/filter-spec/datastore-subtree-filter/datastore-subtree-filter
[INF]: LY: Use of anydata to define configuration data is not recommended. /ietf-subscribed-notifications:filters/stream-filter/{uses='stream-filter-elements'}/filter-spec/stream-subtree-filter/stream-subtree-filter
[INF]: LY: Use of anydata to define configuration data is not recommended. /ietf-yang-push:{augment='/sn:subscriptions/sn:subscription/sn:target'}/ietf-yang-push:datastore/{uses='datastore-criteria'}/{uses='selection-filter-objects'}/selection-filter/within-subscription/r
[INF]: LY: Use of anydata to define configuration data is not recommended. /ietf-subscribed-notifications:subscriptions/subscription/{uses='subscription-policy'}/{uses='subscription-policy-dynamic'}/{uses='subscription-policy-modifiable'}/target/stream/stream-filter/withr
[INF]: LY: Missing explicit "deprecated" status specified in parent "subnet", inheriting for "prefix-length".
[INF]: LY: Missing explicit "deprecated" status specified in parent "subnet", inheriting for "netmask".
[INF]: SR: Connection 116 created.
[INF]: SR: Session 82 (user "root", CID 116) created.
[INF]: SR: Triggering "ietf-subscribed-notifications" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-keystore" "done" event on enabled data.
[INF]: SR: Triggering "ietf-truststore" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-acm" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-acm" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-acm" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-acm" "done" event on enabled data.
root@OpenWrt:/etc/sysrepo# netstat -tuln
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 <IP_ADDRESS>:53          <IP_ADDRESS>:*               LISTEN
tcp        0      0 <IP_ADDRESS>:53            <IP_ADDRESS>:*               LISTEN
tcp        0      0 <IP_ADDRESS>:53          <IP_ADDRESS>:*               LISTEN
tcp        0      0 <IP_ADDRESS>:22              <IP_ADDRESS>:*               LISTEN
tcp        0      0 <IP_ADDRESS>:80              <IP_ADDRESS>:*               LISTEN
tcp        0      0 fe80::2e0:4cff:fe36:45f:53 :::*                    LISTEN
tcp        0      0 :::22                   :::*                    LISTEN
tcp        0      0 ::1:53                  :::*                    LISTEN
tcp        0      0 :::80                   :::*                    LISTEN
udp        0      0 <IP_ADDRESS>:161             <IP_ADDRESS>:*
udp        0      0 <IP_ADDRESS>:162             <IP_ADDRESS>:*
udp        0      0 <IP_ADDRESS>:53            <IP_ADDRESS>:*
udp        0      0 <IP_ADDRESS>:53          <IP_ADDRESS>:*
udp        0      0 <IP_ADDRESS>:53          <IP_ADDRESS>:*
udp        0      0 <IP_ADDRESS>:67              <IP_ADDRESS>:*
udp        0      0 :::161                  :::*
udp        0      0 ::1:514                 :::*
udp        0      0 ::1:53                  :::*
udp        0      0 fe80::2e0:4cff:fe36:45f:53 :::*

I do not know how exactly are you installing the server but since you are cross-compiling, not with # make install. Part of that command is executing scripts (in scripts directory), which set the default configuration. So you have to do that manually, on the target device. You can then check the configuration using sysrepocfg -X -m ietf-netconf-server.

Thanks, i have found it and it starts with open port.
I have another problem, when i try to connect with cli.
There is a parsing error for the private key.
Parsing private key ASN1 - ASN1 tag was of an unexpected value. See log below.
I try the generated config from merge_hostkey from openwrt in Ubuntu and there is no such error and it works there.
I have updated the libssl in openwrt to the latest version, but the problem is still there.
do you possibly have any advice, seems the problem is only openwrt related?
Thank you for your help!
Andre
root@OpenWrt:/etc/netopeer2/scripts# netopeer2-cli

connect
nc ERROR: Starting the SSH session failed (Socket error: Connection reset by peer).
cmd_connect: Connecting to the localhost:830 as user "root" failed.

root@OpenWrt:/# netopeer2-server -v3 -d
[INF]: LY: Searching for "ietf-inet-types" in "/etc/sysrepo/yang".
[INF]: LY: Newer revision than "ietf-inet-types@2013-07-15" not found, using this as the latest revision.
[INF]: LY: Searching for "ietf-yang-types" in "/etc/sysrepo/yang".
[INF]: LY: Newer revision than "ietf-yang-types@2013-07-15" not found, using this as the latest revision.
[INF]: LY: Searching for "ietf-inet-types" in "/etc/sysrepo/yang".
[INF]: LY: Newer revision than "ietf-inet-types@2013-07-15" not found, using this as the latest revision.
[INF]: LY: Searching for "ietf-yang-types" in "/etc/sysrepo/yang".
[INF]: LY: Newer revision than "ietf-yang-types@2013-07-15" not found, using this as the latest revision.
.
.
.
[INF]: LN: Listening on <IP_ADDRESS>:830 for SSH connections.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-keystore" "done" event on enabled data.
[INF]: SR: Triggering "ietf-truststore" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-acm" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-acm" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-acm" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-acm" "done" event on enabled data.
[INF]: LN: Accepted a connection on <IP_ADDRESS>:830 from <IP_ADDRESS>:44186.
[INF]: SR: Session 105 (user "root", CID 14) created.
[2024/08/15 09:26:30.481683, 1] pki_private_key_from_base64:  Parsing private key ASN1 - ASN1 tag was of an unexpected value
[ERR]: LN: Failed to set hostkey "genkey" (/tmp/PjBkJI).

Um, I don't really have any advice. You will have to get a valid key somehow.

Is the generated key valid? It is generated by the openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -outform PEM command and stored in the keystore (sysrepocfg -X -m ietf-keystore). If yes, then I am not sure where the problem is.

Yes, i have tested the config that come from merge_hostkey.sh on openwrt and is stored in TMPFILE.xml in Ubuntu.
In Ubuntu i have imported the xml config  with
sysrepocfg --edit=TMPFILE.xml -d startup -f xml -m ietf-keystore -v2
sudo sysrepocfg -C startup -m ietf-keystore -v2
and checked the key with
sudo sysrepocfg -X -x "/ietf-keystore:keystore"
Then i connect to the netopeer2-server.
There is no such Problem.
Its only openwrt related.
Maybe there is an other Problem with libssh or kernel in openwrt.

is due to mbedtls with openssl is working.
Thanks for your help ver much.
root@OpenWrt:/# netopeer2-server -v3 -d
[INF]: LY: Searching for "ietf-inet-types" in "/etc/sysrepo/yang".
[INF]: LY: Newer revision than "ietf-inet-types@2013-07-15" not found, using this as the latest revision.
[INF]: LY: Searching for "ietf-yang-types" in "/etc/sysrepo/yang".
[INF]: LY: Newer revision than "ietf-yang-types@2013-07-15" not found, using this as the latest revision.
[INF]: LY: Searching for "ietf-inet-types" in "/etc/sysrepo/yang".
[INF]: LY: Newer revision than "ietf-inet-types@2013-07-15" not found, using this as the latest revision.
[INF]: LY: Searching for "ietf-yang-types" in "/etc/sysrepo/yang".
[INF]: LY: Newer revision than "ietf-yang-types@2013-07-15" not found, using this as the latest revision.
[INF]: LY: Searching for "ietf-datastores" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-yang-library" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "sysrepo-monitoring" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Implemented module "ietf-datastores@2018-02-14" is not used for import, revision "2018-02-14" is imported instead.
[INF]: LY: Searching for "sysrepo-plugind" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-netconf-acm" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-netconf" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-yang-metadata" in "/etc/sysrepo/yang".
[INF]: LY: Newer revision than "ietf-yang-metadata@2016-08-05" not found, using this as the latest revision.
[INF]: LY: Searching for "ietf-netconf-with-defaults" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-netconf-notifications" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Implemented module "ietf-netconf@2013-09-29" is not used for import, revision "2013-09-29" is imported instead.
[INF]: LY: Searching for "ietf-origin" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-netconf-monitoring" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-netconf-nmda" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Implemented module "ietf-datastores@2018-02-14" is not used for import, revision "2018-02-14" is imported instead.
[INF]: LY: Implemented module "ietf-netconf@2013-09-29" is not used for import, revision "2013-09-29" is imported instead.
[INF]: LY: Searching for "notifications" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "nc-notifications" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-x509-cert-to-name" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-crypto-types" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Implemented module "ietf-netconf-acm@2018-02-14" is not used for import, revision "2018-02-14" is imported instead.
[INF]: LY: Searching for "ietf-keystore" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Implemented module "ietf-netconf-acm@2018-02-14" is not used for import, revision "2018-02-14" is imported instead.
[INF]: LY: Searching for "ietf-truststore" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Implemented module "ietf-netconf-acm@2018-02-14" is not used for import, revision "2018-02-14" is imported instead.
[INF]: LY: Implemented module "ietf-crypto-types@2019-07-02" is not used for import, revision "2019-07-02" is imported instead.
[INF]: LY: Searching for "ietf-tcp-common" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-ssh-common" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "iana-crypt-hash" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-ssh-server" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Implemented module "ietf-netconf-acm@2018-02-14" is not used for import, revision "2018-02-14" is imported instead.
[INF]: LY: Searching for "ietf-tls-common" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-tls-server" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Implemented module "ietf-keystore@2019-07-02" is not used for import, revision "2019-07-02" is imported instead.
[INF]: LY: Implemented module "ietf-netconf-acm@2018-02-14" is not used for import, revision "2018-02-14" is imported instead.
[INF]: LY: Searching for "ietf-tcp-client" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-tcp-server" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Implemented module "ietf-tcp-common@2019-07-02" is not used for import, revision "2019-07-02" is imported instead.
[INF]: LY: Searching for "ietf-netconf-server" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-interfaces" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-ip" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-network-instance" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Implemented module "ietf-interfaces@2018-02-20" is not used for import, revision "2018-02-20" is imported instead.
[INF]: LY: Searching for "ietf-restconf" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Searching for "ietf-subscribed-notifications" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Implemented module "ietf-interfaces@2018-02-20" is not used for import, revision "2018-02-20" is imported instead.
[INF]: LY: Implemented module "ietf-netconf-acm@2018-02-14" is not used for import, revision "2018-02-14" is imported instead.
[INF]: LY: Searching for "ietf-yang-patch" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Implemented module "ietf-restconf@2017-01-26" is not used for import, revision "2017-01-26" is imported instead.
[INF]: LY: Searching for "ietf-yang-push" in "/etc/sysrepo/yang".
[INF]: LY: Loading schema from<EMAIL_ADDRESS>file.
[INF]: LY: Implemented module "ietf-datastores@2018-02-14" is not used for import, revision "2018-02-14" is imported instead.
[INF]: LY: Implemented module "ietf-restconf@2017-01-26" is not used for import, revision "2017-01-26" is imported instead.
[INF]: LY: The ordered-by statement is ignored in lists representing notification content (/ietf-yang-push:push-change-update/datastore-changes/{uses='ypatch:yang-patch'}/yang-patch/edit).
[INF]: LY: Use of anydata to define configuration data is not recommended. /ietf-yang-push:{grouping='datastore-criteria'}/{uses='selection-filter-objects'}/selection-filter/within-subscription/{uses='selectionr
[INF]: LY: Use of anydata to define configuration data is not recommended. /ietf-yang-push:{grouping='selection-filter-types'}/filter-spec/datastore-subtree-filter/datastore-subtree-filter
[INF]: LY: Use of anydata to define configuration data is not recommended. /ietf-yang-push:{grouping='selection-filter-objects'}/selection-filter/within-subscription/{uses='selection-filter-types'}/filter-spec/r
[INF]: LY: Use of anydata to define configuration data is not recommended. /ietf-yang-push:{augment='/sn:filters'}/ietf-yang-push:selection-filter/{uses='selection-filter-types'}/filter-spec/datastore-subtree-fr
[INF]: LY: Use of anydata to define configuration data is not recommended. /ietf-subscribed-notifications:filters/stream-filter/{uses='stream-filter-elements'}/filter-spec/stream-subtree-filter/stream-subtree-fr
[INF]: LY: Use of anydata to define configuration data is not recommended. /ietf-yang-push:{augment='/sn:subscriptions/sn:subscription/sn:target'}/ietf-yang-push:datastore/{uses='datastore-criteria'}/{uses='selr
[INF]: LY: Use of anydata to define configuration data is not recommended. /ietf-subscribed-notifications:subscriptions/subscription/{uses='subscription-policy'}/{uses='subscription-policy-dynamic'}/{uses='subsr
[INF]: LY: Missing explicit "deprecated" status specified in parent "subnet", inheriting for "prefix-length".
[INF]: LY: Missing explicit "deprecated" status specified in parent "subnet", inheriting for "netmask".
[INF]: SR: Connection 174 created.
[INF]: SR: Session 17 (user "root", CID 174) created.
[INF]: SR: Triggering "ietf-subscribed-notifications" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: LN: Listening on <IP_ADDRESS>:830 for SSH connections.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-server" "done" event on enabled data.
[INF]: SR: Triggering "ietf-keystore" "done" event on enabled data.
[INF]: SR: Triggering "ietf-truststore" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-acm" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-acm" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-acm" "done" event on enabled data.
[INF]: SR: Triggering "ietf-netconf-acm" "done" event on enabled data.
[INF]: LN: Accepted a connection on <IP_ADDRESS>:830 from <IP_ADDRESS>:58506.
[INF]: SR: Session 47 (user "root", CID 174) created.
[INF]: LN: Received an SSH message "request-service" of subtype "ssh-userauth".
[INF]: LN: Received an SSH message "request-auth" of subtype "none".
[INF]: LN: Received an SSH message "request-auth" of subtype "interactive".
[INF]: LN: Received an SSH message "request-auth" of subtype "interactive".
[WRN]: LN: User authentication successful with an empty password!
[INF]: LN: User "root" authenticated.
[INF]: LN: Received an SSH message "request-channel-open" of subtype "session".
[INF]: LN: Received an SSH message "request-channel" of subtype "subsystem".
[INF]: SR: Session 48 (user "root", CID 174) created.
[INF]: SR: There are no subscribers for "ietf-netconf-notifications" notifications.
[INF]: NP: Generated new event (netconf-session-start).
[INF]: LN: Session 1: Schema "ietf-netconf@" was requested.
[INF]: NP: Session 1: thread 2 event new RPC.
[INF]: LN: Session 1: Schema "ietf-netconf-acm@2018-02-14" was requested.
[INF]: NP: Session 1: thread 1 event new RPC.
[INF]: LN: Session 1: Schema "ietf-yang-metadata@2016-08-05" was requested.
[INF]: NP: Session 1: thread 1 event new RPC.
[INF]: LN: Session 1: Schema "ietf-yang-library@2019-01-04" was requested.
[INF]: NP: Session 1: thread 1 event new RPC.
[INF]: LN: Session 1: Schema "ietf-datastores@" was requested.
[INF]: NP: Session 1: thread 2 event new RPC.
[INF]: LN: Session 1: Schema "ietf-netconf-nmda@" was requested.
[INF]: NP: Session 1: thread 2 event new RPC.
[INF]: LN: Session 1: Schema "ietf-origin@" was requested.
[INF]: NP: Session 1: thread 3 event new RPC.
[INF]: LN: Session 1: Schema "ietf-netconf-with-defaults@2011-06-01" was requested.
[INF]: NP: Session 1: thread 3 event new RPC.
[INF]: SR: Published event "rpc" "/ietf-netconf-nmda:get-data" with ID 1 priority 0 for 1 subscribers.
[INF]: SR: Processing "/ietf-netconf-nmda:get-data" "rpc" event with ID 1 priority 0 (remaining 1 subscribers).
[INF]: SR: Successful processing of "rpc" event with ID 1 priority 0 (remaining 0 subscribers).
[INF]: SR: Event "rpc" with ID 1 priority 0 succeeded.
[INF]: NP: Session 1: thread 3 event new RPC.
[INF]: LN: Session 1: Schema "sysrepo@2021-10-08" was requested.
[INF]: NP: Session 1: thread 2 event new RPC.
[INF]: LN: Session 1: Schema "sysrepo-monitoring@2021-07-29" was requested.
[INF]: NP: Session 1: thread 2 event new RPC.
[INF]: LN: Session 1: Schema "sysrepo-plugind@2022-03-10" was requested.
[INF]: NP: Session 1: thread 2 event new RPC.
[INF]: LN: Session 1: Schema "ietf-netconf-notifications@2012-02-06" was requested.
[INF]: NP: Session 1: thread 0 event new RPC.
[INF]: LN: Session 1: Schema "notifications@2008-07-14" was requested.
[INF]: NP: Session 1: thread 1 event new RPC.
[INF]: LN: Session 1: Schema "nc-notifications@2008-07-14" was requested.
[INF]: NP: Session 1: thread 1 event new RPC.
[INF]: LN: Session 1: Schema "ietf-x509-cert-to-name@2014-12-10" was requested.
[INF]: NP: Session 1: thread 1 event new RPC.
[INF]: LN: Session 1: Schema "ietf-crypto-types@2019-07-02" was requested.
[INF]: NP: Session 1: thread 3 event new RPC.
[INF]: LN: Session 1: Schema "ietf-keystore@2019-07-02" was requested.
[INF]: NP: Session 1: thread 0 event new RPC.
[INF]: LN: Session 1: Schema "ietf-truststore@2019-07-02" was requested.
[INF]: NP: Session 1: thread 1 event new RPC.
[INF]: LN: Session 1: Schema "ietf-tcp-common@2019-07-02" was requested.
[INF]: NP: Session 1: thread 3 event new RPC.
[INF]: LN: Session 1: Schema "ietf-ssh-common@2019-07-02" was requested.
[INF]: NP: Session 1: thread 3 event new RPC.
[INF]: LN: Session 1: Schema "iana-crypt-hash@2014-08-06" was requested.
[INF]: NP: Session 1: thread 4 event new RPC.
[INF]: LN: Session 1: Schema "ietf-ssh-server@2019-07-02" was requested.
[INF]: NP: Session 1: thread 0 event new RPC.
[INF]: LN: Session 1: Schema "ietf-tls-common@2019-07-02" was requested.
[INF]: NP: Session 1: thread 2 event new RPC.
[INF]: LN: Session 1: Schema "ietf-tls-server@2019-07-02" was requested.
[INF]: NP: Session 1: thread 2 event new RPC.
[INF]: LN: Session 1: Schema "ietf-tcp-client@2019-07-02" was requested.
[INF]: NP: Session 1: thread 4 event new RPC.
[INF]: LN: Session 1: Schema "ietf-tcp-server@2019-07-02" was requested.
[INF]: NP: Session 1: thread 0 event new RPC.
[INF]: LN: Session 1: Schema "ietf-netconf-server@2019-07-02" was requested.
[INF]: NP: Session 1: thread 0 event new RPC.
[INF]: LN: Session 1: Schema "ietf-interfaces@2018-02-20" was requested.
[INF]: NP: Session 1: thread 3 event new RPC.
[INF]: LN: Session 1: Schema "ietf-ip@2018-02-22" was requested.
[INF]: NP: Session 1: thread 4 event new RPC.
[INF]: LN: Session 1: Schema "ietf-network-instance@2019-01-21" was requested.
[INF]: NP: Session 1: thread 1 event new RPC.
[INF]: LN: Session 1: Schema "ietf-restconf@2017-01-26" was requested.
[INF]: NP: Session 1: thread 0 event new RPC.
[INF]: LN: Session 1: Schema "ietf-subscribed-notifications@2019-09-09" was requested.
[INF]: NP: Session 1: thread 0 event new RPC.
[INF]: LN: Session 1: Schema "ietf-yang-patch@2017-02-22" was requested.
[INF]: NP: Session 1: thread 2 event new RPC.
[INF]: LN: Session 1: Schema "ietf-yang-push@2019-09-09" was requested.
[INF]: NP: Session 1: thread 4 event new RPC.


Reduce unnecessary dependencies (#79)

This issue is quite blocking for me and make the project unusable as a dependency in my projects.
As an example it pulls the jacoco plugin as a dependency and makes the whole build fails. #79
WHat has been done:

Sonar & jacoco are plugins used to do the build/tests so no need to declare them as dependencies that will be also downloaded by end users
Logback is an implementation of Slf4j so IMO it's better to just have Slf4j included and the end user use the logging framework of his choice
Removed google API client as a java.net function already performs the same

Maintainers should be able to do edits if they wish to.

Hi @RakSrinaNa ,
Good point, i'll merge this PR now and add it into the next release !


suggestion about data-only containers

Hi,
Just a remark about your README.md. I've seen that you suggest to use a busybox image as data-only container. I suppose it is to save disk space, but actually you are wrong. as docker uses AUFS, if you use the same image as your app you actually save space. Maybe you could take a look at this blog post.
Thank you for your work, Bye.

The Docker OpenVPN image will continuously update indefinitely.  If I were to create a data volume container from today's docker-openvpn image create a new one tomorrow, ,y system would now need to hold at least two versions of the docker-openvpn image: the original one as the data volume has a refcount on it and current image running.  You would be right if you assumed images were never updated and cleaned-up; however this isn't the case in the long run.


problems in the doc and code

the problem in the code:
At present，the eventmesh-runtime package is missing in the master branch and the released version.
the problems in the doc:
1.QuickStart of the Eventmesh-runtime has an error : in the part of 1.4， "cd bin" should be changed to "cd conf"
2.The script of "runadmin.sh" in the QuickStart of eventmesh-sdk-java can not be found in the project
3.The dependency package is missing in the QuickStart of the eventmesh-sdk-java，when project use sdk to connect eventmesh
4.the doc on how to use the API is missing
5.the best practice in the doc is missing
6.the doc lacks a detailed description of the supported functions,which can be specific to the design scheme and implementation
7.the introduction of the items in the configuration files is missing from the doc

@sunxi92 Do you have any other questions?

@sunxi92 Do you have any other questions?

There are no other questions at the moment.

@sunxi92 Do you have any other questions?

There are no other questions at the moment.

ok, i will close it.


feat(STONEINTG-849): write all Integration-PLR-creation errors to snapshot annotation

This commit now ensures that all the errors that occur while Integration PLR creation, are logged into the Snapshot's status annotation.
Earlier only Invalid-type errors were logged, leaving behind other types of error from the annotation.
This made it difficult for users to understand what went wrong, because annotation was, in some cases, stuck on "Pending" status.

Maintainers will complete the following section

[ ] Commit messages are descriptive enough (hints)
[ ] Code coverage from testing does not decrease and new code is covered (check the PR coverage on codecov)
[ ] Controllers diagrams are updated when PR changes controllers code  (if applicable)

/retest

/retest

/retest

/retest

Codecov Report
Attention: Patch coverage is 25.00000% with 9 lines in your changes are missing coverage. Please review.

:exclamation: No coverage uploaded for pull request base (main@bf9f561). Click here to learn what that means.

Files
Patch %
Lines

internal/controller/snapshot/snapshot_adapter.go
25.00%
9 Missing :warning:

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #719   +/-   ##
=======================================
  Coverage        ?   72.28%
=======================================
  Files           ?       42
  Lines           ?     4008
  Branches        ?        0
=======================================
  Hits            ?     2897
  Misses          ?      811
  Partials        ?      300

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


Looking for a DLL

I'd like to use svgandme's logic as a DLL.
This DLL should just contain the SVGDocument, SVGDrawingContext classes and little else.
But I see that exporting a C++ class into a DLL is a portability nightmare, unless they are built like Blend2d, i.e. as I understand it, exported as C functions and then 'wrapped' into C++ classes at the 'import side'.
Could you tell me how to create this DLL?
One last question: how should the FontHandler thing work on Linux/Mac? Should a small set of font files be included in svgandme?

svgandme is "header only", meaning, all the code is in '.h' files, so no need for a .dll, or any other 'library' mechanism.  Just include 'svg.h' and you're done.  The one exception is the base64.cpp, which you also need to compile, but there's no reason that can't also just be a headed, so I'll change that.
FontHandler, yah, there's some challenges there when you just say "loadDefaultFonts", but you can specify a specific directory, and even a set of files to load.  'loadDefault...' should probably be some #ifdef code that does the platform specific right thing.

I have removed or shifted any items that would require a .dll.  The code should be pure 'header only' at this point.

closed as the code is header only at this point


Remove WWW from Grafana Hostname and Origin

:tada: This PR is included in version 2.0.0-next.25 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.3.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


SLIM-1148: Removes parameter daylightSavingsDeviation.

All is well.

This pull request makes the build fail.

All is well.


Add Gio interface

This adds the GIOUI interface to the application. Wallet syncer page has been implemented. It also  uses dcrlibwallet/master directly.
Fixes #441

I get this while running gio interface.
We are using masters branch of dcrlibwallet so we really dont need any use of the app package.

I get this UI while testing.
We are currently using a new mockup which fyne follows, you can use that as a reference as create/restore page and receive page has been implemented.
Please move to multi wallet feature of dcrlibwallet.


Compatible hezar with python 3.12

For now, hezar will installing until python 3.11.
Please compatible hezar with python 3.12

Hi @zaaferani, can you please paste the errors you get with the 3.12 build?

@arxyzan
└──╼  $ pip install hezar[all]
Collecting hezar[all]
  Using cached hezar-0.41.0-py3-none-any.whl.metadata (18 kB)
Collecting accelerate>=0.27.0 (from hezar[all])
  Using cached accelerate-1.0.1-py3-none-any.whl.metadata (19 kB)
Collecting datasets>=2.9.0 (from hezar[all])
  Downloading datasets-3.0.2-py3-none-any.whl.metadata (20 kB)
Collecting gensim==4.3.2 (from hezar[all])
  Using cached gensim-4.3.2.tar.gz (23.3 MB)
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
Collecting huggingface_hub>=0.12.0 (from hezar[all])
  Using cached huggingface_hub-0.26.1-py3-none-any.whl.metadata (13 kB)
Collecting jiwer>=3 (from hezar[all])
  Using cached jiwer-3.0.4-py3-none-any.whl.metadata (2.6 kB)
Collecting librosa>=0.10.0 (from hezar[all])
  Using cached librosa-0.10.2.post1-py3-none-any.whl.metadata (8.6 kB)
Collecting nltk>=3.8.0 (from hezar[all])
  Using cached nltk-3.9.1-py3-none-any.whl.metadata (2.9 kB)
Collecting numpy==1.24.* (from hezar[all])
  Using cached numpy-1.24.4.tar.gz (10.9 MB)
  Installing build dependencies ... done
  Getting requirements to build wheel ... error
  error: subprocess-exited-with-error

  × Getting requirements to build wheel did not run successfully.
  │ exit code: 1
  ╰─> [33 lines of output]
      Traceback (most recent call last):
        File "/home/hassan/Desktop/testing/llm/hezar/venv/lib/python3.12/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 353, in <module>
          main()
        File "/home/hassan/Desktop/testing/llm/hezar/venv/lib/python3.12/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 335, in main
          json_out['return_val'] = hook(**hook_input['kwargs'])
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "/home/hassan/Desktop/testing/llm/hezar/venv/lib/python3.12/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 112, in get_requires_for_build_wheel
          backend = _build_backend()
                    ^^^^^^^^^^^^^^^^
        File "/home/hassan/Desktop/testing/llm/hezar/venv/lib/python3.12/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 77, in _build_backend
          obj = import_module(mod_path)
                ^^^^^^^^^^^^^^^^^^^^^^^
        File "/usr/lib/python3.12/importlib/__init__.py", line 90, in import_module
          return _bootstrap._gcd_import(name[level:], package, level)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "<frozen importlib._bootstrap>", line 1387, in _gcd_import
        File "<frozen importlib._bootstrap>", line 1360, in _find_and_load
        File "<frozen importlib._bootstrap>", line 1310, in _find_and_load_unlocked
        File "<frozen importlib._bootstrap>", line 488, in _call_with_frames_removed
        File "<frozen importlib._bootstrap>", line 1387, in _gcd_import
        File "<frozen importlib._bootstrap>", line 1360, in _find_and_load
        File "<frozen importlib._bootstrap>", line 1331, in _find_and_load_unlocked
        File "<frozen importlib._bootstrap>", line 935, in _load_unlocked
        File "<frozen importlib._bootstrap_external>", line 995, in exec_module
        File "<frozen importlib._bootstrap>", line 488, in _call_with_frames_removed
        File "/tmp/pip-build-env-emqlpjp8/overlay/lib/python3.12/site-packages/setuptools/__init__.py", line 16, in <module>
          import setuptools.version
        File "/tmp/pip-build-env-emqlpjp8/overlay/lib/python3.12/site-packages/setuptools/version.py", line 1, in <module>
          import pkg_resources
        File "/tmp/pip-build-env-emqlpjp8/overlay/lib/python3.12/site-packages/pkg_resources/__init__.py", line 2172, in <module>
          register_finder(pkgutil.ImpImporter, find_on_path)
                          ^^^^^^^^^^^^^^^^^^^
      AttributeError: module 'pkgutil' has no attribute 'ImpImporter'. Did you mean: 'zipimporter'?
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error

× Getting requirements to build wheel did not run successfully.
│ exit code: 1
╰─> See above for output.

note: This error originates from a subprocess, and is likely not a problem with pip.

@arxyzan
└──╼  $ pip install hezar[all]
Collecting hezar[all]
  Using cached hezar-0.41.0-py3-none-any.whl.metadata (18 kB)
Collecting accelerate>=0.27.0 (from hezar[all])
  Using cached accelerate-1.0.1-py3-none-any.whl.metadata (19 kB)
Collecting datasets>=2.9.0 (from hezar[all])
  Downloading datasets-3.0.2-py3-none-any.whl.metadata (20 kB)
Collecting gensim==4.3.2 (from hezar[all])
  Using cached gensim-4.3.2.tar.gz (23.3 MB)
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
Collecting huggingface_hub>=0.12.0 (from hezar[all])
  Using cached huggingface_hub-0.26.1-py3-none-any.whl.metadata (13 kB)
Collecting jiwer>=3 (from hezar[all])
  Using cached jiwer-3.0.4-py3-none-any.whl.metadata (2.6 kB)
Collecting librosa>=0.10.0 (from hezar[all])
  Using cached librosa-0.10.2.post1-py3-none-any.whl.metadata (8.6 kB)
Collecting nltk>=3.8.0 (from hezar[all])
  Using cached nltk-3.9.1-py3-none-any.whl.metadata (2.9 kB)
Collecting numpy==1.24.* (from hezar[all])
  Using cached numpy-1.24.4.tar.gz (10.9 MB)
  Installing build dependencies ... done
  Getting requirements to build wheel ... error
  error: subprocess-exited-with-error

  × Getting requirements to build wheel did not run successfully.
  │ exit code: 1
  ╰─> [33 lines of output]
      Traceback (most recent call last):
        File "/home/hassan/Desktop/testing/llm/hezar/venv/lib/python3.12/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 353, in <module>
          main()
        File "/home/hassan/Desktop/testing/llm/hezar/venv/lib/python3.12/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 335, in main
          json_out['return_val'] = hook(**hook_input['kwargs'])
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "/home/hassan/Desktop/testing/llm/hezar/venv/lib/python3.12/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 112, in get_requires_for_build_wheel
          backend = _build_backend()
                    ^^^^^^^^^^^^^^^^
        File "/home/hassan/Desktop/testing/llm/hezar/venv/lib/python3.12/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 77, in _build_backend
          obj = import_module(mod_path)
                ^^^^^^^^^^^^^^^^^^^^^^^
        File "/usr/lib/python3.12/importlib/__init__.py", line 90, in import_module
          return _bootstrap._gcd_import(name[level:], package, level)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "<frozen importlib._bootstrap>", line 1387, in _gcd_import
        File "<frozen importlib._bootstrap>", line 1360, in _find_and_load
        File "<frozen importlib._bootstrap>", line 1310, in _find_and_load_unlocked
        File "<frozen importlib._bootstrap>", line 488, in _call_with_frames_removed
        File "<frozen importlib._bootstrap>", line 1387, in _gcd_import
        File "<frozen importlib._bootstrap>", line 1360, in _find_and_load
        File "<frozen importlib._bootstrap>", line 1331, in _find_and_load_unlocked
        File "<frozen importlib._bootstrap>", line 935, in _load_unlocked
        File "<frozen importlib._bootstrap_external>", line 995, in exec_module
        File "<frozen importlib._bootstrap>", line 488, in _call_with_frames_removed
        File "/tmp/pip-build-env-emqlpjp8/overlay/lib/python3.12/site-packages/setuptools/__init__.py", line 16, in <module>
          import setuptools.version
        File "/tmp/pip-build-env-emqlpjp8/overlay/lib/python3.12/site-packages/setuptools/version.py", line 1, in <module>
          import pkg_resources
        File "/tmp/pip-build-env-emqlpjp8/overlay/lib/python3.12/site-packages/pkg_resources/__init__.py", line 2172, in <module>
          register_finder(pkgutil.ImpImporter, find_on_path)
                          ^^^^^^^^^^^^^^^^^^^
      AttributeError: module 'pkgutil' has no attribute 'ImpImporter'. Did you mean: 'zipimporter'?
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error

× Getting requirements to build wheel did not run successfully.
│ exit code: 1
╰─> See above for output.

note: This error originates from a subprocess, and is likely not a problem with pip.

Hi bro, I have this problem
Did you fix this problem?

Hi @zaaferani , the problem lies within the numpy side. When you install the hezar[all] package, it installs numpy==1.24.* so that the embedding models work (due to a bug in Gensim), and numpy==1.24.* has no wheels for python 3.12 yet (maybe never!). I'm trying to work on a solution so that hezar works without that dependency.

Okay bro
thank you,
Is this repository working correctly with the specified Python version?

I want to use all features

@zaaferani Yes it does, you just have to make sure your python version is below 3.12 for now.

@zaaferani Yes it does, you just have to make sure your python version is below 3.12 for now.

Thanks for all answers.


Support checking if an IP address is in a CIDR block

Is your feature request related to a problem? Please describe.
There are use cases where the IP address associated with an event needs to be checked against some given CIDR blocks to determine the further processing actions for the event.
Describe the solution you'd like
Support a ip_in operator in an Data Prepper expression like this:
/source_ip ip_in {"<IP_ADDRESS>/24.", "<IP_ADDRESS>/16"}

to check if an IP address from the event on the left side matches any of the network blocks on the right side.
With the conditional support proposed in #2613, we can then use this expression in many common processors to process events based on the result of the IP check.
Describe alternatives you've considered (Optional)
Support a when option in existing processors (e.g. add_entries processors) to perform CIDR check:
processor:
  - add_entries:
      entries:
        - key: "valid_source"
          value: true
      when:
        cidr:
          address_key: "source_ip"
          network: ["<IP_ADDRESS>/24.", "<IP_ADDRESS>/16"]

This will add an entry {"valid_source": true} to the event if source_ip is within the range of the network blocks.
Additional context
Add any other context or screenshots about the feature request here.

@oeyh , I like this proposal.
You have proposed that we have an operator to support this. This would need to be part of the grammar.
We have a few issues which will make use of functions. The grammar wouldn't need to know about specific functions - just how to parse a function.
This might be more appropriate as a function rather than a general operator. In which case it would look like:
isIpInCidr(/source_ip, {"<IP_ADDRESS>/24.", "<IP_ADDRESS>/16"})


Read the default backend from the app environment

As done here: https://github.com/elixir-nx/nx/commit/31b7c924f1f8de35e96271bf0d6972a79fc5f937

Is this still up for grabs? The equivalent Nx commit looks pretty straightforward - any gotchas/additional considerations I should keep in mind if I gave this a go?

Definitely still up for grabs @tylerbarker! And I can't think of any gotchas or additional considerations, nope.

Sweet, thanks @cigrainger! I'll find some time over the weekend ✌


History manipulation throws error, stops page from loading

I'm getting an 'Uncaught DataCloneError: Failed to execute 'replaceState' on 'History': An object could not be cloned.', which will prevent Mirador from loading.
This happens in Firefox and Chrome, when loading the Mirador index.html from a freshly built mirador.  I'm using hosts-based redirection to access it at http://miradork.io, and serving it via nginx, but I don't think any of that is relevant, as Mirador loads up just fine if I comment out the replaceState stuff in mirador.js.

Argh, nevermind.  This looks to be happening due to the presence of functions in config - anything saved via history API has to be cleanly serializable.  Thus, this issue is a direct result of PR #452