Add support for non optional custom zod types

This looks okay to me, I'll have another look when I have time to properly suss it out.
But would z.coerce.date() be more appropriate in your scenario?

This looks okay to me, I'll have another look when I have time to properly suss it out.
But would z.coerce.date() be more appropriate in your scenario?

I'm using LocalDates from js-joda lib, just used Date as an example here.

Hmmm I'm not entirely sure I like the approach of treating a custom as non optional by default given it can potentially return anything. Including undefined which in JavaScript world is also optional

This solution won't do that because it's still calling zod's isOptional(), for example:
it('returns true for a custom undefined without a check', () => {
  const schema = z.custom<undefined>();
  const result = isOptionalSchema(schema, createOutputState());

  expect(result).toEqual({ optional: true });
});

it('returns true for a custom undefined with a check', () => {
  const schema = z.custom<undefined>((_: unknown) => false);
  const result = isOptionalSchema(schema, createOutputState());

  expect(result).toEqual({ optional: false });
});

For ex both of these will pass because zod will call the the safeParse.success when calling isOptional()

You could also return something | undefined though in a custom.

You could also return something | undefined though in a custom.

From my understanding (I may be wrong) the type you pass to the custom won't matter. If you don't provide a check the schema.isOptional() will return true for custom types. But if you provide a check it won't be.
For custom of string | undefined the following tests pass
  it('returns false for a custom string | undefined without a check', () => {
    const schema = z.custom<string | undefined>();
    const result = isOptionalSchema(schema, createOutputState());

    expect(result).toEqual({ optional: true });
  });

  it('returns false for a custom string | undefined with a check that returns false for undefined', () => {
    const schema = z.custom<string | undefined>(
      (toCheck: string | undefined) => toCheck !== undefined,
    );
    const result = isOptionalSchema(schema, createOutputState());

    expect(result).toEqual({ optional: false });
  });

  it('returns true for a custom string | undefined with a check that returns true for undefined', () => {
    const schema = z.custom<string | undefined>(
      (toCheck: string | undefined) => toCheck === undefined,
    );
    const result = isOptionalSchema(schema, createOutputState());

    expect(result).toEqual({ optional: true });
  });

Ah awesome. TIL: https://github.com/colinhacks/zod/blob/1f4f0dacf313a2dba45563d78171e6f016096925/src/types.ts#L515

Thank you for your work looking into this! I will take a final look tomorrow 🙂

Thanks for this, I might end up re-writing all of the optional checking logic though but I'll keep your test cases


License question

Could you please specify what license your app comes under?

Hey @IzzySoft thanks for prompting about licensing.
I have just added an MIT License to the project here
I have also included a scan of its dependency licenses here
The 2 licenses in use by dependencies are Apache 2.0 and MIT.

Thanks for your swift response and action! Great choice. This enabled me to add your app to my repo: it will show up here with the next sync around 7 pm UTC. Be welcome to pick a badge if you want to link there from your Readme :smiley:
Btw: looks like your app would be eligible for listing in F-Droids own repo, which has a bit stricter inclusion criteria than mine – but therefore also a higher reputation. F-Droid builds apps from their sources (other than my repo, which picks the APKs you provide). If you're interested in that let me know and I can help you with that.
Same if you wish to be in control of how your app is presented (description, screenshots etc) – I can send you what I've set up as PR in Fastlane format, so you can maintain that with your app here directly in your repo (my updater then would pick up changes along with APK updates). F-Droid would ask for that anyway :smile:

@IzzySoft thanks for the interest in my app and the inclusion in your repo.
I hadn't heard of Fastlane before but your link was very helpful. Feel free to open a PR for adding it and I'll take a look.
I may even incorporate Fastlane into my parser as it looks like a good fallback for finding the app icon.
One issue I noticed on the listing page is these are incorrect
    Target: 14.0
    MinVer: 11.0

should be
    Target: 33.0
    MinVer: 29.0

Feel free to open a PR for adding it and I'll take a look.

Will do!

One issue I noticed on the listing page is these are incorrect

No, you're misinterpreting it. Remember those details are intended for end-users, so the values are Android Versions and not sdkVer's. sdkVer 29 = Android 11. sdkVer 33 = Android 14.


Error loading in ROS Melodic

Hi,
I am trying to load the hospital world in gazebo, I can compile everything correctly.
But when I execute roslaunch view_hospital.launch, I have the following errors in the terminal and the world launches correctly but some models are missing.
Error Code 11 Msg: Unable to find uri[model://IVStand]
Error Code 11 Msg: Unable to find uri[model://BMWCart]
Error Code 11 Msg: Unable to find uri[model://Scrubs]
Error Code 11 Msg: Unable to find uri[model://BPCart]
Error Code 11 Msg: Unable to find uri[model://BPCart]
Error Code 11 Msg: Unable to find uri[model://BPCart]
Error Code 11 Msg: Unable to find uri[model://BPCart]
Error Code 11 Msg: Unable to find uri[model://VendingMachine]
Error Code 11 Msg: Unable to find uri[model://VendingMachine]
Error Code 11 Msg: Unable to find uri[model://Chair]
[Msg] Loading world file [/root/COBOTTA/catkin_ws/src/aws-robomaker-hospital-world/worlds/hospital.world]
[Wrn] [ColladaLoader.cc:1537] Unable to add material[]
[Wrn] [ColladaLoader.cc:1537] Unable to add material[]
[Wrn] [ColladaLoader.cc:1537] Unable to add material[]
[ INFO] [1622092038.499380288]: waitForService: Service [/gazebo/set_physics_properties] is now available.
[Wrn] [ColladaLoader.cc:1537] Unable to add material[]
[Wrn] [ColladaLoader.cc:1537] Unable to add material[]
[Wrn] [ColladaLoader.cc:1537] Unable to add material[]
[Wrn] [ColladaLoader.cc:1537] Unable to add material[]
[Wrn] [ColladaLoader.cc:1537] Unable to add material[]
[Wrn] [ColladaLoader.cc:1537] Unable to add material[]
[ INFO] [1622092038.508959044]: Physics dynamic reconfigure ready.
[Wrn] [ColladaLoader.cc:1537] Unable to add material[]
[Wrn] [ColladaLoader.cc:1537] Unable to add material[]
[Wrn] [ColladaLoader.cc:1537] Unable to add material[]
[Wrn] [ColladaLoader.cc:1537] Unable to add material[]
[Wrn] [ColladaLoader.cc:1537] Unable to add material[]
[Wrn] [Event.cc:61] Warning: Deleting a connection right after creation. Make sure to save the ConnectionPtr from a Connect call

I am using ROS Melodic and Gazebo 9.18, this is a image of the environment loaded https://imgur.com/a/shytdIr
Does anyone has any recommendation in how to solve this issue?
Thank you

Hi, can you please share what exact steps you ran to compile and build the world package?
The world definition depends on a few models from ignition and these models are downloaded here. My hunch is that some of the ignition models failed to download during colcon build and hence are not available to gazebo to load.
I would suggest that you try loading the world directly through Gazebo. You can follow these README instructions. If the issue is indeed with fetching/downloading the ignition models, this should also fail. Please let us know what error you see, if any.

Hi, thank you very much for your answer.
The steps that I followed were colcon build then catkin build for my other packages. After that I was launching the roslaunch view_hospital.launch.
I tried repeating the steps again, but now in colcon build I have this error message
Starting >>> aws_robomaker_hospital_world
--- stderr: aws_robomaker_hospital_world
CMake Error at cmake_install.cmake:56 (file):
  file INSTALL cannot find
  "/root/COBOTTA/catkin_ws/src/aws-robomaker-hospital-world/fuel_models".

make: *** [install] Error 1
---
Failed   <<< aws_robomaker_hospital_world [0.25s, exited with code 2]

Summary: 0 packages finished [0.34s]
  1 package failed: aws_robomaker_hospital_world
  1 package had stderr output: aws_robomaker_hospital_world

And following the steps for loading directly the world through Gazebo. I have the following error when I run the instruction ./setup.sh
Traceback (most recent call last):
  File "fuel_utility.py", line 15, in <module>
    import requests
ModuleNotFoundError: No module named 'requests'

I think I am missing some of the libraries required to run fuel_utility.py, I will install them manually and try again.
Thank you for your help.

Thank you for your answer.
The steps that I followed to compile and build the world were colcon build and then sourcing.
I followed the instructions to load the world directly through Gazebo. Initially I had errors when running setup.sh. The errors were of missing libraries such as requests,docopt and lxml. I installed manually those libraries and ran again setup.sh and everything worked and I could launch the gazebo with the world.
I think that the error was related to my installation of Python3 and Colcon.
Thank you for your help.


Added Any Resources

What does this PR do?
Add resource(s)
For resources
Description
I added new links in cheat sheet and free online programming courses in Indonesian, you can check it out in free-courses-id.md and free-programming-cheatsheets.md
Why is this valuable (or not)?
In cheat sheets, I've added HTML & CSS Emmet function which is very useful for web development, SQL for data analysis and also added Visual Studio Code cheat sheet shortcuts for faster if you code. And in Indonesian free programming courses I've added "Belajar Laravel 8" which is Laravel tutorial for web development
How do we know it's really free?
From YouTube channel, it is really open for all users so if you are not of the member from his channel, you can access it. Also, from the link of the websites, you can access and download the pdf, it's free for all users
For book lists, is it a book? For course lists, is it a course? etc.
In free online programming courses in Indonesian, it's a YouTube playlist which is talks about Laravel 8. And from the website, Those are the PDF file documentation about HTML & CSS Emmet function cheat sheet, SQL cheat sheet, and VSCode shortcuts
Checklist:

[x] Read our contributing guidelines
[x] Search for duplicates.
[x] Include author(s) and platform where appropriate.
[x] Put lists in alphabetical order, correct spacing.
[x] Add needed indications (PDF, access notes, under construction)

Follow-up

Check the status of GitHub Actions and resolve any reported warnings!

TIP :rocket:: Thanks for taking your time on fill Pull Request fields in your first contribution :heart:
It's always a good practice which it use to increase the mantainers productivity.

Thanks, and welcome to free-programming-books!


Implement "tiered percentage" value. Fixes #1170

Signed-off-by: David A. Wheeler<EMAIL_ADDRESS>

This is much clearer and a big improvement. +1


Pre-trained model of A2MIM

Hi, when will the pre-trained model of A2MIM be released in the webpage?
The work is so meaningful！
Thank you!

Hi, @zugofn. Thanks for your appreciation of A2MIM. Since A2MIM is under review, we plan to release the pre-trained model in late September or later. We will inform you when we update the release. Thanks again for your attention and patience!

Hi, @zugofn. Thanks for your appreciation of A2MIM. Since A2MIM is under review, we plan to release the pre-trained model in late September or later. We will inform you when we update the release. Thanks again for your attention and patience!

Thanks for your quick reply！
Have a nice day😊

Hi, @zugofn. Thanks for your appreciation of A2MIM. Since A2MIM is under review, we plan to release the pre-trained model in late September or later. We will inform you when we update the release. Thanks again for your attention and patience!

Is it ok to release the model parameters now?  I would like to do research based on this paper.

Hi, @zugofn. Thanks for your appreciation of A2MIM. Since A2MIM is under review, we plan to release the pre-trained model in late September or later. We will inform you when we update the release. Thanks again for your attention and patience!

Is it ok to release the model parameters now? I would like to do research based on this paper.

Hi, @donggoing. Thanks for your attention. Unfortunately, the pre-trained models cannot be released now because we are working on the revision and resubmission of A2MIM. We are sorry about the late release and we plan to upload the pre-trained models after the deadline for ICLR2023 submission.
Meanwhile, feel free to contact me if you have some questions about A2MIM. We can also discuss the relevant questions encountered in your research.

Hi, @zugofn. Thanks for your appreciation of A2MIM. Since A2MIM is under review, we plan to release the pre-trained model in late September or later. We will inform you when we update the release. Thanks again for your attention and patience!

Is it ok to release the model parameters now? I would like to do research based on this paper.

Hi, @donggoing. Thanks for your attention. Unfortunately, the pre-trained models cannot be released now because we are working on the revision and resubmission of A2MIM. We are sorry about the late release and we plan to upload the pre-trained models after the deadline for ICLR2023 submission.
Meanwhile, feel free to contact me if you have some questions about A2MIM. We can also discuss the relevant questions encountered in your research.

Thanks for your quick reply! ”after the deadline for ICLR2023 submission“ you mean like after Sep 28?
And i would like to know how do you think about what brings the gap between Tr（A2MIM） and CNN（A2MIM）?

Yes, @donggoing, it might be uploaded in early October. As for your question, A2MIM works for Transformer and CNN, and there is no difference in its algorithm for both two architectures. When Transformer and CNN adopt A2MIM using the same pre-training epochs, the performance gap might come from two aspects:
(1) Transformer architectures are more suitable for MIM pre-training than CNNs. I have pre-trained A2MIM for longer epochs based on both architectures, ViT-B obtains slight performance gains (800 epochs vs. 1200 epochs), while ResNet-50 suffers from performance degeneration (300 epochs vs. 600 epochs). From my perspective, CNNs have more substantial inductive bias than Transformers but have fewer degrees of freedom. MIM empowerer Transformers with the relevant inductive bias, which helps Transformers to achieve better fine-tuning performances.
(2) The design gap of architecture between ResNet-50 and ViT might cause the sub-optimal performances of CNNs. As you know, ViT belongs to MetaFormer architectures, which is more powerful than ResNet (the vanilla bottleneck module). In A2MIM, we only verify ResNet-50 and ViT architectures. If you adopt advanced ConvNet architectures (e.g., ConvNeXt), you might find Transformers and CNNs yield similar pre-training performances.

@Lupin1998 I got another question, how do a2mim mask exactly? does it mask the original img? I don't know how the openmixup's pipeline works, so when does 'BlockwiseMaskGenerator' is applied, which confued me.

Waiting for pre-trained weights.

Hi guys, thanks for your attention and patience. we have uploaded the release of weights, logs, visualizations of A2MIM and relevant self-supervised methods in a2mim-in1k-weights. We are sorry for the delay and hope you will find it useful. Feel free to ask me if you have further questions.

@Lupin1998 Thanks for your work. I tried to find the self-supervised pre-training weight of a2mim without finetune. Does full_a2mim_r50_l3_sz224_init_8xb256_cos_ep100 stand for that?

@Lupin1998 Thanks for your work. I tried to find the self-supervised pre-training weight of a2mim without finetune. Does full_a2mim_r50_l3_sz224_init_8xb256_cos_ep100 stand for that?

Yes, weights starting with full contain the full weights of pre-training models, while those with backbone are the backbone-only weights (can be used for downstream tasks in PyTorch implementations).

Hi, guys @zugofn, @donggoing, @ksnzh. Since we have uploaded the release a2mim-in1k-weights and updated documents in issue #31, we will close this issue in two days if there are no new questions. You can reopen it or start a new issue if you have more questions. I am pleased to discuss research topics relevant to self-supervised learning with you! 😃

@Lupin1998 Ok~Thanks for your work！

Hi, guys @zugofn, @donggoing, @ksnzh. Since we have uploaded the release a2mim-in1k-weights and updated documents in issue #31, we will close this issue in two days if there are no new questions. You can reopen it or start a new issue if you have more questions. I am pleased to discuss research topics relevant to self-supervised learning with you! 😃

Thanks for your quick and patient reply, thank you for your work!
Happy weekend~😀

I closed this issue if there is no more question. You can reopen it or start a new issue if you have more questions. Thanks again for your attention.


traits, specify that isSame works with types

To be accurate with the change in __traits semantics made by https://github.com/dlang/dmd/pull/9356

Well after all i think it's not required to mention the change.


Transform cause _id mess up

          does not make much sense

Originally posted by @vanpho93 in https://github.com/dryerjs/dryerjs/pull/246#discussion_r1398359059

:tada: This issue has been resolved in version 1.1.4 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


KAFKA-7394; OffsetsForLeaderEpoch supports topic describe access

As part of KIP-320, allow OffsetsForLeaderEpoch requests with Topic Describe permission.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

Note the failing test is fixed in #5635.

I am going to go ahead and merge. The build failures are due to a test regression in streams scala.


graphics crash

when I activated low quality and pressed graphics again, the game crashed

ye i seen that error cuz it happened to me too lmao, ill try to fix it as soon as possible (may take 2 days cuz im not near my pc atm)


feat: serialize interface slice

it don't serialize interface array. I add a support for it. due to I don't have a good solution for deserialization, this PR only contains serialize part.

I don't think an interface slice is a valid use case. We should use ComplexEnum if there might be multiple types of elements in a slice.

okay. for now it will only serialize the length without any elements. I think it will be a little bit confusing.
maybe we can serialize it or return an error ?

That's quite true, we should return error here.
#15 I've created an issue for it. Closing this now. @yihau


Check and set detail view in Layout instead of sub components

Bug
App state is not properly updated when using browser navigation, or clicking the logo at the top of Detail page.
This results in being "stuck" in the Detail page with the wrong navbar, if using the above methods to navigate.
Fix
Check path and set this state in Layout.tsx, instead of doing it in individual subcomponents and not covering all cases.

@jacobtyq please help to review this. I am not sure if I will understand the React changes properly!


Unable to view Battery performance

Describe the bug
This Bug is present again in the latest Unc0ver update. (4.2.0)
To Reproduce
Steps to reproduce the behavior:

Go to '.settings..'
Click on '.battery...'
Scroll down to '....'
See error

Screenshots
If applicable, add screenshots to help explain your problem.

Device (please complete the following information):

iOS Version:13.3
iOS Device: iPhone XR
unc0ver Version: 4.2.0

Place an "x" between the brackets if true:

[X] this is a bug others will be able to reproduce
[ ] this issue is present with all tweaks uninstalled(except for default packages) or disabled
[ ] this issue is present after a rootfs restore
[X] this issue is present on the latest version of unc0ver

Logs
If applicable, add logs or error messages here.

I have this issue as well.
iOS Version:13.3
iOS Device: iPhone Xs
unc0ver Version: 4.2.0
The issue is not present when Load Tweaks is toggled off, @dinol1187 can you test this as well? Maybe we have a common tweak causing this issue. I'll post my tweak list below.
Tweaks installed are (including defaults):
AppList
AppSync Unified
Arkrome
Asteroid
AudioSnapshotServer
Barmoji
BigBoss Icon Set
ColorFlow 5
Cydia Installer
Cydia Translations
HomePlus Beta
iPhone Firmware (/sbin)
Jailbreak resources
libCozy
libCSColorPicker
libCSPreferences
libmitsuha
MTerminal
Saw
shuffle
SnowBoard
StatusVis
Substitute
Substitute Support Package
Substrate Safe Mode
System Memory Reset Fix
Winter Mode for Apple Watch
Let me know if you have any of the same tweaks. If all we have in common are the default packages then the issue is likely something to do with those or unc0ver itself. If we do have common tweaks we should uninstall them one by one to check.

It’s not a tweak causing the issue. When you tick “load tweaks” what your doing is disabling tweak injection there is a bug in the latest unc0ver build causing the issue. I ended up downgrading unc0ver to 4.1.1 and the issue is not present and all is well again.

This happend with checkra1n too and should be fix
In the mean time, you can install tweak powerlogHelperdFix to fix this

I am having same issue.
iOS Version:13.3
iOS Device: iPhone XR
unc0ver Version: 4.2.0

I am having same issue.
iOS Version:13.3
iOS Device: iPhone XR
unc0ver Version: 4.2.0

wow，4.2.1 fixed it.
hahaha

Thanks pwn2ownd your latest update fixed this issue!


Some requests not sent via proxy on SUSE Linux

Hi,
I have integrated browsermob-proxy with my protractor tests. This works wonderfully when I run my tests from Mac (against local environment, or any other test environment).
However, when I run my tests from CI (agent is SUSE Enterprise 11.4) - my tests fail. I narrowed down the problem to the following scenario:
On some specific user action in the UI, there are a lot (>100) of requests fired from the browser in parallel (batches). There are a couple of scenarios like this in my application - and the test fails in all these cases.
Here is a screenshot of what the captured HAR file shows (in this case -

The same test works when I run this locally from Mac

Any idea how to fix this? Thank you in advance!
Some more information

I am starting the proxy server using a separate shell script
./browsermob-proxy-2.1.1/bin/browsermob-proxy --port $port --address $hostname &>$bmpLogDir/bmpProxy.log &

From my protractor tests - I start capture of the HAR file using this command:
{quote}
....
var captureHeaders = true;
var captureContent = true;
var captureBinaryContent = false;
browser.params.proxy.startHAR(browser.params.proxyData.port, name, captureHeaders, captureContent, captureBinaryContent, done);
{quote}

Some more context - the same test in CI passes if I do not start the proxy server.
Infant, after narrowing down the problem to the type of requests - I also tried the following:

start proxy server before running tests
startHAR capture at specific point
saveHAR before the action that causes failures

Even with this, my test fails. This means that having the proxy-server started may be the issue ....

Is there anything suspicious in the BMP log itself? Anything at the WARN or ERROR level that might point in the direction of the problem?

not really - the only 2 warnings I see are below:
[INFO  2016-07-08T08:06:59,511 net.lightbody.bmp.proxy.Main] (main) Starting BrowserMob Proxy version 2.1.1
[INFO  2016-07-08T08:06:59,547 org.eclipse.jetty.util.log] (main) jetty-7.x.y-SNAPSHOT
[INFO  2016-07-08T08:06:59,574 org.eclipse.jetty.util.log] (main) started o.e.j.s.ServletContextHandler{/,null}
[INFO  2016-07-08T08:06:59,713 org.eclipse.jetty.util.log] (main) Started SelectChannelConnector@localhost:7070
[INFO  2016-07-08T08:07:00,612 org.littleshoot.proxy.impl.DefaultHttpProxyServer] (qtp1667305539-17) Starting proxy at address: localhost/<IP_ADDRESS>:7075
[INFO  2016-07-08T08:07:00,627 org.littleshoot.proxy.impl.DefaultHttpProxyServer] (qtp1667305539-17) Proxy listening with TCP transport
[INFO  2016-07-08T08:07:00,664 org.littleshoot.proxy.impl.DefaultHttpProxyServer] (qtp1667305539-17) Proxy started at address: /<IP_ADDRESS>:7075
[INFO  2016-07-08T08:07:07,966 net.lightbody.bmp.proxy.ProxyManager] (qtp1667305539-16) Proxy already exists at port 7075
[WARN  2016-07-08T08:10:12,864 net.lightbody.bmp.filters.HarCaptureFilter] (LittleProxy-0-ProxyToServerWorker-0) No content type specified in response from http://my.host.com/s/info?f=firstname,lastname,uid,email,company. Content will be treated as application/octet-stream
[WARN  2016-07-08T08:10:26,231 net.lightbody.bmp.filters.HarCaptureFilter] (LittleProxy-0-ProxyToServerWorker-0) No content type specified in response from http://my.host.com/s/info?f=firstname,lastname,uid,email,company. Content will be treated as application/octet-stream

The only place I can probably narrow down is triggering a large number of requests in parallel from the browser and the proxy running at that time.
Is there any limit to how many concurrent requests the browsermob-proxy can handle (especially on linux)?

@jekh @lightbody
I think I have more information - I do see a lot of warnings - but also this exception popped up in the browsermob-proxy:
PS: The 1st warning message show most likely has no relation to the exception seen.
[WARN  2016-07-11T09:31:56,651 net.lightbody.bmp.filters.HarCaptureFilter] (LittleProxy-0-ProxyToServerWorker-4) No content type specified in response from http://localhost:9000/api/services//170?tenantid=90. Content will be treated as application/octet-stream
[WARN  2016-07-11T09:31:56,697 net.lightbody.bmp.filters.BrowserMobHttpFilterChain] (LittleProxy-0-ProxyToServerWorker-7) Filter in filter chain threw exception. Filter method may have been aborted. java.lang.NullPointerException
	at io.netty.handler.codec.http.HttpHeaders.getHeader(HttpHeaders.java:621) ~[browsermob-dist-2.1.1.jar:?]
	at net.lightbody.bmp.filters.ServerResponseCaptureFilter.captureContentEncoding(ServerResponseCaptureFilter.java:142) ~[browsermob-dist-2.1.1.jar:?]
	at net.lightbody.bmp.filters.ServerResponseCaptureFilter.serverToProxyResponse(ServerResponseCaptureFilter.java:97) ~[browsermob-dist-2.1.1.jar:?]
	at net.lightbody.bmp.filters.HarCaptureFilter.serverToProxyResponse(HarCaptureFilter.java:251) ~[browsermob-dist-2.1.1.jar:?]
	at net.lightbody.bmp.filters.BrowserMobHttpFilterChain.serverToProxyResponse(BrowserMobHttpFilterChain.java:123) [browsermob-dist-2.1.1.jar:?]
	at org.littleshoot.proxy.impl.ClientToProxyConnection.respond(ClientToProxyConnection.java:418) [browsermob-dist-2.1.1.jar:?]
	at org.littleshoot.proxy.impl.ProxyToServerConnection.respondWith(ProxyToServerConnection.java:534) [browsermob-dist-2.1.1.jar:?]
	at org.littleshoot.proxy.impl.ProxyToServerConnection.readHTTPChunk(ProxyToServerConnection.java:240) [browsermob-dist-2.1.1.jar:?]
	at org.littleshoot.proxy.impl.ProxyConnection.readHTTP(ProxyConnection.java:146) [browsermob-dist-2.1.1.jar:?]
	at org.littleshoot.proxy.impl.ProxyConnection.read(ProxyConnection.java:120) [browsermob-dist-2.1.1.jar:?]
	at org.littleshoot.proxy.impl.ProxyToServerConnection.read(ProxyToServerConnection.java:216) [browsermob-dist-2.1.1.jar:?]
	at org.littleshoot.proxy.impl.ProxyConnection.channelRead0(ProxyConnection.java:587) [browsermob-dist-2.1.1.jar:?]
	at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105) [browsermob-dist-2.1.1.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292) [browsermob-dist-2.1.1.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278) [browsermob-dist-2.1.1.jar:?]
	at io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:266) [browsermob-dist-2.1.1.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292) [browsermob-dist-2.1.1.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278) [browsermob-dist-2.1.1.jar:?]
	at io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86) [browsermob-dist-2.1.1.jar:?]
	at org.littleshoot.proxy.impl.ProxyConnection$ResponseReadMonitor.channelRead(ProxyConnection.java:738) [browsermob-dist-2.1.1.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292) [browsermob-dist-2.1.1.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278) [browsermob-dist-2.1.1.jar:?]
	at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:277) [browsermob-dist-2.1.1.jar:?]
	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:264) [browsermob-dist-2.1.1.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292) [browsermob-dist-2.1.1.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278) [browsermob-dist-2.1.1.jar:?]
	at io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86) [browsermob-dist-2.1.1.jar:?]
	at org.littleshoot.proxy.impl.ProxyConnection$BytesReadMonitor.channelRead(ProxyConnection.java:692) [browsermob-dist-2.1.1.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292) [browsermob-dist-2.1.1.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278) [browsermob-dist-2.1.1.jar:?]
	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:962) [browsermob-dist-2.1.1.jar:?]
	at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131) [browsermob-dist-2.1.1.jar:?]
	at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:528) [browsermob-dist-2.1.1.jar:?]
	at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:485) [browsermob-dist-2.1.1.jar:?]
	at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:399) [browsermob-dist-2.1.1.jar:?]
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:371) [browsermob-dist-2.1.1.jar:?]
	at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112) [browsermob-dist-2.1.1.jar:?]
	at java.lang.Thread.run(Thread.java:745) [?:1.8.0_45-internal]

This is a very interesting issue. The only thing that I can see that would cause the first NullPointerException is if LittleProxy processes the LastHttpContent before it finishes processing the first HttpResponse. Technically, this is possible, and BMP is not currently set up to handle this; though in reality it's very rare.
I've merged a PR that should fix the NPE, though it might still cause other strange issues to occur if messages are indeed being processed out-of-order. Can you build the latest code from master and test? And are you able to reproduce this consistently against a certain URL? I'd like to be able to debug locally, if possible.

Hi @jekh ,
Thanks for fixing this! I will try it out with a local build and get back to you guys with the update.
PS: Is this command (mvn -DskipTests -P release) the correct one to generate the latest build for testing?
Also, this is a consistently reproducible problem for me. What URL / info would you want to see for this to debug locally?

Hi @jekh  - I just tested this locally - and this works 👍
Thank you so much for the fix!! When is v2.1.2 expected to be released?

Thanks @anandbagmar, glad this fixed it. I would like to repro it locally though, to confirm whether it's processing messages out-of-order, or whether something else is going on. Is the URL you're hitting publicly accessible on the internet?
I was planning on putting out another release within the next couple days, most likely this weekend.

Hi @jekh  - unfortunately this is not a public url. But I will try to get a relevant code snippet / or create a sample page for this that hopefully is of help to you.
Looking forward to the new release! Thanks again

@anandbagmar - 2.1.2 is out now, so I'll close this issue. If you update it with steps to reproduce that work for you, I will do some investigation and see if I can fix the underlying issue.


NnUNetTrainerLightMUNet has not been used

Hello, I'm very sorry to disturb you. I didn't see nnUNetTrainerLightMUNet being used in the code, it has always been nnUNetTrainer. Could you tell me where nnUNetTrainerLightMUNet is being used? Thank you very much.

It is passed as an argument during training as mentioned in the README:
nnUNetv2_train DATASET_ID 2d all -tr nnUNetTrainerLightMUNet
By default nnUNetv2_train uses nnUNetTrainer, and if you want to incorporate a custom model such as LightM-UNet, a quick and dirty way is to write a custom trainer that will train using your custom model. All other stages in the pipeline (data preprocessing and augmentation) remain the same, except the model training. Please take a look at the nnUNet documentation - Extending nnUNet.

It is passed as an argument during training as mentioned in the README:
nnUNetv2_train DATASET_ID 2d all -tr nnUNetTrainerLightMUNet
By default nnUNetv2_train uses nnUNetTrainer, and if you want to incorporate a custom model such as LightM-UNet, a quick and dirty way is to write a custom trainer that will train using your custom model. All other stages in the pipeline (data preprocessing and augmentation) remain the same, except the model training. Please take a look at the nnUNet documentation - Extending nnUNet.

Thank you very much for your answer. With your help, I have started modifying my own model.


Feature: vaultAddress parameter for WalletClient

Description of the Desired Feature
Hyperliquid requires specifying the vaultAddress to indicate which Hyperliquid subaccount to trade on.
Currently, it's necessary to provide vault address each time a method like client.order() is invoked, which is tedious and error prone.
If it were possible to provide the vaultAddress when defining WalletClient, this would be DRYer and less error prone.
Additional info
vaultAddress would have a type of 0x${string}.

I'm not entirely sure about this suggestion, but it does seem to add convenience rather than making the SDK more high-level.
I suggest changing the constructor WalletClient so that it accepts a config object and add an optional defaultVaultAddress which is used if vaultAddress is not explicitly specified in the method call.

Implemented in https://github.com/nktkas/hyperliquid/commit/4ad416d3c207e7dc98e2a288621a51ccb7fc81ae in all methods except vaultTransfer.
Explanation why: The problem is that vaultTransfer requires vaultAddress to be present, unlike other methods, so it can end up with a situation where no vaultAddress is passed in the defaultVaultAddress or in the method arguments. TypeScript notices this. The only solution to this problem is to do a runtime check, but I think this is a bad solution because the SDK is TypeScript oriented and adding runtime checks can confuse developers into expecting vaultAddress to be optional (other methods don't have this problem because vaultAddress is not required for them to work).

Thanks!


Make previous/next shortcut keys not require Shift

Two suggestions I saw

Shift+P/Shift+N isn't intuitive, allow just P/N keys to move backwards and forwards. This shouldn't have the same issues that using left/right arrow keys would where they're captured by the FocusTrapZone and would be ignored in certain contexts.
Let B also move to the previous question (back), since it's next to the N key.

Change the tooltips in CycleChooser.tsx and the keybindings in ModaqControl.shortcutHandler to complete this.


Stars are not rendered

I am using this plugin in a modal to set ratings and when ever i use some condition to toggle modal stars are not binded

@Curious-Prateek , it would be great if you share me the snipped using jsBin/Codepen.


Revisit on mutable self references

I don't understand the reason for immutable self references that clearly do mutate the state of self or require exclusive access to the underlying implementation or bus. I think this design decision only causes hacks to circumvent it, unnecessary overhead in the driver implementation (which is the opposite of 'zero cost'/'you only pay for what you need') and does not reflect the strategy of the rust ecosystem, such as  embedded-hal, std-Read, std-Write, tokio-AsyncRead or tokio-AsyncWrite.
I don't follow the argument of @thejpster here as it seems more of an special case scenario and could be solved otherwise by implementing Clone on what seems to be an FD or raw-pointer(?) internally.
Feel free to convince me otherwise.
We stumbled over this in a discussion here where @jonahd-g (thanky you!) proposes an implementation of embedded-nal for the w5500 driver.

I think my example stands. If you can show me a functioning example which has at least two users of embedded-nal (e.g. an HTTP client and something else - CoAP, SMTP, DNS, MQTT, or whatever), and that the burden of juggling the mut-ref between two entirely independent protocol implementations isn't onerous, I'm happy to be persuaded. I come at this as a protocol and wireless systems engineer and so separation of concerns is important to me. Plus I prefer to place complexity in the nal impl rather than on the nal user, so it only has to be done once. I understand though, that others may have different priorities and if your model is, say, the Arduino HTTP library, I can see why embedded-nal might grate a little.
I also think my example of the BSD socket library is valid, as it's what almost all stacks are based on (certainly Linux, Windows and macOS are). There, the mutable state is entirely an issue for your OS, and not your application or library - you do not have to lock anything, you just call 'open' or 'write', etc. This is what I have tried to follow, but using an immutable reference to alleviate the need for a global static state variable, which makes unit testing harder.

In my opinion, the comparison with the BSD Socket API or POSIX (connect) API is not fair or completely correct. There is no equivalent argument for &self (which would be the ~kernel, I guess?). To some extend, the functions are called on a global static mut instance via sys-calls.
embedded-nal seems to build driver abstractions for devices (if I get this correctly?), but you compare it to the features of an full fledged Kernel/OS?
In my understanding, if I need an instance to be mutable from two or more sources, I would then wrap it in a RefCell or Mutex or whatever fits. Enforcing this on the driver will either cause some overhead (RefCell), more overhead (Mutex)  - regardless of whether this is actually required - or lacking support for either/some use case scenarios at the driver level.
I see your point that it might become awkward managing and passing along wrapped driver impls. But I still think, writing a little (user-)wrapper is more flexible than enforcing support for all scenarios on the driver level.
pub trait UdpClientStack {
	fn send(&mut self, socket: &mut Self::UdpSocket, buffer: &[u8]) -> nb::Result<(), Self::Error>;
}

pub struct MyDriver { ... };
impl UdpClientStack for MyDriver {
	fn send(&mut self, socket: &mut Self::UdpSocket, buffer: &[u8]) -> nb::Result<(), Self::Error> {
            // do the stuff without overhead
        }
}

pub struct RefWrapper<'a>(&'a RefCell<MyDriver>);
// pub struct MutexWrapper<'a>(&'a Mutex<MyDriver>); // as alternative in threaded environments
// pub struct RcWrapper(Rc<RefCell<MyDriver>>); // for alloc environments

impl UdpClientStack for RefWrapper<'_> {
	fn send(&mut self, socket: &mut Self::UdpSocket, buffer: &[u8]) -> nb::Result<(), Self::Error> {
            self.0.borrow_mut().send(socket, buffer)
        }
}

fn main() {
    let mut driver = MyDriver::new();
    send(&mut driver); // no overhead

    let shared_driver = RefCell::new(driver);
    let mut http_ref = RefWrapper(&shared_driver);
    let mut smtp_ref = RefWrapper(&shared_driver);
    let mut mqtt_ref = smtp_ref.clone(); // or if clone is derived

    send(&mut http_ref); // opt-in overhead

    let mut client = http_connect(http_ref, "https://www.google.de/search?q=what+is+my+ip");
    let ip = client.read(..);
}

fn send(udp: &mut impl UdpClientStack) {
    // ...
}

// for the sake of typing-simplicity of this example, assuming HTTP travels over UDP
fn http_connect<T: UdpClientStack>(my_owned_stack: T, url: &str) -> HttpClient { ... }

If I am not mistaken, the lifetimes of *_ref in the example above should behave the same as with direct immutable references to the driver.

embedded-nal seems to build driver abstractions for devices (if I get this correctly?), but you compare it to the features of an full fledged Kernel/OS?

embedded-nal exists because I was annoyed it was so difficult to write an HTTP library that worked on both a Quectel BC68 (TCP over AT over UART) and a Nordic nRF9160 (BSDish sockets). I then didn't have time to finish the idea, so it ended up here.
Your argument that we should bring the choice of which mutex (if any) to use up to the application layer, as opposed to putting it at the TCP/UDP layer is persuasive. It does make assembling an application more complicated (outside of the naive case of using a single NAL protocol), but perhaps all the tedious .borrow_mut() wrappers can be generated with macros.

I think we can have a best-of-both-worlds situation if we do require a &mut, but encourage stack authors to provide clonable, runtime-mutexed version of it.
Thus, it would be up to the high-level application author whether they want runtime efficiency (passing the single &mut stack to whichever part of their software just needs it, taking it back from them when that part is dormant) or whether they just take the runtime overhead of needlessly going through the mutex several times in code that could really do without, and just pass everyone an owned object that performs a lock/unlock on every single operation.

I think we can have a best-of-both-worlds situation if we do require a &mut, but encourage stack authors to provide clonable, runtime-mutexed version of it.
Thus, it would be up to the high-level application author whether they want runtime efficiency (passing the single &mut stack to whichever part of their software just needs it, taking it back from them when that part is dormant) or whether they just take the runtime overhead of needlessly going through the mutex several times in code that could really do without, and just pass everyone an owned object that performs a lock/unlock on every single operation.

@kellerkindt I think only MutexWrapper is the only example you gave that makes sense in practice, because the other ones panic if the stack is already borrowed.
In general I would argue for flexibility, too. But I think in this case putting the burden to add synchronization on every implementer of embedded-nal is much less painful than putting it on every user. The only way forward for this idea I can see is providing some kind of MutexWrapper in embedded-nal which allows users to make their stack concurrent without the need for implementers to care about synchronization. If somebody can come up with how this might look, this could be useful.
In general I would say that a simple, single threaded application, where you don't need mutexes is probably not the majority and should probably not be the focus of embedded-nal.

@kellerkindt I think only MutexWrapper is the only example you gave that makes sense in practice, because the other ones panic if the stack is already borrowed.
In general I would argue for flexibility, too. But I think in this case putting the burden to add synchronization on every implementer of embedded-nal is much less painful than putting it on every user. The only way forward for this idea I can see is providing some kind of MutexWrapper in embedded-nal which allows users to make their stack concurrent without the need for implementers to care about synchronization. If somebody can come up with how this might look, this could be useful.
In general I would say that a simple, single threaded application, where you don't need mutexes is probably not the majority and should probably not be the focus of embedded-nal.

I find @kellerkindt's comment about zero-cost-abstractions to be compelling.  Requiring all driver implementations to be internally thread-safe puts a wasted cost on applications that don't need it.
IMO the NAL should dictate only the most simply common abstraction possible.  A feature like thread safety (however important to whatever potential majority) falls outside of that simple abstraction.
My thoughts on this align with what @Sympatron suggested: providing a thread-safe wrapper.  It would need the following attributes:

Take ownership (or mutably borrow) of a NAL implementation
Implement the NAL traits itself
Implement the Sync trait (? I'm not well versed on multithreading in Rust).

I'd also suggest that perhaps this wrapper may belong in a different crate, that way traits and implementations are kept separate.
If this is a direction that is acceptable to the maintainers, I'd be willing to start experimenting into how this could be done. I don't expect it would be particularly complicated, but I'm still a junior rustacean at this point (especially when it comes to thread safety).

I find @kellerkindt's comment about zero-cost-abstractions to be compelling.  Requiring all driver implementations to be internally thread-safe puts a wasted cost on applications that don't need it.
IMO the NAL should dictate only the most simply common abstraction possible.  A feature like thread safety (however important to whatever potential majority) falls outside of that simple abstraction.
My thoughts on this align with what @Sympatron suggested: providing a thread-safe wrapper.  It would need the following attributes:

Take ownership (or mutably borrow) of a NAL implementation
Implement the NAL traits itself
Implement the Sync trait (? I'm not well versed on multithreading in Rust).

I'd also suggest that perhaps this wrapper may belong in a different crate, that way traits and implementations are kept separate.
If this is a direction that is acceptable to the maintainers, I'd be willing to start experimenting into how this could be done. I don't expect it would be particularly complicated, but I'm still a junior rustacean at this point (especially when it comes to thread safety).

I would have no issue going in that direction, and would definitely be very keen on seeing the result. Can any of you think of other abstration crates that does it in this way? or the other way for that sake?
Thoughts @ryan-summers  @eldruin ?

I would have no issue going in that direction, and would definitely be very keen on seeing the result. Can any of you think of other abstration crates that does it in this way? or the other way for that sake?
Thoughts @ryan-summers  @eldruin ?

I personally am more aligned with @chrysn's opinion. Specifically, I do see a lot of applications that will only use a single protocol on top of the embedded-nal, where the NAL is intended just to be an abstract API so that a protocol isn't tied to a particular stack.
However, as noted, some users may need to use it with multiple protocols, and forcing them to handle the synchronization is quite an ask (it's a complex, hard topic).
I figure it may be worth stating here, but in the shared-bus crate, it comes to light that creating a generic mutex is a very non-trivial ask. Thus, it may not even make sense for embedded-nal implementers to provide a default-safe, sharable stack for all types of architectures.

I personally am more aligned with @chrysn's opinion. Specifically, I do see a lot of applications that will only use a single protocol on top of the embedded-nal, where the NAL is intended just to be an abstract API so that a protocol isn't tied to a particular stack.
However, as noted, some users may need to use it with multiple protocols, and forcing them to handle the synchronization is quite an ask (it's a complex, hard topic).
I figure it may be worth stating here, but in the shared-bus crate, it comes to light that creating a generic mutex is a very non-trivial ask. Thus, it may not even make sense for embedded-nal implementers to provide a default-safe, sharable stack for all types of architectures.

Replicating something like shared-bus sounds like a good idea. If somebody is able to pull this off the synchronization would be contained in one place. But I don't know how complicated this would be.

Replicating something like shared-bus sounds like a good idea. If somebody is able to pull this off the synchronization would be contained in one place. But I don't know how complicated this would be.

I think the object which hands out mutable access to the stack is necessarily going to depend on the RTOS (or not) that you are running.
Using RTIC, the exclusivity is given by the framework and the Interrupt controller, so you need an impl UDPStack for RTIC_UDP_Proxy.
Using FreeRTOS, the exclusivity will be through a FreeRTOS mutex that suspends the task until the stack is available, so you need a `impl UDPStack for FreeRTOS_UDP_Proxy
Using Mentor Nucleus you will need to use the Nucleus mutex...
Using mbedOS you will need to use the mbedOS / CMSIS Nucleus...
If you have none of the above, you can just use the stack implementation directly.
Tangentially, this doesn't solve the issue that if the reference isn't immutable, you can't store the stack reference in the socket object. This means you need to be very careful to pass the correct socket object to the correct stack object.
let mut buffer = [0u8; 1500];
let mut stack_one = QuectelTcpStack(uart1);
let mut stack_two = QuectelTcpStack(uart2);
let mut stack_three = PosixTcpStack();
let mut socket_one = stack_one.open("google.com", 80);
let results = stack_two.read(&mut stack_one, &mut buffer); /* boom - and even type checking can't help here */
let results = stack_three.read(&mut stack_one, &mut buffer); /* also boom - but type checking could catch this */

I think the object which hands out mutable access to the stack is necessarily going to depend on the RTOS (or not) that you are running.
Using RTIC, the exclusivity is given by the framework and the Interrupt controller, so you need an impl UDPStack for RTIC_UDP_Proxy.
Using FreeRTOS, the exclusivity will be through a FreeRTOS mutex that suspends the task until the stack is available, so you need a `impl UDPStack for FreeRTOS_UDP_Proxy
Using Mentor Nucleus you will need to use the Nucleus mutex...
Using mbedOS you will need to use the mbedOS / CMSIS Nucleus...
If you have none of the above, you can just use the stack implementation directly.
Tangentially, this doesn't solve the issue that if the reference isn't immutable, you can't store the stack reference in the socket object. This means you need to be very careful to pass the correct socket object to the correct stack object.
let mut buffer = [0u8; 1500];
let mut stack_one = QuectelTcpStack(uart1);
let mut stack_two = QuectelTcpStack(uart2);
let mut stack_three = PosixTcpStack();
let mut socket_one = stack_one.open("google.com", 80);
let results = stack_two.read(&mut stack_one, &mut buffer); /* boom - and even type checking can't help here */
let results = stack_three.read(&mut stack_one, &mut buffer); /* also boom - but type checking could catch this */

@thejpster While the current embedded-nal traits require internal mutability, they don't enforce thread safety.  Right now whether a driver is thread-safe is entirely up to the implementation.  Since that's the status quo, I think we should solve and release a single-thread solution, then come up with a thread-safe solution after.  What do you think?
Here's what I have so far on a single-threaded sharable wrapper, similar to shared-bus.
use core::cell::RefCell;
use embedded_nal::{SocketAddr, UdpClient};

pub struct SharedUdpClientManagerSimple<T: UdpClient> {
    driver: RefCell<T>,
}

impl<T: UdpClient> SharedUdpClientManagerSimple<T> {
    pub fn new(driver: T) -> Self {
        SharedUdpClientManagerSimple {
            driver: RefCell::new(driver),
        }
    }

    pub fn acquire(&self) -> SharedUdpClientSimple<T> {
        SharedUdpClientSimple {
            driver: &self.driver,
        }
    }
}

pub struct SharedUdpClientSimple<'a, T: UdpClient> {
    driver: &'a RefCell<T>,
}

impl<'a, T: UdpClient> UdpClient for SharedUdpClientSimple<'a, T> {
    type Error = T::Error;
    type UdpSocket = T::UdpSocket;

    fn connect(&mut self, address: SocketAddr) -> Result<Self::UdpSocket, Self::Error> {
        self.driver.borrow_mut().connect(address)
    }

    fn send(
        &mut self,
        socket: &mut Self::UdpSocket,
        data: &[u8],
    ) -> Result<(), embedded_nal::nb::Error<<T as embedded_nal::UdpClient>::Error>> {
        self.driver.borrow_mut().send(socket, data)
    }

    fn receive(
        &mut self,
        socket: &mut Self::UdpSocket,
        data: &mut [u8],
    ) -> Result<(usize, SocketAddr), embedded_nal::nb::Error<<T as embedded_nal::UdpClient>::Error>>
    {
        self.driver.borrow_mut().receive(socket, data)
    }

    fn close(&mut self, socket: Self::UdpSocket) -> Result<(), Self::Error> {
        self.driver.borrow_mut().close(socket)
    }
}

This compiles nicely.  This depends on an embedded-nal patched to use mutable references.  Obviously this isn't super useful yet, since you can only share a single trait from the NAL at a time.  I need to think more about how to permit sharing as many stack traits as are available.

@thejpster While the current embedded-nal traits require internal mutability, they don't enforce thread safety.  Right now whether a driver is thread-safe is entirely up to the implementation.  Since that's the status quo, I think we should solve and release a single-thread solution, then come up with a thread-safe solution after.  What do you think?
Here's what I have so far on a single-threaded sharable wrapper, similar to shared-bus.
use core::cell::RefCell;
use embedded_nal::{SocketAddr, UdpClient};

pub struct SharedUdpClientManagerSimple<T: UdpClient> {
    driver: RefCell<T>,
}

impl<T: UdpClient> SharedUdpClientManagerSimple<T> {
    pub fn new(driver: T) -> Self {
        SharedUdpClientManagerSimple {
            driver: RefCell::new(driver),
        }
    }

    pub fn acquire(&self) -> SharedUdpClientSimple<T> {
        SharedUdpClientSimple {
            driver: &self.driver,
        }
    }
}

pub struct SharedUdpClientSimple<'a, T: UdpClient> {
    driver: &'a RefCell<T>,
}

impl<'a, T: UdpClient> UdpClient for SharedUdpClientSimple<'a, T> {
    type Error = T::Error;
    type UdpSocket = T::UdpSocket;

    fn connect(&mut self, address: SocketAddr) -> Result<Self::UdpSocket, Self::Error> {
        self.driver.borrow_mut().connect(address)
    }

    fn send(
        &mut self,
        socket: &mut Self::UdpSocket,
        data: &[u8],
    ) -> Result<(), embedded_nal::nb::Error<<T as embedded_nal::UdpClient>::Error>> {
        self.driver.borrow_mut().send(socket, data)
    }

    fn receive(
        &mut self,
        socket: &mut Self::UdpSocket,
        data: &mut [u8],
    ) -> Result<(usize, SocketAddr), embedded_nal::nb::Error<<T as embedded_nal::UdpClient>::Error>>
    {
        self.driver.borrow_mut().receive(socket, data)
    }

    fn close(&mut self, socket: Self::UdpSocket) -> Result<(), Self::Error> {
        self.driver.borrow_mut().close(socket)
    }
}

This compiles nicely.  This depends on an embedded-nal patched to use mutable references.  Obviously this isn't super useful yet, since you can only share a single trait from the NAL at a time.  I need to think more about how to permit sharing as many stack traits as are available.

Makes sense.
Should it be in this crate though? Or should it be in embedded-nal-sharing (name TBD)?

Makes sense.
Should it be in this crate though? Or should it be in embedded-nal-sharing (name TBD)?

@thejpster Different crate IMO.  I'm using that same name for my testing crate.
Took me a little while of lying in bed to realize how to share all the different traits.  Not fully implemented, just need to flesh out all of the proxy functions.
use core::cell::RefCell;
use embedded_nal::{SocketAddr, UdpClient, UdpServer, TcpStack};

pub struct SharedNalManagerSimple<T> {
    driver: RefCell<T>,
}

impl<T> SharedNalManagerSimple<T> {
    pub fn new(driver: T) -> Self {
        SharedNalManagerSimple {
            driver: RefCell::new(driver),
        }
    }
}

impl<T: UdpClient> SharedNalManagerSimple<T> {
    pub fn acquire_udp_client(&self) -> SharedUdpClientSimple<T> {
        SharedUdpClientSimple {
            driver: &self.driver,
        }
    }
}

impl<T: UdpServer> SharedNalManagerSimple<T> {
    // acquire_udp_server ...
}

impl<T: TcpStack> SharedNalManagerSimple<T> {
    // acquire_tcp_stack ...
}

pub struct SharedUdpClientSimple<'a, T: UdpClient> {
    driver: &'a RefCell<T>,
}

impl<'a, T: UdpClient> UdpClient for SharedUdpClientSimple<'a, T> {
    type Error = T::Error;
    type UdpSocket = T::UdpSocket;

    fn connect(&mut self, address: SocketAddr) -> Result<Self::UdpSocket, Self::Error> {
        self.driver.borrow_mut().connect(address)
    }

    fn send(
        &mut self,
        socket: &mut Self::UdpSocket,
        data: &[u8],
    ) -> Result<(), embedded_nal::nb::Error<<T as embedded_nal::UdpClient>::Error>> {
        self.driver.borrow_mut().send(socket, data)
    }

    fn receive(
        &mut self,
        socket: &mut Self::UdpSocket,
        data: &mut [u8],
    ) -> Result<(usize, SocketAddr), embedded_nal::nb::Error<<T as embedded_nal::UdpClient>::Error>>
    {
        self.driver.borrow_mut().receive(socket, data)
    }

    fn close(&mut self, socket: Self::UdpSocket) -> Result<(), Self::Error> {
        self.driver.borrow_mut().close(socket)
    }
}

@thejpster Different crate IMO.  I'm using that same name for my testing crate.
Took me a little while of lying in bed to realize how to share all the different traits.  Not fully implemented, just need to flesh out all of the proxy functions.
use core::cell::RefCell;
use embedded_nal::{SocketAddr, UdpClient, UdpServer, TcpStack};

pub struct SharedNalManagerSimple<T> {
    driver: RefCell<T>,
}

impl<T> SharedNalManagerSimple<T> {
    pub fn new(driver: T) -> Self {
        SharedNalManagerSimple {
            driver: RefCell::new(driver),
        }
    }
}

impl<T: UdpClient> SharedNalManagerSimple<T> {
    pub fn acquire_udp_client(&self) -> SharedUdpClientSimple<T> {
        SharedUdpClientSimple {
            driver: &self.driver,
        }
    }
}

impl<T: UdpServer> SharedNalManagerSimple<T> {
    // acquire_udp_server ...
}

impl<T: TcpStack> SharedNalManagerSimple<T> {
    // acquire_tcp_stack ...
}

pub struct SharedUdpClientSimple<'a, T: UdpClient> {
    driver: &'a RefCell<T>,
}

impl<'a, T: UdpClient> UdpClient for SharedUdpClientSimple<'a, T> {
    type Error = T::Error;
    type UdpSocket = T::UdpSocket;

    fn connect(&mut self, address: SocketAddr) -> Result<Self::UdpSocket, Self::Error> {
        self.driver.borrow_mut().connect(address)
    }

    fn send(
        &mut self,
        socket: &mut Self::UdpSocket,
        data: &[u8],
    ) -> Result<(), embedded_nal::nb::Error<<T as embedded_nal::UdpClient>::Error>> {
        self.driver.borrow_mut().send(socket, data)
    }

    fn receive(
        &mut self,
        socket: &mut Self::UdpSocket,
        data: &mut [u8],
    ) -> Result<(usize, SocketAddr), embedded_nal::nb::Error<<T as embedded_nal::UdpClient>::Error>>
    {
        self.driver.borrow_mut().receive(socket, data)
    }

    fn close(&mut self, socket: Self::UdpSocket) -> Result<(), Self::Error> {
        self.driver.borrow_mut().close(socket)
    }
}

@kellerkindt ping for your feedback on this

@kellerkindt ping for your feedback on this

Tried my hand at writing a macro for the first time, and wow, between the intuitive syntax and the clear error messages, that was really easy.  Got rid of the infinite list of self.driver.borrow_mut()s.
use core::cell::RefCell;
use embedded_nal::{nb, SocketAddr, TcpStack, UdpClient, UdpServer};

pub struct SharedNalManager<T> {
    driver: RefCell<T>,
}

impl<T> SharedNalManager<T> {
    pub fn new(driver: T) -> Self {
        SharedNalManager {
            driver: RefCell::new(driver),
        }
    }

    pub fn acquire(&self) -> SharedNal<T> {
        SharedNal {
            driver: &self.driver,
        }
    }
}

pub struct SharedNal<'a, T> {
    driver: &'a RefCell<T>,
}

macro_rules! forward {
    ($func:ident($($v:ident: $IT:ty),*) -> $T:ty) => {
        fn $func(&mut self, $($v: $IT),*) -> $T {
            self.driver.borrow_mut().$func($($v),*)
        }
    }
}

impl<'a, T: UdpClient> UdpClient for SharedNal<'a, T> {
    type Error = T::Error;
    type UdpSocket = T::UdpSocket;

    forward! {connect(address: SocketAddr) -> Result<Self::UdpSocket, Self::Error>}
    forward! {send(socket: &mut Self::UdpSocket, data: &[u8]) -> Result<(), nb::Error<<T as embedded_nal::UdpClient>::Error>>}
    forward! {receive(socket: &mut Self::UdpSocket, data: &mut [u8]) -> Result<(usize, SocketAddr), nb::Error<<T as embedded_nal::UdpClient>::Error>>}
    forward! {close(socket: Self::UdpSocket) -> Result<(), Self::Error>}
}

impl<'a, T: UdpServer> UdpServer for SharedNal<'a, T> {
    forward! {bind(local_port: u16) -> Result<Self::UdpSocket, Self::Error>}
    forward! {send_to(socket: &mut Self::UdpSocket, remote: SocketAddr, buffer: &[u8]) -> Result<(), nb::Error<<T as embedded_nal::UdpClient>::Error>>}
}

impl<'a, T: TcpStack> TcpStack for SharedNal<'a, T> {
    type TcpSocket = T::TcpSocket;
    type Error = T::Error;

    forward! {open() -> Result<Self::TcpSocket, Self::Error>}
    forward! {connect(socket: Self::TcpSocket, address: SocketAddr) -> Result<Self::TcpSocket, Self::Error>}
    forward! {is_connected(socket: &Self::TcpSocket) -> Result<bool, Self::Error>}
    forward! {write(socket: &mut Self::TcpSocket, buffer: &[u8]) -> nb::Result<usize, Self::Error>}
    forward! {read(socket: &mut Self::TcpSocket, buffer: &mut [u8]) -> nb::Result<usize, Self::Error>}
    forward! {close(socket: Self::TcpSocket) -> Result<(), Self::Error>}
}

Tried my hand at writing a macro for the first time, and wow, between the intuitive syntax and the clear error messages, that was really easy.  Got rid of the infinite list of self.driver.borrow_mut()s.
use core::cell::RefCell;
use embedded_nal::{nb, SocketAddr, TcpStack, UdpClient, UdpServer};

pub struct SharedNalManager<T> {
    driver: RefCell<T>,
}

impl<T> SharedNalManager<T> {
    pub fn new(driver: T) -> Self {
        SharedNalManager {
            driver: RefCell::new(driver),
        }
    }

    pub fn acquire(&self) -> SharedNal<T> {
        SharedNal {
            driver: &self.driver,
        }
    }
}

pub struct SharedNal<'a, T> {
    driver: &'a RefCell<T>,
}

macro_rules! forward {
    ($func:ident($($v:ident: $IT:ty),*) -> $T:ty) => {
        fn $func(&mut self, $($v: $IT),*) -> $T {
            self.driver.borrow_mut().$func($($v),*)
        }
    }
}

impl<'a, T: UdpClient> UdpClient for SharedNal<'a, T> {
    type Error = T::Error;
    type UdpSocket = T::UdpSocket;

    forward! {connect(address: SocketAddr) -> Result<Self::UdpSocket, Self::Error>}
    forward! {send(socket: &mut Self::UdpSocket, data: &[u8]) -> Result<(), nb::Error<<T as embedded_nal::UdpClient>::Error>>}
    forward! {receive(socket: &mut Self::UdpSocket, data: &mut [u8]) -> Result<(usize, SocketAddr), nb::Error<<T as embedded_nal::UdpClient>::Error>>}
    forward! {close(socket: Self::UdpSocket) -> Result<(), Self::Error>}
}

impl<'a, T: UdpServer> UdpServer for SharedNal<'a, T> {
    forward! {bind(local_port: u16) -> Result<Self::UdpSocket, Self::Error>}
    forward! {send_to(socket: &mut Self::UdpSocket, remote: SocketAddr, buffer: &[u8]) -> Result<(), nb::Error<<T as embedded_nal::UdpClient>::Error>>}
}

impl<'a, T: TcpStack> TcpStack for SharedNal<'a, T> {
    type TcpSocket = T::TcpSocket;
    type Error = T::Error;

    forward! {open() -> Result<Self::TcpSocket, Self::Error>}
    forward! {connect(socket: Self::TcpSocket, address: SocketAddr) -> Result<Self::TcpSocket, Self::Error>}
    forward! {is_connected(socket: &Self::TcpSocket) -> Result<bool, Self::Error>}
    forward! {write(socket: &mut Self::TcpSocket, buffer: &[u8]) -> nb::Result<usize, Self::Error>}
    forward! {read(socket: &mut Self::TcpSocket, buffer: &mut [u8]) -> nb::Result<usize, Self::Error>}
    forward! {close(socket: Self::TcpSocket) -> Result<(), Self::Error>}
}

I don't think a RefCell is Any, so it cannot be shared in multiple
contexts. I've personally been using Unsafe cell instead. Will take a
closer look at the ideas here later as well
On Sun, Jan 17, 2021, 21:02 Jonah Dahlquist<EMAIL_ADDRESS>wrote:

Tried my hand at writing a macro for the first time, and wow, between the
intuitive syntax and the clear error messages, that was really easy. Got
rid of the infinite list of self.driver.borrow_mut()s.
use core::cell::RefCell;use embedded_nal::{nb, SocketAddr, TcpStack, UdpClient, UdpServer};
pub struct SharedNalManager {
driver: RefCell,
}
impl SharedNalManager {
pub fn new(driver: T) -> Self {
SharedNalManager {
driver: RefCell::new(driver),
}
}
pub fn acquire(&self) -> SharedNal<T> {
    SharedNal {
        driver: &self.driver,
    }
}

}
pub struct SharedNal<'a, T> {
driver: &'a RefCell,
}
macro_rules! forward {
($func:ident($($v:ident: $IT:ty),) -> $T:ty) => {
fn $func(&mut self, $($v: $IT),) -> $T {
self.driver.borrow_mut().$func($($v),*)
}
}
}
impl<'a, T: UdpClient> UdpClient for SharedNal<'a, T> {
type Error = T::Error;
type UdpSocket = T::UdpSocket;
forward! {connect(address: SocketAddr) -> Result<Self::UdpSocket, Self::Error>}
forward! {send(socket: &mut Self::UdpSocket, data: &[u8]) -> Result<(), nb::Error<<T as embedded_nal::UdpClient>::Error>>}
forward! {receive(socket: &mut Self::UdpSocket, data: &mut [u8]) -> Result<(usize, SocketAddr), nb::Error<<T as embedded_nal::UdpClient>::Error>>}
forward! {close(socket: Self::UdpSocket) -> Result<(), Self::Error>}

}
impl<'a, T: UdpServer> UdpServer for SharedNal<'a, T> {
forward! {bind(local_port: u16) -> Result<Self::UdpSocket, Self::Error>}
forward! {send_to(socket: &mut Self::UdpSocket, remote: SocketAddr, buffer: &[u8]) -> Result<(), nb::Error<::Error>>}
}
impl<'a, T: TcpStack> TcpStack for SharedNal<'a, T> {
type TcpSocket = T::TcpSocket;
type Error = T::Error;
forward! {open() -> Result<Self::TcpSocket, Self::Error>}
forward! {connect(socket: Self::TcpSocket, address: SocketAddr) -> Result<Self::TcpSocket, Self::Error>}
forward! {is_connected(socket: &Self::TcpSocket) -> Result<bool, Self::Error>}
forward! {write(socket: &mut Self::TcpSocket, buffer: &[u8]) -> nb::Result<usize, Self::Error>}
forward! {read(socket: &mut Self::TcpSocket, buffer: &mut [u8]) -> nb::Result<usize, Self::Error>}
forward! {close(socket: Self::TcpSocket) -> Result<(), Self::Error>}

}
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-embedded-community/embedded-nal/issues/39#issuecomment-761870979,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACC5O6QNUS24LG7VBEZGMYDS2M65JANCNFSM4VPOPDZQ
.

I don't think a RefCell is Any, so it cannot be shared in multiple
contexts. I've personally been using Unsafe cell instead. Will take a
closer look at the ideas here later as well
On Sun, Jan 17, 2021, 21:02 Jonah Dahlquist<EMAIL_ADDRESS>wrote:

Tried my hand at writing a macro for the first time, and wow, between the
intuitive syntax and the clear error messages, that was really easy. Got
rid of the infinite list of self.driver.borrow_mut()s.
use core::cell::RefCell;use embedded_nal::{nb, SocketAddr, TcpStack, UdpClient, UdpServer};
pub struct SharedNalManager {
driver: RefCell,
}
impl SharedNalManager {
pub fn new(driver: T) -> Self {
SharedNalManager {
driver: RefCell::new(driver),
}
}
pub fn acquire(&self) -> SharedNal<T> {
    SharedNal {
        driver: &self.driver,
    }
}

}
pub struct SharedNal<'a, T> {
driver: &'a RefCell,
}
macro_rules! forward {
($func:ident($($v:ident: $IT:ty),) -> $T:ty) => {
fn $func(&mut self, $($v: $IT),) -> $T {
self.driver.borrow_mut().$func($($v),*)
}
}
}
impl<'a, T: UdpClient> UdpClient for SharedNal<'a, T> {
type Error = T::Error;
type UdpSocket = T::UdpSocket;
forward! {connect(address: SocketAddr) -> Result<Self::UdpSocket, Self::Error>}
forward! {send(socket: &mut Self::UdpSocket, data: &[u8]) -> Result<(), nb::Error<<T as embedded_nal::UdpClient>::Error>>}
forward! {receive(socket: &mut Self::UdpSocket, data: &mut [u8]) -> Result<(usize, SocketAddr), nb::Error<<T as embedded_nal::UdpClient>::Error>>}
forward! {close(socket: Self::UdpSocket) -> Result<(), Self::Error>}

}
impl<'a, T: UdpServer> UdpServer for SharedNal<'a, T> {
forward! {bind(local_port: u16) -> Result<Self::UdpSocket, Self::Error>}
forward! {send_to(socket: &mut Self::UdpSocket, remote: SocketAddr, buffer: &[u8]) -> Result<(), nb::Error<::Error>>}
}
impl<'a, T: TcpStack> TcpStack for SharedNal<'a, T> {
type TcpSocket = T::TcpSocket;
type Error = T::Error;
forward! {open() -> Result<Self::TcpSocket, Self::Error>}
forward! {connect(socket: Self::TcpSocket, address: SocketAddr) -> Result<Self::TcpSocket, Self::Error>}
forward! {is_connected(socket: &Self::TcpSocket) -> Result<bool, Self::Error>}
forward! {write(socket: &mut Self::TcpSocket, buffer: &[u8]) -> nb::Result<usize, Self::Error>}
forward! {read(socket: &mut Self::TcpSocket, buffer: &mut [u8]) -> nb::Result<usize, Self::Error>}
forward! {close(socket: Self::TcpSocket) -> Result<(), Self::Error>}

}
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-embedded-community/embedded-nal/issues/39#issuecomment-761870979,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACC5O6QNUS24LG7VBEZGMYDS2M65JANCNFSM4VPOPDZQ
.

A point worth considering in this, would also be that RefCell does not work out great with Futures and async/await once that becomes a thing in embedded contexts.. Not that it would be a main motivator, but might be worth considering as part of this discussion.

A point worth considering in this, would also be that RefCell does not work out great with Futures and async/await once that becomes a thing in embedded contexts.. Not that it would be a main motivator, but might be worth considering as part of this discussion.

I think we've come to the realization that any thread-safety provided by embedded-nal has to be managed similarly to how shared-bus manages thread safety (e.g. via external library wrappers for creating mutex'd proxies in a platform-dependent manner). As such, given that these functions often do require internal mutability of the stack (and logically do as well), I would be happy to move forward with adding mut to self references here.
Thoughts?

I think we've come to the realization that any thread-safety provided by embedded-nal has to be managed similarly to how shared-bus manages thread safety (e.g. via external library wrappers for creating mutex'd proxies in a platform-dependent manner). As such, given that these functions often do require internal mutability of the stack (and logically do as well), I would be happy to move forward with adding mut to self references here.
Thoughts?

Having looked a little deeper into shared-bus, I think this is exactly what we would want for embedded-nal, too. I think all problems mentioned can be handled like that. It is also generic over it's Mutex to support all possible use cases.
I'm not convinced that it has to be in it's own crate though, because it is such a common requirement and shared-bus shows that it can be solved generically. Plus nobody would be forced to use what embedded-nal has to offer and can just as easily write their own StackManager. I think providing a sensible StackManager that can be used in most cases directly in embedded-nal would be convenient.

Having looked a little deeper into shared-bus, I think this is exactly what we would want for embedded-nal, too. I think all problems mentioned can be handled like that. It is also generic over it's Mutex to support all possible use cases.
I'm not convinced that it has to be in it's own crate though, because it is such a common requirement and shared-bus shows that it can be solved generically. Plus nobody would be forced to use what embedded-nal has to offer and can just as easily write their own StackManager. I think providing a sensible StackManager that can be used in most cases directly in embedded-nal would be convenient.

I'm not convinced that it has to be in it's own crate though, because it is such a common requirement and shared-bus shows that it can be solved generically. Plus nobody would be forced to use what embedded-nal has to offer and can just as easily write their own StackManager. I think providing a sensible StackManager that can be used in most cases directly in embedded-nal would be convenient.

As far as I'm concerned, that's out-of-scope for the discussion in this thread. We do need something like shared-bus if we want to share the stack, but whether or not that lives here can be discussed in a new issue (this one is pretty hefty as-is).

I'm not convinced that it has to be in it's own crate though, because it is such a common requirement and shared-bus shows that it can be solved generically. Plus nobody would be forced to use what embedded-nal has to offer and can just as easily write their own StackManager. I think providing a sensible StackManager that can be used in most cases directly in embedded-nal would be convenient.

As far as I'm concerned, that's out-of-scope for the discussion in this thread. We do need something like shared-bus if we want to share the stack, but whether or not that lives here can be discussed in a new issue (this one is pretty hefty as-is).

Am I understanding the consensus to be

Merge #42 and release 0.3.0
Open a new issue to discuss a shared-nal design

Am I understanding the consensus to be

Merge #42 and release 0.3.0
Open a new issue to discuss a shared-nal design


specify build folder for sveltekit app, change fallback filename for …

…static assets

will merge this to test the actions


Different pin configuration

I use a D1 mini V4 esp8266 which has a different pin name. I used a manual config before, but switched to the automated version, now I am looking to where this config needs to go. Some is already there like id, but added just for reference. Looking for the pin definition and possibly the update interval.
esp8266:
board: d1_mini
sensor:

platform: pulse_counter
pin: GPIO2 # D2
id: watermeter_pulse
name: "watermeter pulse"
state_class: measurement
update_interval: 5s
accuracy_decimals: 1
unit_of_measurement: "l/min"
icon: "mdi:water-pump"

Hello @laemen
esp8266 wemos d1 mini v4.
Does not have a 5v output at the same point as the v1 of the wemos d1 mini.
And u have 5v needed for the npn sensor.

Yes I’m on discord, but I solved it by changing the hw to GPIO4 which is the D2 pin.
The GPIO2 I used (=D4) also has the led connected, so I could visually see if the esp had proper input, but according to randomnerdtutorials the D4 pulled low could cause a failed boot.
For future reference having certain settings configurable through substitutions could help, but for now it’s solved.
S0tools is really easy, thanks for developing it!

I was actually wondering if we can change the pinout in a more simple way?
The reason being is pin D2 (gpio4) is also used for part of the communication pins for I2c and I have a Wemos DHT12 shield laying around which I wanted to use. This shield uses I2c and I can't change the i2c pins because it's a shield made for the wemos d1 mini.
So what I've done right now is copied the git code and pasted into my own (public) github repo and altered the code a bit so now it uses d3 (gpio0). For now I'm only using my own repo to assigning the correct pin for the watermeter. But this feels a bit obsolete. Isn't there an easier way to do this?

Hello kanuva,
Saidly i can not change it afterwards.
As i now of.
And i made a pcb design, with i send to people in Holland and Belgian.
And that one is also using the d2 and d5 ports.
The only way is what u already did. To fork it and change the Pinout.


Change --is_sensitive flag when creating projects

With the improved flow for sensitive projects, we will treat all projects as sensitive so I propose that we change the flag --is_sensitive to --non_sensitive and correspondingly reverse the meaning. --non_sensitive should be False by default.

Good point. At the moment all projects are handled in the same way though so I'll connect it to the changes I started.

Closed with #913 and #246


[Bug] Entire screen moves down on datasources page when you configure SSL

Add a datasource and choose SSL settings

I've assigned it to you @BhandarkarPawan. Please go ahead and fix this. Thank you!

@areyabhishek can i get it?

Hi @areyabhishek, can I please be assigned the issue? I'd like to have a crack at it. Thanks!

This isn't an issue anymore. Please close this.


"raise ValueError('First step cannot be zero.')" in the training stage

In the training stage with command:
python models-master/research/object_detection/train.py     --logtostderr
--pipeline_config_path=./data/faster_rcnn_resnet101_cars.config
--train_dir=./data/models/model/train
shows the error message: "raise ValueError('First step cannot be zero.')".
eval.py and tensorboard --logdir=./data/models/model/ works well.
I confirmed all the paths in generate_tfrecord.py and faster_rcnn_resnet101_cars.config are correct, and test.record and train.record was generated successfully(I don't know the content are correct, if there is a method to check them please let me know). Would you please let me know the possible situation may cause the problem? Thank you.

It looks like object detection was recently changed to add this error in https://github.com/tensorflow/models/pull/3656. Maybe try using the commit before that was merged, such as with:
git clone https://github.com/tensorflow/models
cd models
git checkout -b before-object-detection-changes 2913cb24ecb16ba955006b41072adce45c5a0f62

Hello,
Great you created the .records. You make the train and eval empty folders yourself. Then when you call train.py it will fill those folders with checkpoints and frozen points for models that you can use later.

Looking at https://github.com/tensorflow/models/issues/3794, maybe this is no longer valid?
https://github.com/Bellspringsteen/OurCamera/blob/796dbfbf2d73c2520db3da40838985f042da49dd/data/faster_rcnn_resnet101_cars.config#L92


Udpate Lucca and Donostia

[x] added new logo Donostia
[x] added new logo Lucca
[x] changed contact address Lucca
[x] changed physical address Donstia
[ ] changed location of Donostia on the map
I tried to change the location of Donostia on the map. The latitute and longitude in location.yml seem to point to the correct location, but the website still displays the incorrect location.
Any advice @Remi-Gau?
I think we can still merge these changes for now and figure out the map later

Any advice @Remi-Gau?

did you change those lines?
https://github.com/likeajumprope/global2023/blob/49eed297ab25227df6e6eda6f3b6549a93682b5f/data/locations.yaml#L311-L312

ha yeah updating several events lead to major merge conflicts... 🤦🏾
@likeajumprope let me known if you need help with this

omg haha. Will have a look

@Remi-Gau I don't think I have write access to the repo - hence I am not sure wether I can resolve this

ok pushing a fix now


[3.x] Create onready variables when dropping nodes and holding Ctrl

3.x version of #60708

Thanks!


fix: fix versionCross error

Signed-off-by: moweiwei<EMAIL_ADDRESS>
What type of PR is this?

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for reviewers:

Does this PR introduced a user-facing change?

Additional documentation, usage docs, etc.:

cherrypick-master

/lgtm
/approve

/cherrypick master

Codecov Report

Merging #314 (bc30634) into release-1.3 (2af56d5) will increase coverage by 1.15%.
The diff coverage is 100.00%.

@@               Coverage Diff               @@
##           release-1.3     #314      +/-   ##
===============================================
+ Coverage        46.20%   47.35%   +1.15%
===============================================
  Files                7        7
  Lines              606      606
  Branches           171      171
===============================================
+ Hits               280      287       +7
+ Misses             252      246       -6
+ Partials            74       73       -1

Impacted Files
Coverage Δ

src/utils/index.js
30.34% <100.00%> (+2.16%)
:arrow_up:


Broken link to BCP-003-01 README in nmos-testing

At https://specs.amwa.tv/nmos-testing/branches/master/docs/2.2.Usage-_Testing_BCP-003-01_TLS.html, link to the README is broken. Not sure whether the target file should be being rendered into specs.amwa.tv or whether the link should be still pointing to MarkDown file on GitHub, but either would be better! 😄
Or do we just refactor all of the user-facing info in that README into the above Usage file??

Resolved by AMWA-TV/nmos-testing#694


consistent nagiosformat output

Resolves #166

Codecov Report

Merging #172 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master     #172   +/-   ##
=======================================
  Coverage   85.06%   85.06%
=======================================
  Files          21       21
  Lines         743      743
=======================================
  Hits          632      632
  Misses        110      110
  Partials        1        1

Impacted Files
Coverage Δ

lib/pkg/nagiosformatters/nagiosformatters.go
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


Swift | 338. Counting Bits

File(s) Modified: [338-Counting-Bits.swift]
Language(s) Used: [swift]
Submission URL: [https://leetcode.com/submissions/detail/755956243/]

Thanks, @diss1993!


⚠ Bofrost.fr has degraded performance

In 138b851, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1725 ms

Resolved: Bofrost.fr performance has improved in dae15b9 after 9 minutes.


Add script for auto-testing

Description Add script for auto-testing.

Add tests/autotest.sh.
Add new arguments:

limit_train_batches / limit_val_batches / limit_test_batches: train/val/test part of the dataset for each epoch

I think your suggested change is good
On 2021-11-13 09:32, Eleven Liu wrote:

@ELEVEN1LIU commented on this pull request.
In tests/autotest.sh [1]:

+#   $3: Command template to run.
+#######################################
+run_test() {

data_name=$1
network_name=$2
command=$(echo "$3" | sed "s/%s/$data_name/" | sed
"s/%s/$network_name/")

declare -A results actual_results
prefix="${RESULT_DIR}/${data_name}${network_name}"

Get actual results in current branch

get_test_results $prefix "$command"
for i in "${!results[@]}"; do actual_results[$i]=${results[$i]};
done

Get expected results in master branch

git checkout master

Oh yes .. That would be a problem. Maybe we can terminate the program
if we find that they are in the tests/ dir? (like the one we have in
the Suggested change L80)
Because if user run this script under tests/, they would need to
modify the relative paths in the configuration files like
../data/MIMIC-50/train.txt.
--
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub [1], or unsubscribe
[2].
Triage notifications on the go with GitHub Mobile for iOS [3] or
Android [4]. [ { @.": "http://schema.org", @.":
"EmailMessage", "potentialAction": { @.": "ViewAction", "target":
"https://github.com/ASUS-AICS/LibMultiLabel/pull/115#discussion_r748663676",
"url":
"https://github.com/ASUS-AICS/LibMultiLabel/pull/115#discussion_r748663676",
"name": "View Pull Request" }, "description": "View this Pull Request
on GitHub", "publisher": { @.": "Organization", "name": "GitHub",
"url": "https://github.com" } } ]
Links:
[1]
https://github.com/ASUS-AICS/LibMultiLabel/pull/115#discussion_r748663676
[2]
https://github.com/notifications/unsubscribe-auth/ABI3BHU7J474VN4NIQRYGULULW52XANCNFSM5HXEXIVQ
[3]
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
[4]
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub


Possibility to inject manual time slot into the select during the order

Trying to stress the program I fond out is possible to inject a 'not valid' timeslot in the menu page.
I tried to add a check in the CartManager->validateOrderTime but I'm not able to do it..

Can you provide steps to reproduce please?


IOS radio buttons issue

Hi! I'm currently using the latest version 5.1 with cordova  and I have some problems with the radio buttons on IOS (12.4). The problem only comes on real Iphone device, in safari,other browsers and android platform working well, I can only select a radio value at first time after the page load, so if I select a value later cannot modify in the group. Also If my page loaded with selected value I cannot change the value. What could be the problem? Thanks.

Would be good to see live example

Update: If I use this example in my cordova app innside a F7 card component it also doesn't work:
https://www.w3schools.com/howto/tryit.asp?filename=tryhow_css_custom_radio
So maybe It is not only a Framework 7 problem. Do you have any idea why this is not work? After the first select I cannot modify my select.

Would be good to see live example

Closing due to inactivity and/or no responses from issue author


Deprecate update subcommand; introduce apply

This commit is a follow-up to the discussion in the ksonnet.next design
doc, in which users consistently expressed their preference that the
update command be called apply.

Approved this change as most of the work here is renaming update to apply, LGTM.


Update README

I made a few minor changes and one major change.
The major change being moving the installation instructions to lower on the page. My thought process was to help users get to the "How do I use this" portion of the guide faster.
Another thing to note is, I'm not sure if the cleanup liferay is the same as How to Uninstall. If not, can we add a How to Uninstall section?

hey ray, what if we have separate docs in a docs folder
docs/install.md
docs/build.md
docs/guide.md (this is the user guide that lawrence would like to see above the fold)
Then the main readme just have  3 links...
guide -> ...
install -> ...
build -> ..
what do you think?

Yeah that would be fine and it's what I've kind of been doing. I just think that until we have a docs site install is the number one issue.

Hey Lawrence, since this is now in "paused" mode, lets revisit this once we pick the effort back up (and we can create tickets in JIRA).  Thanks.


mysql got broken in docker image?

Hello,
if I do
docker run -it -p 3000:3000 --name=huginn  ghcr.io/huginn/huginn:45378efa7f3a77a8589378d5948a47544c60e2a7
I get a working huginn.
if I do
docker run -it -p 3000:3000 --name=huginn  ghcr.io/huginn/huginn:7ea2f6ffec3073e84dab65aa6e8cec236101ad06
I get lotsa errors regarding mysql
[...]
2023-06-26 13:07:24,089 INFO spawned: 'mysqld' with pid 372
2023-06-26 13:07:24,451 INFO exited: mysqld (exit status 1; not expected)
[...]
bootstrap stdout | Starting mysql server...
bootstrap stdout |
mysqld stdout | 2023-06-26T13:07:24.448501Z mysqld_safe Logging to '/var/log/mysql/error.log'.
mysqld stdout |
mysqld stderr | 2023-06-26T13:07:24.451042Z mysqld_safe The file /usr/sbin/mysqld
mysqld stderr | does not exist or is not executable. Please cd to the mysql installation
mysqld stderr | directory and restart this script from there as follows:
mysqld stderr | ./bin/mysqld_safe&
mysqld stderr | See http://dev.mysql.com/doc/mysql/en/mysqld-safe.html for more information
mysqld stderr |
mysqld stdout | 2023-06-26T13:07:25.547801Z mysqld_safe Logging to '/var/log/mysql/error.log'.
[...]
bash-4.2# docker exec -u root  -it huginn /bin/bash
root@2a84854c2e81:~# rm /var/log/mysql/error.log
root@2a84854c2e81:~# /usr/sbin/mysqld
root@2a84854c2e81:~# cat /var/log/mysql/error.log
2023-06-26T13:20:45.971573Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2023-06-26T13:20:45.974484Z 0 [Note] /usr/sbin/mysqld (mysqld 5.7.42) starting as process 1113 ...
2023-06-26T13:20:46.014757Z 0 [ERROR] Failed to create timer notify thread (errno= 1).
2023-06-26T13:20:46.014775Z 0 [ERROR] Failed to initialize timer component (errno 1).
2023-06-26T13:20:46.055955Z 0 [Note] InnoDB: PUNCH HOLE support available
2023-06-26T13:20:46.056032Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2023-06-26T13:20:46.056055Z 0 [Note] InnoDB: Uses event mutexes
2023-06-26T13:20:46.056059Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2023-06-26T13:20:46.056062Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.13
2023-06-26T13:20:46.056086Z 0 [Note] InnoDB: Using Linux native AIO
2023-06-26T13:20:46.059102Z 0 [Note] InnoDB: Number of pools: 1
2023-06-26T13:20:46.063297Z 0 [Note] InnoDB: Using CPU crc32 instructions
2023-06-26T13:20:46.064897Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2023-06-26T13:20:46.072327Z 0 [Note] InnoDB: Completed initialization of buffer pool
2023-06-26T13:20:46.073509Z 0 [ERROR] [FATAL] InnoDB: pthread_create returned 1
2023-06-26 13:20:46 0x7f4031e55740  InnoDB: Assertion failure in thread<PHONE_NUMBER>48160 in file ut0ut.cc line 921
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
13:20:46 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.
key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68199 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x3b)[0x557c25c76bab]
/usr/sbin/mysqld(handle_fatal_signal+0x377)[0x557c25501937]
/lib/x86_64-linux-gnu/libc.so.6(+0x42520)[0x7f4031e9c520]
/lib/x86_64-linux-gnu/libc.so.6(pthread_kill+0x12c)[0x7f4031ef0a7c]
/lib/x86_64-linux-gnu/libc.so.6(raise+0x16)[0x7f4031e9c476]
/lib/x86_64-linux-gnu/libc.so.6(abort+0xd3)[0x7f4031e827f3]
/usr/sbin/mysqld(+0x6adadc)[0x557c254d7adc]
/usr/sbin/mysqld(_ZN2ib5fatalD1Ev+0x66)[0x557c260274d6]
/usr/sbin/mysqld(_Z21os_thread_create_funcPFPvS_ES_Pm+0x257)[0x557c25f15d17]
/usr/sbin/mysqld(_Z34innobase_start_or_create_for_mysqlv+0x1c7a)[0x557c25fcec1a]
/usr/sbin/mysqld(+0x106da6d)[0x557c25e97a6d]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x4f)[0x557c2555649f]
/usr/sbin/mysqld(+0xc1e3d5)[0x557c25a483d5]
/usr/sbin/mysqld(_Z40plugin_register_builtin_and_init_core_sePiPPc+0x1e5)[0x557c25a4b8f5]
/usr/sbin/mysqld(+0x6d1990)[0x557c254fb990]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x79e)[0x557c254fd05e]
/lib/x86_64-linux-gnu/libc.so.6(+0x29d90)[0x7f4031e83d90]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80)[0x7f4031e83e40]
/usr/sbin/mysqld(_start+0x2a)[0x557c254f161a]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
root@2a84854c2e81:~#

I can not reproduce that, docker run -it -p 3000:3000 --name=huginn ghcr.io/huginn/huginn:7ea2f6ffec3073e84dab65aa6e8cec236101ad06 works without errors for me. Try using the latest image and/or on a different system. Maybe this is about the docker version or something else on the host system.

Whoops. Did not think that this could be an issue of the host system, have seen that on CentOS7/RHEL7 but cannot reproduce on RHEL8/Rocky9/ArchLinux.
So, clearly not a huginn (container) issue. Will look if that issue and maybe some workaround is known with MySQL or MariaDB.


Jeff Schaller: Watch reduxzone.com

Jeff Schaller requests the watch of the watch_keyword reduxzone\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

reduxzone\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Daniil in Charcoal HQ


system integration test node is connecting to itself

While writing a test with 8 total nodes, I've noticed this in the log:

node-0_1  | 2020-04-27T01:55:50.623040704Z 2020-04-27 01:55:50,621 Info [agora.network.NetworkManager] - Discovery reached. 8 peers connected.

And also:

node-0_1  | 2020-04-27T01:55:49.167923309Z 2020-04-27 01:55:49,137 Info [agora.network.NetworkManager] - Established new connection with peer: GBCVDA6EJDTC76WP552UX4NM7ENRX6AK4JW27GKVHVOCLRWOGQES3UPP

This is the node's key, so the node is connecting with itself. It probably has something to do with IP filtering (banning).
I've also noticed the nodes are using several different address types to connect to:
ode-0_1  | Establishing connection with http://<IP_ADDRESS>:7826...
node-0_1  | Establishing connection with http://node-0:2826...
node-0_1  | Establishing connection with http://node-6:8826...
node-0_1  | Establishing connection with http://node-1:3826...
node-0_1  | Establishing connection with http://<IP_ADDRESS>:8826...
node-0_1  | Establishing connection with http://<IP_ADDRESS>:3826...
node-0_1  | Establishing connection with http://node-5:7826...
node-0_1  | Failed to connect to <IP_ADDRESS>:6826: refused
node-0_1  | Failed to connect to <IP_ADDRESS>:4826: refused
node-0_1  | Failed to connect to <IP_ADDRESS>:5826: refused

So it tries connecting with node-*:*, <IP_ADDRESS>:*, and 172.21.0.*:*, the latter of which are probably IPs assigned by docker.

The nodes now ban themselves, so this issue has been solved.


Completely add 'help request' label to readme

Currently, the 'help request' label is only mentioned in line 7 of the readme, it is not specified in the label section of the readme

@menor which section would you add that to? I guess it belongs in the workflow section.

Yes, with the yellow ones it makes sense

Was fixed by #43