[WIP] Update to OpenALPR 2.3 version

This PR updates the OpenALPR library to the version 2.3.

looking forward to using this new version with the new edge detection for high contrast plate

Hi @SandroMachado
I'm trying out this WIP version and I'm getting when processing an image
java.lang.UnsatisfiedLinkError: dlopen failed: could not load library "libopenalpr.so" needed by "libopenalprjni.so"; caused by cannot locate symbol "_ZSt15get_new_handlerv" referenced by "libopenalpr.so"

I saw that there is an open issue regarding android binaries in the parent repository https://github.com/openalpr/openalpr/issues/273#issuecomment-255994514 and it doesn't seem to have any progress.
May I know what are your environment settings and configuration that allowed you to compile the binaries?
Thanks alot!

@Vantablack are you using the sample project to test it?
But, unfortunately this version has a memory leak that makes it almost unusable.

@SandroMachado Yeap! I'm using the sample project included inside is repository. Is there any ETA on when this PR will be accepted?

Hi, there!
Do we have any progress on this? How can I help you?
Thanks!

@mvrogowski This version has an issue that causes a memory leak. I did not had time to fix the issue.

@SandroMachado possible to share the jni code and  setup of this project so that we could look into it and possibly help in fixing the leak issue?

@SandroMachado possible to share the jni code and setup of this project so that we could look into it and possibly help in fixing the leak issue?

Any update on it?

I wish @SandroMachado could have more time to update this library 👍


Inconsistent Dart analyzer results with recent upgrade

Steps to Reproduce
I recently upgraded Flutter, and got my code working with the recent pubspec.yaml/flutter.yaml merge. However, I'm now seeing some very strange things coming out of the dart analyzer. From the "Dart Analysis" panel in IntelliJ, everything looks great and I'm not seeing any errors or warnings, including when I restart the Dart Analysis Server. However, re-analyzing my sources in Atom gives me a bunch of strange warnings. Also, if I run the dartanalyzer command in Terminal, I'm getting the same warnings as I am in Atom. Note that if I go back to an older version of Flutter from 2 weeks ago, I'm not getting any warnings from dartanalyzer.
I'm confused about why I'm seeing different results in IntelliJ from results using the other methods. I'm also not sure why I'm seeing these warnings.
Logs
dartanalyzer [file names]
[warning] Element 'int' from SDK library 'core.dart' is implicitly hidden by 'popup_menu.dart (via material.dart)' ([filepath], line 63, col 18)
[warning] int is not a type ([filepath], line 63, col 18)
[warning] Element 'List' from SDK library 'core.dart' is implicitly hidden by 'popup_menu.dart (via material.dart)' ([filepath], line 78, col 3)
[warning] List is not a type ([filepath], line 78, col 3)
[warning] int is not a type ([filepath], line 79, col 3)
[warning] List is not a type ([filepath], line 90, col 5)
[warning] List is not a type ([filepath], line 91, col 5)
[warning] int is not a type ([filepath], line 109, col 21)
[warning] int is not a type ([filepath], line 159, col 18)
.
.
.
964 warnings found.

Flutter Doctor
[✓] Flutter (on Mac OS, channel master)
    • Flutter at /Users/emshack/flutter
    • Framework revision 682c7992e5 (46 minutes ago), 2017-01-26 15:43:28
    • Engine revision fb69728f33
    • Tools Dart version 1.22.0-dev.9.1

[✓] Android toolchain - develop for Android devices (Android SDK 23.0.2)
    • Android SDK at /Users/emshack/Library/Android/sdk
    • Platform android-23, build-tools 23.0.2
    • Java(TM) SE Runtime Environment (build 1.8.0_60-b27)

[-] iOS toolchain - develop for iOS devices (Xcode 8.2.1)
    • XCode at /Applications/Xcode.app/Contents/Developer
    • Xcode 8.2.1, Build version 8C1002
    x ideviceinstaller not available; this is used to discover connected iOS devices.
      Install via 'brew install ideviceinstaller'.
    x ios-deploy not available; this is used to deploy to connected iOS devices.
      Install via 'brew install ios-deploy'.

[✓] IntelliJ IDEA Community Edition (version 2016.3.1)
    • Dart plugin version 163.9166.22
    • Flutter plugin version <IP_ADDRESS>

[✓] Connected devices
    • None

Do you see these same warnings with flutter analyze?
There is a .analysis_options_user file in the flutter repo root that is not picked up by dartanalyzer and I'm wondering if this is the cause of what you are seeing.

No, I'm not seeing the same warnings. Should something in my project be configured differently?

Nope. That's a bug on my plate to normalize the output between flutter analyze, dartanalyzer, and analysis server. I'm making progress but there are several changes I need to land before the work is complete. For now, rely on flutter analyze.

Ok, thanks! Please let me know when the changes are in.

@emshack was this a regression?  @danrubel is there a bug @emshack can track?

Not sure what you mean-- this bug occurred after I updated Flutter, I had never seen these errors before.

FYI, I just upgraded Dart and this problem went away.

Thanks for the report!  Closing.

Yes, this was resolved in a recent Dart SDK drop.


fix: drover parser setting colors to wireframe

Description
The style-dictionary-sets parser for drover was setting color tokens to wireframe.  This updates the dependency to pick up that patch (2.0.1).

Related Issue
I didn't open an issue

Motivation and Context
I like fixing things

Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] I have signed the Adobe Open Source CLA.
[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

:tada: This PR is included in version 12.0.0-beta.39 :tada:
The release is available on:

GitHub release
npm package (@beta dist-tag)

Your semantic-release bot :package::rocket:

I'm just an automated bot that comments on prs even when I'm not working.

:tada: This PR is included in version 1.0.0 :tada:
The release is available on:

GitHub release
npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:


Error msg. "Ikke definert tittel"

Sometimes the text "Ikke definert tittel" shows up in the drop down for enable when.
Helse Vest has seen this error many times (they have used other elements, so this is not related to mottaker liste only). I have so far only found it in this form: https://gist.github.com/MariaNHN/7e0cbc508df2b3cec81d58e763a1642f

In this case, it is because the item does not have the "text" property. However, it has the following markdown: "Velg det sykehuset som du tenker å oppsøke. Skjemaet vil bli lagret i journalen din hos det sykehuset du velger." We can change the dropdown to use markdown if the item does not have a "text" attribute. (why does this element use markdown though? There is is no markdown formatting in the sentence above)
However, this will not solve the issue of items without "text" and "_text" (markdown extension). This can happen for for example groups without a header. I guess this is a question about design; if we hide them, the dropdown might look confusing since it is missing a level. I prefer showing the item, but perhaps the "Ikke definert tittel" text can be changed to something else.


[Google Drive Connector] File Operations

This pull request contains Google drive connector implementation. As the first step, This contains the functionality of file operations only.
 We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@SkNuwanTissera The commit messages and PR heading is not according to the best practices. Please correct them.

[1] https://github.com/ballerina-platform/ballerina-lang/blob/master/CONTRIBUTING.md#submit-your-contribution

@SkNuwanTissera The commit messages and PR heading is not according to the best practices. Please correct them.

[1] https://github.com/ballerina-platform/ballerina-lang/blob/master/CONTRIBUTING.md#submit-your-contribution

Thank you @anupama-pathirage
I will correct them and follow this practice going forward.

#https://github.com/wso2-enterprise/choreo/issues/2899

Resolves https://github.com/wso2-enterprise/choreo/issues/3050


Parametrised Scenarion Outline Definition

Was going through Specflow-How to pass parameter in scenario outline description and wonder how to pass parameter in Scenario outline description in watir?
Let's use the same example from other post.
Scenario Outline : Testing <Application>
    Given I navigate to <Application>
    Then I should see Home page

    Examples:
    | Application |
    | Test        |
    | Test1       |
    | Test2       |

This will be helpful when user generate the consolidate report with Report Builder to show each scenario outline as a separate scenario with the application name rather showing Testing .
Actual Sample Report: Without parameter updated to scenario outline enter image description here
Expected Sample Report: All we need is to update  based on example table data
enter image description here
Appreciate any detailed explanation.

@aurelien-reeves
Mmh, I actually think that it is not related to the formatter.
I think that @poojaghosh47 means an aspect how the Scenarios are actually build from the ScenarioOutline template description. Meaning what is part of the template and what is not.
QUESTION: Is the example above currently possible in Cucumber (parameter/placeholder in the title) ?
In such a way that:
# — HINT: AFTER TEMPLATE EXPANSION (from example table rows):
Scenario Outline: Testing Test
   Given I navigate to Test
   …

Scenario Outline: Testing Test1
   Given I navigate to Test1
   …

Scenario Outline: Testing Test2
   Given I navigate to Test2
   …

Hi Team ,
I got solution for this . We can pass Examples data directly to scenarios outline using below format.
Seriously I am happy to try this and it worked .
It is helpful for understanding the combine report scenario wise .
Each scenario outline for example will have specific example data in scenario outline definition.
Scenario Outline : Testing ““
Given I navigate to ““
Then I should see Home page
Examples:
| Application |
| Test        |
| Test1       |
| Test2       |

OUTPUT In report will be like:
Scenario Outline : Testing Test
Given I navigate to Test
Then I should see Home page
Scenario Outline : Testing Test1
Given I navigate to Test1
Then I should see Home page

I was not sure that would work, so I did not suggest it
Happy it does! 🎉

@aurelien-reeves Mmh, I actually think that it is not related to the formatter. I think that @poojaghosh47 means an aspect how the Scenarios are actually build from the ScenarioOutline template description. Meaning what is part of the template and what is not.
QUESTION: Is the example above currently possible in Cucumber (parameter/placeholder in the title) ?
In such a way that:
# — HINT: AFTER TEMPLATE EXPANSION (from example table rows):
Scenario Outline: Testing Test
   Given I navigate to Test
   …

Scenario Outline: Testing Test1
   Given I navigate to Test1
   …

Scenario Outline: Testing Test2
   Given I navigate to Test2
   …

Thanks @jenisys
I understood well its proposition. I was not sure for the formatting of the name and description of the scenario.
But reporting one test per example in the examples table actually concern the formatter


Security Master check is hardcoded and non-specific

Currently the system of checking for "Security Master" subscription only considers "Equity Security Master". However, different datasource require different "Security Master" products.
In example:
Bulk US Equity Data -> Bulk US Equity Security Master (PID 180)
US Equity Data -> US Equity Security Master (PID 37)
Bulk US Futures Data -> Bulk US Futures Security Master (PID 179)
US Futures Data -> US Futures Security Master (PID 137)
I believe this can be addressed by a two step change. One to the API and then the CLI reflecting.
SOLUTION:
The web api response for "data/prices" under "datasources" has a field "requiresSecurityMaster" which is a simple true/false. Instead I suggest we make this a requires field as an int[] that contains the required products if any for that Product id.
EX Before
	"datasources": {
		"4": {
			"requiresSecurityMaster": true,
			"options": [],
			"paths": []
		}
        }

EX after
	"datasources": {
		"4": {
			"requires": [ 37 ],
			"options": [],
			"paths": []
		}
        }

That way in the CLI when we want to check if a product can be downloaded we can just ensure that the required product ID exists in the organization subscriptions.
This also allows us to not have to hardcode any security master product ID in the CLI as it is now.

Fixed 2022


Warning: componentWillReceiveProps has been renamed, and is not recommended for use.

react-dates version
<EMAIL_ADDRESS>Describe the bug
Since<EMAIL_ADDRESS>any component that uses componentWillReceiveProps produces a console warning:
Warning: componentWillReceiveProps has been renamed, and is not recommended for use. See https://fb.me/react-async-component-lifecycle-hooks for details.

* Move data fetching code or side effects to componentDidUpdate.
* If you're updating state whenever props change, refactor your code to use memoization techniques or move it to static getDerivedStateFromProps. Learn more at: https://fb.me/react-derived-state
* Rename componentWillReceiveProps to UNSAFE_componentWillReceiveProps to suppress this warning in non-strict mode. In React 17.x, only the UNSAFE_ name will work. To rename all deprecated lifecycles to their new names, you can run `npx react-codemod rename-unsafe-lifecycles` in your project source folder.

Please update the following components: DateInput, OutsideClickHandler

Note at the bottom it says Please update the following components: DateInput, OutsideClickHandler. However, some grep-ing shows:
>grep componentWillReceiveProps -r .
./components/CalendarMonth.jsx:  componentWillReceiveProps(nextProps) {
./components/DayPickerKeyboardShortcuts.jsx:  componentWillReceiveProps(nextProps) {
./components/DayPickerSingleDateController.jsx:  componentWillReceiveProps(nextProps) {
./components/DayPickerRangeController.jsx:  componentWillReceiveProps(nextProps) {
./components/DayPicker.jsx:  componentWillReceiveProps(nextProps) {
./components/CalendarMonthGrid.jsx:  componentWillReceiveProps(nextProps) {
./components/DateInput.jsx:  componentWillReceiveProps(nextProps) {

The fix should be as simple as pre-pending UNSAFE_ to those functions and re-building
Source code (including props configuration)
Note that I'm using react hooks for the state and I'm converting my dates to moments on-the-fly:
const DATE_FORMAT_MOMENT = "YYYY-MM-DD";

<DateRangePicker
  startDate={moment(dates.start)}
  endDate={moment(dates.end)}
  startDateId="start"
  endDateId="end"
  onDatesChange={({ startDate, endDate }) => {
    if (startDate && endDate) {
      setDates({
        start: startDate.format(DATE_FORMAT_MOMENT),
        end: endDate.format(DATE_FORMAT_MOMENT)
      });
    }
  }}
  focusedInput={focusedDate}
  onFocusChange={focusedDate => setFocusedDate(focusedDate)}
/>

Desktop (please complete the following information):

Mac OS 10.14.6
Chrome 77.0.3865.90

Duplicate of #1748.


Update alternatives matrix

First, we add bernedom/SI to the alternatives matrix.  It's an
impressively popular library (400 stars!) which didn't get included when
we released the library because it wasn't on my radar: at the time, it
didn't have the dimensional-analysis tag which most of the others had,
so it didn't show up in my searches.
Next, I updated the results for mp-units for the first time since the
major 2.0 API upgrade.  mp-units improved significantly, and those
improvements were concentrated in the more important categories, such as
"Unit Safety" and "Composability".  (It also regressed in "Macros", but
that's the least important category.)
I added some rows that were completely missing before:

Unit-aware I/O
Linear algebra
Physical constants

I also renamed UDLs to "Abbreviated construction", since UDLs aren't
really the best way to do that anyway.
After that, I made a few tweaks for previous assessments that I couldn't
really justify in retrospect.

Conversion Safety:

The nholthaus library should have been marked as "poor", based on
the literal text of the explanation for this category.

Low Friction:

Boost should have been marked as "poor", based not only on the
literal text of the category explanation, but also my own personal
experience.  (I have never been able to get the library to do
anything except by taking an already-working snippet and modifying
it --- it's a notably high friction experience.)
mp-units should have been marked as "fair", not "good", because it
requires a variety of different headers, and they're hard to
guess.  It also has a more complicated namespace structure,
although that may be an unavoidable consequence of its support for
multiple systems of measurement.

Finally, I make a few updates to the page itself to make it more usable.
For the first time, I explicitly list each library, and a few of its
virtues that led us to include it here.  I also make it clear which
version we evaluated, based on the experience with mp-units which just
got a major upgrade.  I also made explicit for the first time that the
higher-up rows are more important than the lower-down ones.
Fixes #108.

Thanks for the thorough review comment!  I've tried to address all of the points.

Compiler Error Readability

you could mention a new expression template syntax
maybe with expression templates the readability is better? wink

What a blind spot for me: I forgot to check the first two tables!  I was only focused on the main one.  I hadn't noticed that the new update drops the explicit dimension parameter from the quantity template --- very nice improvement.  I've upgraded mp-units to "good" and dropped our own "best" down to "good".

Low Friction

I've just updated the hello_units example to simplify headers (https://github.com/mpusz/mp-units/blob/master/example/hello_units.cpp#L30-L32) - thanks for the feedback!

It's a nice improvement, since now there's just one file to include per system.  I'll take the "x" off, as I think this is now in a similar place to the bernedom/SI entry.
From a big picture perspective, I think the row as a whole is in a good place.

nholthaus should be "good", because the library excels at a low-friction experience.  I've used it before, and it's so easy to pick it up and get going!
Au should be "best", because we have all of the same advantages as nholthaus here, but also a simpler and shorter namespace structure and more configurability.
Boost should be "poor", because the library is simply very hard to use.  That's been my experience, and also the experience of every user I've talked to, including those who advocate it.
mp-units and SI are "middle ground" here.  Clearly easier to use than Boost, but also clearly more friction than nholthaus.

Composability

mp-units can compose units, prefixes, dimensions, and quantity types

Done.

"User-defined literals (UDLs)" should probably be renamed to "Construction helpers"

using UDLs is actually considered a bad practice here

I don't know if I'd say it's a bad practice, but yeah --- as you've shown elsewhere, UDLs for quantities have a lot of drawbacks, and Quantity References are just straight-up better.  I went with "Abbreviated construction" instead of "Construction helpers", since the abbreviated nature is I think really key to its benefits.

Kind Types

I think that this category should be split into two separate rows: "separation of quantities of the same dimension but different kinds" and "hierarchy of quantities of the same kind" as those features are somehow orthogonal, and could be added in isolation, and may have different importance

I decided to put these in the explanation for this row.  I think giving multiple rows to kinds would over-emphasize a feature whose usefulness I've come to see, but which I still think is marginal in the big picture.

Units as types

I am not sure what you mean here
Au mentions "Can form instances and do arithmetic"
in mp-units you can do equations on units, dimensions, quantity specs, and quantities

I had overlooked this update --- nice catch!  Fixed.

Categories that are possibly missing:

Systems of Quantities

I think this is covered under "Explicit Systems of Measurement".

Support of vector and tensor quantities

Thanks!  Added.
I'm giving everyone a "fair" rating as a baseline here because basically any units library here would work out of the box with a linear algebra library that doesn't make strong assumptions.  We had a patched version of Eigen that was like this at ATG, and I hope given the conversation in #70 that this kind of patch can start making its way upstream.  There really wasn't too much patching required to get it to work.  The overall user experience with this approach at ATG was... well, "fair".  :slightly_smiling_face:

pure dimensional analysis

I'm not sure when users would reach for this.  We do support this as well in Au, but with our idioms, end users virtually never work with dimensions directly anyway.

physical constants as units

Yes, definitely!  This is one feature I'm really excited about adding in 0.4.0.

std::format support

Added a unit-aware I/O section near the top.

I agree with the things you wrote and are which are not mentioned below explicitly. But I also have more comments on your answers 😉

I decided to put these in the explanation for this row

Unfortunately, your description has issues. By the "separation of quantities of the same dimension but different kinds" I meant things like frequency, activity, modulation rate, etc. We probably agree that 1 Hz + 1 Bq + 1 Bd should not work, and I think it is quite an important feature (maybe more important than quantities of the same kind like height and radius). Unfortunately, most or maybe even all libraries allow this operation even though ISO explicitly says it is not allowed. This is why I recommended having those two as separate categories.

I think this is covered under "Explicit Systems of Measurement".

I do not think so. Explicit systems of measurement are understood by people as having the imperial, USC, international, CGS, etc. But most libraries implement them either just as system of units or mix of units and quantities. System of Quantities is about modeling dependencies between quantities without mentioning units, numbers, representation types, etc, at all. See the official definition here: https://mpusz.github.io/mp-units/2.0/appendix/glossary/#system-of-quantities. mp-units is the only library that separates Systems of Quantities from Systems of Units. You can define them totally independently (i.e. for the Natural Units system) or base System of Units on the underlying System of Quantities like SI explicitly does (https://mpusz.github.io/mp-units/2.0/appendix/glossary/#si).

I'm giving everyone a "fair" rating as a baseline here because basically any units library here would work out of the box with a linear algebra library that doesn't make strong assumptions

That is actually wrong. My understanding is that besides mp-units (actually the code I have locally on my computer and not pushed yet) none of the libraries work at all with vector quanties. Using any of the libraries on the list, how would you construct angular momentum quantity from position vector and momentum? Note that both arguments are vector quantities so should be expressed with the linear algebra vector type. All of the libraries assume that agular_momentum = position_vector * momentum, but if you actually add an underlying type like (la_vector{1, 2, 3} * m) * (la_vector{3, 2, 1} * (kg * m / s)) how can it mathematically work? How would you obtain angular momentum as a result of those in AU?

I'm not sure when users would reach for this. We do support this as well in Au, but with our idioms, end users virtually never work with dimensions directly anyway.

Well, I didn't think about this as a really important feature as well, but some people from national labs asked me about it at ISO meetings some time ago, and also @bernedom asked for this explicitly during our last meeting.

Added a unit-aware I/O section near the top.

mp-units also supports "Unit labels available even without <iostream>". See:

https://github.com/mpusz/mp-units/blob/60a564a86700804e306f0d73a1521ea6e4abe377/src/core/include/mp-units/unit.h#L811-L823
https://github.com/mpusz/mp-units/blob/master/test/unit_test/static/unit_symbol_test.cpp

It even works at compile-time :wink:

BTW, there are also a few points where I disagree with your assessment of AU (or maybe I just do not know enough about it).

Single header is nice, assuming that it has the same content every time and if it compiles fast. Allowing customization of the contents of this header is, in my opinion, a huge mistake. Consider two vendors using Au with different sets of units and a third one that tries to use the products provided by the former. The same header file in dependencies with different content is asking for problems.
I do not think that extensibility can be marked as good when you need to write multiple lines of code to add one quantity or unit. It is a huge effort on a larger scale. And macros are not welcomed either ;-)
Do you think that "No 'preferred' Rep" is a better solution than = double? I could remove the default in mp-units, but I am not so sure if users would be happy about it? Anyway, in V2 we promote 123 * m syntax so during the construction Rep is always explicitly provided by the user. = default is useful in the interfaces (i.e. void foo(quantity<si::metre, double> q) would be too verbose IMHO and double seems to be a good default based on the established practice in other libraries).
I am not sure if "sizeof()-friendly unit label representation" is a killer feature for embedded 😉, but in mp-units you can easily get the size of any unit at compile time as well (https://github.com/mpusz/mp-units/blob/master/test/unit_test/static/unit_symbol_test.cpp).

Ohh, and according to my understanding, mp-units is probably the only one that provides a system of quantities where an angle is a strong dimension/quantity. The docs are TBD (they were provided for 0.8.0), but you can find more here:

https://github.com/mpusz/mp-units/blob/master/src/systems/angular/include/mp-units/systems/angular/angular.h
https://github.com/mpusz/mp-units/blob/master/src/systems/isq_angle/include/mp-units/systems/isq_angle/isq_angle.h

I just thought of possible additional rows to the comparison table:

basic math on quantities (abs, floor, ceil, round, hypot, pow, sqrt, cbrt, exp)
trigonometric functions for angular quantities (could also extend already existing "Angles" row as an additional criteria for comparison)
one of my users contributed random generators for quantities claiming it is important for their domain as well

You can find all of the above in: https://github.com/mpusz/mp-units/tree/master/src/utility/include/mp-units.

Thanks for another thorough review!
A good thing to keep in mind is that this page is not the internet's authoritative comparison of C++ units libraries; it's merely the comparison from the point of view of Au, and of myself as its primary author.  This means that relative to others, we'll emphasize some things we think are underappreciated (unit-safe APIs; composability; migration helpers; embedded friendliness; ZERO; etc.), and de-emphasize things we find less important ("Kind" APIs; explicit systems of measurement; etc.).
I think it'd be great to see more comparison matrices from other units libraries.  Of course, each one would have somewhat different emphases according to its values.  But I expect a clear picture of the strengths, weaknesses, and other attributes of each library would emerge from comparing these comparisons, as it were.  This would be more valuable for end users than any one comparison table could be.
Having said that, I'll go through your review comments in chronological order (and thanks again for them!).

I agree with the things you wrote and are which are not mentioned below explicitly. But I also have more comments on your answers wink

I decided to put these in the explanation for this row

Unfortunately, your description has issues. By the "separation of quantities of the same dimension but different kinds" I meant things like frequency, activity, modulation rate, etc. We probably agree that 1 Hz + 1 Bq + 1 Bd should not work, and I think it is quite an important feature (maybe more important than quantities of the same kind like height and radius). Unfortunately, most or maybe even all libraries allow this operation even though ISO explicitly says it is not allowed. This is why I recommended having those two as separate categories.

I think preventing 1 Hz + 1 Bq + 1 Bd from compiling is a "nice-to-have".  Distinguishing same-dimension-same-magnitude types is hard to do without adding friction for legitimate use cases, such as adding the results of intermediate computations --- which may produce something like meter * hertz / second --- to an acceleration in meters / squared(second).  I also haven't seen evidence that same-dimension-same-magntiude errors are anywhere near as common and pernicious as "right dimension wrong units" errors, the overwhelmingly most important category.  So from my point of view, giving this nice-to-have category more than one row would be an over-emphasis.
To address your comments on the wording of the explanation text, I clarified and simplified it.  By "kind", we mean "any distinction finer than same-dimension-same-magnitude".
Now, to be clear, I think the new 2.0 syntax of mp-units has by far the most exciting "kind" solution I've seen.  It looks very likely to minimize the "cost" side of the equation, while delivering all of the benefits.  If (as I hope and expect) practical experience proves it out, I think it's likely I'll eventually try to figure out a way to bring the same kind of feature into Au, and turn one of our orange boxes blue.  :slightly_smiling_face:  Even then, though, I doubt I'd give it more than one row.

I think this is covered under "Explicit Systems of Measurement".

I do not think so. Explicit systems of measurement are understood by people as having the imperial, USC, international, CGS, etc. But most libraries implement them either just as system of units or mix of units and quantities. System of Quantities is about modeling dependencies between quantities without mentioning units, numbers, representation types, etc, at all. See the official definition here: https://mpusz.github.io/mp-units/2.0/appendix/glossary/#system-of-quantities. mp-units, and possibly Boost.Units, are the only libraries that separate Systems of Quantities from Systems of Units. You can define them totally independently (i.e. for the Natural Units system) or base System of Units on the underlying System of Quantities like SI explicitly does (https://mpusz.github.io/mp-units/2.0/appendix/glossary/#si).

The "measurement" in "Explicit systems of measurement" is intentionally a more generic term.  It covers systems of quantities, systems of units, and systems of whatever else may be useful.  The question this row answers is: do we allow the simultaneous representation of measurements which may have incompatible ideas about "which dimensions exist", or do we not?
I find it very hard to articulate why an end user would evaluate a units library separately based on explicit-systems-of-units support and explicit-systems-of-quantities support.  I think the bar for making the case to consider them separately would be to describe realistic library designs in each of the four quadrants --- "yes/no" on explicit systems of "units/quantities" --- or, if any quadrant is empty, to explain why.
That said, and just to be clear ahead of time, I'd probably need a great deal of convincing to actually put separate rows here, even once I do understand the distinction.  "Explicit systems" (generically) is a pretty clear tradeoff: you get more flexibility at the cost of a steeper learning curve.  With this many rows, we're probably risking decision fatigue for the reader as it is.

I'm giving everyone a "fair" rating as a baseline here because basically any units library here would work out of the box with a linear algebra library that doesn't make strong assumptions

That is actually wrong. My understanding is that besides mp-units (actually the code I have locally on my computer and not pushed yet) none of the libraries work at all with vector quanties. Using any of the libraries on the list, how would you construct angular momentum quantity from position vector and momentum? Note that both arguments are vector quantities so should be expressed with the linear algebra vector type. All of the libraries assume that agular_momentum = position_vector * momentum, but if you actually add an underlying type like (la_vector{1, 2, 3} * m) * (la_vector{3, 2, 1} * (kg * m / s)) how can it mathematically work? How would you obtain angular momentum as a result of those in AU?

I don't see how it can be "wrong", when the reason I gave this rating is based on our experience doing this in production for several years at Uber ATG.  We used strong types with (homogeneous!) units for vectors and matrices, where the vector quantities were things like position, velocity, and acceleration.
This was an "algebra-on-units" solution, because that was all we had at the time.  We hadn't yet learned about the "units-on-algebra" solution or why it is superior.  That's why I'm rating it as "fair", not "good".  It's also true that most or all linear algebra libraries would need some patching to get non-trivial use cases to work, but we know from experience that the patches aren't that onerous for most features.  Since those patches would benefit each library equally, I'm rating them all as "fair", except for mp-units which has some exciting new ideas for how to go beyond.
By the way, now that I've clarified that I was talking about an "algebra-on-units" solution, note that your example was spelled in a "units-on-algebra" style.  If we translate it to "algebra-on-units", it looks more like la_vector{1 * m, 2 * m, 3 * m} * la_vector{3 * (kg * m / s), 2 * (kg * m / s), 1 * (kg * m / s)}.  Assuming the vector multiplication is the cross product --- an API choice to which I would have tremendous objections, for what it's worth :grin: --- then this should produce an angular momentum "vector" without issue.

I'm not sure when users would reach for this. We do support this as well in Au, but with our idioms, end users virtually never work with dimensions directly anyway.

Well, I didn't think about this as a really important feature as well, but some people from national labs asked me about it at ISO meetings some time ago, and also @bernedom asked for this explicitly during our last meeting.

Cool!  I didn't know people needed this.  I decided to fold it into the units-as-types section near the bottom.  I explicitly listed the support from both mp-units and Au for units and dimensions.

Added a unit-aware I/O section near the top.

mp-units also supports "Unit labels available even without <iostream>". See:

https://github.com/mpusz/mp-units/blob/60a564a86700804e306f0d73a1521ea6e4abe377/src/core/include/mp-units/unit.h#L811-L823
https://github.com/mpusz/mp-units/blob/master/test/unit_test/static/unit_symbol_test.cpp

It even works at compile-time wink

Thanks for calling it out!  Added.

BTW, there are also a few points where I disagree with your assessment of AU (or maybe I just do not know enough about it).

Thanks!  It's hard for me to see beyond my own perspective, so I'm grateful that you're sharing yours.

Single header is nice, assuming that it has the same content every time and if it compiles fast. Allowing customization of the contents of this header is, in my opinion, a huge mistake. Consider two vendors using Au with different sets of units and a third one that tries to use the products provided by the former. The same header file in dependencies with different content is asking for problems.

I don't understand how a customized single-header delivery is any worse than having the libraries depend on two different versions of the same library --- which is admittedly a very hard problem, but not one that has much to do with this delivery method.  In fact, assuming the versions are the same, wouldn't it be strictly less bad?  After all, the contents should be either identical or absent relative to the other file: there won't be any conflicting definitions.
(I will say that dependency management outside of a monorepo context is very much not my forte, so I could be missing something obvious.)
I'll also say that, given that we're offering a customizable single-file delivery, I'm really glad that we made a manifest comment part of it from the very beginning.  This comment makes it clear at a glance which precise version was used to generate the file, whether it has <iostream> support included, and which specific units were included.  If there does turn out to be some special problem caused by customizable single files, this should at least make it much easier to fix.

I do not think that extensibility can be marked as good when you need to write multiple lines of code to add one quantity or unit. It is a huge effort on a larger scale. And macros are not welcomed either ;-)

The reason I'm fine with the multi-line setup is that I don't expect new unit definition to be a major part of most users' workflow.  Most missing units should be brought into Au itself via PR, so as time goes on, I expect the units will tend to already be present more and more.  When users do need to define their own named units, they'll typically do so only once per project per unit: it's not part of the normal workflow.  And of course, for unnamed units, they can simply define them inline in a single line: e.g., constexpr auto trinches = inches * mag<3>();.
So, sure, it may be a significant effort on a larger scale, but I don't think a use case for that "larger scale" really exists.
I also think readability matters more than writability for unit definitions.  And I'm not a fan of the readability of a sequence of positional arguments, as one sees in most (all?) unit definition macros.  In fact, come to think of it, I'd even feel more confident about writing a unit definition in Au's style than with a macro if I was forced not to look at the docs!  I understand all the parts and I can reason about what they do.  I can start with a single line definition, and then add the parts for whatever features I want, when I need them.
That said --- I definitely agree that a modern, minimum-C++20 implementation can give us the best of both worlds!  You get more flexibility in your template parameters with NTTPs.  Also, Concepts clarify constraints, cultivating callsite confidence.  That's why I'm glad there's a library like mp-units that's willing to bite the bullet of that steep C++20 requirement, so it can show the way to the interfaces of the future.

Do you think that "No 'preferred' Rep" is a better solution than = double? I could remove the default in mp-units, but I am not so sure if users would be happy about it? Anyway, in V2 we promote 123 * m syntax so during the construction Rep is always explicitly provided by the user. = default is useful in the interfaces (i.e. void foo(quantity<si::metre, double> q) would be too verbose IMHO and double seems to be a good default based on the established practice in other libraries).
I am not sure if "sizeof()-friendly unit label representation" is a killer feature for embedded wink, but in mp-units you can easily get the size of any unit at compile time as well (https://github.com/mpusz/mp-units/blob/master/test/unit_test/static/unit_symbol_test.cpp).

I'll answer these together, because they came from a common source: our actual conversations with embedded developers, who were brought in as first-class clients from the library's inception.
Through working with them, I learned that <iostreams> is an unacceptably huge dependency.  I also learned that const char[] is strongly preferable to const char* (to which the former decays if you but look at it sideways), in part because of the ability to do sizeof() on the unit label.  Our const char[] compatibility through-and-through is one of the small details that I think makes Au the C++ units library with the best real-world track record for embedded support... at least, so far.  :slightly_smiling_face:  I expect that will change as we get more and more mature toolchains that support C++20.
As for no preferred Rep, yes, I think this is important.  The explicit goal there was to avoid making our embedded users second-class citizens: we didn't want one set of APIs for "normal" use cases, and then a separate set for "embedded".  Given that double is very often a notably poor choice in embedded applications, making it the default would make embedded users second-class citizens.
This goal forced us to make our APIs as Rep-agnostic as possible.  I'm really pleased with where this led for QuantityMaker instances: you can call meters(x) on any arithmetic type x, and it'll work just fine!  (Much as with the x * m which mp-units' quantity references permit.)  The main downside is of course naming the types.  I think we've worked around it pretty well in practice with the Rep-named aliases, which get it down to a single letter: QuantityD<Meters> instead of Quantity<Meters>.  I can't say I love this solution as much as the quantity makers, but I think it does the job in practice --- and there's no privilege over the QuantityI32 that I see my embedded colleagues reach for routinely.
That said, I'm not sure that rep-named aliases would work well with the idioms either of mp-units, or of a future std::units library.  I'm genuinely at a loss as to how I'd suggest to spell it.  I think "default double" will win the day, but I feel a little sad about it.

Ohh, and according to my understanding, mp-units is probably the only one that provides a system of quantities where an angle is a strong dimension/quantity. The docs are TBD (they were provided for 0.8.0), but you can find more here:

https://github.com/mpusz/mp-units/blob/master/src/systems/angular/include/mp-units/systems/angular/angular.h
https://github.com/mpusz/mp-units/blob/master/src/systems/isq_angle/include/mp-units/systems/isq_angle/isq_angle.h

Perhaps the only explicit system of quantities.  I do get a little confused by the terms sometimes, but I think Au also has a system of quantities (i.e., our one, implicit system) with angle as a strong type: we have a base dimension called angle.  Maybe we were the first?  I haven't checked.
I think mp-units is the only one which simultaneously supports different systems of quantities with and without strong angles.  This is really neat, and I'm excited to see what the community does with it!
(I guess Au kind of supports both?  But mainly because users can neglect any dimension they're not interested in, which leads to a kind of "don't say radians if you don't mean radians" policy.)

I just thought of possible additional rows to the comparison table:

basic math on quantities (abs, floor, ceil, round, hypot, pow, sqrt, cbrt, exp)
trigonometric functions for angular quantities (could also extend already existing "Angles" row as an additional criteria for comparison)

I can't believe I didn't have a row for math functions --- how on earth did I miss that one?  I've added it as na for now because assessing each individual library is a lot of work, and I want to finish this comment.  :sweat_smile:

one of my users contributed random generators for quantities claiming it is important for their domain as well

I'm pretty wary of that one: it strikes me as being scope creep.  I don't think a units library should be in the business of defining how random numbers are generated.  This is especially true given that mp-units, like Au, has made it so easy to apply units to arbitrary Rep!  I think the right move is to advise a user on how to write a generic function if they need the help, but I expect the library itself is better off without this feature.
We have a similar use case at Aurora, with "fuzz helpers", where we need to generate random quantity values for fuzz testing.  Au has no such concept.  But our generic Aurora-internal implementation is 5 lines of code --- and only so many because of our clang-format settings!  I think this is one feature best left to the end users.

Thanks for the detailed answer. I understand your points, even if I might have other priorities 😉.
One thing that I am not convinced about is the double thing. I fully understand that you do not want to favor one group over the other, but one could argue that you already do. QuantityD is less to type than QuantityI32 😉. Said that any user can create any alias they want for their project. For example,
namespace my_project {

template<mp_units::Reference auto R>
using quantity = mp_units::quantity<R, std::int32_t>;

}

With the above, users have fixed type as needed for their project and they even do not have to prefix the identifier with the mp_units namespace anymore (so less to type). Having double as a default makes the library easy to use at least for some (majority?) of users. The rest may provide a simple alias like above and it will work great for them as well.

Thanks for the detailed answer. I understand your points, even if I might have other priorities wink.
One thing that I am not convinced about is the double thing. I fully understand that you do not want to favor one group over the other, but one could argue that you already do. QuantityD is less to type than QuantityI32 wink. Said that any user can create any alias they want for their project. For example,
namespace my_project {

template<mp_units::Reference auto R>
using quantity = mp_units::quantity<R, std::int32_t>;

}

With the above, users have fixed type as needed for their project and they even do not have to prefix the identifier with the mp_units namespace anymore (so less to type). Having double as a default makes the library easy to use at least for some (majority?) of users. The rest may provide a simple alias like above and it will work great for them as well.

That's true, yes.  I see both sides on this one, and have even held both positions at different times.
Ultimately, I think it's good for there to be a library that explores the region of design space that is radically committed to not favoring any Rep.  Some of the consequences have been unambiguously great, like the quantity maker APIs which are equally usable with any Rep --- I think mp-units is now the only other library with interfaces that match this flexibility.  On the other hand, the consequences for the type names are more ambiguous, although I'm happy that the Rep-named aliases have mitigated most of the pain.
That said, I can see the benefits for other libraries to use a default Rep --- especially if Rep-named aliases would be too hard to spell within the idioms of the library (as I think likely for mp-units and a possible future standard units library).
As for D vs. I32, while I'm definitely keen on minimizing unnecessary typing, I wouldn't call D privileged, any more than I'd say that int is privileged over double for that reason.  Interestingly, the extra characters in I32 are actually a bonus for my target customers!  One thing I've learned is that embedded developers really prefer to be conscious of how many bits they have at their disposal.  Spending a couple extra characters to make this clear at the callsite is a price they're generally very happy to pay. :slightly_smiling_face:


Shell completions

This would be a very nice feature, but requires dynamic completions in clap: https://github.com/clap-rs/clap/issues/1232
We'll want to live-read the config tree on each completion, and fill in:

App names
Profile names

I started a branch that does compile-time completions, but it will no doubt need some updating by the time clap supports this. https://github.com/LucasPickering/env-select/tree/completion
Hopefully the config scan+read process is fast enough that this will Just Work, but we may need to introduce some caching or multi-threading something. We'll see.

Put some more work into this, I think we should wait until https://github.com/clap-rs/clap/issues/3166


Can threading.local() and uWSGI cause unexpected behaviour?

I noticed that threading.local() is used to set and retrieve the current tenant.
There's a discussion here  mentioning threading.local() being shared across threads in uWSGI.
Could this potentially cause unexpected behaviour when serving a django application that is using django-multitenant through uWSGI?

I got the following response from Citus Data's public Slack channel.

I've used thread locals with Django and uWSGI for years, as long as you're careful to set/unset the values on every request it's fine and I don't believe causes the issue suggested in that post. Also using it with django-multitenant with no issues.


Laravel 9 not Supported

Hello,
Is it possible to update the module here to Laravel 9 so that the module runs on the new Laravel version Up to date.

Second this!!

@kaidesu @thekanbo ping :/

C'mon man! Push the support for L9

please email<EMAIL_ADDRESS>directly instead of using the issue tracker.

As it's been a really long time with no contact from the creator, I forked this repository and made (what I think) are the necessary changes here. I followed this guide to use my forked repository, instead of the current version of caffeinated/modules.
Here is the relevant portion of my composer.json (including Laravel 9 required changes):
    "require": {
        "php": "^8.0",
        "caffeinated/modules": "dev-master",
        "spatie/laravel-ignition": "^1.0",
        "laravel/framework": "^9.0",
       //...
    },
    "require-dev": {
        "nunomaduro/collision": "^6.1",
         //...
    },
    "repositories": [
        {
          "type": "git",
          "url": "https://github.com/ctstimjackson/modules.git"
        }
      ],

You're welcome to use my fork or fork yourself. I offer this with zero support. I will not respond to feature requests. - I'm just trying to keep my app up-to-date and would love the creator to continue providing support to such a great project. My hope would be that in the future I can switch back to the caffeinated/modules repo, instead of my forked version.

Really sad, all the caffeinated packages gets abandoned


Modify README to not use local state for any account other than the "terraform" account

🗣 Description
After a discussion with @dav3r, it occurred to me that there is no need to start out with local state for any account other than the "terraform" account when bootstrapping.  One can instead simply configure the backend to temporarily use programmatic credentials for AWSAdministratorAccess as obtained for the COOL "terraform" and "users" accounts from the AWS SSO page.
💭 Motivation and Context
This doesn't greatly reduce the number of steps required to bootstrap the accounts, but it does reduce the cognitive load since the starting state is more similar to the final state.  Therefore I think it's a good change to make.
🧪 Testing
The changes are really just documentation changes, but I did make sure that the pre-commit hooks all passed.
🚥 Types of Changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (causes existing functionality to change)

✅ Checklist

[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.

Thanks to hashicorp/terraform#22103, this idea will not work right now.  Perhaps this PR can be revived in the future.


Ltd 3372 case allocation banner

Aim
The “allocate yourself” banner was showing on case sub-pages, for TAU, advice, and notes, even after you have allocated yourself to a case.
This was happening because the rule in the case template checking whether that banner should render needed the user in the context.
This PR adds the user to the different pages contexts. I'm not sure that I've covered all the different places it might need to be in... I'm also wondering if there were a more centralised way to add the user in the context.
Link to story

I'm also wondering if there were a more centralised way to add the user in the context.

Great question.  Django has a thing called context processors which allow a more global way to inject things in to template context...  And if we look at the ones already set up for the caseworker app it seems like there might already be one that fits the bill for this; https://github.com/uktrade/lite-frontend/blob/dev/conf/caseworker.py#L51

closing to open another branch


Add severity support for vso formatter

PR checklist

[x] Addresses an existing issue: #4248
[x] New feature, bugfix, or enhancement

[x] Includes tests

[ ] Documentation update

Overview of change:
Updated the vso formatter to include the severity of the failure.
(Severity warning was hard-coded)

Thanks for your interest in palantir/tslint, @pfoedermayr! Before we can accept your pull request, you need to sign our contributor license agreement - just visit https://cla.palantir.com/ and follow the instructions. Once you sign, I'll automatically update this pull request.

I appreciate that this may be a breaking change and may have to wait until a major version release, but is there any timeframe of when this may be added?
We have been able to workaround this by piping output to a separate script which logs vso commands with the correct severity based on ERROR/WARNING report from tslint. This works, but obviously an official solution would be preferred.

Removing the Type: Breaking Change label per #4811. Now ready to merge! (once the CircleCI build unfreezes...)

Hmm, @adidahiya - any idea how to get this build restarted? I don't have permissions to merge.

ci/circleci: clean-lockfile

😢


Update README.md

Added a line with a link to the live website.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


refactor: replace declaration files with JSDoc comments

This a more elegant alternative to #285.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

6 of 6 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.04%) to 89.727%

Totals

Change from base Build<PHONE_NUMBER>:
0.04%

Covered Lines:
1072

Relevant Lines:
1163

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

6 of 6 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.04%) to 89.727%

Totals

Change from base Build<PHONE_NUMBER>:
0.04%

Covered Lines:
1072

Relevant Lines:
1163

💛  - Coveralls

I think the JSDoc approach is more maintainable since it put the type definition closer to the code. Sadly, I did not have the experience with porting a JS project to TS. I would say that this is the right direction though.

I think the JSDoc approach is more maintainable since it put the type definition closer to the code. Sadly, I did not have the experience with porting a JS project to TS. I would say that this is the right direction though.

Awesome, thanks for the feedback! :) I think I actually found a setup that offers the best of both worlds, keeping the project structure mostly as it is while providing strict(er) type checking based on the JSDoc comments. I need to add a couple of commits then this PR will be able to be merged :)

With the exception of some cleanup this PR should now be finally finished :) It should provide typing support for the whole project now. Unfortunately, this isn't possible without having some kind of compilation step as JSDoc comments are only parsed if depending Typescript have a value > 0 for maxNodeModuleJsDepth which should not be the case too often. I therefore added a .ts file back and let tsc compile the whole project before testing and publishing.
In the process of working on this PR I noticed that there is an incorrect type definition for the bl module. I opened https://github.com/DefinitelyTyped/DefinitelyTyped/pull/56130 to this fix issue. Once it is merged, this PR will be ready to be merged as well.


Configure Local Plans Delivery Fund

Superseded by https://github.com/communitiesuk/funding-service-pre-award-stores/pull/45


Do not include ineffectual constraints in hash

When SolveParameters.RootManifest contains a ProjectConstraint for a project that is present in any of the imports described in SolveParameters.RootPackageTree, that ProjectConstraint should not be included when computing the input hash, as it will have no bearing on the solver, and thus is equivalent to not being present at all. As a rule, we try to reduce all cases that we can determine will not bear on solving to the same base/zero case, in order to minimize the possibility of spurious hash conflicts.

Fixed in #139

Not actually done yet, see #143

done again/actually now


Relax error FS0208: --target:exe require .exe extension

if i try to compile with
fsc --target:exe Program.fs --out:prova.notexe
i get error FS0208
error FS0208: The output name extension doesn't match the options used.
If '-a' or '--target:library' is used the output file name must end with '.dll',
if '--target:module' is used the output extension must be '.netmodule',
otherwise '.exe'.

that's a problem because dotnet cli ( the old dnx ) compile to .dll instead of .exe
Is possibile to remove this error completly? We can disable it ( with --nowarn maybe ) but is not really useful
bonus point: remove it from coreclr branch first, so i can remove the workaround from dotnet cli

Yes we can remove it from the compiler, it is not really a useful restriction.

I will take care of it over Christmas.

good :smile:

I get an error on this with the latest dotnet CLI on linux. Can't wait for Ionide, F#, and friends to be stable for CoreCLR on linux(C# for that matter too).

@ProTip what version of cli ( dotnet --version or dotnet --info if supported )

$ dotnet --version
.NET Command Line Tools (1.0.0-beta-001793)

Product Information:
 Version:     1.0.0-beta-001793
 Commit Sha:  42a0eec967

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  14.04
 OS Platform: Linux
 Runtime Id:  ubuntu.14.04-x64

I could be throwing you for a loop here(unrelated issue). This is what I get:
$ dotnet build
Compiling fsharp for .NETStandardApp,Version=v1.5
/usr/share/dotnet/bin/dotnet compile-fsc @/home/gzapp/projects/fsharp/obj/Debug/netstandardapp1.5/dotnet-compile.rsp returned Exit Code 1
/home/gzapp/projects/fsharp/error FS0208: The output name extension doesn't match the options used. If '-a' or '--target:library' is used the output file name must end with '.dll', if '--target:module' is used the output extension must be '.netmodule', otherwise '.exe'.

in that version of .net cli, f# doesnt support netstandardapp1.5, and it's trying to compile without --profile: netcore
if you do dotnet --verbose build you can see arguments ( or check .rsp file in obj/Debug/netstandard1.5/dotnet-compile-fsc.rsp )
**You can try version version 1.0.0-beta-002071 **, that should work ( see https://github.com/enricosada/fsharp-dotnet-cli-samples/wiki/Status )

can we close this?

yes @dsyme, i see it working locally (.net core preview2, so latest compiler).
i think the fix is in commit 79165ef4318e30bb81200ecb910660aa28a2b733 in pr #1159


DSAChecker.VerifySignatureOfFile() needs to catch errors

In production we are seeing a lot of crash reports here. 100% of the time the unhandled exception is caused by the downloaded installer file be held open for some reason. So, when called in SparkleUpdater.InitAndBeginDownload() the exception causes a crash of the app.
The fix, I believe is to wrap the file calls in a try/catch block and return ValidationResult.Invalid if the file cannot be opened. This way at least a re-download will be attempted and if that fails, an error path is followed.
   public ValidationResult VerifySignatureOfFile(       string signature,       string binaryPath)     {       using (Stream stream = (Stream) File.OpenRead(binaryPath))         return this.VerifySignature(signature, Utilities.ConvertStreamToByteArray(stream));     }
I worked around the issue for now by creating my own ISignatureVerifier class based on the DSAChecker class where the only difference is try/catch noted above.

@anti-matter Hi! Thanks for the bug report. Instead of fixing this in the signature verifiers, I did this try/catch in SparkleUpdater instead so that all ISignatureVerifier types would have their errors caught. The exception is logged via LogWriter.
You don't happen to know if the root cause is some antivirus software running or something, do you? O_o
In any case, thanks for the report, and you can use 2.0.0-preview20200906001 once the CI/CD finishes

Better yet, use 2.0.0-preview20200906002 and then you'll have an event called DownloadedFileThrewWhileCheckingSignature that will be called if the signature verifier throws while verifying a signature after download. :)
....it's not a perfect solution, but I'm trying not to have any more seriously breaking changes between now and 2.0.


40_43 strong types in example

Issues
https://github.com/exercism/dart/issues/40
Updating tests for Dart hamming distance example.

@jerold Just checking in, how do you feel about my feedback?

@Stargator Sorry about the delay. I was out of town last weekend.  I'm going to clean this up today.

@jerold No worries. Thanks for remembering us 😸

@Stargator restored the previous set of tests and implemented the 6 you've asked for. Run the new tests against the example hamming implementation and all pass. Ready for re-review.

@Stargator Sorry for the churn. The previous commit by itself may look a little confusing. I effectively undid the previous commit (where I'd reordered/renamed the tests to exactly match the canonical-data.json file). Looking at the diff for the whole pr currently should show 6 tests added:

[ ] empty strands
[ ] non-unique character in first strand
[ ] non-unique character in second strand
[ ] same nucleotides in different positions
[ ] disallow first strand longer
[ ] disallow second strand longer

Do you mean to say the bottom 5 of those should be skipped, or should all tests in the file, minus the top test be skipped? Are these tests brought online one by one somehow as the coder works on their implementation? I'm curious what the process is for these tests that required them to be skipped initially? Are these part of multi-part tutorial?

@jerold The tests should be done one at a time. Generally, the top test is the first test (we don't skip the first test). Then all the tests that follow it will be appended with }, skip: true);

should all tests in the file, minus the top test be skipped?

Yes
The process is that we are signalling to the user that the first problem for them is the only test that is failing, the first test. Then they solve that problem by passing the first test.
Then they stop skipping the second test, see that it fails and work to resolve it. Then repeat the cycle until all the tests pass.

@Stargator give this a look. I've translated the full test suite described in canonical-data.json to dart tests. Each test has a counterpart. Same descriptions, cases, expectations. The diff is a little ugly, but take a look at the current raw test file next to canonical, and I think you'll like it. Otherwise I can revert, but in that case I would think a change really should be made to canonical first, and the tests then made to match here in hamming_test.dart.

@jerold Understood. But do understand, we don't have to follow the canonical-data 1 to 1.
So I opened a PR in the problem-specifications https://github.com/exercism/problem-specifications/pull/953, feel free to comment.


Use route URI for transaction when missing name

Aside I'm not 100% sure transaction route names are working in 5.1

updated, and confirmed it works in 5.1 (woo!)


Dose the network use depth pre-training?

Hello,
I'd like to ask whether the network is pre-trained on a depth dataset.
Thanks.

No, the network is not pre-trained on any depth dataset. The dla backbone is pre-trained on imagenet.


added db connection and tested

#6  👈
master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @mAmineChniti and the rest of your teammates on  Graphite


[HIP] Reclaim hipLaunchKernel API

Reclaiming the old deprecated hipLaunchKernel symbol to implement hipLaunchKernel that matches cudaLaunchKernel signature.

@SarbojitAMD Can you add the test case - don't enable the HIT option for now.

Comment from @SarbojitAMD :-
Note: As of now hipLaunchKernel takes one extra argument i.e. kernel arg size, compare to cudaLaunchKernel API which I am trying to find a way to get rid of. Once found working solution will remove it.
Testing : I have manually tested with different arguments but could not enable automated tests as we need to have some infrastructure fix once done should be able to enable automated tests.

@gargrahul, I have updated test files as you asked. Let me know if you feel any particular scenario needs to be covered.

I am closing this PR as I have incorporated all review comments and initiated a fresh PR #1353
Need to close this as I have by mistake raised the PR on my forked master branch.


Minor correction to how-pulumi-works

Proposed changes

Make a single correction to what appears to be an incorrect work, replacing "exists" with "exits".
Unreleased product version (optional)

Related issues (optional)

Thanks!


Added variable timer for play pos notification, RN_TRACK_CHANGE setter

Hi @pschatzmann !
The set_avrc_rn_play_pos_callback was hardcoded to output notifications every 10s. Some may want faster playing position notifications (for example, one project I am working one requires notifications closer to 1s) so I introduced a new property to BluetoothA2DPSink call notif_interval_s and an overload of the set_avrc_rn_play_pos_callback method.
Then I got carried away and also added a wrapper for RN_TRACK_CHANGE and an example. I'm not sure if there is anything else than elm_id = 0b0000001 as a possible outcome, but at least it's there, including with an example.

Thanks a lot for your contribution.
I would actually prefer to keep only one setter method instead of 2. Can you delete the old one and add a default value for the time on your version ?

Thanks a lot for your contribution.
I would actually prefer to keep only one setter method instead of 2. Can you delete the old one and add a default value for the time on your version ?

Much welcome ! I actually updated the Pull request with another wrapper as you were probably writing your comment, for the TRACK_CHANGE notification.
Will delete the old setter and update the examples.

Thanks a lot for your contribution.
I would actually prefer to keep only one version of the set_avrc_rn_play_pos_callback setter method instead of 2. Can you delete the old one and add a default value for the time on your version ?

Should be done now ! Let me know.


IndexError: index 3 is out of bounds for axis 2 with size 3

Hi there,
Thank you for writing this, I have been trying it and it's been working mostly well.
I have encountered this error while trying to run impute.py:
$  impute.py --bgen /path/to/data.chr_@ --ibd<EMAIL_ADDRESS>--king /path/to/king.kin0 --agesex /path/to/agesex.txt --threads 28 --out /path/to/out.@ --chr_range 1-22
2023-05-26 07:48:53,587 INFO impute - main: creating pedigree ...
2023-05-26 07:48:53,827 INFO preprocess_data - create_pedigree: loaded kinship file
2023-05-26 07:48:54,634 INFO preprocess_data - create_pedigree: loaded agesex file
2023-05-26 07:48:54,672 INFO preprocess_data - create_pedigree: creating age and sex dictionaries
2023-05-26 07:48:55,513 INFO preprocess_data - create_pedigree: dictionaries created
2023-05-26 07:48:55,514 INFO preprocess_data - create_pedigree: creating pedigree objects
2023-05-26 07:48:56,003 INFO impute - main: pedigree loaded.
2023-05-26 07:48:56,003 INFO impute - run_imputation: processing /path/to/data.chr_1,None
2023-05-26 07:48:56,003 INFO preprocess_data - prepare_data: For file /path/to/data.chr_1;None: Finding which chromosomes
2023-05-26 07:48:56,226 INFO preprocess_data - prepare_data: with chromosomes [1] initializing non_gts data
2023-05-26 07:48:56,226 INFO preprocess_data - prepare_data: with chromosomes [1] loading and filtering pedigree file ...
2023-05-26 07:48:56,910 INFO preprocess_data - prepare_data: with chromosomes [1] loading bim file ...
2023-05-26 07:48:56,910 INFO preprocess_data - prepare_data: with chromosomes [1] loading and transforming ibd file ...
2023-05-26 07:48:58,911 INFO preprocess_data - prepare_data: ibd loaded.
2023-05-26 07:48:58,911 INFO preprocess_data - prepare_data: with chromosomes ['1'] initializing non_gts data done ...
2023-05-26 07:48:58,994 INFO preprocess_data - prepare_gts: with chromosomes ['1'] initializing gts data with start=0 end=82
Traceback (most recent call last):
  File "/mnt/storage/home/my_username/scratch/.conda/envs/snipar/bin/impute.py", line 419, in <module>
    main(args)
  File "/mnt/storage/home/my_username/scratch/.conda/envs/snipar/bin/impute.py", line 313, in main
    run_imputation(args)
  File "/mnt/storage/home/my_username/scratch/.conda/envs/snipar/bin/impute.py", line 195, in run_imputation
    phased_gts, unphased_gts, iid_to_bed_index, pos, freqs, hdf5_output_dict = prepare_gts(phased_address, unphased_address, bim, pedigree_output, ped_ids, chromosomes, start, end, pcs, pc_ids, find_optimal_pc)
  File "/mnt/storage/home/my_username/scratch/.conda/envs/snipar/lib/python3.9/site-packages/snipar/imputation/preprocess_data.py", line 710, in prepare_gts
    phased_gts[probs[:,:,3] > 0.99, 1] = 0
IndexError: index 3 is out of bounds for axis 2 with size 3

I am using a subset of the original phased data (in .bgen) for the imputation, and I estimated the IBD segments on a separate set of genotyped data (with the same IDs).
I tried to replicate this issue on the original files; unfortunately, they're too big to fit in memory.
What am I doing wrong?
Thank you in advance and sorry if it's trivial!

Just noticed that the starting files I was using did not have phase information for some reason, so that explains the error message

Thanks, Guilio, let me know if you need any further assistance.


Enhancement: Adding handlePastedText handler to handle pasted text in…

As discussed in the issue #195, adding handlePastedText handler to handle pasted text in Editor and removing nullThrows import (unused) to fix lint warning.

Thanks!
It occurs to me that we may also want to make the raw HTML available to the paste handler. It's a risk, though, since that would mean that one wouldn't be able to benefit from internal clipboard detection. Plus, of course, parsing HTML into Draft data structures is not an easy task.
I think what you have here is definitely the right thing to do, but curious to get @CLowbrow's thoughts on HTML before importing the PR.

Sure. This use case of passing the raw HTML did not occur to me. But yes parsing the HTML limits the use case.

How about:  we expose one handlePaste prop that takes a function that takes two nullable arguments: text, and html. User can examine both objects. If they return false, we don't do anything. If they return true, we do our regular song and dance to see if there is an internal clipboard/html to use.

If we want to be extra aggro we can prepend <img src="#" onerror="console.error('YOU ARE HANDLING PASTED HTML IN A BAD WAY')"> to pasted html, but that doesn't seem necessary.

+1 for access to the raw text before parsing - my current use case for this would be removing formatting but retaining new lines/converting 's in content pasted into a  area.
In the scenario where i'm pasting text within the same document, from styled text into a code block, does this complicate things? Is the inter-document paste already parsed?

So if you intercept at this point, it will not be aware of the internal paste.

Cool

we expose one handlePaste prop that takes a function that takes two nullable arguments: text and html

That sounds like a good solution, best of both worlds

@hingermayank Want to update the PR to provide both html and text?

@facebook-github-bot import


typo in pool.move docs in examples/defi

https://github.com/MystenLabs/sui/blob/b8ace6ff5e3045f6e3fdd9a7ff076dfd2c236a61/sui_programmability/examples/defi/sources/pool.move#L77-L78
This is wrong, it should be /// that 10000 is 100% and 1 is 0.01%

resubmitting with Issue template


Add Label Encoding

The machine learning algorithms in the major python machine learning framework scikit-learn cannot handle nominal values by themselve, but need a encoded labels (see here. Because this can be easily done at encoding time, and natively supports missing values, I added such functionality. If you consider this useful for others, please tell me and I will add documentation.

Thanks Matthias, It will be great to have this documented (if possible, with examples using scikit-learn). If you do that, I close the 2.0.2 and update the library on pypi.

Thanks for merging this, I was not sure if this would be helpful for anyone except me. I'm pretty busy right now, but I hope I can do this next week. Also, right now I am not sure what happens if you try to dump an arff object with encoded labels. I will figure that out, too.

It is useful, specially when we are working with other libraries (most of the time). No need to hurry, next week is fine.
Yeah, would be cool to expand this process to dump. Right now, to dump the encoded labels you have to change the attributes to follow the new encoded classes, losing the original information.


[Fix #7733] Fix rubocop-junit-formatter imcompatibility XML

Summary
Fixes #7733.
This PR fixes rubocop-junit-formatter imcompatibility XML for JUnit formatter
The original rubocop-junit-formatter displayed all cops with or without offenses.
https://github.com/mikian/rubocop-junit-formatter/blob/v0.1.4/lib/rubocop/formatter/junit_formatter.rb#L9
It then displays all cops in XML elements, like the original rubocop-junit-formatter.
Other Information
In the future, it would be preferable to display only enabled cops.
https://github.com/mikian/rubocop-junit-formatter/blob/v0.1.4/lib/rubocop/formatter/junit_formatter.rb#L7-L8

Before submitting the PR make sure the following are checked:

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

Thanks!


[Song select] Genre folder specific Background

Add the possibility on box.def to add a background directly on a genre folder, would allow custom pack makers to bundle backgrounds with their packs without depending on a skin

Added #447


Bring iproj support into base

Right now, iproj support only exists in the makefile generation to get the list of include paths, but we actually need this in the base for include resolving.

I wanted to meet with you on that.  I.e have the Code 4 i LSPs respect the includePath.  Thanks for being ahead of the curve again.

@edmundreinhardt Code for IBM i already supports includePaths in iproj! But, Source Orbit does not.

Closing as I didn't provide enough context here.

The issue is that the RPG (and COBOL etc) LSPs do not respect the includePath specified in the iproj.json
@worksofliam


chore: remove projects entrypoint from kai

Current dependencies on/for this PR:

main

PR #2237

PR #2238

PR #2239   👈

This comment was auto-generated by Graphite.

⏳ This pull request is set to merge as part of a Graphite merge job
Stack job ID: YPzuXEnO1y4hlJLWNOv8.
See details on graphite.dev


Correct parameter info

@event_value correct name: @events_value
@level_description correct data type to nvarchar(max)

@pkral : Thanks for your contribution! The author, @douglaslMS, has been notified to review your proposed change.

#sign-off


Prepare for new release of Bitbucket

Workflow links: https://github.com/atlassian-labs/atlassian-slack-integration-server/actions/runs/794875867, https://github.com/atlassian-labs/atlassian-slack-integration-server/actions/runs/794876758.

Addressed in #116


[doc build] Use secrets

Companion pr to https://github.com/huggingface/doc-builder/pull/379
Please feel free to merge it yourself

Thanks for the fix!


Limiting parallelism to a max of 4 is overly constrictive

While heavy-duty users should be connecting Seahorse to a cluster, a lot can be done with it in local mode. The biggest impediment to this in our use cases is the artificial limitation on parallelism that Seahorse preemptively places on a user:
This code:
https://github.com/deepsense-ai/seahorse/blob/868b1a8563c9bcd973b95a44de4510109ead9622/sessionmanager/src/main/scala/ai/deepsense/sessionmanager/service/sessionspawner/sparklauncher/clusters/LocalSparkLauncher.scala#L55-L64
The user should be given the freedom to determine resource usage themselves, setting spark.default.parallelism through the "Custom Settings" box should they need to limit Spark.

Resolved by https://github.com/deepsense-ai/seahorse/pull/93
Add --conf spark.default.parallelism=N in local cluster settings


Switch Dockerfile build to a static golang build

The current build process does not create static go binaries resulting
in binaries that reuse libraries from the base container. When running
this container in GCP, this results in TLS not working (reports
mismatched ciphers between server and agent).

/hold

/hold cancel

/cherry-pick release-4.11


Failed to use --fp16 and --use_dml_attn simultaneously in Whisper pytorch-directml

I tried to run Whisper with torch-directml. It can run with either --fp16 flag or --use_dml_attn flag. However, I want to run with both flags. It failed with the following information:

@XciciciX Thank you for reporting this issue. Could you please try with the latest Whisper sample? Multilingual models preserve past_key_value tensors when detecting language which causes the parameter to be incorrect when running transcription inference on audio. The sample has been updated to remove DML attention in AudioEncoder as there's no significant perf gains in the encoder


Display/edit unlisted addons through the devhub (bug 1144676)

Fixes bug 1144676
This PR is based on PR #479, only the last commit is relevant to this bug

r+with travis


Share to story gives black image

Plugin version: 0.5.6
Ionic version: 2.2.1
Cordova version: 6.5.0
Test device: Google Pixel (1)
Test device OS: Android 8.1.0 Oreo
Instagram version: <IP_ADDRESS>.92
When invoking share I get brought to the Instagram app, but a black image is loaded and not the actual picture that should have been shared. The same share flow and same image works when sharing it as a regular post. Both story and regular post sharing works on iPhone5 iOS 10.3.3.

As far as I know the sharing to story isn't part of this spec. Your phone is giving you the option because of instagram but that's something out of control of this lib.


MAINT,CI: signal: fix failing refguide check

Reference issue
fixes #15692
What does this implement/fix?
np.seterr prints a status in new releases which caused the refguide check to fail. This PR fixes those failures.

Minor, optional, non-blocking: While you're at it, maybe use a context manager instead
with np.errstate(divide='ignore'):
   ...

As discussed in the other issue, if you have a better exemple in mind that would not require this that would be better. I proposed something but did not get a feedback so I am not sure (never used this).

I think it could be done in a follow-up. For now, it would be nice to have CI green again.

LGTM now

Can you folks reproduce this locally? I couldn't with NumPy 1.21.5 which refguide is using I think

Not to block this PR but can you folks reproduce this locally? I couldn't with NumPy 1.21.5 which refguide is using I think

These kind of floating point errors are unfortunately not always portable, so it doesn't just depend on numpy version.

True but FFT result shouldn't be that far off to get away  from zero

I too am not able to reproduce it locally. I have removed np.errstate. Let's see if the CI is happy with it.

One timeout notwithstanding, the CI is happy with this! Feel free to merge if this looks good to you @tupui!

One timeout notwithstanding, the CI is happy with this! Feel free to merge if this looks good to you @tupui!

I am not sure, if we do then we should leave an issue open to track it because we added this in the first place after noticing some instabilities there.
I would instead do this window = signal.windows.cosine(51)[1:-1] as a bandaid, as I proposed in the previous issue, but better confirm this with @ilayn

I am not sure, if we do then we should leave an issue open to track it because we added this in the first place after noticing some instabilities there.

Oh OK, I wasn't aware about that. Looking at the blame, I see you submitted #15649 (can't find the issue where this was discussed). I can revert the last commit in that case.

My apologies @tupui for missing out the previous pings in that issue. So as far as I understand it started with #15327 then we fixed bunch of stuff and then things kind of disappeared. If none of us is able to repro then this is probably a fluke otherwise I don't see why this should pop up because hitting exact 0. is very unlikely.

No worries :)
As you wish, as I said it's really not my area so would rely on your judgment. Feel free to merge if you think this is fine as it is.

Let's get this in and if the problem comes back, I'll fix the examples quickly. Thanks all!


Patch 2022 08 10

upgrade to the newer Gradle version > 7.0

Hi @renatoathaydes ,
This is great news. I couldn't publish a copy of your plugin, because they want me to maintain the existing plugin. This just solves my problem. Your plugin would be great if it worked with the newest version of Gradle. There is some incompatibility which I fixed. It looks good to me.
Speaking of SDKMAN unpublished older versions, this is why I keep a backup of all versions locally, and I bring them to every project I work on :) If you would like to have some, I will gladly share it with you. I put all the java versions in private repositories for all developers and all CI pipelines will have this java version baked into the docker images. This is how I solve this. Besides, each Developer can pull the docker image directly and extract the JDK from there. Clearly, if I don’t have the latest/given JDK, you cannot run the pipeline, but this is ok. The CI/CD pipeline should work with the same JDK as it was developed with. If you don’t have it, it means that you cannot maintain the project with this version and you need to change the .sdkmanrc file. This is just my opinion. I loved your plugin and the idea behind it is great. If someone doesn’t like it, can simply disable it. This will be very easy to do, so it can only bring benefits to the project :)
I would love to maintain this project :)
How can I take over the repository?
Would you also be that kind and share access to the website that you created? It looks really good but add a few things here and there, for example new Gradle version, etc…
I am new to opensource, so I don’t know how this really works. Could you just give me the admin rights to the git repository so I can merge everything myself?
With regards,
Lukasz

Hi Renato,
This is great news. I couldn't publish a copy of your plugin, because they want me to maintain the existing plugin. This just solves my problem. Your plugin would be great if it worked with the newest version of Gradle. There is some incompatibility which I fixed. It looks good to me.
Speaking of SDKMAN unpublished older versions, this is why I keep a backup of all versions locally, and I bring them to every project I work on :) If you would like to have some, I will gladly share it with you. I put all the java versions in private repositories for all developers and all CI pipelines will have this java version baked into the docker images. This is how I solve this. Besides, each Developer can pull the docker image directly and extract the JDK from there. Clearly, if I don’t have the latest/given JDK, you cannot run the pipeline, but this is ok. The CI/CD pipeline should work with the same JDK as it was developed with. If you don’t have it, it means that you cannot maintain the project with this version and you need to change the .sdkmanrc file. This is just my opinion. I loved your plugin and the idea behind it is great. If someone doesn’t like it, can simply disable it. This will be very easy to do, so it can only bring benefits to the project :)
I would love to maintain this project :)
How can I take over the repository?
Would you also be that kind and share access to the website that you created? It looks really good but add a few things here and there, for example new Gradle version, etc…
I am new to opensource, so I don’t know how this really works. Could you just give me the admin rights to the git repository so I can merge everything myself?
With regards,
Lukasz

On 23. Aug 2022, at 21:14, Renato Athaydes @.***> wrote:
Hi @lukaszochmanski https://github.com/lukaszochmanski . Feel free to take over this project if you find it useful.
I gave up because SDKMAN unpublishes older versions of SDKs all the time so it just broke CI a lot.
You could make it work, still, if you just tried to find the latest version of a SDK you can use for a certain config, but doing that would be a bit guesswork and would make CI unstable , which in my opinion is a dealbreaker.
So I am not maintaining this or using this anymore.
—
Reply to this email directly, view it on GitHub https://github.com/renatoathaydes/sdkman-gradle-plugin/pull/2#issuecomment-1224661603, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2EAXCW24YVKTIJ6KUDQZP3V2UPJPANCNFSM56ET2CNA.
You are receiving this because you were mentioned.

Hi Lukasz,
I can transfer the project to you but you need to delete your fork first.
By the way, while I don't mind you forked the project and changed my name everywhere with yours, this would be considered bad manners usually, as it looks as if you're stealing credit for the project.
If you wanted to just contribute to the project, you should make small changes from your fork and submit them as pull requests.
But as I don't have interest in this project anymore, I am willing to transfer everything to your name as long as you promise not to do anything malicious in the code, like add advertising, install unnecessary libraries and anything of that nature.
The website was created using a small static generator I wrote, Magnanimous. Should be easy for you to change the contents as it's all markdown with a custom template language (well documented on the website I linked) for generating dynamic content. And there's a few HTML and CSS files that get thrown together with the HTML generated from markdown, hopefully easy to "get" it.

With that said, It's not unusual for forks to take over from the original, unmaintained project...
It would actually prefer if you just kept developing on your own fork, actually.
I can archive this project and add a link in the README to your project... I think that would be more appropriate than transferring the repo.
The website is currently deployed on my personal GitHub account , so I cannot transfer the same URL to you, but you can easily publish the website on your own account or some new org to avoid this problem again in the future.
The Gradle plugin ID is also on my personal name (id "com.athaydes.sdkman"), so it just doesn't make sense for me to transfer that to you. Please change the Gradle ID and the Maven coordinates.
Does that work, you think?

hi Renato,
I already went through all of this. I agree to the second idea. Here is how it went:
First I wanted to fork it. Then I realized, that there is no way that someone will agree to review all those changes. I am going to make mistakes and there will be some bugFixes on a way. Therefore, I decided to copy your code and put it in my own repo. The problem was the package name and the group ID which they should match. My group id must be the same as my gradle plugin respository account. As you said it makes no sense to publish your name under my account. It will simply look, like your code was stolen. I changed everything locally and I pushed it into my git repository. Then I started to read the documentation, and that I will not be allowed to publish this plugin because it was based on some other plugin that is similar. The only way to make it work, is if I get written confirmation from the author of the plugin that the project is archived and not maintained any more. I went back and forth a few time, fork, clone, fork, clone. I gave up... and then you emailed me! Now there is hope :-)
I would honestly prefer option 2. I will be much faster if I own the repo. Once I finish coding, you could add some note to README.md that this project was transfered. I will do this as well on my side, so there is full transparency. I will add acknowledgments to the README.md that you were the original author of this project and that I had to change to group because this is how my account is called in Gradle Plugin Repository. I knew that this renaming looks bad. I was just experimenting with it. If I had left your name in the group, the chance that I would get permission to publish the plugin would be close to zero. I tried to remove your name so that they just let me do it. At the end I just got annoyed with it and I stopped. All your commits will be in Git history so this will acknowledge that you are the true author of the code. All I need from you is a short message that you 1. will not maintain this project. 2. you are going to archive it, 3. you allow me to use your code, and that we both decided not to work in one repository. We agreed that I will work on a separate fork, and my plugin should be published and used, with a new name, instead of the old one.
This is the right way of doing it. If you shoot me an email to<EMAIL_ADDRESS>I will be able to take it from there and forward this email to the Gradle team for the review.
Thank you very much for your time and effort. I really appreciate.
Let me know what you think.
Lukasz

and I also need the website. Where can I find the source code for it?

I will do that soon. The website is in the website directory :).
To build it:
cd website
magnanimous

Configure GitHub Pages to deploy from the website/target directory (where the built website will be located after building).

Oh, and once website/target exists, you can try it locally by using some webserver to serve that directory, it's just a static website.


Lower MSRV to 1.75

Change Summary
Lower MSRV to 1.75. Rust 1.75 is the lowest working Rust version.
Related issue number
fix: #1315
Checklist

[ ] Unit tests for the changes exist
[ ] Documentation reflects the changes where applicable
[ ] Pydantic tests pass with this pydantic-core (except for expected changes)
[x] My PR is ready to review, please add a comment including the phrase "please review" to assign reviewers

please review
MSRV is not mentioned in README.md and there are no tests beyond the "test MSRV" job. Lowering MSRV should not have an impact on pydantic tests, either.


support migration for sqlite

can we use migrations in sqlite? (i mean Once we have changed the database, we can update it without losing any data)

Duplicate of #329


Notebook null ref error after cancelling a query

Versions : 1.13.1 (current stable) and current insiders

Start running query
Immediately cancel
Get this message in the output pane

I can't repro this right this second, but I'd be shocked if it's a regression from a recent month. Because of that, moving to planning.

Yeah interesting, I can't seem to repro it either. Odd. Anyways I'll close this for now and if I see it again I'll let you know.


Validate that provided geo_ids match expectations

Tracking bug for item in plans.md: Which, if any, specific geo_ids are missing (get unique geo ids from historical data or delphi_utils)
Currently, we only check that geo_ids are in the correct format.
There are 2 categories of issues that should be addressed:

If the data contains geo_ids that do not match any known values
If the data is missing known geo_ids

The first case should probably be an error, since it suggests a typo or otherwise bad data is being ingested.
The second case should be a warning, since missing data can legitimately occur if it is not reported to our upstream data sources.

I am currently working on this on a forked branch.
Can somebody add me as assignee? it looks like I don't have permission in this repo.

PR #470 addresses category 1 (alert on new geo_ids).
@nmdefries Creating an alert for category 2 (missing geo_ids) may be too noisy. We would potentially need a different list for every data source / signal combination and some of those are much less consistent. For example, the number of counties we get survey data from each day fluctuates. I'd suggest deprioritizing this (unless this is a frequent cause of issues).

That make sense. It may be that this would only be useful at higher geo-levels, like states, where we can reasonably expect data to be available every day. The only relevant bug I'm aware of is #179.


WebSocket adapters

It would be great to extract the websocket functionality to use a proper adapter pattern.
Right now there's a stub of an adapter which just returns a socket.io instance.
Ideally:

Wrap any websocket functionality in an adapter
Call that in nest side code

This lets socket.io be potentially swapped out for alternatives, without breaking changes.

uWebSockets should be better than socket.io, IMO

Socket.io is familiar to most of the Angular community of which Nest has it's roots. I don't disagree that uWebSockets outperforms socket.io at scale but imo Nest shouldn't make choices like that for consumers.
As @ProbablePrime said above, make it pluggable, support what makes sense & allow consumers to make their own tooling choices.

Hi @ProbablePrime,
Since latest update you should be able to use custom socket.io adapter. Example:
import { SocketIoAdapter } from '@nestjs/common';

class CustomAdapter implements SocketIoAdapter {
    create(port: number) {
        return {};
    }
    createWithNamespace(port: number, namespace: string) {
        return {};
    }
}

const app = NestFactory.create(ApplicationModule, instance);
app.setIoAdapter(new CustomAdapter());

@kamilmysliwiec I don't think this addresses the issue.
The issue is asking for a way to replace Socket.io completely. Right now this appears to just require an adapter to return Socket.io instances.

@kamilmysliwiec will be this #80 pr merged in a few days?

@cojack, yes

This looks a lot better \o/ thanks! doing a more indepth read of your changes but i will close it most likely

Hi @ProbablePrime,
Since 3.0.0 you can create adapter for any ws library. Read more

Yep PERFECT. thanks!


Register Contract API for Fabric Stack fails with 400 Bad Request Error.

This is the failure I see. Cutting and pasting from the Server Response:
{

"name"
:
"BadRequestError"
,

"message"
:
"Invalid body, check 'errors' property for more info."
,

"stack"
:
"Error\n    at new HttpError (/app/server/node_modules/routing-controllers/cjs/http-error/HttpError.js:17:22)\n    at new BadRequestError (/app/server/node_modules/routing-controllers/cjs/http-error/BadRequestError.js:10:9)\n    at /app/server/node_modules/routing-controllers/cjs/ActionParameterHandler.js:206:31\n    at processTicksAndRejections (node:internal/process/task_queues:96:5)\n    at async ActionParameterHandler.normalizeParamValue (/app/server/node_modules/routing-controllers/cjs/ActionParameterHandler.js:126:21)\n    at async Promise.all (index 0)"
,

"errors"
: [
  {

"target"
: {

"name"
:
"assetTransfer"
,

"interfaceName"
:
"asset_transfer"
,

"interfaceVersion"
:
"1.0"
,

"chaincode"
:
"asset_transfer"
,

"channel"
:
"firefly"

   },

"property"
:
"address"
,

"children"
: [],

"constraints"
: {

"isString"
:
"address must be a string"

   }
  }
 ]
}

The API creation succeeds with postman. The FFI is the one used in the draft tutorial document. The contract was deployed with the CLI.

#91


mouse still affected by raw accel after uninstalling

im using a logitec g pro with lghub but when i uninstalled raw accel and restarted my computer my mouse is still affected by the settings put on by raw accel.

could reinstall it and delete it using revo uninstaller (not trying to shill just a great tool) although it shouldn't leave anything behind except the folder that houses ra uninstaller (manually delete those), either do that or dive into the drivers for it and delete it (dont do this if you havent got a clue what you are selecting and deleting, also always make a restore point!)