[WIP] TorchvisionBackboneConfig refactor

This PR proposes a refactor of TorchvisionBackboneConfig to adopt a similar structure to the MMDetBackboneConfig
Because TorchvisionBackboneConfig is used by existing Torchvision models such as faster_rcnn, mask_rcnn, keypoint_rcnn and retinanet modifying the TorchvisionBackboneConfig directly will cause the imports from icevision.all import * to fail. As a result, I could not get the getting started training notebook to run to test it out.
Hence, I have create a temporary class TorchvisionBackboneConfigV2 to work on the refactor. If the TorchvisionBackboneConfigV2 passes all the code review by core-devs, this will replace all instances of TorchvisionBackboneConfig class. For the purpose of this test, I have also create a temporary retinanetv2 model that uses the TorchvisionBackboneConfigV2 class.
The model trains on my machine but with a relatively poor performance compared to the mmdet retinanet. The model I tested was instantiated with the following lines
model_type = models.torchvision.retinanetv2
backbone = model_type.backbones.resnet50_fpn
model = model_type.model(backbone=backbone(pretrained=True), num_classes=len(parser.class_map), **extra_args)

Please let me know if this is consistent with the existing IceVision structure and how should I proceed further.
Thank you.

@ai-fast-track do you think this is going in the right direction you intended? @lgvaz do you have any suggestions?


ARROW-5432: [Python] Add NativeFile.read_at()

Adding a read_at function for pyarrow.NativeFile that allows you to specify a length and offset. The read_at function doesn't do any reading ahead.
https://issues.apache.org/jira/browse/ARROW-5432

HdfsPread (documented here: https://mapr.com/docs/archive/mapr50/28872231.html) doesn't change the offset of the file, but it seems ReadAt call in the arrow library does. This doesn't really matter for functionality, but it's good to know.

it seems ReadAt call in the arrow library does

It should be platform-dependent. Did you test on Windows?

Travis-CI compile error is due to https://github.com/cython/cython/issues/2974

I tried to push changes to your branch but apparently that confused Github. I'll open a new PR, sorry.


Debian Stretch gives a mysterious message.

Please paste the output of the following command here: sudo edit-chroot -all

name: beta
encrypted: no
Entering /mnt/stateful_partition/crouton/chroots/beta...
crouton: version 1-20170825164243~master:6af640de
release: stretch
architecture: amd64
xmethod: xorg
targets: gnome-desktop,gnome,extension
host: version 9592.71.0 (Official Build) stable-channel peppy
kernel: Linux localhost 3.8.11 #1 SMP Thu Jul 27 00:04:59 PDT 2017 x86_64 GNU/Linux
freon: yes
Please describe your issue:
When startgnome is run this error message is given:
Entering /mnt/stateful_partition/crouton/chroots/beta...
Unknown username "geoclue" in message bus configuration file
_XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root
X.Org X Server 1.19.2
Release Date: 2017-03-02
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.9.0-3-amd64 x86_64 Debian
Current Operating System: Linux localhost 3.8.11 #1 SMP Thu Jul 27 00:04:59 PDT 2017 x86_64
Kernel command line: cros_secure console= loglevel=7 init=/sbin/init cros_secure oops=panic panic=-1 root=/dev/dm-0 rootwait ro dm_verity.error_behavior=3 dm_verity.max_bios=-1 dm_verity.dev_wait=1 dm="1 vroot none ro 1,0 2539520 verity payload=PARTUUID=84de0146-4580-ca4f-823c-989c25105b57/PARTNROFF=1 hashtree=PARTUUID=84de0146-4580-ca4f-823c-989c25105b57/PARTNROFF=1 hashstart=2539520 alg=sha1 root_hexdigest=678204cbba46b8ad7ee4f033691fbe11a833d104 salt=475c61b6682e9441f2e7ffe37e2cb2e38283084af1e2993424a01692ff6e2d65" noinitrd vt.global_cursor_default=0 kern_guid=84de0146-4580-ca4f-823c-989c25105b57 add_efi_memmap boot=local noresume noswap i915.modeset=1 tpm_tis.force=1 tpm_tis.interrupts=0 nmi_watchdog=panic,lapic iTCO_vendor_support.vendorsupport=3
Build Date: 07 July 2017  06:14:06AM
xorg-server 2:1.19.2-1+deb9u1 (https://www.debian.org/support)
Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(++) Log file: "/tmp/Xorg.crouton.1.log", Time: Sat Aug 26 08:42:02 2017
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(EE)
Fatal server error:
(EE) parse_vt_settings: Cannot open /dev/tty0 (No such file or directory)
(EE)
(EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
(EE) Please also check the log file at "/tmp/Xorg.crouton.1.log" for additional information.
(EE)
(EE) Server terminated with error (1). Closing log file.
/usr/bin/xinit: giving up
/usr/bin/xinit: unable to connect to X server: Connection refused
/usr/bin/xinit: server error
Unmounting /mnt/stateful_partition/crouton/chroots/beta...
If known, describe the steps to reproduce the issue:
install the stretch chroot with gnome-desktop and extension targets
run startgnome

#3310 solution solves this.

What does this message mean?
"Unknown username "geoclue" in message bus configuration file"

Unfortunately, I don't think this is related to #3369.  I'm much more familiar with ubuntu flavors than debian.  I'd recommend trying to install the same targets on xenial to make sure that crouton is working properly with your chromebook and chrome os version.  If that works, then it must be something that changed in debian.
Good luck tracking it down!

@Asternitix Have you tried creating a chroot with only the gnome target, which provides only the basic setup with just a few applications?
GeoClue is a geolocation service used by Maps and various other stuff that's part of the complete Gnome desktop. That's why I wonder if there could be a problem with the gnome-desktop target, which installs many more applications.
The message you asked about,

Unknown username "geoclue" in message bus configuration file

probably means that geoclue appears as a username somewhere in the configuration file for the message bus, but the user geoclue doesn't exist.

@shelleyvadams  yeah, I tried that, how do I remove geoclue from the configuration file?

Unfortunately, I don't think this is related to #3369. I'm much more familiar with ubuntu flavors than debian. I'd recommend trying to install the same targets on xenial to make sure that crouton is working properly with your chromebook and chrome os version. If that works, then it must be something that changed in debian.

I have xenial installed,
encrypted: yes, unlocked
Entering /mnt/stateful_partition/crouton/chroots/devbox...
crouton: version 1-20171122220410~master:99877eaf
release: xenial
architecture: amd64
xmethod: xorg
targets: unity,extension
host: version 10176.22.0 (Official Build) beta-channel cave
kernel: Linux localhost 3.18.0-16352-g01e32a3522ff-dirty #1 SMP PREEMPT Tue Dec 19 22:22:39 PST 2017 x86_64 x86_64 x86_64 GNU/Linux
freon: yes

and I get the same error message as OP.
Though I have to say that the chroot works (mostly). Though there are some display issues over time as I switch between the chroot and ChromeOS:

certain letters stop appearing
terminal emulator displays contents beneath until I select the window and scroll up and down.

Hope this helps?

Regarding the "geoclue" message, it might be a bug in the iio-sensor-proxy package that should depend on the geoclue-2.0 package. To get rid of the error message you can install geoclue-2.0. Another option is to edit the file /etc/dbus-1/system.d/net.hadess.SensorProxy.conf and comment-out the part that refers to the user geoclue.

Installing geoclue-2.0 worked for me!


Cut v2.30.0-rc.0

Currently waiting on https://github.com/prometheus/prometheus/pull/9314 to be merged before I cut the rc0 (I will re-create the release branch once that is merged). In the meantime, here is the changelog.

Some git screw-up got this merged automatically. I will force update release-2.30 to sync with main and open another PR for the release.

Synced release-2.30 with main and removed this commit and opened https://github.com/prometheus/prometheus/pull/9316


v1.0 updates have made Dark Theme border text difficult to read

Since the Obsidian v1.0 update, I am having trouble reading the text in borders (headers) or seeing the icons in the header part of the page. The white font is quite dull and does not contrast well with the black background of the Dark Theme anymore - this makes it difficult to read or make out the icons.

While it may not look like much of an issue from the screenshot, on a real monitor I have noticed a big different since the update.

Additional issue related to the same update.
The left portion of text in some windows is now cut off, as in the screenshot below.

@kandyman2017 - I have updated the theme to be compatible with the 1.0 release of obsidian. This is a complete rewrite and because I don't have much time for updates, I've tried to simplify things and have really made this mostly a UI theme rather than adjusting any text.


Entries of Zdnet.fr feed are (almost) never updated

Feed URL
https://www.zdnet.fr/feeds/rss/
Add-on version
Add-on version:Latest, ie. 3.3
Describe the bug
The list of entries is (almost) never updated. I guess this is likely due to a bug in cache management by LiveMarks, since if I deactivate LiveMarks, and put the URL in address bar, I get an up-to-date list of entries. But as soon as I re-activate LiveMarks, putting the URL in address bar gives a list of entries not up-to-date (and consistent with what add-on's bookmark).
I have checked in Firefox Options / Private / Manage site's data, but there is no data nor cookie stored about this website (to be more exact : all data relative to the site, if exist, have already been cleansed by another add-on, "Forget-me-not".
I have writen above "almost never updated", because sometimes, but very very very rarely (once every 10 - 30 days, or even more), without doing anything, entries list is updated. What is the cause of this update ? No idea.
I don't know if this is specific to this feed, but among all feeds I have, this one is the only one with the bug.
Currently, It's not possible to use this feed. I have only maintained it to see if the problem was disappearing, before creating this issue. But it's now several months (> 6 months ?) I have the issue...
To be sure, of course, I tried to delete the feed in Livemarks, close Firefox, reopen it, then re-create the feed. But this doesn't change anything : entries list is still out of date.
To Reproduce
Steps to reproduce the behavior:

Create this feed with LiveMarks, going to  https://www.zdnet.fr/actualites/ and clicking on the LiveMarks icon in address bar
First time, most likely is that list of entries will be consistent with what you can see on https://www.zdnet.fr/actualites/

Go back the day after. (Zdnet.fr is updated several times a day, but from one day to the day after, we are 100% sure there are new "News")
List of entries in LiveMarks bookmark is still the same than the day before.
Nevertheless, if you go directly to https://www.zdnet.fr/actualites/, you can see new more recent "News" that were not existing the day before, and are not in LiveMarks entries for this feed.

Deactivate LiveMarks

Open www.Zdnet.fr/feed/rss
Since LiveMarks is deactivated, you can see in top of XML file new entries.

Reactivate LiveMarks

Re-Open www.Zdnet.fr/feed/rss (or click on LiveMarks icon in address bar, when on https://www.zdnet.fr/actualites/)
In the list (managed by LiveMarks), new entries are not there

Expected behavior
To have entries managed by LiveMarks updated each time a new entry is created on the site

Actually, there were probably an issue not only in Livemarks, but maybe also in my Firefox profile.
Because, when I wanted to re-create this feed in LiveMarks... I got an error : Impossible de récupérer le flux
And it was not the case in other environments (eg. on VMs running on Virtualbox)
Then I created a new Firefox profile... in which creation of the feed in LiveMarks is OK.
I let it in place, and in a few days, I'll be able to see if it is automatically updated or not.
Rather than to create a new profile, I would have prefer to be able to purge any reference to Livemarks in my initial profile, then to reload Livemarks. But even after a full de-install of livemarks, then stop/start Firefox, then re-install Livemarks, it comes with all its previous parameters.
So my question : How can we remove all parameters of a de-installed extension, to restart parameterization from scratch when re-installing the extension ?

We are now 3 days later, and (up to now...) it works fine. Thank you !
If someone was able to answer to the question I ask (just above, in my previous post in this thread), I would be REALLY interested in the answer...


Allow using inline render method defined on a parent

Summary
A (very) small PR that changes the Base#inlined?check to use instance_methods including ancestors to allow using an inline render method defined on a parent class.
This behaviour currently isn't possible, given the code currently uses instance_methods(false) to check if the call method is defined (even though the instance responds to call with the expected outcome)
Example:
class BaseComponent < ViewComponent::Base
  def call
    content_tag :div, class: base_classes + additional_classes
  end

  private

  def base_classes
    %w[base-class]
  end

  def additional_classes
    []
  end
end

class ChildComponent < BaseComponent
  private

  def additional_classes
    %w[additional-class]
  end
end

# irb
> BaseComponent.inlined?
=> true
> ChildComponent.inlined?
=> false

# ..however
> BaseComponent.new.call
=> "

"

> ChildComponent.new.call
=> "

"

(will update tests)

First attempt at this had a silly mistake, updated now!

Just as an extra note on this, I'm not massively comfortable grepping the all instance methods for what we are looking for here, an alternative much be just to grep the relevant classes, something like:
def inlined?
  return false unless templates.empty?

  # Only check if an inline render method has been defined on this class
  # or on an ancestor, up to (but excluding) ViewComponent::Base
  ancestor_classes = (ancestors[0...ancestors.index(ViewComponent::Base)] - included_modules)
  return false unless ancestor_classes

  ancestor_classes.any? { |ancestor_class| ancestor_class.instance_methods(false).grep(/^call/).present? }
end

..or maybe there's a better way to do this?

@simonrand what if we used a respond_to?(:call) check?

(It would be helpful to have a test case here, if you don't mind ❤ )

@joelhawksley thanks for the reply! (..and the work on all this - have been following it for a long time) I did go for that approach first, but I hit a couple of problems, mostly around moving this check from a class to instance method (felt like too big a change for what was needed) - the other problem arose from supporting inline calls for variants.. Leave this with me and I'll take another look (and add tests!)

@joelhawksley have updated!
This feature is made a bit difficult mainly by the variants feature - but I think I've got a reasonable solution at this point (without getting into changing the way variants are implemented)
..there is maybe also an argument for not being so defensive on the template rendering - it a template and/or inline call are missing, instead of trying to catch this, maybe just raising would be an easier option? (perhaps by catching any calls this call* methods in ViewComponent::Base) I'm not convinced this is good either so, so I will still offer this PR as my solution for now..
I should mention this also fixes a bug - inline variants were not working correctly as the available variants were not being gathered properly and thus this check https://github.com/github/view_component/blob/3550b486aeb5865656a7b2a34bdd51b9065a0895/lib/view_component/base.rb#L160 was always falling.
Thanks again!

@joelhawksley so it seems like I was about 90% there with the work I'd already done! dddd353 implements sidecar + inline method support in the same component, with the template taking priority in situations where both exist (which would seem to be the correct behaviour to me)..
There'll obviously be warnings if an inline render method and template exist (as the inline method will be overwritten in the compile method, which is now called if any template exists unless the component is entirely inlined) - but I think this is probably ok, unless we dig into how the template methods are being defined (which I'm not sure is really necessary at this stage)..

@joelhawksley thanks for the comments - updated!
One thing of note - there's a relatively interesting case here: https://github.com/github/view_component/pull/284/files#diff-c7432794f4e04debce14f00887227594R104-R110 - in this example we have a child component which inherits from a fully inlined component, but the child provides a template file for a variant call (it could be a default call either).
In my changes I am allowing this - my reasoning is there's a clear use case in our usage of ViewComponent for this. i.e. we have a Base component which has a def call which covers most cases for any child components that inherit from it, however there are cases when a template file may be required, so allowing this would seem to make some sense. Effectively I'm limiting the scope of the template file and inline render method check to only the render methods on that instance.
Let me know what you think!

@joelhawksley thanks for the comments! I have updated - I think this is looking tidier to me now..
One thing - when defining the variants method I've used define_singleton_method, it feels a bit more appropriate here (compared to class_eval) given the method name and content is pretty static - or would you like to keep things consistent here?

@simonrand excellent work! Thank you for your contribution. I look forward to your next PR ❤

Nice one! Thanks @joelhawksley - ended up being quite a bit different to what I intended when I started, but I think the result ended up being good!
This is an important feature for something we're working on, I'm hoping to be able to push something solid on that soon - I'll probably let you know when this happens (via issues) as I think it might have some possible (if quite specific) benefits in some use cases..
Thanks again for the work on this!


Create enumerable

In this pull request, @CarlosIgreda and @LarryIVC, did the following:

[ ] Used GitFlow.
[ ] Added a branch.
[ ] Created an Enumerable on Ruby.
[ ] Created MyList class.
[ ] Implemented #all?, #any?, and #filter methods.
[ ] Install and check the linter.

Next, we'd like to present an image with the result of the proposed problem.

Thanks @Rustamxon7


support for datetime/smalldatetime using TVP

Codecov Report

Merging #407 into dev will increase coverage by 0.01%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##                dev     #407      +/-   ##
============================================
+ Coverage     44.98%   44.99%   +0.01%
+ Complexity     2133     2130       -3
============================================
  Files           107      107
  Lines         24661    24661
  Branches       4102     4102
============================================
+ Hits          11093    11097       +4
+ Misses        11711    11702       -9
- Partials       1857     1862       +5

Flag
Coverage Δ
Complexity Δ

#JDBC41
44.77% <ø> (+0.01%)
2119 <ø> (-2)
:arrow_down:

#JDBC42
44.79% <ø> (-0.02%)
2123 <ø> (-4)

Impacted Files
Coverage Δ
Complexity Δ

...in/java/com/microsoft/sqlserver/jdbc/IOBuffer.java
54.95% <ø> (+0.37%)
0 <0> (ø)
:arrow_down:

...m/microsoft/sqlserver/jdbc/SQLServerDataTable.java
49.13% <ø> (ø)
13 <0> (ø)
:arrow_down:

...ncurrentlinkedhashmap/ConcurrentLinkedHashMap.java
42.2% <0%> (-0.44%)
46% <0%> (-1%)

...m/microsoft/sqlserver/jdbc/SQLServerResultSet.java
31.84% <0%> (-0.21%)
242% <0%> (-1%)

...om/microsoft/sqlserver/jdbc/SQLServerBulkCopy.java
49.71% <0%> (-0.08%)
212% <0%> (-1%)

...om/microsoft/sqlserver/jdbc/ReaderInputStream.java
46.06% <0%> (ø)
17% <0%> (ø)
:arrow_down:

...c/main/java/com/microsoft/sqlserver/jdbc/Util.java
60.25% <0%> (+0.21%)
91% <0%> (ø)
:arrow_down:

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 9f9e78e...a87c907. Read the comment docs.

fixes #408

closing this as opened another one #435


[BUG] - streamlit crashed when running from python directly

Describe the bug
When running streamlit run main.py the files runs without issue
However, when running python3 main.py it will crash and attribute it to streamlit-analytics2
To Reproduce
Steps to reproduce the behavior:

write boilerplate streamlit file as main.py
install streamlit and streamlit-analytics2
enter python3 main.py

Expected behavior
streamlit should run as expected, as seen with streamlit run main.py
Confirmed that this has no correlation to the streamlit-analytics2 migration as it appears on the upstream as well
Error text
python3 main.py
2024-03-02 08:46:19.021 WARNING streamlit.runtime.state.session_state_proxy: Session state does not function when running a script without `streamlit run`
Traceback (most recent call last):
  File "/home/codespace/.python/current/lib/python3.10/site-packages/streamlit/runtime/state/session_state.py", line 398, in __getitem__
    return self._getitem(widget_id, key)
  File "/home/codespace/.python/current/lib/python3.10/site-packages/streamlit/runtime/state/session_state.py", line 443, in _getitem
    raise KeyError
KeyError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/codespace/.python/current/lib/python3.10/site-packages/streamlit/runtime/state/session_state_proxy.py", line 119, in __getattr__
    return self[key]
  File "/home/codespace/.python/current/lib/python3.10/site-packages/streamlit/runtime/state/session_state_proxy.py", line 90, in __getitem__
    return get_session_state()[key]
  File "/home/codespace/.python/current/lib/python3.10/site-packages/streamlit/runtime/state/safe_session_state.py", line 91, in __getitem__
    return self._state[key]
  File "/home/codespace/.python/current/lib/python3.10/site-packages/streamlit/runtime/state/session_state.py", line 400, in __getitem__
    raise KeyError(_missing_key_error_message(key))
KeyError: 'st.session_state has no key "last_time". Did you forget to initialize it? More info: https://docs.streamlit.io/library/advanced-features/session-state#initialization'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/workspaces/codespaces-blank/main.py", line 4, in <module>
    with streamlit_analytics.track():
  File "/home/codespace/.python/current/lib/python3.10/contextlib.py", line 135, in __enter__
    return next(self.gen)
  File "/home/codespace/.python/current/lib/python3.10/site-packages/streamlit_analytics2/main.py", line 425, in track
    start_tracking(
  File "/home/codespace/.python/current/lib/python3.10/site-packages/streamlit_analytics2/main.py", line 276, in start_tracking
    _track_user()
  File "/home/codespace/.python/current/lib/python3.10/site-packages/streamlit_analytics2/main.py", line 78, in _track_user
    counts["total_time_seconds"] += (now - st.session_state.last_time).total_seconds()
  File "/home/codespace/.python/current/lib/python3.10/site-packages/streamlit/runtime/state/session_state_proxy.py", line 121, in __getattr__
    raise AttributeError(_missing_attr_error_message(key))
AttributeError: st.session_state has no attribute "last_time". Did you forget to initialize it? More info: https://docs.streamlit.io/library/advanced-features/session-state#initialization

Closing this as it seems to WAI.
proof: https://docs.streamlit.io/knowledge-base/using-streamlit/how-do-i-run-my-streamlit-script
One should run streamlit via streamlit run xyz.py and not python3 xyz.py


WILDS smoke testing

In this PR:

Added smoke test script
Added instructions on how to run the smoke tests
Added instructions on how to run the evaluation script to the main README

Runs: https://worksheets.codalab.org/worksheets/0xacd40b3e4991410b98643b9cc0b10347

Closing this PR for now since we will use a separate repository for testing.


chore: Delete migrations older than v1.9.2, the last checkpoint version

We delete migrations that are ineffective on a fresh installation. For example, migrations that modify existing workspaces or applications etc.
We add a check to avoid reusing the same migration ids in the future.
Deleted all unused methods in the changelog classes, that were once used in the migrations that now no longer exist.

/ok-to-test

/ok-to-test

/ok-to-test

That test failure doesn't make sense. Looks like it should've passed.


Support redirectToDefaultLang in static mode

Regarding #77. It worked locally for me.

Wow! Thanks a lot for the contribution @justincy ! LGTM!


Remove unnecessary dependencies (flake-utils)

This project/overlay was using both flake-utils & nix-filter. The former is obsoleted (in this context) by lib.genAttrs […] & the latter by lib.fileset. Where flake-utils makes sense is only in the context of distributing a flake for users while not having nixpkgs & its lib as a dependency—but since nixpkgs is dependency & is coming from the flake input in this project/overlay, there is no need to depend on flake-utils.
As this project is used by downstream projects, it is important to keep the flake inputs to the bare minimum since all inputs will become dependencies in those downstream projects (where all dependencies require maintenance & auditing). It is also virtuous to set a good example for those projects since a lot of those users will be primarily OCaml developers, not Nix developers & therefore using Nix as primarily a tool for a job while looking to upstream for best practices.
Not only does this eliminate dependencies, but the diff shows -69 -38 lines of code changed… & less code means less to maintain.
[^1]
[^1]: Please consider giving up MS GitHub or offering a non-proprietary, non-US-corporate-controlled mirror for this free software project. I wish to delete this Microsoft account in the future, but I need more projects like this to support alternative methods to send patches & contribute.

thanks, this makes sense


update sidebar to include ybribe section

I was trying to join this with with #278 and #279 and it seems to not fit (file names not matching the ones here in the sidebar)
can you remake the three PRs as one? would be better to catch this type of error :)


Fix thread header becoming invisible after toggling resolved-state

Describe what this PR does / why we need it
When resolving threads via Octo thread [un]resolve the virtual text of the thread should be updated with the new resolved-state. Currently the text only gets cleared due to an oversight.
Does this pull request fix one issue?

Fixes #362
Describe how you did it
Added a field, which was needed since a feature commit
Describe how to verify it
Tested it within the timeline (Octo pr list)  aswell as within the review mode (Octo review start). Just resolved and unresolved some threads.
Special notes for reviews
Fwiw this seems to be introduced with the commit 50704c5071e9dd4a5643f55403f146b2bbe710bc.
I have added a for loop to gather the commit sha of the actual thread from the response from github. If there is an easier way, Im happy to change it.
Sidenote: the duplicated code between resolve_thread and unresolve_thread increases with this commit. If you want, I can extract those twenty-ish lines into another function

Thanks for the fix! Yep, I think it will be better to move the shared code to its own function. Can you please do that?

Sure, I extracted the logic. Let me know if there is anything else to fix

Nice! Thanks a lot!


Support backwards compatibility with mlrose-hiive

Issue Summary
Refactored code needs to be further revised to ensure backward compatibility with mlrose-hiive.

Progress towards supporting backward compatibility

[ ] Class names

[ ] .algorithms

[ ] .decay

[x] GeomDecay -> GeometricDecay
[ ] ArithDecay -> ArithmeticDecay
[ ] ExpDecay -> ExponentialDecay
[ ] CustomSchedule -> CustomDecay

[ ] .mutators

[ ] ChangeOneMutator -> SingleGeneMutator
[ ] DiscreteMutator -> DiscreteGeneMutator
[ ] ShiftOneMutator -> SingleShiftMutator
[ ] SwapMutator -> GeneSwapMutator

[ ] .fitness

[ ] TravellingSales -> TravellingSalesperson

[ ] .samples

[ ] SyntheticData -> SyntheticDataGenerator

[ ] Method names

[ ] Requires investigation

[ ] Method property names

[ ] Requires investigation

[ ] Method returned object/dictionary attributes

[ ] Requires investigation

Update
I've decided that the classes, methods, properties, and attributes should be renamed back to their original names for the time being. This revision will inherently support backwards compatibility with mlrose-hiive.
At this time, only the renamed classes have been documented in the comment above, so we'll start with reverting the class names.
The other renamed entities will be more difficult to track down, but they might be just as important as the class names.

@gitongah want me to leave the last two class names for you to rename, or you want me to do it?

Finished method names check for .algorithms.decay.

Finished method name check for .algorithms.crossovers

Finished method name check for .algorithms.mutators all the same with the mlrose-hiive

Finished method name check for the whole algorithms folder and they are the same with mlrose-hiive

Finished method name check for .decorators.short_name_decorator.py we have different names
from the mlrose-hiive

Finished method name check for .fitness and the names match with  mlrose-hiive

Finished method name check for .gridsearch.grid_search_mixin.py we have different name from the mlrose-hiive

Finished method name check  for .runners._nn_runner_base.py and we have a method that is not on the mlrose-hiive.  "dynamic_runner_name" method.
We also have some method name that are different from mlrose-hiive in .runners._runner_base.py

I'm reasonably satisfied with the level of backwards compatibility at this time, so I'm closing this issue.


hotfix: ipex fails since cuda moe kernel is not supported

error like
"Could not import Flash Attention enabled models: No module named 'moe_kernels'"
@danieldk @ErikKaum @Narsil please help review and merge it. thanks

please help merge it ASAP, since it block all the ipex cpu/xpu support in tgi

@yao-matrix

Thanks!


DocsArchive-<IP_ADDRESS>Auto archive content

Please don't merge this PR until target archive repo PR https://github.com/OPS-E2E-PPE/docs-yml-archive-non-versioning-archive/pull/268 is merged into live branch.
Auto archive content to https://github.com/opstest2/docs-yml-archive-non-versioning-archive.git

Docs Build status updates of commit d6fe252:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

.openpublishing.redirection.json
:white_check_mark:Succeeded

docs/TOC.yml
:white_check_mark:Succeeded
View

docs/to-be-archive/level1/article3-1-1.md
:white_check_mark:Succeeded
View

docs/to-be-archive/level1/article3-1-2.md
:white_check_mark:Succeeded
View

docs/to-be-archive/level1/article3-1-3.yml
:white_check_mark:Succeeded
View

docs/to-be-archive/level2/article3-2-1.md
:white_check_mark:Succeeded
View

docs/to-be-archive/level2/article3-2-2.md
:white_check_mark:Succeeded
View

docs/to-be-archive/level2/article3-2-3.yml
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Fail to create a python project on Linux

OS: Linux
Build Version: 20201110.1
Python Version: 3.8.6
Repro Steps:

F1 -> Type and select "Create New Project..." -> Select a blank folder -> Select "Python" language -> Select “python3.8” to create a project.
Check the result.

Expect:
Succeed to create a python project.
Actual:
Fail to create a python project.

More Info:
This issue doesn't reproduce on Win10/Mac.

This is an issue with how Python is setup on that machine. Here's an example result I found where people try to fix the problem: https://github.com/pypa/virtualenv/issues/1059


Reduce the number of directory sync on rowset writing

Summary: Instead of submiting a directory sync request to filesystem
every time a segment file is created, only send one directory sync
request to filesystem after all segment files have been created.
Benchmark:
On my local machine, the time to load 1.2GB CSV file is improved
from 132s to 123s.

run starrocks_be_unittest


Can the parameter type is bool?

like
# File: templates/steps-with-params.yml

parameters:
  runExtendedTests: false

steps:
- script: npm test
- ${{ if eq(parameters.runExtendedTests, true) }}:
  - script: npm test --extended

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 6724abea-bbdc-bf66-ed5e-3214fa6c3e66
Version Independent ID: 4f8dab21-3f0e-da32-cc0e-1d85c13c0065
Content: Job and step templates - Azure Pipelines
Content Source: docs/pipelines/process/templates.md
Product: devops
GitHub Login: @vtbassmatt
Microsoft Alias: alewis

Parameters are all strings. In the explicit parameters block, you don't have to use quotes (because of how we parse YAML) and it will still be treated as a string. In the ${{ }} expression, you must use single quotes: '. It's probably clearer just to use single quotes everywhere.


Improve validation options to allow direct comparison and multi-use

A use case has been raised where it would be good to have validation rules to satisfy conditions like:
Field A is valid when Field B has value X and is not value Z
So the specific use case was when selecting one particular option in a field, certain values in other fields should not be valid (but still displayed). At the moment there is no way of combining validation clauses.
The workaround to this currently is to use a custom validation handler (provided as a prop to the form)

This issue has been addressed by #11 - hopefully this will be sufficient


Support reverse order for Parquet streams

Is your feature request related to a problem or challenge? Please describe what you are trying to do.

I have been evaluating Parquet and Arrow Datafusion for use at my company. While testing out Datafusion I noticed that queries like SELECT * FROM table ORDER BY field DESC LIMIT n causes it to read the whole file, even though the existing data was sorted in ascending order.
Upon further investigation, this made sense because the Parquet reader can't return data in any order except the ordering that it was stored in. But this makes it hard to minimize the amount of work done while executing certain queries, e.g. get the last N events sorted by time before a certain known timestamp (especially for small N).
Describe the solution you'd like

A new function added to ArrowReaderBuilder, something like this:
pub fn with_reverse(self, reverse: bool) -> Self {
    Self { reverse, ..self }
}

which would cause the data to be streamed in the reverse of its native order as well as individual record batches being reversed, respecting limits all the while. E.g. with_limit(100).with_reverse(true) would return the last 100 rows satisfying the query.
Setting with_reverse should probably not affect the order of the row groups, since there are no guarantees on the organization of Parquet row groups anyway.
Describe alternatives you've considered

After realizing that implementing this feature would be non-trivial, I tried implementing my own querying code by fetching a whole row group at a time, using the existing query builder, then reversing the entire row group. See here. It works, but it has to deserialize the entire row group, even though the limit might be 1. A more sophisticated implementation would deserialize only the minimum number of pages before stopping early, as the existing code in the Parquet library does.
If the library had lower-level API it might be possible to support specific use cases like reverse ordering without overloading the existing logic (which is already quite complex by the looks of it). However I am not sure what such an API would look like.
Additional context

which would cause the data to be streamed in the reverse of its native order as well as individual record batches being reversed, respecting limits all the while

Unfortunately the nature of the way parquet data is encoded would make doing this at anything below the row group level likely impractical for a couple of reasons:

With exception to PLAIN encoding, there is no easy way to decode pages in reverse order, as the underlying encodings are length prefixed blocks
The dremel record shredding, especially for repetition levels, is order sensitive

That being said, it is possible to just decode the last n rows using RowFilter, potentially reducing this to a query optimisation problem in DataFusion, as opposed to something needing new functionality in the parquet crate.

Unless I am misunderstanding, I do not think it is possible to select the last N rows subject to a predicate with a RowSelection.

This is actually possible, see https://arrow.apache.org/blog/2022/12/26/querying-parquet-with-millisecond-latency/ for more background on how predicate pushdown works for parquet

Unless I am misunderstanding, I do not think it is possible to select the last N rows subject to a predicate with a RowSelection.

This is actually possible, see https://arrow.apache.org/blog/2022/12/26/querying-parquet-with-millisecond-latency/ for more background on how predicate pushdown works for parquet

I have read this article and am familiar with the RowSelection API. To my understanding, a RowSelection generated by a filter can rule out ranges based on the page statistics but cannot tell you how many matches for a predicate are actually in each page — it can only tell you that a page definitely has zero matches. In the worst case there might only be one match per page that wasn't pruned.  So if I wanted to retrieve exactly N rows satisfying my predicate, I would have to include offsets from the last N pages of the column in the RowSelection, which is maximally pessimistic.
I apologize if I'm wrong, in which case I probably will look like a fool... nonetheless, I would love to be wrong on this particular issue.

I do not think it is possible to select the last N rows subject to a predicate with a RowSelection.

Correct, RowFilter is the machinery that underpins late materialization, which is what would be necessary here. The output of this process is a RowSelection that is then used to read the output columns.
Although now that I write this, whilst there is a mechanism to limit this final computed RowSelection to the first N rows, there isn't a public API to limit this to the last N rows. This should be a very simple addition, I'll add it to my list.


niunit: fix after/before test calls

The specification of nitunit states that before and after methods can be called to initialize or clean test related things:
module my_test_suite

class MyTestSuite
    super TestSuite

    redef fun before_test do
          # complex things to set up the test
    end

    redef fun after_test do
          # complex things to tear down the test
    end

    fun test_foo do end
    fun test_bar do end
end

In the above example, nitunit will call the methods precisely in this order:
test_before
test_foo
test_after
test_before
test_bar
test_after

Before this PR, the before and after methods were only call if a redefinition of the before/after method exists locally in the test suite. Inheritance was not considered:
module my_test_suite

class TestBase
    super TestSuite

    redef fun before_test do # ...
    redef fun after_test do # ...
end

class MyTestSuite
    super TestBase

    fun test_foo do end
    fun test_bar do end
end

So the output was only:
test_foo
test_bar

This PR fixes that behavior.

+1


Prometheus Metrics into Grafana dashboard?

Which version are you using?
v0.13.01
Question
Has anyone managed to get the prometheus metrics into a grafana dashboard and is willing to make a dashboard template available?
Although I can see the metrics at http://serveraddress:9998/metrics, my attempts to get this into grafana are failing.
Thanks

I think you should run Prometheus server for grabbing this metrics
cat prometheus.yml
global:
  scrape_interval:     15s
  evaluation_interval: 15s

rule_files:
      # - "first.rules"

scrape_configs:
  - job_name: rtspserver
    static_configs:
      - targets: ['serveraddress:9998']

run prometheus
docker run -p 9090:9090  -v $PWD/prometheus.yml:/etc/prometheus/prometheus.yml  prom/prometheus

Thanks for your help. This solution worked as expected.

Thanks for your help. This solution worked as expected.


Library/Homebrew/rubocops/uses_from_macos: add ssh-copy-id

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.
[ ] Have you successfully run brew style with your changes locally?
[ ] Have you successfully run brew tests with your changes locally?

See https://github.com/Homebrew/homebrew-core/pull/52658
And sort list alphabetically

Thanks @bayandin!


Output response as Env Var

Assume 2 files where the goal is to output an env var from the request in file 1 and use it in file 2
File 1:
requests:
  test:
    url: https://postman-echo.com/get
    method: GET
    data:
      params:
        foo: bar
    output_env_vars:
      FILE_1_OUTPUT: args.foo

output:
{"args":{"foo":"bar"}}

requests:
  test:
    url: https://postman-echo.com/get
    method: GET
    data:
      params:
        foo: Env(FILE_1_OUTPUT)

Alternative implementation:
Assuming file output from #55
requests:
  file1_test1:
    url: https://postman-echo.com/get
    method: GET
    data:
      params:
        foo: bar
    log:
      file: true

requests:
  file2:
    url: https://postman-echo.com/get
    method: GET
    data:
      params:
        foo: Json(file1_test1.args.foo)

I am having the same thoughts..
Why not just doing all the requests in one file ..
maybe we can chain them when running the tests.yaml files in a folder test ..

As the number of requests approaches 50+ it makes sense to organize them with files and directories. (Postman uses collections and folders)
The ability to specify a directory for execution is a great feature. It allows this:
1-foo_dir
1-foo_file.strest.yml
2-foo_file.strest.yml
2-foo_dir
2-bar_file.strest.yml
etc
Assuming that directory 1 contains a login request, it would be good to use that param in future requests.

I'd prefer to use the existing Value keyword instead of Json but overall it's a good idea

agreed.  Even if it is valuable to output responses to file, the better implementation for variable handling across files is to use Value()


Any way to close a channel explicitly?

crossbeam-channel can detect close when all sender or all receiver are closed. Is it possible to close a channel explicitly? For example, a channel may need to be closed eagerly when one of its other endpionts detects errors.

Is it possible to close a channel explicitly?

Not currently possible, but it'd be fairly easy to implement this feature.

For example, a channel may need to be closed eagerly when one of its other endpionts detects errors.

Isn't the Receiver or Sender going to be dropped anyway when an error is detected? I'm just curious to understand better why channels must be explicitly disconnected in your use case.

Isn't the Receiver or Sender going to be dropped anyway

In my case, there will be some cache that still holds a reference to the sender, and receiver closes only when all senders are closed. So the channel won't be closed immediately.

I'm feeling slightly hesitant to add this feature because it makes the disconnection mechanism a little bit more complicated. But, if futures-channel has this feature, perhaps it's a no-brainer to add it to crossbeam-channel, too...

Could this problem perhaps be solved with a side "shutdown" channel? In such a setup, on the receiving side, you select over your "main" channel, on which "normal" communication comes in, and when a message comes in on the other "shutdown" channel, you shutdown, which would include dropping the receiver of the "main" channel.
I'd say you could even just have a Msg::Shutdown handled on the "main" channel directly, but I'm guessing you don't want the other senders to keep sending messages when the Msg::Shutdown has already been sent, but not yet received? @BusyJay
A bigger challenge would be if you have multiple receivers, since the one message you would send on the "shutdown" channel would not reach all receivers? What to do in that case? Keep sending messages on the "shutdown" channel, until it is disconnected? Or, hide your multiple receivers/workers behind a single intermediary "router", who could then stop forwarding messages once something comes in on the "shutdown" channel...
Also note that the use case for close in futures::channel seems to be the mirror of this problem:

If the Receiver is simply dropped, then it is possible for there to be messages still in the channel that will not be processed. As such, it is usually desirable to perform a "clean" shutdown. To do this, the receiver will first call close, which will prevent any further messages to be sent into the channel. Then, the receiver consumes the channel to completion, at which point the receiver can be dropped
https://rust-lang-nursery.github.io/futures-api-docs/0.3.0-alpha.11/futures/channel/mpsc/index.html#clean-shutdown

I guess that use-case could also be dealt with using some sort of "reverse shutdown" channel, where sending a "normal" message on the "main" channel would consist of selecting over the "send" and a "recv" on a shutdown channel. Then the "main" receiver could, when shutting down, first send a message on the "reverse-shutdown" channel, then drain the "main" channel, and finally drop it?

@gterzian Setting up an auxiliary channel for shutdown is a lot of work and it might be easy to forget to select over the main channel and the shutdown channel.
The use case for Receiver::close() in futures::channel you've mentioned is very compelling. I really like this close-and-drain pattern.

I agree that an auxiliary channel is more complicated than calling a stop method, and I also think one could avoid adding features that could be implemented with basic building blocks, especially when such features could turn a channel into something that it is not(for example, introducing some concept of shared-state, or sync communication for an unbounded channel).
My experience of using channels comes down to an "actor-like" form of concurrent programming, with async message passing, no shared-state, and having the various components in the system run logically "in parallel"(even though they will not all actually run fully in parallel due to physical restrictions of the machine).
From my perspective, the idea of "eagerly closing" a channel, or ensuring errors are "immediately" propagated, points more towards a need for redesigning the system, as opposed to adding such features to the means of communication used by the system. Such redesign could focus on removing the need for errors to "propagate immediately" instead embracing the async nature of message passing.
Although the close use-case mentioned in the futures doc is compelling, it also makes a lot of assumptions about the needs of a given system. If the component holding the receiver has decided to shut itself down, why would it care about messages not yet handled? A "clean" shutdown could as well be argued to be empathically not handling any further messages, even when those have already been "sent" by other components.
Other people are undoubtly using channels differently, especially in the context of futures which come with a very different executing context. That could be an argument against standardizing channel APIs, since the context of their use will be different.

@stjepang It is typically much harder to argue against seemingly harmless API additions. I would instead kindly suggest that we flip the burden here. I think in this case, especially if disconnect is something that could be added in a backwards compatible manner, it would be nice to get more use cases that truly demand it. It introduces a secondary way of shutting down a channel distinct from causing all senders (or all receivers) to be dropped. It's hard to reason about exactly how a secondary shutdown mechanism might be negative, but I could certainly see it resulting in manifest complexity in larger systems. For example, I believe that with today's API, if you know that there are still at least one live sender and one live receiver, then the channel is still connected. If I'm understanding the proposed feature, if you introduced a disconnect method, then this guarantee is no longer possible to make.
There are also potential footguns associated with introducing accessor methods like is_disconnected, where a decision based on it becomes stale and you wind up introducing a race. This is why, for example, chan never had len or is_empty methods.

@BurntSushi That is fair, no need to rush with a decision here!

For example, I believe that with today's API, if you know that there are still at least one live sender and one live receiver, then the channel is still connected.

Yes - this is certainly an invariant one might rely on.

There are also potential footguns associated with introducing accessor methods like is_disconnected, where a decision based on it becomes stale and you wind up introducing a race. This is why, for example, chan never had len or is_empty methods.

Well, len and is_empty are useful - for example, Servo uses these methods to compute the estimated memory usage of channels. Even Go has similar functions.
We could also argue in favor of disconnect() when it comes to races. Currently, there is no "clean" (non-racy) way to drain and disconnect a channel. Even if we do for msg in receiver {}, we can't guarantee there won't be messages left in the channel. That is because send(), try_recv(), and drop(receiver) are racy operations. I'm not even sure there's a way to "fix" Receiver::into_iter() to make it non-racy. But with receiver.disconnect(); for msg in receiver {} we could be sure the channel really gets drained.

Well, len and is_empty are useful - for example, Servo uses these methods to compute the estimated memory usage of channels. Even Go has similar functions.

Yes, I know. :-) I don't think I've ever used them myself, and if I ever saw them used (in Rust or Go code), they would be immediately flagged for closer inspection. I wrote chan without them to see if I could get away with it. But yeah, if it had gotten more popular, I'm certain I would have added them!

Even if we do for msg in receiver {}, we can't guarantee there won't be messages left in the channel. That is because send(), try_recv(), and drop(receiver) are racy operations.

I think I might be missing something here. I had thought that the only way for for msg in receiver {} to terminate would only be if all messages had been received and if all senders were dropped. That is:
let (sender, receiver) = bounded(1);
sender.send(1).unwrap(); // non-blocking
drop(sender); // all senders are gone
assert!(1, receiver.iter().count()); // iterator still consumes everything

Ugh, sorry, I got myself confused here! That was a bad example and what you said is correct. :)
So my point was supposed to be about termination from the receiver side as follows:
// Receiver is shutting down. Consume all remaining messages.
for msg in receiver.try_iter() {
    do_something(msg);
}

// Disconnect.
drop(receiver);

This is racy because messages could be pushed just before we disconnect.
However, with explicit disconnect() we can tell senders to stop producing work before we drain the channel:
// Disconnect.
receiver.disconnect();

// Receiver is shutting down. Consume all remaining messages.
for msg in receiver.try_iter() {
    do_something(msg);
}

Finally, one more thought - there are cases where disconnect() is more convenient than wrapping a Receiver into Option and Cell so that it can be dropped manually. Consider this:
struct Foo {
    receiver: Cell<Option<Receiver<Message>>>
}

impl Foo {
    fn try_receive_one(&self) -> Option<Message> {
        // Uglier than `self.receiver.try_recv().ok()`.
        let r = self.receiver.take();
        let msg = r.and_then(|r| r.try_recv().ok());
        self.receiver.set(r);
        msg
    }

    fn shutdown(&self) {
        // `self.receiver.disconnect()` would be very handy here.
        self.receiver.set(None);
    }
}

@stjepang Ah ok! So I think I'm still missing something though, because even in your try_iter() example, my understanding is that the only way for drop(receiver) to be executed is if all receivers have been dropped and all remaining messages have been processed.
w.r.t. to your Cell example, I guess I don't feel particularly strong there. I wouldn't bat an eye at Cell<Option<Receiver<Message>>> other than to perhaps ask why not use &mut self without the Cell, and then use self.receiver.take() to drop it. (Or even the more general question of why it needs to be explicitly dropped in the first place, but I'm pre-supposing we've invented a use case for it, which kind of makes me a little uneasy because it's hard to reason about how common it is. It definitely feels uncommon to me.)

my understanding is that the only way for drop(receiver) to be executed is if all receivers have been dropped and all remaining messages have been processed.

Hm, not sure I understand. Suppose there is only one receiver associated with the channel.
It is possible to execute drop(receiver) without consuming a message that gets sent from another thread just before we drop the receiver. That message will be stuck in the channel until it gets destroyed, which is a bit unfortunate.

Errm, sorry, I meant, the only way for drop(receiver) to be executed is if all senders have been dropped and all remaining messages have been processed. Basically what I'm saying is that the termination semantics of the iterator itself should be preventing races.

Oh, oof, I see. TryIter has different termination semantics in that it will quit as soon as it has to block for a message. To me, that's part of the deal here. There's no synchronization point to make sure you've received all messages. I understand now what you're saying about self.disconnect() enabling one to use the API this way, but I don't think I understand why it's desirable.

In the discussion of panic! on send (context here and here) there was a lot of talk about requiring code to be correct by construction.  In particular there's the idea that send panics by default because code that could send to a disconnected channel is already deadlock-prone by construction (discussion on #314).
I've been doing some thinking about what "correct by construction" means, and if there's a straightforward set of patterns that can be applied that are correct.
@emk gave an example of structuring UNIX pipeline style code in this reddit comment and in this github comment:

data_producer | data_transformer | data_sink

I've attempted to write robust example code implementing this, but I've had great difficulty creating something that isn't excessively verbose, but is also robust against errors and race free. I think verbosity is important because the verbose option isn't going to be the default option users reach for.  I think this applies both to crossbeam-channels and tokio channels.
One difficulty is that if data_sink gets EOF from its Receiver it doesn't know if it's because data_transformer finished sending data, or if it's because it encountered an unexpected error and the Sender was just dropped. I would propose adding a method:
fn close(self);

and extending RecvError to be able to distinguish between disconnection because the send side called Sender::close and closing because the Sender was dropped.
Then the pattern is: do your work, and once you know that all the work is done successfully call close.  This is inspired by the C++ "commit or rollback" idiom where you call a function after doing fallible work to say that no failures occurred.
This is different than the explicit disconnect proposed above because it consumes the Sender rather than leaving a Sender around that can't be used.  AIUI the motivation for mut& is so you can avoid storing your Senders as Option<Sender>, whereas the motivation for close is robustness.  Possibly I should raise this as a separate issue?
Problems with this approach:

The semantics are clear for SPMC, but not so for MPMC.  Options:

Calling close on one Sender should probably cause send on other Senders of the same channel to panic.
A new SPMC channel type could be made available with a close method, while MPMC continues to lack this ability
All Senders must call close for the receiver to be told that the channel was shutdown cleanly.

It doesn't help to detect errors where the Sender is not dropped, like deadlocks/livelocks - but if a deadlock detection/recovery system is in place this approach could compliment it.

Alternatives and extensions:

Don't modify channel and send an enum with an explicit end value.  So instead of Sender<T> use enum { Value(T), SuccessfulShutdown }.  This has the disadvantage (or possible advantage?) that you can carry on calling send(Value(xyz)) after calling send(SuccessfulShutdown).
Have a second error channel and use something like scopeguard to notify down that channel when something goes wrong, rather than calling close once everything's gone right.  I think a second channel possibly makes things much more verbose.  I also think calling a method on success is easier to understand than trying to distinguish between success and failure using scopes.
Allow sending a payload with close so Sender<T> becomes Sender<T, FinalT> and close(self) becomes close(self, value: FinalT). The return value from recv would also have to be modified. This way you can provide even more context to the receiver.  This would make dealing with MPMC even trickier, but could be worth the complexity.  This would be analogous to a [Generator][5] which has seperate yield and return types.

[5]:

One difficulty is that if data_sink gets EOF from its Receiver it doesn't know if it's because data_transformer finished sending data, or if it's because it encountered an unexpected error and the Sender was just dropped.

One trick which helps a bit with this is declaring the channel to hold a Result<T, Error>, and when the sender encounters an error, forward it to the channel before closing.
This is not necessarily robust in the face of panics, however. On the other hand, I generally run with panic = "abort", because I've seen plenty of Rust libraries fail in annoying ways when a background worker panics. But that's not a general solution.

One trick which helps a bit with this is declaring the channel to hold a Result<T, Error>, and when the sender encounters an error, forward it to the channel before closing.

Indeed.  This is a pattern I tried, but I've found it quite awkward to implement in practice.  It's tricky to ensure that you're catching all the appropriate errors from all the call sites to forward them, and as you say it doesn't help with panics.  Panics are where scopeguard can come in handy, but it's a lot less obvious what's happening then.  Using scopeguard to notify errors when async Futures are dropped would probably be possible too, but it's more work, so I would guess in the common case it probably wouldn't be implemented at all, let alone correctly.  As you know, you discuss this case in your blog post "await may never return".

Yeah, in my personal experience the sending code has often (fortunately!) been less than 20 lines of code, so it's possible to keep track of errors and panics. Let's assume that you're implementing something like my "pipes" example. In the more complicated cases—for example, if the sending end can be shut down by a timeout or a dropped future—then probably you'd want a type like:
enum Piped<T> {
    Message(T),
    Done,
}

...and an stream item type of Result<Piped<T>, Error>. If the channel closes without receiving Ok(Message::Done), then it has failed.
This has the advantage that you can wrap an existing channel sender & receiver, adding the behavior needed for this use case.
It's entirely possible that I'm overlooking something. I usually am. I personally find that channels are a surprisingly difficult concurrency primitive, at least once I get into these details.

As another data point, I've decided to use Option<T> as message type to signal to recv that the channel is done, and there won't be more messages. Instead of using try_recv and sleeping the thread when we get None, this makes it possible to block the receiver thread/loop indefinitely, and quit gracefully when the main thread sends a None message.

heh, this is a fairly good and old issue. :) fyi, I'm creating a pr for this: #959

As one who has come from Go, I miss this feature. It's customary in Go for the writer (sender) to close the channel. For example, a jobs channel will be closed when there are no more jobs. The receiver goroutines will consume everything, then detect that the channel has been closed, and exit. If we didn't close the channel, they wouldn't exit, thus creating a leak.

@iesahin Option<T> isn't really a solution when there are multiple receivers.

Ah, I see. One can just drop() the sender.


gdal_calc:  RuntimeWarning: invalid value encountered in divide

          Thanks for your response. However, it seems that I've encountered an new issue during the 'isolated filter' step. What could be a possible solution?

isolated filter==============================================
processing 1=wet 0=dry WSE mask for WBT
GDAL command:
gdal_calc.bat --overwrite --calc "A/A" --format netCDF --type Float32 --NoDataValue -9999.0 -A C:\Users\19107\AppData\Local\Temp\tmpl9pn0jcg\05bdem_mask.tif --A_band 1 --outfile C:/Users/19107/AppData/Local/Temp/processing_xmPXoX/71567c8162904bc497700341ede4e71b/OUTPUT.nc
GDAL command output:
:1: RuntimeWarning: invalid value encountered in divide
0...10...20...30...40...50...60...70...80...90...100 - done.
Process completed successfully
Results: {'OUTPUT': 'C:/Users/19107/AppData/Local/Temp/processing_xmPXoX/71567c8162904bc497700341ede4e71b/OUTPUT.nc'}
Results: {'OUTPUT': 'C:\Users\19107\AppData\Local\Temp\tmpl9pn0jcg\filter_isolated\01_WSEmask_f4yzhird.tif'}
processing clump mosaic from WSE mask
WhiteboxTools command:
"D:/WBT/whitebox_tools.exe" -v=true --compress_rasters=True --max_procs=12 --run=Clump --input="C:\Users\19107\AppData\Local\Temp\tmpl9pn0jcg\filter_isolated\01_WSEmask_f4yzhird.tif" --diag="False" --zero_back="True" --output="C:\Users\19107\AppData\Local\Temp\tmpl9pn0jcg\filter_isolated\02_clumps_k3yx23_6.tif"
WhiteboxTools output:

Welcome to Clump *
Powered by WhiteboxTools *
www.whiteboxgeo.com *

Reading data...
thread 'main' panicked at 'The TIFF file does not contain geokeys', whitebox-tools-app\src\main.rs:72:21
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
Process returned error code 101
Results: {'output': 'C:\Users\19107\AppData\Local\Temp\tmpl9pn0jcg\filter_isolated\02_clumps_k3yx23_6.tif'}
Unable to execute algorithm
Could not load source layer for input: C:\Users\19107\AppData\Local\Temp\tmpl9pn0jcg\filter_isolated\02_clumps_k3yx23_6.tif not found
Unable to execute algorithm
Could not load source layer for input: C:\Users\19107\AppData\Local\Temp\tmpl9pn0jcg\filter_isolated\02_clumps_k3yx23_6.tif not found
Execution failed after 4.58 seconds
Originally posted by @rumeitang in https://github.com/cefect/FloodRescaler/issues/12#issuecomment-1890941993

it looks like there is an issue with converting the downscaled output WSE into a binary inundation raster (gdal_calc --A/A). I would try starting with a very small test area, and seeing if you can reproduce the issue. If this doesn't solve the problem, please send the input files and the logs and I can take a look.
good luck! @rumeitang

inputs&log.zip
Here are the input files and the log for your reference.

Thank you for the input data. Contrary to my first guess, this doesn't seem to be a 'divide by zero' issue, but a limitation of the clump selection (i.e. isolated filter). This shows the clumps:

in the current version, the largest clump is simply selected (which in your case is the NE purple blob).  On my to-do  list is to implement the more sophisticated pixel-selection from the pure-python version.
as a workaround, you could do one of the following:

manually finish the algorithm starting from the isolated filter step (selecting all of the clumps you're interested in)
temporarily edit this line to point to a manually created raster mask that includes all the clumps you're interested in
pre-process the DEM to mask out the problematic regions (this will be challenging in your case as the downscaled result is also discontinuous)

Hopefully I can implement a more permanent fix soon

@rumeitang, try using the new 'pixel' based method I just pushed. This should give you some reasonable results in the upper part of your reach (the lower part is quite flat and there is no obvious floodplain).


Adds the ability to maintain multiple instances of precip

Adds the ability to maintain multiple instances of precip, without overwriting a previously provisioned/run instance’s VM configuration in the provider. Although this does not allow for multiple instances of precip to run simultaneously (IP assignments, DNS names), it greatly improves the ability for developers to test and troubleshoot different versions without harming their stable, working precip VM.

Implemented this functionality via a new optional config.rb variable over here: https://github.com/clwdev/precip/pull/53/commits/cd3c28c5695658a496924f5e9cbbabaad8af97be


notoire_file_extension is not used when creating links

When I set up notoire_file_extension = 'md' and create a new zettel with :NotoireCreateLink it creates link like the following [second one](2) which is not a valid link when commiting this to github. Is there a possibility to create the link with the extension like this: [second one](2.md)? Thank you.

Hello,
I'm not sure what you mean by "it's not a valid link committing this to github".
It is the intended behavior that no file extension is displayed in the notes (for clarity). It's all handled internally.
Is there something you want to achieve in particular with the file extensions?

Hello Kevin,
Sorry for not making it clear. So I created a test repository on github to show it: https://github.com/nakedpony/zettel
If you click first link from README.md it will not work, but the second one will.

Thanks I see now. I added an option to add the file extension in the links: https://github.com/KevinBockelandt/notoire/blob/5dd9b3f4e94eef1bd220699ca386118b6dcbf260/doc/notoire.txt#L140
Beware though that links should be consistent. All of them without extensions or all of them with extensions and the option active. If they are mixed some search features of Notoire will not work properly.
Tell me if that's ok with you :)

Hey Kevin,
Thank you so much for making changes so quickly. It works perfectly now!
Cheers,
Sergey.


It would be great if you add intellisense support for useToken api

Description
It would be great if you add intellisense support for useToken api,
or do you guy have any suggestions for me to make that happen
thank you
Problem Statement
When I create many custom theme.tokens that very hard to maintain and developing is slow, So for now I create constants for contain keys from tokens but when I create new of tokens that make me have to create new constants too.
That why I looking for intellisense
Proposed Solution or API
fast development, easy to maintain, readable for all tokens, suggestion tokens
Alternatives
No response
Additional Information
No response

Hey @afu-hive, We have added type intellisense for useToken in the latest versions of @gluestack-style/react. Please upgrade to latest version. Let me know if we can improve anything after using it or you face any issues ;)


Some old versions of the QGIS website are online

URL
No response
Type(s) of Problems
No response
Summary
There are some old versions of the QGIS website online:

http://test.qgis.org/html/en/site/index.html

https://timdocs.qgis.org/en/site/index.html

They sometime appear in web searches confusing the users.
I don't know if there are also other ones.

It looks like https://timdocs.qgis.org/en/site/index.html is no longer available, while http://test.qgis.org/html/en/site/index.html is still available.


Allow 1D RTrees

[X] I agree to follow the project's code of conduct.
[X] I added an entry to rstar/CHANGELOG.md if knowledge of this change could be valuable to users.

This PR removes the parameter validation to allow 1D RTrees to be created.
1D RTrees already seem to work fine as far as I can tell from a simple example I just tested. I've looked through the places where we reference "dimensions" but most of them just loop from 0..dimensions. We even explicitly support single dimensions in 1D tuples and some other places.
Motivation described in #111
Edit: actually it looks like there are some places where it's returning false positives, I'll take a look

Edit: actually it looks like there are some places where it's returning false positives, I'll take a look

Ah, I just saw your edit.

I don't think the point of not allowing one-dimensional geometry that it would not work, but rather that R trees are considerably over-engineered for the one-dimensional problem. I think the closest analogue is an interval tree which we for example use for time range queries (where we use an R tree for spatial queries).
I do think that all operations we provide here collapse to the interval tree version for the one-dimensional case, but it seems questionable to use this instead of providing a proper interval tree structure. Consider for example distance computations where we would uselessly compute squares or sometimes even worse square roots when we need the distance instead of the squared distance which would just collapse to computing the absolute value for the interval case.
The main conceptual difference here I think is that basically all nuances around R trees come from having to chose a single dimension each time the search space is to split into smaller parts. A problem which is completely absent when using a single dimension.

@adamreichold Agreed, I'd like to use it for the exact use case of implementing an interval tree. I've evaluated most of the existing interval trees/range maps/segment tree crates but haven't been able to find anything suitable (usually cache-inefficient or inflexible).
My thought was that we could try to specialize the 1D RTree with traits as much as possible (beyond this initial support) to avoid some of the distance tests we need for higher dimensions. It also is totally fair to say we don't want support that complexity here and keep it restricted it to 2D or higher.
RTree already has most of the operations I'd like for the 1D case, so I could copy most of the implementation and remove all of the higher dimension functionality to specialize it, but I was hoping there was a way to share most of the implementation.

My thought was that we could try to specialize the 1D RTree with traits as much as possible (beyond this initial support) to avoid some of the distance tests we need for higher dimensions. It's also totally fair to say we don't want support that complexity here and keep it restricted it to 2D or higher.

I ran into this as well and my take away was that implementing the one-dimensional case from the ground up as an interval is indeed simpler than working to specialize the n-dimensional case trying to achieve a similar efficiency.
(I maintain my own little interval tree called sif-itree so I can memory map it directly, so for me that did solve the flexibility issue because I can implement exactly what I need which is just range queries. I guess PR to improve existing crates if you do not have the memory mapping use case would also be viable. I started out along those lines for example here.)

I don't think it would be too difficult to specialize 1D here, but I'm ok with writing my own outside rstar.
For what it's worth I'd also like to eventually specialize 2D calculations too (e.g., SIMD overlap tests on a specialized 2D-only AABB) while sharing the same tree structure, selection iterators, etc.

For what it's worth I'd also like to eventually specialize 2D calculations too (e.g., SIMD overlap tests on a specialized 2D-only AABB) while sharing the same tree structure, selection iterators, etc.

I think this should be possible by reimplementing the traits defined by this crate and in the 2D case this should also not impose any infrastructure cost that is not actually necessary, in contrast to the one-dimensional case. (I also think we could carry those two-dimensional reimplementations upstream here because 2D is likely a very common case in GIS.)

It looks like the false positives I noticed were due the from_points issue I split off into #170, so this seems to be working fine for 1D.
#[derive(Clone, Debug, PartialEq)]
#[repr(transparent)]
struct IntervalAabb(AABB<(i64,)>);

impl RTreeObject for IntervalAabb {
    type Envelope = AABB<IntervalPoint>;

    fn envelope(&self) -> Self::Envelope {
        self.0
    }
}

let envelopes = vec![
    IntervalAabb(AABB::from_corners((3,), (4,))),
    IntervalAabb(AABB::from_corners((0,), (1,))),
    IntervalAabb(AABB::from_corners((10,), (12,))),
];

let tree = RTree::bulk_load(envelopes);

for x in tree.locate_in_envelope_intersecting(&AABB::from_corners((4,), (11,))) {
    println!("{:?}", x);
}

// Outputs:
// IntervalAabb(AABB { lower: (10,), upper: (12,) })
// IntervalAabb(AABB { lower: (3,), upper: (4,) })

Happy to close this PR if we'd prefer to keep 1D disabled. Either way it looks like rstar is already set up to handle 1D so it might be nice to expose it for use cases like this.


Add support for blank passwords

The "old" version of zxcvbn supported empty strings, but there was a line in scoring.ts that got tripped up by the empty string. I patched it up and added a test!

Good finding, thanks for the fix! :)


Allow skipping data logging for a trial

Frequently there are filler trials that show up in the final data for an experiment, such as the trial that presents a fixation cross prior to the actual stimulus and response.
I think we should allow those trials to be skipped in the data storage with a simple flag, e.g.,
var fixation_trial = {
  type: 'html-keyboard-response',
  stimulus: '+',
  choices: jsPsych.NO_KEYS,
  trial_duration: 500,
  record_data: false
}

Is this a reasonable 8.0 addition, @bjoluc ?


Add "Update Details" Button in view details page of community nurse and details log update

Describe the bug
We can't directly access the edit log update page from the view details page of the community nurse or the detail log update page.
To Reproduce
Steps to reproduce the behavior:

Go to the patient tab
Click on active consultation and click on log update
create a new community nurse log update
On successful creation, in the patient consultation page, switch to "Daily Rounds" view
click the view details page in the community nurse log update card
See error

Expected behavior

[ ] add the "Update details" button, in the view details page of community and detail log update

Screenshots

I want to work on this issue.

I would like work on this, if that's okay.


[BUG] Query.Or is very slow

Version
5.0.7 (Windows 10, .NET Core 2.2)
Describe the bug
Performance degradation between 4.1.4 and 5.0.7. Query.Or is now much slower.
Code to Reproduce
var stopwatch = Stopwatch.StartNew();

var query = Query.EQ("field", "value");
for (var i = 0; i < 100; i++)
{
    query = Query.Or(query, Query.EQ("field", i.ToString()));
}

Console.WriteLine(stopwatch.ElapsedMilliseconds); // Takes 2ms in 4.1.4 and 2503ms in 5.0.7

Or and And operation, it will compiles whole expression to string, concat them with and/or and recompiles them from string to expression object, that's the reason it runs so slow.


字体和大小怎么修改？

你好
请问博客的字体，还有字体大小在哪里修改？

I have the same question, when I search for the answer here, then, I find your unsolved question.
I find the solution from other issues. You could modify the file themes/pure/assets/css/style.css and search for the key font-size, and there is one item locates at the body bracket. Its origin value is 14px, you could change its value to change the font size.

thank you！我还想问下代码框里的字体怎么修改。


Freemarker template exception in Associated Parties

What steps will reproduce the problem?
1. Open the Associated Parties metadata form
2. Click on the "add associated parties link"
3. Click on the "Save" button without entering any data

What version of the provider software are you using? The version should be
displayed in the footer of any page.

Version 2.0RC3-SNAPSHOT-r2703

What browser are you using?

Chrome

Please provide any additional information below.

Here is  the beginning of the exception text:

Expression eml.associatedParties[item_index].role is undefined on line 64, column 149
in WEB-INF/pages/manage/eml/parties.ftl.
The problematic instruction:
----------
==> ${eml.associatedParties[item_index].role} [on line 64, column 147 in WEB-INF/pages/manage/eml/parties.ftl]
 in user-directive select [on line 64, column 33 in WEB-INF/pages/manage/eml/parties.ftl]

Original issue reported on code.google.com by gtuco.btuco on 2010-12-21 02:59:44

This issue was closed as a duplicate of #537 on Dec 21, 2010


revert: rbd: consider remote image health for primary

When the image is force promoted to primary on the cluster the remote image might not be in a replaying
state because due to the split-brain state. This PR reverts back the commit c3c87f2ef33e8d8ad08d7d9f28b59d1aedc4ef31. Which we added to check the remote image status.
closes: #3215
Signed-off-by: Madhu Rajanna<EMAIL_ADDRESS>

By reverting this, won't you re-introduce the problem that the change addressed? The original commit points to https://bugzilla.redhat.com/show_bug.cgi?id=2014495.

It was not a problem, it's an enhancement we did, as this is getting reverted back I will move the BZ to the next release (downstream )

Can you explain why this is not an issue?

As I mentioned above its an enhancement we tried to due but introduced a regression in a corner case. AFAIK, so revert back is fine

I also expect to see some unit testing for different image/mirroring statuses. This code seems fragile enough that breakage is not easily spotted or detected.

Unit testing is not possible as checkHealthyPrimary makes a ceph call to get the mirroring image details.

The change that introduced the regression was only detected months after is has been merged. Preventing breaking this code in the future should be of the highest priority.

not all the cases can be covered in the happy path testing, as you know testing DR is always hard we get new bugs in different areas when we started exploring different areas.

much appreciated, thanks!

Fixed CI test failure, PTAL

@mergifyio refresh


Hide snippets for unavailable commands

If yum isn't installed, for example, all snippets that start with yum should be hidden

this shouldn't impact startup time
if --show-all is used, there should be no filtering

This is really good idea to achieve since project is grooving well.
I guess more easy to implement, you can define some kind of NAVI_IGNORE variable and users can add their groups there.
NAVI_IGNORE='yum, mac, k8, kubernetes, etc, etc'
In This case it will more more static than yours but still useful
Best Regards

A friend of mine suggested to, instead of checking the availability of a command given its snippet,  introduce a new syntax, as:
% version control
& git

# Change branch
git checkout <branch>

& git would determine that this cheat will only appear if git is installed, for example

Unless I'm wrong, which git can be used to verify that the tool is installed on Linux as well.

@denisidoro
If your leaning towards the new syntax, then it  should be applicable for tag section, command and variables.
let's say you have
% git

# print current commit
git show HEAD

# copy current commit
git show HEAD | pbcopy

If you were to add this new syntax only on the tag level you'd hide both commands because it'll probably be something like & git, pbcopy
If you were to add it only on the lowest level (commands & variables) it would be a huge copy/paste problem, for instance, in the example each command would need git.
I think adding them to all levels and then "merging" them would be the best in terms of UX.
If all the requirements in the tag section pass, you can look at the requirements in the command/variable and if all of them pass, you can show the snippet.

Could you please review https://github.com/denisidoro/navi/pull/258 as a possible workaround?

I'm closing this because there are workarounds for the purpose of hiding unwanted snippets


[Location Types] HTTPGet method returns incorrect status code when data is received from the server

Reproducible: always.
Preconditions

Set HTTP method as GET.

Steps to reproduce

Set the value in the URL field as https://car-project.azurewebsites.net/api/location-types/location-types
Click on the 'Send' button.

Actual result
Method HTTPGet returns status code "200 OK".
Expected result
Method HTTPGet shall return status code "500 Internal Server Error".
Labels to be added
"Bug" ("bug"), Priority ("pri: ")

Bug is fixed.


devServer.js config with environment variable

In devServer.js, instead of
app.listen(3000, 'localhost', function (err) {

for Cloud9 this should be:
app.listen(8080, '<IP_ADDRESS>', function(err) {

and Nitrous.io:
app.listen(3000, '<IP_ADDRESS>', function (err) {

This could be configured with an environment variable.
The console.log output of course would also need to be updated, and for Cloud9 should also mention that Open in Preview should not be used.

Would you like to file a pull request? =)
I don't think we need to specifically mention Cloud9. The environment variables should be enough to allow users to make it work on Cloud9.

Perhaps another approach is a flag on npm start.
Environment Variables are only for Windows (I think), but what if someone wants to run Cloud9 say from a Mac?

Environment variables work great on any platform, but the way you set them varies depending on platform. However, we should not care about how it gets set, and only respect the environment variables if they are set.
So, for example, you could create host and port variables like this:
const {
  host = 'localhost',
  port = 3000
} = process.env;

Now in your cloud9 console, you can set the environment variable before launching the service:
set HOST='<IP_ADDRESS>'
set PORT=8080
npm start

I see, and the Readme would give the details for Cloud9, Nitrous etc.
But what is wrong with having:
set cloud='c9'
npm start

Is it that if Cloud9 would ever change their config, the burden is on the software maintainer -- and not the user -- to conform to the update? But even so, the Readme (part of the 'software') would still need to be updated. One might suggest that the Readme simply end with caveat 'as of this writing' after giving the hardcoded constants...

I plan to file pull request for this.

There doesn't seem to be anything to test, but yet a test there must be...

I am stuck on manual testing: Unable to set HOST in bash shell.

This codebase is written in ES6.
If HOST is reserved, I'm happy using something less generic like PC_HOST and PC_PORT

When I try to send Pull Request, I get Authentication Failed.

@pdavidow Have you set up your GitHub SSH Keys?

The SSH keys are all set, but it still doesn't help.
Instead, I have pushed branch here: https://github.com/pdavidow/react-pure-component-starter

If you delete that and just hit the fork button on this repo, then pull your fork and merge your changes into that, then push your changes to your fork, you should be able to submit a pull request. You should see a yellow button pop up asking if you want to submit a PR.

See Forking a repo

The deed has been done, I think. A yellow button did pop up, but all it's doing is notifying me of pending CI tests -- it's not asking me to submit a PR.  (Anyway, the reason it didn't originally work is because I had cloned without making a fork.)

Nice.. I'll look over it asap

How would you write tests for this?

Set the environment variable. Launch the server. Use something like supertest to make sure the server responds appropriately to requests on the specified host/port.


Update ComplexWords.yml

https://docs.microsoft.com/en-us/style-guide/a-z-word-list-term-collections/a/ask states "Don't use as a noun. Use request, task, or another suitable word."
This also has a conflict with microsoft.Avoid - which says "don't use ask". So if you put in 'request' it says "use ask" but if you put in "ask" it says "don't use ask".
(Hope I did this correctly!)

Thanks!


Run checks on model after code generation

Requirement got rejected as #129 is what we acctually need.


JSDocTag - Nodes on properties do not have parent set when setParentNodes is true

TypeScript Version:  3.2.0-dev.20181103
Search Terms: jsdoc no parent
Code
import * as ts from "typescript";

console.log(ts.version);

const testFilePath = "/file.ts";
const testFileText = `
class Test {
    /** @internal */
    test() {
    }
}
`;

const testSourceFile = ts.createSourceFile(testFilePath, testFileText, ts.ScriptTarget.Latest, true);
const classDec = testSourceFile.statements.find(ts.isClassDeclaration)!;
const method = classDec.members.find(ts.isMethodDeclaration)!;
const tag = ts.getJSDocTags(method)[0];
const tagName = tag.tagName; // also happens with atToken

console.log(tag.parent != null); // true, good
console.log(tagName.parent); // undefined, problem

Expected behavior: Should return the tag as the parent.
Actual behavior: Returns undefined.
IdentifierObject {
  pos: 23,
  end: 31,
  flags: 0,
  parent: undefined,
  escapedText: 'internal'
}

Fix?
I believe the fix here would be to have forEachChild visit the tagName and atToken for JSDocTags and the nodes that extend them. I'm not sure though...
tag.forEachChild(node => {
    console.log("here"); // never happens
});

Thanks @ajafff!


a head request is done in Chrome when there is no extension in the URL

Have you read the FAQ and checked for duplicate open issues?
Yes
What link can we use to reproduce this?
will provide when needed
What version of Shaka Player are you using?
v3.0.7-uncompiled
What browser and OS are you using?
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.96 Safari/537.36
What did you do?
We use an external service to do serverside add insertion into our HLS stream and/or VOD. However what we noticed is that the player is doing an HEAD request in chrome because there's no extension on the segments. I understand that this is done to determine the mime type, but the HEAD fails with a 404 and the streams stops.
What did you expect to happen?
I would expect if the HEAD fails, that the stream continues with a GET, OR that there's no HEAD request at all.
What actually happened?
The head request only seems to be done on chrome (not on safari and/or firefox).
chrome:

firefox:

I will provide a sample stream if needed

If you could provide a manifest URL, it would help verify we got it.  But I think the problem is here.
The problem is that if we make a full request, it will download a large segment that we'll just throw away (and the browser may not cache it correctly).  If we try a partial request, it may not be supported by the web server and require us to make a full request anyway.  Since this seems like an edge case and would require downloading large segments, I'm going to mark this as an enhancement and put it on the backlog.

Here's an idea: how about if there's no extension and a HEAD request fails, we fall back to assuming it's MP4?  This will only impact HLS content which is lacking in both MIME type metadata and segment file extensions.  It would be cheap and easy to implement, and could be cherry-picked to v3.0.x and v2.5.x.

@joeyparrish If I understand this issue correctly, hlsparser.js tries to guess the MIME type inside guessMimeType_(...). It starts with checking the extension of URI inside the first found segment type  EXT-X-MAP. when it fails to map it to any audio, video, or text it attempts to send a Head request to segment URI, it gets the header of URI as a response. If it fails to get any extension in the header it throws an error. so for a possible solution, you are proposing to replace throwing an error inside if with a return statement of MimeType as MP4 as per the content type.  so,
Replacing this
if (!contentMimeType) {
      throw new shaka.util.Error(
          shaka.util.Error.Severity.CRITICAL,
          shaka.util.Error.Category.MANIFEST,
          shaka.util.Error.Code.HLS_COULD_NOT_GUESS_MIME_TYPE,
          extension);
    }

with this
if (!contentMimeType) {
      // if the HLS content is lacking in both MIME type metadata and segment file extensions
      // we fallback to assuming its MP4.
      contentMimeType = map[" "];
      return contetMimeType;
    }

shaka.hls.HlsParser.AUDIO_EXTENSIONS_TO_MIME_TYPES_ = {
  .....

  ' ': 'audio/mp4',

  .....
};

shaka.hls.HlsParser.VIDEO_EXTENSIONS_TO_MIME_TYPES_ = {
  ......

  ' ': 'video/mp4',
};

shaka.hls.HlsParser.TEXT_EXTENSIONS_TO_MIME_TYPES_ = {
 .....

  ' ': 'application/mp4',

 .....
};

I don't have a file to reproduce this issue and try the solution so posting it here. Should I add a pr with these changes or is there something wrong with this solution?


Support footnote definitions in output

This patch adds the footnote defintions to the output of this plugin. As part of this, I added the node's attributes to the props for each react component, so you can specify className, id etc.

The footnotes addition looks great, but I don't feel comfortable including all of the node attributes because it introduces the possibility of a DOM Clobbering attack if we allow uncontrolled ids and name attributes.

Would you be happy with a whitelist approach to this? To get the footnotes working we just need to include id and class/className, so just those to start?

The class attribute is fine, but id & name are the ones that open the attack vector.

Hmm, we need to give each footnote definition node an id, otherwise you can't link to them. Have you got a suggested workaround for this?

Are the footnote IDs automatically generated? It looks so in this example, like they'd be fn-1 and so on. In that case that'd be fine.

Yes, the footnote ids are generated, however you can specify named footnotes like [^test]. So for that footnote, it would have an id of fn-test.

@ciaranw you could probably omit that behaviour when compiling though, it’s not essential for functioning but nice slug-sugar and easy to use as an author.

Ok, i've made a couple of changes which allow footnote ids through since they are generated. Otherwise, add all of the nodes attributes to props apart from id and name.

Should this show a footnotes section at the end of the output? Trying this out in our demo shows the footnote properly becoming superscript, but not linked to anything.

It should show the footnotes after all the regular content. There is a test here which shows the current behaviour.

You could be missing the footnotes because your footnote definition is being parsed as a regular definition. The regular definition parser's regex is before the footnote definition regex, and will match unless your footnote definition has at least one space in it:
[^1]: footnote gets parsed as a definition
[^1]: footnote definition gets parsed as a footnote definition
I'd love for this to be merged in to master, since we'd like to use footnotes in markdown on our project, so if there's anything outstanding let me know and I'll get right on to it.

Yep, I was not defining footnotes properly.


fix(location-strategy): find the correct outlet when navigating back and forward

Extend FrameService to return the correct topmost frame
When using TabView, with multiple tabs that have <p-r-o>, the topmost frame will currently return the root <p-r-o> for the current tab item even if there is a child <p-r-o> (even it is the last navigated frame). This will affect back navigation.

Extend FrameService to maintain <p-r-o> frames

Modify ns-location-strategy to mark the correct outlet state as isPageNavigation
In order to recognize the correct currentOutlet, when navigating back and forward, we bind outlets names with their unique Frames and parent outlets (since there could be outlets with the same names but different frame instances).
Knowing the parent outlet, along with its frame, helps us distinguish root and child outlets
Modal view from different tab item issue: When using TabView with multiple tabs that have <p-r-o> the currentOutlet will be the last <p-r-o> that was navigated. This could be wrong since we could be landing on some other tab and decide to show Modal view from it. We need to mark the correct outlet state as isModalNavigation (the outlet from in which the modal view is shown) otherwise the wrong router states will be removed later on (and some other bad things).
When opening modal view we pass the Frame from which the modal view was shown and search for it ( from our Frames collection) in order to find the correct outlet

Add e2e tests for modal-navigation scenarios

TO DO: Extend ns-location-strategy unit tests

test android#4.2.0-2018-06-18-02

test

run ci

For anyone whom is using ~6.1.0 release and your routing is terribly unreliable/broken it's related to this commit and you can fix it by pinning your project to the build right before this commit went in:
"nativescript-angular": "6.1.0-2018-07-03-01",


Logs shouldn't say "Using linked mysql container" when using an external mysql database

A minor issue but enough to lead someone who's troubleshooting astray. The docker logs shouldn't say "Using linked mysql container" when connected to an external mysql database (vs mysql running in a container).

I suspect this happened because you supplied an environmental variable MYSQL_PORT when creating the container? The presence of this variable is what the code used to detect if it was a linked container or not.
This has been changed to check MYSQL_ENV_MYSQL_PASSWORD instead which should hopefully prevent this occurring again if that was the reason.

Yes we did supply the variable, but we pointed it to a non-containerized MySQL instance (so it's a bit misleading for it to say 'linked container'. But it's not a big deal, it's more visual than anything :-)
Thanks for the great container! I learned a lot about supervisord, nginx and alpine from using it.


how to use dynamic template-url

Can template-url value can be dynamically assigned from controller or dom?
I would like to use like this

<ng-pdf template-url={{pdfTemplateUrl}} id="pdfpreview">

Currently whatever value use for template-url is only regarded as string value. Is there a work around to avoid this manner? I also found out that issue #142  is same as this but there is no visible and working answer provided in that issue.

Hi @SwanHtetKyaw24
I think the only solution is to force a compilation using $compile, like in the example at this comment

Thz for reply. I use a work-around by directly using pdf.js and angular-pdf.min.js. In that way, that issue can be avoided though I had to manually create canvas to handle showing PDF.


Fix developer guide

Fix #165
It is due to the development-environment page. By the way, I noticed that there is not link to this page from anywhere. Should I add it somewhere? @alrra

There are some links to it in the pull requests page.

There are some links to it in the pull requests page.


add Razer CChromaEditor

SteamDB app page links to a few games using this
https://steamdb.info/app/552500/
Brief explanation of the change
added a rule for CChromaEditor

Add Razer in the rules' name and add a non matching test