text:
add libqt5-serialport-dev key to provide build headers

Please add the following dependency to the rosdep database.
Package name:
libqt5-serialport-dev
Package Upstream Source:
https://www.qt.io/
https://github.com/qt/qtserialport
Purpose of using this:
This package provides header and Qt5SerialPortConfig.cmake files to build an application using the Qt5::SerialPort module.
Distro packaging links:
Links to Distribution Packages

Debian: https://packages.debian.org/

REQUIRED
https://packages.debian.org/sid/libdevel/libqt5serialport5-dev

Ubuntu: https://packages.ubuntu.com/

REQUIRED
https://packages.ubuntu.com/hirsute/i386/libqt5serialport5-dev/filelist

Fedora: https://src.fedoraproject.org/browse/projects/

IF AVAILABLE

Arch: https://www.archlinux.org/packages/

IF AVAILABLE
https://archlinux.org/packages/extra/x86_64/qt5-serialport/files/

Gentoo: https://packages.gentoo.org/

IF AVAILABLE

macOS: https://formulae.brew.sh/

IF AVAILABLE

Alpine: https://pkgs.alpinelinux.org/packages

IF AVAILABLE

NixOS/nixpkgs: https://search.nixos.org/packages

OPTIONAL

Checks

[ ] All packages have a declared license in the package.xml
[ ] This repository has a LICENSE file
[ ] This package is expected to build on the submitted rosdistro

Could you add?
https://src.fedoraproject.org/rpms/qt5-qtserialport
https://packages.gentoo.org/packages/dev-qt/qtserialport
https://pkgs.alpinelinux.org/package/edge/community/x86/qt5-qtserialport

Hi @ivanpauno thanks for the feedback. Note that there already is a rosdep key for libqt5-serialport and what I want to add is a key for packages that contain the development header and CMake files.

https://src.fedoraproject.org/rpms/qt5-qtserialport

It looks like the fedora package does include this RPM with development files https://koji.fedoraproject.org/koji/rpminfo?rpmID=27106679 so I will specify qt5-qtserialport.

https://packages.gentoo.org/packages/dev-qt/qtserialport

I am having trouble finding the list of files included in that package. Do you have any tips on where that information can be found?

https://pkgs.alpinelinux.org/package/edge/community/x86/qt5-qtserialport

It looks like the alpinelinux package that I want to add is https://pkgs.alpinelinux.org/package/edge/community/armhf/qt5-qtserialport-dev which does include the development headers and CMake Qt5SerialPortConfig.cmake files. I will specify that package.

Hi @ivanpauno thanks for the feedback. Note that there already is a rosdep key for libqt5-serialport and what I want to add is a key for packages that contain the development header and CMake files.

Thanks for clarifying, I didn't notice that.

https://packages.gentoo.org/packages/dev-qt/qtserialport
I am having trouble finding the list of files included in that package. Do you have any tips on where that information can be found?

I couldn't find that, but I think they do include header files there.
e.g.: https://github.com/ros/rosdistro/blob/50786bb7164fdd424a78ced35efa87f4fe33b0e0/rosdep/base.yaml#L4630

@ivandariojr I found a way to list the package contents on this site https://www.portagefilelist.de/site/query/listPackageFiles/?category=dev-qt&package=qtserialport&version=5.9.4&do#result
I confirmed that the gentoo package has the development files so I will add it to the rosdep entry.

authors: ivanpauno zflat


text:
ros_msg_parser: 1.0.0-1 in 'noetic/distribution.yaml' [bloom]

Increasing version of package(s) in repository ros_msg_parser to 1.0.0-1:

upstream repository: https://github.com/facontidavide/ros_msg_parser.git
release repository: https://github.com/facontidavide/ros_msg_parser-release.git
distro file: noetic/distribution.yaml
bloom version: 0.10.7
previous version for package: null

@facontidavide the license tag in the package.xml and the license file don't agree. Once that's fixed up we can merge this release.

Similar to https://github.com/ros/rosdistro/pull/31636#issuecomment-1015679869 closing for now. Please resubmit with the license disparity resolved.

Similar to #31636 (comment) closing for now. Please resubmit with the license disparity resolved.

Hi @tfoote @facontidavide ; this mismatch appears to be resolved; any reason not to merge this?

With the changes upstream, a new release is needed to include those changes into the release. So please make the new release and bloom that release. It will create a new pr which will supercede this one.

source: gharchive/pull-request

authors: danielmohansahu facontidavide nuclearsandwich tfoote

repo: ros/rosdistro

license_type: permissive

license_source: github-api


text:
septentrio_gnss_driver: 1.2.3-1 in 'humble/distribution.yaml' [bloom]

Increasing version of package(s) in repository septentrio_gnss_driver to 1.2.3-1:

upstream repository: https://github.com/septentrio-gnss/septentrio_gnss_driver
release repository: https://github.com/septentrio-users/septentrio_gnss_driver_ros2-release.git
distro file: humble/distribution.yaml
bloom version: 0.11.1
previous version for package: 1.2.2-5

septentrio_gnss_driver
* New Features

  Twist output option

  Example config files for GNSS and INS

  Get leap seconds from receiver

  Firmware check

  VSM from odometry or twist ROS messages

  Add receiver type in case INS is used in GNSS mode

  Add publishing of base vector topics
* Improvements

  Rework RTK corrections parameters and improve flexibility
* Fixes

  /tf not being published without /localization

  Twist covariance matrix of localization

  Support 5 ms period for IMU explicitly

Holding for humble sync: https://discourse.ros.org/t/preparing-for-humble-sync-and-patch-release-2022-11-21/28234

authors: methylDragon tibordome


text:
Refactor to update Kotlin Coroutines

This PR should:

[x] Update gradle dependencies
[ ] Use CoroutineScope instead of GlobalScope on ViewModels
[ ] Fix #11

We should consider upgrading to Retrofit 2.6.0 before merging this.

Closing this, since I'm starting the 2020 challenge.

license: MIT


text:
Coil logger support

Ability to view the log information while processing the image. Currently it doesnot support it.
I had implemented ImageLoaderFactor in the Application Class  with the following snippets:
 return ImageLoader.Builder(this)             .availableMemoryPercentage(0.25) // Use 25% of the application's available memory.             .crossfade(true) // Show a short crossfade when loading images from network or disk.             .componentRegistry {                 add(StorageReferenceFetcher())             }             .apply {                 if (BuildConfig.DEBUG) {                     logger(DebugLogger(Log.VERBOSE))                 }             }             .build()
Ok, never mind. just found out that you can have your own imager loader by using
    FireCoil.setDefaultImageLoader(newImageLoader())

@blacpythoz glad you figured it out :)
I'll close this, since it has been solved.

source: gharchive/issue

authors: blacpythoz rosariopfernandes

repo: rosariopfernandes/firecoil


text:
Dropwizard 4.0.0 and Jakarta Compliance : Resolves #37, Resolves #38

I believe this should be working, it builds fines and all tests pass
Resolves #37, resolves #38
@roskart

@roskart, is there a plan to release these changes?

repo: roskart/dropwizard-jaxws

license_source: bigquery


text:
Page Content: Open Business

From Patrick
8. Open Business
LEARN
You have gone through the entire process and now you’re ready to open.
If you have a brick-and-mortar site, you’ve gone through the 4th floor of Long Beach City Hall and you’re at the final step. Get your Certificate of Occupancy.
You will need:
Certificate of Occupancy Application
DO
Submit Certificate of Occupancy Application
Get final approval.
Start doing business!

LEARN
Once your business license has been issued and all permits approved, the city will issue you a certificate of occupancy for your location. This certificate indicates that your building and facilities meet city safety rules, and allows for utilities (power, water, and gas) to be connected to the building.
Oddly enough, I don't see a CofO application. There's only an application for temporary ones. Perhaps the CofO is automatically issued?
DO

Receive Certificate of Occupancy
Start doing business!

Many free services are available if you need help as you begin doing business. Search here: (Primer Peso link?)

A Temporary Certificate of Occupany may be obtained if part of the building are habitable. It allows for a 90 days period to operate in those TCO areas.
A CO is issued after a final walk-through inspection.

Ok, adjusted above to indicate that the CO is automatic, and does not require an application.

Content has been moved to Google doc for further discussion: https://docs.google.com/document/d/1l5PIDZLrkQpMwqDwpxD-TpEtbE6IyWeQLdXvygtjQWU/edit

repo: rossettistone/bizport

license: mit


text:
Can't change width

I can't manually change the width of a dialog without adding more text.
This is the dialog:
<wired-dialog id="dialog1">

    <wired-input id="name-input" ></wired-input>

      <wired-button id="closeDialog">Done</wired-button>

  </wired-dialog>

and this is the CSS:
#dialog1 {
  width:150px;
  height:120px;
}
#name-input {
 width:150px;
}

and even with adding more text, the input still is not as wide as intended.

Up

Update: I changed the width of the text container and for some reason adding position:absolute to the input allows for changing the width.

repo: rough-stuff/wired-elements


text:
examples 32 and 33 are identical

and this one is really cool BTW!

Thanks

authors: ev-br rougier


text:
🛑 Fossil based IRC Log is down

In 53dd0ff, Fossil based IRC Log (https://rouilj.dynamic-dns.net/fossil/roundup_irc_logs/doc/trunk/log/roundup/) was down:

HTTP code: 503
Response time: 337 ms

Resolved: Fossil based IRC Log is back up in 49aac7d.

repo: rouilj/RoundupAssets


text:
The summary does not update

Connected everything according to the instructions, the page works, data is sent to Firebase and I see it in Rowy.

I can see the voting data, but the totals are not updated

Solved! Reed this page if you have the same problem https://docs.rowy.io/extensions

repo: rowyio/roadmap


text:
Add open-drain output implementation

For convenience, please add an open-drain output implementation. I experimented with the implementation InOutPin used in the example rp2040-hal/examples/dht11.rs for communication with the 1-wire protocol (i.c.w. a DS18B20), but it seems to be unreliable. (Or more accurately: not working at all.)
As stated in the example, it is not possible to drive the pin low before changing the pin mode to output to emulate the open-drain output low state.

// In theory, we should set the pin to low first, to make sure we never actively
// pull it up. But if we try it on the input pin, we get Err(Gpio(InvalidPinType)).

It seems to me this cannot be solved by a custom DynPin implementation (as is done in the example) and should be solved in the rp2040-hal itself. Hence this ticket.
In another hals - e.g. https://github.com/stm32-rs/stm32f3xx-hal - this pin mode is implemented.
I would suggest a method like into_open_drain_output() as used in:
let mut one_wire_pin = pins.gpio0.into_open_drain_output();

To sum up the requirements (please correct me if I am wrong):

the open-drain output Pin should implement the HAL traits OuputPin and InputPin;
when the Pin's method set_low is called, the pin should be set to low and switch its internal mode by using the following ModeFields values: funcsel=SIO_FUNCSEL, sio_outen = true, inen = true and all other fields set to false;
when the Pin's method set_high is called, the pin should switch its internal mode by using the following ModeFields values: funcsel = SIO_FUNCSEL, sio_outen = false, inen = true and all other fields set to false;
switch from low to high and visa versa should be fast.

The main reason for not implementing this so far is that the hardware does not support it. It has to be emulated with controling OE.
The difference with the st hal (and lots of other silicon) is that they do have support for it in hardware (see stm32f3xx reference manual page 228/1141 – 11.3 GPIO Functional description).

Ai, I should have RTFM first. Somehow I got the idea that all modern micro-controllers have no other option than to emulate the open-drain output. (I'm a software developer for many years but a beginner/hobbyist in embedded programming and electronics.)
In this case I might be better of with a I2C to 1-wire bridge (like the DS2482). No any hassle with the 1-wire protocol. (One disadvantage of this option is though, there no lib written in Rust yet for this device.)

Well, that's an opportunity to write a driver for the weekly driver initiative :-)
Seriously: @ithinuel correctly explained why there is no open-drain output implementation. But that doesn't mean that the rp2040 is unable to speak the 1-wire protocol. If the emulated InOutPin doesn't work, we should find out why.

I actually considered adding support for open drain/open collector [by fiddling OE] when doing the conversion to the type-based GPIO, but didn't want the added complexity when the original code didn't support it.

I probably wouldn't call it open drain/open collector. It works similar, but electrically, it's something different. I'm not knowledgeable enough about electrical circuits to tell if it actually makes a difference, so I'd just be cautious and give it some neutral name. That's why I just called it InOutPin in the dht11 example.
And yes, it shouldn't be hard to add. Hardest thing would be to find a good API (ie. as flexible as possible without becoming difficult to use).

authors: anall bartweber ithinuel jannic

repo: rp-rs/rp-hal


text:
🛑 dm.vern.cc is down

In 8e4353c, dm.vern.cc (https://dm.vern.cc) was down:

HTTP code: 0
Response time: 0 ms

Resolved: dm.vern.cc is back up in 18386a0 after 5 minutes.

repo: rramiachraf/dumb-instances


text:
There seems to be an error in file 'nres.py'.

Should “Pz = Pe * p_erle ** 2” be written as “Pz = (Pe * p_erle) ** 2” in function “def get_erle(self, inp)”?

Hello, rrbluke.
I'm sorry. I misunderstood it myself.Your code is right.

repo: rrbluke/NRES


text:
Feat: Add Logging

Topic
Add logging levels to SFM
Service
Backend

Added initial logging to the backend with commit #2874612. Small changes will be needed to incorporate Azure SDK insights once the app is deployed in Azure.

repo: rropen/SFM


text:
ReplayProvider for saving latest values

What I need?
A ReplayProvider that behaves similar to StateProvider but also saves the last X values.
Why?
In many cases I need to compare latest 2-3 values. Best example would be stock/currency prices change animations(usually green flash if goes up, red if down). Or during animating BottomNavigationBar pages, you choose the animation depending on the last index and current index.
Similar Concepts
RxDart has ReplaySubject as most of you know, which is behaves exactly I want. But I don't want to use that bloated inorganic library.

That isn't the responsibility of the providers.
Instead, consider making a custom StateNotifier:
abstract class ReplayStateNotifier<T> extends StateNotifier<T> {
  ReplayStateNotifier({@required T initialValue, @required this.historyLength}):
      _history = [initialValue],
      super(initialValue);

  final int historyLength

  List<T> _history;

  @override
  set state(T value) {
    _history = [value, ...history];
    if (_history.length > historyLength)
      _history.removeLast();
  }
}

@rrousselGit I gout your point, yea Riverpod shouldn't be bloated also 😄  I'm using a similar solution, but I think I should make a library for more opinionated usages of Riverpod.

Indeed
I've seen many people argue that Riverpod already is bloated, so I want to avoid adding too niche features.

Hey @rrousselGit, please be my first code reviewer 😄
abstract class ReplayStateNotifier<T> extends StateNotifier<T> {
  ReplayStateNotifier({@required T initialValue, this.capacity = 2})
      : assert(capacity != null, "Capacity cannot be null"),
        assert(capacity > 1,
            "Capacity must be greater than 1, if it's not consider using `StateNotifier` itself"),
        _queue = ListQueue<T>(capacity)..add(initialValue),
        super(initialValue);

  final int capacity;
  final ListQueue<T> _queue;
  int _size = 1;

  @protected
  @override
  set state(T value) {
    if (_size == capacity) {
      _queue.removeLast();
    } else {
      _size++;
    }
    _queue.addFirst(value);
    state = value;
  }

  List<T> get replay {
    if (_size == capacity) return _queue.toList();
    return _queue.take(_size).toList();
  }

  List<T> take(int count) {
    assert(count > 1, 'Count must be greater than 1, otherwise consider using `state`');
    if (_size < count) throw StateError('Few elements to take');
    if (_size == capacity && count == capacity) return _queue.toList();
    return _queue.take(count).toList();
  }

  T get second => _queue.elementAt(1);

  T get last {
    if (_size == capacity) return _queue.last;
    return _queue.elementAt(_size);
  }
}

After writing tests, I'll publish this and gonna update time to time with new classes.

authors: rrousselGit softronaut


text:
[riverpod_lint] Fix to dart run custom_lint

dart pub custom_lint isn't valid command, and dart run custom_lint is right.

Sorry, duplicated of #2167 🙏

repo: rrousselGit/riverpod


text:
Arrowhead release

ci:arrowhead-600
rskj:ARROWHEAD-6.0.0-rc
rit:arrowhead-600

pipeline:run

repo: rsksmart/powpeg-node


text:
Missing JSON-RPC methods

What

Solves #214

Why

Keep interface updated

circleci error complains about a link to #eth_chainId but that link works


text:
Nested skip behaves weird, is this intended?

Subject of the issue
I run into the issue that my specs run when I didn't expect them to run. I would expect that if I set a block to be skipped, that all nested examples are skipped. This is not always true.
I could not find out if it is on purpose or not. I found it especially weird when I set skip to nil, which of course is falsy. I at least expected nil to take the parent's skip status, instead of disabling skip.
In my case skip was set to nil due to some meta programming. The solution would to remove the skip option in that case.
Your environment

Ruby version: 3.2.2
rspec-core version: 3.12.2

Steps to reproduce
RSpec.describe "skip" do
  describe "", skip: true do
    # I expect all examples to be skipped, no matter if skip is set or not.
    it "is skipped via describe" do
    end
    describe "describe group should be skipped due to parent being skipped" do
      it "is undefined" do end
      it "is nil", skip: nil do end
      it "is false", skip: false do end
      it "is true", skip: true do end
    end
  end
end

Expected behavior
I would expect all nested examples to be skipped
Actual behavior
Not all examples are skipped. Those with skip set to nil or false are run anyway.
**..*
Pending: (Failures listed here are expected and do not affect your suite's status)
  1) skip  is skipped via describe
     # No reason given
     # ./skip_spec.rb:3
  2) skip  describe group should be skipped due to parent being skipped is undefined
     # No reason given
     # ./skip_spec.rb:6
  3) skip  describe group should be skipped due to parent being skipped is true
     # No reason given
     # ./skip_spec.rb:9
5 examples, 0 failures, 3 pending

This is intended, group metadata is copied down to examples and they are processed at that level, so you've essentially overridden the metadata by setting it to falsey.

authors: JonRowe stillhart

repo: rspec/rspec-core


text:
Possible redirect_back support in Rails 5?

Hey all,
I'm game to submit a PR if anyone has a workable approach, but so far I'm stumped here. This question has reference: http://stackoverflow.com/questions/38162970/testing-redirect-back-in-rails-5.
Basically, I'm interested in testing for the usage of the new redirect_back API in Rails, but under the hood it just calls vanilla redirect_to, which makes it a little tough. Meanwhile, I still get a deprecation notice for asserting like:
expect(response).to redirect_to(:back)

That test is still green but clearly deprecated. What would work now, but be more than I really need, would be to 1) send a referer and assert redirection to that referer, and 2) assert redirection to the fallback path provided to redirect_back.
Is anyone else interested in this feature? I can dig some more, but unless someone else sees a clever solution, I think it'd require a PR to actionpack to make them properly aware of redirect_back calls.
Thanks!
Joe

expect(response).to redirect_to('path/to/previous/location')?

Or set a specific referrer header and assert on that?

Oh agreed, those do work, but they seem far less literate than the previous
ability to just check that we redirected to "back".
If it's not enough difference for anyone else I can just use those methods,
but I'll feel like I've lost communicativeness in my tests.
On Jul 6, 2016 5:46 PM, "Jon Rowe" notifications@github.com wrote:

Or set a specific referrer header and assert on that?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/rspec/rspec-rails/issues/1659#issuecomment-230930390,
or mute the thread
https://github.com/notifications/unsubscribe/AASbu6vPySuSmmeApS2M79HRnbpqxXy2ks5qTDBUgaJpZM4JGhSb
.

Unless theres a new rails equivalent theres not much to do about that.

We provide compatability with supported Rails APIs for the versions of Rails we support. That is, if an API is gone in the version of rails you're using, it is not RSpec's responsibility to provide that API instead. Given that Rails is getting rid of the redirect(:back). I don't think this is a feature we should special case.

@jmmastey do you know if Rails is going to provider a assert_redirect_back or the like? I'm guessing this might be a no given there switch away from controller tests...

Thanks for the feedback both of you. Totally agreed / understood that we'd need an API to hook. There's no assert_redirect_back yet, and I don't see any discussion on it. I'm going to close this for now. If I open that conversation and they do provide that assertion, I'll reopen and reapproach the conversation.
Thanks all.

In my test suite, using rails 5.2.3 the following works:
expect(response).to redirect_to 'http://test.hostwhere_I_came_from'

authors: JonRowe jmmastey obromios samphippen

repo: rspec/rspec-rails


text:
Remove incompatible --color CLI option

The option was removed in RSpec 4, see https://github.com/rspec/rspec-core/pull/2864
Follow-up to https://github.com/rspec/rspec-rails/pull/2458

Merging, as there's no external behaviour change, it only affects our builds. To my best knowledge, --color is a no-op, as color_mode is :automatic by default ("the output will be in color if the output is a TTY").


text:
Update rubocop to latest with Ruby 2.2 support

This updates Rubocop from 0.23.0 to 0.32.1 (most recent).
Unfortunately, in order to support this new version, which includes several bug fixes and support for Ruby 2.2, we need to drop support on Ruby 1.9.2. In fact Rubocop dropped 1.9.2 support as of version 0.25.0.
Some additional new cops are now available:

Metrics/AbcSize (Assignment Branch Condition)
Metrics/PerceivedComplexity

There are three additional new cops but they have been disabled (these settings should be ported to rspec-dev as part of the project defaults):

Lint/NonLocalExitFromIterator
This has been disabled due it's inability to distinguish between when / where return is sent from within a block. For example, a DSL block which has an explicit return in a method definition triggers this cop:
some_method do
  def a_local_method
    return if true # triggers cop even though `return` will not exit from the block
  end
end

Style/ParallelAssignment
Rubocop suggested this because it believed that parallel assignment was slower than sequential assignment. Unfortunately the benchmark they reference is flawed due to how Ruby handles implicit returns. It turns out that parallel assignment is faster.

Style/StringLiteralsInInterpolation
We previously disabled the related cop Style/StringLiterals. We simply don't care about single vs double qoutes.

See also: rspec/rspec-dev#134

:frowning: way too many builds. A bit tired so was thrashing trying to get the travis config working. Now that things are green, I'm grabbing a few hours of sleep and will get this cleaned up in the AM.
Also, I'm temporarily dumping the parallel-vs-sequential assignment and symbol-to-proc-vs-block benchmarks to stdout in the script/run_build. You can see how all of the different Ruby versions shape up in the last travis build: https://travis-ci.org/rspec/rspec-support/builds/73746126
I skimmed the benchmarks and it looks like the general trends are:

sequential assignment & blocks are faster on 1.8.7, REE, JRubys
parallel assignment & symbol-to-proc are faster on 1.9.2 through 2.2

There were a lot of numbers to skim over tonight, but I think the benchmarks show that sequential vs parallel assignment really doesn't matter much for us. So we can disable that cop and use what seems best for the situation.
As for the block vs symbol-to-proc, we just need to decide if / when we are going to start following the optimizations for the newer Rubies. Thoughts?
/cc @rspec/rspec

This is good to go.

Good work on the benchmarks, but shouldn't we be doing the config via rspec-dev as its centralised? Also I disagree with one of the style changes but I'm willing to go with the majority obviously :)

but shouldn't we be doing the config via rspec-dev as its centralised?

Bumping rubocop will cause all the builds to fail. We've opened up PRs on all repos that have these fixes as a stop-gap so the new cops can be configured and fixes made. I am going to have a PR open for rspec-mocks tonight, and a PR for rspec-dev with the "master" changes; which I plan to push out after the PRs get merged in so that the build stays happy.

Yeah but we can open the PRs from rspec-dev with the bump and then fix them in those PRS

@JonRowe do you think fix conflicts in a new PR (from this one) could be a good idea? I can work on it.
It seems lot's of things have change since. Maybe it can be close?

@benoittgt feel free to take a shot at rebasing this

Closing for now. In favor of https://github.com/rspec/rspec-support/pull/350

authors: JonRowe benoittgt cupakromer

repo: rspec/rspec-support


text:
Implement logic for predicting exobiology species for planets

Primarily for using in state, but all input should come from a specific struct so the input can be constructed and used in other places as well.

Spawn conditions for all species have already been added to the Species enum, but is currently not really structured in a way that makes it easy to feed input and get a list of possible matches.


text:
Fix install fail when Python version >= 3.10

A bash condition leads to Python 3.10 being "lower" than Python 3.7, thus the installation of fastapi-mvc would fail.
Checklist:

[x] Added tests for changed code where applicable.
[x] Documentation reflects the changes where applicable.
[x] Updated the CHANGELOG.md file with your changes.
[x] My PR is ready to review.

Resolves: #60
Description of the changes being introduced by the pull request: The python version bash condition is changed so Python version >=10 should also pass.

Should I implement #62 in the same PR or should we let this good first issue to anyone that would like to contribute?

@Merinorus Feel free to implement #62 as well if you'd like. Even though it's an easy issue, I don't think it should wait just because of that (at least in this case).

Oops... Github actions thinks it's Python 3.1 instead of 3.10...
https://github.com/actions/setup-python/issues/160#issuecomment-724485470

Yep, I also didn't see that coming :laughing:

Codecov Report

Merging #61 (a29965a) into master (467f29b) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #61   +/-   ##
=======================================
  Coverage   99.49%   99.49%
=======================================
  Files          34       34
  Lines         591      591
=======================================
  Hits          588      588
  Misses          3        3

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 acdde1d...a29965a. Read the comment docs.

Lol, I thought it was easier as well!
I think we need to update tlake8 to 4.0.0 at least.
https://github.com/PyCQA/flake8/issues/1372

Don't worry about failing CI metrics for 3.10; it seems there is a typo.
"$POETRY_HOME"/bin/poetry run flake8 --select=T --tee  --exclude fastapi_mvc/template--output-file=todo_occurence.txt --statistics --count fastapi_mvc tests
# VS
"$POETRY_HOME"/bin/poetry run flake8 --select=T --tee  --exclude fastapi_mvc/template --output-file=todo_occurence.txt --statistics --count fastapi_mvc tests

But I wonder how it didn't fail before for other py versions.

And even if in fact flake8 version bump will be needed it can be done via the separate issue and PR.
If K8s integration will pass, this is good to merge.
Thanks again for the contribution!

authors: Merinorus codecov-commenter rszamszur

repo: rszamszur/fastapi-mvc


text:
PDF builds do not do enough pdflatex runs

Details

Project URL: http://readthedocs.org/projects/sphinx/
Build URL (if applicable): e.g. http://readthedocs.org/projects/sphinx/builds/5413951/

The issue shows for 1.6.1. The PDF is missing "Index" both in the PDF bookmarks and table of contents.  As explained below I will push (after posting this to get the reference of this issue) a workaround for 1.6.2.
Expected Result
PDF contains in its bookmarks an "index" entry and also in the Table of contents.
Actual Result
No  "index" entry in PDF bookmarks nor in PDF table of contents.
Analysis
RTD does only one pdflatex run after makeindex. This is not enough.
For Sphinx own docs I will push a commit with this in conf.py:
latex_elements = {
    'printindex': r'''
\IfFileExists{\jobname.ind}
             {\footnotesize\raggedright\printindex}
             {\begin{sphinxtheindex}\end{sphinxtheindex}}
''',
}

This malaxes LaTeX into inserting an "index" entry in the auxiliary .toc file on first run.
However, better solution would be for RTD builds to do pdflatex twice after makeindex. The more general  approach could be to use Latexmk.
Relates: #1583, https://github.com/sphinx-doc/sphinx/issues/3742

Why do you want me  to think by my self if I can work with you

Duplicate of #4454

authors: agjohnson jfbu maryroseMXXXVI


text:
Modernize Python 2 code to get ready for Python 3

Make the minimal, safe changes required to convert the repo's code to be syntax compatible with both Python 2 and Python 3.  There may be other changes required to complete a port to Python 3 but this PR is a minimal, safe first step.
Run: futurize --stage1 -w **/*.py
See Stage 1: "safe" fixes http://python-future.org/automatic_conversion.html#stage-1-safe-fixes

Given these comments https://github.com/rtfd/readthedocs.org/pull/3514#pullrequestreview-88719473 should we just close this PR?

I think it would be fine to merge this and remove the files we don't use in a separate PR still. (No this PR does not exist yet).

Given these comments #3514 (review) should we just close this PR? Is there a PR to remove the /deploy files?

I think you can just remove this files in this PR and we can merge.

@cclauss are you still interested in finishing this PR?

authors: Blendify cclauss humitos stsewd


text:
file read error: iostream error

Hello,
I'm trying to create a FlatImage file with a Linux game, but when it comes to choosing a cover image I get the following error:
file_stream_device: file read error: iostream error
I tried with a png and jpeg file.
Any ideas ?

Great! Any other problems feel free to re-open the issue. :smile:

authors: ruanformigoni targanis

repo: ruanformigoni/gameimage


text:
Bump version to 2.1.0

Is it time for a new release? Too soon?

Before submitting the PR make sure the following are checked:

[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[-] Added tests.
[-] Updated documentation.
[x] Added an entry to the CHANGELOG.md if the new code introduces user-observable changes.
[x] The build (bundle exec rake) passes (be sure to run this locally, since it may produce updated documentation that you will need to commit).

Changing the changelog date and releasing today :-)

repo: rubocop-hq/rubocop-rspec


text:
[Fix #7161] Fix Style/SafeNavigation cop to preserve comments

Closes #7161.

Before submitting the PR make sure the following are checked:

[x] Wrote good commit messages.
[x] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[x] Added tests.
[x] Added an entry to the Changelog if the new code introduces user-observable changes. See changelog entry format.
[x] The PR relates to only one subject with a clear title
and description in grammatically correct, complete sentences.
[x] Run bundle exec rake default. It executes all tests and RuboCop for itself, and generates the documentation.

@tejasbubane I think this is ready to merge if you just fix the conflicts.

@jonas054 Fixed merge conflicts. I think the build failure is unrelated.

repo: rubocop-hq/rubocop


text:
Convert some tests to use expect_correction

This covers the easy to convert tests from metrics, security, and lint. There will be more changes to come.

@rrosenblum The changes look good but the build is failing.

Thanks!

authors: bbatsov jonas054 rrosenblum


text:
Performance/MapCompact autocorrection leads to invalid syntax

Original code:
MyClass
  .map(&:foo)
  .compact
  .first

Performance/MapCompact autocorrects the code to:
MyClass
  .filter_map(&:foo)
                    # <== blank line added here
  .first

Which leads to a syntax error:
E: Lint/Syntax: unexpected token tDOT
(Using Ruby 3.0 parser; configure using TargetRubyVersion parameter, under AllCops)
            .first
            ^

RuboCop version
$ rubocop -V
1.13.0 (using Parser 3.0.1.0, rubocop-ast 1.4.1, running on ruby 3.0.1 x86_64-darwin18)
  - rubocop-performance 1.11.0
  - rubocop-rails 2.9.1
  - rubocop-rspec 2.2.0

Thanks @koic! :heart:

repo: rubocop/rubocop-performance


text:
I18n translation: require default translation when key is dynamic

Is your feature request related to a problem? Please describe.
When a translation relies on a dynamic key, we have few control on the result and therefore cannot ensure the translation exists:
I18n.t("export.#{type}")

Describe the solution you'd like
Enforce the presence of a default value if the key is dynamic:
# bad

I18n.t("export.#{type}")

# good

I18n.t("export.#{type}", default: "whatever")
I18n.t("export.#{type}", default: I18n.t("export.default"))

Describe alternatives you've considered
No real alternative except asking for it during reviews.
Additional context
-

I think a better approach is configure your app to trigger an error notification when there is a missing translation:
https://thoughtbot.com/blog/foolproof-i18n-setup-in-rails

I think a better approach is configure your app to trigger an error notification when there is a missing translation:
https://thoughtbot.com/blog/foolproof-i18n-setup-in-rails

We can catch these errors when they happen on production. But if it's not covered by any test, how could we know there is a missing translation before the code is executed, since keys are dynamic?
Imagine that for whatever reason we want to translate a user input if we have the translation, for example the user has a gender and we have translations for many of them, but we need a fallback either:
I18n.t("gender.#{user.gender}", default: user.gender)
# if user.gender is "male", translation is known so we return the translation for it
# if user.gender is "gender fluid", translation is known so we return the translation for it
# if user.gender is "foobar", translation is unknown so we return "foobar"

repo: rubocop/rubocop-rails


text:
[Fix #13483] Fix an incorrect autocorrect for Style/RedundantRegexpArgument

Fixes #13483.
This PR fixes an incorrect autocorrect for Style/RedundantRegexpArgument when using escaped double quote character.

Before submitting the PR make sure the following are checked:

[x] The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
[x] Wrote good commit messages.
[x] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[x] Added tests.
[x] Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
[x] Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.

Thanks!

authors: bbatsov koic

repo: rubocop/rubocop


text:
error_response deprecation ?

There's a todo for deprecation (it's been a while) but there's no warn DEPRECATION. Since it's use internally, adding a warning will pop every single time.
I think we should not use it internally and add a proper warning DEPRECATION. What do you think ?
https://github.com/ruby-grape/grape/blob/0fa5216947816fff9d3cb37bab44144ee7d33701/lib/grape/middleware/error.rb#L62-L71

Makes sense, please.

authors: dblock ericproulx

repo: ruby-grape/grape


text:
Setting the irb_console configuration true has no effect

Your environment

ruby -v: 3.2.2 (also tested at 3.1.4p223, 3.0.6p216, and even 2.7.8p225)
rdbg -v: 1.9.1
irb -v: 1.11.1

Describe the bug
Setting the irb_console to true has no effect, and the environment variable RUBY_DEBUG_IRB_CONSOLE must be used to have rdbg and its breakpoint always start the user out with the irb:rdbg console.
To Reproduce
Expected behavior
I didn't expect that setting the configuration inside the REPL would take immediate effect so I created a ~/.rdbgrc file with a single line:
config set irb_console true

I would expect that hitting a debugger breakpoint or using the rdbg command would invoke the irb:rdgb console. To achieve the behavior I expect, I set the RUBY_DEBUG_IRB_CONSOLE env var to true in my ~/.zshenv instead.
Additional context
I do see the following message print after creating the ~/.rdbgrc file:
(rdbg:/Users/joesharp/.rdbgrc) config set irb_console true
irb_console = true                 # UI: Use IRB as the console (default: false)

Checking config irb_console shows the same line.

Thanks for reporting! I opened #1057 to address this.

repo: ruby/debug


text:
Add a string type to the lock method arguments

The lock method accepts a string value as well as a boolean value.
Account.lock("FOR UPDATE NOWAIT").find_by(name: "shugo")

This behavior remains the same in v6.0.x.
refs:

https://github.com/rails/rails/blob/v6.0.6.1/activerecord/lib/active_record/locking/pessimistic.rb
https://github.com/rails/rails/blob/v6.0.6.1/activerecord/lib/active_record/relation/query_methods.rb#L757-L770

/merge


text:
Remove 2 1 specs

See #405.
Work in progress.

I agreed to remove Ruby 2.1 specs.
We already removed Ruby 2.1 from Ruby CI at
https://github.com/ruby/chkbuild/commit/f87d844b53642984dc864d00ca50af73d7103313

authors: eregon hsbt

repo: ruby/spec


text:
Fixing cassettes.

https://github.com/rubyatscale/visualize_packs/pull/23 should have not been allowed to merge because status checks failed. However, we had the Branch protection misconfigured to not require any status checks to pass
I updated the branch protection setting...

Now the status checks are working... Otherwise we'd have already seen a merge because of @alexevanczuk approval.


text:
[PACKS] #8 New / Edit Distribution for the banks shows custom request units, if applicable

Summary
Add custom request units to new distribution.
Why
This is step #8 of adding the ability to specify "packs" versus "individual" for requests
Details
If the distribution is from a request, add a"Requested" column beside the current item fields
The # of requested items and the requested units will be shown beside the corresponding item in the distribution entry.
If the request is using a custom request unit (not the default units), the quantity for the distribution of the item will not be initially filled in.  The purpose of this is to reduce the likelihood of errors of the "leaving the number that was there because we fulfilled what they wanted"  type.   If the item doesn't have custom request units, or the item request uses the default units,  the quantity for the distribution will be filled in.
Visual Aid

Identified rules
In all cases:
May put 0 as a quantity
Saving with blank quantities will give an error
May remove any item
May add more items. This functionality will work as it does currently, except for the 0/blank behavior as noted above
On new or edit,  not-from-request:
Do not show the requested column
On new, from request
Show the requested column, including units if any
Quantities for items requested with custom units are initially blanks
Quantities from items requested without a custom unit are initialized to the amount requested
Items that were NOT from the request show "n/a" in the requested column
On edit, from request
Quantities for items requested, that are not included in the current distribution, are initialized to 0.
Show the requested column, including units if any.  (even for the items that are not included in the current distribution)
Item selection for requested items is frozen (i.e. only display the item name)
Item selection for not-requested items is not frozen (should be like the current distribution, barcodes and all)
may remove
N.B.
All of the changes for PACKS  must  be implemented behind a flipper flag "enable_packs"
1/ Flipper works by enabling or disabling a tag (for the PACKS issues, that is enable_packs)
2/ Here is a code snippet illustrating how to use it in your code, with enable_packs as the example tag:
if Flipper.enabled?(:enable_packs)
// do the thing we are guarding with the tag
end
3/ How to check out if it works manually (with the example tag: enable_packs ):
You have to enable the flipper tag on your localhost (note - the tag is stored in your db, so if you reset your db you have to do it again)
localhost:3000/flipper
userid:  admin
password:  password
Sign In
Click: Add feature
enable_packs
Click: Add feature
Click:  Fully enable
To set it back (to check that your nifty changes haven’t broken anything when the flag is off)
Sign in as above:
click on “enable_packs”
click “Delete”
type      enable_packs     in the “Are you sure” dialog and click ok
Criteria for completion

[ ] functionality as described above
[ ] tests that support the functionality as described above

Background
The following sections have been identified as required for the PACKS implementation.  These should be implemented in numerical order.

@cielf two questions:

Item selection for requested items is frozen (i.e. only display the item name)

This is only in the "edit" section - but this should be true for "new" as well, no? They can always remove the item if they don't want to fulfill it.

If the item doesn't have custom request units, or the item request uses the default units

To clarify - we removed the concept of a "default unit", correct? So if the item has any unit that isn't blank, we should follow the logic (e.g. blank out the quantity) - correct?

1/  That sounds right.
2/ If they pick "units" (instead of any custom unit) when requesting, we don't save the unit,  right?    If that's the case, then if the item request (not the item, per se) has any unit that isn't blank, we should blank out the quantity.

authors: cielf dorner

repo: rubyforgood/human-essentials


text:
When the newest version in github repo will be pushed to rubygems.org?

The version on rubygems.org was too old, released at Dec 28 2013
https://rubygems.org/gems/motion-support
At least this update is very useful:
rubymotion/motion-support#22
I encountered a file dependency issue recently, the root cause is that 'motion-yapper' gem set detect_dependencies to false for motion-support, but Promotion-menu gem can't work without auto dependency detection.

I'll push the most recent code up today, thanks for pointing that out!

On Feb 5, 2015, at 3:09 AM, Alex Wang notifications@github.com wrote:
The version on rubygems.org was too old, released at Dec 28 2013
https://rubygems.org/gems/motion-support
At least this update is very useful:
rubymotion/motion-support#22
I encountered a file dependency issue recently, the root cause is that 'motion-yapper' gem set detect_dependencies to false for motion-support, but Promotion-menu gem can't work without auto dependency detection.

Reply to this email directly or view it on GitHub.

@colinta Want to tag the latest as 0.3.0 and close the issue?

Good call - done!

authors: colinta jbender nanamiwang

repo: rubymotion/motion-support


text:
Added ioki, railslove as sponsors

hab noch im ioki icon den kleinen Text drunter entfernt weil ich mich im Slack mit Daniela auf ein icon ohne Text geeinigt hatte

license: Unlicense


text:
Tune PsScrpitAnalyzer to avoid useless errors

As a developer
I want GHAS to provide useful errors
so that I trust GHAS Alerts
In thsi case PsScriptAnalyzer is reproting formating best practices and not Security errors like tailing white spaces.

Reference
https://github.com/microsoft/psscriptanalyzer-action
https://github.com/marketplace/actions/run-psscriptanalyzer
Severity Settings
https://github.com/microsoft/psscriptanalyzer-action#severity

repo: rulasg/PsModuleLearning


text:
Migrate all property graph retrievers to Workflows 🔵

[ ]  🟢 @ravi Theja already made a notebook for GraphRAG

Closing this for now, as it's no longer something we are pursuing -- workflows are a way to orchestrate events yes, but converting existing classes is going to be messy and unnatural.
Instead, pushing docs changes and prebuilts to slowly shift people to using workflows

authors: logan-markewich nerdai


text:
[Feature Request]: Add Support for Claude 3.5 Sonnet V2

Feature Description
With the latest release of Claude Sonnet 3.5 V2, it would be nice to have this supported in the the llama-index-llms-bedrock-converse package.  It supports messages and tool use, so we can use it with those existing features of the package.
For good measure, we can update the llama-index-llms-bedrock, as well.
Reason
One could in theory download the package, update the model, and bundle it.  But that only works for an individual.  Not ideal!
Value of Feature
It adds the latest foundation model from Anthropic for Amazon Bedrock into the library.  This will enable those of us on developing greenfield applications the ability to use the latest models.

I'm happy to take on this task!

The above PR will release a new version of both the bedrock and bedrock converse integration packages when it merges. Added support for the new sonnet model

authors: chrismgonzalez logan-markewich


text:
[Bug]: TextNode object has no attribute fields_set

Bug Description
QuestionsAnsweredExtractor triggers following error during MetadataExtractor.process_nodes when processing TextNode using in_place=False

  File "/home/me/.local/lib/python3.11/site-packages/llama_index/node_parser/extractors/metadata_extractors.py", line 118, in process_nodes
    cur_metadata_list = extractor.extract(new_nodes)
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/me/.local/lib/python3.11/site-packages/llama_index/node_parser/extractors/metadata_extractors.py", line 386, in extract
    node.excluded_llm_metadata_keys = ["questions_this_excerpt_can_answer"]
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "pydantic/main.py", line 405, in pydantic.main.BaseModel.__setattr__
AttributeError: 'TextNode' object has no attribute '__fields_set__'

(fyi TitleExtractor and KeywordExtractor work fine)
Version
0.8.69
Steps to Reproduce
when in_place=False is not provided, the error does not occur

>>> metadata_extractor = MetadataExtractor(extractors=[QuestionsAnsweredExtractor(questions=3, llm=service_context.llm)],in_place=False)
>>> metadata_extractor.process_nodes([TextNode(text='abc')])
Extracting questions:   0%|                                                                                | 0/1 [00:00<?, ?it/s]DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): localhost:9997
Starting new HTTP connection (1): localhost:9997
DEBUG:urllib3.connectionpool:http://localhost:9997 "POST /v1/chat/completions HTTP/1.1" 200 1411
http://localhost:9997 "POST /v1/chat/completions HTTP/1.1" 200 1411
DEBUG:llama_index.llm_predictor.base:  Certainly! Based on the context "abc", here are three questions that this context can provide specific answers to which are unlikely to be found elsewhere:

1. What is the significance of the letter combination "ab" in the context of abc?

Higher-level summary: The context "abc" suggests a sequence of letters, and the letter combination "ab" may have a specific meaning or purpose within that sequence.

2. How does the letter "c" contribute to the overall meaning of the context "abc"?

Higher-level summary: The presence of the letter "c" in the context "abc" may indicate a connection to a particular theme, concept, or idea.

3. What is the relationship between the letters "a" and "b" in the context of abc?

Higher-level summary: The proximity of the letters "a" and "b" in the context "abc" may suggest a connection or relationship between them, such as a cause-and-effect relationship or a pattern.

I hope these questions are helpful! Let me know if you have any further requests or clarifications.
  Certainly! Based on the context "abc", here are three questions that this context can provide specific answers to which are unlikely to be found elsewhere:

1. What is the significance of the letter combination "ab" in the context of abc?

Higher-level summary: The context "abc" suggests a sequence of letters, and the letter combination "ab" may have a specific meaning or purpose within that sequence.

2. How does the letter "c" contribute to the overall meaning of the context "abc"?

Higher-level summary: The presence of the letter "c" in the context "abc" may indicate a connection to a particular theme, concept, or idea.

3. What is the relationship between the letters "a" and "b" in the context of abc?

Higher-level summary: The proximity of the letters "a" and "b" in the context "abc" may suggest a connection or relationship between them, such as a cause-and-effect relationship or a pattern.

I hope these questions are helpful! Let me know if you have any further requests or clarifications.
Extracting questions:   0%|                                                                                | 0/1 [00:35<?, ?it/s]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/me/.local/lib/python3.11/site-packages/llama_index/node_parser/extractors/metadata_extractors.py", line 118, in process_nodes
    cur_metadata_list = extractor.extract(new_nodes)
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/me/.local/lib/python3.11/site-packages/llama_index/node_parser/extractors/metadata_extractors.py", line 386, in extract
    node.excluded_llm_metadata_keys = ["questions_this_excerpt_can_answer"]
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "pydantic/main.py", line 405, in pydantic.main.BaseModel.__setattr__
AttributeError: 'TextNode' object has no attribute '__fields_set__'

Relevant Logs/Tracbacks
No response

same problem

much easier reproducer
>>> n1=TextNode(text='abc')
>>> n2=deepcopy(n1)
>>> n2.embedding=1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "pydantic/main.py", line 405, in pydantic.main.BaseModel.__setattr__
AttributeError: 'TextNode' object has no attribute '__fields_set__'

go back to v0.8.65 work for me

authors: prd-tuong-nguyen stdweird


text:
macでの動作

PlantUML Preview 実行後
command 'extension.previewPlantUML' not found
と表示されます
versiohは0.0.8
tommyMac:~ Tommy$ echo $JAVA_HOME
/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
tommyMac:~ Tommy$ echo $PLANTUML_HOME
/Users/Tommy/Dropbox/developer/jar
tommyMac:~ Tommy$ echo $TMP
/tmp
tommyMac:~ Tommy$

TMPではなくTEMP環境変数は定義されてますか？
そのエラーが出るときは、一緒に何か環境変数の定義がないっていうエラーも出てそうな気がするのですがどうでしょうか。

TMP -> TEMP
見間違えていました
すみません
ありがとうございます。

解決して良かったですー。

いつも
$TMPでしていましたので、、、
恥を晒してしまいました
macでの利用ですので、winと違う視点の発見があるかもしれません
なにかありましたらissuesにて報告いたします

authors: BaronTommy runceel

repo: runceel/plantumlpreview


text:
Chat-command for clue scrolls completed (+ Rank)

Is your feature request related to a problem? Please describe.
A simple addition to the chat-commands, because right now the list looks a bit lonely :smiley:.
Describe the solution you'd like
Uses the HiscoreClient to fetch the relevant data.
Something like this:

@J-Leg I think you implemented this with #3973?
In the future, you can close the issue from a PR using specific keywords so it is closed automatically upon merge.

Implemented in #3973

Ah yeah, was wondering how to do that. Thanks!

authors: J-Leg Nightfirecat deathbeam

repo: runelite/runelite


text:
Fletching and Crafting Counter

Describe the solution you'd like
Is it posible to add a fletching and crafting counter overlay? that shows the amount of bows made, the amount per hour and if posible the profit you made. and the same thing for crafting like how much flax you spinned, and the amount you spin per hour, and the profit

I could try my hand on implementing this later tonight.

Hey bmwhitehead200,
Great if you could that, doesnt have to be like very advanced, atleast not for me just mostly counting you know :) nothing fancy haha if you have time left or something and posibly also add a smithing counter that would be nice :)
Greetings

Hello,
Did you get it to work?
Greetings

Hey!
So as of now, I got the basic plugin created, as well as some functionality for total items made, items made per hour.
I'm still working out the animations on the fetching so I can more accurately calculate the values, and I still need to implement the GE functionality.
Here are some screenshots:

As you can see, it always says Fletching so im trying to use the animation to detect when not Fletching.

Hey,
Looking good ty for doing it for me :) maybe you could look at the idle notification plugin to see how its implemented there the animation function
Greetings

Another Update,
as of now, the functionality of everything is complete, except for the GE Price Calculator.
For some reason, I cannot get it to work, and when parts of the code does run, it decreases performance by ~60%.
So I decided to scrap that part of the plugin.
So as of now, you can check how many items per hour is made, the total amount of hours made, and can tell you when you are fletching.
Any other ideas for the plugin? Because if not I can push to the next stage of submitting the code.

Hey,
Oke great yea the ge price function is not a problem,
and i have no more ideas for the plugin, ty again for doing this do you have paypal or something so i could make you a donation?
Greetings

Nah,
I needed an excuse to get started on contributing, no need to donate.
Ill let you know when I submit the request.

Tried to get this working but didn't have too much success sadly.


text:
Menu Entry Swapper - Tears of Guthix

Simple addition, add an option to make Story the left-click option. The only two times you want to talk to Juna is for the Tears of Guthix and Another Slice of H.A.M. quests.

This is a niche feature that is best suited for the plugin hub, and is currently covered by the Menu swapper extented plugin there. See runelite/plugin-hub#42

authors: Nightfirecat Spedwards


text:
Add herb sack price check

When clicking "Check" on Herb Sack, the player gets a chat message which contains the total value of the herbs in the sack.
Fix #4573

Why is this not being merged? It seems ready and it fixes a real issue?


text:
测试

你好，我想请问一下我训练好模型之后要如何在测试集上面测试然后上传到网上得到结果呢？谢谢

我提交到网上的时候报错了，按照他们给的那个格式提交的
/opt/conda/lib/python2.7/site-packages/matplotlib/font_manager.py:273: UserWarning: Matplotlib is building the font cache using fc-list. This may take a moment.
warnings.warn('Matplotlib is building the font cache using fc-list. This may take a moment.')
Traceback (most recent call last):
File "/tmp/codalab/tmp7txC6i/run/program/cocoEvalCapCoda.py", line 68, in
cocoEval.evaluate()
File "/tmp/codalab/tmp7txC6i/run/program/pycocoevalcap/eval.py", line 24, in evaluate
res[imgId] = self.cocoRes.imgToAnns[imgId]
KeyError: 536
你能看看是什么原因吗？

找到原因是因为有重复的，我再看看程序


text:
[Add] TOOOLS.design

Site URL
https://www.toools.design
Description of the above provided site
A growing archive of 1,500+ design resources, frequently updated for the community.
category is not an option

Category
Other
Sub Category
AI Tools > Design
Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I am willing to work on this issue (optional)

@JuanPabloDiaz you're assigned.

authors: JuanPabloDiaz rupali-codes

repo: rupali-codes/LinksHub


text:
Replace progress dots with <sl-progress-bar>

https://shoelace.style/components/progress-bar
see https://bennypowers.dev/decks/devconf-brno-2023 for an example

height, color, opacity, etc are all configurable with css
html composability is easy with slot default content, the js apis are a little trickier, so users that slot in their own progress would need to write their own event listener
hiding on individual slides could likewise be with some javascript, or perhaps by reflecting the slide number/name to the deck element

I think the deck can handle most of these things. It can know the total
number of steps and the current step. It can also check the active slide if
the progress bar should be hidden. If it's composed, it can control the
slotted progress bar and feed it the right state.
The difficult part is that we have to align on a single interface for the
slotted progress bar. I.e. it needs some standard method to set the total
number of steps, and the current step. So not all custom progress bars will
work by default, they would have to adhere to this interface. But it would
probably be trivial to write a wrapper for any progress bar that does that
On Tue, Jun 20, 2023, 12:35 Benny Powers @.***> wrote:

height, color, opacity, etc are all configurable with css
html composability is easy with slot default content, the js apis are a
little trickier, so users that slot in their own progress would need to
write their own event listener
hiding on individual slides could likewise be with some javascript, or
perhaps by reflecting the slide number/name to the deck element
—
Reply to this email directly, view it on GitHub
https://github.com/ruphin/slidem/issues/51#issuecomment-1598526204, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAQJSVETHZODUPCA65SMMLXMF4FZANCNFSM6AAAAAAZNBM2S4
.
You are receiving this because you commented.Message ID:
@.***>

authors: bennypowers ruphin

repo: ruphin/slidem


text:
Add "Sailing" mode

This feature allows you to set upper and lower charge limit: do not charge while current value between lower and upper limits
Similar to this
https://apphousekitchen.com/feature-explanation-sailing-mode/

Hey!

Since it is theoretically healthier for the battery to be charged 10% once instead of 1% 10 times, we have included the Sailing Mode feature. This allows you to set a lower limit, from which the battery will be charged up to the charge limit again.

And then later:

Which interval should I choose for my battery to last as long as possible?
Unfortunately, we could not find any explicit studies on this topic yet. Therefore, we assume a value of 5-10%, depending on your own judgment.

I will have to double check if it's actually needed.

The idea is that a user can set any lower and upper limit as he want.
So, someone can set 45% – 65%, other user could set 90% – 95%

I understand what it does and it seems like a really clever idea. I'm just curious if it actually has a noticeable effect on the lifespan :)
And my data from the past 2 months doesn't support the claim that it happens frequently (it hasn't happened once on my M2 Max) – maybe because I don't leave my computer connected to the charger for long enough, or the Apple Silicon SOC doesn't consume enough power (maybe it happens on Intel), or perhaps I'm using chargers that are powerful enough (140W for M2 Max and 96W for M1 Pro), or maybe on Apple Silicon it only happens with the maxed version of the M Max. But please understand where I'm coming from – implementing this feature isn't a priority because another app has it, yet they don't provide any evidence that it actually affects the lifespan...

I understand what it does and it seems like a really clever idea. I'm just curious if it actually has a noticeable effect on the lifespan :)

However, small discharges of the battery still occur when a lot of power is needed for a short time. Then the battery of the MacBook steps in as a buffer.

And my data from the past 2 months doesn't support the claim that it happens frequently (it hasn't happened once on my M2 Max) – maybe because I don't leave my computer connected to the charger for long enough, or the Apple Silicon SOC doesn't consume enough power (maybe it happens on Intel), or perhaps I'm using chargers that are powerful enough (140W for M2 Max and 96W for M1 Pro), or maybe on Apple Silicon it only happens with the maxed version of the M Max. But please understand where I'm coming from – implementing this feature isn't a priority because another app has it, yet they don't provide any evidence that it actually affects the lifespan...

Just installed this app and its great, love the statistics. I moved from another battery charge limiter to here, I did notice a change in battery health on my M2 macbook when sailing mode is enabled vs when not.
I understand it isn't a priority however just letting you know that it does make a difference.

authors: SohamJa1n olfway rurza

repo: rurza/BatFi


text:
Can't find freshly-built Expat

I'm having a problem where a project can't find Expat if it looks for it right after Hunter builds it, but it works fine for other libraries.  For example,
hunter_add_package(TIFF)
find_package(TIFF REQUIRED)

hunter_add_package(Expat)
find_package(EXPAT REQUIRED)

TIFF will be found fine but EXPAT will not.  This only happens when Hunter has just built Expat: if I reconfigure, EXPAT will be found on the second run; if I start configuring a new build tree from scratch, EXPAT will be found as long as I reuse the same Hunter ID.
I've made a test project that reproduces the error: https://github.com/alamaison/hunter-find-test
When I configure this the first time when the Hunter ID does not already exist, I get:
[hunter] Build step successful (dir: C:/Users/Alexander/.hunter/_Base/94f56cb/cbb4458/a44f91b/Build/Expat)
CMake Error at C:/ProgramData/chocolatey/lib/cmake.3.1.3/content/cmake-3.1.3-win32-x86/share/cmake-3.1/Modules/FindPackageHandleStandardArgs.cmake:138 (message):
  Could NOT find EXPAT (missing: EXPAT_LIBRARY) (found version "2.1.0")
Call Stack (most recent call first):
  C:/ProgramData/chocolatey/lib/cmake.3.1.3/content/cmake-3.1.3-win32-x86/share/cmake-3.1/Modules/FindPackageHandleStandardArgs.cmake:374 (_FPHSA_FAILURE_MESSAGE)
  C:/ProgramData/chocolatey/lib/cmake.3.1.3/content/cmake-3.1.3-win32-x86/share/cmake-3.1/Modules/FindEXPAT.cmake:56 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:22 (find_package)

If I reconfigure:
[hunter] HUNTER_ROOT: C:/Users/Alexander/.hunter
[hunter] [ Hunter-ID: 94f56cb | Config-ID: cbb4458 | Toolchain-ID: a44f91b ]
[hunter] ZLIB_ROOT: C:/Users/Alexander/.hunter/_Base/94f56cb/cbb4458/a44f91b/Install (ver.: 1.2.8-p2)
[hunter] PNG_ROOT: C:/Users/Alexander/.hunter/_Base/94f56cb/cbb4458/a44f91b/Install (ver.: 1.6.16-patch-4)
[hunter] TIFF_ROOT: C:/Users/Alexander/.hunter/_Base/94f56cb/cbb4458/a44f91b/Install (ver.: 4.0.2-hunter-2)
[hunter] EXPAT_ROOT: C:/Users/Alexander/.hunter/_Base/94f56cb/cbb4458/a44f91b/Install (ver.: 2.1.0)
Found EXPAT: C:/Users/Alexander/.hunter/_Base/94f56cb/cbb4458/a44f91b/Install/lib/expat.lib (found version "2.1.0")
Configuring done
Generating done

Any idea why this would be?  I think it must be to do with CONFIG vs MODULE projects.  PNG and TIFF install a config file.  Expat doesn't (at least not in the correct place).

I've made a test project that reproduces the error

Hi, Alex. I think it's a bug in CMake. I can reproduce this error with CMake 3.1.2. Version 3.2.1 works fine for me.
Some theory:

FindEXPAT from standard CMake's location used
FindEXPAT calls find_path for header expat.h look-up
FindEXPAT calls find_library for library expat look-up
Hunter modify CMAKE_PREFIX_PATH in master file (same level as HunterGate)
CMAKE_PREFIX_PATH has highest priority in both find_path  and find_library

I think it must be to do with CONFIG vs MODULE projects. PNG and TIFF install a config file. Expat doesn't

Unfortunately this is not unified yet so you need to use documentation each time you're adding new package:

PNG use MODULE: https://github.com/ruslo/hunter/wiki/pkg.png
TIFF use CONFIG: https://github.com/ruslo/hunter/wiki/pkg.tiff
Expat use MODULE: https://github.com/ruslo/hunter/wiki/pkg.expat

I've added notes to README: https://github.com/ruslo/hunter/tree/develop#notes-about-version-of-cmake

authors: alamaison ruslo

repo: ruslo/hunter


text:
Add "botan" package

I've followed this guide
step by step carefully. Yes

I've tested this package remotely and have excluded all broken builds.
Here is the links to the Travis/AppVeyor with status "All passed":
Unfortunately, no AppVeyor/Windows build are working at the moment. There are still some issue.
I created also an issue in botan project.
On Travis, these builds should be running.
https://travis-ci.org/Bjoe/hunter/builds/562156574
But unfortunately, all linux builds are failing with a python error:
ImportError: No module named 'setuptools'
For three days, these builds are running:
https://travis-ci.org/Bjoe/hunter/builds/561340524
I didn't change anything on travis, I also merged the newest
pkg.template from ingenue/hunter repo.

I have submitted CI configs to https://github.com/ingenue/hunter targeting pkg.template branch,
see this merged pull request https://github.com/ingenue/hunter/pull/384 integrated as 38ad00f

Testing:

https://ci.appveyor.com/project/ingenue/hunter/builds/26171626
https://travis-ci.org/ingenue/hunter/builds/562426100?utm_source=github_status&utm_medium=notification

Merged, thanks. Please also make sure to read: https://github.com/ruslo/hunter/issues/1921
Released: https://github.com/ruslo/hunter/releases/tag/v0.23.205

authors: Bjoe ruslo


text:
Add support for Web Identity providers for IAM credentials

Add support for Web Identity providers for IAM credentials to the default provider chain. This feature is especially important to support the new projected token based IAM role support for EKS (Kubernetes) service accounts.
More infos here:

https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html
https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts-minimum-sdk.html

The official AWS SDKs already have gained support for that new feature in the following releases and it would be great if rusoto will add support soon:

Java — 1.11.623
Java (Version 2) — 2.7.36
Go — 1.23.13
Python (Boto3) — 1.9.220
Python (botocore) — 1.12.200
AWS CLI — 1.16.232
Node — 2.521.0
Ruby — 2.11.345
C++ — 1.7.174
.NET — 3.3.580.0
PHP — 3.110.7

Maybe I am wrong, but I guess we first need to fix https://github.com/rusoto/rusoto/issues/1478, then we might need to consider moving the following methods from rusoto_sts to rusoto_credentials in order to avoid circular dependencies:

assume_role_with_web_identity
assume_role_with_saml

Those methods are special because:

They do not need to be signed with credentials (see AWS documentation for more details)
They are used to obtain AWS credentials with non AWS credentials (OAuth or OpenID Connect bearer tokens resp. SAML assertions).

Note, for this issue only assume_role_with_web_identity is relevant. Nevertheless, assume_role_with_saml has the same characteristics.

Fixed in https://github.com/rusoto/rusoto/pull/1500 , thanks @alex-berger !

This issue is still not resolved, PR #1500 just provides the foundation and I am still working on adding support for "IAM roles for service accounts".
I intend to first add a corresponding credential provider to the STS service. Once this is in place we have to decide how we can add that provider to the default provider chain without introducing cyclic dependencies.

Gotcha. Reopening until this is fixed. 😄

Stupid question - is there an example of how to use this new credentials provider when using IRSA? I couldn't get it to work properly until now in my deployment

Stupid question - is there an example of how to use this new credentials provider when using IRSA? I couldn't get it to work properly until now in my deployment

This worked for me:
fn get_k8s_clients(opts: &super::Opts) -> Result<AwsClients> {
    let credentials_provider = WebIdentityProvider::from_k8s_env();
    let dynamo = DynamoDbClient::new_with(
        request::HttpClient::new()?,
        credentials_provider.clone(),
        opts.aws_region.clone(),
    );
    let s3 = S3Client::new_with(
        request::HttpClient::new()?,
        credentials_provider,
        opts.aws_region.clone(),
    );
    Ok(AwsClients { dynamo, s3 })
}```

@asthasr thanks! Will try it out!

authors: alex-berger asthasr matthewkmayer vmalloc

repo: rusoto/rusoto


text:
Figure out how to tag credentials crate versions

By breaking out the credentials crate we now have more moving pieces in this repo.  The ties between the Rusoto and Rusoto_codegen crate are pretty straightforward: they usually move in lockstep.  Credentials are different, as we added behavior and it should be available without upgrading the main Rusoto crate if we don't make a breaking change.
We could force the issue by assuming any change in any crate rusoto depends on is a breaking change and release a new version of the main crate.

I wouldn't be against extract the credential crate to it's own repo, if it were to make this easier. I don't think assuming all changes are breaking changes are a good idea (in the long term).

How about crate-vmajor.minor.patch ?
Examples:

rusoto-v0.21.0
credentials-v0.3.0
codegen-v0.5.0

I prefer these shortened ones over using the full crate name like rusoto_codegen-v0.5.0.


text:
CARGO_MANIFEST_DIR must be set and could not resolve macro json_internal

Was working fine two weeks ago.
Get the repo
https://github.com/whamcloud/integrated-manager-for-lustre/
Go to the
iml-api/src/graphql/mod.rs
Observe the list of problems, none of which happen when doing cargo check.

Settings required for procedural macro and build script support (rust-analyzer.cargo.loadOutDirsFromCheck, rust-analyzer.procMacro.enable) are enabled.
In the Rust Analyzer Language Server output panel there are panics
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: "failed to parse derive input: \"pubenumSpinnerNames{Dots, Dots2, Dots3, Dots4, Dots5, Dots6, Dots7, Dots8, Dots9, Dots10, Dots11, Dots12, Line, Line2, Pipe, SimpleDots, SimpleDotsScrolling, Star, Star2, Flip, Hamburger, GrowVertical, GrowHorizontal, Balloon, Balloon2, Noise, Bounce, BoxBounce, BoxBounce2, Triangle, Arc, Circle, SquareCorners, CircleQuarters, CircleHalves, Squish, Toggle, Toggle2, Toggle3, Toggle4, Toggle5, Toggle6, Toggle7, Toggle8, Toggle9, Toggle10, Toggle11, Toggle12, Toggle13, Arrow, Arrow2, Arrow3, BouncingBar, BouncingBall, Smiley, Monkey, Hearts, Clock, Earth, Moon, Runner, Pong, Shark, Dqpb, Weather, Christmas, Grenade, Point, Layer, BetaWave, }\""', /home/mkpankov/.cargo/registry/src/github.com-1ecc6299db9ec823/strum_macros-0.8.0/src/lib.rs:43:43
stack backtrace:
   0: rust_begin_unwind
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:483
   1: core::panicking::panic_fmt
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/panicking.rs:85
   2: core::option::expect_none_failed
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/option.rs:1234
   3: core::result::Result<T,E>::unwrap
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/result.rs:973
   4: strum_macros::from_string
             at /home/mkpankov/.cargo/registry/src/github.com-1ecc6299db9ec823/strum_macros-0.8.0/src/lib.rs:43
   5: core::ops::function::FnOnce::call_once
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227
   6: proc_macro::bridge::client::Client<fn(proc_macro::TokenStream) .> proc_macro::TokenStream>::expand1::run::{{closure}}
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/client.rs:410
   7: proc_macro::bridge::client::run_client::{{closure}}::{{closure}}
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/client.rs:377
   8: proc_macro::bridge::scoped_cell::ScopedCell<T>::set::{{closure}}
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/scoped_cell.rs:80
   9: proc_macro::bridge::scoped_cell::ScopedCell<T>::replace
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/scoped_cell.rs:75
  10: proc_macro::bridge::scoped_cell::ScopedCell<T>::set
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/scoped_cell.rs:80
  11: proc_macro::bridge::client::<impl proc_macro::bridge::Bridge>::enter::{{closure}}
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/client.rs:325
  12: std::thread::local::LocalKey<T>::try_with
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/local.rs:272
  13: std::thread::local::LocalKey<T>::with
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/local.rs:248
  14: proc_macro::bridge::client::<impl proc_macro::bridge::Bridge>::enter
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/client.rs:325
  15: proc_macro::bridge::client::run_client::{{closure}}
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/client.rs:370
  16: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:308
  17: std::panicking::try::do_call
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:381
  18: __rust_try
  19: std::panicking::try
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:345
  20: std::panic::catch_unwind
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:382
  21: proc_macro::bridge::client::run_client
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/client.rs:369
  22: proc_macro::bridge::client::Client<fn(proc_macro::TokenStream) .> proc_macro::TokenStream>::expand1::run
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/client.rs:410
  23: proc_macro_srv::proc_macro::bridge::server::run_server
  24: proc_macro_srv::dylib::Expander::expand
  25: proc_macro_srv::cli::run
  26: rust_analyzer::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: "failed to parse derive input: \"pubenumSpinnerNames{Dots, Dots2, Dots3, Dots4, Dots5, Dots6, Dots7, Dots8, Dots9, Dots10, Dots11, Dots12, Line, Line2, Pipe, SimpleDots, SimpleDotsScrolling, Star, Star2, Flip, Hamburger, GrowVertical, GrowHorizontal, Balloon, Balloon2, Noise, Bounce, BoxBounce, BoxBounce2, Triangle, Arc, Circle, SquareCorners, CircleQuarters, CircleHalves, Squish, Toggle, Toggle2, Toggle3, Toggle4, Toggle5, Toggle6, Toggle7, Toggle8, Toggle9, Toggle10, Toggle11, Toggle12, Toggle13, Arrow, Arrow2, Arrow3, BouncingBar, BouncingBall, Smiley, Monkey, Hearts, Clock, Earth, Moon, Runner, Pong, Shark, Dqpb, Weather, Christmas, Grenade, Point, Layer, BetaWave, }\""', /home/mkpankov/.cargo/registry/src/github.com-1ecc6299db9ec823/strum_macros-0.8.0/src/lib.rs:73:43
stack backtrace:
   0: rust_begin_unwind
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:483
   1: core::panicking::panic_fmt
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/panicking.rs:85
   2: core::option::expect_none_failed
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/option.rs:1234
   3: core::result::Result<T,E>::unwrap
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/result.rs:973
   4: strum_macros::enum_iter
             at /home/mkpankov/.cargo/registry/src/github.com-1ecc6299db9ec823/strum_macros-0.8.0/src/lib.rs:73
   5: core::ops::function::FnOnce::call_once
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227
   6: proc_macro::bridge::client::Client<fn(proc_macro::TokenStream) .> proc_macro::TokenStream>::expand1::run::{{closure}}
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/client.rs:410
   7: proc_macro::bridge::client::run_client::{{closure}}::{{closure}}
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/client.rs:377
   8: proc_macro::bridge::scoped_cell::ScopedCell<T>::set::{{closure}}
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/scoped_cell.rs:80
   9: proc_macro::bridge::scoped_cell::ScopedCell<T>::replace
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/scoped_cell.rs:75
  10: proc_macro::bridge::scoped_cell::ScopedCell<T>::set
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/scoped_cell.rs:80
  11: proc_macro::bridge::client::<impl proc_macro::bridge::Bridge>::enter::{{closure}}
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/client.rs:325
  12: std::thread::local::LocalKey<T>::try_with
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/local.rs:272
  13: std::thread::local::LocalKey<T>::with
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/local.rs:248
  14: proc_macro::bridge::client::<impl proc_macro::bridge::Bridge>::enter
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/client.rs:325
  15: proc_macro::bridge::client::run_client::{{closure}}
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/client.rs:370
  16: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:308
  17: std::panicking::try::do_call
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:381
  18: __rust_try
  19: std::panicking::try
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:345
  20: std::panic::catch_unwind
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:382
  21: proc_macro::bridge::client::run_client
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/client.rs:369
  22: proc_macro::bridge::client::Client<fn(proc_macro::TokenStream) .> proc_macro::TokenStream>::expand1::run
             at /home/mkpankov/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/proc_macro/src/bridge/client.rs:410
  23: proc_macro_srv::proc_macro::bridge::server::run_server
  24: proc_macro_srv::dylib::Expander::expand
  25: proc_macro_srv::cli::run
  26: rust_analyzer::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

I think this will be fixed by #6820.

Seems to be working now:

Seems to be working now:

Fixed in #7145 again :)

Fixed in #7145 again :)

repo: rust-analyzer/rust-analyzer


text:
fix: Fix server path on NixOS

See https://github.com/rust-analyzer/rust-analyzer/commit/c0d0ceefb29111732cacf39dbb57fe9f3ce25ee8#commitcomment-62688259.
bors r+

CC @cab404

LGTM; Are there workflows producing vsix, so I can test it?

I kicked off an early nightly build, https://github.com/rust-analyzer/rust-analyzer/actions/runs/1637540572, check https://github.com/rust-analyzer/rust-analyzer/releases/tag/nightly in 30 minutes or so.

Thank you!

Just checked — works fine)


text:
Error out non single root token tree conversion

This PR add a check to prevent non single root token tree conversion between token trees and syntax tree.
It should prevent the assert produced in #1267.

bors r+


text:
Add sourcemap for rollup and fix launch.json outfiles

Fix #2509

bors r+
Thanks!


text:
Parsing error design and fancy errors.

We started improving parsing errors but I'm not really sure what's the best design. There are two main things I'm concerned about: sensible carrying of the input and advanced error information such as spans or multiple errors.
The first issue is that some errors are nested. Recently proposed FromHexStr trait is an example of the situation where there are two checks being done, one of them being optional. So that begs the question where the input should go.
The second issue is I'd love to enable fancier errors - such as spanned error messages pluggable into codespan-reporting (I do not want to add it as a dep, just an example of consuming crate) and ability to report multiple errors. For the latter it'd be cool to report all positions of invalid hex chars.
Here's an example of beautiful error message from configure_me_codegen crate:
error: the identifier `a=bit**loong   and ###weird@parameter` contains invalid characters
   ┌─ unknown file:42:18
   │
42 │         name = "a=bit**loong   and ###weird@parameter"
   │                  ^   ^^     ^^^   ^^^^     ^ ... and this char
   │                  │   │      │     │
   │                  │   │      │     ... and these chars
   │                  │   │      ... and these chars
   │                  │   ... and these chars
   │                  this char is invalid

I guess carrying around more error information should be feature-gated. I think this would require #1143 to some degree.
I'm thinking of something like this:
pub struct ParseError<E> {
    input: ParseInput,
    first_error: E,
    #[cfg(feature = "multi-error")]
    other_errors: Vec<E>,
}

impl<E> ParseError<E> {
    #[cfg(feature = "error-input")]
    pub fn input(&self) -> &str {
        &self.input
    }

    #[cfg(feature = "multi-error")]
    pub fn sources(&self) -> impl Iterator<Item=&E> + '_ {
        std::iter::once(&self.first_error).chain(&self.other_errors)
    }
}

Though it's still imperfect as we could for instance detect missing 0x prefix in hex and invalid hex characters and there can only be one invalid prefix error. Also maybe we should have a single error for invalid characters just as in configure_me which only carries multiple spans within the same error.
Defining a completely new error for each item is a possibility, although a bit annoying. Maybe it'll be required anyway. In that case maybe we should have a trait instead:
pub trait ParseError {
    /// Iterator of labels
    type Labels: Iterator<Item=(String, Span)>; // GAT would be very useful here...
    /// Human-readable English explanation of the expected format.
    fn expecting(&self) -> &str;

    /// Additional hint relevant to the specific input.
    ///
    /// This is intended to explain more details about the specific error.
    fn hint(&self) -> Option<&str>;

    /// Returns an iterator of labels for characters within the input to explain the error better.
    fn labels(&self) -> Self::Labels;
}

pub struct Span {
    /// Starts from 0 which points to the beginning of the input passed to a parsing function
    pub start: usize,
    /// How many bytes are affected.
    pub len: usize,
}

Another can of worms is localization. I'm not sure if I want to deal with it but maybe we should keep the possibility open somehow.

I don't think we need to feature-gate any extra error info. If we have large errors we should box them and make sure that we have sensible accessors to get information out of them (and even to downcast).
We may need an alternate "dumb" representation when we have nostd, I suppose.

Yeah, that's a possibility too and probably not too bad. If someone is parsing strings instead of binary maybe they should switch the format as well. That being said, since no_std will likely need same gates as multi-error it might be useful to have it optional.

Yep, that makes sense -- I guess what I'm proposing is that we aggressively try to shrink the non-multi-error versions of our errors, even as we increase the size of the multi-error versions.

This seems like a big task. Would love to see concrete examples of rust-bitcoin data structures where a fancier display might be helpful. My only guess it is just amount? Everything else is just consensus-defined hex serialized strings.

@sanket1729 Network, LockTime... I could find more. Also hex errors could point to the locations of the invalid characters.

authors: Kixunil apoelstra sanket1729

repo: rust-bitcoin/rust-bitcoin


text:
Fix kani codegen CI job

Fix the current failing Kani job on todays PRs.
FTR our daily kani job has been red for ages, perhaps since we created the units crate? But today the --codege-only job broke (on all PRs). kani released a new version 10 days ago, pinning to the previous version seems to resolve the issue. I raised a bug report but did not investigate further.

Patch 1: Remove redundant import
Patch 2: Rename the tests
Patch 3: Pin kani version

File bug report: https://github.com/model-checking/kani/issues/3142
PR is CI only, can go in with one ack.
(Patch 2 is the result of debugging the real kani failure we have at the moment, I'll save the rant for the PR that fixes it.)

Pull Request Test Coverage Report for Build 8695777190
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 83.131%

Totals

Change from base Build 8689264293:
0.0%

Covered Lines:
19195

Relevant Lines:
23090

💛  - Coveralls

This is CI only, can go in with one ack.

I wonder if we shoud comment out the test in rust.yml and file an issue

I don't understand, how is that better than keeping coverage by using an old kani?

I don't understand, how is that better than keeping coverage by using an old kani?

We don't have coverage unless we fix our existing tests. We just have a daily "CI failed" notification that we ignore.

I fixed that yesterday, its in the amount error PR
https://github.com/rust-bitcoin/rust-bitcoin/pull/2689#discussion_r1567914186

We don't have coverage unless we fix our existing tests.

I meant that the rust.yaml job adds coverage by doing the --codegen-only because otherwise the code is never checked (because of the #[cfg(kani)] attribute.

Fixing it is what set me off raging about the error types. git blame tells me you wrote the problematic line in the kani test, its bad policy to throw mud but I chuckled when you said it was perfectly clear above :)

I said the fields of the error types were perfectly clear :). I said nothing about the Kani test. If you used git blame a little harder, you would have found that Kix wrote the original code, and when it was intermittently failing on the same line, I simply edited it to invert that specific line (without reasoning through the rest of the test, which tries to do way too many things at once). This appeared to fix it so we merged it, but it seems that it merely turned an intermittent failure into a differently intermittent failure.

Actually the history on this test is a little weirder.
It looks like I wrote the test in https://github.com/rust-bitcoin/rust-bitcoin/pull/1415. Originally it had simple error types (and presumably worked).
Then in https://github.com/rust-bitcoin/rust-bitcoin/pull/2497 (by a new contributor) we changed all the error types to have more information, which broke the Kani tests, which (at the time) we were not compile-testing in CI. Note that in that PR I commented on how much better the error types were ;).
Then you "fixed" the test https://github.com/rust-bitcoin/rust-bitcoin/pull/2430 which Kix and I ACKed, presumably because it was a test-only change that made CI pass when it previously wasn't. This was Feb 1st.
However, we did not realize that your fix was wrong, because Kani was separately broken. I "fixed" this on Feb 5 in https://github.com/rust-bitcoin/rust-bitcoin/pull/2450 (this is what I was thinking about my previous comment -- Kix had introduced the offending line a week prior, in https://github.com/rust-bitcoin/rust-bitcoin/pull/2370, though now that I look at it, I actually wrote the rest of the test ;) Kix did not have anything to do with this issue).
So, you are welcome to try to untangle the exact sequence of events there. It looks like we had two very-similar-looking-but-unrelated problems being introduced and partially fixed on overlapping timelines, and the root cause was that my old Kani tests (which previously had simple "this should work or this should overflow" semantics) being gangpressed into detecting different kinds of overflow. Which would have been complicated and likely-broken no matter how clearly-defined the new more-nuanced error types were.

Wow, so whats the lesson from this? Some possible ones I can think of

One assertion per test
Don't let kani daily job go red

Well, unless we expect PR authors and reviewers to see the future, we cannot enforce this :).

oh, I should have said "don't let kani stay red"

authors: apoelstra coveralls tcharding


text:
Implement taproot specific script helpers

This change implements the script parts of https://github.com/rust-bitcoin/rust-bitcoin/issues/503. Will rebase with changes from https://github.com/rust-bitcoin/rust-bitcoin/pull/563 once it's merged

There is also a dependency on  #585 imo.

Am I right that this PR was superseded by #585?

This is now done as a part of #696.

authors: dr-orlovsky jrawsthorne sanket1729 sgeisler


text:
PtyProcess: add NO_CTTY flag

The default behavior of posix_openpt seems to be to replace the controlling terminal for the calling process, and PtyProcess should only change it for child instead. I think this might be a reason why some of the tests were failing non-deterministacally sometimes, although I am not 100% confident in this fix.
Signed-off-by: Petre Eftime petre.eftime@gmail.com

bors try

@matthiasbeyer so far this passes 100% of the tests.

bors try

Ah. This failed as well.

bors try

bors try

bors try

In pexpect, a similar issue is called out: https://github.com/pexpect/pexpect/blob/2532721644781543ca660e52d48a35bd93872fc1/doc/commonissues.rst#timing-issue-with-send-and-sendline

bors try

bors try

bors try

Yes, so far I was reading through how pexpect or some other terminal emulators set this up and see if we're missing anything. So far, not luck with getting the issue fixed unfortunately, and no matter what I do I can't seem to be able to reproduce it on my setup.

Yeah that also was the case for me... it seems like we only have this issue in CI, which makes it even worse.

authors: matthiasbeyer petreeftime

repo: rust-cli/rexpect


text:
How to implement RAII / Drop for Sockets?

I have been working on a modem driver for a Quectel BG77 which is a modem that is controlled via AT commands over a UART. The network stack is implemented on the modem and the modem supports multiple sockets.
To me, it seems obvious to keep track of acquired sockets in a list and recycling/returning those as soon as TcpClientStack::close is called. Unfortunately, it seems to be impossible to guarantee that the close-method gets called at all. It is easy to imagine cases which will cause socket exhaustion in the long run:
let mut socket = tcp_stack.socket()?;
function_call_that_can_fail()?; // e.g. socket.send(...), function returns here, socket is leaked
tcp_stack.close(socket);

Normally, this would be tackled with RAII, i.e. implementing the Drop trait for the socket. But as far as I see, this is impossible (at least with the current trait definitions) because we need the &mut TcpStack to close the socket.
In the beginning, I thought that this could be solved with interior mutability. But to implement that, the socket type needs to contain a &RefCell<TcpClientStack> (which still is a reference to the TcpClientStack). First, I could not get this to compile at all. The closest I could get was type TcpSocket<'a> = Bg77TcpSocket<'a, ...>; which fails with "generic associated types are unstable". Secondly, regarding the lifetimes, the socket would borrow the tcp stack in TcpClientStack::socket(&mut self). So the tcp stack would be borrowed until the socket is destroyed which limits us to a single usable socket.
Personally, I would really like to implement this feature because not doing so brings us back to C-style manual resource management with all its downsides (even worse, because the ?-operator is harder to spot than a return).
The solution will most probably be based on interior mutability because the (possibly multiple) sockets require (possibly mutable) access to the underlying hardware. I have seen discussions here that want to save the driver developers from re-inventing this interior mutability wheel over and over again, so it would be nice to have a solution which is generic over different driver implementations I guess. So what are your thoughts and ideas on this?

I've hit this myself a few times and I agree that it's easy to get wrong. Dropping sockets is definitely not something we want to do if they're being tracked internally by the stack structure. Perhaps https://github.com/rust-embedded-community/embedded-nal/issues/53 could help to solve this, but that API implies some internal &RefCell<Stack> as well I believe

Some data point that may be helpful (even though not fully thought through as my own implementation is incomplete): The stack as I use it in riot-wrappers comes with sockets that are allocated inside the stack (which need to be pinned as that's what the backend requires).
Dropping a socket is as fine as it gets (well it leaks resources, as dropping often does), but if the stack is ever deallocated (which I don't fully support yet) and not all of its sockets were closed properly before that, dropping the stack (which is guaranteed to run through its pinning) panics.
For the example you give, a try! block, or a helper function (which may or may not make sense as a provided method of stacks) could catch this:
tcp_stack.with_socket(|s| {
    function_call_that_can_fail()?;
})?;

Such a with_socket would always close the socket at the end, having only handed out a &mut socket. I don't think it should be the general pattern, because where sockets are longer lived, ownership is desired, but comes at the cost of having to dispose of them properly.

Thanks for your suggestion but I do not think this resolves my problem because the responsibility of not leaking the resource is still on the caller/user side and that is exactly what I try to avoid.
I think I just found a way of achieving my goal, based on a RefCell obviously. I hope I can post this here in a few hours.

It works. The trick was to do/implement everything in a Bg77Driver and let the Bg77ClientStack and Bg77SocketHandle both take &RefCell<Bg77Driver>s. Like this, the TcpClientStack trait can be used as is and Drop can be implemented for the socket handles because they can get direct access to the underlying driver via the RefCell.
The following gist shows how all this can be set up:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=ddbd1f1e476934159dd52aa2c9070b76
Some observations on this:

Does this re-invent the SharableStack / shared-bus interior mutability wheel? Unfortunately, yes.
Because it does so, the Bg77ClientStack can be Copy (stack sharing is no problem at all).
The Drop implementation shows that the sockets do not actually need the &mut TcpClientStack at all to operate on the modem. So this implementation would allow a socket-directed API / trait as proposed in #53.

authors: DrTobe chrysn ryan-summers

repo: rust-embedded-community/embedded-nal