drivers: pwm: Add MAX32xxx PWM driver

This PR adds PWM driver for ADI MAX32xxx series microcontrollers. Test overlays for "pwm_api" are provided for each board.

Twister failure will be resolved, when this PR will be merged.

Twister failure will be resolved, when this PR will be merged.

Please follow https://docs.zephyrproject.org/latest/develop/modules.html#process-for-submitting-changes-to-existing-modules to verify the HAL change before merging it.

Twister failure will be resolved, when this PR will be merged.

Please follow https://docs.zephyrproject.org/latest/develop/modules.html#process-for-submitting-changes-to-existing-modules to verify the HAL change before merging it.

Update in hal_adi is pointed out in manifest.

Need to rebase

Need to rebase

Done

Shall be merged after #76593 being merged, due to similar commits.

Might need to add DNM label if this is still the case.

Please check commit messages after rebase, some of them need to be updated to demonstrate addition,
Like https://github.com/zephyrproject-rtos/zephyr/pull/77002/commits/15478af7afb78dadeb9d921de4c9ea595f4da57a
commit:

dts: arm: adi: Add Timer instance to MAX32655
Add timer and pwm yml files
TIMER0/1/2/3 support pwm, LPTIMER0/1 not.
LPTIMER0/1 provide 16bits out that not meet pwm requirement.

Should be updated as "Add PWM sub node" due to timer node and related .yml file already there, the commit adds PWM sub node.

Please check commit messages after rebase, some of them need to be updated to demonstrate addition, Like 15478af commit:

dts: arm: adi: Add Timer instance to MAX32655
Add timer and pwm yml files
TIMER0/1/2/3 support pwm, LPTIMER0/1 not.
LPTIMER0/1 provide 16bits out that not meet pwm requirement.

Should be updated as "Add PWM sub node" due to timer node and related .yml file already there, the commit adds PWM sub node.

Done

@ttmut, can you revisit this PR


org-journal-file-header doesn't seem to work

Trying out org-journal for the first time - I've set org-journal-file-header but it seems to always be ignored - it only inserts the default title. Here's what my config looks like:
  (setq org-journal-file-type 'yearly)
  (setq org-journal-file-format "%Y.org")
  (setq org-journal-enable-agenda-integration t)
  (setq org-journal-date-format "%e %b %Y (%A)")
  (setq org-journal-file-header "#+TITLE: Journal\n#+CATEGORY: journal\n#+STARTUP: folded")
  (setq org-journal-time-format "")
  (setq org-journal-find-file 'find-file)

Am I missing something?

Hey @jsravn!
If I use your config:
(use-package org-journal
    :load-path "~/Developing/third_party/org-journal"
    :custom:
    (org-journal-file-format "%Y.org")
    :config
    (setq org-journal-file-type 'yearly)
    (setq org-journal-enable-agenda-integration t)
    (setq org-journal-date-format "%e %b %Y (%A)")
    (setq org-journal-file-header "#+TITLE: Journal\n#+CATEGORY: journal\n#+STARTUP: folded")
    (setq org-journal-time-format "")
    (setq org-journal-find-file 'find-file))

I end up with the following journal file when I create the first entry (C-c C-j).
#+TITLE: Journal
#+CATEGORY: journal
#+STARTUP: folded
* 18 Feb 2020 (Tuesday)
:PROPERTIES:
:CREATED:  20200218
:END:
**

Not quite sure what could be wrong.
The only thing wrong with your setup is org-journal-file-format, either you set it before loading org-journal, use the customize interface or any of the customize function, otherwise auto-mode-alist  and org-journal-file-pattern will not get updated.

Hmm, I wonder what's going on. I tried duplicating your config, but it still doesn't insert the header:
(use-package! org-journal
  :custom
  (org-journal-file-format "%Y.org")
  (org-journal-dir org-directory)
  :config
  (setq org-journal-file-type 'yearly)
  (setq org-journal-enable-agenda-integration t)
  (setq org-journal-date-format "%e %b %Y (%A)")
  (setq org-journal-file-header "#+TITLE: Journal\n#+CATEGORY: journal\n#+STARTUP: folded")
  (setq org-journal-time-format "")
  (setq org-journal-find-file 'find-file)
  )

It could be an issue w/ something else, I will try to dig. Thank you for your help!

Stepping through it with edebug, something is inserting "#+TITLE: 2020" when the org file is created, which then causes org-journal to not insert its own header (it checks if the buffer is empty which fails).

Okay, figured it out - using doom-emacs with file-templates enabled, it was adding the header. Removed and it works. Thanks!

Thank for letting us know where the issue was.

Okay, figured it out - using doom-emacs with file-templates enabled, it was adding the header. Removed and it works. Thanks!

Thanks for the solution! Spent hours trying to pinpoint this issue. Would be ideal if this is included in the documentation :)


snownet: investigate what happens if we change socket based on WG activity re: invalidation of candidates

When updating a socket via ICE, we invalidate all other candidates that are equal or worse in priority.
We also update the socket on wireguard activity.
Can those states diverge? Needs to be investigated. Maybe we can remove the latter (but accept the WG packet anyway, just don't update where we send from?).
We should always treat ICE as the source of truth for our socket.

I looked into this today and ran into some issues. You can see the failing test in https://github.com/firezone/firezone/actions/runs/8682303755/job/23806698516?pr=4615.
What ends up happening is that the test times out because we don't switch sockets fast enough. From ICE's point of view, the old socket is still active and we'd only switch over after the ICE timeout. I do believe that this is an upstream bug though. As the controlled agent (i.e. the gateway), we should just follow whatever the client nominates and not wait for the ICE timeout of the old candidate pair before switching over.

Working on #4615 made it more obvious that the idea of updating the socket from WG activity was a bad one. We should treat ICE as our source of truth and bend it such that it works for our usecase.
This "feature" was masking the above bug. I am not sure it is related to some of the odd behaviour we have been seeing but diverging state machines certainly sound like they could cause weird behaviour!

Upstream fix is here: https://github.com/algesten/str0m/pull/496
With the above applied, CI in https://github.com/firezone/firezone/pull/4615 is green.

Upstream fix is here: algesten/str0m#496

Damn, it is not as easy unfortunately. I think this means that our current strategy of not doing an ICE restart and instead keep trickling candidates is a bit flawed. ICE restart is the event that both parties use to figure out that they are no longer using a certain socket. But a full on ICE restart is way to destructive because it also resets the credentials and invalidates all candidates.

it also resets the credentials and invalidates all candidates

Invalidates candidates seems appropriate, though right? If we're actually roaming networks or changing our default interfaces, then I would expect the Direct candidates to fail, but Relayed candidates should stick around?
If we're calling reconnect too eagerly that would be a source of woe

it also resets the credentials and invalidates all candidates

Invalidates candidates seems appropriate, though right?

Yes and no. If we invalidate all candidates in one go, then the connection "fails" and we clean up associated state like DNS resolutions. We could catch that by tracking more state on whether we just issued an ICE restart. Possible but makes things a bit more complicated.

If we're actually roaming networks or changing our default interfaces, then I would expect the Direct candidates to no longer be valid because NAT has likely changed, but Relayed candidates should stick around?

Yes, that is correct. Also the relay candidates are dead because they are identified by the 3-tuple.

If we're calling reconnect too eagerly that would be a source of woe

That is the issue. We would have to be more careful in when we are calling this because it would trigger communication with the portal each time.

#4634 is a pre-requisite for this. We need to let the other party know that we've invalidated a candidate so that both sides can switch over to a new one without having to wait for the ICE timeout.


Add gfortran version 12 and remove 9 and 10.

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

I added myself as a maintainer to go with gfortran_impl_osx-64-feedstock.

@isuruf At this point I don't understand what is going wrong with the linux_64_cross_target builds, or even how this is supposed to work or which direction they're supposed to go.  Hopefully I didn't mess something up with gfortran_impl?

What does -dumpspecs show for the compilers? That looks like it might be empty or something?
I'm just guessing here...

I don't know what that means.

Oh I just mean we can add gcc -dumpspecs in the CI job bash script and see what gives?
The code says the specfile is missing and I am curious if this might help us find more info on that?

This is in the tests, not the build, right?  I am basically confused about what it's supposed to be doing... I guess this is building on macos to target linux?

Something like that. I always forget host vs target vs build vs whatever here.

Okay, in #48 which I did basically nothing it's the same failures and even for 9.5 which wasn't touched by the recent PR.  And I also note that the impl package for the linux cross build seems to be coming from ctng feedstock, and not from the gfortran_impl_osx feedstock.  Is this even something that we're supposed to be building?  Is it used by anything?

Which package comes from ctng?

This warning is likely unrelated but not ideal:
The install/build script(s) for gfortran_osx-64 deleted the following files (from dependencies) from the prefix:
['x86_64-conda-linux-gnu/lib/libgfortran.so', 'x86_64-conda-linux-gnu/lib/libgfortran.so.5', 'x86_64-conda-linux-gnu/lib/libgfortran.so.5.0.0']
This will cause the post-link checks to mis-report. Please try not to delete and files (DSOs in particular) from the prefix
WARNING:conda_build.build:The install/build script(s) for gfortran_osx-64 deleted the following files (from dependencies) from the prefix:
['x86_64-conda-linux-gnu/lib/libgfortran.so', 'x86_64-conda-linux-gnu/lib/libgfortran.so.5', 'x86_64-conda-linux-gnu/lib/libgfortran.so.5.0.0']
This will cause the post-link checks to mis-report. Please try not to delete and files (DSOs in particular) from the prefix
number of files: 9

FWIW, this bug must be in the upstream compiler builds, not here. This package is a simple wrapper to set env vars and such.

So in the build log you see this being installed:
    gfortran_impl_linux-64:   12.2.0-h55be85b_19        conda-forge

And that build (19) is from https://github.com/conda-forge/ctng-compilers-feedstock/blob/main/recipe/meta.yaml (and also according to the conda forge package searcher thingy).

Ohhh that's fine. We never made a new feedstock but ctng is not used there. We build from the upstream source.

Okay, I'm at a loss as to how this ever worked.  The problem as far as I can tell is that running gfortran needs $PREFIX/lib/libgfortran.spec to be there.  And this is installed explicitly in the gfortran_impl_osx-64 installation of gfortran_impl_{{ cross_target_platform }} here: https://github.com/conda-forge/gfortran_impl_osx-64-feedstock/blob/main/recipe/meta.yaml#L163
But for the linux-64 version this gets all messed up.  Because gfortran_impl_linux-64 is defined as an output of both gfortran_impl_osx-64-feedstock and ctng-compilers-feedstock.  And the ctng-compilers-feedstock does not seem to install $PREFIX/lib/libgfortran.spec.  And I don't know what the conda forge system is supposed to do when two feedstocks define the same output package (this seems bad!) but right now it ends up finding the one from ctng-compilers-feedstock which doesn't have the spec file in the right location.
I think this is a bigger problem than I know how to solve, or even what the solution is supposed to look like.
I also don't know why we're building these linux packages in osx-64 land anyway.

The packages are for cross compiling builds. I agree we don't usually use them but they are built. It seems to me that the solution is to put the spec file in the right spot in ctng compilers.

Isn't it a problem that two different feedstocks are producing packages with the same name?

That's not necessarily an issue as long as the builds are compatible.

Okay, so more digging, and I may be wrong.  The tests are run on linux, and are installing gfortran_impl_osx-64.  Which when installed on macos has lib/libgfortran.spec (as a symlink).  But when installed on linux it doesn't?  I'm guessing something is being stripped, and maybe this is a new feature of conda?  (Because this ran in august 2022, but not today, so what else would have changed?).

Idk.

@isuruf @beckermr I've done further digging and there just seems to be some strange incompatibility with our linux gfortran build and the osx gfortran build that is triggering what seems to be a bug in gcc (that it tries to read a directory as a spec file in some instances when it's scanning?).  This is currently the case for any existing installation; I'm not sure how/if it ever worked.  Obviously the ability of cross compiling fortran code from linux to osx-64 or osx-arm64 isn't something that people have been making much use of (or else there would be complaints) so I've turned it off on this PR.
Please let me know if there are any problems with this.

I do use the linux-64 to osx-64/osx-arm64 cross compiling and the current environment I have has gfortran_impl_osx-arm64   11.3.0  he99ca6a_27 in it and it works. *_28 and  *_29 does not work anymore. I'll have a look soon

Interesting.  27 to 28 was this PR https://github.com/conda-forge/gfortran_impl_osx-64-feedstock/pull/64/files which added what looks like an unrelated patch.  But the c compiler versions were updated, and then the cross-run test had to be removed (!!) https://github.com/conda-forge/gfortran_impl_osx-64-feedstock/blob/main/recipe/gfortran_test.sh#L5-L6 which looks like the same problem we're having here.  Very curious.

We should mark any broken packages as such. @isuruf @erykoff I'm happy to make the PR but IDK which ones exactly we need to remove.

The other notable thing is that in the 27 build (this is linux_64/gfortran_impl_osx-64-11.3.0-hacec75c_27 which works) then the lib/ directory only has gcc but in the 28 build (linux_64/gfortran_impl_osx-64-11.3.0-h7451c75_28) and the 29 build (linux_64/gfortran_impl_osx-64-11.3.0-h1f927f5_29) then the lib/ directory has the libgfortran.a, libgomp.a, and the links to libgfortran.spec and libgomp.spec.  Maybe these aren't supposed to be there for the cross-packages?  Though I don't see what changed to put them there.
I assume the same problems for the other non-11.3.0 versions with those builds.

https://github.com/gcc-mirror/gcc/blob/master/gcc/gcc.cc#L8334-L8335 seems to not strcat specs in there whereas *_27 does

Looks like an issue with conda binary prefix modification. Installing the compiler into a prefix with exactly 255 characters works.

Marking https://github.com/gcc-mirror/gcc/blob/553ff2524f412be4e02e2ffb1a0a3dc3e2280742/gcc/gcc.cc#L1617-L1620 as volatile should probably fix it

@isuruf Thanks to your fix at https://github.com/conda-forge/gfortran_impl_osx-64-feedstock/pull/69 this now builds and passes tests on all platforms.  Thanks so much for your help figuring out what was going wrong!


Redundant Masks?

The ang parameter in rounding_angled_edge_mask() defaults to 90°.  Doesn't that make rounding_edge_mask() redundant?
Should rounding_edge_mask() be dropped and rounding_angled_edge_mask() be renamed?
Same for rounding_corner_mask().

This is a reasonable idea.

The actual shapes produced are different.  Does it matter?  For some reason rounding_angled_edge_mask makes a shape that rounds on two sides.
This mask shape might also be used to create a fillet (that is, added to the model instead of removed) in which case the double-sided one would be bad.

For the rounding corner masks, the orientation is different as well.
In example 2, rounding_corner_mask() is used with corner_mask().  To do the same with rounding_angled_corner_mask() you need to add an xrot(180) between the two.

So does this mean we should leave things alone instead of merging the masks?


Can I set an environment variable from an argument passed to my script?

I want to use an argument passed to my npm script as part of the path that is given to a command. Like this:
yarn my-script en-GB
Where en-GB is a locale-id that I want to use as part of the path in my script, e.g. "./intl/translation/en-GB". In the example script below, ARG[0] would resolve to en-GB.
"my-script": "cross-env THEVAR=ARG[0] other-command \"./intl/translation/$THEVAR\""

If I can't do this with cross-env is there another package (or tactic) that comes to mind? Or, if you think there is any value to this perhaps you can make this a feature request or accept a pull request for it..although I'm not sure if my proposed syntax is any good.

It looks like cross-env doesn't like being changed while it is running. Funny that. So, let's not update cross-env as well:
    if (file.indexOf('cross-env') >= 0) {
      return;
    }


Chat-Enhancement: hidden messages

Hello,
As the GM I would like to enter privates notes to my log. But if the "hidden message/roll" button is checked in the list of role types, the message displayed in the chat is still public.

I'll add a toggle to turn off the chat messages. I can look at the Roll Types, but because the message is not a roll, the best I can do is make a Whisper to yourself if anything but "Public" is selected.

@flamewave000 whipser is good!


[TOPI] Treat undefined elements as constants in Array

#7018 introduces the dynamic support to strided_slice. However, in the following case, the static workload will be treat as a dynamic:
cpp.strided_slice(weight, begin=[0, 0, 0, 0], end=[None, None, filter_h, filter_w])

This is because the None in end is not IntImmNode and will be judged as a non-constant array. This PR changes the behavior by ignoring the undefined elements.
In addition, the dynamic path also assumes strides array is always given, but it will be initialized to array of 1 after this path. Since I'm not sure what's the right behavior, I only add a checker to error out.
cc @kevinthesun @mbrookhart

I didn't know we could use None. Is there a way to test it in the unit tests?
I'd like to see a unit test, but otherwise it looks good.

I didn't know we could use None. Is there a way to test it in the unit tests?
I'd like to see a unit test, but otherwise it looks good.

I didn't know we could use None. Is there a way to test it in the unit tests?
I'd like to see a unit test, but otherwise it looks good.

It is supported here: https://github.com/apache/tvm/blob/main/include/tvm/topi/transform.h#L658 (so does begin). A test case is also added.

I didn't know we could use None. Is there a way to test it in the unit tests?
I'd like to see a unit test, but otherwise it looks good.

It is supported here: https://github.com/apache/tvm/blob/main/include/tvm/topi/transform.h#L658 (so does begin). A test case is also added.

Thanks @mbrookhart @yzhliu

Thanks @mbrookhart @yzhliu


Obsmon v4.1.0

Hello,
I have just installed version 4.1.0 and this is what I get when I draw a coloured map. It is great you can choose from different colour palletes but in the new arrange the map is very small.
Might be something related with my local installation? Is it the way it should be?
Thank you!
Gema

Hi @lagemuchi ,
The default initial size needed to be reduced to make room for the extra controls. The actual size of the map, however, depends on many factors including the size of your own screen. You can try resizing the screen you are using to get a larger picture.
Mind also that the colorbar can be dragged using the mouse, and this sometimes causes the plot to be resized, which may help in some occasions.
I hope this helps.

Ok. Thanks, Paulo
Gema

Hi @lagemuchi[1] ,
The default initial size needed to be reduced to make room for the
extra controls. The actual size of the map, however, depends on many
factors including the size of your own screen. You can try resizing
the screen you are using to get a larger picture.
Mind also that the colorbar can be dragged using the mouse, and
this sometimes causes the plot to be resized, which may help in some
occasions.
I hope this helps.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub[2], or unsubscribe[3].
Triage notifications on the go with GitHub Mobile for iOS[4] or Android[5].
[ { @.": "http://schema.org", @.": "EmailMessage",
"potentialAction": { @.": "ViewAction", "target":
"https://github.com/Hirlam/obsmon/issues/9#issuecomment-892686141",
"url":
"https://github.com/Hirlam/obsmon/issues/9#issuecomment-892686141",
"name": "View Issue" }, "description": "View this Issue on GitHub",
"publisher": { @.": "Organization", "name": "GitHub", "url":
"https://github.com" } } ]

Vínculos:
[1] https://github.com/lagemuchi
[2] https://github.com/Hirlam/obsmon/issues/9#issuecomment-892686141
[3]
https://github.com/notifications/unsubscribe-auth/ATBTHM5P2BNNXUW3VJWDCVLT3FCEBANCNFSM5BRFIVXA
[4]
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
[5]
https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email

You're welcome :)

Hi again @lagemuchi ,
Just FYI, I have now made that new menu collapsible. This should also help making more space for the plot.
The changes are in the devel branch at the moment but will make their way into master soon.
Cheers,
Paulo.

Thank you Paulo ;-)
Gema
Paulo V C Medeiros @.***> escribió:

Hi again @lagemuchi[1] ,
Just FYI, I have now made that new menu collapsible. This should
also help making more space for the plot.
The changes are in the devel branch at the moment but will make
their way into master soon.
Cheers,
Paulo.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub[2], or unsubscribe[3].
Triage notifications on the go with GitHub Mobile for iOS[4] or Android[5].
[ { @.": "http://schema.org", @.": "EmailMessage",
"potentialAction": { @.": "ViewAction", "target":
"https://github.com/Hirlam/obsmon/issues/9#issuecomment-898342607",
"url":
"https://github.com/Hirlam/obsmon/issues/9#issuecomment-898342607",
"name": "View Issue" }, "description": "View this Issue on GitHub",
"publisher": { @.": "Organization", "name": "GitHub", "url":
"https://github.com" } } ]

Vínculos:
[1] https://github.com/lagemuchi
[2] https://github.com/Hirlam/obsmon/issues/9#issuecomment-898342607
[3]
https://github.com/notifications/unsubscribe-auth/ATBTHM6C7Z3EPPU6SKO7PCDT4TUMZANCNFSM5BRFIVXA
[4]
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
[5]
https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email


Is this project still alive ?

Is this project still alive ?

Not anymore! It evolved into separate projects:
If you're looking for a Lua-like language that compiles to C, check Pallene!
If you're looking for a statically-typed superset of Lua a la TypeScript, check Teal!


Explicitly wait for server unbind before actor system termination

By at least waiting for the unbind request to complete we try and ensure that the server has received the Unbind request before the actor system sends a Terminated message. Thus we should avoid the underlying race condition.
fixes #140

@adamw I was wondering when the 0.13.11 will be published please? Maven central/Sonatype still show only 0.13.10 at the moment.

Sorry, sth is wrong with the release process. Should be fixed soon :)


fix filename routing of the builtin php server

I had a problem with the php buildin webserver
to find correct routes when having a filename.
reproduce: browse to the example and type:

localhost:8080/tom => Hello tom! ( SCRIPT_NAME = /index.php )
localhost:8080/tom.doe =>   ( SCRIPT_NAME = /tom.doe )
localhost:8080/tom.doe/wtf =>   (is also handled, no 404) ( SCRIPT_NAME = /tom.doe/wtf )

setting $_SERVER['SCRIPT_NAME'] = '/index.php' solves this issue

This doesn't work for me on PHP 7.1, probably due to PHP bug 61286.

I don't think that dot is the problem. In fact routes any routes except base route don't work for me and this PR fixes it.
More general fix could be
if (php_sapi_name() === 'cli-server') {
    $_SERVER['SCRIPT_NAME'] = basename($_SERVER['SCRIPT_FILENAME']);
}


Join Us Page

https://bankless-new.netlify.app/new-members
Design: https://i.imgur.com/iPDEtzF.png

Link the Join now button to Discord.

Link the Join now button to Discord.

Please provide the link url  so that I can add it to join now button


Added support for stream I/O. Bumped version

Please don't merge, this doesn't seem to work yet with non-seekable streams...

Need to redo this

Thanks for making interest in project.


Requiring 'rake/file_list' in gemspec breaks the Gemfile if rake is not already installed

Summary
#179 added use of rake/file_list which breaks the Gemfile via the use of bundle install/update if rake is not already installed. This is especially problematic on CI systems where we always start from a clean state.
@utkarsh2102 Could you please take a look at this when you have time? I could attempt to fix this, but don't want to inadvertently break your Debian specific pipeline. Thank you!
CI Failure
https://travis-ci.org/github/titusfortner/webdrivers/builds/727632931
$ bundle install --jobs=3 --retry=3 --path=${BUNDLE_PATH:-vendor/bundle}

[!] There was an error parsing `Gemfile`:
[!] There was an error while loading `webdrivers.gemspec`: cannot load such file -- rake/file_list
Does it try to require a relative path? That's been removed in Ruby 1.9. Bundler cannot continue.
 #  from /home/travis/build/titusfortner/webdrivers/webdrivers.gemspec:6
 #  -------------------------------------------
 #  require 'webdrivers/version'
 >  require 'rake/file_list'
 #
 #  -------------------------------------------
. Bundler cannot continue.
 #  from /home/travis/build/titusfortner/webdrivers/Gemfile:6
 #  -------------------------------------------
 #  # Specify your gem's dependencies in webdrivers.gemspec
 >  gemspec
 #  -------------------------------------------

No errors on Appveyor (example) because it has rake v12.0 pre-installed as part of the CI image.
Workaround
Install rake 12.x prior to bundle install/update - gem install rake -v 12.3.3

Hey,
I'm sorry for having caused this! 😪
The best fix, in my opinion, is to use Dir over Rake::FileList. The should omit the need of using our installing Rake in the first place.
What do you think?

Giving more thoughts into this, there are a few options here:

The straightforward one here is to add gem install rake thingy so the CI works fine (though I am not sure why it doesn't in the first place!).
The other way is the one I mentioned above^. Using Dir over Rake::FileList is the simplest thing in my opinion. But that's your call.
Another way to fix this is to have a Manifest.txt file, explicitly listing the files that you want to ship and that file will be read by s.files. That's a bit of an overkill but for some, it works best.

From the Debian side, all we care about is to not use git in the gemspec file. You may circumvent that by using Dir or Dir.glob (purely Ruby alternatives) or Rake::FileList (since rake is almost always available to use!) or any other way that doesn't use git! :smile:

@utkarsh2102 Thanks for the prompt response! I personally like option 2 - using Dir to keep things simple. Would you have time to put in a PR for this? If not then I'll try to make time this week or the next.

Hi @kapoorlakshya,

Thanks for the prompt response! I personally like option 2 - using Dir to keep things simple. Would you have time to put in a PR for this? If not then I'll try to make time this week or the next.

Opened PR #185 for this^

Closed by #185


Syntax folding for diff/patch files

The syntax file for the filetype "diff" (not the mode) does currently not support folding of hunks/files. Below a draft for adding this functionality.
The folding is not 100% accurate as the "diff" filetype does cover lots of different flavours of diff or patch syntax.
The implementation below works for unified format (and thus for derivative of it, e.g. gitdiff, hgdiff, ...)
The implementation adds two syntax-item (diffFoldFile, diffFoldHunk) whose sole purpose is to provide folding. I would have liked to reuse the diffFile syntax item as start-pattern for the region, however, Vim does not seem to support this. Therefore, I combined the most often used one into a new regex.
This regex is not perfect, e.g. it does not contain the "^Only..." parts which are therefore folded as part of a previous hunk (if any) and not as an individual file. Adding this seems like a mess, especially because there are also a tone of translations to consider. Thus, so far only unified syntax (and a little more) is supported.
During testing I experienced the problem that in a file-fold only included the first hunk and that further hunks were not folded at all. I solved this problem with trail-and-error and derived at syncing. There are two sync way:

syntax sync minlines=2 maxlines=2 (and any derivatives of it with minlines>=2 works and maxlines can be ommitted)
syntax sync match diffFoldFileSync grouphere diffFoldFile '^\(...\) (same regex as for diffFoldFile)

I don't understand any of it, except that I can see that they work. I believe "sync match" is saner as it will find the corresponding file-fold. If someone wants to shed some light on it, I'll be happy to learn something new.
It would be nice to bring this into a state such that this functionality (although not perfect for all diff flavours) can make it into the runtime files. Thanks.
P.S.: For anybody stumbling upon this in the future. Instead of using syntax folding, 'foldexpr' can be used (which has similar flaws when it comes to non unified formats):
" Extracted form https://github.com/sgeb/vim-diff-fold
function! DiffFoldLevel()
    let l:line=getline(v:lnum)

    if l:line =~# '^\(diff\|Index\)'     " file
        return '>1'
    elseif l:line =~# '^\(@@\|\d\)'  " hunk
        return '>2'
    elseif l:line =~# '^\*\*\* \d\+,\d\+ \*\*\*\*$' " context: file1
        return '>2'
    elseif l:line =~# '^--- \d\+,\d\+ ----$'     " context: file2
        return '>2'
    else
        return '='
    endif
endfunction

augroup ft_diff
    au!
    autocmd FileType diff setlocal foldmethod=expr
    autocmd FileType diff setlocal foldexpr=DiffFoldLevel()
augroup END

I'll await comments.  Perhaps some improvements can be made?

FWIW, this is the ftplugin I've been using for years to get diff folding:
function! DiffFoldLevel(lineno)
  let line = getline(a:lineno)
  if line =~# '^Index:'
    return '>1'
  elseif line =~# '^index '
  elseif line =~# '^===' || line =~ '^RCS file: ' || line =~ '^retrieving revision '
    let lvl = foldlevel(a:lineno - 1)
    return lvl >= 0 ? lvl : '='
  elseif line =~# '^diff'
    return getline(a:lineno - 1) =~ '^retrieving revision ' ? '=' : '>1'
  elseif line =~# '^--- ' && getline(a:lineno - 1) !~# '^diff\|^===\|^index'
    return '>1'
  elseif line =~# '^@'
    return '>2'
  elseif line =~# '^[- +\\]'
    let lvl = foldlevel(a:lineno - 1)
    return lvl >= 0 ? lvl : '='
  else
    return '0'
  endif
endf

setlocal foldmethod=expr
setlocal foldexpr=DiffFoldLevel(v:lnum)

Thanks @jamessan for sharing an extended version of the foldexpr function.
I'd like to point out the following difference: Adding folding support via the syntax file instead of the filetype plugin, not only provides folding support for *.diff and *.patch files but also to all filetypes which include the diff syntax, e.g. gitcommit.


Small R code improvements from VSCode linting warnings

Hi @venexia
(out of guilt about the previous typo) I went through all the VSCode R linting output for the .R files.
It started with 0 (linting) errors, 27 (linting) warnings, and alot of (linting) infos (see this in bottom lefthand corner of VSCode window).

After these commits there are 0 (linting) errors, 15 (linting) warnings, and alot of (linting) infos (I think all remaining linting warnings are spurious).

I think none of these changes actually affect output of previously run jobs, but the new code is a bit more robust at least.
The most useful find was that in fn-fit_model.R on line 84 covariate_other was being used - but that was input into the covariates argument in that function - there was no error because covariate_other was defined in the global environment, so the previous code picked it up anyway, but safer to use the argument you specified I guess.

Thanks @remlapmot. No guilt PRs were necessary but I appreciate these changes to make the code more robust!


Block until objects have been created and are ready

In some parts of the controller, during the reconciliation logic, we check for existing objects, such as deployments. A timing condition might cause the check for the state of a object to fail, as the object might not have been created yet. Ideally, we would wait until the object has been created and available, instead of just available.
https://github.com/jaegertracing/jaeger-operator/blob/898bb4312ff74f829f01b1c1c0440a722aaf90bc/pkg/controller/jaeger/deployment.go#L48-L52
https://github.com/jaegertracing/jaeger-operator/blob/898bb4312ff74f829f01b1c1c0440a722aaf90bc/pkg/controller/jaeger/deployment.go#L74-L76

In ES we wait for exact number of available replicas to be sure ES cluster is in ready state.
https://github.com/jaegertracing/jaeger-operator/blob/898bb4312ff74f829f01b1c1c0440a722aaf90bc/pkg/controller/jaeger/elasticsearch.go#L68

True, but it will fail before that in case there are no objects matching the List criteria:
https://github.com/jaegertracing/jaeger-operator/blob/898bb4312ff74f829f01b1c1c0440a722aaf90bc/pkg/controller/jaeger/elasticsearch.go#L64

Basically, we need to check if the error is a "not found" and ignore the failure (return true, nil)
The IsNotFound function can be used for that:
https://github.com/jaegertracing/jaeger-operator/blob/898bb4312ff74f829f01b1c1c0440a722aaf90bc/pkg/controller/jaeger/jaeger_controller.go#L84

True, but it will fail before that in case there are no objects matching the List criteria:

In general case yes. In ES case I know the expected number of ES nodes so I can loop until they are not there.

One example of this situation can be seen in the logs recorded for #279, especially this snippet here:
DEBU[0075] creating deployment                           deployment=simple-prod-query instance=simple-prod namespace=default
DEBU[0075] Deployment doesn't exist yet.                 name=simple-prod-query namespace=defaul

The deployment was passed to the create method but wasn't yet available via the get operation.


Should we maintain a local database?

Currently we do not populate a local database when files are downloaded. Once to_dataset_dict() is called, we query the index node for file information and use the directory_format_template_ and other information in the response to build up a local path. Essentially we are using the remote index as our database which is only useful for querying if a specific file is present.
I chose this originally because no database means nothing to keep clean, nothing to maintain, no additional complexity. As downloads fail or are canceled by the user, the database could become corrupt and we simply avoid this by not having one. However, I am now experiencing some drawbacks. Having the local database could:

Speed up some aspects of querying. This is particularly painful when you are working on an analysis and, since your search is also how you load data into a container, you hit the index node each time just to find out where you local file is located. For big queries it takes a non trivial amount of time. This could be helped if/when the federation moves to the ElasticSearch index.
We also hit the search when we add cell measures. The local database could store where the local cell measures are located to make this fast to recall.
You could also hit a situation where you cannot find a file on your system because either the index node where its information is logged is not responding, or not part of your current ESGFCatalog configuration.
We could store more of the file information in the database to make some operations quick: looking up citation information, checksums, path to nearest cell measures, etc.

It strikes me now that the additional complexity is worth the added benefit. It is really not acceptable that you cannot find a file that exists locally on your system. So then the question is: which format makes the most sense?

esgpull uses a SQLite database. I have some experience with this but it would be a small learning curve. It seems that pandas even has a read_sql() function which would make integration with intake-esgf easy.
Could we just use pandas saved in feather format? See this article.

Probably SQLite is a better choice given that we will be writing to the database in parallel.  @mgrover1 thoughts?

I like the idea of maintaining a SQLite database! I think this offers the features we need and satisfies the requirements here.

I have restructured the queries to get file information and they may not take nearly as long as before. Hold off on this until we see how much of a pain point it remains.

You could also consider just using a cache instead of a full blown database, e.g. requests_cache is used by esgf-pyclient to cache searches. That also speeds up the searches that go over the internet, but takes very little effort to maintain and if it becomes corrupted for some reason it can just be deleted.

Thanks for this suggestion! Will take a look.


Made sure my save system works with the latest Fungus

Hey CGT, thanks for the PR. I see you have split your additions out into their own folder.
Did you intend for this to become part of core fungus? Or did you want it bundled with fungus but as an add on?

I intend for the save system to become part of core Fungus, yes. And if the powers that be would like to make it so, I suggest renaming the folder; it'd no longer be just my save system by that point xD

Cool. Is that work something you are looking at doing or are you wanting to hand this off?

 Of course, if anyone finds any significant bugs in it, I'd like to be alerted so I can help fix said bugs.

OK, I'll pull this into a feature branch and make a new PR from there to do the changes and further testing on.
How would you like to be alerted? and thanks for the contribution.

Understood, thanks. And I'd like to be alerted through email

Consolidation of this and further improvements to save system ongoing here #795


pull request for e2e test at 11/15/2016 14:26:10

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

optest/docs/updated_at.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


element-uap-visualelements: fix BackgroundColor missing column

The "Yes" was in the wrong column. Add the extra empty column to get the right number of columns.

Thanks for catching this!


Support for Pekko HTTP?

Hi!
First of all, thank you for supporting such an important project for Akka HTTP users!
My issue is rather a question to the maintainers (so probably @hseeberger), what's your take on supporting Pekko HTTP?
Pekko now reached nightly releases, so it's high time to think about akka-http-json but for Pekko. Options I think are that either this project would be a place for it or a fork will be needed.
I'm happy to help and do some legwork but before that, I'd like to hear from you.

@hseeberger oh, I see. Is there someone else with merge privileges?

I don't think so.

I forked akka-http-json and created https://github.com/pjfanning/pekko-http-json
I pushed snapshot jars to:
https://oss.sonatype.org/content/repositories/snapshots/com/github/pjfanning/
Thanks @hseeberger for all the amazing work you've done on akka-http-json and all your other projects. I think it is useful to have a pekko equivalent of these akka-http-json libs.

Thanks @pjfanning to take this project further.
Do you think it could make sense to either make you a maintainer of this project or transfer it to some other organization first and then make you maintainer? Might be easier for the existing user base.

@hseeberger I'm not really sure what the best way forward is. Most of the code in this repo depends on 'akka' classes and while the Pekko equivalents are basically the same except for the package names - the classes are still not compatible. So it feels like the Akka and Pekko modules won't share much code. To take as an example, Jackson, it's possible to rewrite the code to support Scala 3 but that change would probably need to be applied separately to the Akka and Pekko Jackson modules.
At the moment Pekko HTTP is far from complete and the build.sbt will need to be updated regularly with new snapshot version numbers. This means maintaining my own personal fork is easier, for now.
Maybe in a few months, when Pekko HTTP is released, we can look again at the options around adding Pekko modules to this Github project or a successor project.

It's now a year later and I think we can all see that pekko-http-json is the reasonable continuation of akka-http-json. Perhaps it would be best to archive this project and to forward anybody with questions to the Pekko ecosystem.


updating material-ui and react

@keybase/react-hackers

👍

Huh, why didn't Travis run on this pull?

Ah -- it's not a pull req onto master.


canonicalize Cargo.toml path

@nikomatsakis I left the possible errors that canonicalize() could throw unhandled but if you prefer we could add some custom messages for them. I wasn't sure if it worth.

Great! :)


test-branch/execute-job/quoted-authorization/bfcd9f96-0885-40d3-801b-30c5859eb969

PR for testing c46561efc313898bc3f41861d040b6e5e97ff9b5

/canonical/self-hosted-runners/run-workflows c46561efc313898bc3f41861d040b6e5e97ff9b5


checkpoint saving stuck when use multiple GPUs

🐛 Bug
When I use multiple GPUs, the model saving step will be stuck, while it works perfectly when I use only one GPU.
Please reproduce using the BoringModel
class Spectrogram_based(Conditional_Source_Separation, metaclass=ABCMeta):

    @staticmethod
    def add_model_specific_args(parent_parser):
        parser = ArgumentParser(parents=[parent_parser], add_help=False)

        parser.add_argument('--n_fft', type=int, default=2048)
        parser.add_argument('--hop_length', type=int, default=1024)
        parser.add_argument('--num_frame', type=int, default=128)
        parser.add_argument('--spec_type', type=str, default='complex')
        parser.add_argument('--spec_est_mode', type=str, default='mapping')

        parser.add_argument('--train_loss', type=str, default='spec_mse')
        parser.add_argument('--val_loss', type=str, default='raw_l1')
        parser.add_argument('--unfreeze_stft_from', type=int, default=-1)  # -1 means never.

        return Conditional_Source_Separation.add_model_specific_args(parser)

    def __init__(self, n_fft, hop_length, num_frame,
                 spec_type, spec_est_mode,
                 conditional_spec2spec,
                 optimizer, lr,
                 train_loss, val_loss, hparams=None
                 ):
        super(Spectrogram_based, self).__init__(n_fft, hop_length, num_frame,
                                                optimizer, lr, hparams)

        self.n_fft = n_fft
        self.hop_length = hop_length
        self.num_frame = num_frame

        assert spec_type in ['magnitude', 'complex']
        assert spec_est_mode in ['masking', 'mapping']
        self.magnitude_based = spec_type == 'magnitude'
        self.masking_based = spec_est_mode == 'masking'
        self.stft = fourier.multi_channeled_STFT(n_fft=n_fft, hop_length=hop_length)
        self.stft.freeze()

        self.spec2spec = conditional_spec2spec
        self.valid_estimation_dict = {}
        self.val_loss = val_loss
        self.train_loss = train_loss

        self.init_weights()

    def init_weights(self):
        init_weights_functional(self.spec2spec,
                                self.spec2spec.activation)

    def training_step(self, batch, batch_idx):
        mixture_signal, target_signal, condition = batch
        loss = self.train_loss(self, mixture_signal, condition, target_signal)
        self.log('train_loss', loss, prog_bar=False, logger=True, on_step=False, on_epoch=True,
                 reduce_fx=torch.mean)
        return loss

    # Validation Process
    def on_validation_epoch_start(self):
        for target_name in self.target_names:
            self.valid_estimation_dict[target_name] = {mixture_idx: {}
                                                       for mixture_idx
                                                       in range(14)}

    def validation_step(self, batch, batch_idx):

        mixtures, targets, mixture_ids, window_offsets, input_conditions, target_names = batch

        loss = self.val_loss(self, mixtures, input_conditions, targets)

        self.log('raw_val_loss', loss, prog_bar=False, logger=False, reduce_fx=torch.mean)

        # Result Cache
        if 0 in mixture_ids.view(-1):
            estimated_targets = self.separate(mixtures, input_conditions)[:, self.trim_length:-self.trim_length]
            targets = targets[:, self.trim_length:-self.trim_length]

            for mixture, mixture_idx, window_offset, input_condition, target_name, estimated_target \
                    in zip(mixtures, mixture_ids, window_offsets, input_conditions, target_names, estimated_targets):

                if mixture_idx == 0:
                    self.valid_estimation_dict[target_name][mixture_idx.item()][
                        window_offset.item()] = estimated_target.detach().cpu().numpy()
        return loss

    def validation_epoch_end(self, outputs: List[Any]) -> None:
        for idx in [0]:
            estimation = {}
            for target_name in self.target_names:
                estimation[target_name] = get_estimation(idx, target_name, self.valid_estimation_dict)
                if estimation[target_name] is None:
                    continue
                if estimation[target_name] is not None:
                    estimation[target_name] = estimation[target_name].astype(np.float32)

                    if self.current_epoch > 1 and isinstance(self.logger, WandbLogger):
                        track = estimation[target_name]
                        if track.shape[0] > 40 * 44100:
                            track = track[44100 * 20:44100 * 40]

                        self.logger.experiment.log({'result_sample_{}_{}'.format(self.current_epoch, target_name): [
                            wandb.Audio(track, caption='{}_{}'.format(idx, target_name), sample_rate=44100)]})

        reduced_loss = torch.stack(outputs).mean()
        self.log('val_loss', reduced_loss, prog_bar=False, logger=True, on_step=False, on_epoch=True, sync_dist=True)
        print(reduced_loss)

    @abstractmethod
    def to_spec(self, input_signal) -> torch.Tensor:
        pass

    @abstractmethod
    def separate(self, input_signal, input_condition) -> torch.Tensor:
        pass

To Reproduce
My checkpoint_callback is
    checkpoint_callback = ModelCheckpoint(
        dirpath=ckpt_path,
        save_top_k=save_top_k,
        verbose=True,
        monitor = "val_loss",
        save_last= False,
        period  = args["check_val_every_n_epoch"],
        save_weights_only=args['save_weights_only']
    )

I use the command python main.py --gpus 4 --distributed_backend ddp for multiple-GPU running, while I use python main.py --gpus 1 for single GPU running. I did not change anything else.
Expected behavior
Model supposed to be saved smoothly, however, it is stuck at the step of saving the checkpoint. The GPU utilization shows 100% and never change. Please see the figures below:
GPU utilization stay at 100% forever

Saving is stuck at epoch 0

Environment

pytorch lightning version :1.2.1
PyTorch Version (e.g., 1.0): 1.4
OS (e.g., Linux): Ubuntu 18.04
How you installed PyTorch (conda, pip, source): pip
Build command you used (if compiling from source):
Python version:
CUDA/cuDNN version: 10.2
GPU models and configuration:
Any other relevant information:

it is possible that this PR will solve it: #6410

This is a huge pain for me at the moment too. The model checkpointing routine is stuck at the end of epoch X where X is random (e.g. 5,10 or whatever).
@awaelchli  is there any cheap workaround or do we have to wait until the PR you mentioned gets merged?
I would be fine with the second option if it was not for an upcoming deadline set on Wednesday.
Best,
Alex

I just saw the issue and the other PR and it's just a guess. I can't say for sure that it fixes this problem, also because the code sample you provided does not run directly.
Also, we don't know for sure that the problem here is the saving, all we see is that the last printed message is related to the checkpoint. The GPU utilization at 100% is another indication that the problem might not be with checkpointing.
One thing I noticed however is this suspicious list of arguments:
    checkpoint_callback = ModelCheckpoint(
        dirpath=ckpt_path,
        save_top_k=save_top_k,
        verbose=True,
        monitor = "val_loss",
        save_last= False,
        period  = args["check_val_every_n_epoch"],
        save_weights_only=args['save_weights_only']
    )

This doesn't look right. The checkpoint does not accept an argument save_weights_only and if you set check_val_every_n_epoch=x in Trainer then probably period in model checkpoint should not be set.
I suggest these steps:

remove save_weights_only argument from ModelCheckpoint
remove period and set check_val_every_n_epoch in the Trainer instead
upgrade to master pip install git+https://github.com/PyTorchLightning/pytorch-lightning@master

I tried running my experiments from pytorch-lightning@bugfix/broadcast_2 but the issue remains, although it seems less prevalent (i.e. 11/14 jobs are still running 4 hours into the training).
Even though this is mainly my responsibility, I have so far burnt close to 3000 GPU hours on a limited computational budget only to realize my jobs had silently failed. Needless to say that it's slightly annoying.
Is there anything I can do to help fix this bug?

Is there anything I can do to help fix this bug?

Sorry for the standard answer but a minimal working example (ready to run) would be the best, because then we can directly start debugging with minimal guess work. I understand that given the conference deadline this is probably too much work (I myself am also submitting to ICCV next week).

I will see what I can do. My only concern for reproducibility is that the issue seems quite random so far (not all runs are impacted, it happens at a random epoch). I'm not sure I would be able to reproduce it given a simple BoringModel for example. But yes, I could give it a try!

@awaelchli Thanks. I can remove the save_weights_only. The logic of setting period equal to the number args["check_val_every_n_epoch"] is that I would like to do validation check when I save the model. Based on what you said, when I set the check_val_every_n_epoch in Trainer, I don't need this in the callback? It will automatically do the check periodically ?
Thank you once again.

@awaelchli @inzouzouwetrust Hi, just want to update that when I switch to "dp" backend, everything is OK. Hope this help you identify the problem.
Thanks.

Dear @sun-peach,
Any chance you could provide a reproducible script ?
Would you mind trying to following:

Master: We recently merged a PR about DDP hanging.
Add sync_dist=True within all your self.log, just to see if the pb remains.

Best,
T.C

@tchaton I see this issue with pytorch 1.7 and PL 1.2.4, which has those fixes that are supposed to fix DDP hanging. sync_dist=True doesn't help either (it's actually set to true in the BoringModel code). My script doesn't even finish the validation loop. The gpu usage goes to 100% at some point and the training script simply hangs.

Dear @azouaoui-cv, @yukw777,
Would it be possible for you to share a reproducible script for us to work on ?
Best,
T.C

@tchaton I no longer have access to a multi-gpu machine. I'd like to try reproducing it once I get a hold of one. :/ @azouaoui-cv did the issue ever go away?

I've had exactly the same problem, and found that the problem is caused specifically if (using ddp on multiple GPUs) checkpoint saving is done based on monitoring a quantity.
@sun-peach do the hangups go away if you remove the monitor-based saving and simply checkpoint at every epoch?

Closing for now, please reopen with a reproducible script.


Hide byline for RSS feeds

A lot of RSS feeds have a single common byline. As such, it would be nice to ignore the author for such feeds as a configurable option.

Totally agree! What do you think of this:
"byline": "all" | "none" | "first"

all: include byline always
none: never include byline
first: only show on the first from this provider

Any cases I'm missing?

Sounds good to me!


Code release

Great job!
When will you release the code?

We are preparing the code as concisely as possible and optimizing the algorithm for acceleration, and will release the complete training and inference code later.

+1

helpful

+1

+1

A nice work, interactive page can be used, can you get more contact with the author.

A nice work, interactive page can be used,? Can you get more contact with the author.

I promise to release the code and weights before the end of August.

I promise to release the code and weights before the end of August.

Great work! Could you please just release the inference code and pre-trained weights first, even if the complete codes of the project are not well-organized?

The code has been released, please enjoy it.

Do you plan to release the pre-trained lora_checkpoint  named “last_checkpoint.pth” for directly running the demo.py, or did I miss something?


Nerf airlock deconstruction

Delays a bit higher. Might be too high so might need dialing back after feedback.
Also made anchoring for powered stuff take 2s instead and also made airlock assembly take 2s for anchoring instead of the default 0.5s. This is mainly for stuff like if you misclick (very possible due to clickmaps rn) and want to cancel it out 0.5 isn't really enough time.
Resolves https://github.com/space-wizards/space-station-14/issues/6340
:cl:

tweak: Airlock construction / deconstruction now takes longer.

conflcits


[Issue-1058]: Do not show the category of dApp

Pr for issue #1058

Close this pull request because issue is resolved


Feature Request: Support React Applications

Do you want to request a feature or report a bug?
feature
What is the current behaviour?
preact-cli is working awesome for projects based on preact, but does not support react applications out of the box.
If the current behaviour is a bug, please provide the steps to reproduce.

What is the expected behaviour?
preact-cli should be able to build/run react based applications.
If this is a feature request, what is motivation or use case for changing the behaviour?
Motivations:

I ❤ preact-cli and I wish if I could use some of the awesome features for applications based on react instead. Mainly:

Fully Automated Code Splitting
PRPL Support

If we can use same CLI for both preact and react, both the communities will benefit from ongoing improvements and defects fixes

Note: I am interested in investing some time on this, if it seems like a lot of maintenance for this repo, we can even create a fork and maintain relevant bits there. In that case, it would be great if you can point me to any prior attempts or any guidance on ways to proceed.
Thoughts / Opinions ?

I would imagine that you can add a couple of aliases to the custom preact.config.js file so that React is used instead. Eg, re-updating these aliases.

What @lukeed has mentioned is definitely a start, I also think you need to have your own babelrc file. In the transform react JSX plugin options, you have a pragma where you should use the default value for React and for Preact the pragma option value is h check it out here:
https://www.npmjs.com/package/babel-plugin-transform-react-jsx#options

Thank you @lukeed and @zouhir. Here is a list of things we might need to support this request:

[ ] Update list of aliases in webpack-base-config.js - Can be customized using preact.config.js
[ ] Update list of plugins for babel in babel-config.js - Can be customized using preact.config.js
[ ] Investigate changes needed in async.js and async-component-loader.js
[ ] Investigate changes need in prerender.js
[ ] Investigate changes needed in entry

Not sure if last 3 can be configured using preact.config.js.
Did I miss anything?


MediaPlayer.Play() does not invoke CurrentStateChanged

When an app with MediaPlayer (autoplay : false) starts & the MediaPlayer playlist is loaded, MediaPlayer_CurrentStateChanged gets invoked to show changing statuses: "Opening" & "Paused".
But, when playback is started with MediaPlayer.Play(), MediaPlayer_CurrentStateChanged does not get invoked and the status is stuck at "Paused".
Also, if MediaPlayer's Playlist.MoveNext(), Playlist.MovePrevious() or Playlist.MoveTo(index) is called, the state does not change.
I have also observed that in case of Playlist.MoveNext(), if it is called before Play method, state change does get invoked. For other methods, calling before or after Play has not effect.
You can test this behaviour in my app Music Wall. Play few tracks. Close the app. Start the app again. Press "previous". Music playback will start, but the play/pause button is stuck at play.
Now, close the app. Start it again & press next. This time, state change gets invoked correctly because MoveNext is called before Play in the code.

Thanks for reporting. We think there may be a platform bug here and that it has been fixed in an upcoming release. I'll update when I hear back from the team.

We believe this is an OS and not a sample bug that has been fixed in the latest Windows 10 flights. Please let us know if you still see this on RS2.


Http Request with content type Application/Json but no actual request body makes System.Text.Json throw exception

    ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls;
    WebRequest wr = WebRequest.Create($"http://localhost:3000/api/endpoint");
    wr.Method = "GET";
    wr.ContentType = "application/json";
    var response = wr.GetResponse;

Throws exception, i found the reason looking at the source code.
BindToModel method of Endpoint class does the following:
if (isPlainTextRequest)
{
  req = await BindPlainTextBody(ctx.Request.Body);
}
else if (ctx.Request.HasJsonContentType())
{
  req = (TRequest?)await FastEndpoints.Config.ReqDeserializerFunc(ctx.Request, tRequest, serializerCtx, cancellation);
  if (req is null) throw new InvalidOperationException("JSON deserialization failed!");
}
else
{
  req = new();
}

isPlainTextRequest is false because ContentType is set.
ctx.Request.HasJsonContentType() returns true because ContentType is set to 'application/json'.
But we don't have any body in our request so the following line gets confused.
req = (TRequest?)await FastEndpoints.Config.ReqDeserializerFunc(ctx.Request, tRequest, serializerCtx, cancellation);

After this line of code the request never reaches the endpoint.
My hotfix was adding try-catch:
       try
        {
            if (isPlainTextRequest)
            {
                req = await BindPlainTextBody(ctx.Request.Body);
            }
            else if (ctx.Request.HasJsonContentType())
            {
                req = (TRequest?)await FastEndpoints.Config.ReqDeserializerFunc(ctx.Request, tRequest, serializerCtx,
                    cancellation);
                if (req is null) throw new InvalidOperationException("JSON deserialization failed!");
            }
            else
            {
                req = new();
            }
        }
        catch
        {
            req = new();
        }

But a better solution could be coded, when a third party developer just adds
    wr.ContentType = "application/json";

to every call they make to fastendpoint api, it shouldn't break the api in my opinion.
I'm open to questions about this topic.

we've come across this before on discord: https://discord.com/channels/933662816458645504/968858009520451595
the try/catch would certainly work but first i need to measure the performance impact of doing that since this is the hottest path in the library. if the perf drop is neglibible, i will implement it. if not, we need to figure out an alternative solution.
also fyi @fretje

Would the following be better?:
 TRequest? req = default;

        if (isPlainTextRequest)
        {
            req = await BindPlainTextBody(ctx.Request.Body);
        }
        else if (ctx.Request.HasJsonContentType())
        {
            var bodyHasData = await BodyHasData(ctx.Request.Body);
            if (bodyHasData)
            {
                req = (TRequest?)await FastEndpoints.Config.ReqDeserializerFunc(ctx.Request, tRequest,
                    serializerCtx,
                    cancellation);
                if (req is null) throw new InvalidOperationException("JSON deserialization failed!");
            }
            else
            {
                req = new();
            }
        }
        else
        {
            req = new();
        }

    private static async Task<bool> BodyHasData(Stream body)
    {
        using var streamReader = new StreamReader(body);
        var content = await streamReader.ReadToEndAsync();
        return content.Length > 0;
    }

We could even do this so it does not streamread twice if its plaintext:
 TRequest? req = default;
        var bodyContent = await BodyContent(ctx.Request.Body);
        var bodyHasData = bodyContent.Length > 0;
        if (isPlainTextRequest && bodyHasData)
        {
            req = await BindPlainTextBody(bodyContent);
        }
        else if (ctx.Request.HasJsonContentType() && bodyHasData)
        {
            req = (TRequest?)await FastEndpoints.Config.ReqDeserializerFunc(ctx.Request, tRequest,
                serializerCtx,
                cancellation);
            if (req is null) throw new InvalidOperationException("JSON deserialization failed!");
        }
        else
        {
            req = new();
        }

  private static async Task<TRequest> BindPlainTextBody(string bodyContent)
    {
        var req = (IPlainTextRequest)new TRequest();
        req.Content = bodyContent;
        return (TRequest)req;
    }

    private static async Task<string> BodyContent(Stream body)
    {
        using var streamReader = new StreamReader(body);
        return await streamReader.ReadToEndAsync();
    }

these won't work without ctx.Request.Body.EnableBuffering() which has a considerable perf impact since each request to the system is going to get fully buffered either in memory or disk.
in any case, need to pit each solution against eachother and benchmark before we can select a path to take.
give me a few days to try and benchmark these.

Yeah totally forgot that. My fix would be to use the bodyContent to make a new stream so no need for (ctx.Request.Body.EnableBuffering()):
File: Endpoint.Static.cs, Line 17
	TRequest? req = default;
        var bodyContent = await BodyContent(ctx.Request.Body); // Get stream as string
        var bodyHasData = bodyContent.Length > 0;
        if (isPlainTextRequest && bodyHasData)
        {
            req = await BindPlainTextBody(bodyContent);
        }
        else if (ctx.Request.HasJsonContentType() && bodyHasData)
        {
            MemoryStream stream = new(Encoding.ASCII.GetBytes(bodyContent)); // String back to stream because we need the content to json deserialize.

            req = (TRequest?)await FastEndpoints.Config.ReqDeserializerFunc(stream, tRequest,
                serializerCtx,
                cancellation);
            if (req is null) throw new InvalidOperationException("JSON deserialization failed!");
        }
        else
        {
            req = new();
        }

File: Config.json, Line: 31

	// Using Stream instead of HttpContext.Body
	internal static Func<Stream, Type, JsonSerializerContext?, CancellationToken, ValueTask<object?>>
        ReqDeserializerFunc { get; private set; }
        = (stream, tReqDto, jCtx, cancellation) =>
        {
            return jCtx == null
                ? JsonSerializer.DeserializeAsync(stream, tReqDto, SerializerOpts, cancellation)
                : JsonSerializer.DeserializeAsync(stream, tReqDto, jCtx, cancellation);
        };

File: Config.json, Line: 154
		public Func<Stream, Type, JsonSerializerContext?, CancellationToken, ValueTask<object?>> RequestDeserializer
		{
			set => ReqDeserializerFunc = value;
		}

I'm out of ideas for now 😄 I really wonder what your test results will be.

that doesn't look any more performant than a simple try/catch imho. i see some additional allocations that need to happen which will add to gc pressure which would in turn reduce requests per second of the system. let's see...

looks like my assumption was correct. it takes twice as long for the try/catch version to complete the operation and allocates more memory as well.
here's the benchmark project if you wanna run it yourself and see: FETryCatchBench.zip
BenchmarkDotNet=v0.13.1, OS=Windows 10.0.22000
AMD Ryzen 7 3700X, 1 CPU, 16 logical and 8 physical cores
.NET SDK=6.0.300
  [Host]     : .NET 6.0.5 (6.0.522.21309), X64 RyuJIT
  Job-SFFKRT : .NET 6.0.5 (6.0.522.21309), X64 RyuJIT

InvocationCount=10000  IterationCount=10  LaunchCount=1
WarmupCount=1

Method
Mean
Ratio
Gen 0
Gen 1
Allocated

WithoutTryCatch
32.68 μs
1.00
1.5000
-
13 KB

WithTryCatch
74.13 μs
2.27
2.0000
0.1000
16 KB

so we will definitely not be adding a try/catch to the most critical & hottest execution path in fastendpoints.
you have three options the way i see it.

get your client applications to do the correct thing and ensure that whenever they're sending application/json content-type, they need to at least send an empty json object {} in the request body.

if you have no control over the client code, then you'll have to pay the performance panelty by using a custom request deserializer function like this:

app.UseFastEndpoints(c =>
{
    c.RequestDeserializer = async (req, tDto, jCtx, ct) =>
    {
        try
        {
            if (jCtx == null)
                return await JsonSerializer.DeserializeAsync(req.Body, tDto, options: null, ct);
            else
                return await JsonSerializer.DeserializeAsync(req.Body, tDto, jCtx, ct);
        }
        catch (JsonException x)
        {
            if (x.Message.StartsWith("The input does not contain any JSON tokens"))
                return new EmptyRequest();
            throw;
        }
    };
});
app.Run();

make a feature request with the system.text.json team so that we can set a serializer option where we get to instruct the serializer not to throw an exception in case the supplied stream has no data.

This also happens if you accidentally send a get request with Content-Type
bombardier https://localhost:7035/faster/weather --method GET -n 1 -c 1 -l --header "Content-Type: application/json"

@andtii get requests with a json body is supported in fastendpoints. the root cause is really a shortcoming in system.text.json
in order to work around that, we'll have to do a try/catch as mentioned above which reduced performance by 50%. so we will not do it. you are left with the 3 options i've mentioned above :-)

we have a simple solution to this issue thanks to #148
but your request dto must be of type EmptyRequest
which is basically what EndpointWithoutRequest is

we have a simple solution to this issue thanks to #148 but your request dto must be of type EmptyRequest which is basically what EndpointWithoutRequest is
fix available after v4.3.0-beta11

Wow amazingly simple solution, all my complex useless tries looks so dumb 🤣

What would be the correct solution in this case?
I currently have an endpoint like:
/items/{id}
And a request model:
class Request
{
    public int Id { get; set; }
}

Should I refactor it to an endpoint without a request and retrieve the id using Route("Id")?
Or is there another recommended approach?


Models

pushed User and Activity models.
Profile Model still in development

User and Activity models updated.
Profile model removed. Replace with Daily Log model.


requestJSONEncodableParameters

Hey, great library! Thanks for creating.
My use case requires an Encodable body along with url parameters. I can make this work with requestCompositeParameters, but that feels clunky. For one thing, my var task is doing JSON encoding but I have to silently eat any exceptions that occur.
It would be better if Moya offered requestJSONEncodableParameters and possibly requestCustomJSONEncodableParameters for completeness. Let me know if a PR would be helpful or if there is a better approach. Thanks guys!

Hello :)
#1936 is an opened PR that should satisfy your needs.

Thank you, I will check it out! At first glance it looks like a good change. Much appreciated.


About the value of Resistance, capacitance, inductance

Hello, I have download your project and found that I can't get the value of Resistance, capacitance, inductance.Could you please show me you BOM?Thank you!

I'm currently choosing the values for PCBA, so I'll push version 2.1 later, maybe before the end of the month.

Values for 915Mhz are up!


Labels are not applied to deployment or pod when specified for an ingress gateway component

Bug description
This is found in 1.7 and even in 1.9
Example YAML
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: istio-install
  namespace: istio-system
spec:
  meshConfig:
    defaultConfig:
      proxyMetadata:
        ISTIO_META_DNS_CAPTURE: "true"
        ISTIO_META_DNS_AUTO_ALLOCATE: "true"
  profile: demo
  components:
    ingressGateways:
      - name: istio-ingressgateway
        enabled: true
      - name: httpbin-gateway
        enabled: true
        namespace: httpbin
        label:
          app-name: httpbin
          gateway: httpbin
        k8s:
          podAnnotations:
            sidecar.istio.io/inject: "false"
  values:
    global:
      istiod:
        enableAnalysis: true
    pilot:
      env:
        PILOT_ENABLE_STATUS: true

Here I expect httpbin-gateway pods or deployment to have app-name and gateway labels. It seems that labels are swallowed during overlaying process in operators as shown in the saved IstioOperator CR.
    ingressGateways:
    - enabled: true
      k8s:
        resources:
          requests:
            cpu: 10m
            memory: 40Mi
        service:
          ports:
          - name: status-port
            port: 15021
            protocol: TCP
            targetPort: 15021
          - name: http2
            port: 80
            protocol: TCP
            targetPort: 8080
          - name: https
            port: 443
            protocol: TCP
            targetPort: 8443
          - name: tcp
            port: 31400
            protocol: TCP
            targetPort: 31400
          - name: tls
            port: 15443
            protocol: TCP
            targetPort: 15443
      name: istio-ingressgateway
    - enabled: true
      k8s:
        podAnnotations:
          sidecar.istio.io/inject: "false"
      name: httpbin-gateway
      namespace: httpbin

Pod labels for httpbin-gateway
Name:         httpbin-gateway-6ddfcb7cc9-dkpdg
Namespace:    httpbin
Priority:     0
Node:         xcp-1-control-plane/<IP_ADDRESS>
Start Time:   Wed, 17 Feb 2021 21:10:57 +0530
Labels:       app=istio-ingressgateway
              install.operator.istio.io/owning-resource=unknown
              istio=ingressgateway
              istio.io/rev=default
              operator.istio.io/component=IngressGateways
              pod-template-hash=6ddfcb7cc9
              service.istio.io/canonical-name=httpbin-gateway
              service.istio.io/canonical-revision=latest
              sidecar.istio.io/inject=false
Annotations:  prometheus.io/path: /stats/prometheus
              prometheus.io/port: 15020
              prometheus.io/scrape: true
              sidecar.istio.io/inject: false

Similarly labels and annotations on deployment
Name:                   httpbin-gateway
Namespace:              httpbin
CreationTimestamp:      Wed, 17 Feb 2021 21:10:57 +0530
Labels:                 app=istio-ingressgateway
                        install.operator.istio.io/owning-resource=istio-install
                        install.operator.istio.io/owning-resource-namespace=istio-system
                        istio=ingressgateway
                        istio.io/rev=default
                        operator.istio.io/component=IngressGateways
                        operator.istio.io/managed=Reconcile
                        operator.istio.io/version=1.9.0
                        release=istio
Annotations:            deployment.kubernetes.io/revision: 1

Ideally, it should be on pods and services?
[ ] Docs
[X] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
[ ] Upgrade
Expected behavior
Label should be added to pods/services (to be decided, but pods is ideal)
Steps to reproduce the bug
Apply IstioOperator CR mentioned in this issue and check pods and deployments for additional labels.

Working as expected. Closing it.


helm: enable to specify nodeSelector

why
To enable to deploy to dedicated node
what

Enable to specify nodeSelector in the helm chart

Duplicated with #69


Untimely service expiry

Services are being killed automatically even when nohup is provided.

Resolved this issue by adding BUILD_ID=dontKillMe


Refactor/switch to helm install

using helm install is just more modern than make...and while handy during dev, users benefit if we test with their tools

Codecov Report

Merging #172 (0ca9dd3) into develop (ac856dc) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop     #172   +/-   ##
========================================
  Coverage    96.78%   96.78%
========================================
  Files           22       22
  Lines         1056     1056
========================================
  Hits          1022     1022
  Misses          34       34

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 ac856dc...0ca9dd3. Read the comment docs.


Camel Cron trait page is rendered incorrectly

It says a valid cron is: cron:tab?schedule=0/2++++?, but it should be cron:tab?schedule=0/2+*+*+*+?.
Page here: https://camel.apache.org/camel-k/latest/traits/cron.html

Replacement of + with {plus} needs to be done in the code generator, otherwise it's replaced when we regenerate the doc.

ok. Need to check code-generator then.

Btw I see the page rendered correctly


Cannot read property 'uri' of null

Issue Id: 5158e8e3-2e09-43c1-badd-5989e08cdab3Versions - 0.10.6-release-  dfc08dc9edf6607483b193bf934d3badc3fa2e11Stack TypeError: Cannot read property 'uri' of nullvs/workbench/node/pluginHostProcess.js#L9:0 (define)    at render (c:\Program Files (x86)\Microsoft VS Code\resources\app\extensions\jrieken.vscode-omnisharp\out\features\omnisharpStatus.js:43:57) /vs/base/common/arrays.ts#L5:0/vs/base/common/arrays.ts#L5:0vs/workbench/node/pluginHostProcess.js#L9:0 (define)vs/workbench/node/pluginHostProcess.js#L9:0 (define)/vs/base/common/arrays.ts#L5:0    at Object.p.handle (c:\Program Files (x86)<br />

This issue was moved to OmniSharp/omnisharp-vscode#15