Declaration emit widens literal types in readonly properties

TypeScript Version:  2.3.1
Code
$ cat > foo.ts
export const FOO = 'FOO';
export class Bar { readonly type = FOO; }
$ tsc --declaration foo.ts
$ cat foo.d.ts
export declare const FOO = "FOO";
export declare class Bar {
    readonly type: string;
}

EDIT: added readonly to clarify bug report
Expected behavior:
Bar.type is of type "FOO"
Actual behavior:
The type falls back to string

This is not specific to declaration emit.
The general idea is that a property declaration (or any other  mutable declaration e.g. let or var) has no use of a literal type. you would not declare a variable with only one possible value usually. in these cases you would use a const. similarly for property declarations, you would use readonly.
export const FOO = "FOO";
export class Bar {
     readonly type = FOO
}

for non-const, non-readonly declaration the type is widened to its base type, in this case string.
You can always put a type annotation to tell the compiler what type you want the property to be.
export class Bar {
    type: typeof FOO = FOO
}

Readonly is also widened:
cat > foo.ts
export const FOO = 'FOO';
export class Bar {readonly type = FOO;}
╰─$ tsc --declaration foo.ts
╰─$ cat foo.d.ts
export declare const FOO = "FOO";
export declare class Bar {
readonly type: string;
}

@mhegazy sorry I changed the report to add readonly

thanks for pointing that. it is indeed a bug in the declaration emitter.

Workaround: when you export a class, write properties with an extra typeof.
export class Bar {
  readonly type: typeof FOO = FOO;
}

This is actually the correct behaviour for readonly as per the rules in #10676 (more succint explanation in #11126) Specifically, this sequence:
const foo = "FOO" // widening literal type
class C { readonly cfoo = foo } // still widening
let usage = new C().cfoo // widens to 'string'

Should behave similarly even if it's split across two files:
// @Filename: foo.d.ts
const foo = "FOO" // widening literal type (special-cased: see below)
class C { readonly cfoo: string } // don't use a non-widening literal type

// @Filename: use.ts
import { C } from './foo'
let usage = new C().cfoo // so usage will still be of type 'string'

Note that there is a special case for const but not for readonly: the declaration emit for const foo = "FOO" is const foo = "FOO" not const foo: "FOO". const foo = "FOO" is more flexible because it's a widening literal type. It's not wrong in the way that const foo: string or const foo: "FOO" is. But this special case only applies to simple constant assignments; for more complex assigments the emit is still const foo: string:
const foo = "FOO"
const bar = "BAR"
const both = foo || bar

emits:
const foo = "FOO"
const bar = "BAR"
const both: string

which is essentially the same as the emit for class C { readonly x = foo }, where the simple-assignment special case doesn't exist.
I believe that simple constant assignment is special-cased for historical reasons, and because people tend to simple constants. I suspect they do this a lot more than they export classes full of readonly literal types.
We could change readonly to have the same special case as const, but it would need some justification; this is a breaking change. Old versions don't allow class C { readonly x = "foo" } in a .d.ts. We could soften the break by allowing it and then changing declaration emit a version or two later. But that's a lot of work for something we don't know whether people actually use.
@gcanti @OliverJAsh @evmar can you give examples of use? I propose leaving this issue open until we have good evidence that (1) a lot of people would use this and (2) this pattern is better than what works today.

My use case is simulating nominal types:
class A { readonly _tag = 'A' }
class B { readonly _tag = 'B' }

emits
export declare class A {
  readonly _tag: string;
}
export declare class B {
  readonly _tag: string;
}

which leads to
import { A, B } from 'foo'
declare function f(a: A): void
f(new B()) // <= no error

Adding an explicit type annotation
class A { readonly _tag: 'A' = 'A' }
class B { readonly _tag: 'A' = 'B' }

emits
export declare class A {
  readonly _tag: 'A';
}
export declare class B {
  readonly _tag: 'B';
}

and now I get the expected error
import { A, B } from 'foo'
declare function f(a: A): void
f(new B()) // <= ERROR: Type '"B"' is not assignable to type '"A"'

I had the very same use case as @gcanti, which you can see I had to work around with explicit type annotations in https://github.com/OliverJAsh/twitter-api-ts/commit/5282684f7a8e445965fb18688611958870104f92.

Is this why const obj = Object.freeze({ a: 0, b: 50, c: 90 }) gives obj a type of  ReadOnly<{a: number, b: number, c: number}> rather than a ReadOnly<{a: 0, b: 50, c: 90}>?
I've been playing around with this, since I was hoping that I could use typeof Object.values(obj) to help generate a type of 0 | 50 | 90. Since the types were being widened that doesn't seem to be possible...

I'm also hitting this, in similar circumstances. I want to define classes with a readonly field with a string literal type for a discriminated union, and use the value of those types as keys in a separate dictionary (minimal example below). This bug means that while this pattern works fine inside a single typescript module, it breaks completely if I try to export type definitions and use those types elsewhere.
This is happening because in my case this bug causes tsc to generates invalid type definitions (i.e. definitions will never type check).
One of my exported functions' type signatures only compiles when given string literals, so is fine in the normal TS that does use them, but throws Type 'T' cannot be used to index type 'ObjectWithTheLiteralsAsKeys' if you try to compile anything using the type definition output, because this bug means T is string, not 'a' | 'b' | 'c'. Playground example.

I'm running into a similar problem but I can't tell if it's exactly what's described here, or if last week's patch will fix it.  I'm trying to Object.freeze something with a union-literal type, but I can't assign the result to Readonly<MyType> because freeze is widening the union literal to string.
Playground example is probably easier to follow -- you should see the error Type 'string' is not assignable to type '"a" | "b" | "c"'..
Will the patch address this problem? If not, is it already tracked or should I put in a new ticket?


What does ERRORCODE 3010 stands for?

Please add a description whats to reason to check for ERRORCODE 3010.

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

ID: b91a4a43-5353-97cf-7532-7644aa3b497f
Version Independent ID: 858d9a5c-72f3-6a85-9270-0a0dd9e0438b
Content: Install Visual Studio Build Tools into a container
Content Source: docs/install/build-tools-container.md
Product: visual-studio-windows
Technology: vs-installation
GitHub Login: @heaths
Microsoft Alias: tglee

@moerwald Thank you for the feedback.
A note has been added to the documentation and is pending review.
Please refer to MsiExec.exe error messages.


Node: explicitly define Release and Debug builds, use build flags from build.yaml

This basically fixes #3958.
I was looking through some old node issues, and that one seemed simple enough to fix. Plus, this partially unifies the compiler flags that are used in the Makefile with those that are used here. It's not complete because a couple of the compiler flags in build.yaml reference specific Makefile variables.

No significant performance differences

The windows failure is #10199.


[Discussion] Azure Functions Runtime release 2.0.13616

Discussion issue for the Azure Functions runtime release 2.0.13616: https://github.com/Azure/azure-functions-host/releases/tag/v2.0.13616

We found a few issues reported by our customers in this payload, and have started rolling out a hotfix -- https://github.com/Azure/app-service-announcements-discussions/issues/160


Another memory allocator:TLSF

Is your enhancement proposal related to a problem? Please describe.
Current memory allocator adapts slab algorithm. But it can’t support different memory size.
There is another algorithm support different memory size and is designed for RTOS.
Describe the solution you'd like
TLSF allocator is implemented.
Reference: http://www.gii.upv.es/tlsf/files/ecrts04_tlsf.pdf
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or graphics (drag-and-drop an image) about the feature request here.

Current implement already support if my understand is not wrong.


template has StagesAvailable

Hi Nate, Congrats on getting v2 out. I'm sure it will be a great success.
I tried importing a cloud formation template. Loaded ok. But when I try to export to yaml, vaporshell objects. There is a 'stagesAvailable' header on the template. I'm sure you can guess the error.
I worked around this by removing the StagesAvailable element and the TemplateBody wrapper. Then I exported successfully.  I then loaded the exported template into the AWS template designer. So with out further testing, looks excellent so far.
Not that it is a super complicated template, but it did take me a long time to create with Serverless. I'm thrilled vaporshell imported it without much issue. Planning to move everything to Vaporshell now.
Here's the problem elements:
{     "StagesAvailable": [         "Original",          "Processed"     ],      "TemplateBody": {         "AWSTemplateFormatVersion": "2010-09-09",          "Outputs": { rest of template...
The error:
Exception calling "ToYAML" with "1" argument(s): "Unable to find any resources on this Vaporshell template. Resources are required in CloudFormation templates at the minimum."
In my template I have the two elements, "StagesAvailable", and "TemplateBody".
The "TemplateBody", has four elements, "AWSTemplateFormatVersion", "Outputs", "Description", and "Resources".
I did run into some other kind of file type issue too. To fix, I had to copy the text from my template file to a demo export file. I'm not sure what is causing this, but I went back and confirmed that the error reported above exists in either file. So I'm sure it is just the way the original import template file was created. I think it was via downloading it from cfn via awscli. Some kind of windows UTF issue I presume, and unrelated to the 'stagesAvailable' issue reported here.
Anyways. No big concern re: either issue. Just thought I would let you know about the headers preventing the export.
Regards, Richard

Thanks, Richard!!
Did you pull that template directly from CloudFormation in the AWS console? It looks like you pulled a Change Set JSON, which would make sense as you have to go through a Change Set to deploy a SAM template.
For those, you have 2 stages: Original (what the template looked like with Transforms still in it when originally uploaded to CloudFormation) and Processed (what the template looks like after CloudFormation goes through it's Transforms and results in the final template layout)
Curious on where you pulled the template from that you imported, for sure!

Ahh, seeing now that you pulled it from the aws cli, assuming with the get-template command: http://docs.aws.amazon.com/cli/latest/reference/cloudformation/get-template.html
Output
TemplateBody -> (string)

Structure containing the template body. (For more information, go to Template Anatomy in the AWS CloudFormation User Guide.)
AWS CloudFormation returns the same template that was used when the stack was created.
StagesAvailable -> (list)

The stage of the template that you can retrieve. For stacks, the Original and Processed templates are always available. For change sets, the Original template is always available. After AWS CloudFormation finishes creating the change set, the Processed template becomes available.
(string)

That being said, if you have the StackName / StackID, you can do that directly with 2.0 😄 :
Import-VaporShell -TemplateBody (Get-VSStack -Template -StackId $stackName).TemplateBody

I don't recall. I didn't see a spot on cfn to download my template, so I assumed I must have used awscli. I checked the designer too, and I don't see a way I could get the template that way.
In hindsight it may have been via a powershell module.
But sounds like you've got it figured that it was awscli. That's what I figured.
Trying the direct import now.

I get this error:
ProcessRequest4 : Multiple ambiguous overloads found for "AmazonCloudFormationClient" and the argument count: "2".
Maybe cause I'm version4?

Even this fails for me 'Get-VSStack -List', same error.
Too bad...

 I didn't hit that when I was testing, but I have an idea
On your credentials file, do you have a region specified under the profile you're using?
Get-Content ~\.aws\credentials should show you quick, here's a redacted look at mine:
[default]
aws_access_key_id={redacted}
aws_secret_access_key={redacted}
region=us-west-1
[scrthq]
aws_access_key_id={redacted}
aws_secret_access_key={redacted}
region=us-west-2

Here's my PSV4 test
What's the latest version of .NET that you have installed on that machine?

how do i get net version? no region in my credentials..

Ah ha! Pulled the region off and replicated it, definitely the region:)

Can you run Set-VSCredential -Region USWest1 then retry your stack list? Should work after setting the region

(or set it to whatever region you'd like to use)

bear with me.. should work, but doesn't like my current iam user

come onnnnnn (kidding)... no worries! looking forward

I forget how to set my profile... lol

lol...
Set-VSCredential -AccessKey $accessKey -SecretKey $secretKey -Region USWest1 -ProfileName DevAccount

adjust accordingly and all that

durnn it all, two different secret keys and all that lead to the same iam user, that doesn't have permission,,, aaargh!

in case it's easier, I have Gitter setup for more chat style back and forth around VaporShell:
https://gitter.im/VaporShell/Lobby
https://gitter.im/VaporShell/Help

never tried it.. maybe some time. I think the set-vscred is not playing nice, and I'm stuck on the same profile. I'll get back when resolved

2.0.1 coming to PS Gallery now that adds better context to the error you had. It also checks the imported template for a TemplateBody property and dives into that layer (so your original issue would work regardless if you pulled the body out or not)
Let me know if you get any errors with Set-VSCredential still!

So you'll see that vs the ambiguous error you saw prior

https://www.powershellgallery.com/packages/Vaporshell/2.0.1 upped!

Cool. You're fast..lol
I ended up nowhere with Set-VSCredential, but changed the permission on the iam user to allow the formation listing (works). Have to run away for awhile, but will try the direct import later today.

No worries! Let me know once you're covered and I'll close this out! Cheers!

how can i list the profile that get-vs uses? I set it as you showed, but it doesn't seem to be correct. as the iam user listed doesn't match the keys i use on the commandline. anyways will be gone for awhile.

The functions will use whichever of these has a value first, in order of precedence:

The profile name you pass to the -ProfileName parameter on the function itself:

Get-VSStack -List -ProfileName devAccount

The value for $env:AWS_PROFILE, if set
"default", if 1 and 2 are not matched

Thanks. Yeah just stuck in default profile, though I had thought I was setting it with the proper keys, as my cred file was changing. I have a default 'NetSDKCredentialsFile' too, but I don't think it's a factor.
Anyways ran this with success. Doubt I'll go back to the original issue considering I can retrieve direct from cfn. thanks, close her out.. you are awsome sir!
`PS> Import-VaporShell -TemplateBody (Get-VSStack -Template -StackId 'thestack' -ProfileName devAccount ).TemplateBody
AWSTemplateFormatVersion      Description                   Resources                     Outputs

2010-09-09                    The AWS CloudFormation tem... @{ServerlessDeploymentBuck... @{ServerlessDeploymentBuck...`

Awesome!!
So, the NetSDKCredentialsFile is what AWS Tools for PowerShell uses. I opted to leverage the shared credentials file instead, as the NetSDKCredentialsFile is a little weird with .netstandard / Linux / macOS. Nothing wrong with it, but VaporShell is not looking there at all

cool. i eliminated the iam permission i set earlier and confirmed it was for the default in my cred file, So i figured the net file was not used. still not sure why I was stuck., but not uncommon..lol. Bye for now.

No worries! Cheers man!


302 moderate severity vulnerabilities in npm audit due to minimist package

Describe the bug
I have prepared new project with create-react-app. and then I have tried to run npm audit.
in that I got following output
Moderate        Prototype Pollution

 Package         minimist

 Patched in      >=1.2.3

 Dependency of   react-scripts

 Path            react-scripts > webpack-dev-server > chokidar > fsevents >
                 node-pre-gyp > rc > minimist

 More info       https://npmjs.com/advisories/1179

found 302 moderate severity vulnerabilities in 918863 scanned packages
 302 vulnerabilities require manual review. See the full report for details.

Environment
package.json
"dependencies": {
    "@testing-library/jest-dom": "^4.2.4",
    "@testing-library/react": "^9.3.2",
    "@testing-library/user-event": "^7.1.2",
    "react": "^16.13.0",
    "react-dom": "^16.13.0",
    "react-scripts": "3.4.0"
  },

System npm and node version:
npm -v
6.14.2
node -v
v12.12.0

Expected behavior
It should use suggested updated version of package minimist.

Same issue here, except mine says 583 low severity vulnerabilities.
But I'm just curious about something from looking at the path.  Does this mean the rc package dependency needs to be updated?  Or the react-scripts dependency?  Or something else entirely?

Stopped by to say I'm also having the same issue with 583 low severity vulnerabilities.

@briannakeune @mdodge-ecgrow If you have 583 then you likely need to update react-scripts to 3.4.0.
Change your package.json files to "react-scripts": "^3.4.0", and then run npm install
I still have the 302 low-security vulnerabilities though.

I think this is a webpack issue. I don't use react-scripts and I see similar warnings about minimist. I tried updating webpack to no avail.

#8663

@kbarnesweb My current package.json says "react-scripts": "3.4.0".  Would the missing caret affect that?

After recommended fix - "Change your package.json files to "react-scripts": "^3.4.0", and then run npm install" - I still have 583 low severity vulnerabilities

@ddd-37 The carrot shouldn't be the reason it works or not in this case.  I tried updating jest and it fixed 300 of the 302 issues.  If you want to recreate this:
Run
npm i jest@latest
Then, delete package-lock.json and node_modules folder.
Reinstall
npm install

@ddd-37 I believe the final 2 issues are due to mkdirp still using an old version of minimist. I'll post here if I find a fix.

Can confirm.
With react-scripts and node-sass, I got a total of 283 low severity vulnerabilities and it's all minimist, which seems to be a dependency of mkdirp in all cases. Mkdirp is using an old version of minimist.
"mkdirp": {
      "version": "0.5.1",
      "resolved": "https://registry.npmjs.org/mkdirp/-/mkdirp-0.5.1.tgz",
      "integrity": "sha1-MAV0OOrGz3+MR2fzhkjWaX11yQM=",
      "requires": {
        "minimist": "0.0.8"
      },

Seems like a fix is underway, though.
https://github.com/isaacs/node-mkdirp/issues/7

It appears like they've closed the issue.  Does that mean it's done?  The only resolution they gave at the end only applies to Yarn users and requires the user to manually do something.  What about NPM users?  And shouldn't this be a fix that is automatic and just happens when updating to the latest packages?

I just ran npm audit fix and all 583 vulnerabilities were fixed!

Also having this issue. In my case, i just created a new project and i have 2 "Prototype Pollution" low severity vulnerabilities. They are both due the package "minimist", which are dependency of "react-scripts".
They both point to https://www.npmjs.com/advisories/1179 for more info

I ran into the same issue, although I'm using my own React boilerplate w/ Babel and Webpack, not create-react-app. Turns out the chokidar package was using an older version of minimist (and was likely outdated itself). Running npm install chokidar updated chokidar to the latest version that uses a current version of minimist.

This appears to be fixed in ^3.4.1
install react-scripts@latest to solve this

Its been resolved by adding following line in package.json
   "resolutions": {     "minimist": "^1.2.3"   },

I still have it, even in 3.4.1

Solution:
For npm users:

npm install minimist --save-dev
eg: (minimist version: 1.2.5)

Add Resolution key adjacent to dependency key into package.json file
{
"resolutions": {
"minimist": "^1.2.5"
}
}

Add below line inside script key into package.json
example:
"scripts": {
"preinstall": "npx npm-force-resolutions"
}

Remove node_modules, and then run command:  npm install.

That's it. :)

I am also still getting this issue after upgrading to react-scripts 3.4.1. I've temporarily used @amit14apr's solution above, but it would be nice if it could be fixed at source.
Has this issue been incorrectly closed, or are we missing some required step to make it work?

I still have it, even in 3.4.1, with yarn audit

After reinstalling node modules and yarn lock, everything works fine now. Thanks ;)

Upgrade react-scripts to 3.4.1
Remove yarn.lock file
Perform a clean install with yarn install

To see if it is fixed, run npm ls minimist. It should be something like this:


The toXWithExpectedSize methods pre-allocate a full size array for every thread.

When using, for example, IntArrayList.toListWithExpectedSize in a parallel stream, every thread will pre-allocate the size given.
While this doesn't break correctness, it is rather wasteful, especially if given a large size on a highly multithreaded system.
Only one thread (the one that will merge it all into the final result) needs the full array. The second thread only needs ~half of the given size preallocated (as it will only be handling about half the input). The 3rd and 4th only need a ~quarter of the size preallocated. Etc
For the toXWithExpectedSize collectors may want to replace the supplier function (the one that allocates each threads' mutable accumulator) with a stateful one that tracks how times it has been called and reduce how much it preallocates as the calls go up (to some floor, like 8 or something).
The "correct" way would be preallocateSize / (floor(log_2(timesCalled)) + 1), but that may be too complicated to be worth it.
A simpler method that isn't quite as optimal but still gives a meaningful improvement to the current state is preallocateSize / timesCalled.
This assumes that the first thread is indeed the one that will merge together the final result. If it isn't, then all this gets thrown out the window and there is no safe way we can determine which threads get how much.
Alternatively, we can leave the methods as they are and just warn as an @implNote that these methods may be a bit wasteful with memory if used on parallel streams.

Also, the supplier method gets called only on each recursive step, not every inner loop. So this overhead of tracking will be negligible compared to the "real" work.

Also, the supplier method gets called only on each recursive step, not every inner loop. So this overhead of tracking will be negligible compared to the "real" work.


Return dictionaries instead of tuples

I found it a bit inconvenient to have fit_sdm_cec_sam() return a tuple. I think returning a dictionary with ['I_L_ref', 'I_o_ref', 'R_sh_ref', 'R_s', 'a_ref', 'Adjust'] keys would be much more convenient and safe.
The same goes for calcparams_cec(), which could return a dictionary with ['photocurrent', 'saturation_current', 'resistance_series', 'resistance_shunt', 'nNsVth'] keys instead.
I think that is more Pythonic (explicit is better than implicit and readability counts).
Also, more convenient API-wise:
cec_parameters = fit_sdm_cec_sam(...)
sd_parameters = calcparams_cec(..., **cec_parameters)
curve_info = singlediode(..., **sd_parameters)

The tests could be simplified as well. They currently look like:
I_L_ref, I_o_ref, R_sh_ref, R_s, a_ref, Adjust = ivtools.fit_sdm_cec_sam(...)
expected = pd.Series(get_cec_params_cansol_cs5p_220p['output'])
modeled = pd.Series(index=expected.index, data=np.nan)
modeled['a_ref'] = a_ref
modeled['I_L_ref'] = I_L_ref
modeled['I_o_ref'] = I_o_ref
modeled['R_sh_ref'] = R_sh_ref
modeled['R_s'] = R_s
modeled['Adjust'] = Adjust
assert np.allclose(modeled.values, expected.values, rtol=5e-2)

They could look like:
modeled = ivtools.fit_sdm_cec_sam(...)
expected = get_cec_params_cansol_cs5p_220p['output']
assert modeled == pytest.approx(expected, rel=5e-2)

For reference, tuples vs dicts was discussed briefly (with no immediate resolution) in this thread: https://github.com/pvlib/pvlib-python/pull/784#discussion_r337998873

PD: Since what I am proposing is a breaking change... I also think that reducing the number of parameters in a function is good (i.e.: curve_info = singlediode(..., sd_parameters=sd_parameters)), where sd_parameters is a variable containing all the SDM parameters. Although this could also be applied with a tuple instead of a dict.

My preference would be to use keyword arguments instead, eg: curve_info = singlediode(..., a, b, c, d) = singlediode(..., **sd_parameters) where sd_parameters = {'a': 12.3, 'b': 4.56, 'c': 0.789, 'd': False}. I believe there are a couple of reasons why this could be more Pythonic:

The keyword arguments are explicit. If an argument is misspelled or missing, the function will raise an exception
Whereas I believe a dictionary argument would be implicit. It requires documentation to tell the user what the required keys should be. This is potentially error prone, one could mistype a key or miss one.
Using keywords allows the user all options, pass the dictionary using splat, as keywords, or positional.

In my experience maintaining pvlib, it's been easier to deal with things that require order (positional args and returned tuples) than things that require labels (keyword args and returned dicts or DataFrames). I do use a lot of dicts, Series, and DataFrames in my work, so I certainly appreciate their general value. It just seems they're harder for a more general purpose library. As I mentioned in the linked issue, I'd really like to read a blog post about this kind of API design question in scientific computing.
It's also not clear to me that you'd actually need to switch to keyword arguments to achieve the input simplification you're after. Examples showing that it can be done with positional arguments:
In [1]: def f(a, b):
   ...:     print(a, b)
   ...:

In [2]: f(b=2, a=1)
1 2

In [3]: d = dict(a=1, b=2)

In [4]: f(**d)
1 2

In [5]: t = (1, 2)

In [6]: f(*t)
1 2

The test simplification could work with a tuple too:
assert (1., 5.) == pytest.approx((1., 5.))

Will you explained what I was trying to say, but much better, thanks!

@mikofski I have no strong opinion on packing/unpacking parameters. :blush:
@wholmgren Yeah, simplification can be done either way, I should not have brought it to this issue. :+1:
@wholmgren In my opinion positional args should be enforced then. That is possible in Python 3.8, but not before. Also, positional arguments must come before keyword arguments, and that may require further API modifications.
In example:
# Assuming `cec_params` is a tuple...
cec_params = fit_sdm_cec_sam(...)
# This works fine
calcparams_cec(
    1000,
    25,
    0.004,
    2.5,
    *cec_params,
    ...,
)
# This does not
calcparams_cec(
    effective_irradiance=1000,
    temp_cell=25,
    alpha_sc=0.004,
    a_ref=2.5,
    *cec_params,
    ...,
)

You can't just use keyword parameters before the cec_params expansion and, in my opinion, that makes the code less legible/explicit and the API less convenient/friendly to use. So, in my opinion it would be better to change the API to have *cec_params first, and then effective_irradiance, temp_cell, ....
To summarize, I think returning a dict is better and I do not mind that much about params=dictionary vs. **dictionary on function calls. But your project, your rules! Feel free to close this. :stuck_out_tongue_winking_eye:

A worthy discussion.

ICYMI: @kanderso-nrel and @CameronTStark - could be useful to get your opinions on this, if you care to weigh in.

On the subject of passing groups of values into a function as a unit vs individually -- if the values are coherent enough to interact as a group in several parts of the API, I wonder if they would be better grouped as a simple object like scipy's OptimizeResult instead of a dictionary.
For positional-only arguments, I don't think it's a good idea at this time.  For one, it would require a big bump in minimum python version, and for two I don't think pvlib satisfies any of the use cases listed in PEP 570.
For returning dicts vs tuples... a 6-element tuple is a bit unwieldy.  On the other hand, returning a dictionary for two values would seem silly.  I notice fit_sdm_desoto returns a dictionary.  But taking a step back, it seems like there will always be some complexity to the plumbing of these low-level interfaces, which suggests maybe they need a high-level interface.  Just throwing out an idea, what about some sort of "PVDevice" class that behaves like this?
device = fit_device(v_mp, i_mp, ... model='cec')
# or
device = Device(I_L_ref, ..., model='cec')
# calls calcparams_x and singlediode under the hood:
curve_info = device.ivcurve(effective_irradiance, ...)

@wholmgren 's description of the situation is good although I would prefer to have a dictionary on the output if there are more than two values being returned. This makes it possible to enable easy transfer of the output of one function into another without careful positioning.
In [1]: def outputs_dictionary():
         ...:     return dict(this="foo", that="bar", other_thing="baz")

In [2]: def uses_output_dictionary(first_arg, that, other_thing, this, last_arg):
         ...:     print(this, that, other_thing)

In [3]: example_dictionary = outputs_dictionary()

In [4]: example_dictionary
Out[4]: {'this': 'foo', 'that': 'bar', 'other_thing': 'baz'}

In [5]: uses_output_dictionary(42, **example_dictionary, last_arg=1337)
foo bar baz

In [6]: uses_output_dictionary(last_arg=1337, **example_dictionary, first_arg=42)
foo bar baz

This is useful in interactive data analysis as well as in programmatic scripting to unify the API. Having sensible defaults for these arguments, when possible, makes this even easier and is also useful in enabling new users a path forward when they'd otherwise have no idea what value to insert.

I don't think we're going to get any farther arguing in the abstract. Can the proponents of an API change provide a list of functions for which they think it should change? Are we only talking about the single diode functions?
While we're at it, we might also consider functions that return labeled data (either as DataFrames or dicts) that could simply be ordered instead.

Having sensible defaults for these arguments, when possible, makes this even easier and is also useful in enabling new users a path forward when they'd otherwise have no idea what value to insert.

I'm not aware of any pvlib functions that require input for which there exists reasonable defaults, but they exist then we should address them in separate issues.

I'm late to this conversation, but I lean against the suggestion to return dicts instead of admittedly long tuples. Two reasons, which have already been mentioned:

a dict requires users to conform to pvlib's key names. Users trying to combine pvlib with other code are likely to have to write translators from pvlib to other code, which strikes me as annoying.
for the function layer, pvlib prefers to use one argument for each quantity being input to the model implemented. I think the same preference is useful for function output.

It is expected that pvlib's key names do not match other packages'. Not a huge hassle in my opinion to handle it with dicts vs. tuples (I assume other packages will have different order in their parameters as well, of course):
# Returning dicts
d = pvlib_function()
non_pvlib_function(x=d['bar'], y=d['foo'], z=d['baz'])

# Returning tuples
foo, bar, baz = pvlib_function()
non_pvlib_function(x=bar, y=foo, z=baz)

On the other hand, as an end-user, I would be much more scared if I had to rely on the order.
Of course I would assume that pvlib would take care of updating other pvlib functions if the order changed in the future, so this will always work:
t = pvlib_function()
another_pvlib_function(*t, ...)

But any change in the order in the future, for any reason, will break my code without raising an exception if tuples are used instead of dicts:
foo, bar, baz = pvlib_function()  # Now this should be "bar, baz, foo" instead
non_pvlib_function(x=bar, y=foo, z=baz)  # Silently yields wrong results

So, as an end user, I would vote against tuples. I would prefer my code to crash blatantly if the API changed in the future.
On the other hand, if what you are proposing is to freeze the API once this is decided (i.e.: the order will never change no matter what), then I take everything I just said back. I just don't know how stable you consider pvlib's API to be. :blush:

I second @wholmgren on this:

I don't think we're going to get any farther arguing in the abstract. Can the proponents of an API change provide a list of functions for which they think it should change?

My proposal was about the SDM functions in particular. Since my pvlib's API knowledge is very limited, I do not know if it should extend to other parts of the API, so I would feel unable to provide a list of functions.
I hope this issue ends up not causing more noise than it helps. :heart:

@Peque please take a look at the changes in #708, and let me know how we can improve the fit functions to make a better interface with the pvlib.pvsystem.calcparams_xxx functions.
For the record, I regret that I did not first reorganize pvlib.ivtools in a separate PR, rather than as part of the port of a fitting method from MATLAB.

@cwhanse :+1:
In my opinion this could be improved:

fit_cec_sam and fit_sandia_simple return parameters in a tuple, but fit_desoto, fit_pvsyst_sandia, fit_desoto_sandia return parameters in a dict; this should be consistent (either dict or tuple)
If the fit_ functions are going to return tuples, that part of the API should be frozen forever (i.e.: the order should never change)
If the fit_ functions are going to return tuples, the calcparams_ functions should have the fit_-returned parameters first in the function definition and enforced as positional parameters when only Python 3.8+ is supported in the future; this part of the API should be also frozen

Minor suggestions:

I noted an inconsistency, already reported in https://github.com/pvlib/pvlib-python/issues/958
There are inconsistencies in the use of upper/lower case in function parameters (i.e.: v_oc, EgRef, I_L_ref, I_o_ref, Adjust...) I would always use lower case for function parameters, with _ for separation (you could use flake8's pep8-naming plugin to check that)
R_s does not seem to have a _ref suffix, even if it is supposed to be the resistance at reference conditions; maybe those _ref suffixes could be always omitted to simplify naming?

If all the SDM related functions become compatible with each other with just a few changes, I'm in favor.
As much as I like to see a layer of functions for everything at the base of pvlib (and as much as I like to limit myself to using only that layer) I do share the view of @kanderso-nrel that classes could provide a nice solution here.

I don't really have a strong opinion here, and there are already a lot of voices, but I will just mention this: beware of classes. They can be useful if used thoughtfully, but they

can take up a lot of memory,
can be slow to create,
and may not play friendly with concurrency and task graphs.

As usually I may be completely wrong about this but I have seen otherwise. PVMismatch is a case in point. With cells as a "class" we have to do a lot of secret magic to keep the memory load down. This might be less of an issue if the cells' info was all in one giant NumPy array or other efficient memory container.


Create load balancer: argument "--vnet-name"

Argument is keyed with a single "-" instead of two. Correct syntax is "--vnet-name".

This checklist is used to make sure that common guidelines for a pull request are followed.

[ ] The PR has modified HISTORY.rst describing any customer-facing, functional changes. Note that this does not include changes only to help content. (see Modifying change log).

[ ] I adhere to the Command Guidelines.

This change was rolled into #6843.


feat: Create the dev sub-command

#19
Checklist

[x] I didn't over-scope my PR
[x] My PR title matches the commit convention
[x] I did not include breaking changes
[ ] I included unit tests that cover my changes
[x] I added/updated the documentation about my changes
[x] I made my own code-review before requesting one

Description of the changes
Add the dev command with it basic implementation: build, start and logs(app).

Looks good to me, just some rephrasing to do so that the documentation follows one model.


[Bug]-[500]:Evaluation of store value failed for child widget of a List widget.

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
User's data -

Value in the store (printed on console) -

Eval failure -

Steps To Reproduce
Couldn't reproduce it on the cloud.
Environment
Production
Version
Self-Hosted

BINDING_SUCCESS, entityType = LIST_WIDGET
&
WIDGET_PROPERTY_UPDATE, updatedValue contains 'storeValue('
--> 6m usage: 476
Stats

Stat
Values

Reach
500

Effort (months)
<>

not reproducible anymore


Stop using gtk crate features

The examples still need features internally to remain buildable with older libraries.

I wait for build and I merge. Once again, thanks a lot for all your work ! =D

Cheers :)


Loadash warning

I'm getting this error/warning after running
npx lint-openapi src/public/openapi.yaml -e -r docs/ibm-lint-openapi-rules.yaml

$ npx lint-openapi src/public/openapi.yaml -e -r docs/ibm-lint-openapi-rules.yaml
'lodash/isPlainObject' is imported by lodash/isPlainObject?commonjs-external, but could not be resolved – treating it as an external dependency
'lodash/isEqual' is imported by lodash/isEqual?commonjs-external, but could not be resolved – treating it as an external dependency
'lodash/uniqWith' is imported by lodash/uniqWith?commonjs-external, but could not be resolved – treating it as an external dependency
'lodash/pickBy' is imported by lodash/pickBy?commonjs-external, but could not be resolved – treating it as an external dependency

I'm using v 0.97.3

I can reproduce with the latest version (1.0.7) as well. We will be looking into this soon. It seems to specifically happen when using a custom, YAML-formatted ruleset. As a temporary alleviation, you can define the ruleset as JS file. The warnings don't show in that case, for some reason. e.g.
const ibm = require('@ibm-cloud/openapi-ruleset');

module.exports = {
  extends: ibm,
  rules: {
    'ibm-parameter-casing-convention': 'info',
  },
};

:tada: This issue has been resolved in version 1.6.1 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:

:tada: This issue has been resolved in version 1.2.1 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:

:tada: This issue has been resolved in version 1.6.1 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:


be 2.13 friendly

for the Scala 2.13 community build (yup, there already is one)

I also threw 2.12.0 into .travis.yml on the assumption its absence there was inadvertent

the 2.12.0 build failed with "java.lang.UnsupportedClassVersionError: scala/tools/nsc/Main : Unsupported major.minor version 52.0" so I guess there's more work to be done there. it's not really related to the main change I want here, so I have pushed a revised commit that leaves that part out

the remaining Travis failures are unrelated to my changes, I believe — they are seen elsewhere at e.g. https://travis-ci.org/lihaoyi/upickle-pprint/jobs/173883852. could this be merged regardless?

@lihaoyi can this be merged?

Sorry I've been busy with work and haven't had a chance to un-bork my build...

@japgolly is this a repo where you now have mighty powers?

@SethTisue Nay. I'm but one of the small folk in this land.

upickle is being put to sleep, so we can just drop this


Explain usage of createAppContainer

Hey there, I would like to know where exactly do we need to put createAppContainer? Do we need to use it with each navigator? It was introduced in the recent version of react-navigation 3. Now we need to use the container directly.
For my new app, I just wrapped my root navigator with it and placed in App.js, and it seems to be working and no problems with Redux so far. Thank you.
More about App Container:
https://reactnavigation.org/docs/en/app-containers.html#props-of-createappcontainer-on-react-native
react-navigation: 3.0.0

you only need to use it at the root of the app. cc @ericvicenti maybe you can clarify in doc

Hi, @brentvatne how do we do nested routing in react-navigation: 3.0.0, now that we have to use createAppContainer ?

@jkhusanov  i used it after creating my stacks. On this way:
`
// Here is your app with all of your stacks together, even TabNavigator, etc.
const AppWithNavigationState = AppNavigator;
const AppContainer = createAppContainer(AppWithNavigationState);
class App extends PureComponent {
render() {
return (
<AppContainer
ref={(navigatorRef) => {
NavigationService.setTopLevelNavigator(navigatorRef);
}}
/>
);
}
}
`
Then i just import this component on my main component. I dont know if this if the correct aproach, but it works fine for me.

@brunokiafuka - the app container is only at the very root of the app. it's a bit confusing i know, sorry :( think of it like a provider from redux and such

I have mention my codes below. Anyone help how can i change AppContainer in root ?
mport {
createStackNavigator,
createSwitchNavigator,
createBottomTabNavigator,
createAppContainer
} from 'react-navigation';
import React, {
Component
} from 'react';
import { NavigationService } from '../API/NavigationServices';
const AuthNavigator = createStackNavigator(
{
Login: {
getScreen: () => require('./LoginScreen').default,
},
},
{
navigationOptions: {
header: null,
},
},
);
const TabNavigator = createBottomTabNavigator({
Home: {
getScreen: () => require('./HomeScreen').default,
},
});
const MainNavigator = createStackNavigator({
Tab: TabNavigator,
});
const AppNavigator = createSwitchNavigator({
Splash: {
getScreen: () => require('./SplashScreen').default,
},
Auth: AuthNavigator,
Main: MainNavigator,
}, {
initialRouteName: 'Splash',
}, );
//export to app.js
class Navigation extends Component {
state = {};
render() {
return <AppNavigator ref={r => NavigationService.setTopLevelNavigator(r)} />
}
}
export default Navigation;

//Its not working createBottomTabNavigator when i put inside the createAppContainer how can i solve this problema??? any example, full example with codes??
import React from 'react';
import {
ActivityIndicator,
AsyncStorage,
StatusBar,
StyleSheet,
View,
Text,
YellowBox,
} from 'react-native';
import Icon from 'react-native-vector-icons/FontAwesome';
import { createStackNavigator, createSwitchNavigator,  createBottomTabNavigator, TabBarBottom, createAppContainer  } from 'react-navigation';
import Login from './components/src/screens/Login';
// To disable fucking yellowbox warnings
console.disableYellowBox = true
class AuthLoadingScreen extends React.Component {
componentDidMount(){
//SplashScreen.hide();
}
constructor() {
super();
this._bootstrapAsync();
}
// Fetch the token from storage then navigate to our appropriate place
_bootstrapAsync = async () => {
const userToken = await AsyncStorage.getItem('userToken');
// This will switch to the App screen or Auth screen and this loading
// screen will be unmounted and thrown away.
this.props.navigation.navigate(userToken ? 'App' : 'Auth');

};
// Render any loading content that you like here
render() {
return (

);
}
}
const styles = StyleSheet.create({
container: {
flex: 1,
alignItems: 'center',
justifyContent: 'center',
},
});
const AppStack = createStackNavigator({
MainGuest: MainGuest,
Login:Login
});
const AuthStack = createStackNavigator({ Login: Login});
export default createAppContainer(createSwitchNavigator(
{
AuthLoading: AuthLoadingScreen,
App: MainGuest2,
Auth: AuthStack,
},
{
initialRouteName: 'AuthLoading',
}
));
const MainGuest2 = createBottomTabNavigator(
{
Home: { screen: HomeScreen },
Settings: { screen: SettingsScreen },
Profile: {screen:ProfileScreen}
},
{
defaultNavigationOptions: ({ navigation }) => ({
tabBarIcon: ({ focused, tintColor }) => {
const { routeName } = navigation.state;
let iconName;
if (routeName === 'Home') {
iconName = ios-information-circle${focused ? '' : '-outline'};
return ;
}
else if (routeName === 'Settings') {
iconName = ios-options${focused ? '' : '-outline'};
return ;
}
else if (routeName === 'Profile') {
iconName = ios-options${focused ? '' : '-outline'};
return ;
}
    // You can return any component that you like here! We usually use an
    // icon component from react-native-vector-icons

  },
}),
tabBarComponent: TabBarBottom,
tabBarPosition: 'bottom',
tabBarOptions: {
  activeTintColor: 'tomato',
  inactiveTintColor: 'gray',
  showLabel:false,
},
animationEnabled: true,
swipeEnabled: true,

}
);
class HomeScreen extends React.Component {
render() {
return (
<View style={{ flex: 1, justifyContent: 'center', alignItems: 'center' }}>
Home!

);
}
}
class SettingsScreen extends React.Component {
render() {
return (
<View style={{ flex: 1, justifyContent: 'center', alignItems: 'center' }}>
Settings!

);
}
}
class ProfileScreen extends React.Component {
render() {
return (
<View style={{ flex: 1, justifyContent: 'center', alignItems: 'center' }}>
Profile!

);
}
}

@jkhusanov i used it after creating my stacks. On this way:
`
// Here is your app with all of your stacks together, even TabNavigator, etc.
const AppWithNavigationState = AppNavigator;
const AppContainer = createAppContainer(AppWithNavigationState);
class App extends PureComponent {
render() {
return (
<AppContainer
ref={(navigatorRef) => {
NavigationService.setTopLevelNavigator(navigatorRef);
}}
/>
);
}
}
`
Then i just import this component on my main component. I dont know if this if the correct aproach, but it works fine for me.

Can you put the full code of  -> const AppWithNavigationState = AppNavigator; ????

@jaumetips  i created the AppWithNavigationState with the following code:
const mainStack = createSwitchNavigator({   [routes.YourRoute]: {     screen: yourFirstStack,   },   [routes.YourTabContainer]: {     screen: yourTabStack,   }, }, {   initialRouteName: routes.YourTabContainer,   header: false, });
I split my stacks on different files, by doing this i think you get a more clear file structure. Hope it helps: :)


Type narrowing can be improved based on _ can't match error

This is not working for me: the name property is not accessible. I get invalid operation: type XXX does not support field access.
Ballerina Swan Lake Beta 3
Language specification 2021R1
Update Tool 1.3.5
import ballerina/sql;

type Person record {string name; };

function foo(Person|error v) returns string {
    match v {
        error sql:NoRowsError() => { return "OK"; }
        _ => { return v.name;}
    }
}

The narrow doesn't seems to work, am I missing something ?
Originally posted by @ecoupal in https://github.com/ballerina-platform/ballerina-spec/issues/152#issuecomment-965612816

Since _ doesn't match to errors, only potential candidate is Person hence v should be narrowed to Person.

Related to https://github.com/ballerina-platform/ballerina-lang/issues/30191.


Print the SMT model to a file when running an external solver

Might be useful for debugging.

Looks good!


Support for DuckDB v1.1.0

This should fix #21

Oh hey @jankramer, thanks a lot for the PR! Unfortunately, it is currently a bit redundant since I implemented the update fix yesterday (along some other stuff). I just haven’t had a chance to fully test it or address the GitHub Actions pipeline issue yet — it got pretty late last night. However, I also noticed that in your PR, the duckdb_version in MainDistributionPipeline.yml is still set to duckdb v1.0.0. This would hinder the project to build right now.

Gotcha, I'll leave it to you then 👍

merged it to an intermediate branch.

Awesome! Thanks for your work on this extension, it's really nice 👍 I'll certainly give it a star 😄


Disable print_config by default.

What does this PR do?
This PR disables print_config by default, because the configuration trees have grown so much that it's hard to examine in console anyway.
The config will still be available in logs/<experiment>/<timestamp>/.hydra/config.yaml.
We can also print the final config (no interpolation) as a file in logs/<experiment>/<timestamp>/config.txt in the future.
Type of change
Please check all relevant options.

[x] Improvement (non-breaking)
[ ] Bug fix (non-breaking)
[ ] New feature (non-breaking)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Testing
Please describe the tests that you ran to verify your changes. Consider listing any relevant details of your test configuration.

[x] pytest
[ ] CUDA_VISIBLE_DEVICES=0 python -m mart experiment=CIFAR10_CNN_Adv trainer=gpu trainer.precision=16 reports 70% (21 sec/epoch).
[ ] CUDA_VISIBLE_DEVICES=0,1 python -m mart experiment=CIFAR10_CNN_Adv trainer=ddp trainer.precision=16 trainer.devices=2 model.optimizer.lr=0.2 trainer.max_steps=2925 datamodule.ims_per_batch=256 datamodule.world_size=2 reports 70% (14 sec/epoch).

Before submitting

[x] The title is self-explanatory and the description concisely explains the PR
[x] My PR does only one thing, instead of bundling different changes together
[ ] I list all the breaking changes introduced by this pull request
[ ] I have commented my code
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[x] I have run pre-commit hooks with pre-commit run -a command without errors

Did you have fun?
Make sure you had fun coding 🙃

FWIW I still examine the config output. Easy to do in with a modern console (I use tmux) and its search capabilities.

OK. I would close the PR then.


Extra blank pages appear in some spine items

This issue could be related to #193
The total number of pages calculated by the pagination/layout info might be incorrect due to elements that reflow the layout after initial pagination (such as deferred loading of resources such as web fonts)
This issue is more apparent in WebKit than in Blink or Gecko.

Is there a sample ePub in which this is reproducible?


[Feature Request] 2FA - Authenticator additoin

Many websites offer 2FA with auth codes. Would be a cool addition to support this and after a single paste of the password also copy the Gauth for 30 seconds to paste during the period.

This is an interesting idea. I hadn’t thought of it but adding it now would break backwards compatibility with the database format. If we make it to version 2 I’ll definitely consider adding it.


Fix error symbol’s value as variable is void: union

As a title mention, I encounter this error when I call =persp-import=. I think there is no =union= in emacs lisp but it exists in the common lisp so it should be called =cl-union= instead in emacs-lisp.

Great catch! Thank you for contributing to Perspective.


Is there support for getting archived stories?

As title above, is there support for getting archived stories? Notably, getting the archived story and viewer list of the archived story.

Duplicate #1124.

and viewer list of the archived story.

I don't think you can get this in the app.


Authentication failure

While logging in Response: 401 Unauthorized Begin Message {"status":{"code":40120,"text":"Authentication failed. Bad username or password."}} End message
Keep getting authentication failure with the most recent build. Regular skype client accepts credentials.
Username: lighthouse.pro
Password: TestPassword

Works fine for me. Check if you're supplying the right username and password

This exact credentials provide me same error. I use this library from within ColdFusion.

How are you using the credentials? Is it hard coded? While testing I thought it wasn't working but I was just reading extra data from my credentials file which was appended onto the password. Once I fixed that I logged in just fine.

Wow! My bad, sorry. I had an additional argument on my arguments list. Thank You very much!

No problem


Add related links in list.md

#3124

Hello @thepriefy,Thanks again for the PR! It's HACKTOBERFEST! We want to show our appreciation by sending                                              you some special Hacktoberfest swag. If you have not already, could you please fill out                                              this form so we can send it to you? Thanks!                                             Team SendGrid DX


[chef] removing automatic dm code generation from chef

Added warning to chef script when zap-cli is not found in path, as well as brief instructions on how to install it
Updated Readme file

I agree. I don't like the scope creep in this PR. I'll make all the af-gen-event changes in a separate PR. We merge that, and then this one that depends on it
Yes, I'll check what seems dead code in the cpp file as well
Andrei and I will ping people in Slack
Aye. I'll ping them on the other PR once it's opened

PR not relevant after #24844


grafana dashboards not installed causing grafana crash loop

In the ceph-grafana role https://github.com/ceph/ceph-ansible/blob/master/roles/ceph-grafana/tasks/configure_grafana.yml#L9 skips the deployment of the dashboards when containerized_deployment is true. In my case I'm using containerized_deployment=true, since I want all ceph daemons to be container based.
Without the dashboards grafana fails to initialize since it has a provisioning entry for a directory that doesn't exist (/etc/grafana/dashboards is installed by the ceph-grafana-dashboards package)
group_vars:
ceph_origin: repository
ceph_repository: community
ceph_stable_release: nautilus
ceph_version_num: 14
cluster_network: <IP_ADDRESS>/24
containerized_deployment: true
dashboard_enabled: true
docker_pull_timeout: 600s
ip_version: ipv4
monitor_address_block: <IP_ADDRESS>/24
public_network: <IP_ADDRESS>/24
radosgw_address_block: <IP_ADDRESS>/24
Environment:

CentOS7 hosts
docker
ansible 2.8
ceph-ansible - master

@pcuzner

In the ceph-grafana role https://github.com/ceph/ceph-ansible/blob/master/roles/ceph-grafana/tasks/configure_grafana.yml#L9 skips the deployment of the dashboards when containerized_deployment is true. In my case I'm using containerized_deployment=true, since I want all ceph daemons to be container based.
Without the dashboards grafana fails to initialize since it has a provisioning entry for a directory that doesn't exist (/etc/grafana/dashboards is installed by the ceph-grafana-dashboards package)

This should be fixed by https://github.com/ceph/ceph/pull/26415

@guits should we close this once @zmc does the backport to Nautilus - so there is visibility to others trying to install?

@pcuzner sure, thanks for taking care of this!

btw: This is a nautilus back-port: https://github.com/ceph/ceph/pull/28635

closing it since the backport has been merged


[DO NOT MERGE] Auto PR to update dependencies of istio

This PR will be merged automatically once checks are successful.
none

@istio-testing: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e.sh
8e2e2b89d5563d3f9caa4bc1aa2fd4d9df17f72b
link
/test istio-pilot-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


Fix #1052

Added check as function might return null

I could not merge this PR, so I pushed as my commit: https://github.com/masayuki0812/c3/commit/fb5154338348a0adbcdee067543d497c7ad87bde
Thanks!


import_data.py attachment upload problem

The pdf attachments for documents is not processed properly (in the Document sheet), when a path is given it should be converted to an attachment object, however it return "None".
I tried with both local and full paths.
To test the problem on beanstalk I added a test.py and fieldsTest.xls
running the following command
python3 import_data.py Rao_et_al_2014/fieldsTest.xls --update
Gives this
Running on http://4dn-web-dev.us-east-1.elasticbeanstalk.com/
{'document_type': 'general protocol', 'aliases': ['dcic:test'], 'attachment': None, 'award': '1U01CA200059-01', 'lab': '/labs/4dn-dcic-lab/'}
POSTing data!
WARNING:root:POST failure. Response = {"status": "error", "description": "Failed validation", "@type": ["ValidationFailure", "Error"], "title": "Unprocessable Entity", "errors": [{"description": "None is not of type 'object'", "name": ["attachment"], "location": "body"}], "code": 422}
{'title': 'Unprocessable Entity', 'status': 'error', 'code': 422, 'description': 'Failed validation', '@type': ['ValidationFailure', 'Error'], 'errors': [{'description': "None is not of type 'object'", 'name': ['attachment'], 'location': 'body'}]}
DOCUMENT: 0 out of 1 posted, 1 errors, 0 patched

@KorayKirli ok this is now fixed, get the latest from the 4DNWranglerTools Repo


Alphanet docs have a weird autoreload

To reproduce, open: https://docs.nearprotocol.com/quick_start/expert
Observe that web page opens, and there is a section:
"Expert: Run Alphanet deploy on GCP"
Then page reloads by itself, and the section changes to:
"Expert: Connect to NEAR Testnet"

Press reload in the browser repeatedly for a greater effect.

https://www.dropbox.com/s/5qfnijq49hl8oyr/Weird_docs.mov?dl=0

Can you reproduce now?

Cannot reproduce.


Adapt flags to tldr client specification

Following tldr client specification
Change the flags

-p to choose the platform, mv port to -P
-L to choose the language

Aiming to invite people to collaborate with translations to the locale language or the platform.

Handled by 4a4265dc383ac4a2b63d789ca8d70a00d94ac809


Expose float filter & add default params for float UpdateParams

Change OneEuroFilter's scope to be public and add default parameters for non-frequency values in its UpdateParams method
Resolves this issue: https://github.com/DarioMazzanti/OneEuroFilterUnity/issues/4

Thanks!


How can I get traind APIRetriever model(in apicoder)

In the part of apicoder, I notice although the API embediing and score is public , but the weight of the traind APIRetriever is not released.
I would appreciate it if you could release the weight kindly😍.

Thank you for your interest. Due to company intellectual property policies, we are currently not planning to open-source APIRetriever.


Servers should disregard RequestVote RPC when they believe a current leader exists

If a server receives a RequestVote RPC within the minimum election timeout, it does not update its term or grant its vote.

Implemented in the check_quorum branch. Not merging for now. See #3 .

The target scenario for this change was to avoid a "disruptive server rejoin".
If a server is cutoff from the rest of the network, it could increase its term continuously and seek to become the leader. Once the network is restored, this server will have the largest term and eventually be elected the leader. Note that this election might be utterly unnecessary, since the rest of the servers could be functioning normally.
So the solution to this problem is

A server should not increase the term unless it gathers enough pre-voting support.
A follower should not agree to prevote if it believes the current leader still functions. A leader must proactively step down to avoid stalling connected followers.

Now item 1 fixed most of the problem. The case in which the disruptor is only disconnected to the current leader, however, remains open. It could not be solved by item 1 when the disruptor did not miss any commits from the leader. 2) solves this case.
I'm arguing that the remaining case is not worth solving, since the target case is rare, and item is a timing-based solution that brings a lot more complexity. We could have item 2 as an optimization.


The footnotes modal URL is not behind any authentication

I can access /footnotes/footnotes_modal/ without logging in.

No data is exposed, only the basic HTML for the modal is returned so it is essentially a static file (if the {% comment %} tag was removed, it literally could be a static HTML file), so I'm not sure authentication should be required here.

I think it's worth looking into it further.


Consider adding the new HPC instances to this page (i.e. HB and HC)

Looking at https://docs.microsoft.com/en-us/azure/architecture/topics/high-performance-computing#networking we refer to A8, A9, H16r, and H16mr. Should we include HB and HC in that section as well or should we remove reference to the old instances and replace it with a link to a page that shows all HPC instances that have InfiniBand connectivity.

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

ID: a7cf67b7-8d94-d7a2-97ef-1387e252109c
Version Independent ID: 0d3a72a7-6600-5682-6be1-6c333192bbd6
Content: High Performance Computing (HPC) on Azure
Content Source: docs/topics/high-performance-computing.md
Service: architecture-center
GitHub Login: @adamboeglin
Microsoft Alias: pnp

Hi @JonShelley Thank you for your feedback! We will review and update as appropriate.

We've taken this item to our internal backlog for further research and will update as necessary!


devcontainer does not support operations on current project (eg, add-auth)

Fix in progress

Fixed in 10.04.47.
See docs, here.


Timestamp calculation in SenMLResolver class

Our colleagues identified  issue in timestamp calculation mechanism in Leshan. In class SenMLResolver resolvedTimestamp is calculated as  sum of currentTimestamp (in miliseconds) and resolvedTimestamp (in seconds):
           if (resolvedTimestamp < 268_435_456) {
                resolvedTimestamp = currentTimestamp + resolvedTimestamp;
            }

what is your opinion on the following change:
            if (resolvedTimestamp < 268_435_456) {
                resolvedTimestamp =  TimeUnit.MILLISECONDS.toSeconds(currentTimestamp) + resolvedTimestamp;
            }

on line 52 ?

Good catch !
Yep, fix could be something like :
line 52 :
resolvedTimestamp =  TimeUnit.MILLISECONDS.toSeconds(currentTimestamp) + resolvedTimestamp;

OR line 25 :
    private long currentTimestamp =  TimeUnit.MILLISECONDS.toSeconds(System.currentTimeMillis());

Fixed in master by PR #1303 (commit b14a7406f5b12f98c577465605f7e6c20db3f36f)
Thx to you and  your colleagues :wink:


Add an option for OCSP Must-Staple

Since we know that non-stapled OCSP leaks information to the CA, I thought it would be a good idea to add user_pref("security.ssl.enable_ocsp_must_staple", true); for completeness and increased security and privacy. The default value is true anyways.

@Exodion sorry for the delay. We probably left it out as it was already at true. This is more @earthlng 's area - I'm all for comprehensiveness, so why the heck not.
/* 1213: blah blah
Anyone want to write it up? Maybe find a doc link? Earthlng, what say you?

Thanks @Exodion . I'll discuss the PR in here, so it's all together. Not that there is necessarily anything wrong with it, but I like to understand it myself before it goes in, and its not 100% clear to me what this does with that one short line - one aim of the js is to put things in non layman terms so idiots like me can use it (even if the link does it for us, the more info in the js the better)
/* 1213: require a stapled OCSP response from the CA (FF45+)
 * [1] https://blog.mozilla.org/security/2015/11/23/improving-revocation-ocsp-must-staple-and-short-lived-certificates/ ***/
user_pref("security.ssl.enable_ocsp_must_staple", true);

I'd add (FF45+) as per above
Excellent link
maybe "enforce OSCP Must-Staple (FF54)" and then an short explanation

When a CA adds this [TLS feature] extension to a certificate, it requires your browser to ensure a stapled OCSP response is present in the TLS handshake. If an OCSP response is not present, the connection will fail and Firefox will display a non-overridable error page

I'm confused. If the CA has the new feature, then who is not giving the stabled OCSP response? Maybe I don't follow this. Where is the cert coming from? I understand the hard fail part as the fallback rather than a soft fail, but I maybe I need a flow chart. Is their a third party in this besides the CA + the browser? I'm struggling to see when this fails (because I am a dummy!) :)
I need to head off, so will get to this tomorrow,

I'm 50-50 on this. On one hand there's no reason not to add this to the user.js for completeness but on the other there are lots of other security prefs for which we don't enforce the default value either. And then there's the possibility that it confuses people about what this pref does. In fact @Exodion seems to be one of those people because in the pull request he/you titled it "require a stapled OCSP response from the CA" which is incorrect - it merely enables support for it.
If we want to add it, another nice article IMO is https://www.grc.com/revocation/ocsp-must-staple.htm.
But I also found this from May 19. 2017:
https://blog.hboeck.de/archives/886-The-Problem-with-OCSP-Stapling-and-Must-Staple-and-why-Certificate-Revocation-is-still-broken.html

The OCSP Stapling implementations of Apache and Nginx are broken
... the biggest share of active sites on the Internet run on Apache (about 46%), followed by Nginx (about 20 %).
... To summarize: This is all a big mess. Both Apache and Nginx have OCSP Stapling implementations that are essentially broken. As long as you’re using either of those then enabling Must-Staple is a reliable way to shoot yourself in the foot and get into trouble. Don’t enable it if you plan to use Apache or Nginx.

If we add it then users might get a false sense of added privacy/security due to a feature that still seems to be broken and/or not very widespread. IDK, up to you Pants. Just my 2 cents

IDK .. I have no cents .. this is one area that always does my head in

Not many servers support it. https://github.com/pyllyukko/user.js/issues/17#issuecomment-100435660

By all that argument then the default is true so we all have shot feet

OK, I follow now - 66% of servers are Apache/Nginx - so if you hit one of those that fit the OSCP Must-Staple then you've tricked yourself - how? By connecting when you shouldn't have, I assume - because hard failing wouldn't be a loss of privacy/security? :headspin:

No you've not tricked yourself. The article just illustrates that back in May even if someone in charge of a webserver would want to enable OCSP stapling on those 2 webserver SWs it could result in problems for their users if a CA is temporarily down and the stapling information on the server would get fucked up, effectively stopping anyone who had Must-staple enabled in their browsers from accessing their sites.
Therefore 66% of servers out there are likely not very inclined to enable stapling in the first place. But again, that was back in May, lots could have changed in the meantime.
I just don't want to confuse people into thinking that they can "force" a server to use stapling (and must-staple on the client-side) Read the grc.com article it explains at lot of it.

bad use of words .. "false sense" then. So they would fail at worst (hard fail when they didn't have to) which is not a loss of security/privacy. Which makes sense because if the error was the other way round (soft fail when they should have blocked it) then I doubt the default would be true.
So I agree the value should be true, which is default. But I also think this is too confusing. Hell, I'm a genius with 25 PhD's and a goat, and it takes too much to explain the ups and downs and side effects. It's even tricky to condense it to two or three lines - and even then people would misunderstand it. So yeah ..
I need to go .. I'll have a sleep on it

"false sense of added privacy/security" as in "I use the ghacks user.js and when reading thru it I noticed that OCSP must-staple is enforced and therefore I can trust that I will always get connected to the right server because otherwise must-staple would detect it and stop the connection"

and therefore

Which is why we (/s ) I always want to putin explanations for dumb people like me :)

I think we'll skip on adding this to the user.js. The default value is what we want, so no worries there. IF it ever changes, we will pick this up in our FF release diffs and we can revisit it - so that's covered. Essentially we are future-proofed and the decision really boils down to earthlng's point about confusion and a false sense of security
@Exodion Thanks for the suggestion, appreciated - I learned something :)


Add test from issue #751

#751

Codecov Report

Merging #1030 into develop will increase coverage by 0.01%.
The diff coverage is 100%.

@@             Coverage Diff             @@
##           develop    #1030      +/-   ##
===========================================
+ Coverage    89.76%   89.77%   +0.01%
===========================================
  Files           12       12
  Lines         2696     2699       +3
  Branches       461      461
===========================================
+ Hits          2420     2423       +3
  Misses         187      187
  Partials        89       89

Awesome, thank you!

You can close https://github.com/timothycrosley/isort/issues/751
I wasn't sure if you were going to merge this, I just wanted you to see that the test would pass and the issue can be closed.


Fix foodcritic 2x

Test Kitchen Evidence: https://gist.github.com/bbaugher/a52e4d65317f97be2a93ec868e11f4ef
Same as #46 but also hit FC074 to use default_action method on our resource

+1

+1

Have enough +1s, merging


feat: finish populating existing precompiles and predeploys

Completed TODOs around precompiles for Arbitrum and Mainnet. Also added missing references for Mainnet precompiles and checked Optimism's. Resolves #3
Optimism payout address: 0x741cB6A6a8dC16363666462769D8dEc996311466

Thanks for the quick turnaround here, planning to review this tomorrow


feature: add Authy authentication MFA to local auth

From what I understand MFA is available for configuration but is not enforceable at the moment, would you like contributions or are you perhaps planning to implement this sometime in the near future?
PS. Thanks for a much needed plugin!

From what I understand MFA is available for configuration but is not enforceable at the moment, would you like contributions or are you perhaps planning to implement this sometime in the near future?
PS. Thanks for a much needed plugin!


how to do this only on tags?

I think in the common use-case you only want to use this config for tags and not for every commit. Is there a way to do that?

I can think of two possible strategies, neither of which I've fully worked out:

Have a travis configuration that runs on every build, then checks the $TRAVIS_TAG envvar and bails out if it's not what you want
Do something with a deploy section to have a script run on tags only.

Can the matrix not have an "only" on some entries? Does it apply to the
whole matrix?
I feel like the basic use case is to have a standard environment for
testing for all builds, and use this for tags only. And yeah worst case
just handle everything in the scripts.
The scripts already need to take care of the testing vs the building
environment.
I mean having this is example is great, but actually using this seems to
require quite a bit of extra work :-/
Sent from phone. Please excuse spelling and brevity.
On Jul 14, 2017 22:37, "Nathaniel J. Smith"<EMAIL_ADDRESS>wrote:

I can think of two possible strategies, neither of which I've fully worked
out:

Have a travis configuration that runs on every build, then checks
the $TRAVIS_TAG envvar and bails out if it's not what you want
Do something with a deploy section
https://docs.travis-ci.com/user/deployment/#Conditional-Releases-with-on%3A
to have a script run on tags only.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/pypa/python-manylinux-demo/issues/14#issuecomment-315506538,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAbcFgxN4VoYvQxrc6_q8OnEKQweqygWks5sODPdgaJpZM4OY5jx
.


nushellPlugins: add the format plugin and fix darwin

Description of changes
Fix compilation under darwin and add the formats plugin to support ini, ical and others.
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[x] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

if someone ever finds out, I still don't know why those plugins are not being built by ofborg.


Matching for wildcards in topics

Hi, @davidyaha.
I have added a filter to check if any of the subscriptions match the message topic, while matching on wildcards too. Currently on message receive it does not find a key for topic/a, if one subscribes for topic/# because it only checks if the topic exists as a key in the subscriptions dictionary.
In our use case we would like to allow us to set the topic more generally without specifying the whole path.

Hey @eranor! Thanks for taking interest in this project!
Would you mind specifying what this PR is for?
How it will be used?
Also could you add tests for this feature?
Thanks ahead!

Added description and the tests requested

@eranor Thanks for updating this PR!
This actually a great addition to support the mqtt wildcards!
It is currently not passing the CI tests due to TS errors, have you seen those while running locally?
Thanks again!

@davidyaha Hi. I've corrected the Typescrip and other errors causing the CI to fail.


[iOS] uiDelegate is not a UIViewController

I think I did everything according to the Readme - the app runs and works, but when I click the Google Sign In button it crashes - what I can see in the logs is:
HelloWorldApp[75023:1475420] *** Terminating app due to uncaught exception
'NSInvalidArgumentException', reason: 'uiDelegate must either be a |UIViewController|
or implement the |signIn:presentViewController:| and |signIn:dismissViewController:| methods from |GIDSignInUIDelegate|.'

Does anyone have any idea how to fix this?

I've been able to fix this with a custom ViewController.h and ViewController.m - so the part from Google Docs https://developers.google.com/identity/sign-in/ios/sign-in#add_the_sign-in_button - should be added as a reference to the docs

@karolsojko thanks for reporting this. Any chance you can set up a public repo or best a PR so that I can look into it ?

I've been able to fix this with a custom ViewController.h and ViewController.m

@karolsojko Seeing the same error here! What do you mean by customer ViewController files?
Thanks

@tomeng728 I used this repo as a refference and copied ViewControllers or most of their contents https://github.com/googlesamples/google-services/tree/master/ios/signin/SignInExample

+1

@karolsojko can you be a little more specific? My problem is not copying/adapting the view controllers or the code, but in the context of react-native how does this all blend together?

This is quite old issue and we have not seen similar reports lately. If you experience this don't hesitate to create a new issue.


ghc version

I have ghc version 9.0.2
But when I run stack build on this repo, I get
No setup information found for ghc-8.10.7 on your platform.
This probably means a GHC bindist has not yet been added for OS key 'linux64-ncurses6'.
Supported versions: ghc-7.10.3, ghc-8.0.1, ghc-8.0.2, ghc-8.2.1, ghc-8.2.2

What can I do?

Glad to hear it! Thanks for the fix; I'll update the readme when I get a
chance.
On Fri, Jul 15, 2022, 10:06 AM Eloi Torrents @.***>
wrote:

Closed #62 https://github.com/isovector/cornelis/issues/62 as completed.
—
Reply to this email directly, view it on GitHub
https://github.com/isovector/cornelis/issues/62#event-7003380738, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AACLAF6I7XU3C6VNPV4OWD3VUGLBJANCNFSM53U7XYWA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


$index not available

Thank you for this great library! This was exactly for what I was looking for.
Before I used your lib I populated a  with product-div-nodes via the foreach knockout binding. At the very end after all product-divs were inserted I needed to add a clearing div like that:
`

`
With the knockout-sortable lib it seems that the data-bind="sortable: { data: products }" doesn't offer the $index var - am I right?
Do you have a suggestion how I could restore this functionality?

I also ran into this problem. It would be great if $index didn't break. Otherwise I'm really happy at how easy this plugin has been to use!

+1


Support to idLabels

@Niddhogur thanks for the PR - I haven't had time to actually take a look. One thing I've noticed on this is that the parameters seem to adhere to a different scheme than what I inherited from the Trello-generated code.
Compare:
# existing code
def new_member(self, card_id_or_shortlink, value):

# new code
def new_label_by_id(self, idCard, idLabel):

I'm not sure if it should be id_label or value (I'd have to look at the API docs for each function), but I suspect that it should be card_id_or_shortlink - at least for now. I have some nebulous plans to make the API more pythonic, but I have some other projects that have priority.

Yeah, you are totally right. I wrote the code that way to match the standards of my current project. So, clarifying: idCard should be card_id_or_shortlink and idLabel should be value.

Looking at the api docs:
POST /1/cards/[card id or shortlink]/idLabels

and
value (required)
Valid Values: The id of the label to add

It looks like it should be card_id_or_shortlink and value.
At some point when I get some actual time, I want to make this codebase quite a bit more Pythonic, fixing a lot of the naming schemes (like I'm pretty sure id would be just fine, rather than card_id_or_shortlink), providing actual docstrings, fix pep8 formatting, etc.
But for now, yeah, just fixing those two names will bring it inline with the current code, and I can merge it in :)


I want filter should be fixed on the top

I'm using "react-picky": "^4.5.1".
I want to filter(search bar) on the top of the options. The filter should not be scrollable with the options. How should I fix the position of filter?

Use the render prop and implement the filter functionality yourself. Or maybe you could do it by overriding the CSS.


Allow negative weight in FiMap (e.g. velocities)

Fix to allow the weight (mass) of a particle in FiMap to be negative (e.g. for using a velocity as weight)

I think maybe to be sure mass(index) should be set to zero (in addition to pindex(index)=-1 in map_remove_particle (though clean_array is called before projection so maybe not necessary) - it wouldn't hurt though...for the rest looks ok..


slight tweaks to @ggoodman's work in #203

I've made a couple slight tweaks to the pull request in #203 (also see #202).
First off, thanks for reporting and tackling this @ggoodman, this makes commands significantly more powerful. I've made a couple small changes:

I added some unit-tests, including one I found for the edge-case where the node-bin is in _.argv.
I modified your approach slightly:

the core of the problem was that commands were getting checked in the order they were defined.
the solution was to instead iterate over argv._ in order.

Could you give this branch a try and let me know if it does the trick for you.

@bcoe I've tried your tweaks in this branch but note that this doesn't seem to fully resolve the issue. Given a 'category' like profile with commands like init and ls (but no create) as well as a top-level 'command' called create, I note the following behaviour:
cli profile create --> Unable to read the file $(pwd)/create(It actually prints a path, but what is important is that the path is relative to the working directory and not the cli tool). Expected behaviour would have been to fall back to my top-levelcheck()handler that would have printedno such command profile create` under my proposed changes.
See auth0/nested-yargs for the library I created to structure this 'category' and 'command' hierarchy.

Could you paste a failing code example again? The problem with the counter
based solution is that it's too strict. As an example your original sample
code failed because of the node bin in process.argv.
I'm happy to put a test around any other edge cases you find, and fix them.
On Monday, July 13, 2015, ggoodman<EMAIL_ADDRESS>wrote:

@bcoe https://github.com/bcoe I've tried your tweaks in this branch but
note that this doesn't seem to fully resolve the issue. Given a 'category'
like profile with commands like init and ls (but no create) as well as a
top-level 'command' called create, I note the following behaviour:
cli profile create --> Unable to read the file$(pwd)/create(It actually
prints a path, but what is important is that the path is relative to the
working directory and not the cli tool). Expected behaviour would have been
to fall back to my top-levelcheck()handler that would have printedno such
command profile create` under my proposed changes.
See auth0/nested-yargs https://github.com/auth0/nested-yargs for the
library I created to structure this 'category' and 'command' hierarchy.
—
Reply to this email directly or view it on GitHub
https://github.com/bcoe/yargs/pull/206#issuecomment-120958254.

@ggoodman bump, it's been a busy week at npm; but if you could gist me a couple code examples to put tests around again it would be amazing :)

@ggoodman I've written this code example, but I can't create the behavior you're describing on this branch:
var argv = require('yargs')
  .command('profile', 'profile commands', function (yargs) {
    console.log('run profile')

    yargs
      .command('ls', 'ls command', function (yargs) {
        console.log('run ls')
      })
      .command('init')
      .argv
  })
  .command('create', 'create some junk', function (yargs) {
    console.log('run create')
  })
  .argv

./test.js create prints run create like I'd expect.
./test.js profile ls prints run profile run ls as I'd expect.
./test.js profile ls create, prints run profile run ls.
./test.js profile create ls, prints run profile run ls like I'd expect.
I think you've really got some good ideas about how to hammer out yargs' command handling, but I think I'm slightly confused at this point.

@ggoodman closing this pull request for the time being, happy to revisit if we can get a few more test cases around the behavior -- as I said, love your ideas surrounding how to improve command handling.


MongoDB bulk:true run never complete

I'm trying to get started with Transporter (which feels like awesome!).
Just found out that if I have bulk:true in MongoDB configuration, what I use as source, the run never exists. The reason why I would have it in source config is that I didn't want to duplicate configs if I read and write to same database.
If I duplicate the configs so that I have source_mongodb and target_mongodb and only define bulk:true in target_mongodb it copies data and exits nicely with code 0.
Don't work
nodes:
  my_mongo:
    type: mongo
    uri: mongodb://<IP_ADDRESS>:27017/my_database
    bulk: true

Source({name:"my_mongo", namespace: 'my_database.SomeCollection'})
  .save({name:"my_mongo", namespace: 'my_database.SomeCollection'});

After copying data, it just hangs and never exit.
Works
nodes:
  source_mongo:
    type: mongo
    uri: mongodb://<IP_ADDRESS>:27017/my_database
  target_mongo:
    type: mongo
    uri: mongodb://<IP_ADDRESS>:27017/my_database
    bulk: true

Source({name:"source_mongo", namespace: 'my_database.SomeCollection'})
  .save({name:"target_mongo", namespace: 'my_database.SomeCollection'});

Copies and exits with code 0.
Transporter version: 0.1.1
Host: OS X El Capitan 10.11.1

hi @ernoaapa, I've been able to duplicate the issue locally and will look at getting a fix in.

fixed via #211
@ernoaapa we should have a new beta release of v0.1.2 up soon


chore: Update Discord username

Hey, I just made a Pull Request!

Minor documentation tweak given the Discord user name rename process rolling out.
:heavy_check_mark: Checklist

[ ] A changeset describing the change and affected packages. (more info)
[x] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[x] All your commits have a Signed-off-by line in the message. (more info)

Just fixed the prettier - should automerge when complete :tada:


Plz new backup database

shop-online
Plz new backup database
Static analysis:
3 errors were found during analysis.
Variable name was expected. (near " " at position 23)
Variable name was expected. (near " " at position 38)
Unrecognized statement type. (near "new" at position 0)
SQL query:
new file mode 100644 @@ -0,0 +1,232 @@ +++++++++ +SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO"
MySQL said: Documentation
#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'new file mode 100644
@@ -0,0 +1,232 @@
+++++++++
+SET SQL_MODE = "NO_AUTO_VALUE_' at line 1

#1064 Database Error
Please do change new backup (export) database. :( 👍
Thank You

I Just make a new databases to the Source Code Thank You for the free Source :) 👍
Sorry for my language

@tommyhawk95 I need database Plz upload

@cookiesze Done

@cookiesze Done

can you send me the database ? hehe


Remove ViewProps from being extended of component type

Some View props when passed to the native iOS View cause an execution error. To avoid future problems, this PR removes the possibility of it being extended from ViewProps type from the component's typing.
Also added the possibility of passing only one prop style.

LGTM, thank you.


chore(all): fix eslint and lint-staged setup

Proposed solution
Minor fixes and updates for eslint and lint-staged configurations.

Allure report
allure-report-publisher generated test report!

smokeTests: ✅ test report for c3ffd99d

passed
failed
skipped
flaky
total
result

Total
19
0
0
0
19
✅

It's so freaking big 😯


Support for singluar currency word

Added support for singular suffix for currency.
Eg.
$1 -> One Dollar Only (instead of One Dollars Only)
$1.01 -> One Dollar and One Cent Only (instead of One Dollars and One Cents Only)

My conversation with ChatGPT
[me]
---
Q. Which one is accurate grammatically? zero rupee or zero rupees?

[chatgpt]
---
A. In English grammar, when referring to a quantity of zero, it's common to use the plural form of count nouns.
Therefore, the correct and widely used phrase would be "zero rupees," not "zero rupee."
The same rule applies to other currencies and count nouns in general.

Here are some examples with other popular currencies and different decimal values:

1. **Rupees (INR, Indian Rupee)**:
   - Zero rupees (₹0)
   - ₹0.50 is pronounced as "fifty paise" (since 1 rupee = 100 paise)

2. **Dollars (USD, US Dollar)**:
   - Zero dollars ($0)
   - $0.25 is pronounced as "twenty-five cents" (since 1 dollar = 100 cents)

3. **Euros (EUR, Euro)**:
   - Zero euros (€0)
   - €0.75 is pronounced as "seventy-five cents" or "seventy-five euro cents"

4. **Pounds (GBP, British Pound Sterling)**:
   - Zero pounds (£0)
   - £0.10 is pronounced as "ten pence" (since 1 pound = 100 pence)

5. **Yen (JPY, Japanese Yen)**:
   - Zero yen (¥0)
   - ¥0.00 is still zero yen, as the yen does not commonly use smaller units in everyday transactions.

In each case, when the value is zero, the plural form of the currency is used.

For fractional amounts, the smaller unit of the currency is typically named (like paise, cents, pence) and is usually pronounced in its plural form if the amount is more than one.

[me]
---
Q. Any place where either rupee or paisa is used?

[chatgpt]
---
A. In the context of Indian currency, the terms "rupee" and "paisa" are used in singular or plural forms based on the specific quantity they refer to. Here are some scenarios where either "rupee" or "paisa" might be used:

1. **Rupee (Singular and Plural)**:
   - Singular: When referring to one unit of currency, you would say "one rupee."
   - Plural: For any quantity more than one, you use "rupees." For example, "five rupees," "twenty rupees," etc.

2. **Paisa (Singular and Plural)**:
   - Singular: Similarly, when referring to exactly one-hundredth of a rupee, you would say "one paisa."
   - Plural: When referring to more than one-hundredth of a rupee, you use "paise." For example, "fifty paise," "seventy-five paise," etc.

The use of "paisa" is less common in everyday transactions now due to the low value of a single paisa.
However, it's still used in formal and financial contexts, particularly in accounting, pricing, and financial statements where exact amounts are important.

When the amount is zero, the plural forms "rupees" and "paise" are typically used, as in "zero rupees" or "zero paise." This follows the general rule in English grammar for using plural forms with the number zero.

@mastermunj I have covered only en-IN, en-US, and en-GB. If the proposed changes look okay, I will add other locales.

@hardiksondagar please go ahead.

@hardiksondagar please go ahead.

@mastermunj I have covered the remaining locales.

Thank you @hardiksondagar. Please help rebase with the main so that en-IE also gets covered.

Thank you @hardiksondagar. Please help rebase with the main so that en-IE also gets covered.

Just did that @mastermunj

Somehow the changes aren't visible. I am unable to find en-IE with relevant changes in the file list.

Somehow the changes aren't visible. I am unable to find en-IE with relevant changes in the file list.

@mastermunj I have synched your main branch to my feature branch here 37b3564
Merge branch 'mastermunj:main' into singular-currency-support

The file en-IE is still not visible in the files list. You can check at https://github.com/mastermunj/to-words/pull/1470/files

The file en-IE is still not visible in the files list. You can check at https://github.com/mastermunj/to-words/pull/1470/files
Instead of merging, try doing a rebase. Also, please run the test suite locally as I believe it should fail for en-IE if it's not updated.

Hi @mastermunj I have attempted to do the rebase now. I am unfamiliar with rebase, so please guide me if I have not done it the right way.

Thank you, @hardiksondagar. Released this as v4


[WIP] Add Alpine SDK image

This PR isn't quite ready. Work items:

[x] Update URL format (to match other images)
[x] Add hash/checksum matching (to match other images)
[ ] Consider globalization invariant mode support for the SDK.
[x] Update tests appropriately to verify Alpine SDK image
[x] Update manifest.json
[x] Update readme

Sample I used for testing: https://github.com/dotnet/dotnet-docker-samples/tree/alpine/dotnetapp-prod
I got the image to work as expected but needed to remove invariant-mode support for the SDK. it seems like the SDK fails to run with invariant mode.
This is the error that I saw before removing globalization invariant mode / adding ICU:
Step 7/11 : RUN dotnet publish -c Release -o out
 ---> Running in 0f3ff19e0e0f
Microsoft (R) Build Engine version <IP_ADDRESS>775 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 46.27 ms for /app/dotnetapp.csproj.
/usr/share/dotnet/sdk/2.2.0-preview1-007846/Microsoft.Common.CurrentVersion.targets(2051,5): error MSB3095: Invalid argument. SafeHandle cannot be null. [/app/dotnetapp.csproj]
/usr/share/dotnet/sdk/2.2.0-preview1-007846/Microsoft.Common.CurrentVersion.targets(2051,5): error MSB3095: Parameter name: pHandle [/app/dotnetapp.csproj]
The command '/bin/sh -c dotnet publish -c Release -o out' returned a non-zero code: 1

This PR was moved to the nightly branch of the dotnet/dotnet-docker repo - https://github.com/dotnet/dotnet-docker/pull/376


Feature - identify missing resources

Feature
Fix #138
The provider now will handle the case when resources are deleted from dbt Cloud directly instead of crashing
Docs
Update docs with examples where there was none

CI passed OK 🚀


Map::entry() is not implemented

Let's implemented similar to this: https://doc.rust-lang.org/std/collections/struct.HashMap.html#method.entry

isn`t this issue solved?
this implementations is from the branch master
https://github.com/yegor256/micromap/blob/master/src/map.rs#L283

@VsevolodGus right, closing


Broken XML feed in bottom corner of calendar page

On the calendar page, there is a broken link. The link is to:
https://www.google.com/calendar/feeds/nlkc39jt4p0nbc4pk9pj7p5fh0%40group.calendar.google.com/public/basic
Visiting this link gives you 403 forbidden.
The image source is: http://www.google.com/calendar/images/xml.gif . That is a broken image as well.
I am not sure what this link was for. Was it supposed to be an RSS feed? Now that it is broken what should we do? Just delete it? Replace it with something else? Why would there have been two separate RSS feeds?

It looks like that was the original Google Calendar RSS feed, which Google helpfully discontinued in 2015: https://www.404techsupport.com/2015/10/google-discontinue-feed-google-calendars/ . Ugh.
It may be possible to use the API to regenerate a feed, but I do not know how intensive this will be. As an RSS zealot I am loathe to see the feed disappear entirely.

This is the same issue as #6 . I am closing this issue and just using the other one instead.


Bschnurr/Microsoft.Python.Parsing nuget publish

Bundling Microsoft.Python.Parsing into a nuget package for PTVS
Removing the old Anaylsis nuget bundle
Updating copywrite info to pass nuget push command verification
https://aka.ms/Microsoft-NuGet-Compliance
Updating signing to sign Microsoft.Python.Parsing package instead of analysis

so replacing analysis to parsing rather than just adding parsing nuget pkg?

Engine package included parser since it is a dependency. I guess analysis is no longer needed since VS works via LSP.

Engine package included parser since it is a dependency. I guess analysis is no longer needed since VS works via LSP.

Correct.. @Huges has duplicated the one or two files he needed from analysis

so replacing analysis to parsing rather than just adding parsing nuget pkg?

Yes. PTVS was the only user of analysis but in reality they just need parsing.


Data transfer from MSSQL to PGSQL fails for very large varchar() types

MSSQL will allow for some very large varchar() data type sizes, such as varchar(2147483647).  When attempting data transfers to PostgreSQL from MSSQL, these large varchar() data types produce failures.  Perhaps varchar types from MSSQL that are beyond a certain size could be translated to "text" types for PostgreSQL?

is it still actual? what version of MS SQL do you use?

there is no update on an issue for almost a month.
if the issue is still actual for you - feel free to reopen the ticket with additional info


Add collaborators to this repo

Comment below to be added as a collaborator
We will all be using this repository today. Even though it's public right now, you will not be able to make changes until you're given the correct permissions. We've automated this process via the GitHub API. Once you comment, we will add you as a collaborator.
You'll start to receive a lot of emails. (❗) You can slow these down immediately by clicking the Unwatch button at the top of the page and selecting either the Participating and @mentions or Ignore option.

Good Morning

first

Hello World V2.0

Comment

HOWDY

Ahh, the learning.

Thanks for the training!

Hello

Test for echo

Hi!

Hey y'all again

dang it tom

Hello!

Round 2

here

woops wrong account. heh.

add me again please

please add me