first take at filetypes

docu is really vague,.. something about 4 letter combos corresponding to 3 letter extensions (maybe that was another object)? so mostly a guessing game here...  so i made "filetype csv" (i know, only 3 letters, but how you make it 4?) set extension ".csv" and "filetype text" set extension ".txt", anything else unsets extension
think i got the max length for strncpy correct maxpdstring - 5

my guess is that the user specifies whatever he wants as a file extension, anything arbitrary or not, like ".dek", ".fft", and whatever is in coll just gets saved with that file extension

anyway, trying your Pull Request, any "write" message blows up Pd :)

hmm, when does this happen? trying with args and seems to work okay, with both write with no args (works as it did before) and write with args, need to implement filetype with no args though...

when does this happen?

anytime I try a write message. Just opening the help file and trying the "write coll.txt" message in the help examples blows up Pd for me... this doesn't happen for the last stable release

about how filetype doesn't work in Max... just tested with the new Max 8 trial...

oops, here it is: https://github.com/porres/pd-cyclone/issues/438


How to get a range of cells

I'm planning to make a pr here is the current progress
use it like this
var data = selectRange(mySheet, 'D8:H12');

List<List<dynamic>> selectRangeWithString(Sheet sheet, String range) {
  var rangeVars = range.split(':');

  CellIndex from = CellIndex.indexByString(rangeVars[0]);
  CellIndex to = CellIndex.indexByString(rangeVars[1]);

  return selectRange(sheet, from, to);
}

List<List<dynamic>> selectRange(Sheet sheet, CellIndex from, CellIndex to) {
  List<List<dynamic>> selectedRange = List<List<dynamic>>();

  for (var row in sheet.rows.sublist(from.rowIndex, to.rowIndex + 1)) {
    var selectedColumn = row.sublist(from.columnIndex, to.columnIndex + 1);
    selectedRange.add(selectedColumn);
  }

  return selectedRange;
}

also, mine returns the values of the cells, there is a method in the package that is not completed and returns an empty list
but it plans to return as a list of cell Data which seems to be a better idea but uses more resources than needed if you just want to get the values
sheet.getSelection(CellIndex.indexByString('A1'),end: CellIndex.indexByString('C1'));

thank you alot....you saved my ass😘😘😘
On Sat, 26 Dec 2020 9:52 AM Arin Faraj<EMAIL_ADDRESS>wrote:

I'm planning to make a pr here is the current progress
use it like this
var data = selectRange(mySheet, 'D8:H12');
List<List> selectRangeWithString(Sheet sheet, String range) {
var rangeVars = range.split(':');
CellIndex from = CellIndex.indexByString(rangeVars[0]);
CellIndex to = CellIndex.indexByString(rangeVars[1]);
return selectRange(sheet, from, to);
}
List<List> selectRange(Sheet sheet, CellIndex from, CellIndex to) {
List<List> selectedRange = List<List>();
for (var row in sheet.rows.sublist(from.rowIndex, to.rowIndex + 1)) {
var selectedColumn = row.sublist(from.columnIndex, to.columnIndex + 1);
selectedRange.add(selectedColumn);
}
return selectedRange;
}
also, mine returns the values of the cells, there is a method in the
package that is not completed and returns an empty list
but it plans to return as a list of cell Data which seems to be a better
idea but uses more resources than needed if you just want to get the values
sheet.getSelection(CellIndex.indexByString('A1'),end: CellIndex.indexByString('C1'));
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/justkawal/excel/issues/59#issuecomment-751339899, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ARGO34LKTM5V3JHHMJYNRWTSWWW6FANCNFSM4UFRW5SA
.

I'm planning to make a pr here is the current progress
use it like this
var data = selectRange(mySheet, 'D8:H12');

List<List<dynamic>> selectRangeWithString(Sheet sheet, String range) {
  var rangeVars = range.split(':');

  CellIndex from = CellIndex.indexByString(rangeVars[0]);
  CellIndex to = CellIndex.indexByString(rangeVars[1]);

  return selectRange(sheet, from, to);
}

List<List<dynamic>> selectRange(Sheet sheet, CellIndex from, CellIndex to) {
  List<List<dynamic>> selectedRange = List<List<dynamic>>();

  for (var row in sheet.rows.sublist(from.rowIndex, to.rowIndex + 1)) {
    var selectedColumn = row.sublist(from.columnIndex, to.columnIndex + 1);
    selectedRange.add(selectedColumn);
  }

  return selectedRange;
}

also, mine returns the values of the cells, there is a method in the package that is not completed and returns an empty list
but it plans to return as a list of cell Data which seems to be a better idea but uses more resources than needed if you just want to get the values
sheet.getSelection(CellIndex.indexByString('A1'),end: CellIndex.indexByString('C1'));

It's awesome work friend.
Would be waiting for your pr.
Lpng Live 🔥pen Source


LICENSE

Looks like there are two license files, one MIT and one CC0. Don't know whether the MIT is a relic or whether it needs to stay...

Should be legacy.  We should go with CC0.


Transaction history

How can I see the history of all transactions?

you should be able to do  this through https://cosmos.network/rpc/#/ICS0/get_txs


Survey: Shall we launch a new Forum?

What do you think about this section "Issues" here?
Is it the right place for all kinds of "articles" like they are at the moment?
Is it too mixed up and difficult to find information? Would categories make it better?
... ?
Do you think a different representation and functionality like in "Discussion"* would benefit?
*So that you know what we are talking about, if you haven't seen it yet somewhere, here are some examples:
https://github.com/reactwg/react-18/discussions
https://github.com/nasa/cFS/discussions
https://github.com/vercel/next.js/discussions
https://github.com/AcademySoftwareFoundation/OpenTimelineIO/discussions
We would like to hear from people who are new here as well as long-term users.
Write your thoughts and opinions as comments below.

This is a great idea!

In favor of this idea as well..

The new Discussions section has been opened.


Metro disconnect when the emulator network is Off

Description
Before i upgrade RN to the latest, disabling the emulator network wasn't disconnecting the metro. for example if i wanted add a listener to listen for the network status this listener will be invoked even when the network is Off. now its not doing that
when i try to refresh metro and the network is off it shows this warning:
warn No apps connected. Sending "reload" to all React Native apps failed. Make sure your app is running in the simulator or on a phone connected via USB.
info Reloading app...

and when i connect the network again and refresh metro it works again.
React Native Version
0.72.3
Output of npx react-native info
System:
OS: Windows 10 10.0.22621
CPU: "(12) x64 AMD Ryzen 5 5600X 6-Core Processor             "
Memory: 2.98 GB / 15.94 GB
Binaries:
Node:
version: 18.12.1
path: C:\Program Files\nodejs\node.EXE
Yarn:
version: 1.22.19
path: ~\AppData\Roaming\npm\yarn.CMD
npm:
version: 8.19.2
path: C:\Program Files\nodejs\npm.CMD
Watchman: Not Found
SDKs:
Android SDK: Not Found
Windows SDK: Not Found
IDEs:
Android Studio: AI-212.5712.43.2112.8609683
Visual Studio:
- 16.11.32510.428 (Visual Studio Community 2019)
- 17.5.33414.496 (Visual Studio Community 2022)
Languages:
Java:
version: 1.8.0_352
path: C:\Program Files\Eclipse Adoptium\jdk-8.0.352.8-hotspot\bin\javac.EXE
Ruby: Not Found
npmPackages:
"@react-native-community/cli": Not Found
react:
installed: 18.2.0
wanted: 18.2.0
react-native:
installed: 0.72.3
wanted: 0.72.3
react-native-windows: Not Found
npmGlobalPackages:
"react-native": Not Found
Android:
hermesEnabled: true
newArchEnabled: false
iOS:
hermesEnabled: Not found
newArchEnabled: Not found
Steps to reproduce
1- run the application
2- metro works well
3- disconnect wifi & celluar data
4- now metro disconnects
Snack, screenshot, or link to a repository
https://github.com/saif-o99/Awesome-project

The device is connected on Metro from USB debugging or from Wifi Debugging?

The device is connected on Metro from USB debugging or from Wifi Debugging?

its an Android Emulator

1- run the application
2- metro works well
3- disconnect wifi & celluar data
4- now metro disconnects

This is the intended behavior. The device talks to Metro via the http protocol. If network is down, the connection is lost.

@cortinico can you explain how it was working fine before the update?
before closing the issue...

it should be okay that i want to see the behaviour of my application when the network is off

You can do so by disabling wifi and mobile data, and the Metro connection won't be lost.
But if you also turn on AirPlane mode, you will lose the connection to Metro

it should be okay that i want to see the behaviour of my application when the network is off

You can do so by disabling wifi and mobile data, and the Metro connection won't be lost. But if you also turn on AirPlane mode, you will lose the connection to Metro

if you please look at this case i have:
i have a listener which tell me when the network is on or off to show indicator to the user.
before the update i was checking if everything is okay by disabling wifi and mobile data on the emulator and the listener will return network off
but after the update i can't do that because whenever the wifi or mobile data is off the metro disconnect and shows this warn
warn No apps connected. Sending "reload" to all React Native apps failed. Make sure your app is running in the simulator or on a phone connected via USB.
info Reloading app...

@cortinico

This is the intended behavior. The device talks to Metro via the http protocol. If network is down, the connection is lost.

You can do so by disabling wifi and mobile data, and the Metro connection won't be lost.

Seems like two contradictory statements? I don't understand why this is closed, and I see @saif-o99 opened a new issue. It's been some time, did you mange to find a fix for it?

@Xmaxer No solution/workaround for this. Look like if you want to upgrade your react native version you will lose the ability to test your app on no network, sounds like a downgrade for me not upgrade.
maybe open a new issue so they start pay attention to it idk.

Hey @saif-o99
My apologies but this statement of mine was incorrect:

You can do so by disabling wifi and mobile data, and the Metro connection won't be lost.

Your device talks to metro via the HTTP protocol though, so you need to create a tunnel via localhost for it to work properly.
To do so you can run the following in a terminal:
adb root
adb reverse tcp:8081 tcp:8081
adb shell setprop metro.host "localhost"

That will make sure that your app will attempt to search for Metro in localhost:8081 rather than <IP_ADDRESS> (the default). With this you can keep the connection to Metro alive, even if the internet connection (Wifi/Mobile) goes down. Hope this clarifies.


Create project setup

This PR contains the Set-Up of a Math Magicians application using React.

Math magicians is a website for all fans of mathematics.

Highlights:

Created using Create React App (CRA) util
Setup linters: [ESLint, StyleLint]
Add a descriptive ReadMe file
Setup Gitflow
The application runs in the browser without errors.
etc

Approved ✔
Hi @Lembani
Congratulations on completing this project! 👏🏼 🎉
You have correctly implemented all of the requirements📃 correctly and without any errors⚠ or bugs🪲.
Cheers and good luck in your next milestones! 🍀
Feel free to leave any questions or comments in the PR thread(don't forget to tag me 😄) if something is not 100% clear.

As described in the Code reviews limits policy  you have a limited number of reviews per project (check the exact number in your Dashboard). If you think that the code review was not fair, you can request a second opinion using this form.

Hi @Mre55, I have now done everything accordingly. You can review it again.


Unable to upload videos to instagram stories

Hello,
I have been trying to upload videos to stories but I have been having this error:
Error parsing error response: Expecting value: line 1 column 1 (char 0)
Error is >>
Forbidden
Something went bad.
Please retry or send an issue on https://github.com/b3nab/instapy-cli
Traceback (most recent call last):
File "s.py", line 18, in
res = cli.upload(image_files[i], story=True)
File "/home/ubuntu/.local/lib/python3.6/site-packages/instapy_cli/cli.py", line 153, in upload
raise IOError("Unable to upload.")
OSError: Unable to upload.
I'm using python 3.7,  instapy-cli  version == 0.0.12, os ubuntu 18

Hi, I have the same problem, did you fix this?

same problem here. any fix?

same issue , did you fix it?


Inheritance problem

Hello,
Inheritance seems to be a problem with the Earth class.
Please have a look at the following example :
from pyearth import Earth

class EarthDerived(Earth):

    def __init__(self, other_attribute):
        Earth.__init__(self)
        self.other_attribute = other_attribute

if __name__ == "__main__":
    earth_derived = EarthDerived("foo")

/usr/bin/python3 /home/jv/pythonmars/trunk/pythonmars/examples/EarthInheritance.py
Traceback (most recent call last):
  File "/home/jv/pythonmars/trunk/pythonmars/examples/EarthInheritance.py", line 15, in <module>
    earth_derived = EarthDerived("foo")
  File "/home/jv/pythonmars/trunk/pythonmars/examples/EarthInheritance.py", line 11, in __init__
    Earth.__init__(self)
  File "/usr/local/lib/python3.4/dist-packages/py_earth-0.1.0-py3.4-linux-x86_64.egg/pyearth/earth.py", line 244, in __init__
    if call[name] is not None:
KeyError: 'other_attribute'

Regards

Hello @julienvienne,
thanks for reporting this issue. @jcrudy, this error happens because the class method  _get_param_names (inherited from BaseEstimator) returns the param names of EarthDerived while it expects the param names of Earth. We might solve this issue by replacing self._get_param_names (in the __init__ of Earth) by Earth._get_param_names, but some lines after self.set_params(...) is called and it expects the param names returned by self.get_params(...) which would be in this case the param names of EarthDerived, not those of Earth. I would suggest to use explicit assignments in the _init_ of Earth, something like this :
      def __init__(self, max_terms=None, max_degree=None, allow_missing=False,
                   penalty=None, endspan_alpha=None, endspan=None,
                   minspan_alpha=None, minspan=None,
                   thresh=None, zero_tol=None, min_search_points=None,
                   check_every=None,
                   allow_linear=None, use_fast=None, fast_K=None,
                   fast_h=None, smooth=None, enable_pruning=True,
                   feature_importance=None, verbose=0):
          self.max_terms = max_terms
          self.max_degree = max_degree
          self.allow_missing = allow_missing
          self.penalty = penalty
          self.endspan_alpha = endspan_alpha
          self.endspan = endspan
          self.minspan_alpha = minspan_alpha
          self.minspan = minspan
          self.thresh = thresh
          self.zero_tol = zero_tol
          self.min_search_points = min_search_points
          self.check_every = check_every
          self.allow_linear = allow_linear
          self.use_fast = use_fast
          self.fast_K = fast_K
          self.fast_h = fast_h
          self.smooth = smooth
          self.enable_pruning = enable_pruning
          self.verbose = verbose

What do you think ? perhaps @agramfort might also have an opinion on this.

+1 on @mehdidc suggestions. All params should be passed in init to follow sklearn convention. Another option is to write your own set_params and get_params methods.

It looks like the current Earth.__init__ carefully avoids setting attributes to None.  I'm not sure, but I suspect it's code that I wrote and that I wrote it because I incorrectly thought that was the sklearn convention.  So, since it's not the convention, I think it definitely makes sense to switch to @mehdidc's suggestion.  There may be other places in the code that rely on an attribute being present or absent as some kind of indicator, although I can't think of any specifically.

"There may be other places in the code that rely on an attribute being present or absent as some kind of indicator, although I can't think of any specifically." yes actually in the constructor of ForwardPasser and PruningPasser.

Closing this as fixed by @mehdidc.  @julienvienne please comment or reopen if you still experience the problem after the fix.


Import report

In a solution with several projets, it's better (10 times faster in my case) to run resharper on all solution and not on each project.

ReportFile parameter works great for me.  Hopefully this will be accepted soon because it's far more convenient to run inspectcode.exe with my our resharper settings as part of a TeamCity build then gather all of the artifacts in a dependent build to push to SonarQube.

This feature has been added to the R# plugin now, and so I'm closing this PR.
The mode where inspectcode.exe gets executed by the SonarQube plugin is even deprecated.


Setup CoAP server

Use Californium CoAP

Use Californium CoAP server:

Implement the CoAP server for communication with CDA


VR: fix expunging vm will remove dhcp entries of another vm in VR

Description
This PR fixes an issue that expunging vm will remove dhcp entries of another vm in VR
Steps to reproduce the issue
(1) create two vm wei-001 wei-002, and wei-003 start them.
Assume that wei-001 has the biggest ip (order by char, not number. for example <IP_ADDRESS> > <IP_ADDRESS>)
(2) check /etc/cloudstack/dhcpentry.json and /etc/dhcphosts.txt in VR
They have entries for all vms
(3) stop wei-002 and wei-003, then restart VR (or restart network with cleanup).
check /etc/cloudstack/dhcpentry.json and /etc/dhcphosts.txt in VR
They have entries for wei-001 only (as wei-002 and wei-003 are stopped)
(4) expunge wei-002. when it is done,
check /etc/cloudstack/dhcpentry.json and /etc/dhcphosts.txt in VR
The last entry ("id": "dhcpentry") is removed.
(5)  expunge wei-003, when it is done.
check /etc/cloudstack/dhcpentry.json and /etc/dhcphosts.txt in VR
the entry for wei-001 is removed, and the ip is removed from /etc/dhcphosts.txt
VR health check fails at dhcp_check.py and dns_check.py
This does not always happen, as the last items in /etc/cloudstack/dhcpentry.json are order by ip addresses.
if the last item is dhcp entry for a running vm , its dhcp info will be removed from dnsmasq.

Types of changes

[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] New feature (non-breaking change which adds functionality)
[X] Bug fix (non-breaking change which fixes an issue)
[ ] Enhancement (improves an existing feature and functionality)
[ ] Cleanup (Code refactoring and cleanup, that may add test cases)

Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale

[ ] Major
[ ] Minor

Bug Severity

[ ] BLOCKER
[X] Critical
[ ] Major
[ ] Minor
[ ] Trivial

Screenshots (if appropriate):
How Has This Been Tested?

@rhtyd @DaanHoogland @shwstppr
this looks like a major issue.

@rhtyd @DaanHoogland @shwstppr
this looks like a major issue.

@blueorangutan package

@blueorangutan package

@shwstppr a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

@shwstppr a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✔centos7 ✖centos8 ✔debian. JID-2611

Packaging result: ✔centos7 ✖centos8 ✔debian. JID-2611

I'm not able to reproduce the issue on a KVM and a VMware environment. Can someone else verify @vladimirpetrov @nvazquez @rhtyd

I'm not able to reproduce the issue on a KVM and a VMware environment. Can someone else verify @vladimirpetrov @nvazquez @rhtyd

I'm not able to reproduce the issue on a KVM and a VMware environment. Can someone else verify @vladimirpetrov @nvazquez @rhtyd

@shwstppr did you follow the steps in description ? in which step you have different result ?

I'm not able to reproduce the issue on a KVM and a VMware environment. Can someone else verify @vladimirpetrov @nvazquez @rhtyd

@shwstppr did you follow the steps in description ? in which step you have different result ?

@weizhouapache in final step. After expunging second VM, VR still had an entry for the first VM.
Also just for info, I was testing with an isolated network.

@weizhouapache in final step. After expunging second VM, VR still had an entry for the first VM.
Also just for info, I was testing with an isolated network.

@weizhouapache in final step. After expunging second VM, VR still had an entry for the first VM.
Also just for info, I was testing with an isolated network.

@shwstppr it is strange. which cloudstack version did you test ?

@weizhouapache in final step. After expunging second VM, VR still had an entry for the first VM.
Also just for info, I was testing with an isolated network.

@shwstppr it is strange. which cloudstack version did you test ?

@shwstppr can you test against Wei's steps to reproduce the issue against latest 4.14 branch

@shwstppr can you test against Wei's steps to reproduce the issue against latest 4.14 branch

@rhtyd @shwstppr
I tested with 4.15. it cannot be reproduced. strange
closed this pr. I will double check with 4.14

@shwstppr I updated the steps in description.
the issue can be reproduced.

@weizhouapache will test and update

@blueorangutan package

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✖centos7 ✖centos8 ✖debian. JID-2631

not sure why but I'm still not able to reproduce this.
My VMs were like,
VM-001 - IP: <IP_ADDRESS>
VM-002 - IP: <IP_ADDRESS>
VM-003 - IP: <IP_ADDRESS>
After I stopped VM-002 & VM-003, restarted network with cleanup and then expunged VM-002, the last entry in /etc/cloudstack/dhcpentry.json was not removed.
Later, on expunging VM-003, /etc/dhcphosts.txt still had an entry for VM-001

Packaging result: ✔centos7 ✖centos8 ✔debian. JID-2639

@blueorangutan test

@DaanHoogland a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests

Trillian test result (tid-3478)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 42266 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr4627-t3478-kvm-centos7.zip
Intermittent failure detected: /marvin/tests/smoke/test_kubernetes_clusters.py
Smoke tests completed. 83 look OK, 0 have error(s)
Only failed tests results shown below:

Test
Result
Time (s)
Test File

not sure why but I'm still not able to reproduce this.
My VMs were like,
VM-001 - IP: <IP_ADDRESS>
VM-002 - IP: <IP_ADDRESS>
VM-003 - IP: <IP_ADDRESS>
After I stopped VM-002 & VM-003, restarted network with cleanup and then expunged VM-002, the last entry in /etc/cloudstack/dhcpentry.json was not removed.
Later, on expunging VM-003, /etc/dhcphosts.txt still had an entry for VM-001

@shwstppr  strange.
I will test with cloudstack 4.16

@weizhouapache I was testing 4.14, #4150 to be specific

@weizhouapache I was testing 4.14, #4150 to be specific

@shwstppr I have tested with 4.14, 4.15 and 4.16. this issue can be reproduced.
I use ubuntu for testing.
could you please try again ?

@shwstppr can you test with Ubuntu 18.04 and see if that helps? @weizhouapache is the env adv zone or adv zone with SG, or some other permutation?

@shwstppr can you test with Ubuntu 18.04 and see if that helps? @weizhouapache is the env adv zone or adv zone with SG, or some other permutation?

@rhtyd @shwstppr I use advanced zone with isolated networks.
I will test with shared networks.

@shwstppr can you test with Ubuntu 18.04 and see if that helps? @weizhouapache is the env adv zone or adv zone with SG, or some other permutation?

@rhtyd @shwstppr I use advanced zone with isolated networks.
I will test with shared networks.

tested with shared network in advanced zone.
it has the same issue.

@weizhouapache @rhtyd I'm to reproduce the issue with 4.14 with Ubuntu18 mgmt and hosts. Testing the fix now


Automated cherry pick of #4193: fix: fetch hosts if no permission to access datacenter

Cherry pick of #4193 on release/2.12.
#4193: fix: fetch hosts if no permission to access datacenter

Codecov Report

:exclamation: No coverage uploaded for pull request base (release/2.12@dd54ff6). Click here to learn what that means.
The diff coverage is 3.22%.

@@              Coverage Diff               @@
##             release/2.12   #4195   +/-   ##
==============================================
  Coverage                ?   6.86%
==============================================
  Files                   ?     501
  Lines                   ?   85054
  Branches                ?       0
==============================================
  Hits                    ?    5838
  Misses                  ?   78723
  Partials                ?     493

Flag
Coverage Δ

#aFlag
6.86% <3.22%> (?)

Impacted Files
Coverage Δ

pkg/multicloud/esxi/mobase.go
0% <0%> (ø)

pkg/multicloud/esxi/datacenter.go
0% <0%> (ø)

pkg/multicloud/esxi/manager.go
1.87% <7.84%> (ø)

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 dd54ff6...4ea2d31. Read the comment docs.

/lgtm
/approve


fix react native 0.19.0 upgrade bugs for android

@rpopovici This contains changes that should not be made including returning arrays in the promise response.

@lwansbrough sorry for this. Don't know exactly how github pull request works. Can't you just cherry pick the relevant commit?

I guess this can be closed now since it was already merged. Thanks

@rpopovici :+1:


Reimplement value coerced

@solnic I took the branch @emmanuel was working on, and removed the ability for primitive to be a set of types. I think this should be enough to get it merged into the master branch.
I have some other ideas on how to allow the equivalent of a "sum type" that will probably be cleaner than our initial idea of allowing primitive to be a Set. It should also help with the Enumerable types like the Set and Array ones that will come in the future. I don't think we should hold back this line of code though since it should be compatible with what I'm considering too.

@dkubb are you going to clean the merge and add missing specs for the rest of the attributes? I can help you with that

@solnic I'm not sure what else needs to be cleaned. As for spec coverage, I think it's got full coverage as-is, but we could move around the specs to match the Veritas convention more closely.
I think we probably should shoot for converting to the Veritas convention asap, and configure it to work with heckle. Then when mutant comes in, it should be relatively simple to upgrade things. I would imagine we'd want the same spec organization for mutant too, since it will allow us to test the unit tests in total isolation.

@dkubb 'clean the merge' as in deal with 'This pull request cannot be automatically merged.' :)
Re: heckle, how much work is required to make it pass on rspec1 with heckle? Damn, I'm still not thrilled when I think about downgrading to rspec1.

@dkubb I'm intrigued to hear more about your strategy for handling 'sum-types' in a different way. I've just started scheming on a nice implementation of collection types (with optional member coercion), and I imagine that will overlap with whatever it is you have in mind.
In short, I'm thinking to start with (roughly):
class Virtus::Attribute
  def self.determine_type(type)
    case type
    when ::Array
      member_type = type.first || Object
      Virtus::Attribute::Array.with_member(member_type)
    # repeat for Set, Hash, etc
    else
      super # only deal with collections here, otherwise hand-off to Virtus::TypeLookup
    end
  end
end

This will require changing the coercion API, which I haven't completely thought through yet. Basically, for collection attributes, Virtus::Coercion.to_* will need information about how to perform the member coercion, as well as the collection coercion. My early hunch is that the parallel class hierarchies (Attribute and Coercion) should be merged at that point. I'll get clearer on these points and we'll see once there's actually code to discuss.

@emmanuel I should mention we've been thinking about extracting Coercion into a separate library but the more I think about it now the less I like that idea

@solnic Making virtus work with heckle? The actual plumbing can be setup in less than an hour. I'll do it myself.
The harder part will be filling in the holes where coverage is lacking. Tools like rcov aren't precise enough to give you a good indication of this; while they might report 90 or 95% the true coverage is likely much less. They rely on incidental coverage much of the time (that is when another piece of code "uses" some public method, and then that method is reported to be covered, when it has no unit tests itself).
I'm guessing that virtus has about 70-80% true coverage in the way I would measure it with heckle. That's pretty damn good as far as ruby projects go, most fall way below that.
While I don't care much about numbers (really) it's only a way to communicate the state of things in shorthand. What I'm more concerned about are the behaviours that currently have no coverage, and if there are bugs lurking in them or unspecified behaviours. There will be at least some mutations that aren't covered, probably a few hundred or so.
The heckle harness I setup will expose most of these holes, and then we can start gradually filling them in. I don't expect it to be able to be done overnight, but I do think we should start if we want this piece to be as high quality as the other pieces being used for DM2.

@emmanuel this is what I was thinking for the sum type: https://gist.github.com/1553965
This would allow types to be combined together, and/or for enumerables to contain non-homogenous entries.

@solnic I would be strongly opposed to tightly coupling coercions to virtus in such a way that it cannot be extracted into it's own gem. It's probably a good litmus test of any design that if it has to be tightly coupled to how virtus does things, it's probably a sign that there is something wrong with the design itself.

@dkubb oh I want to keep them separate, just not sure if I want them in a separate library :)
re: heckle, I hope 'the plumbing' won't turn our specs up side down. I still fear downgrading rspec.

ok, can you rebase and squash? It's easier for me to browse commits and update Changelog when I have 'atomic' commits...

Yeah sure. I'll do that for any branches I merge in (starting now).

thank you

Merged this in<PHONE_NUMBER> and 11fd1f5 (I got confused during the rebase/squash, so the specs ended up as a second commit).

Awesome, thanks!


add docker stats support

Signed-off-by: Victor Vieux<EMAIL_ADDRESS>

ping @crosbymichael @icecrime :dancer:

LGTM


⚠ Bofrost.be has degraded performance

In 5471563, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1185 ms

Resolved: Bofrost.be performance has improved in e343e33 after 8 minutes.


CMAKE not recognizing BuildType argument

Hi!
I'm passing -DCMAKE_BUILD_TYPE=Release argument to the cmakeAppendedArgs action, but CMAKE doesn't recognize it. Is there any extra step needed to make it work?

@rickomax thanks for the report!
I think that the problem is the following:

setting cmakeListsOrSettingsJson to CMakeListsTxtBasic;
setting any value for cmakeAppendedArgs, that is this mode is ignored, as documented:

 cmakeAppendedArgs:
    default: ""
    required: false
    description: "Provides a mean to provide all the CMake arguments.
This is required when using CMakeLists.txt in Advanced mode.
For CMakeSettings.json, the arguments are already inferred, but you can append
 your arguments providing them here.  Used by CMakeListsTxtAdvanced and CMakeSettingsJson modes."

I think the action should be improved and warn about any argument that is being currently set by the user but disregarded at the same time during execution.

I have the same problem, by using  cmakeBuildType: Release and cmakeGenerator: VS16Win64
CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_BUILD_TYPE

I see this
In the build pass, it also need passing a args --config Release with Visual Studio or Xcode.

@iovw thanks for the report!
The problem is that run-cmake action is passing CMAKE_BUILD_TYPE when it is not necessary (for example, when the Visual Studio generator is being used), and CMake is then correctly reporting the warning about 'unused input'.
In order to not show the warning, you could either use CMake's Ninja generator. Also take in consideration that with using cmakeListsOrSettingsJson : CMakeListsTxtAdvanced you can create your command line for CMake using cmakeAppendedArgs
I believe the original poster has a slightly different problem, we will find out.

This is my full command, which still doesn't work:
steps:
      - uses: actions/checkout@v2
      - uses: lukka/run-cmake@v0
        with:
          cmakeListsOrSettingsJson: CMakeListsTxtAdvanced
          cmakeListsTxtPath: '${{ github.workspace }}/CMakeLists.txt'
          useVcpkgToolchainFile: false
          buildDirectory: '${{ runner.workspace }}/build/win64'
          cmakeAppendedArgs: '-G "Visual Studio 16 2019" -DCMAKE_BUILD_TYPE=MinSizeRel -DASSIMP_BUILD_TESTS=OFF -DASSIMP_BUILD_ASSIMP_TOOLS=OFF -DASSIMP_NO_EXPORT=ON -DBUILD_SHARED_LIBS=ON -DUSE_AES=OFF -DZIP_64=ON -DSKIP_INSTALL_ALL=ON -DASSIMP_BUILD_ALL_IMPORTERS_BY_DEFAULT=ON -DSKIP_MSVC_UPDATE=ON -DCMAKE_CONFIGURATION_TYPES="MinSizeRel" --config MinSizeRel'

The --config containing the build type part must be called on the cmake --build command which I'm not sure the location

It worked!
I had to put it here:
buildWithCMakeArgs: '--config MinSizeRel'

If you feel like the addition of --config argument should happen automatically, let me know, i am always open to improvements.
I have not put efforts around this because i would strongly suggest to use Ninja: in this case there is no need to specify the config at build time (as it is a single configuration CMake's generator).

Yeah, I think it should passing the --config argument automatically, when using Visual Studio generator and specific a cmakeBuildType.

@iovw @rickomax  should be fixed now (i.e. for multi config generator the proper '--config' is passed at build time, and not CMAKE_BUILD_TYPE passed during configuration).

That's great.

Ty!


Switch from unsafeFlags to enableExperimentalFeature to enable strict concurrency checking

This removes one of our usages of .unsafeFlags in favor of .enableExperimentalFeature, which is helpful since .unsafeFlags cannot be safely used by clients (except when the package is local or using a branch for its dependency).

@swift-ci please test

Compiler crash:

Assertion failed: (Bits.ApplyExpr.ThrowsIsSet), function throws, file Expr.h, line 4662.

While lowering $s12TestingTests05IssueB0C31testCustomTestStringConvertibleyyYaF ---> TestingTests.IssueTests.testCustomTestStringConvertible() async -> ().

@swift-ci please test

Manually tested at-desk on macOS 14 and Ubuntu 22. A compiler bug in the latest toolchain prevents testing in CI. Team has approved merging.


scalastyle errorformat is incomplete

First and foremost thanks for the plugin!
The errorformat for scalastyle is incomplete:
$ cat a.scala
package constants
object Const {

}

val xxx: Int = 1.0

$ scalastyle -jar scalastyle_2.12-1.0.0-batch.jar -c scalastyle_config.xml a.scala
error file=/tmp/a.scala message=expected class or object definition
Processed 1 file(s)
Found 1 errors
Found 0 warnings
Finished in 357 ms

From within the file:
syntastic: 1.634872: CacheErrors: Invoking checker: scala/scalastyle
syntastic: 1.635354: SyntasticMake: called with options: {'subtype': 'Style', 'errorformat': '%trror file=%f message=%m line=%l column=%c,%trror file=%f message=%m line=%l,
%tarning file=%f message=%m line=%l column=%c,%tarning file=%f message=%m line=%l', 'makeprg': 'scalastyle -jar scalastyle_2.12-1.0.0-batch.jar -c scalastyle_config.xml a.scala', 'returns': [0, 1]}
syntastic: 2.187599: system: command run in 0.551897s
syntastic: 2.188784: getLocList: checker scala/scalastyle returned 0
syntastic: 2.189224: getLocList: checker scala/scalastyle run in 0.554239s

And I get zero errors/warninigs. See that 'errorformat' does not have:
    '%trror file=%f message=%m'

I have tried setting g:syntastic_scala_errorformat but it didn't work. Any workarounds until this issue is solved?

I get zero errors/warninigs.

Sadly, messages without line numbers are not that useful to syntastic.

I agree but maybe for completeness they should be included because they are still useful. An idea would be to assign them the line 1 or line zero (if possible) since they are probably module wide.

Messages without line numbers produce conflicts with the cursor notifier (the thing that shows messages on the last line when you move around the file), which eventually leads to Vim crashing.  This is a limitation of syntastic's design, and it has no easy fix. shrug

well no problem
thanks for the fast support


TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.
If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.
If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/52164

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/53121

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/53202

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/53482

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/54292

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/54359

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/54773

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/54866

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/54969

Triggering TagBot for merged registry pull request
This extra notification is being sent because I expected a tag to exist by now, but it doesn't.
You may want to check your TagBot configuration to ensure that it's running, and if it is, check the logs to make sure that there are no errors.


MongoDbMessageSource builds wrong messages array

What steps will reproduce the problem?
Configure yii2-advanced template for i18n translations:
`
'language' => 'th',
'sourceLanguage' => 'en-US',
'i18n' => [
'translations' => [
'app' => [
'class' => 'yii\mongodb\i18n\MongoDbMessageSource',
],
],
],
mongo collection:
{
"_id" : ObjectId("57a96d25c02fdb1991def59e"),
"category" : "app",
"language" : "th",
"messages" : [
{
"Recommended" : "Hallo Welt!"
}
]
}
somewhere in the view:
\yii\base\Event::on(\yii\i18n\MessageSource::className(), \yii\i18n\MessageSource::EVENT_MISSING_TRANSLATION, function ($event) {
Yii::trace(get_class($event->sender));
});
`
What's expected?
Yii::t('app', 'Recommended') --  "Hallo Welt!"
What do you get instead?
EVENT_MISSING_TRANSLATION
Additional info
Default PhpMessageSources works fine. MySQL defined message sources works fine.
Problem in structure of array. Look at MessageSource.php line 109.

Just need to make $messages array flat.

Unable to reproduce: MongoDbMessageSource works fine.
There is a unit test, which verifies it:
https://github.com/yiisoft/yii2-mongodb/blob/master/tests/i18n/MongoDbMessageSourceTest.php

I assume you get event handler trigger from some other message source since you bind your event handler to the base yii\i18n\MessageSource.

Sorry, for blaming source code, problem in documentation. I took collection example from http://www.yiiframework.com/doc-2.0/yii-mongodb-i18n-mongodbmessagesource.html
correct example for schema example should be:
{      "language" : "th",      "category" : "app",      "messages" : {         "Recommended" : "แนะนำโดย"        ...     } }

fe0f2b0f10714fb528f98ba800646e4f78ef522e

@kudzuu thanks!


go playground vet error?

What version of Go are you using (go version)?

$ go version 1.14

Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (go env)?
go env Output
$ go env

What did you do?

What did you expect to see?
the code here in the go playground compiles and runs but it shouldn't
https://play.golang.org/p/PRMEkdSGNsx
What did you see instead?
an error

nvm I see why it compiles


Allow c++14 as valid standard

Currently C++14 is a valid standard in cppcheck but not in the plugin.
Can you add it ?
Also, why is the plugin doing it's own check for these types of parameters? It forces the plugin to "keep up" with cppcheck changes, while it could be possible to pass the parameter to the underlying cppcheck executable and forward any occurring errors.

C++14 should now be the default in version 0.2.2. As for passing arbitrary parameters to the underlying engine, that could be a separate feature request. The extension checks most options otherwise in order to give a better user experience ("it just works").


Avoid a buffer getting overwritten during calls to send

If ITransportSender ends up queuing the buffers before sending (as we've seen in the case of the WS library in jsdom) then calls to send can overwrite the buffer incorrectly.  This change ensures that each call to send works on a newly allocated buffer.

Pull Request Test Coverage Report for Build 80020

3 of 3 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 88.554%

Totals

Change from base Build 79884:
0.0%

Covered Lines:
4420

Relevant Lines:
4796

💛  - Coveralls


New Feature form API?

Can You add set emergency mode?

or set temporary door locking rule? to stay on lock/unlock status?

First of all, thanks for your answer. I tried to fork and add options myself, but it's not my level yet :P
I was thinking about making two switches for Emergency Status
One set to true does evacuation, the other set to true does lockdown. Set to false disables this mode.
However, the Temporary Door Locking Rule, I don't really know how. I would like, or rather my wife ;) who is dissatisfied that she has to unlock the door with a card/PIN during the day, to be able to set the automation so that if someone is at home - leave it unlocked

@aLAN-LDZ I've been playing around with this and I was able to add switches to the integration:

However, I did notice that every time I hit either evacuation or lockdown, it will sound the alarm. No matter what the alarm setting is (even if it's set to never go off). Is this something you really want?
Also right now, it's polling for evacuation and lockdown status every 3 seconds. Since the websocket API is not documented I'd have to dig in and see if we do get emergency updates via websockets to avoid polling too much.

Generally, I need an option that will be able to leave the door in the "leave open" status, maybe the 7.10 API option will be better. I just found two examples. I looked at how they work on the UI website

Gotcha. So definitely not evacuation and lockdown then. The door locking rule adds some challenges from an interface standpoint. I am unsure if we should be using an input_select or a service call. input_select (basically a dropdown) may be better for ease of use but then that adds challenges for custom locking mode which requires an interval.

basically a dropdown seems like a better idea, if i could help somehow let me know.

@aLAN-LDZ can you try this branch and let me know if it works for you?

Yes, it works great, thank you.
I tested all settings.

Check out v1.2.0


Added the Klay layout for cytoscape

I used the cytoscape-klay package to add the Klay layout, matching the way you had done for fcose.  tested locally and it works.

Many thanks @ph11be for the pull request. Could you please include in your PR an update of the "Advanced layout" section of README.md to add a reference to Klay to concisely explain the added value of Klay and provide a minimalistic code sample (as it is done for fcose)?
Could you please also add as a comment in this discussion a minimalistic example of a Streamlit python script demonstrating the use ofst-cytoscape and Klay?


pull request for e2e test at 11/15/2016 09:45:09

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

optest/docs/updated_at.md
:white_check_mark:Succeeded

Details

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


Failed to modify guest Preferred  Language

Describe the Bug
I modified the English to Chinese.It doesn't work。
I logged out of my account and it still shows English. When I logged in again, the guest language settings page was automatically reset to English.
Steps to Reproduce

Login Admin
Go to Users Setting
modify Guest Preferred Language to Chinese
Log out Admin
guest access, the display is in English
Login Admin Again
Go to Users Setting
Guest Preferred Language displayed in English

Expected Behaviour
modify guest Preferred  Language Should work
Screenshots or Additional Context
No response
Browser Details
Chrome 103.0.5060.134
Exact BookStack Version
v22.07.3
PHP Version
No response
Hosting Environment
ubuntu 20.04

Hi @maojunxyz,
Technically, the anonymous user is not logged in as this account, it's just used for permission control, so their language option won't be applied for external/public use.
Please see this page in our docs for setting the default language:
https://www.bookstackapp.com/docs/admin/language-config/#setting-the-default-language


Optionally keep files from old build and don't process images that have already been processed

This PR does the following:

Expose the build option --keep={directory1,directory2} so we can optionally pass directories or files that should be kept from one build to another
Don't process images that have already been processed

The benefits are A and B below:
A) In combination, these two modifications allow us to save time on the build by passing the assets directory through the keep option.
gridsome build --keep=assets/static
With this command, the dist directory is cleared except for the images processed on the last build that were stored on ./dist/assets/static. These images get copied to a temporary directory and then copied back to (outDir) ./dist.
By the time image-processor.js gets to that image, it skips it since it already exists on the directory.
If you want to reprocess everything, just do gridsome build.
If you change any settings on the images being passed to  or on the graphQL query fetching the image - let's say you change the width - the hash for the file will change and the image will be processed no matter if you pass the --keep=assets option. The old image will be kept on ./dist/assets/static too, which leads us to item B.
B) Consider issue #488.

Your website is live and users are browsing it.
.html files are not cached by the browser, but users are browsing back and forth through your articles using the back button of the browser or swipe back on mobile - that means they are not reloading the html.
A new article is published, webhook hits Netlify and your website build process starts.
New assets get published with different hashes.
A new user hits your website, he gets the new version, everything works fine.
Users that were browsing your website during the publish process will get 404 errors when browsing back and forth through pages because the page data does not exist anymore on ./dist directory unless of course, they hit f5.

By allowing us to keep some files from the previous ./dist, we can work around this small issue too.
gridsome build --keep=assets,data,js,css
Downside is you will have more files published. Somewhere down the road, you will want to do a full gridsome build to clear up the ./dist. That could be ie: scheduled for Sunday at midnight.
B is mostly a consequence of A, because why not? But it kinda offers a solution to issue #488.
Also closes #494.
Looking forward for your input.

Thanks for looking into this @dominiquedutra :) This could be a nice feature. But I think it might be better to do this in a plugin instead (or in gridsome.server.js). Because the dist folder isn't available during the build process in services like Netlify, etc.
I think something like this could work, but I haven't tested:

Move contents of config.imagesDir to config.imageCacheDir in the beforeBuild hook
Gridsome checks the cache folder if an image is already processed and copies it to dist
Optionally delete config.imageCacheDir in the afterBuild hook to delete unprocessed images

The issue with missing assets after a new build will be fixed by reloading the page instead :)

Hey @hjvedvik
Of course, it's better. I did know about the hooks.
I am going to document a basic plugin for your appreciation. Been wanting to try a plugin anyway.
Thanks,

Hi @hjvedvik
In services like Netlify, we would need to add the processed images to the repository. So what about changing your suggestion above with the following?

Create a directory in the project to keep processed images (processedImagesDir); this directory and its content is added to the repository
In a server plug-in (or gridsome.server.js) do the following:

beforeBuild: move content of processedImagesDir to config.imageCacheDir
afterBuild: copy content of config.imagesDir to processedImagesDir

In our workflow, it will be required to run gridsome build before committing and pushing to the repository and triggering a Netlify build

Is this reasonable?
Thanks,
Ricardo


Kubevirt + Ubuntu Testing

Has kubevirt-tdx been tested with Ubuntu-based K8 installation?
cc: @mengmeiye

hi @apoorvemohan  @mengmeiya
I updated the wiki about build section.(kubevirt-tdx doest not provide pre-built images) If mengmei wants to try the kubevirt-tdx, you can follow it.
if meet any problems, feel free to pin me.

Thanks @LeiZhou-97

Hi @mengmeiye ,
Are you install the TDX host stack in advance ?

@LeiZhou-97: Yes the TDX host stack has been installed.

Do you try to launch the traditional TDVM successfully on bare-metal?
The error log points the host stack is not installed. kvm is out-of-scope of kubevirt-tdx.
Please check if TDX is initialized through dmesg.
kvm: vm-type tdx not supported by KVM

Oh I think the error is because  qemu-kvm inside of the pod doesn't support tdx. The host is enabled with TDX, and I can successfully launch a TDVM on bare-metal.

Oh I think the error is because qemu-kvm inside of the pod doesn't support tdx. The host is enabled with TDX, and I can successfully launch a TDVM on bare-metal.

No, it's qemu call the kvm to do the feature check and find tdx not supported by kvm. If qemu-kvm doesn't support tdx, it will tell you tdx is unrecognized.
And I only provide the tdx-enabled qemu-kvm in the source, it's impossible to install a non-tdx qemu-kvm package.
rpm(
    name = "qemu-kvm-core-17__8.0.0-15.el9s.x86_64",
    sha256 = "3b9f9995b3dfacf78c237952afefad71f495a48d62ffd20cd90ced0e6ed7db70",
    urls = [
        "http://mirror.stream.centos.org/SIGs/9-stream/virt/x86_64/tdx-devel/Packages/q/qemu-kvm-core-8.0.0-15.el9s.x86_64.rpm",
    ],
)

Which host stack are you using? I guess it may be caused by the host stack is not aligning with the guest stack within the pod.

This is the tdx stack I'm using: https://github.com/intel/tdx-tools/tree/2023ww15

Currently, the kubevirt-tdx only work with mid-stream stack.
ubuntu: https://github.com/canonical/tdx/tree/mantic-23.10
centos: https://mirror.stream.centos.org/SIGs/9-stream/virt/x86_64/tdx-devel/


[BUG]: "Accept-Invite" link leads to blank page

What happened?
A user encounters a blank page after clicking on an "accept-invite" link received via email from a workspace admin or owner.
Steps to reproduce

Admin or owner sends an invite
User receives the invite email and clicks on the link
User experiences a blank page instead of the expected content

Expected behavior
The expected behavior is a confirmation and redirection to the login page.
Additional context
The issue has not been reproducible on my end. Further investigation is needed to identify and resolve the underlying cause.

Solved by https://github.com/fonoster/goodtok/commit/031f0d0b9f483e408890a1873bb5a88167b16a88


fix(iOS): displaying irregular borders on iOS Fabric

Summary:
This PR solves issue with displaying irregular borders on Fabric. The same issue appears on the old architecture, but I am having a problems there, so I am pushing this fix for now.
The problem is solved by decoupling backgroundColor from borderLayer and setting zPosition on borderLayer to 1024.0f, so that the border is always in front of the layer. The zPosition is compared within a layer, so it shouldn't impact outside components. I would love to hear your opinion if there is a case in which this could break.
Changelog:
[IOS] [FIXED] - changed border display
Test Plan:
I've checked that on RNTester Images.

I am trying to replicate the same mechanism (creating a borderLayer and setting it as a sublayer of layer). Unfortunately, the zPosition makes the border come above children of the view. I am not sure why is that, but I am still working on it.

The new approach clips the inner image separately (as this bug occurs for images only) according to its bounds and the border's corner insets. We keep the previous value of zPosition, so it should be drawn in the same way as css does.

@coado could you please resolve the merge conflict? 🙏

What do you think of this solution?

Set the zPosition of the contentView (which holds the image, among other things), to be less than the borderLayer
Refactor border drawing the be agnostic of the layer's background color (so resulting image is just the border, no pixels for background color). If we do not do this, the backgroundColor would now hide the image that is under this layer.
Introduce a layer that holds the background color and the appropriate shape using mask, if necessary

If we are clipping for this view then we wouldn't need to do this, we could just set the mask on the current layer, but its a generalized solution for all cases. We could optimize fast paths if needed like those that currently exist for border rounding

Btw, this area has a ton of churn right now. There is this PR, @jorge-cab is working on asymmetrical border radius % in #46009, and I am prototyping how to get box shadows to work with clipping (which relates to borders and masks). I feel like we just need to clean this area up some, and have a good story for how each element of the background/border area works.
Lmk if the steps above would miss some edge case you have thought about

Hey @coado, was thinking about this more and the above refactor I mentioned would in theory fix some problem I am running across with trying to get outset box shadows to work with clipping, so I went ahead and started on some of that refactor (specifically the second bullet point). I think we can just land this as is, but I might refactor some of it in the coming days

Hey @coado, was thinking about this more and the above refactor I mentioned would in theory fix some problem I am running across with trying to get outset box shadows to work with clipping, so I went ahead and started on some of that refactor (specifically the second bullet point). I think we can just land this as is, but I might refactor some of it in the coming days

Hey, so I've resolved the merge conflicts. I was thinking about the solution that you provided, but I wasn't sure if we wanted to keep the border in front of the image. I think it will work, but I haven't tested it myself. Should I proceed with it or is it something that you want to implement in the future?


Quickstart_guide.md added

Added quickstart guide with just implementation steps

Two things we need to add this to the menu and we need to specify which OS this works for I think its RHEL8

This works with RHEL 7.6(podman) and Amazon Linux(docker)


It works incorrectly

I have layout
const size = create({ width: 360, height: 640 })

And real sizes are
{
  height:<PHONE_NUMBER>666666
  width: 360
}

And size(344) =<PHONE_NUMBER>65079, this is not correct

function create({ width = 360, height = 640 } = {}) {
  const { width: deviceWidth, height: deviceHeight } = Dimensions.get('window')
  const widthResolution = deviceWidth / width
  const heightResolution = deviceHeight / height

  return {
    height: (size) => Math.floor(size * heightResolution),
    width: (size) => Math.floor(size * widthResolution),
  }
}

How is this solution, for each side

@himelbrand

@dmitryshelomanov It doesn't work for me as well. Were you able to implement it properly?

@abhikulshrestha22
export const { width, height } = Dimensions.get("window")

const baseWidth = 320
const baseHeight = 568

const scaleW = width / baseWidth
const scaleH = height / baseHeight

export const normalizeSize = (prevSize: number, dir?: "w" | "h") => {
  const newSize = prevSize * (dir === "h" ? scaleH : scaleW)

  return Math.floor(PixelRatio.roundToNearestPixel(newSize))
}

At now I have this solution
And it works
But + width side - not sure


feat(cdc): create external table reader with retry for backfill

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
Previously we try to create the table reader in src/stream/src/from_proto/stream_cdc_scan.rs, if upstream database is down, the executor cannot be built so that the cluster will enter recovery loop. This pr try to create the table reader after we forward the initial barrier, so that it won't block recovery if cannot connect to upstream db.
close #17807
Checklist

[ ] I have written necessary rustdoc comments
[ ] I have added necessary unit tests and integration tests
[ ] I have added test labels as necessary. See details.
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
[ ] All checks passed in ./risedev check (or alias, ./risedev c)
[ ] My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

[ ] My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

[ ] My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

As per discussion in https://github.com/risingwavelabs/risingwave/issues/17807#issuecomment-2249576983, may I know if this still holds?

When creating the physical executor of a new source, we recommend throwing errors to users immediately when creating actors and calling from_proto.

As per discussion in #17807 (comment), may I know if this still holds?

When creating the physical executor of a new source, we recommend throwing errors to users immediately when creating actors and calling from_proto.

This pr doesn't modify the code of Source, so the behavior is same as before. For the cdc backfill executor, previously if we fail to create the table reader, the stream job will fail to create.

Can we add tests to verify this PR is working and prevent future regression?
I tried the following two cases with this PR:

Start RW/MySQL -> Create cdc table -> shutdown MySQL

Start RW/MySQL -> Create cdc table -> shutdown RW -> shutdown MySQL -> Start RW

1 works but 2 doesn't. The cluster is in recovery loop due to

error=get error from control stream, in worker node 1: gRPC request to stream service failed: Internal error: recv actor failure: Actor 1 exited unexpectedly: Executor error: Connector error: Connector configuration is not valid. Unable to connect: Communications link failure

I guess it is related to source validation before creating the source executor.

I have tested again and cannot reproduce this issue. I created a source and table, then shutdown rw and postgres. Restart rw and then create a mv based on the table, everything is ok. Finally I restart postgres, the cdc source can be resumed.

Can we add tests to verify this PR is working and prevent future regression?
I tried the following two cases with this PR:

Start RW/MySQL -> Create cdc table -> shutdown MySQL
Start RW/MySQL -> Create cdc table -> shutdown RW -> shutdown MySQL -> Start RW

1 works but 2 doesn't. The cluster is in recovery loop due to

error=get error from control stream, in worker node 1: gRPC request to stream service failed: Internal error: recv actor failure: Actor 1 exited unexpectedly: Executor error: Connector error: Connector configuration is not valid. Unable to connect: Communications link failure

I guess it is related to source validation before creating the source executor.

I have tested again and cannot reproduce this issue. I created a source and table, then shutdown rw and postgres. Restart rw and then create a mv based on the table, everything is ok. Finally I restart postgres, the cdc source can be resumed.

The mysql source can reproduce the issue: Executor error: Connector error: Connector configuration is not valid. Unable to connect: Communications link failure, I am investigating.


ComponentScan as a list of packages

Is your feature request related to a problem? Please describe.
I have a multi-model project and the interfaces in project A don't bind in project B
Describe the solution you'd like
Provide an opportunity to specify the packages in ComponentScan annotation

You would need to specify several packages in @ComponentScan?

@arnaudgiuliani yes, I think something like that

@arnaudgiuliani my issue is related by this problem https://github.com/InsertKoinIO/koin-annotations/issues/7

Then is it just a problem to use external package/interface, or your need is to have a Module to cover many packages?

@arnaudgiuliani, Hi! Sorry for the long answer.
I have the following project structure: two app projects (com.example.app, com.example.secondApp) and one core lib (com.example.core) with described interfaces. And when I applied @Single annotation on class in com.example.app package, and class implements an interface from com.example.core package, ksp ignoring a binding of a class.
![Uploading Screenshot 2022-04-30 at 18.14.35.png…](should be)
![Uploading Screenshot 2022-04-30 at 18.14.44.png…](generating without binding => koin doesn't inject by interface)

and to "fix that" I just rewrite my interfaces in com.example.app class and additionally specified binding

oh... I upgraded to the second beta and it solved my problem :D

The issue is closed, workarounds are available (I'm using @Module::includes), but is there a way to scan multiple packages using one class with @ComponentScan annotation(s)?


[Bug] Display name of Wand Item, Effects display name of Spells. + Lore on spells not working

Version: Magic-10.8.1
Server Version:

Config of Wand:
# This is the key name of this wand
# It must be unique across the server, and is used in commands such as /wand and /mgive to refer to this wand.
Fluffys_Cake:
  # These track who created what spells, you can remove them if you want
  creator: Ash10744
  creator_id: 1ca75b77-6280-4eb3-8c86-58cf8ff13d8e
  # Name and description may be added here and will appear in lore for this wand.
  name: Fluffos Cake
  description: Don't eat it
  display_name: §8[§5Unique§d+§8] §5Fluffos Cake
  lore:
    - §8―――――――――――――――――――――――§d―――§8―――――――――――――――――――――――
    - §eA Magical Staff of the Fluffy
    - §8―――――――――――――――――――――――§d―――§8―――――――――――――――――――――――
    - '§cMana: §3$mana'
    - '&CCurrent Spell: §f$spell'
    - §8―――――――――――――――――――――――§d―――§8―――――――――――――――――――――――
  # Inherit from the base_wand template to get basic wand functionality
  # Such as spell inventory and key bindings
  # Other options include: basic_wand, base_bound, base_magic
  inherit: base_wand
  # Choose an icon, this is the item the wand will appear as
  icon: Crossbow{CustomModelData:10010}
  # Give the wand some mana for casting
  mana_max: 5000
  mana: 5000
  # The wand regenerates this amount of mana every second
  mana_regeneration: 5000
  # Give the wand some spells to cast
  spells: []

Config of Spell:
# This is the key name of this spell
# It must be unique across the server, and is used in configs and commands such as /mage, /wand and /mgive
# to refer to this spell.
spark:
  # These track who created what spells, you can remove them if you want
  creator: Ash10744
  creator_id: 1ca75b77-6280-4eb3-8c86-58cf8ff13d8e
  # Name and description may be added here and will appear in lore for this spell.
  name: §8[§dSpell§8] §6Spark
  description: The user conjures forth a spark to cause light.
  lore:
  - §8test
  - '§8%xp%'
  # Choose an icon, used when showing this spell in a wand inventory.
  icon: meteor
  category: combat
  worth: 0
  earns: 0
  cooldown: 10
  upgrade: true
  actions:
      cast:
      -  class: EntitySelect
         actions:
         -  class: CustomProjectile
  effects:
      cast:
      -  class: EffectSingle
         sound: entity_generic_burn
         location: origin
         color_override: color_override
         effectlib:
           class: ConeEffect
           particle: flame
           lengthGrow: 0.1
           radiusGrow: 0.003
           updateLocations: false
           updateDirections: false
  parameters:
      allow_max_range: true
      velocity: 200
      range: 8
      hitbox: true
      target_type: Damageable
      player_damage: 2
      entity_damage: 4
      target_breakables: 1
      cooldown: 15 seconds
      reorient: false
      destructible: solid
      destructible_durability: 50
      break_durability: 2
      undo: 10000
  costs:
      mana:

Bug Proof:
The Spell with the display name on the wand:

The spell without a display name on a wand:

I also found it works fine if the spell is in my inventory not on my Hotbar. So I believe this to be a bug.
The lore on the spell doesn't also display properly I am unsure if I have done something wrong but it won't display properly despite the wand I am using.

If I'm understanding what you're saying, this is intentional. Otherwise when you switch spells by using the hotbar it will look very glitchy as Minecraft wants to show the name of the spell for a brief moment.
This is why all the spells in your hotbar are usually renamed to include the wand name.
When using a fixed display name for the wand, it doesn't show the spell name and so has to resort to renaming all of the spells to be just the wand name.
It's possible I could change this for wands that don't use inventory mode or other special cases, but that is the reasoning behind what's going, let me know if that does not make sense.

Yeah what I am saying is I am trying to rename the spells to be different and not include the wand name, is that possible or?

No, because it will cause the UI to glitch out.
I can leave this ticket open and add a way but you probably won't want to use inventory mode in that way.

Ah okay, I will see if I can reformat the name, and the lore on the spells is that the same? Or can that be solved?

Alright yeah thanks for the help if there is a way that could be implemented that'd be fantastic 😀

For spell lore, you can use description then I think you could turn off all the auto-lore via messages.yml, that'd turn them off for all spells in the game though.

Alright I will look to see if I can do that. We are limiting spells on my server so it's all manually added to a wand for a player. So it wouldn't really matter about all the lore stopping as long as I could essentially do custom lore.

The next dev build (https://jenkins.elmakers.com) will have a new wand parameter spells_use_wand_name: false to use the bare spell names, as well as support for a lore string list on spells to replace the autogenerated lore.


getVideoPlayerOptions

Description

Issue Ticket Number
Fixes #154

Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Fix or improve the documentation
[ ] This change requires a documentation update

Checklist

[ ] I have followed the contributing guidelines of this project as mentioned in CONTRIBUTING.md
[ ] I have created an issue ticket for this PR
[ ] I have checked to ensure there aren't other open Pull Requests for the same update/change?
[ ] I have performed a self-review of my own code
[ ] I have run tests locally to ensure they all pass
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes needed to the documentation

closed in favor of https://github.com/cloudinary-community/cloudinary-util/pull/156


[QUESTION] How do I install this on Debian 12?

Doing "./run.sh" on Debian 12 doesn't work and gives me the following result:
creating build/lib.linux-x86_64-cpython-312
      creating build/lib.linux-x86_64-cpython-312/tokenizers
      copying py_src/tokenizers/__init__.py -> build/lib.linux-x86_64-cpython-312/tokenizers
      creating build/lib.linux-x86_64-cpython-312/tokenizers/models
      copying py_src/tokenizers/models/__init__.py -> build/lib.linux-x86_64-cpython-312/tokenizers/models
      creating build/lib.linux-x86_64-cpython-312/tokenizers/decoders
      copying py_src/tokenizers/decoders/__init__.py -> build/lib.linux-x86_64-cpython-312/tokenizers/decoders
      creating build/lib.linux-x86_64-cpython-312/tokenizers/normalizers
      copying py_src/tokenizers/normalizers/__init__.py -> build/lib.linux-x86_64-cpython-312/tokenizers/normalizers
      creating build/lib.linux-x86_64-cpython-312/tokenizers/pre_tokenizers
      copying py_src/tokenizers/pre_tokenizers/__init__.py -> build/lib.linux-x86_64-cpython-312/tokenizers/pre_tokenizers
      creating build/lib.linux-x86_64-cpython-312/tokenizers/processors
      copying py_src/tokenizers/processors/__init__.py -> build/lib.linux-x86_64-cpython-312/tokenizers/processors
      creating build/lib.linux-x86_64-cpython-312/tokenizers/trainers
      copying py_src/tokenizers/trainers/__init__.py -> build/lib.linux-x86_64-cpython-312/tokenizers/trainers
      creating build/lib.linux-x86_64-cpython-312/tokenizers/implementations
      copying py_src/tokenizers/implementations/sentencepiece_unigram.py -> build/lib.linux-x86_64-cpython-312/tokenizers/implementations
      copying py_src/tokenizers/implementations/char_level_bpe.py -> build/lib.linux-x86_64-cpython-312/tokenizers/implementations
      copying py_src/tokenizers/implementations/base_tokenizer.py -> build/lib.linux-x86_64-cpython-312/tokenizers/implementations
      copying py_src/tokenizers/implementations/bert_wordpiece.py -> build/lib.linux-x86_64-cpython-312/tokenizers/implementations
      copying py_src/tokenizers/implementations/__init__.py -> build/lib.linux-x86_64-cpython-312/tokenizers/implementations
      copying py_src/tokenizers/implementations/sentencepiece_bpe.py -> build/lib.linux-x86_64-cpython-312/tokenizers/implementations
      copying py_src/tokenizers/implementations/byte_level_bpe.py -> build/lib.linux-x86_64-cpython-312/tokenizers/implementations
      creating build/lib.linux-x86_64-cpython-312/tokenizers/tools
      copying py_src/tokenizers/tools/visualizer.py -> build/lib.linux-x86_64-cpython-312/tokenizers/tools
      copying py_src/tokenizers/tools/__init__.py -> build/lib.linux-x86_64-cpython-312/tokenizers/tools
      copying py_src/tokenizers/__init__.pyi -> build/lib.linux-x86_64-cpython-312/tokenizers
      copying py_src/tokenizers/models/__init__.pyi -> build/lib.linux-x86_64-cpython-312/tokenizers/models
      copying py_src/tokenizers/decoders/__init__.pyi -> build/lib.linux-x86_64-cpython-312/tokenizers/decoders
      copying py_src/tokenizers/normalizers/__init__.pyi -> build/lib.linux-x86_64-cpython-312/tokenizers/normalizers
      copying py_src/tokenizers/pre_tokenizers/__init__.pyi -> build/lib.linux-x86_64-cpython-312/tokenizers/pre_tokenizers
      copying py_src/tokenizers/processors/__init__.pyi -> build/lib.linux-x86_64-cpython-312/tokenizers/processors
      copying py_src/tokenizers/trainers/__init__.pyi -> build/lib.linux-x86_64-cpython-312/tokenizers/trainers
      copying py_src/tokenizers/tools/visualizer-styles.css -> build/lib.linux-x86_64-cpython-312/tokenizers/tools
      running build_ext
      running build_rust
      error: can't find Rust compiler

      If you are using an outdated pip version, it is possible a prebuilt wheel is available for this package but pip is not able to install from it. Installing from the wheel would avoid the need for a Rust compiler.

      To update pip, run:

          pip install --upgrade pip

      and then retry package installation.

      If you did intend to build this package from source, try installing a Rust compiler from your system package manager and ensure it is on the PATH during installation. Alternatively, rustup (available at https://rustup.rs) is the recommended way to download and update the Rust compiler toolchain.
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
  ERROR: Failed building wheel for tokenizers
  Building wheel for progressbar (setup.py) ... done
  Created wheel for progressbar: filename=progressbar-2.5-py3-none-any.whl size=12067 sha256=245ae051bfd4e90426cd943becd254d159fe2afe6f5b4005a8c191bf093c3a7a
  Stored in directory: /home/scott/.cache/pip/wheels/a5/4d/c7/f3cf0f75c746c219090060131fe00f1523cc2c5484991f4030
Successfully built tortoise-tts progressbar
Failed to build tokenizers
ERROR: Could not build wheels for tokenizers, which is required to install pyproject.toml-based projects

How do I install this on Debian 12?

According to the readme:
This code works on python 3.10 (lower versions don't support "|" type annotations, and i believe 3.11 doesn't have support for the TTS library currently).

This could be the reason, it appears you are using Python 3.12 which might not have all of the prebuilt wheels. When wheels are missing, you need a bunch of developer tools on your system. In this case it seems to be Rust compiler.
For most projects I highly recommend 3.10 or even lower, depending on what the Readme says. Due to various reasons, python is a lot more sensitive than node.js and other languages when it comes to 3.10 vs 3.11 etc.


Introduce straightforward, comprehensible version scheme

#34 suggests to just release a 1.0. In a recent discussion with @probonopd, I proposed an alternative scheme which I think is very much superior to just starting with a 1.x release with the current state for multiple reasons. Before a decision is made, I think it makes sense to thoroughly discuss the semantics of such versioning.
Yes, I know, another lengthy issue... but there is no point in rushing things either...
In my opinion, the spec version number should be equivalent to the current AppImage type, and should be extended to a full major.minor.patch number. We could use semantic versioning, a concept widely used and well understood by programmers.
As a result, the current specification would be released as a 2.0.0, marking the initial release.
Keeping the numbers in sync makes it very straightforward for people seeking to implement support for a specific type to find the correct document. It makes it easier for us to ensure some sane versioning semantics on either end. And, after all, it is close to what we have done so far with the spec.
Main Semantics
The AppImage community can expect the following semantics:

Every major breaking change leads to a new version of the specification, which also leads to a new type. As long as things can be kept compatible, i.e., only bug fixes and new compatible features may be added to the spec, as demanded by semver, which I think is a good strategy. Tools that work with AppImages can expect proper forward compatibility: any feature included in an AppImage type 3.2 can be expected from a type 3.9, too (i.e., >=3.2, <4). With a 4.0, they need to react and ensure their tool continues to work.
Whenever a new major release is made, the old type will essentially no longer be maintained. While this may be confusing, in my opinion, this is a good idea. We are a small team and cannot support types to eternity. Situations leading to the creation of an entirely new type are really, really rare. And we want to bring this to people's attention then. Of course, good documentation of changes would be appreciated, including some "what changed?" or "what this means for me" snippets.
Minor changes, e.g., the addition of a new runtime parameter, lead to minor releases. Tools that work with AppImages can expect reasonable backwards compatibility: if they support type 1 and type 2 up to 2.4 for instance, every AppImage that falls into that range is fully compatible. A newer AppImage of some hypothetical type 2.6, will continue to work, even though the newly added features cannot be easily used.
Bug fixes should always supported, as permitted by semver. A tool that supports 2.6 AppImages should always accept any 2.6.x release, because the patch number only increases with bug fixes, after all.

Challenges

Changes need to be evaluated correctly, including possible side effects. For instance, adding a new allowed compression type to the spec could be seen as a minor change at a first glance. However, it really is a major change. Tools that want to work with AppImages to, e.g., extract desktop integration information directly from the integrated filesystem need to know which ones to expect so they can implement support. Suddenly adding a new variant violates the semantics described above. Of course, once this happens, one can think of solutions to avoid such situations in the future. A very good idea is to just move those data into some .zip in between the runtime and the payload, as described in some other issue.
Depending on the situation, it may make sense to continue maintaining some old type on a feature branch, e.g., when developing an entirely new type. But hey, after all, we take into account such minor inconveniences if it avoids complexity for users.
Bug fixes can be backported at any time, but that means that we'll have to do release older versions of the specification in between. For instance, while the latest release is 2.7.1, we may have to make a 2.6.9 release. That, however, can be seen as an advantage, as it increases compatibility levels. That said, I do not expect such a situation. Once a 2.7.1 is released, all the tools should use that one from now on. I just wanted to mention this. (This is daily business in software release management anyway.)

I'm sure there are more. Please add yours in a comment.

It might be worth starting a new numbered spec file for each major release and having a latest file that is a symlink to the most recent major release, plus a draft file where you add things that are not ready for the main files.
draft.md
latest.md -> appimagespec-v3.md
appimagespec-v3.md
appimagespec-v2.md

This way implementors can quickly see what the spec used to look like for a particular version without having to trawl through the Git history, plus it saves you having to write "New in version X" all over the place. The system could be extended to minor versions too, though that might be more trouble than it's worth.
draft.md
latest.md -> spec/3/appimagespec-v3.2.md
spec/3/appimagespec-v3.2.md
spec/3/appimagespec-v3.1.md
spec/3/appimagespec-v3.0.md
spec/2/appimagespec-v2.0.md

Caveat: now the Git history wouldn't show the difference between versions (since each version is in a new file) although the history of draft.md would essentially show this.

As per discussion with TheAssassin, we will simplify things as follows:

Instead of having multiple types (type 0, type 1, type 2) which were thought like different profiles (as in PDF), we see that in reality only one type (the newest one) is actively used
Hence, going forward, we will not have multiple AppImage types at the same time
The types will hence be called versions from now on
The AppImageSpec will try to follow semver with major and minor versions
The AppImage runtime that implements a certain version of the AppImageSpec will have the same version number as the AppImageSpec, plus a patch level

@shoogle have a look at https://github.com/AppImage/AppImageSpec/tree/next (still wip)

Basically, this means whenever a new "type" (version) is released, all the tools will be switched to a new major version, same for the runtime. The old stuff will continue to work in theory, but we are going to cease support immediately since we are a small team anyway.

Let's hope we won't end up like USB (in German but probably understandable even if you don't understand German) ;-)


Multiple minor pipeline runtime updates

Developer's Certificate of Origin 1.1
   By making a contribution to this project, I certify that:

   (a) The contribution was created in whole or in part by me and I
       have the right to submit it under the Apache License 2.0; or

   (b) The contribution is based upon previous work that, to the best
       of my knowledge, is covered under an appropriate open source
       license and I have the right under that license to submit that
       work with modifications, whether created in whole or in part
       by me, under the same open source license (unless I am
       permitted to submit under a different license), as indicated
       in the file; or

   (c) The contribution was provided directly to me by some other
       person who certified (a), (b) or (c) and I have not modified
       it.

   (d) I understand and agree that this project and the contribution
       are public and that a record of the contribution (including all
       personal information I submit with it, including my sign-off) is
       maintained indefinitely and may be redistributed consistent with
       this project or the open source license(s) involved.

@ajbozarth Here is the visual for the updated properties

Thanks Luciano. Should these sentences include periods?  (Not sure what the UX book says here.)
Also, can we expand var to variable in the second line of the Environment Variables?
I see that some headers use capitalization of each word (last two), others do not (first two).  I think we need to be consistent here - either way.

I agree with @kevin-bates we should spell out variable in the text, we should be consistent in title capitalization (I'm fine with either choice though) and since the placeholder text is now 2 lines we should include periods (I believe that is typical UX).

Rebased and updated with review feedback


ring.DoBatch with goroutine pool

This adds an option to ring.DoBatch to run the callbacks through a function provided that could make use of a goroutine pool (with concurrency.ReusableGoroutinesPool as an implementation).
This should help in Mimir's distributors to avoid extra stack allocation on every new goroutine created to perform a push to an ingester.
Since there was a recent change to DoBatch that added an isClientError param, I made a more generic version DoBatchWithOptions. I also made the cleanup optional, since I see it's
not so common to pass it down.
With this change, I also marked as deprecated the default ring.DoBatch version.
I did two benchmark versions, showing some imrovement in CPU time on the pooled version:
$ benchstat -col /go bench.txt
goos: linux
goarch: amd64
pkg: github.com/grafana/dskit/ring
cpu: 11th Gen Intel(R) Core(TM) i7-11700K @ 3.60GHz
                 │   default    │  concurrency.NonBlockingWorkerPool   │
                 │    sec/op    │    sec/op     vs base                │
Batch10x100-16     69.04µ ±  0%   64.53µ ±  0%   -6.53% (p=0.000 n=20)
Batch100x100-16    131.6µ ±  1%   123.8µ ±  1%   -5.94% (p=0.000 n=20)
Batch100x1000-16   2.088m ± 30%   1.146m ± 39%  -45.12% (p=0.001 n=20)
geomean            266.7µ         209.2µ        -21.57%

Could you please update CHANGELOG.md and write the improtant changes this PR brings:

ring.DoBatchWithOptions() has been added.
ring.DoBatch() and ring.DoBatchWithClientError() have been deprecated.

I have updated the CHANGELOG.md, however since we don't do releases, and changelog is sorted by section type (CHANGE/FEATURE/ENHANCEMENT/BUGFIX) instead of the date, I think it's quite useless.


Prometheus metrics for WCA playbook expgen APIs

Jira Issue: AAP-25884 & AAP-25894

Description

Implement prometheus metrics for WCA playbook explaination/generation APIs.  Following metrics are added:

wca_codegen_playbook_hist
wca_codegen_playbook_retry_counter
wca_explain_playbook_hist
wca_explain_playbook_retry_counter

Testing

Unit test cases are included.
Steps to test

Pull down the PR
Run unit tests

Scenarios tested

See above
Production deployment

[X] This code change is ready for production on its own
[ ] This code change requires the following considerations before going to production:

Thank you Tami for the PR split <3.