hydrographic_msgs: 1.1.0-1 in 'noetic/distribution.yaml' [bloom]

Increasing version of package(s) in repository hydrographic_msgs to 1.1.0-1:

upstream repository: https://github.com/apl-ocean-engineering/hydrographic_msgs.git
release repository: https://github.com/apl-ocean-engineering/hydrographic_msgs-release.git
distro file: noetic/distribution.yaml
bloom version: 0.11.2
previous version for package: null

acoustic_msgs
* Fix ProjectedSonarImage comments about frame (#26 <https://github.com/apl-ocean-engineering/hydrographic_msgs/issues/26>)
* Add CI, pre-commit, prerelease and dependabot (#27 <https://github.com/apl-ocean-engineering/hydrographic_msgs/issues/27>)
  Co-authored-by: Laura Lindzey<EMAIL_ADDRESS>* Merge pull request #25 <https://github.com/apl-ocean-engineering/hydrographic_msgs/issues/25> from apl-ocean-engineering/add_migration_rule
  Add migration rule from v0.0.1 to 28ec6a7
* Add migration rule from v0.0.1 to 28ec6a7
* Merge pull request #22 <https://github.com/apl-ocean-engineering/hydrographic_msgs/issues/22> from rolker/fix_variable_name
* Rename num_beams to beam_count.
* Merge pull request #21 <https://github.com/apl-ocean-engineering/hydrographic_msgs/issues/21> from CaptKrasno/acoustic_msg_devel
* Contributors: CaptKrasno, Laura Lindzey, Roland Arsenault, Vatan Aksoy Tezer, lauralindzey

environmental_msgs
* Add CI, pre-commit, prerelease and dependabot (#27 <https://github.com/apl-ocean-engineering/hydrographic_msgs/issues/27>)
  Co-authored-by: Laura Lindzey<EMAIL_ADDRESS>* Fix typo in package.xml
* Contributors: Laura Lindzey, Vatan Aksoy Tezer

Holding for Noetic sync

New package review:

[ ] At least one of the following must be present

[ ] Top level license file:
[ ] Per package license files:

[ ] License is OSI-approved: BSD is ambiguous especially without a license file in the repository
[ ] License correctly listed in package.xmls

[ ] environmental_msgs: https://github.com/apl-ocean-engineering/hydrographic_msgs/blob/main/environmental_msgs/package.xml#L11
[ ] acoustic_msgs: https://github.com/apl-ocean-engineering/hydrographic_msgs/blob/main/acoustic_msgs/package.xml#L11

[ ] Public source repo: SOURCE_REPO_URL
[ ] Source repository contains ROS packages and each package meets REP-144 naming conventions

[ ] acoustic_msgs
[ ] environmental_msgs

Before this repository can be released some changes need to be made.
@vatanaksoytezer this repository is missing a license file and as a result the package.xml license entry BSD is ambiguous. Consider using a SPDX identifier instead of just BSD.
I'd like to get a second opinion on the package names here I'm right on the fence about whether "acoustic" and "environmental" are sufficient especially when neither is implicitly underwater. @cottsay what are your thoughts?

@nuclearsandwich sounds good. I'm just helping for release, tagging @lauralindzey, who is the actual maintainer for opinions on licensing and packaging names.

@nuclearsandwich -- what's involved in the naming review / what do I need to do to kick that off?
I don't love the current package names, but they're the result of brainstorming with a lot of stakeholders and we didn't come up with anything that we thought was unambiguously better.
I've read through REP-144, and as you say, I think we're very borderline.

@nuclearsandwich -- what's involved in the naming review / what do I need to do to kick that off?

Naming review happens as part of a package's first inclusion in the rosdistro database (this repository) so this release has started the process. As far as what's involved, those of us who are handling incoming rosdistro updates will review the names of new packages to make sure they adhere to REP-144 as part of this review process. Often packages pass without remark and it only comes up when something either violates the conventions or is right on the fence. In this case, I've sought a second opinion and if we're unable to find a consensus we'll pull in more members of the rosdistro maintenance team to confer.

I don't love the current package names, but they're the result of brainstorming with a lot of stakeholders and we didn't come up with anything that we thought was unambiguously better.
I've read through REP-144, and as you say, I think we're very borderline.

The main reason I flagged the names is that without the context of hydrographic, which is part of the repository names but not the package names, I think they are too generic. One alternative would be to name the packages hydrographic_acoustic_msgs and hydrographic_environmental_msgs which would improve their specificity at the cost of extra verbosity.

I agree that this is borderline.  I can buy the package name acoustic_msgs; that is pretty descriptive of what it does.  (though I might suggest acoustic_sensor_msgs, which is a bit more accurate)
But I don't think we should use environmental_msgs here.  Just think about how that package will  turn out in the distribution; it will be ros-noetic-environmental-msgs.  Which environment?  Underwater, in the air, in space, on the ground?  I think this is too generic a name, so we should change it to be more clear that it is for maritime uses, somehow or another.

Thank you for writing your input @clalancette! @lauralindzey what do you think? Do you think we can discuss this in a future maritime meeting or can you discuss with your colleagues?

Thanks for the review @clalancette!
I've pinged Arjo about getting this on the agenda for this month's working group meeting, which will be held on 19 Jan.

This pull request has been mentioned on ROS Discourse. There might be relevant details there:
https://discourse.ros.org/t/january-maritime-wg-meeting/29209/1

I've discussed this with colleagues and a this month's maritime working group meeting.
We've agreed that we want to run with a prefix of "marine_*" for both message packages, with a view towards a future where they may be collected in a meta package marine_msgs.
We are also considering changing environmental_msgs to the more generic marine_sensor_msgs, given feedback from @rolker who is interested in contributing messages from a marine radar, in addition to the various scientific sensor messages that were originally envisioned. @nuclearsandwich @clalancette -- is the more generic name OK, or do y'all encourage more specificity when packaging messages? (The alternative would be marine_environmental_msgs and marine_radar_msgs.)
Once I get the OK that our proposed package names are acceptable, I'll update the repository with the new names.

Maybe:

marine_sensor_msgs/maritime_sensor_msgs  corresponds to sensors related to normal ship operation and navigation(radars, AIS, NMEA 2000, etc.)
oceanographic_sensor_message corresponds to true oceanographic sensors (CTD, O2, Chlorophyll, ORP, etc.)

Where does this discussion leave us on the Acoustic_msgs?   Are we still ok with that?
Where do future messages for Hydrographic Nav Sensors like heave sensors, tide gauges, INS go?    What about sensors that are acoustic and nav sensors like USBL and LBL.   How about sensors that are oceanographic, navigation, and hydrographic like a DVL/USBL?
I think the distinction for marine_sensor_msgs is fairly safe.   However,  the line blurs between oceanographic, environmental, acoustic and hydrographic.   I think we should consider if it is worth creating a distinction at all?   Maybe they all fall under the purview of oceanographic_msgs and we should only have one package?  I'm starting to feel like a simpler package structure would nullify discipline overlap and help reduce future code refactors.
I think we need to step back and ask ourselves what we are trying to distinguish with package names and why.

Where does this discussion leave us on the Acoustic_msgs? Are we still ok with that?

I think acoustic_msgs/* would become marine_acoustic_msgs/*.

Where do future messages for Hydrographic Nav Sensors like heave sensors, tide gauges, INS go? What about sensors that are acoustic and nav sensors like USBL and LBL. How about sensors that are oceanographic, navigation, and hydrographic like a DVL/USBL?
I think the distinction for marine_sensor_msgs is fairly safe. However, the line blurs between oceanographic, environmental, acoustic and hydrographic. I think we should consider if it is worth creating a distinction at all? Maybe they all fall under the purview of oceanographic_msgs and we should only have one package? I'm starting to feel like a simpler package structure would nullify discipline overlap and help reduce future code refactors.
I think we need to step back and ask ourselves what we are trying to distinguish with package names and why.

I think simplifying with exceptions is the way to go. The package name should identify that messages within are marine related so we don't have to name types themselves MarineThis.msg or MarineThat.msg. We could use hydrographic or maritime, but I like marine because it's shorter.
Maybe the default package should simply by marine_msgs or marine_sensor_msgs (to reserve marine_msgs as a meta package).
Reasons for exceptions would be for a collection of message types that might need to be grouped together without adding unnecessary length to the message type names. For example, the  messages type names in acoustic_msgs  would become more cumbersom if we had to rename PingInfo.msg to AcousticPingInfo.msg to distinguish it from a hypotetical RadarPingInfo.msg.
Message types that are more self contained would live the the default marine package.
So for messages that are ready to go:
marine_sensor_msgs/TurbityNTU.msg          // from environmental_msgs/
marine_acoustic_msgs/.msg                        // from acoustic_msgs/.msg
For messages that are currently under development, I have:
marine_sensor_msgs/RadarSector.msg
marine_sensor_msgs/RadarEcho.msg
Potential future messages:
marine_sensor_msgs/CTD.msg
marine_sensor_msgs/O2.msg
marine_sensor_msgs/Chlorophyll.msg
etc...
AIS messages are some I plan to work on soon. I'm not sure if they'll go into a separate package or not.
marine_sensor_msgs/AISPositionReport.msg
marine_sensor_msgs/AISBaseStationReport.msg
marine_sensor_msgs/AISShipData.msg
etc...
or
marine_ais_msgs/PositionReport.msg
marine_ais_msgs/BaseStationReport.msg
marine_ais_msgs/ShipData.msg
etc...

@CaptKrasno -- I like @rolker's reasoning here. (I also kind of see it as a question of namespacing -- once you have enough related messages + ecosystem around them, maybe it should be its own package rather than being thrown into an onmibus. For what we've done so far, I think the acoustic_msgs definitely fit in that category, while all of the simple one-value oceanographic sensors do not.)
So, I'd propose going with:

marine_sensor_msgs for simple sensors (rename of environmental_msgs)
marine_acoustic_msgs for acoustic_msgs  (rename of acoustic_msgs)
TBD for the AIS and radar work Roland is doing -- I'd like more information / a better sense of how much of a message hierarchy and processing ecosystem is likely to build up around each.

I'm also happy to set up another real-time meeting with y'all if you think further discussion is warranted -- just let me know. I'm eager to keep this process moving along =)

@rolker @lauralindzey
I largely like Roland's approach.    I think it's worth a quick chat though just to sync our thoughts (on this and in general) if you guys are up for it.
-Kris

@nuclearsandwich @clalancette -- is the more generic name OK, or do y'all encourage more specificity when packaging messages? (The alternative would be marine_environmental_msgs and marine_radar_msgs.)

There is still ongoing discussion and so I would not consider this a definitive review of any name but I think that marine_sensor_msgs is very much an improvement over environmental_msgs.

Regarding the discussion around simpler package names versus more precise package names: Packages are both the unit of installation/distribution in ROS and the unit of maintenance/administration. So creating packages that are about the size of your administrative unit (team or group for example) is the most straightforward thing to do, rather than trying to create one all-encompassing package that will have varied owners. Of course, having varied contributors is welcome and encouraged. Some care should also be taken that packages are small enough that most users will want nearly everything in the package or none of it so that they are not installing more than they need.

@rolker, @CaptKrasno and I (the main contributors behind these packages) got together today to talk about the need to rename these packages. Our discussion converged, and was in line with what was discussed in the monthly maritime working group, so at this point I think we're ready for naming re-review. @nuclearsandwich @clalancette  -- what are our next steps?
Our proposal:

rename repo itself hydrographic_msgs -> marine_msgs
rename acoustic_msgs -> marine_acoustic_msgs
rename environmental_msgs -> marine_sensor_msgs

A big point of discussion was how to decide which (soon-to-be-added) marine messages belong in which package. The guidelines we came up with are:

The default category is marine_sensor_msgs
Create a new package for:

anything complicated enough to require custom submessages (e.g. existing imaging&profiling sonar messages in marine_acoustic_msgs)
anything with a large number of tightly-related messages. (e.g. when developed, AIS will be its own package)

Our proposal:
* rename repo itself hydrographic_msgs -> marine_msgs

* rename acoustic_msgs -> marine_acoustic_msgs

* rename environmental_msgs -> marine_sensor_msgs

That sounds very reasonable to me.  Your package names (once you release them) will end up being:

ros-noetic-marine-acoustic-msgs
ros-noetic-marine-sensor-msgs

And as far as I'm concerned, that well describes what they are for and should be REP-144 compliant.

@clalancette thank you very much for the quick review! Are we good to go ahead and do the renaming and re-releasing?

Are we good to go ahead and do the renaming and re-releasing?

Yes! Please close this PR when you do the new release and link this discussion in a comment on that PR so that the review team has the full context for the new release.
Thanks for iterating on this with us!

Friendly ping @vatanaksoytezer

I’m the holdup… on vacation now, this is on my list for early March when I
get back.
On Tuesday, February 21, 2023, Michael Carroll @.***>
wrote:

Friendly ping @vatanaksoytezer
https://urldefense.com/v3/__https://github.com/vatanaksoytezer__;!!K-Hz7m0Vt54!gGC5X2cboQjhbnZ4AG0PlgD9wzGM924LYlCKs6A_6lbVqhFiwkPBS-pt0BZjQzdulxxHRsPot9XTWPaOmn9jClE$
—
Reply to this email directly, view it on GitHub
https://urldefense.com/v3/__https://github.com/ros/rosdistro/pull/35488*issuecomment-1438533393__;Iw!!K-Hz7m0Vt54!gGC5X2cboQjhbnZ4AG0PlgD9wzGM924LYlCKs6A_6lbVqhFiwkPBS-pt0BZjQzdulxxHRsPot9XTWPaOtXCIgs8$,
or unsubscribe
https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/APRKPUH2K22HGCXDMTSFCMLWYTCF3ANCNFSM6AAAAAASQAA5AY__;!!K-Hz7m0Vt54!gGC5X2cboQjhbnZ4AG0PlgD9wzGM924LYlCKs6A_6lbVqhFiwkPBS-pt0BZjQzdulxxHRsPot9XTWPaOgAGNje0$
.
You are receiving this because you were mentioned.Message ID:
@.***>

@lauralindzey let's sync when you are back and I am sure we can get this done in no time!

Given that this needs a new PR to move forward, I'm going to close this to get it off of the rosdistro docket.  Do feel free to open a new one when things have been renamed.  Thanks for the understanding and iteration here.

This pull request has been mentioned on ROS Discourse. There might be relevant details there:
https://discourse.ros.org/t/new-ros-enhancement-proposal-for-marine-robotics/36218/6


Fix doc duplication in README and quickstart

Previously we had difficulties with referencing README content from the docs folder. However, that was when we had the additional constraint of integrating sphinx and markdown. Now that we're using mkdocs, this may be easier.
Fix and update in all repos

K. Thx
On Monday, 20 June 2016, Kim (Hamilton) Duffy<EMAIL_ADDRESS>wrote:

Previously we had difficulties with referencing README content from the
docs folder. However, that was when we had the additional constraint of
integrating sphinx and markdown. Now that we're using mkdocs, this may be
easier.
Fix and update in all repos
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/digital-certificates/cert-viewer/issues/26, or mute
the thread
https://github.com/notifications/unsubscribe/ARxeyv1uQKl2N7M1zftOHKC7BYwdn7d8ks5qNvtRgaJpZM4I6Grk
.

--

Dennis Carter-Chand, MBA
Email<EMAIL_ADDRESS>Phone, Text: +1-647-515-7961
LinkedIn: www.linkedin.com/in/dcarterchand

fixed in relevant projects: cert-viewer and cert-issuer


Add htop

Htop is present on most other Scalaway images by default and is very useful to have there.

Thank you :)


ERROR: Undefined variable: "$breakpoints". when setting $beard-enable-responsive to false

I'm trying to  set the $beard-enable-responsive to 'false' but got this error:

[10:59:32] Starting 'sass'...
{ Error: node_modules\beardcss\stylesheets\_helpers.spacing.scss
Error: Undefined variable: "$breakpoints".
        on line 20 of node_modules/beardcss/stylesheets/_helpers.spacing.scss
>>             @each $key, $breakpoint in $breakpoints {

Here's my app.scss
$beard-reset: false;
$beard-base: false;
$beard-enable-responsive: false;

@import '../../../node_modules/beardcss/stylesheets/beard.before';
// Place custom spacing, color, and media query configuration here
@import '../../../node_modules/beardcss/stylesheets/beard.after';

Did I missed something?

Looks like you found a bug. Just pushed a fix, so just update the package and you'll be good to go. Thank you for reporting!

@davidhemphill  - Thanks :) can update it on npm? it's still on v2.2.3

Just saw this. It's published!


Tooltip missing with either "allow popup windows snapping/child windows snapping" on

Microsoft PowerToys version
0.56.1
Running as admin

[X] Yes

Area(s) with issue?
FancyZones
Steps to reproduce
Hover on desktop icon for tooltip or
AutoCad with dynamic mode ON
✔ Expected Behavior
Show tooltip
❌ Actual Behavior
Missing tooltip
Other Software
No response

Most probably this happens because of "allow popup windows snapping" option. Does it happen when this option is off?

tooltip shows up when off, I can confirm.

Can't remember the exact toggle (or maybe renamed after the update), I tried the "Allow child windows snapping" and everything seems alright on 0.76 and 0.76.1

Thank you, it's good to know! We can now close the issue.


Retrieving product options now performs only 1 query.

Also it returns all the product options combined. This makes more sense because
as the existing tests prove, there is allready a way to retrieve the product_class
options and the product options separately.

Looks good - please could you fix the lint errors?

Sorry to be a pain, but can you remove the changes you have committed to package-lock.json? This is not a meaningful change and just seems to happen when different versions of npm are used - we need to look separately into a way of preventing that.


Gitea integration

Hi
It's possible use this with gitea repos?
Best regards

Hi! There are currently no plans to support gitea, but feel free to contribute with a PR :)


fix insert example

Codecov Report

Merging #6605 into master will increase coverage by 0.06%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #6605      +/-   ##
============================================
+ Coverage     82.95%   83.01%   +0.06%
- Complexity    13311    13329      +18
============================================
  Files          1516     1516
  Lines         49572    49572
  Branches       5933     5933
============================================
+ Hits          41124    41154      +30
+ Misses         5627     5597      -30
  Partials       2821     2821

Impacted Files
Coverage Δ
Complexity Δ

.../main/java/io/crate/analyze/AnalyzedStatement.java
0% <0%> (-100%)
0% <0%> (-1%)

...rc/main/java/io/crate/analyze/UnboundAnalyzer.java
76.31% <0%> (-13.16%)
2% <0%> (ø)

...ration/collect/collectors/OrderedDocCollector.java
90% <0%> (-10%)
5% <0%> (-1%)

...ration/reference/doc/lucene/IpColumnReference.java
77.27% <0%> (-9.1%)
4% <0%> (-1%)

...va/io/crate/protocols/postgres/types/JsonType.java
76.66% <0%> (-6.67%)
8% <0%> (-1%)

.../java/io/crate/planner/node/dql/join/JoinType.java
64.7% <0%> (-5.89%)
6% <0%> (ø)

.../collect/collectors/LuceneOrderedDocCollector.java
86.27% <0%> (-5.89%)
15% <0%> (-1%)

...java/io/crate/planner/operators/HashAggregate.java
92.42% <0%> (-3.04%)
15% <0%> (-1%)

...c/main/java/io/crate/metadata/RoutingProvider.java
77.27% <0%> (-2.28%)
22% <0%> (-1%)

...er/src/main/java/io/crate/sql/tree/AstVisitor.java
24.26% <0%> (-2.21%)
33% <0%> (-3%)

... and 27 more

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 98c6081...3b41ca0. Read the comment docs.


provider declared incorrectly - by default

The Authentication section of the README.md file needs to add the redefined datasource structure to be:
datasource db {
  provider = "postgres"
  url      = env("DATABASE_URL")
}

the provider field is by default defined as sqlite. Without this change  both enum declaration and field roles     String[] are marked as invalid.
Note: the actual code is fine - just the documentation needs to be fixed.

added


[DiskRP] Adding swagger spec for 09-30-2018

Latest improvements:
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Contribution checklist:

[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and have all been fixed in this PR.
[ ] The OpenAPI Hub was used for checking validation status and next steps.

ARM API Review Checklist

[ ] Service team MUST add the "WaitForARMFeedback" label if the management plane API changes fall into one of the below categories.
adding/removing APIs.
adding/removing properties.
adding/removing API-version.
adding a new service in Azure.

Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs.

[ ] If you are blocked on ARM review and want to get the PR merged urgently, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.
Please follow the link to find more details on API review process.

Can one of the admins verify this patch?

Automation for azure-sdk-for-ruby

Automation for azure-sdk-for-js

Automation for azure-sdk-for-python

Automation for azure-sdk-for-go

Automation for azure-sdk-for-node

@pollock4595 I don't see this API version being added to the readme.md file, is that intentional?

Automation for azure-sdk-for-java

@pollock4595 I don't see this API version being added to the readme.md file, is that intentional?

@jhendrixMSFT Sorry I had forgotten  to commit that specific file. Adding it now.

@sarangan12 can you please take a look at the linter failure, I believe it's due to the hard-coded version of AutoRest and there's a newer version available so we get the "there's a new version of AutoRest..." spew.

@pollock4595 I checked in a fix for the linter issue, can you please rebase on top of master?

Signing off from ARM side.

@pollock4595 the latest linter failure has also been fixed in master, could you please rebase again?  Sorry for the hassle.

@jhendrixMSFT could the linter issue be a problem on my end since it keeps popping up?
There error is about a file I did not modify though.

@pollock4595 is the new functionality live?

@jhendrixMSFT yep!


Ch maintain 161034240

What does this PR do
Handle code repetitions
Description of task
create a base model to handle common functions
How to manually test this
Clone the repo
git clone  https://github.com/kevinene91/Fast-Food-Fast-API.git
Navigate to the folder
cd Fast-Food-Fast-Api
switch to  this branch
git fetch  origin /bg-fix-validations-161003218
Create virtualenv
virtualenv venv
Activate the enviroment
source venv/bin/activate
install requirements
pip install -r requirements.txt
create databse with postgres
export enviroment variables for database
export SECRET_KEY="your secret key" exportDB_URL="dbname=fastfoodfast user=user password=host=localhost" export TEST_DB_URL="dbname=yourtestb user=user password= host=localhost"
navigate to tests/v2 folder
run python run.py
Test  and /api/v2
on the root folder run python run.py
RelevaI PVT story
[161003218](https://www.pivotaltracker.com/n/projects/2193832/stories/### What does this PR do
Fix validations for inputs
Description of task
validate parse argments fields
How to manually test this
Clone the repo
git clone  https://github.com/kevinene91/Fast-Food-Fast-API.git
Navigate to the folder
cd Fast-Food-Fast-Api
switch to  this branch
git fetch  origin ch-maintain-16103424
Create virtualenv
virtualenv venv
Activate the enviroment
source venv/bin/activate
install requirements
pip install -r requirements.txt
create databse with postgres
export enviroment variables for database
export SECRET_KEY="your secret key" exportDB_URL="dbname=fastfoodfast user=user password=host=localhost" export TEST_DB_URL="dbname=yourtestb user=user password= host=localhost"
navigate to tests/v2 folder
run python run.py
Test  and /api/v2
on the root folder run python run.py
RelevaI PVT story
161034240

Pull Request Test Coverage Report for Build 277

57 of 67 (85.07%)  changed or added relevant lines in 7 files are covered.
2 unchanged lines in 1 file lost coverage.
Overall coverage increased (+0.7%) to 88.437%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

app/api/v2/models/base.py
28
38
73.68%

Files with Coverage Reduction
New Missed Lines
%

app/api/v2/models/orders.py
2
79.31%

Totals

Change from base Build 272:
0.7%

Covered Lines:
956

Relevant Lines:
1081

💛  - Coveralls


remove checkstyle

Description

Remove checkstyle in favor of spotless.
resolve Guava dependency conflicts between com.google.guava:guava:32.0.1-jre and com.google.guava:guava:32.1.2-jre.

Issues Resolved
[List any issues this PR will resolve]
Check List

[ ] New functionality includes testing.

[ ] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Why remove checkstyle ?

@ylwu-amzn I added two points in the description.

While both tools can be part of a quality control pipeline in software development, they serve different purposes. Checkstyle is more about enforcing coding standards and best practices, while Spotless ensures that the code looks consistent without manually formatting it.


How can I get the present price ?

Thank you in advance.
I can know how to use the get_hist_data.
But I don't know how to get the present tick price value.
Can I get the value with this ?

hi Swarms,
seems there's no function can get the present tick value, haha


added instruction in dice game

#286

Please add this in the main readme , in the list of projects section
Also please attach image / video to support your project @harshita-2003

Since this is an enhancement in the existing project , the project is already listed in readme
To support my contribution here is the image of added instruction section


[question] Can I draw texture on BABYLON.Lines2D?

I have a thick line that I want to draw textures on it. Can I do that?
The closest thing I've found so far is using BABYLON.Mesh, which I don't like so much.

Hello please use our forum for questions :)


Block selection not work

In Vim: Ctrl+v

Thanks @movEAX ! I know about this (personally, I use it very often.)
So, there's a good chance I will implement this anytime soon for pyvim as well.

In Vim this also responds to Ctrl+q iirc as this is the mapping on Windows for gVim where compatibility with Ctrl+C/X/V/Z are maintained.


Bridge Parser Diagnostics into the C++ Diagnostic Engine

Add a hook so the Swift parser can emit diagnostics that go through the normal diagnostics engine.

apple/swift-syntax#976
@swift-ci test

@swift-ci smoke test macOS

https://github.com/apple/swift-syntax/pull/976
@swift-ci smoke test macOS

I'll pull the round-trip failures into the hook in a follow-up.


andy.rb: fix to use pkg

Closes https://github.com/caskroom/homebrew-cask/issues/12847.

Merged as 04ba84e9a8096255648bef354ac35f89a9c294d6.


[Question] Is it possible to do "in-context-learning" on LLaVA?

Question
Dear authors, LLaVA is an amazing model.
I was wondering can it do "in-context-learning". So that I can ask questions and get responses following a specific and rigorous format.
For instance, if I ask "how many water melons are in the image? Please respond only with the number. " I do expect a single  number as response, instead of receiving a lot of words.
Best,
Jiaying

Hello, I have the same question. Have you tried it yet?

Hello, I have the same question. Have you tried it yet?

Seems not capable of doing "In-contenxt learning" because LLaVA did not train for that. I do find another model has this ability, check https://github.com/Luodian/Otter

Hello, I have the same question. Have you tried it yet?

Seems not capable of doing "In-contenxt learning" because LLaVA did not train for that. I do find another model has this ability, check out -> https://github.com/Luodian/Otter

ok, Thanks!


Context Options

Pipeline for passing options into a rendering context.

@redwoodfavorite can you update this to work with the COmmands scheme?

Closing in favor of more explicit options vs using the command buffer.


prompty: Superfluous f-string templating causes prompt templaing to fail

Checked other resources

[X] I added a very descriptive title to this issue.
[X] I searched the LangChain documentation with the integrated search.
[X] I used the GitHub search to find a similar question and didn't find it.
[X] I am sure that this is a bug in LangChain rather than my code.
[X] The bug is not resolved by updating to the latest stable version of LangChain (or the specific integration package).

Example Code
Use a barebone .prompty file such as:
---
name: IssuePrompt
description: A prompt used to infer the intent of a user's query
model:
  api: chat
---

user:
Tell me about {templating issues}.

And the following script in the same folder:
from langchain_prompty import create_chat_prompt
from pathlib import Path

root_path = Path(__file__).parent
prompt_path = root_path / "issue.prompty"

templated_prompt = create_chat_prompt(prompt_path)
templated_prompt.invoke(inputs={})

Error Message and Stack Trace (if applicable)
Traceback (most recent call last):
  File "issue.py", line 8, in <module>
    templated_prompt.invoke({})
  File ".venv\Lib\site-packages\langchain_core\runnables\base.py", line 4475, in invoke
    return self._call_with_config(
           ^^^^^^^^^^^^^^^^^^^^^^^
  File ".venv\Lib\site-packages\langchain_core\runnables\base.py", line 1785, in _call_with_config
    context.run(
  File ".venv\Lib\site-packages\langchain_core\runnables\config.py", line 397, in call_func_with_variable_args
    return func(input, **kwargs)  # type: ignore[call-arg]
           ^^^^^^^^^^^^^^^^^^^^^
  File ".venv\Lib\site-packages\langchain_core\runnables\base.py", line 4341, in _invoke
    output = output.invoke(
             ^^^^^^^^^^^^^^
  File ".venv\Lib\site-packages\langchain_core\prompts\base.py", line 179, in invoke
    return self._call_with_config(
           ^^^^^^^^^^^^^^^^^^^^^^^
  File ".venv\Lib\site-packages\langchain_core\runnables\base.py", line 1785, in _call_with_config
    context.run(
  File ".venv\Lib\site-packages\langchain_core\runnables\config.py", line 397, in call_func_with_variable_args
    return func(input, **kwargs)  # type: ignore[call-arg]
           ^^^^^^^^^^^^^^^^^^^^^
  File ".venv\Lib\site-packages\langchain_core\prompts\base.py", line 153, in _format_prompt_with_error_handling
    _inner_input = self._validate_input(inner_input)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File ".venv\Lib\site-packages\langchain_core\prompts\base.py", line 145, in _validate_input
    raise KeyError(
KeyError: "Input to ChatPromptTemplate is missing variables {'templating issues'}.  Expected: ['templating issues'] Received: []"

Description
Hello everyone! Thank you for your work.
I am playing around with langchain_prompty and noticed that messages are rendered two times, once by Prompty using Mustache, and once by langchain by treating messages as f-strings.
So you have to process all inputs to your prompts to escape brakcets for them to be ignored by the f-string templating (so {{ }}instead of { }, which could cause issues with Mustache if the content is a key in your inputs). This is a bit hacky and brittle. Would there be a way to avoid this sedonc templating? Below is a detailled explanation of how the templating(s) happens.
langchain_prompty uses Mustache templates, as discussed in this PR introducing the package.
This templating happens like this:

Prompt creation using the prompty file (call to langchain_prompty.create_chat_prompt())

Which leads to the processing of the prompty file

Which triggers the Mustache templating

After this initial templating, the messages are processed by Langchain, which by default treats them as f-strings templates (see source code). Hence the issue.
Tagging you @wayliums as I saw you worked on the prompty integration into langchain.
Thanks!
System Info
Happens on all systems and configurations.

@matthieucx I have created a PR which handles the issue that you are fixing.

@keenborder786 Thanks for taking so time to work on this.
I think here the issue lies in the double templating, which will always lead to issues because it's super hacky to process your inputs expecting it to be interpreted as a template when it does not need to be.
I think we would need to either remove the Prompty templating, or find another way to create the prompt for LangChain
 (so the call you modified), that templates the messages a second time.
I'll look into it


[Usage] using FSDP leads to libtorch_cuda_cpp.so not found

When did you clone our code?
I cloned the code base after 5/1/23
Describe the issue
Issue:
By following the docs here https://github.com/haotian-liu/LLaVA/tree/main#experimental-use-fsdp-to-save-memory-in-pretraining
I create an new environment, and run torchrun to do the second step to finetune the model. But I found this error:
Command:
from flash_attn.flash_attn_interface import flash_attn_unpadded_qkvpacked_func
# throw error
import flash_attn_cuda
ImportError: libtorch_cuda_cpp.so: cannot open shared object file: No such file or directory

Please kindly advise

Fixed, should check server's cuda version. Make sure the cuda version match with pytorch


Adding RPC macros for handy, dandy calling automation

Codecov Report
Base: 84.79% // Head: 84.11% // Decreases project coverage by -0.69% :warning:

Coverage data is based on head (57cdd80) compared to base (67ac50c).
Patch coverage: 53.57% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #28      +/-   ##
==========================================
- Coverage   84.79%   84.11%   -0.69%
==========================================
  Files          23       23
  Lines        2217     2260      +43
==========================================
+ Hits         1880     1901      +21
- Misses        337      359      +22

Impacted Files
Coverage Δ

ractor/src/lib.rs
3.70% <0.00%> (-96.30%)
:arrow_down:

ractor/src/actor/tests/mod.rs
94.73% <100.00%> (-0.14%)
:arrow_down:

ractor/src/rpc/tests.rs
97.25% <100.00%> (+0.35%)
:arrow_up:

ractor/src/rpc/mod.rs
68.54% <0.00%> (+3.22%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Please invite me to the GitHub Community Organization

Please invite me to the GitHub Community Organisation.

Name: Manish Samota

Discord Username(if exists): Manish Samota#0849

Additional Context: Eddie Jaoude really doing great work I think to join this community I can grow my knowledge and can share my knowledge with others.  I can contribute to building some awesome projects that can make other's life easy.

:nerd_face:

Invitation sent for the GitHub Organisation. Welcome to the community 🎉
Don't forget after accepting to make it public so it appears on your GitHub profile for everyone else to see, you can do this by finding your name in the GitHub organisation list and change the dropdown to public https://github.com/orgs/EddieJaoudeCommunity/people
Tips for practising:
Customise your GitHub profile, here is a live stream on it https://www.youtube.com/watch?v=cT6GXCuS0Zo
Practice repo, instructions on how to add your name to the README in the README https://github.com/EddieJaoudeCommunity/hacktoberfest-practice
Remember contributing to open source is not just about code, its about collaboration, communication and adding value
I hope that helps

Invitation sent for the GitHub Organisation. Welcome to the community 🎉
Don't forget after accepting to make it public so it appears on your GitHub profile for everyone else to see, you can do this by finding your name in the GitHub organisation list and change the dropdown to public https://github.com/orgs/EddieJaoudeCommunity/people
Tips for practising:
Customise your GitHub profile, here is a live stream on it https://www.youtube.com/watch?v=cT6GXCuS0Zo
Practice repo, instructions on how to add your name to the README in the README https://github.com/EddieJaoudeCommunity/hacktoberfest-practice
Remember contributing to open source is not just about code, its about collaboration, communication and adding value
I hope that helps


Dont trigger dry run on PRs automatically

What has been done

Eradicated dry-run action configuration. Triggering action in dry-run mode for PR builds makes not much sense since main action purpose is to be triggered via PR comments. Having no comment object present in GitHub payload in action workflow build makes it impossible to perform full integration test on each PR. Instead, to test the action comment with dry-run parameter should be left on PR.

See https://github.com/vgaidarji/github-actions-pr-merger/pull/20 for more context.
How to test
No easy way to test atm.
When /robin merge --dry-run command support is added, trigger a build using via that command which will execute .github/test-action-on-pr-comment.yml workflow for comment left on PR.

Merge PR to master so that .github/test-action-on-pr-comment.yml workflow changes take effect.
Open another PR for any future changes and leave a comment on PR with /robin merge --dry-run
Verify action test-action-on-pr-comment.yml workflow is triggered and dry run merge operation result is posted to PR

/robin merge --dry-run

/Robin merge --dry-run


Building pre-compiled gem

Hi,
I'm trying to include rest-client in an extension for Sketchup. Since they're using their own interpreter, native libraries usually can't be used, since they don't include dev-tools. Other libraries sometimes are offering pre-compiled gems that can be used in this situation.
I tried using gem-compile, but according to them, There are no extensions to build on this gem file... Any idea?

I'm not familiar with gem-compile, but rest-client does not itself include any C extensions or native libraries.
Maybe you're looking to compile the C extensions of the dependencies? There is a dependency unf_ext that has C extensions.
Relevant dependency tree showing versions as of today:
rest-client (1.8.0)
  http-cookie (1.0.2)
    domain_name (0.5.20160310)
      unf (0.1.4)
        unf_ext (<IP_ADDRESS>)


Campus Digital FP

Campus Digital FP

@DanMarBar First stage of verification passed, official domain for Campus Digital FP is campusdigitalfp.com as far as I verified. This is just an informational note. Pull request is still in the review. I appreciate your patience while waiting for the final decision.

Ok, thank you for your patience and trust!

@DanMarBar Thank you for your patience while waiting for a review and processing your request. Pull request merged. Please start applying for JetBrains educational subscription at https://www.jetbrains.com/shop/eform/students in an hour, to allow the changes to propagate through JetBrains systems.


(1.19.4 FORGE) - Ver. 1.2.3 Crashes Xaero's Worldmap

Crash at startup. Reverting to ver. 1.2.0 works normally.
(Forge Only - Fabric ver. 1.2.3 doesn't crash)
Uncrafting Table Crash.txt

There was an error in the build classes, so I deleted the entire build directory and rebuilt.


Berlin source is broken

Current source is not functioning, and has not been since December '18

Looks like the _ Berlin Hauskoordinaten _ layer is no longer present at https://services.arcgis.com/OLiydejKCZTGhvWg/arcgis/rest/services/
Anyone speak German who might be able to identify a replacement layer from that list?

I did a quick check and there appears to be two main sources for Berlin data:

The sources described at https://daten.berlin.de/tags/adressen-berlin (though they all link to fbinter.stadt-berlin.de, which appears to be down)
The previous CSV dumps during 2014-2016 (https://daten.berlin.de/search/node/RBS-Adressen), though I would not know if they are better than what we already have


background image - not centered

It's a great plugin, But the document about background image is not clear, also, have no option to set background image as center, fixed, repeat or no-repeat.

If the element has the data attribute data-layzr-bg, then the image will be loaded as a background image.  This attribute can be customized per the options object passed to your instance.
Layzr only sets the background-image property - use the other background properties to set the other values.
Any other questions, just ask.

Yup! Got it to work! Thanks for the conformation though.. thought I m missing something! :+1: for the plugin


Sphinx 3 add_stylesheet deprecation warning

Hi, sphinx 3 issues a deprecation function as follows:
~myenv/lib/python3.8/site-packages/sphinx_nbexamples/__init__.py:1165: RemovedInSphinx40Warning: The app.add_stylesheet() is deprecated. Please use app.add_css_file() instead.
  app.add_stylesheet('example_gallery_styles.css')

The relevant parts of my environment :
python==3.8.1
sphinx==3.0.0
sphinx-nbexamples==0.4.0

Hi @Ohjeah! Thanks for the input! Yes, I got lazy with continuous sphinx testing :sweat_smile:. I made a PR #15 to handle this issue and will work on it.


Removed Syntactic Feature (-i flag for in-place file editing)

While digging into Perl6, I try to focus on users - those who use Perl 5 for some reason meanwhile, and how to catch them.
I found Perl Is Still The Goddess For Text Manipulation nowadays and walk over it. Unfortunately, -i has been removed (see https://github.com/perl6/specs/blob/master/S19-commandline.pod), because:
  -i *extension*
   Modify files in-place. Haven't thought about it enough to add yet, but I'm certain it has a strong following. {{TODO review decision here}}

When Perl 6 is still a Perl, this is a mandatory feature.

It is a frequently requested feature. I don't think there's any reason not to have, so somebody just needs to implement it.

@lizmat suggested some kind of Hackathon - but we might need topics ;)
This could be one of it...

Squashathon is currently in progress (21 hours left), any contributions to rakudo count, one winner gets a plush camelia :)
Just submit a PR with the thing. However, last time I looked at it, in-place editing turned out to be a bit harder to implement than it seems.

If we want this, I guess we need to implement this in Perl 6 logic, possibly in module space.  If that works, we can hook it into the default parameter parsing if we think that is still a good idea.

I'm fine with -i being implemented and added to Rakudo; it should probably be spec'd (that is, spectests) also, as I believe other options like -n are.

Then I suspect this is best implemented as a Perl 6 class taking the necessary parameters and producing the right output, and then hooking that into the parameter parsing logic?


feature:  Workload personalization per WEC

Feature Description
In some cases when a workload is deployed to multiple WECs users may want to personalized the workload parameters for specific WEC(s)
Current state description and problems involved
In general a user can achieve the above by:

Create a different workload object for each WEC
Create a binding policy that will send the workload to a specific WEC

While this may be good for some cases this is not a practical solution for several reason:

If we want to personalize cluster scope resources we need to use different WDS for each instance
Scalability issues: we basically duplicate the object on the WDS(s) which become impractical for large number of WECs
Manageability:  The user need to manage all those copies + the different binding policies.

Proposed approach
Assumptions

For phase 1, we will be focusing on Hub based customization
For phase 1 we will start with simple parameter substitution

Description
The user will specify a template with placeholders for fields that need to be personalized.  Once the target WEC is known KS will populate the placeholders with the WEC specific values.
Additional requirements

Some common fields should be pre-defined by KS (e.g., "wec-name" )
The should be able to add workload specific fields  (e.g., "debug-level")
Simple solution - if possible use existing mechanism or know syntax (e.g., Go templating)
Very simple UX - user should easily define new fields and/or use existing pre-defined system fields.

@ezrasilvera so the idea is to use something like go templating with variables expressed as "{{varName}}" in the yaml, right ? What is your thinking on how the per-WEC values of these variables would be defined ?

@ezrasilvera so the idea is to use something like go templating with variables expressed as "{{varName}}" in the yaml, right ? What is your thinking on how the per-WEC values of these variables would be defined ?

Yes.
Personally I think we will probably use configmaps to hold those values.  Some will be populated automatically by KS from values in the managedCluster object, but we probably should allow the user to define his own. I think there can be several other alternatives  (KS will search the values in a chain of places 1. user CM in the WDS 2.  global CM created by KS 3. managedCluster  special labels ....
But this is just initial thinking we should first:

Agree on the requirements
Brainstorm directions (starting with what Mike already proposed)
Who ever own it need to come up with design doc that can be reviewed (addressing questions like you asked)
Implementation - PR
We can probably accomplish all of it in 1-2 weeks (depending on speed of agreements :-) ) , I assume design + implementation is 1W and reviews is another week

On the how the customization object or sub-object should be defined, and on the UX, I think the following should be considered:
With agreement to Ezra's additional requirements that involve supporting system provided dynamically evaluated keys, and user provided key-value pairs:

At medium to high scale, it makes more sense to customize workloads for groups of clusters

This means customization object should specify cluster selectors (scalable UX)

It would still be relevant to target single clusters, but probably not a large amount of clusters customized individually with user-provided key-value pairs

There are two main POVs to this matter:

Customization can be viewed as a set of “personalization rules” that set values per WECs, and user workloads can make use of these values (somewhat of a ConfigMap with cluster selectors style)

Knowledge flow: rules are defined -> user is aware of rules -> user utilizes rules
Limitations:

Having to bind workloads to clusters correctly adds fragility
Conflicts on WEC rules level

Customization is related to both the workload and the target WECs (somewhat of a BindingPolicy with key-value pairs style)

Knowledge flow: rules are defined alongside the workload (perhaps indirectly)
Limitations:

Conflicts are now on a higher dimension

few points I would like to add on this topic:

Instead of inventing our own syntax are implementing templates from scratch, use GoLang templates, which is widely used in CNCF and k8s eco system.
The key value pairs are configuration values. Instead of putting labels and annotations on ManagedCluster objects, use ConfigMap per WEC in its dedicated namespace on ITS.

There are many advantages in using GoLang templates:
Standardization
GoLang templates are widely used in CNCF projects and k8s eco system. Few examples:

Helm, Kustomize and KubeBuilder use it extensively to generate k8s resources based on user-defined templates and values.
Prometheus Operator uses it for generation Prometheus and Grafana configuration files based on custom configurations.
Istio uses it for generation configuration files such as virtual services, gateways, and destination rlules based on user-defined configurations.
Argo CD uses it to generate k8s manifests from declarative yaml files stored in Git repos.

Security
Provides a built-in mechanisms to prevent common security vulnerabilities such as injection attacks. it automatically escapes output to prevent injections making KS more secure.
Performance
it's optimized for performance and efficiency. it's been tested and optimized by Go team and the community, ensuring it performs well even with large and complex templates.
Overall, using GoLang templates provides a reliable, secure and efficient way to implement templating for YAML files, saving development time and effort while ensuring the quality and maintainability of KS.

I would prefer that we keep the name 'customization' for this feature and change the name of this issue accordingly.

I would prefer that we keep the name 'customization' for this feature and change the name of this issue accordingly.

done

Yes, it is easy for our code to invoke the Go text template expander. I am more concerned about the user experience.
In the legacy work I deliberately chose syntax that is different from what is used in bash and in Helm charts so that users do not have to use escaping when using bash and/or Helm to get workload objects into a WDS. Yes, escaping can be done, but it is a burden on users to have to remember it and do it. It is tolerable when it is rare. I expect that using Helm, in particular, may be common. I expect that KubeStellar will be just a cog in a bigger machine, so the story of escaping does not end here.
The go template expander can not possibly be as efficient and secure as a simple parameter replacement mechanism.

For an example of what the go template expander does when there is a reference to an undefined parameter, see https://go.dev/play/p/c6KI_I4bbOx

For an example of what the go template expander does when there is a reference to an undefined parameter, see https://go.dev/play/p/c6KI_I4bbOx

maybe I missed the point, this example looks very good to me.
if a user tries to use parameter that was not defined, he is getting an appropriate error.
sounds to me like the normal behavior and exactly what I would expect.
btw, the fact that some parameter wasn't defined for WEC1 doesn't mean it wasn't defined for WEC2. you're making over assumptions.
I'm also failing to see how is it simpler to request from users to learn a new syntax instead of using standards.
from reading the comments of the others, I'm not sure anyone else thinks implementing our own syntax is simpler.

an example of how Karmada uses overridepolicy as a post-manifest (late-binding) mechanism

The override policy is a different way to "customize", not based on templating - almost like kustomize vs. helm.
Seems like it is possible to do things like override or even remove labels and annotations as well. This would be actually another feature we may need along the way for use cases like integration with Argo Workflows / Kubeflow Pipelines V2 / Kueue, where there is no templating (objects are created by KFP for example) but there is a need to change spec fields (e.g. .spec.suspend from false to true) and remove labels (e.g. workflows.argoproj.io/phase ). I am still exploring these integrations, but so far this override policy approach seems would work nicely for those use cases (templating would not).

I think these capabilities are complementary.
one can use templates while other may use something similar to override policy

@nirrozenbaum : exactly, that is the approach we took in the legacy KubeStellar.

I think these capabilities are complementary. one can use templates while other may use something similar to override policy

Got to leave something for phase 2.

Regarding the error that comes out in xxx: it has a lot of content that is noise in our use case. The string returned by Error() of that error is "template: yaml:5:11: executing "yaml" at <.Foobar>: can't evaluate field Foobar in type main.customizationConfig". Remember that in our case we are talking about applying substring replacement to each leaf string independently. In that error message, the parts template: yaml:5, executing "yaml" at, and in type main.customizationConfig are not helpful. And the part can't evaluate field Foobar is not the wording I would choose. We would want wording in terms of our own interface and abstractions, something like no value provided for parameter "Foobar".

In my opinion, the above doesn't justify implementing capabilities we can get for free using go templates.
you can always put in the error field of an object any text you define.
the discussion here is more conceptually -
There is a standard for doing something. CNCF projects are using this standard and we're also part of CNCF.
Now the question is -
should we be aligned with the standard other CNCF projects are using or invent something of our own?
for me the answer is simple - definitely to be aligned with standards and with CNCF projects.
for me it's the same question as asking if we want to implement KS controllers in Go or in python.
I don't see the benefit from inventing something of our own.
IMO, the fact you would choose different wording for returned errors is not a good enough reason not to use the standard, nor the need to escape characters.
I haven't seen anything that we want to do and cannot be done using the standard.

@MikeSpreitzer @nirrozenbaum another aspect is future extendibility. If I understood correctly @MikeSpreitzer main point is that for our current limited usage developing our own expansion may be simpler, more efficient, and more secure. Putting aside the question whether those statements are correct or not, I'm wondering whether this will limit us if/when we do want to add more capabilities and enrich the possibilities for user inputs in the future.
My concern is that we may eventually find ourselves developing a full blown go templating as more requirements are coming in.

you put aside the question about the statements, but I actually think these are also important.
go templates is developed by Go community in golang repo -  a repo with more than 2K contributors and almost 120K stars.
if you google it quickly you will find that go templates was designed and optimized for efficiency and security.
trying to develop templates of our own cannot compete with what Go templates supplies - there is a very big community behind it, which helps optimizing design, performance and security.
and that is even before talking about the flexibility it allows if we want to extend the customization capabilities in the future.

If you google modern lisp implementations you will also find that they are designed and optimized for efficiency. And yet they are still far from the efficiency of C.
The Linux kernel is also an open source project with many contributors. It is designed for security. And yet...
The opening comment of this issue asserts that we will do substring replacement. Go templating is much more than that.
A feature and syntax that is deliberately limited to substring replacement is just what you want if you want to leave room for something more general later.

I think that overall we need to keep three degrees of customization in mind:

simple substring replacements
a collection of replace-this-with-that statements
Playing nice with other ecosystem players that do general templating (e.g., Helm charts, kustomize)

Customization should be late binding (after manifest work is created) to allow for environment-specific assignment of values, integrations with something like zookeeper and other k/v config stores (tikv), and allow for future service discovery whereby deployments can interact with each other without needing to call home to KS for configuration.

@clubanderson : each ManifestWork is destined to one specific WEC, so I do not see why customization has to be done after the ManifestWork is created.
I do see that doing customization in the WEC is an idea that KubeStellar must support. I do not see that KubeSteller must require all the customization to be done in the WEC.

My point about three degrees of customization is on this point.  Since there are already other tools in the ecosystem that do these, my inclination is to lean on them. What they are missing is the 1:many distribution between clusters. For users that can get all their needs met by some other tool(s) doing customization post-distribution in the WEC, nothing is needed from KubeStellar. But I do not think this covers every user's needs. For these users we need KubeStellar to do rule-based customization as an integral part of its 1:many distribution.

@MikeSpreitzer please study karmada

@clubanderson : I saw your example in https://github.com/kubestellar/kubestellar/issues/1897#issuecomment-1997806942 . In that example the customization is not parameterized; each replacement is a string literal.

@clubanderson, regarding the idea that customization should be after manifest work is created. As shown in https://karmada.io/docs/core-concepts/concepts/ and explained in https://karmada.io/docs/core-concepts/architecture , Karmada produces its work objects in two steps: the first step creates a ResourceBinding object per (workload object, destination) and the second step applies the relevant overrides to each ResourceBinding to create a work object per (workload object, destination). So in fact, Karmada is doing its customization prior to the existence of its work object. I think this is not the only possible choice, but it is the choice that Karmada makes.

@clubanderson, regarding service discovery in Karmada. I suppose you are referring to what is described at https://karmada.io/docs/userguide/service/multi-cluster-service . I do not suppose you mean that very directly, it is specifically about Service objects. I suppose you are suggesting that somehow information about each WEC might propagate from that WEC to the core, to be used in customization. I think that is something that makes sense to include as a possible source of parameter values. This also raises the question of why customization using those parameters would be done in the core rather than in the WEC. There are possible answers, such as the user wants to be able to write one layer of customization that takes input from both core and WEC rather than write two distinct and non-interacting layers of customization.

FYI, I have drafted a change to #1760 to make it use golang text/template instead of parameter expansion. It is the last commit in branch https://github.com/MikeSpreitzer/kcp-edge-mc/tree/templatize

In a parameter based paradigm, we can easily allow any Kubernetes label or annotation name as a valid parameter name.


Add remote reference resolving

SwaggerParser is the right place for having resolution of remote references.  It should not be the default, though, but there should be an option to "ResolveFully" when parsing a spec.  In addition, there should be strategies for passing authentication information so the remote references can be read.
The authentication strategy will need some thought, and probably configured by hostname.

in v1.0.1


fix duplicate route names with prefix_and_default strategy

fix duplicate route names with prefix_and_default strategy

Closing in favor of https://github.com/nuxt-community/nuxt-i18n/pull/230


Gradient.remove_point does not allow fewer than two points.

Godot version: 3.2.stable.official
Issue description: Gradient.remove_point explicitly disallows removing points when there are already <= 2 points. However, the editor itself does allow having fewer than two points in a Gradient, and having only one point does indeed seem to work.
IMO it makes sense to disallow removing all points, but I do think allowing a single point should be acceptable. In my case, I'm passing an array of one or more Colors to use for the given GradientTexture. As a workaround, I'm currently setting gradient.colors and gradient.offsets directly:
var color_count := colors.size()

if color_count == 1 && gradient.get_point_count() != 1:
	gradient.colors = PoolColorArray(colors)
	gradient.offsets = PoolRealArray()
	gradient.offsets.append(0)
else:
	for i in range(color_count, gradient.get_point_count()):
		gradient.remove_point(i)

Steps to reproduce:

Create a Gradient (by default it has only two points)
Create a script that calls Gradient.remove_point
Observe the error: remove_point: Condition "points.size() <= 2" is true.

Minimal reproduction project:
Link to relevant source code here: https://github.com/godotengine/godot/blob/0edcb8ed58be8bf6a5145ceaae5ff96778afb2a2/scene/resources/gradient.cpp#L134

Fixed by #35924.


Better user interface

it's necessary  create a new user interface. I thought about using a better language for the UI and keeping python as the backend.

Can you assign it to me?


Zombies ignore raiders, raiders don't ignore zombies.

Bit of an oddity with setting Zombies to only rage against colonists: Raiders will attack them, often ignoring colonists.  Zombies will continue ignoring raiders (while getting killed), until the raiders finally give up and leave.
Not sure if this is as intended, but it seems weird to me.
Possible solutions:

Make non-player factions friendly with the zombiefaction. Zombies and raiders will now ignore mutually ignore each other, much like Traders and Tribals.
Make zombies always fight back when engaged in melee.
Some other clever Brrainz solution.
Leave as is.

This is rather tricky. I discussed this on discord and it seems that there is no easy solution to this problem.

Isn't there a setting of that in the Zombieland settings? Like "All Creatures, Human-Like Creatures and Colonists"?

Maybe I misunderstand this request, Mehni. Do you want raiders to ignore zombies if zombies are set to only attack colonists? That specific case is possible to patch. I think I could add a checkbox to the setting that, if you choose "only colonists" you can choose "raiders attack zombies anyway". I think that having such an option is favourable since I think some players like the way it works right now.

Do you want raiders to ignore zombies if zombies are set to only attack colonists?

Yes, precisely. Raiders shouldn't attack zombies if zombies don't attack them: 1-way-hostilities in RimWorld are rare.
My expectations of Hostile To All Human-Likes and Hostile To Colonists only:
If I select Zombies to be hostile to all humans, I am mostly stuck in my base, I have to be self-sufficient.  That's awesome if you want a game that heavily focuses on Zombies.
If I select Zombies to be hostile to my colonists only, I expect a more or less normal game of RimWorld, with the normal raids and traders being able to move freely (zombie inoculation? idunno) and on top of that the constant threat from Zombies.

I think that having such an option is favourable since I think some players like the way it works right now.

You're the best.


Add compact mode setting

Users can select between two design modes:

Comfortable
Compact (implemented with #1559 and #1557

This may be significant work. I will investigate how we can change the layout at runtime the easiest.

This is essentially implemented. Waiting for #1570 to add proper setting (currently makeshift checkbox on main form, see branch win-compact-mode).


hljs.highlight is not a function

I got this error (hljs.highlight is not a function) and it turned out to be because highlight.js revved to 10.1.1, and somewhere along the line it's now incompatible with vue-highlight.js
Workaround is to set the highlight.js version to ^9.11.0 in package.json.
Might want to revisit the decision not to Move highlight.js from peerDependencies into dependencies

I had a similar error message:
registerLanguage is not a function

Downgrading highlight.js to ^9.11.0 fixed that.
Thanks for the pointer!

highlightjs support Vue officially now.
import hljs from "highlight.js"
import "highlight.js/styles/github.css"
Vue.use(hljs.vuePlugin);

<highlightjs language='javascript' code="var x = 5;" />

Version 4 was released.
You can try it via npm install vue-highlight.js@next.

Version 4 was released.
You can try it via npm install vue-highlight.js@next.


Refactor build process

This pull request merges in changes that will add a build script that will:

get development dependencies from npm
get runtime dependencies from bower
static code analysis (lint-like analysis by jshint)
cats all files together into chaise.js
compiles and minifies all source files into chaise.min.js
able to now write tests in mocha+chai specs
generates api documentation in markdown

Minified js code is harder to debug and troubleshoot because of all of the symbol replacement.  While this code is being actively developed, I would recommend the default build target NOT minify (or concatenate) by default, and there be a explicit "release" target (or somesuch) that minifies for public or release deployments.

@mikedarcy I agree we should tread lightly on using the minified and maybe even the concatenated code in most deployments for the time being until things are more stabilized. I do think its important to start including it in the build process and testing against them. I like the suggestion of having a release target specifically for producing those artifacts.


Can not use double quote in table name

As I know, double quote in table name is SQL92 standard, why I got an error from CovenantSQL?

SQLite exported SQL has " with the table name


v1 spec: fix typos and formatting

https://github.com/TomasTomecek/docker/blob/fix-v1-spec-typos/image/spec/v1.md

ping @jlhawn @steeve @dmcgowan

LGTM
thanks @TomasTomecek

LGTM

That was quick! Thanks for such a fast response.


Bug: Reduce still assuming >= inequalities

The reduce method is still considereing greater equal inequalities based on everest. We have to change it to <= for BoFire.
Just as notice for @DavidWalz @jkleinekorte @bertiqwerty

Fixed!


Daffodil 2663 pluggable charsets

This now includes commits that are not really part of this change set, but they are showing up as commits in this review.
That and... github UI is having trouble. I can't seem to narrow the review to just the last 3 commits. It doesn't seem to allow me to select that. (I can select 2 commits, but not 3)
The exact best way to fix this isn't clear. I think the first 2 and last 5 commits should be in this change set, the other commits shouldn't be part of this.

Note to other reviewers - this got fixed - it's now just the right set of commits.

yeah I will get rid of those extra commits


Bump to 1.0

For the new gulp release, I'm trying to get all dependencies to bump to version 1.0
After #10 is resolved or found to be invalid, can you bump to 1.0?

@phated published v1.0 to npm just now


Tag Master for Laravel 6 Support

Hi,
Would it be possible if you could tag master so we don't have to use dev-master when upgrading to Laravel 6 please.
Thanks,
Rich

I think the issue with monolog 2 needs to be resolved?

Tagged 2.6.4


Return after a for in a try on Windows incorrectly marked as missing

If you have a return after a for in a try block, the return is incorrectly said to not be hit.
This is effecting my Windows, however it does not seem to effect Linux installs.
Below is an MVCE of the commands and file to setup the environment to reproduce this.
               $ mkdir example
               $ cd example
       example $ python -m virtualenv venv
       example $ & ./venv/Scripts/activate
(venv) example $ pip install pytest coverage>5.0.0
Successfully installed atomicwrites-1.3.0 attrs-19.3.0 colorama-0.4.3 coverage-5.0.4 more-itertools-8.2.0 packaging-20.3 pluggy-0.13.1 py-1.8.1 pyparsing-2.4.6 pytest-5.4.1 six-1.14.0 wcwidth-0.1.8
(venv) example $ vim test_example.py
(venv) example $ coverage run --omit venv/* -m pytest
================================================= test session starts =================================================
platform win32 -- Python 3.8.0, pytest-5.4.1, py-1.8.1, pluggy-0.13.1
rootdir: example
collected 1 item

test_example.py .                                                                                [100%]

================================================== 1 passed in 0.04s ==================================================
(venv) example $ coverage report -m
Name              Stmts   Miss  Cover   Missing
-----------------------------------------------
test_example.py      10      1    90%   5

test_example.py
def fn(values):
    try:
        for _ in values:
            raise KeyboardInterrupt()
        return 0
    except KeyboardInterrupt:
        return 130

def test_fn():
    assert fn([]) == 0
    assert fn([...]) == 130

System information
(venv) example> python -V
Python 3.8.0
(venv) example> coverage debug sys
-- sys -------------------------------------------------------
                        version: 5.0.4
                       coverage: example\venv\lib\site-packages\coverage\__init__.py
                         tracer: -none-
                        CTracer: available
           plugins.file_tracers: -none-
            plugins.configurers: -none-
      plugins.context_switchers: -none-
              configs_attempted: .coveragerc
                                 setup.cfg
                                 tox.ini
                                 pyproject.toml
                   configs_read: -none-
                    config_file: None
                config_contents: -none-
                      data_file: -none-
                         python: 3.8.0 (tags/v3.8.0:fa919fd, Oct 14 2019, 19:37:50) [MSC v.1916 64 bit (AMD64)]
                       platform: Windows-10-10.0.18362-SP0
                 implementation: CPython
                     executable: example\venv\scripts\python.exe
                   def_encoding: utf-8
                    fs_encoding: utf-8
                            pid: 195048
                            cwd: example
                           path: example\venv\Scripts\coverage.exe
                                 example\venv\scripts\python38.zip
                                 C:\Program Files\Python\3.8.0\DLLs
                                 C:\Program Files\Python\3.8.0\lib
                                 C:\Program Files\Python\3.8.0
                                 example\venv
                                 example\venv\lib\site-packages
                    environment: -none-
                   command_line: example\venv\Scripts\coverage debug sys
                sqlite3_version: 2.6.0
         sqlite3_sqlite_version: 3.28.0
             sqlite3_temp_store: 0
        sqlite3_compile_options: COMPILER=msvc-1916
                                 ENABLE_FTS4
                                 ENABLE_FTS5
                                 THREADSAFE=1
(venv) example> pip freeze
atomicwrites==1.3.0
attrs==19.3.0
colorama==0.4.3
coverage==5.0.4
more-itertools==8.2.0
packaging==20.3
pluggy==0.13.1
py==1.8.1
pyparsing==2.4.6
pytest==5.4.1
six==1.14.0
wcwidth==0.1.8

I don't understand why Windows would have anything to do with this.  On Mac, I can't reproduce the issue. I get 100% coverage.

I don't get it either. I'll try reproducing this on a second computer.
How would I go about getting more debugging information?

I have reproduced it on second, fairly clean, Windows box. I followed the above instructions.
The "system information" is exactly the same. Except the pid.

This has been reproduce on:

3.8.0-2 (all available Windows 3.8 versions) on my main PC. These were all standard 64 bit CPython installs from their website.
3.8.0 on a second box.
I also got another person to test this on their Windows box, inside a VM, and they also reproduced this.

Other person's system information
(venv) example $ python --version
Python 3.8.2
(venv) example $ pip list
Package        Version
-------------- -------
atomicwrites   1.3.0
attrs          19.3.0
colorama       0.4.3
coverage       5.0.4
more-itertools 8.2.0
packaging      20.3
pip            20.0.2
pluggy         0.13.1
py             1.8.1
pyparsing      2.4.6
pytest         5.4.1
setuptools     46.0.0
six            1.14.0
wcwidth        0.1.8
wheel          0.34.2

I cannot reproduce this on Windows.  With Windows 10, Python 3.8.1 64 bit, coverage 5.0.4, pytest 5.4.1, your example has 100% coverage on my machine.

I can reproduce this

https://usercontent.irccloud-cdn.com/file/Suugb9xM/.coverage

Here is dis output from Windows: https://gist.github.com/bensimner/463858949e4a34dde1edce7489027f49 I get the same dis output on Mac, so I don't understand how the execution could differ.

Would comparing .coverage files between systems help? Are there other logs/outputs we can get to help narrow down where the bug is coming from? Do the different stages each have output we can use for this? Would the output with --debug used help?

If I am able to learn how to get VMs to work on Linux then I'd be happy to compare the outputs. But I know very little about coverage as you've made the usage super simple. If you could help me find any and all debugging output then I'd be happy to try and track down the origin of the bug. But I'm not too sure how much I'd be able to help.

This seems to be Python 3.8 specific on Windows. I.e.:
$ coverage run  -m pytest
============================================================================================================= test session starts =============================================================================================================
platform win32 -- Python 3.8.0, pytest-6.0.1, py-1.9.0, pluggy-0.13.0
rootdir: G:\Python\libs\example
collected 1 item

test_example.py .                                                                                [100%]

============================================================================================================== 1 passed in 0.06s ==============================================================================================================

$ coverage report -m
Name              Stmts   Miss  Cover   Missing
-----------------------------------------------
test_example.py      10      1    90%   5

Vs.:
$ coverage run  -m pytest
============================================================================================================= test session starts =============================================================================================================
platform win32 -- Python 3.7.3, pytest-5.4.2, py-1.8.0, pluggy-0.12.0
rootdir: G:\Python\libs\example
plugins: anyio-1.3.1, cov-2.9.0, timeout-1.3.4, trio-0.6.0
collected 1 item

test_example.py .                                                                                [100%]

============================================================================================================== 1 passed in 0.06s ==============================================================================================================

$ coverage report -m
Name              Stmts   Miss  Cover   Missing
-----------------------------------------------
test_example.py      10      0   100%

Both are with:
$ pip show coverage
Name: coverage
Version: 5.2.1

$ pip show pytest
Name: pytest
Version: 6.0.1

And disassembly is different:

Python 3.8 disassembly
    ```
    $ python -m dis test_example.py
      1           0 LOAD_CONST               0 ()
                  2 LOAD_CONST               1 ('fn')
                  4 MAKE_FUNCTION            0
                  6 STORE_NAME               0 (fn)
 10           8 LOAD_CONST               2 (<code object test_fn at 0x0000019421162C90, file "test_example.py", line 10>)
             10 LOAD_CONST               3 ('test_fn')
             12 MAKE_FUNCTION            0
             14 STORE_NAME               1 (test_fn)
             16 LOAD_CONST               4 (None)
             18 RETURN_VALUE

Disassembly of <code object fn at 0x0000019421162BE0, file "test_example.py", line 1>:
  2           0 SETUP_FINALLY           22 (to 24)

  3           2 LOAD_FAST                0 (values)
              4 GET_ITER
        >>    6 FOR_ITER                10 (to 18)
              8 STORE_FAST               1 (_)

  4          10 LOAD_GLOBAL              0 (KeyboardInterrupt)
             12 CALL_FUNCTION            0
             14 RAISE_VARARGS            1
             16 JUMP_ABSOLUTE            6

  5     >>   18 POP_BLOCK
             20 LOAD_CONST               1 (0)
             22 RETURN_VALUE

  6     >>   24 DUP_TOP
             26 LOAD_GLOBAL              0 (KeyboardInterrupt)
             28 COMPARE_OP              10 (exception match)
             30 POP_JUMP_IF_FALSE       44
             32 POP_TOP
             34 POP_TOP
             36 POP_TOP

  7          38 POP_EXCEPT
             40 LOAD_CONST               2 (130)
             42 RETURN_VALUE
        >>   44 END_FINALLY
             46 LOAD_CONST               0 (None)
             48 RETURN_VALUE

Disassembly of <code object test_fn at 0x0000019421162C90, file "test_example.py", line 10>:
 11           0 LOAD_GLOBAL              0 (fn)
              2 BUILD_LIST               0
              4 CALL_FUNCTION            1
              6 LOAD_CONST               1 (0)
              8 COMPARE_OP               2 (==)
             10 POP_JUMP_IF_TRUE        16
             12 LOAD_GLOBAL              1 (AssertionError)
             14 RAISE_VARARGS            1

 12     >>   16 LOAD_GLOBAL              0 (fn)
             18 LOAD_CONST               2 (Ellipsis)
             20 BUILD_LIST               1
             22 CALL_FUNCTION            1
             24 LOAD_CONST               3 (130)
             26 COMPARE_OP               2 (==)
             28 POP_JUMP_IF_TRUE        34
             30 LOAD_GLOBAL              1 (AssertionError)
             32 RAISE_VARARGS            1
        >>   34 LOAD_CONST               0 (None)
             36 RETURN_VALUE
```

vs.

Python 3.7 disassembly
    ```
    $ python -m dis test_example.py
      1           0 LOAD_CONST               0 ()
                  2 LOAD_CONST               1 ('fn')
                  4 MAKE_FUNCTION            0
                  6 STORE_NAME               0 (fn)
 10           8 LOAD_CONST               2 (<code object test_fn at 0x000001FD5FAF5780, file "test_example.py", line 10>)
             10 LOAD_CONST               3 ('test_fn')
             12 MAKE_FUNCTION            0
             14 STORE_NAME               1 (test_fn)
             16 LOAD_CONST               4 (None)
             18 RETURN_VALUE

Disassembly of <code object fn at 0x000001FD5FB03F60, file "test_example.py", line 1>:
  2           0 SETUP_EXCEPT            24 (to 26)

  3           2 SETUP_LOOP              18 (to 22)
              4 LOAD_FAST                0 (values)
              6 GET_ITER
        >>    8 FOR_ITER                10 (to 20)
             10 STORE_FAST               1 (_)

  4          12 LOAD_GLOBAL              0 (KeyboardInterrupt)
             14 CALL_FUNCTION            0
             16 RAISE_VARARGS            1
             18 JUMP_ABSOLUTE            8
        >>   20 POP_BLOCK

  5     >>   22 LOAD_CONST               1 (0)
             24 RETURN_VALUE

  6     >>   26 DUP_TOP
             28 LOAD_GLOBAL              0 (KeyboardInterrupt)
             30 COMPARE_OP              10 (exception match)
             32 POP_JUMP_IF_FALSE       44
             34 POP_TOP
             36 POP_TOP
             38 POP_TOP

  7          40 LOAD_CONST               2 (130)
             42 RETURN_VALUE
        >>   44 END_FINALLY
             46 LOAD_CONST               0 (None)
             48 RETURN_VALUE

Disassembly of <code object test_fn at 0x000001FD5FAF5780, file "test_example.py", line 10>:
 11           0 LOAD_GLOBAL              0 (fn)
              2 BUILD_LIST               0
              4 CALL_FUNCTION            1
              6 LOAD_CONST               1 (0)
              8 COMPARE_OP               2 (==)
             10 POP_JUMP_IF_TRUE        16
             12 LOAD_GLOBAL              1 (AssertionError)
             14 RAISE_VARARGS            1

 12     >>   16 LOAD_GLOBAL              0 (fn)
             18 LOAD_CONST               2 (Ellipsis)
             20 BUILD_LIST               1
             22 CALL_FUNCTION            1
             24 LOAD_CONST               3 (130)
             26 COMPARE_OP               2 (==)
             28 POP_JUMP_IF_TRUE        34
             30 LOAD_GLOBAL              1 (AssertionError)
             32 RAISE_VARARGS            1
        >>   34 LOAD_CONST               0 (None)
             36 RETURN_VALUE
```

@matham Yes this seems to effect Python 3.8.x on Windows only. Your 3.8 disassembly is the exact same as I'm getting on Python 3.8.5 on Linux.

Reposting here, as Ned alluded to here https://discuss.python.org/t/same-python-version-different-optimizations-on-different-os/5098, this is a CPython bug. In particular, it relates to the opcode prediction in the interpreter which is different on Windows vs compilers that support computed GOTOs.

I've created https://bugs.python.org/issue41670 for this.

Nice. Since there is a duplicate and this doesn't seem to be a coverage.py issue, I'm going to close this.

@Peilonrayz the duplicate was already closed, this is the last remaining ticket in this project

@ammaraskar had an interesting idea about how coverage.py could perhaps adapt to this, so I'm re-opening.

There is now a fix for this upstream in CPython, could someone try this on the latest alpha and see if it re-creates: https://www.python.org/downloads/release/python-3100a1/

I have tried this with 3.10.0a1 and did not reproduce my issue.

I'll close this since Python 3.10 fixes it.


Business

Hello, I would like to know if this project runs over some sort of licence or if it's open source for commercial use. It's for a little project I'm making.

don't i member of this project, but i use in my personal project and is free, i think what not problem if you use this library.
the creator say me by inbox, what don't have problem.
welcome, if we more, better!

It is open source under BSD-3-Clause license. So you can use it with Copyright notice of FolioReader..
To know more checkout https://github.com/FolioReader/FolioReader-Android/blob/master/License.md


Changes the way we evaluate policies to using entrypoints

What type of PR is this? (check all applicable)

[x] Refactor
[x] Feature
[ ] Bug Fix
[ ] Optimization
[ ] Documentation Update

Description
Changes the way we evaluate policies, we move to using entrypoints which is discussed in #143
Related Tickets & Documents

Related Issue #143
Closes #143

Instructions, Screenshots, Recordings
N/A
Added/updated tests?
We encourage you to keep the code coverage percentage at 80% and above.

[x] Yes
[ ] No, and this is why: please replace this line with details on why tests
have not been included
[ ] I need help with writing tests

@anderseknert can I get your opinion on this? 😅


Add more option types

Is your feature request related to a problem? Please describe.
Options generation from .json file was added in https://github.com/f3d-app/f3d/pull/1471, but only a few types were added:

bool
int
double
ratio
double_vector
string

Lets add more types.

[ ] direction (specialisation of double_vector): https://github.com/f3d-app/f3d/issues/1645
[ ] color (specialisation of double_vector)
[ ] path (specialisation of string)
[ ] rgba_colormap (specialisation of double_vector)

To add a type it is needed to:

Add it to types.h with the correct API
Add a naive parse/format methods to options_tools.h.in
Use it for at least one option in options.json
Add testing in TestSDKOptions*

Is this issue still open? If it is I would like to work on it.

Yes it is open! Lets discuss this one discord though :)

sure lets discuss on discord

Good afternoon, I was wondering if this issue was still open? If so, is it possible I could work on it?

It is still open but @Yogesh9000 is working on it in https://github.com/f3d-app/f3d/pull/1648


Caught I/O errors from localhost, trying to reconnect (error: java.io.InvalidClassException: com.orientechnologies.orient.core.exception.OCoreException: local class incompatible)

Expected behavior and actual behavior
Moved to orientdb v2.2.2 to counter issue(s) #6219 & #6234. Running the same code as in #6219 & #6234 to insert dbpedia data as a linked data graph in orientDB.
While I am not getting the issue as in #6234, after insertion of some 20k more vertices and similar no. of edges from the point i got the #6234 issue, i get this issue. Kindly refer to the jpeg attached to get the full error stack.
While the program is running, as you can see from the jpeg, its losing connection again & again from the OrientDB server at localhost, and as such further inserts are not happening.

Steps to reproduce the problem

Steps to reproduce the problem are mentioned in the comments of #6234, as i am running the same code.

Running Mode

Remote, on the same machine.

OrientDB Version

v2.2.2

Operating System

Linux, Ubuntu 14.04

Java Version

Java 8

This has been very frustrating. After 2 months, 3 bugs filed, I am still not able to upload a simple real-world graph to OrientDB.

Hi @srthecodexpress
From the logs it seems you are using different versions of Java client vs. server, could you please check this and in case align both to the same version?
Thanks
Luigi

Ok @luigidellaquila I'll check it and get back to you.
Thanks
Sitanshu.

@luigidellaquila I checked that. Both java versions are the same. To make sure, i re-ran the same code again with same java versions and i am getting same issue. Kindly check.
Thanks
Sitanshu.

Hi @srthecodexpress
ops, sorry, my fault, wrote too quick... I meant OrientDB version, not Java version... could you please check it?
Thanks
Luigi

Hi @luigidellaquila
Oops, yes, the OrientDB version in the client program was different, my mistake.
I fixed that and re-ran the code. Now, this issue is not happening!!
However, I am getting the exception of the issue #6234 for 4 nodes.
Here are the caught exceptions entries that were there in the log.
016-06-23 16:48:06.142 INFO  org.formcept.knowledge.base.graph.FCOrientGraph: {:message "Exception at insertion of node: http://dbpedia.org/resource/Communist_Party_of_Malaya/Marxist–Leninist\n. Exception message: Cannot put key value entry in index\r\n\tDB name="LinkedDataStore"\r\n\tDB name="LinkedDataStore""}
2016-06-23 16:48:09.263 INFO  org.formcept.knowledge.base.graph.FCOrientGraph: {:message "Exception at insertion of node: http://dbpedia.org/resource/Communist_Party_–_Red_Star\n. Exception message: Cannot put key value entry in index\r\n\tDB name="LinkedDataStore"\r\n\tDB name="LinkedDataStore""}
2016-06-23 16:48:10.531 INFO  org.formcept.knowledge.base.graph.FCOrientGraph: {:message "Exception at insertion of node: http://dbpedia.org/resource/Communist_Party_of_Nepal_(Janamukhi)\n. Exception message: Cannot put key value entry in index\r\n\tDB name="LinkedDataStore"\r\n\tDB name="LinkedDataStore""}
2016-06-23 16:48:11.842 INFO  org.formcept.knowledge.base.graph.FCOrientGraph: {:message "Exception at insertion of node: http://dbpedia.org/resource/Communist_Party_of_Malaya/Revolutionary_Faction\n. Exception message: Cannot put key value entry in index\r\n\tDB name="LinkedDataStore"\r\n\tDB name="LinkedDataStore""}
Since its only 4 nodes till now, that is not such a big problem for us. We are proceeding with the ETL.
But FYI, #6234 seems not to be fully resolved yet. The URIs are there for your testing and validation.
Should I re-open the #6234 issue? Because, it will be a problem for us if the number of such exceptions rise as we still have a lot of dbpedia data still left to upload. The program is still running.
I'll go ahead and close this issue.
Thanks
Sitanshu.

Hi @srthecodexpress
Thank you for the update, I'm re-opening issue #6234 for you, for a double check
Thanks
Luigi


Add missing matchers for lvm thin pools and volumes

Description
Adds missing ChefSpec matchers for the lvm_thin_pool and lvm_thin_volume LWRPs.
Issues Resolved
There are currently matchers missing for the lvm_thin_pool and lvm_thin_volume LWRPs.
Check List

[x] All tests pass. See https://github.com/chef-cookbooks/community_cookbook_documentation/blob/master/TESTING.MD
[x] New functionality includes testing.
[x] New functionality has been documented in the README if applicable
[x] All commits have been signed for the Developer Certificate of Origin. See https://github.com/chef-cookbooks/community_cookbook_documentation/blob/master/CONTRIBUTING.MD

Thanks!


initial commit of Get-DbaLastGoodCheckDb

First attempt - feedback more than welcome!

Here is an example of the error when trying to add two values to [datetime]$lastKnownGood although it doesn't really tell you much...
Cannot convert the "System.Object[]" value of type "System.Object[]" to type "System.DateTime".
At C:\users\DanielAlexander\My Documents\WindowsPowerShell\Modules\dbatools\functions\Get-DbaLastGoodCheckDb.ps1:132 char:5

...             [datetime]$lastKnownGood = ($resultTable | Where-Object F ...

            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

CategoryInfo          : MetadataError: (:) [], ArgumentTransformationMetadataException
FullyQualifiedErrorId : RuntimeException

Further testing reveals the field you're reading to get the information doesn't exist in SQL 2000, so you'll either need to skip that version, or account for the field not existing.
My advice would be to code for both, that way you're informing the user why it was skipped (there's examples in other cmdlets), but also trapping any other errors that may come up, rather than spitting out a red wall of text about time spans :+1:

@Jagoop: The warning output does not mention the instance name, for example:
WARNING: Get-DbaLastGoodCheckDb is only supported on SQL Server 2005 and above. Skipping Instance.
WARNING: The database DBName is not accessible. Skipping database.
Which instance was skipped? On which instance was the database DBName skipped?

Hey @Jagoop we're not sure why this PR is now showing a merge conflict. As the branch is a fork in your own repo, we're also not sure we can do anything about it, so we might have to bump this into November unless you can clean it up today at some point, unless someone else can come to the rescue?