Make bidi-classes/index.js more compact

Now that canonical names for bidi classes are being used, the size of bidi-classes/index.js increased drastically. E.g. unicode-8.0.0/bidi-classes/index.js is ~12 MB. 😨
Wanted: an npm module that minifies code like
['long string', 'long string', 'long string']

…into something like…
var a='long string';[a,a,a]

I feel like this probably already exists so I’ve asked here before building it myself: https://github.com/h5bp/lazyweb-requests/issues/193

Hmm, doing var u=undefined; and then using u instead of undefined yields ~7 MB savings.

Could use a parser, put all the strings in an array and do the leg work yourself. It shouldn't be too much work. An npm module for this is pretty specific.

Got the size down from 12.7 MB to 6.8 MB.
$ wc -c output/unicode-8.0.0/bidi-classes/index.js
 6804602 output/unicode-8.0.0/bidi-classes/index.js

Files that would benefit from minification of repeated string values (https://github.com/h5bp/lazyweb-requests/issues/193):

categories/index.js (one entry for every code point from U+000000 to U+10FFFF)
bidi-classes/index.js (limited number of entries, but lots of repeated strings)
bidi-brackets/index.js (limited number of entries, but lots of repeated strings)

Moved the string deduping to another issue: #31


PredicateType: pull the predicate off of a type guard or other function with predicate attached

I've often had a need to chain type guards in a manner than continues to narrow in on the type, for usability purposes. Unfortunately TS doesn't provide a type guard's predicate details to allow such chaining. Finally figured it out after months of playing around and thought I'd offer it up for consideration in this lib.
/**
 * For use to extract the Predicate that has been set on a function
 */
export type PredicateType<
  T extends (...x: any[]) => boolean
> = T extends (target: any, ...rest: any[]) => target is infer P ? P : never

Contrived example use case:
const isArrayOf = <
  T extends (...x: any[]) => boolean
>(thing: unknown, validator: T): thing is Array<PredicateType<T>> => (
  Array.isArray(thing)
  && thing.every(validator)
)

const isMessage = (thing: unknown): thing is { type: "message" } => (
  typeof thing === "object"
  && thing !== null
  && 'type' in thing
  && thing['type'] === "message"
)

const thing = []
if(isArrayOf(thing, isMessage)) { /* do something */ }

Below is some other examples that could use this and the outcomes from using the type.
// no type predicate set: never
const never = (thing: any) => true
type neverType = PredicateType<typeof never>

// return basic predicate
const basic = (thing: unknown): thing is boolean => typeof thing === 'boolean'
type testtype2 = PredicateType<typeof basic>

// returns predicate even if more arguments are supplied
const extraArgs = (thing: unknown, _other: any): thing is boolean => typeof thing === 'boolean'
type extraArgsType = PredicateType<typeof extraArgs>

// returns a complex predicate
const complexPredicate = (thing: { type: string }): thing is typeof thing & { payload: unknown } => 'payload' in thing
type complexPredicateType = PredicateType<typeof complexPredicate>

// if predicate is not first: never (i'd rather this error, but its technically true as written 🤷♂; see below)
const lastArgPredicate = (thing: unknown, other: unknown): other is boolean => typeof other === 'boolean'
type lastArgPredicateType = PredicateType<typeof lastArgPredicate>

// type error when used with asserts
const testAssert = (thing: unknown): asserts thing is false => {
  if(typeof thing === 'boolean' && thing === false) {
    throw new Error('why you giving me falsy things?')
  }
}
// @ts-expect-error Type '(thing: unknown) => asserts thing is false' does not satisfy the constraint '(...x: any[]) => boolean'.
type testAssertType = PredicateType<typeof testAssert>

As for "if predicate is not first: never", I've never had a use case where I wanted to target outside the first argument, but this could be expanded as such (or with overloads) should you want that use case... like perhaps following a functional mentality and having target supplied "last":
export type PredicateType<T extends (...x: any[]) => boolean> =
  T extends (target: any, ...rest: any[]) => target is infer P ? P
  : T extends (arg1:any, target: any, ...rest: any[]) => target is infer P ? P
  : T extends (arg1:any, arg2: any, target: any, ...rest: any[]) => target is infer P ? P
  : never

A similar construct might work for asserts as well, but honestly I'm not sure how useful that'd be at all.
edit: formatting

@kevinpeno hey 👋
Thank you for the suggestion, I will come back to you a bit later in the evening, when I will be near my laptop 💻

@kevinpeno sorry for the late response
I checked it on playground – https://tsplay.dev/Wy51bW
It looks really promising, I would really like to see it in our library
@krzkaczor what do you think? It can have a really wide usage

Hey all, just checking in on this again. I'd be happy to implement, but I'd want to better understand your testing process around it before writing a PR. Is there a readme I missed or something?

Hey all, just checking in on this again. I'd be happy to implement, but I'd want to better understand your testing process around it before writing a PR. Is there a readme I missed or something?

Hey 👋
Thank you for reminding about the issue!
So at the moment we don't have any README information about testing (but it would be great to add it)
For now we have:

Test folder where we keep all the tests – https://github.com/krzkaczor/ts-essentials/tree/master/test
I try to split it into files now but it's still in progress
We also have CI pipelines for type checks for different TypeScript versions – https://github.com/krzkaczor/ts-essentials/blob/master/.github/workflows/typecheck.yml (we install specific typescript version, set typescript version with yarn setTsVersion, it updates the type which allows us to check it differently if it's working differently for different typescript versions)

Feel free to ask anything about testing or general questions (you can even contact me in Twitter, Telegram or any other suitable way)
Feel free to prepare MR if you have time, we'll think about test cases together and then merge it without problems
Thank you again!

Alright. Before I work on the PR, what are your thoughts on the original design vs supporting the data-last method for it? Or, should we do both perhaps?

Alright. Before I work on the PR, what are your thoughts on the original design vs supporting the data-last method for it? Or, should we do both perhaps?

I think we need to focus on types only
Given PredicateType in ts-essentials, we can import it in a library / application and then create functions for validation the way you prefer doing it (either data-first or data-last approach)
Use case in library / application
// src/types/isArrayOf.ts
import { PredicateType } from 'ts-essentials';

export const isArrayOf = <
  Validator extends (...x: any[]) => boolean
>(thing: unknown, validator: Validator): thing is Array<PredicateType<Validator>> => (
  Array.isArray(thing)
  && thing.every(validator)
)

Action points
Do not create functions here
Also I'm thinking how it can be used widely in other libraries / applicatoin as we're not trying to build validation library here (otherwise, it will become @sindresorhus/is)
Provide the way how to create a correct validator
Without correctly written validators (e.g. isMessage, isBoolean, isNumber) it cannot be used, right?
However, what I came up with, we can add another type (let's say BuildValidator, we can discuss the better name later) that can simplify doing it:
type BuildValidator<T> = (thing: unknown) => thing is T;

// examples
const isNumber: BuildPredicate<number> = (thing): thing is number => typeof thing === 'number';
const isString: BuildPredicate<string> = (a: unknown): a is string => typeof a === 'string';
const isBoolean: BuildPredicate<boolean> = (a: unknown): a is boolean => typeof a === 'boolean';

Please have a look at examples in Playground – https://tsplay.dev/WyODZN
Limitations are, as you probably already found out, it cannot be easily used with functions that use generic types, e.g.
export type BuildPredicate<T> = (thing: unknown) => thing is T;

export type PredicateType<
  T extends (...x: any[]) => boolean
> = T extends (target: any, ...rest: any[]) => target is infer P ? P : never;

// ❌ error here: Type '<T extends (...x: any[]) => boolean>(thing: unknown, validator: T) => thing is PredicateType<T>[]' is not assignable to type 'BuildPredicate<never[]>'
const isArrayOf: BuildPredicate<Array<PredicateType<(...x: any[]) => boolean>>> = <
  T extends (...x: any[]) => boolean
>(thing: unknown, validator: T): thing is Array<PredicateType<T>> => (
  Array.isArray(thing)
  && thing.every(validator)
)

Example in Playground – https://tsplay.dev/W4yk1w
Does it sound good for you? Please let me know if we need to do it differently for specific use cases that I might miss

@kevinpeno sorry for pinging you, but let me know what you think

Hey @Beraliv. I'm sorry for the silence. I've been a little overwhelmed with work/home life lately.

Alright. Before I work on the PR, what are your thoughts on the original design vs supporting the data-last method for it? Or, should we do both perhaps?

I think we need to focus on types only

Yup. I enjoy the type-only aspect of this library, I was not trying to say we should add validators. In my original statement I was trying to suss out if you wanted a data-first approach (target: unknown, ...params) target is Thing or a functional programing data-last approach (...params, target: unknown) target is Thing approach to PredicateType implementation (or both understanding the complexity that might come of it).

Provide the way how to create a correct validator
I will review your playground items and consider this suggestion. I have some suspicions that it might be more problematic than the limitations you've found thus far.

Does it sound good for you? Please let me know if we need to do it differently for specific use cases that I might have missed

Overall yes. I'll do some digging today and tomorrow and do my best to reply back if I have any questions and/or open a PR with some initial input.

Which version should I be targeting? I honestly do not know if I have the time available to backport, so I assume I should target the next/latest (v9)?

Which version should I be targeting? I honestly do not know if I have the time available to backport, so I assume I should target the next/latest (v9)?

Sorry for the late response here
I started writing the answer but then probably reloaded the page and forgot to leave it here
Yeah, let's target the next release (v9.2.0)

It will be released in https://github.com/ts-essentials/ts-essentials/pull/302 (changelog is missed but I will fix it)


adding version catalog

There is lots to replace, maybe we can split the work? this is very repetitive
Also autocomplete does not work for Groovy. we have to migrate to .kts

Also autocomplete does not work for Groovy. we have to migrate to .kts

Agree with migrating to .kts

There is lots to replace, maybe we can split the work? this is very repetitive

Yep i will help you with that

convert all libraries to Version Catalog

Retrofit
Serialization
Compose dependencies
Coroutines
Dagger - Hilt
Testing

migrate all build files to Kotlin

write which part you will work on
I will work on Compose and ramcosta

you converted to KTS nice


start-all.sh: switch to prometheus 2.7.2

Fixes #456

@amnonh @roydahan we need to test the new Prometheus under load, and we need to validate the upgrade from Monitoring 2.2 to 2.3 with data


Doctests in Munch fork don't run correctly

Hello,
I try this fork of Bunch which seems interesting
https://github.com/Infinidat/munch
but Doctests don't run (never failed)
For example I changed:
    >>> [ (k,b[k]) for k in b ]
    [('ponies', 'are pretty!'), ('foo', Munch(lol=True)), ('hello', 42)]

to
    >>> [ (k,b[k]) for k in b ]
    [('ponies', 'are prettyERROR!'), ('foo', Munch(lol=True)), ('hello', 42)]

and no error raised (which is a problem as it should raise an error)

nosetests gives no error but nosetests -s -v gives 2 failing tests
@vmalloc Any idea ?
pc:munch scls$ nosetests
..
----------------------------------------------------------------------
Ran 2 tests in 0.089s

OK

pc:munch me$ nosetests -s -v
tests.test_doctests.test ... Trying:
    b = Munch()
Expecting nothing
ok
Trying:
    b.hello = 'world'
Expecting nothing
ok
Trying:
    b.hello
Expecting:
    'world'
ok
Trying:
    b['hello'] += "!"
Expecting nothing
ok
Trying:
    b.hello
Expecting:
    'world!'
ok
Trying:
    b.foo = Munch(lol=True)
Expecting nothing
ok
Trying:
    b.foo.lol
Expecting:
    True
ok
Trying:
    b.foo is b['foo']
Expecting:
    True
ok
Trying:
    b = Munch()
Expecting nothing
ok
Trying:
    b.hello = 'world'
Expecting nothing
ok
Trying:
    b.hello
Expecting:
    'world'
ok
Trying:
    b['hello'] += "!"
Expecting nothing
ok
Trying:
    b.hello
Expecting:
    'world!'
ok
Trying:
    b.foo = Munch(lol=True)
Expecting nothing
ok
Trying:
    b.foo.lol
Expecting:
    True
ok
Trying:
    b.foo is b['foo']
Expecting:
    True
ok
Trying:
    sorted(b.keys())
Expecting:
    ['foo', 'hello']
ok
Trying:
    b.update({ 'ponies': 'are pretty!' }, hello=42)
Expecting nothing
ok
Trying:
    print (repr(b))
Expecting:
    Munch(foo=Munch(lol=True), hello=42, ponies='are pretty!')
ok
Trying:
    [ (k,b[k]) for k in b ]
Expecting:
    [('ponies', 'are pretty!'), ('foo', Munch(lol=True)), ('hello', 42)]
ok
Trying:
    "The {knights} who say {ni}!".format(**Munch(knights='lolcats', ni='can haz'))
Expecting:
    'The lolcats who say can haz!'
ok
Trying:
    b = Munch(ponies='are pretty!')
Expecting nothing
ok
Trying:
    'ponies' in b
Expecting:
    True
ok
Trying:
    'foo' in b
Expecting:
    False
ok
Trying:
    b['foo'] = 42
Expecting nothing
ok
Trying:
    'foo' in b
Expecting:
    True
ok
Trying:
    b.hello = 'hai'
Expecting nothing
ok
Trying:
    'hello' in b
Expecting:
    True
ok
Trying:
    b[None] = 123
Expecting nothing
ok
Trying:
    None in b
Expecting:
    True
ok
Trying:
    b[False] = 456
Expecting nothing
ok
Trying:
    False in b
Expecting:
    True
ok
Trying:
    b = Munch(lol=42)
Expecting nothing
ok
Trying:
    del b.values
Expecting:
    Traceback (most recent call last):
        ...
    AttributeError: 'Munch' object attribute 'values' is read-only
**********************************************************************
File "/Users/scls/github/others/munch/munch/__init__.py", line 163, in munch.Munch.__delattr__
Failed example:
    del b.values
Expected:
    Traceback (most recent call last):
        ...
    AttributeError: 'Munch' object attribute 'values' is read-only
Got:
    Traceback (most recent call last):
      File "//anaconda/lib/python3.4/doctest.py", line 1318, in __run
        compileflags, 1), test.globs)
      File "<doctest munch.Munch.__delattr__[1]>", line 1, in <module>
        del b.values
      File "/Users/scls/github/others/munch/munch/__init__.py", line 182, in __delattr__
        object.__delattr__(self, k)
    AttributeError: values
Trying:
    del b.lol
Expecting nothing
ok
Trying:
    b.lol
Expecting:
    Traceback (most recent call last):
        ...
    AttributeError: lol
ok
Trying:
    b = Munch(bar='baz', lol={})
Expecting nothing
ok
Trying:
    b.foo
Expecting:
    Traceback (most recent call last):
        ...
    AttributeError: foo
ok
Trying:
    b.bar
Expecting:
    'baz'
ok
Trying:
    getattr(b, 'bar')
Expecting:
    'baz'
ok
Trying:
    b['bar']
Expecting:
    'baz'
ok
Trying:
    b.lol is b['lol']
Expecting:
    True
ok
Trying:
    b.lol is getattr(b, 'lol')
Expecting:
    True
ok
Trying:
    b = Munch(foo=Munch(lol=True), hello=42, ponies='are pretty!')
Expecting nothing
ok
Trying:
    print (repr(b))
Expecting:
    Munch(foo=Munch(lol=True), hello=42, ponies='are pretty!')
ok
Trying:
    eval(repr(b))
Expecting:
    Munch(foo=Munch(lol=True), hello=42, ponies='are pretty!')
ok
Trying:
    b = Munch(foo='bar', this_is='useful when subclassing')
Expecting nothing
ok
Trying:
    b.values                            #doctest: +ELLIPSIS
Expecting:
    <built-in method values of Munch object at 0x...>
ok
Trying:
    b.values = 'uh oh'
Expecting nothing
ok
Trying:
    b.values
Expecting:
    'uh oh'
ok
Trying:
    b['values']
Expecting:
    Traceback (most recent call last):
        ...
    KeyError: 'values'
ok
Trying:
    b = Munch.fromDict({'urmom': {'sez': {'what': 'what'}}})
Expecting nothing
ok
Trying:
    b.urmom.sez.what
Expecting:
    'what'
ok
Trying:
    b = Munch(foo=Munch(lol=True), hello=42, ponies='are pretty!')
Expecting nothing
ok
Trying:
    b.toDict()
Expecting:
    {'ponies': 'are pretty!', 'foo': {'lol': True}, 'hello': 42}
ok
Trying:
    b = Munch(foo=Munch(lol=True), hello=42, ponies='are pretty!')
Expecting nothing
ok
Trying:
    json.dumps(b)
Expecting:
    '{"ponies": "are pretty!", "foo": {"lol": true}, "hello": 42}'
ok
Trying:
    b.toJSON()
Expecting:
    '{"ponies": "are pretty!", "foo": {"lol": true}, "hello": 42}'
ok
Trying:
    b = Munch(foo=['bar', Munch(lol=True)], hello=42)
Expecting nothing
ok
Trying:
    import yaml
Expecting nothing
ok
Trying:
    yaml.safe_dump(b, default_flow_style=True)
Expecting:
    '{foo: [bar, {lol: true}], hello: 42}\n'
ok
Trying:
    b.toYAML(default_flow_style=True)
Expecting:
    '{foo: [bar, {lol: true}], hello: 42}\n'
ok
Trying:
    yaml.dump(b, default_flow_style=True)
Expecting:
    '!munch.Munch {foo: [bar, !munch.Munch {lol: true}], hello: 42}\n'
ok
Trying:
    b.toYAML(Dumper=yaml.Dumper, default_flow_style=True)
Expecting:
    '!munch.Munch {foo: [bar, !munch.Munch {lol: true}], hello: 42}\n'
ok
Trying:
    import yaml
Expecting nothing
ok
Trying:
    yaml.load('''
    Flow style: !munch.Munch { Clark: Evans, Brian: Ingerson, Oren: Ben-Kiki }
    Block style: !munch
      Clark : Evans
      Brian : Ingerson
      Oren  : Ben-Kiki
    ''') #doctest: +NORMALIZE_WHITESPACE
Expecting:
    {'Flow style': Munch(Brian='Ingerson', Clark='Evans', Oren='Ben-Kiki'),
     'Block style': Munch(Brian='Ingerson', Clark='Evans', Oren='Ben-Kiki')}
**********************************************************************
File "/Users/scls/github/others/munch/munch/__init__.py", line 326, in munch.from_yaml
Failed example:
    yaml.load('''
    Flow style: !munch.Munch { Clark: Evans, Brian: Ingerson, Oren: Ben-Kiki }
    Block style: !munch
      Clark : Evans
      Brian : Ingerson
      Oren  : Ben-Kiki
    ''') #doctest: +NORMALIZE_WHITESPACE
Expected:
    {'Flow style': Munch(Brian='Ingerson', Clark='Evans', Oren='Ben-Kiki'),
     'Block style': Munch(Brian='Ingerson', Clark='Evans', Oren='Ben-Kiki')}
Got:
    {'Block style': Munch(Brian='Ingerson', Clark='Evans', Oren='Ben-Kiki'), 'Flow style': Munch(Brian='Ingerson', Clark='Evans', Oren='Ben-Kiki')}
Trying:
    b = munchify({'urmom': {'sez': {'what': 'what'}}})
Expecting nothing
ok
Trying:
    b.urmom.sez.what
Expecting:
    'what'
ok
Trying:
    b = munchify({ 'lol': ('cats', {'hah':'i win again'}),
            'hello': [{'french':'salut', 'german':'hallo'}] })
Expecting nothing
ok
Trying:
    b.hello[0].french
Expecting:
    'salut'
ok
Trying:
    b.lol[1].hah
Expecting:
    'i win again'
ok
Trying:
    b = Munch(foo=['bar', Munch(lol=True)], hello=42)
Expecting nothing
ok
Trying:
    import yaml
Expecting nothing
ok
Trying:
    yaml.dump(b, default_flow_style=True)
Expecting:
    '!munch.Munch {foo: [bar, !munch.Munch {lol: true}], hello: 42}\n'
ok
Trying:
    b = Munch(foo=['bar', Munch(lol=True)], hello=42)
Expecting nothing
ok
Trying:
    import yaml
Expecting nothing
ok
Trying:
    yaml.safe_dump(b, default_flow_style=True)
Expecting:
    '{foo: [bar, {lol: true}], hello: 42}\n'
ok
Trying:
    b = Munch(foo=Munch(lol=True), hello=42, ponies='are pretty!')
Expecting nothing
ok
Trying:
    unmunchify(b)
Expecting:
    {'ponies': 'are pretty!', 'foo': {'lol': True}, 'hello': 42}
ok
Trying:
    b = Munch(foo=['bar', Munch(lol=True)], hello=42,
            ponies=('are pretty!', Munch(lies='are trouble!')))
Expecting nothing
ok
Trying:
    unmunchify(b) #doctest: +NORMALIZE_WHITESPACE
Expecting:
    {'ponies': ('are pretty!', {'lies': 'are trouble!'}),
     'foo': ['bar', {'lol': True}], 'hello': 42}
ok
2 items had no tests:
    munch.Munch.__members__
    munch.Munch.fromYAML
14 items passed all tests:
   8 tests in munch
  13 tests in munch.Munch
  11 tests in munch.Munch.__contains__
   7 tests in munch.Munch.__getattr__
   3 tests in munch.Munch.__repr__
   5 tests in munch.Munch.__setattr__
   2 tests in munch.Munch.fromDict
   2 tests in munch.Munch.toDict
   3 tests in munch.Munch.toJSON
   6 tests in munch.Munch.toYAML
   5 tests in munch.munchify
   3 tests in munch.to_yaml
   3 tests in munch.to_yaml_safe
   4 tests in munch.unmunchify
**********************************************************************
2 items had failures:
   1 of   4 in munch.Munch.__delattr__
   1 of   2 in munch.from_yaml
81 tests in 18 items.
79 passed and 2 failed.
***Test Failed*** 2 failures.
ok
tests.test_munch.test_dir ... ok

----------------------------------------------------------------------
Ran 2 tests in 0.093s

OK

Once again, works in munch... https://github.com/Infinidat/munch

I don't know why you opened this here -- if this is a munch issue you should open it in Munch itself. In any case it uses py.test and not nose...

Because you need to enable Issue in Munch repository
because when you fork a project on GitHub by default forked project doesn't have bug tracker enabled.
so you need (our someone from your org) to go to
https://github.com/Infinidat/munch/settings
and enable Features / Issues

Whoops! I just enabled it. Sorry!

Thanks.
Closed


getCurrentConnectivity should resolve with object

getCurrentConnectivity() should resolve with object instead of array otherwise in NetInfo.fetch().done(reach => console.log('Initial: ' + reach)) reach will be undefined (see https://github.com/l-urence/react-native/blob/master/Libraries/Network/NetInfo.js#L200).
cc @satya164

As far as I can see Android looks good. But never tested.

I've also noticed that NetInfo.fetch appears broken currently, and it looks like this should fix it. Do you have a test plan? Perhaps a code sample that shows how it was broken before and now works?

cc @bestander @nicklockwood

I think NetInfo.fetch was just forgotten in https://github.com/facebook/react-native/commit/c9a1956c4fd9cfb6bf883c835b501d097181e1a4. Probably would be worth looking for calls to RCTPromiseResolveBlock and making sure nothing else was missed.

ccing @dmmiller too

Apparently all other RCTPromiseResolveBlock calls are okay or at least they do not return an array (find . -name *.m | xargs egrep 'resolve\(').
@corbt The code should now work as described in the documentation.

sweet, thanks again for working on this @l-urence.
@facebook-github-bot shipit

Thanks for catching this one.

I upgraded to 0.22 today. I am getting the following error:
undefined is not an object (evaluating 'RCTNetInfo.getCurrentConnectivity().then')

@shraddha1704 this PR was picked into 0.22 release.
Try creating a new issue with more details please

Found a solution. Replacing the fetch function in NetInfo.js with:
fetch(): Promise {
return new Promise((resolve, reject) => {
RCTNetInfo.getCurrentConnectivity(
function(resp) {
resolve(resp.network_info);
},
reject
);
});
},

@shraddha1704 Your native code seems to be out of date. Run react-native upgrade to update your native files.


Allow scripts to automatically eject

Following the rejection of PR #202 , fixes #196.
In a comment on #202 it was suggested to refactor eject.js to make it possible for other scripts to do the eject for you.
Using the changes in these two commits, I was able to make a script like this from a CRNA-project:
const rns = require("react-native-scripts/build");
rns.eject({
  ejectMethod: "raw",
  enteredName: "ProjectName",
  enteredDisplayname: "My project"
});

I didn't manage to make a index.js file go to react-native-scripts/index.js as taskfile.js specifies to build src directory, if anyone else has another solution for that (or anything else that can be improved in this PR) then feel free to improve on that or suggest improvements.

Sorry for mixing up the issue id in one of the commits and in my branch name, I just noticed this mistake now :(

Closing this one because of the commit message mistake and the branch name mistake. See #346 instead


Weird Icon

Hi there! Thanks for your work. Appreciate it.
I have the following icon on the right:

This looks wrong. Where is it coming from and how to change it?
Thanks!

Hi, you're welcomed
what's the version of ST (Help: About in the command palette) ?


Make words to emoji generator

I smile to  😁
Make a emoji generator which converts text to emoji with the demoji module .

Assign this issue to me please @sumanth-0 .


.dll files are missing in multiple releases

v0.10.1
v0.10.0
v0.9.2

Are all missing deno_mongo.dll
As a library author you should always include all assets needed, this is breaking usage for your windows userbase.
Additionally: v0.10.1 initialization is pointing to v0.10.0 assets.

Because the test on the Windows platform always fails inexplicably, resulting in the inability to release the binary file, the problem has not been resolved. But as you said, I should temporarily disable testing on Windows to ensure the normal distribution of binary files.
By the way, there is no change in v0.10.1 and v0.10.0, v0.10.1 is only caused by deno.land/x refactoring, and it is invalid, so re-release

does this have the same symptoms as this ->
INFO downloading deno plugin "deno_mongo" from "https://github.com/manyuanrong/deno_mongo/releases/download/v0.10.0/deno_mongo.dll"
error: Uncaught Error: downloading plugin "deno_mongo" from "https://github.com/manyuanrong/deno_mongo/releases/download/v0.10.0/deno_mongo.dll" failed.
throw Error(downloading plugin "${name}" from "${remoteUrl}" failed.);
^
at downloadFromRemote (mod.ts:76:11)
at async download (mod.ts:46:7)
at async prepare (mod.ts:60:21)
at async init (util.ts:44:3)
at async mod.ts:13:1

v0.12.0 has binary releases


Does GCM4J helps

https://www.reddit.com/r/AndroidQuestions/comments/43om7p/how_to_generate_a_gcm_registration_token_on_java/

This is out of the scope of this library.


[r] Plumb old-style contexts to new libtiledbsoma contexts

Allow plumbing tiledb-r contexts SOMATileDBContext objects into libtiledbsoma soma_context() objects
Modified SOMA methods:

TileDBObject$new(): plumb tiledbsoma_ctx config options into soma_context() when provided

SC-56531
addresses #3213

Manual backport on #3257
The automated backport failed because of apis/r/DESCRIPTION and apis/r/NEWS.md (as one would expect)


[Snyk] Upgrade com.fasterxml.jackson.core:jackson-core from 2.16.0 to 2.16.1

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to upgrade com.fasterxml.jackson.core:jackson-core from 2.16.0 to 2.16.1.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 1 version ahead of your current version.
The recommended version was released 22 days ago, on 2023-12-24.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Created from snyk in error against this repo


Only appears to work in Chrome

In Chrome 58 / 59, this module works as expected.
In other browsers, I am getting variants of the same error:

Safari 10:

Can't find variable TouchEvent

Firefox 53 / 54:

TouchEvent is not defined

Removing references to angular2-draggable in my project caused these errors to disappear.
Any idea what's going on here? Have I perhaps done something wrong in the setup?

I'm experiencing the same issue with IE 11, I am just testing the demo, it works with Chrome but not in IE.

@laps1967 I used window.getComputedStyle in my code. It's not working in IE 11 as I expected. I should work out another solution for this.
@bodom0015 I think the error for the TouchEvent is another issue. Did you use .umd bundle or not?

thank you so much xieziyu, I see the demo is now working for me in IE 11, I will get the latest version and will try this in my project, very excited about this new feature :)

Yes, I followed the instructions here: https://www.npmjs.com/package/angular2-draggable
Using "angular2-draggable": "1.0.4", my systemjs.config.js is as follows:
(function(global) {
  System.config({
    warnings: true,
    paths: {
      'npm:': 'node_modules/',

      'systemjs': 'node_modules/systemjs/dist/system.js',
      'system-polyfills': 'node_modules/systemjs/dist/system-polyfills.js',
      'es-module-loader': 'node_modules/es6-module-loader/dist/es-module-loader.js',
      'traceur': 'node_modules/traceur/bin/traceur-runtime.js',
    },
    map: {
      'dist': 'dist',
      'src': 'src',

      'angular2-jwt': 'npm:angular2-jwt/angular2-jwt.js',
      '@angular/core': <EMAIL_ADDRESS>      '@angular/common': <EMAIL_ADDRESS>      '@angular/compiler': <EMAIL_ADDRESS>      '@angular/forms': <EMAIL_ADDRESS>      '@angular/http': <EMAIL_ADDRESS>      '@angular/router': <EMAIL_ADDRESS>      '@angular/platform-browser': <EMAIL_ADDRESS>      '@angular/platform-browser-dynamic': <EMAIL_ADDRESS>
      'file-saver': 'npm:file-saver/FileSaver.min.js',
      'rxjs': 'npm:rxjs',

      'moment': 'npm:moment/moment.js',
      'ngx-bootstrap': 'npm:ngx-bootstrap/bundles/ngx-bootstrap.umd.js',
      'ng2-slimscroll': 'npm:ng2-slimscroll/bundles/ng2-slimscroll.umd.js',
      'ng2-file-upload': 'npm:ng2-file-upload/bundles/ng2-file-upload.umd.js',
      'angular2-draggable': 'npm:angular2-draggable',

      crypto: '@empty'
    },
    packages: {

      // TypeScript source
      'src': {
        defaultExtension: 'ts'
      },

      // Transpiled JavaScript
      'dist': {
        defaultExtension: 'js'
      },

      'rxjs': {
        defaultExtension: 'js'
      },

      'file-saver': {
        format: "cjs"
      },

      'moment': {
        defaultExtension: 'js'
      },

      'ngx-bootstrap': {
        defaultExtension: 'js'
      },

      'ng2-slimscroll': {
        defaultExtension: 'js'
      },

      'ng2-file-upload': {
        defaultExtension: 'js'
      },

      'angular2-draggable':  {
        defaultExtension: 'js',
        main: 'bundles/angular2-draggable.umd.min.js'
      }
    }
  })
})(this);

Then, in my module:
import {NgModule} from '@angular/core';
import {CommonModule} from '@angular/common';
import {FormsModule} from '@angular/forms';
import {AngularDraggableModule} from 'angular2-draggable';

import {Footer} from './Footer';
import {TagEditorModal} from './TagEditorModal';
import {TextboxEditorModal} from './TextboxEditorModal';
import {MyModal} from './MyModal';
import {MyOtherModal} from './MyOtherModal';

@NgModule({
    imports: [CommonModule, FormsModule, AngularDraggableModule],
    declarations: [Footer, TagEditorModal, TextboxEditorModal, MyModal, MyOtherModal],
    exports: [Footer, TagEditorModal, TextboxEditorModal, MyModal, MyOtherModal]
})

export class MyTestModule { }

And in my component template(s):
<div class="my-modal" ngDraggable>
      Modal content
</div>

Does the above configuration seem correct to you?

We had similar issue with Firefox and Safari when using this package. We did a little research and realized Firefox and Safari at the time did not support TouchEvent, see Browser Compatibility at https://developer.mozilla.org/en-US/docs/Web/API/TouchEvent.

Hi, @xialiao! This is Mike Lambert from the KnowEnG project! :D
I was just raising this issue with the package developer to see if they recognized the error, or could offer any insight.

@xialiao Yes, you are right. I used TouchEvent just for mobile phones and its definition is not supported by FF and Safari. I realized that mistake, so I removed the definition in v1.0.5.
@bodom0015 please use v1.0.5, It should work in FF and Safari. : )

Awesome, that totally fixed it! Thank you so much for the help!! :D
Closing this issue


[B-03888] I'd like a confirmation email after I registration or role change.

Registrants get an email with a link once they try to register with their email.
Once they complete the registration, send a confirmation email.
Also, send an email when your user has the role changed.
Also, send an email when a Curator gets added or removed from a RV.
Add missing private to emailTemplateService declaration in AuthController.

Coverage decreased (-2.1%) to 48.837% when pulling f0ee7840374df1ad0d7d9af4dcb6e74ee570926f on sprint-tcdl-b03888-confirmation_email into 0950203b2a7b5d4ae04a2a9c50044e4f91f52e67 on sprint-tcdl-staging.


win: dlerror test fails

Any idea why this fails on my machine? I added already some debug output:
`dlerror` failed: exit code 3
Output from process `dlerror`:
msg = 'no error'
dlerror_desc = '%1 is not a valid Win32 application'
Assertion failed in .\test\test-dlerror.c on line 50: strstr(msg, dlerror_desc) != NULL

I'm deeply impressed by libuv. But this test also fails for me on Win-10 using MinGW. I.e.
msg = 'no error'


guide: add running-pipelines page

This started as a way to address #4431, but it expanded into a page on running pipelines generally.

After this, I think we could close #3630 and maybe #2883.


chore: Generate output types for cloud run metadata.yaml

Can we generate output type for submodules too? We need output-type for at least modules/v2. @tjy9206

Can we generate output type for submodules too? We need output-type for at least modules/v2. @tjy9206

Sounds good, added.


MTE tests are broken after gestalt v7 migration

Currently the module integration tests using Module Testing Environment (MTE) are all broken.
Locally, they fail with a VerifyException as the testing environment is unable to find a module for a sepcific component. As far as I can observe, this is not always the same component, but the stacktrace looks quite similar every time.
com.google.common.base.VerifyException: Could not find module for MappedType class org.terasology.unittest.stubs.MappedTypeComponent
	at com.google.common.base.Verify.verify(Verify.java:124)
	at com.google.common.base.Verify.verifyNotNull(Verify.java:500)
	at org.terasology.engine.core.bootstrap.EnvironmentSwitchHandler.registerComponents(EnvironmentSwitchHandler.java:197)
	at org.terasology.engine.core.bootstrap.EnvironmentSwitchHandler.handleSwitchToGameEnvironment(EnvironmentSwitchHandler.java:107)
	at org.terasology.engine.core.TerasologyEngine.initialize(TerasologyEngine.java:227)
	at org.terasology.moduletestingenvironment.ModuleTestingEnvironment.createEngine(ModuleTestingEnvironment.java:409)
	at org.terasology.moduletestingenvironment.ModuleTestingEnvironment.createHeadlessEngine(ModuleTestingEnvironment.java:383)
	at org.terasology.moduletestingenvironment.ModuleTestingEnvironment.createHost(ModuleTestingEnvironment.java:451)
	at org.terasology.moduletestingenvironment.ModuleTestingEnvironment.setup(ModuleTestingEnvironment.java:167)
	at org.terasology.moduletestingenvironment.MTEExtension.beforeAll(MTEExtension.java:93)

In CI, the tests also fail but with a different error message. For instance, in Health build #62 the tests fail with a NoClassDefFoundError for PathManager.
java.lang.NoClassDefFoundError: org/terasology/engine/core/paths/PathManager
	at org.terasology.moduletestingenvironment.ModuleTestingEnvironment.createEngine(ModuleTestingEnvironment.java:401)
	at org.terasology.moduletestingenvironment.ModuleTestingEnvironment.createHeadlessEngine(ModuleTestingEnvironment.java:383)
	at org.terasology.moduletestingenvironment.ModuleTestingEnvironment.createHost(ModuleTestingEnvironment.java:451)
	at org.terasology.moduletestingenvironment.ModuleTestingEnvironment.setup(ModuleTestingEnvironment.java:167)
	at org.terasology.moduletestingenvironment.MTEExtension.beforeAll(MTEExtension.java:93)

In the first case, where EnvironmentSwitchHandler.registerComponents throws "Could not find module for MappedType class o.t.unittest.stubs.MappedTypeComponent," environment.getSubtypesOf(Component) is returning these components in unittest.stubs though the environment does not contain the unittest module.
It looks like that ModuleManager.environment is in its default engine-module-only state, the other modules named in the test class's @Dependencies annotation not yet added to it.
I think the thing to investigate here is to compare to the integration tests in engine-tests, because those aren't failing and I think at least some of them do something like MTE.createEngine, right?

Well, I think the reason that engine-test's TerasologyTestingEnvironment and HeadlessEnvironment don't have that same failure in TerasologyEngine.initalize is because they never call TerasologyEngine.initalize!
They've got gobs of initialization code that's essentially a parallel implementation of the stuff that TerasologyEngine.initialize does, but with mocks and whatnot sprinkled in.
But it looks like it should end up at some of the same register-component code, e.g. from HeadlessEnvironment's call of EntitySystemSetupUtil.addEntityManagementRelatedClasses. The difference is that it sets up the ModuleManager differently (including the "unittest" module) before it gets to that point.

This is some of the engine initialization: https://github.com/MovingBlocks/Terasology/blob/86606d111aaaf18baaeb611d4410de48a8af438f/engine/src/main/java/org/terasology/engine/core/TerasologyEngine.java#L217-L231
here's one idea: make an engine-test subsystem that registers its weird unittest module. Because initSubsystems comes after initManagers but before that handleSwitchToGameEnvironment.
That handleSwitchToGameEnvironment method kinda stands out. I find it dates back to 186086136df79900d7c21d8030dfeafb1f9ecbb5, when it was named applyModules. The registerComponents part came a bit later in ff1125cec9c1cdb6ae31c675f64f539642d8d8b7 as part of #1740.
The thing that's bugging me is that I don't understand why this "switch to game environment" code is being run this early. We haven't selected game modules yet, so I'm not sure why we're doing all this stuff that depends on the module environment. It is called again when we go to actually load a game.
Is it required to load assets that are part of the GUI or something like that?

I think the thing to investigate here is to compare to the integration tests in engine-tests, because those aren't failing and I think at least some of them do something like MTE.createEngine, right?

Just did a quick grep in engine-tests and I did find neither createEngine nor ModuleTesting nor MTE. Do you recall where you thought you might've seen something like that?

The difference is that it sets up the ModuleManager differently (including the "unittest" module) before it gets to that point.

On MTE or on TTE side? If on TTE, should me maybe just add that to the setup on MTE, too?

a quick grep in engine-tests and I did find neither

Indeed, I was wrong about that. engine-tests does not use TerasologyEngine for TTE after all.

On MTE or on TTE side?

TTE has customized its setup. MTE can't do so in exactly the same way because MTE doesn't have its own version of all those initialization methods; it lets TerasologyEngine do that.

TTE has customized its setup. MTE can't do so in exactly the same way because MTE doesn't have its own version of all those initialization methods; it lets TerasologyEngine do that.

So TTE does not let TerasologyEngine do it, but does it in a customized way?
Is TerasologyEngine used by any other tests?
Do we know yet in how far the customized way of TTE diverge from what TerasologyEngine does for MTE?
Would it make sense to adjust whatever TerasologyEngine does so we can have both TTE and MTE rely on that and have it parametrizable to support scenarios with and without for instance the "unittest" module?

Yep. I don't know how far TTE has diverged from TerasologyEngine, but given how much code there is, I assume it has diverged and will only widen as time goes on.
One of the ways that we have of parameterizing Engine is with subsystems. That's one idea I came up with yesterday but I don't know if it's a good idea.
I think it would be sufficient for this particular failure we're having at the moment. Of course, it would be nice if the steps we take for this failure are steps toward fixing the problem of all TTE's potentially-divergent code, and I haven't thought that far ahead.
Another option would be to make the unittest module less of quirky thing. Put it in /modules/, or maybe have another directory /test-modules/ we add to the module path during tests. We'd want it to stay in the same repo so it can't get out of sync with engine-tests.

One of the ways that we have of parameterizing Engine is with subsystems. That's one idea I came up with yesterday but I don't know if it's a good idea.

I'd like to ping @DarkWeird on that one.

Another option would be to make the unittest module less of quirky thing. Put it in /modules/, or maybe have another directory /test-modules/ we add to the module path during tests. We'd want it to stay in the same repo so it can't get out of sync with engine-tests.

This kind of bring me back to the idea of a "developer tooling" distro we talked about a while ago. Basically a distro where modules for testing such as MTE or modules adding debug tooling or so could live...

All this talk about diverging code makes me wonder

a) why do have diverging code for tests? aren't we testing "the real thing"? how many issue just come from having tests run in a different environment than actual game?
b) why do we have multiple lines (of diverging code)? can we merge MTE and TTE and only have a single engine variant for testing (in case we need it).

Yes, that's the subject of #4545.
But for the issue at hand, the TTE tests are the ones that are passing, so removing it for the sake of de-duplication won't get us out of the current mess.
I'm going to try implementing the subsystem thing I suggested in https://github.com/MovingBlocks/Terasology/issues/4757#issuecomment-864343185
I have some misgivings about it, but at the moment I think it's my best shot at trying something.


Some Contacts with birthdays won't display on Search

Short Description
A contact that clearly has Birthday, is not displayed in the app's search.
Steps to reproduce

Open app from home screen's icon
Tap on Searhbar
Type the first letters of the contact (alex)

Resulted in
The search containing no results (see Searching screenshot)
Expected Results
The contact to be displayed (Alexandros)
Video/Screenshots

Searching
Contact has birthday

NOTE: For some reason the contact will be displayed when the "Greek Namedays" are chosen to be displayed form the app settings.

Closed as it cannot be replicated currently on develop


Show user if the coordinator is offline

If the coordinator is offline the app is practical only in view mode usable, but the user does not get any information about that.
We should show that the coordinator is offline and disable functionalities like

send & receive payment
open or closing a position

The force close channel button should always be enabled though, informing the user that she has always a way out.

Closely related to https://github.com/get10101/10101/issues/860
as for force-close channel button - I thought it's not enabled on mainnet?

as for force-close channel button - I thought it's not enabled on mainnet?

not yet, but it should be considered when implementing that feature. don't panic should always be possible eventually ;)


Throwing a "semi-colon expected" error on a seemingly valid syntax

I have the code below, and ts-styled-plugin is complaining about it, even though it appears to be syntactically valid...
const CardSize = styled.div`
  width: 400px;
  height: 400px;

  @media (max-width: 575px) {
    width: 200px;
    height: 400px;
  }
`

const FlipContainer = styled(CardSize)`
  perspective: 1000px;
`

const Flipper = styled.div`
  transition: 0.6s;
  transform-style: preserve-3d;
  position: relative;
  ${FlipContainer}:hover & { // [ts-styled-plugin] semi-colon expected (on the '{')
    transform: rotateY(180deg);
  } // [ts-styled-plugin] at-rule or selector expected (on the '}')
`

On the Flipper variable, it complains about the { and }, the first error being [ts-styled-plugin] semi-colon expected and the second being [ts-styled-plugin] at-rule or selector expected.
Not sure if it's related, but if I change the Flipper to the code below, it stops complaining about the last line (on the })
const Flipper = styled.div`
  ${FlipContainer}:hover & {
    transform: rotateY(180deg);
  }
`

Any idea why this is happening?

I had a same problem like you. and I solved it trough line break between lines.
try this.
const Flipper = styled.div
transition: 0.6s;
transform-style: preserve-3d;
position: relative;
${FlipContainer}:hover & { // [ts-styled-plugin] semi-colon expected (on the '{')
transform: rotateY(180deg);
} // [ts-styled-plugin] at-rule or selector expected (on the '}')
``
still I don't know what's really problem is.

@Jonir227 Doing that just dismisses the last error (on the }), but the one on the { stays 🤔

I'm having the same issue with this code. This should be syntactically correct according to the styled-components docs:
const Button = styled.div`
    background-color: #4CAF50;
    color: white;
    padding: 16px;
    font-size: 16px;
    border: none;
`

const Content = styled.div`
  display: none;
  position: absolute;
  background-color: #f1f1f1;
  min-width: 160px;
  box-shadow: 0px 8px 16px 0px rgba(0,0,0,0.2);
  z-index: 1;
`

const Container = styled.div`
  position: relative;
  display: inline-block;
  margin: 3%;

  ${Content}:hover & {
    display: block;
  }

  ${Button}:hover & {
    background-color: #3e8e41;
  }
`


Generate NL IBAN may generate invalid IBAN

When IBAN.generate( country_code = 'NL',  ank_code = 'INGB',  account_code = str( i ) )
may generate an IBAN thats not 11-proof, which is required by Dutch banks, neither an exception is throw on an invalid account_code.
Also the IBAN.validate() function does not detect a non 11-proof account_code.

@pe2mbs can you share an example of valid and invalid IBANs?
Would you be willing to open a PR that would fix the issue? I can help with testing if you want.

@pe2mbs You can still use
from schwifty import IBAN
from schwifty import SchwiftyException

valid: list[IBAN] = []
for i in range(1, n):
    iban = IBAN("NL", "INGB", str(i))
    try:
        iban.validater(validate_bban=True)
    except SchwiftyException:
        continue
    else:
        valid.append(iban)

to generate random IBANs. The validate_bban-parameter will validate the national checksum digits.


[NETBEANS-285] Fix Quick Search Exception on missing JavaHelp RT

This seems to fix only the symptom and not the cause. The cause is the bad separation from the javahelp jar. (Which I am not entirely certain but might be complicated to pull off since we re-export the JavaHelp APIs, no?)
Anyhow, it might be a good temporary workaround but ideally we should use the module system somehow and not rely on NCDFE / CNFE checks and --cp:a...

Well, I guess JavaHelp has some license issues so this one has happened: https://github.com/apache/incubator-netbeans/pull/249/commits/bdb74770a17d5484b9c1fe068c98f41ced7fe07b
We might create another issue to mend this stuff when the fate of the help system get decided.

@lkishalmi sorry for the late reply. Geertjan proposed a different solution in #467. His approach has the benefit, that the whole registration for java help is removed - that looks cleaner.

@matthiasblaesing Well, that was my first solution as well, then I thought that there would be some platform applications bundling JavaHelp, then they would need to re-add these services. But I'm fine with #467, so I'm closing this PR.


Type-safe regex

This would involve updating the static parser to give more detailed feedback and inference for regex literals embedded in strings.
The general goals would be:

If a RegExp will throw an error when instantiated via new RegExp, we should try and have a corresponding type error describing the problem
If a RegExp implies anything about the contents of a string that would match it that can be expressed using template literals, we should infer its type.

I think there may be limitations on (2) in particular (lookaheads etc could be complicated?) but we can go for the low hanging fruit, e.g. literal strings embedded in regex.
Here are some basic cases that should be covered:
// should be a parse error
type("/(unterminated_group/")

// should be inferred as `${string}foo${string}`
type("/foo/")

// should be inferred as `foo${string}`
type("/^foo/")

// should be inferred as `${string}foo`
type("/foo$/")

// should be inferred as `foo${string}bar`
type("/^foo.*bar$/")

Cases like this could also work. It will quickly create types that are not performant to use, so ideally we should internally have a way to bail out if the expressions gets too complex and return string if we end up supporting stuff like this:
// should be inferred as `${string}${0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9}${string}`
type("/\d/")

// should be inferred as `a${0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | ""}b`
type("/^a\d?b$/")

It wouldn't work with standard raw regex literals like:
// can't narrow because TS just types it as RegExp
type(/^foo.*/)

@didavid61202 is looking into this! 😍

How did you solve the double escape problem?

You're right that looks wrong, I'll update the issue!

@Hsiwe Is looking into this now🔥

@ssalbdivad I guess I can give this a shot, per your request.  I'm probably going to stick to my current parsing strategy while I finish feature-completeness on my proof-of-concept matcher (I think I've figured out how to force the matching to progress in a sensible left-to-right fashion without doing a character-wise lookahead), but I'm open to working with you to improve the implementation for robustness/performance once I finish doing so.

@Oblarg Are you sure a top-down strategy will work for regex? There were cases I ran into like '1|2'|'3|4' that were essentially impossible to parse top-down as far as TS syntax which is what motivated me to switch to shift-reduce parsing in the first place.
Haven't fully considered if in every instance a regex control character would interfere with matching it's preceded by an escape or if its contextual, but I can imagine top down could be problematic in those scenarios.

I'm not sure of anything, but the results so far have been extremely promising.  My overall strategy is to first split on "or" operators into a union, and then recursively parse each branch in the union by searching for the leftmost unescaped quantifier or wildcard, performing a prefix match, and recursing on the remaining portions of the match string and regex.

But what if you have an escaped foo|\||bar? It doesn't seem like you'd be able to recover from this top down.
It seems quite similar to the issues I eventually ran into with a similar approach parsing TS syntax at a type-level.

Escape-pruning has proven way easier than anticipated, and I'm fairly sure I can easily force the union-split to ignore escaped operators (and prune the escapes).
Remember, though, that i'm defining a generic type that represents the regex match with conditional expansion.  This gives me a lot more tools in my toolbox than if I were writing a first-class type.

@Oblarg Yes I'm aware, ArkType's validation works quite similarly!
I'd have to look into it more. It may be possible if in regex every control character would be directly preceded by an escape character to filter those out somehow, whereas if you have to be able to parse quoted strings top-down definitely can't work.
My intuition is still that you will hit cases where it falls apart though. It doesn't seem like you'd ever be able to handle grouping- matching sets of parens for an arbitrary expression like (foo(bar)*)* definitely seems impossible?
It was a really fun journey to explore all of this at a type-level so I don't want to deprive you of that. Just consider that likely, a top-down approach will have inherent limits that a bottom up approach will not, so if you start to run into those, it may be worth considering using a shift-reduce strategy like the one I mentioned.

I already have grouping working in my proof of concept, though only (so far) for the “or” operator.  I suspect it will work for the others.

I'd say just try handling this test case in particular: (foo(bar)*)|(baz)*
If it is possible, I'd definitely be interested to see what that would look like.

I’ll give it a shot when I can!


Added basketball features

Basketball uses scoring periods and matchup period where football uses weeks so I made some variable name changes.
Added nba schedule getter.

Codecov Report

Merging #76 into develop will decrease coverage by 1.17%.
The diff coverage is 23.07%.

@@             Coverage Diff             @@
##           develop      #76      +/-   ##
===========================================
- Coverage     75.9%   74.73%   -1.18%
===========================================
  Files           21       21
  Lines          826      843      +17
===========================================
+ Hits           627      630       +3
- Misses         199      213      +14

Impacted Files
Coverage Δ

espn_api/basketball/matchup.py
25% <100%> (+3.26%)
:arrow_up:

espn_api/basketball/constant.py
100% <100%> (ø)
:arrow_up:

espn_api/basketball/league.py
14.81% <13.04%> (-0.19%)
:arrow_down:

espn_api/basketball/logger.py
25% <25%> (ø)
:arrow_up:

espn_api/basketball/player.py
26.08% <26.08%> (-1.19%)
:arrow_down:

espn_api/basketball/utils.py
6.66% <6.66%> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a4c257c...bcd7548. Read the comment docs.

Looks good, merging in!


Add support to provision SNP components

Is your feature request related to a problem? Please describe.
Add support to the operator so that it can provision a node with SNP support and create a SNP runtimeclass.
Describe the solution you'd like
Package components needed like other runtimeclasses. The work will mostly be based off of https://github.com/kata-containers/kata-containers/blob/main/docs/how-to/how-to-run-kata-containers-with-SNP-VMs.md guide.

Operator tests is a good start instead of the kata-cc because there is no k8s.
Bundle:

A Containerd config file

QEMU Path, Kernel Path
SNP Guest flags
...

Kata PR https://github.com/kata-containers/kata-containers/pull/5796
Config SEV SNP: https://github.com/kata-containers/kata-containers/pull/6135
https://github.com/kata-containers/kata-containers/pull/6124
https://github.com/kata-containers/kata-containers/pull/6062
https://github.com/kata-containers/kata-containers/pull/5850
OVMF https://github.com/kata-containers/kata-containers/pull/5850. We will need an upstream OVMF.
QEMU: Built with the AMD branch: https://github.com/kata-containers/kata-containers/issues/6061

cc: @fitzthum for more context

Operator PR:

#187

How do you plan to change CI to cover SNP as well?

A new jenkins job, and we'll convert one of the AMD nodes to be SNP capable. But I don't think we'll get that done for v0.5.0.

PRs for SNP testing:
https://github.com/kata-containers/tests/pull/5594
https://github.com/confidential-containers/operator/pull/197

We can close this one, as it's already in.


v4.8.0

@rultor release, tag is 4.8.0

@rultor release, tag is 4.8.0

@maxonfjvipon OK, I will release it now. Please check the progress here

@rultor release, tag is 4.8.0

@maxonfjvipon Done! FYI, the full log is here (took me 3min)


[config-transformer] Function imports are prefixed

When I convert one of our XML files to PHP with the bin/config-transformer switch-format path/to/config.xml command I get the following output:

declare(strict_types=1);

use Symfony\Component\DependencyInjection\Loader\Configurator\ContainerConfigurator;
use function ConfigTransformer202203039\Symfony\Component\DependencyInjection\Loader\Configurator\service;

return static function (ContainerConfigurator $containerConfigurator): void {
    $services = $containerConfigurator->services();
    $services->set('some_service', 'My\Class')
        ->args([service('dependency_class')]);

    // ...
}

Since the prefixed namespace ConfigTransformer202203039\Symfony\Component\DependencyInjection\Loader\Configurator\service does  not exist, symfony throws an error when using this new file.
I tested this with current version 10.1.1 but also with the latest changes from dev-main
It seems like the scoper.php file also prefixes strings, as you can see here https://github.com/symplify/config-transformer/blob/35ea9a0dd9600a5b86c89b50e544359d889c159c/vendor/symplify/php-config-printer/src/ValueObject/FunctionName.php#L8-L27 which in the end leads to the output you see above.

Hi, thanks for reporting :+1:
Could you send a failing test case and fix for this one?


Updated ms.author

Docs Build status updates of commit 0eef2d9:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

mixed-reality-docs/scale.md
:white_check_mark:Succeeded
View

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


usdt: what the default namespace should be?

This is a question that follows #1466.
According to the documentation, it is possible to omit namespace when specifying usdt probe:

Syntax:
usdt:binary_path:probe_name
usdt:binary_path:[probe_namespace]:probe_name
usdt:library_path:probe_name
usdt:library_path:[probe_namespace]:probe_name

Where the probe_namespace is optional, and will default to the basename of the binary or library path.

This suggests that in such case, namespace is set to the basename of the binary.
On the other hand, the code in bpftrace.cpp#L366-L367 indicates that the empty namespace should be expanded as if * was provided. This behaviour is also supported by a test in tests/bpftrace.cpp#L541.
My question is, what do you think the correct behaviour should be? I'd suggest the expansion, but that currently doesn't work since it is not handled correctly in all places in the code, causing the mentioned bug.
Any thoughts?

The wildcard makes sense to me. Should help with writing terser bpftrace scripts. And it'd be a compatible change with the documented behavior (to say nothing of the actual behavior).

There is also a third option - find the namespace automatically but assume that just a single probe with the given name exists. This is also how bcc does it. After some thinking, I start to prefer this solution - it would shorten simple scripts where the namespace is obvious and it would also notify the user when there are multiple probes with the same name. If the user wants to attach to all of them, he must use a wildcard.

Sure, that makes sense too.


I am having a problem

I am installing puppeteer on linux.
sh: node: command not found
npm WARN<EMAIL_ADDRESS>No description
npm WARN<EMAIL_ADDRESS>No repository field.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm ERR! file sh
npm ERR! code ELIFECYCLE
npm ERR! errno ENOENT
npm ERR! syscall spawn
npm ERR<EMAIL_ADDRESS>install: node install.js
npm ERR! spawn ENOENT
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2018-12-24T02_29_59_358Z-debug.log
[root@ip-172-31-43-27 crawler_costco]# node -v
v8.11.3
[root@ip-172-31-43-27 crawler_costco]#
Please help

Provide any additional info based on what command do you use to install puppeteer? What OS build?
Since I have Ubuntu 18.04LT I successfully install Puppeteer with:
apt update
apt upgrade
apt install npm
npm install npm -g
npm install -g puppeteer


Add transparency ordering to individual renderers

Gotta be able to give some renderers priority over others to prevent Z fighting.

Automatically displacing objects to avoid Z fighting is probably beyond the scope of 3.0 beta, but we can can improve the situation with transparency by giving the user some control over the order in which renderers paint. A suggested short term solution is to fire renderers in the order that they are enabled. Thus the last enabled renderer gets drawn last.

I'm not sure if this is working correctly.
To reproduce my failed test:

Spin up Vapor and load KatrinaMaster.nc
Create a TwoD and Contour instance (don't enable)
Enable the TwoD, then enable the Contour
Shouldn't we be able to see the Contour renderer, since it was the last one to be enabled?

This is working. The fix Stas put in does NOT resolve Z fighting. That has to be done manually by translating the rendered images away from each other. The order in which a renderer is activated does impact alpha blending: objects need to be rendered from front-to-back order to for alpha blending to be performed correctly.

This fix needs to be documented

I'm not sure what our current stance is on this one.  Needs discussion.


Include ANIm self vs self in test fixtures

Continues work for https://github.com/pyani-plus/pyani-plus/issues/4 to run nucmer for the ANIm method. Builds on #128, with the goal of logging each a single ANIm comparison from snakemake following the pattern used for ANIb and fastANI.
We need to expand the tests to include self-vs-self in the ANIm targets. This is mostly straightforward, other than an oddity with pyANI v0.3 putting 1 on the diagonal for sim_errors.
Type of change

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

Action Checklist

[x] Work on a single issue/concept (if there are multiple separate issues to address, please use a separate pull request for each)
[ ] Fork the pyani-plus repository under your own account (please allow write access for repository maintainers)
[x] Set up an appropriate development environment (please see CONTRIBUTING.md for this repository)
[x] Create a new branch with a short, descriptive name
[x] Work on this branch

[x] style guidelines have been followed (please see CONTRIBUTING.md for this repository)
[x] new code is commented, especially in hard-to-understand areas
[x] corresponding changes to documentation have been made
[x] tests for the change have been added that demonstrate the fix or feature works

[x] Test locally with pytest-plus -v non-passing code will not be merged
[x] Rebase against origin/master
[x] Check changes with linting/formatting tools before submission (please see CONTRIBUTING.md for this repository)
[x] Commit branch
[x] Submit pull request, describing the content and intent of the pull request
[x] Request a code review
[x] Continue the discussion at Pull requests section in the pyan-plus repository

The ones on the ANIm sim-errors diagonal from pyANI v0.3 was the last hurdle in getting the matrices recorded via snakemake to match the expected output - final part of this pending (could add it to this branch, or make another followup PR shortly).

Note we might alternatively fix pyANI v0.3 to put zeros on the sim-errors diagonal...

It is a one character fix on the pyani side, so I lean to fixing the output there - rather the somewhat fiddly fix proposed here post-processing the output in the fixture generator script.

My plan is once https://github.com/widdowquinn/pyani/pull/439 is merged, I will drop the diagonal fixes from this branch, and re-generate the matrices using the updated pyani instead.

Hi @peterjc. My apologies for missing this code review ealier.
I think there is only one thing that needs to be adressed before this branch can be merged. Hope my comments make sense :)

Do you want to postpone query-vs-subject order to a follow up PR, especially given this likely affects dnadiff as well?

Whichever works best. If you're busy with other tasks, we can merge this as-is, and I'll fix the <query>_vs_<subject> in the next PR for both methods. That way, I can move on to working on #131.

I'm taking your last comment as an implicit PR approval, merging now.


errors when using conda to install r

Hello,
I've been trying to install r and keep getting the following error message. Not sure how to proceed. Appreciate any assistance. Thank you!
Include the output of the command 'conda info' in your report.
Traceback (most recent call last):
File "/home/cdmelloc/anaconda/bin/conda", line 5, in
sys.exit(main())
File "/export/home/cdmelloc/anaconda/lib/python2.7/site-packages/conda/cli/main.py", line 201, in main
args_func(args, p)
File "/export/home/cdmelloc/anaconda/lib/python2.7/site-packages/conda/cli/main.py", line 208, in args_func
args.func(args, p)
File "/export/home/cdmelloc/anaconda/lib/python2.7/site-packages/conda/cli/common.py", line 612, in inner
return func(args, parser)
File "/export/home/cdmelloc/anaconda/lib/python2.7/site-packages/conda/cli/main_install.py", line 46, in execute
install.install(args, parser, 'install')
File "/export/home/cdmelloc/anaconda/lib/python2.7/site-packages/conda/cli/install.py", line 336, in install
minimal_hint=args.alt_hint)
File "/export/home/cdmelloc/anaconda/lib/python2.7/site-packages/conda/plan.py", line 397, in install_actions
config.track_features, minimal_hint=minimal_hint):
File "/export/home/cdmelloc/anaconda/lib/python2.7/site-packages/conda/resolve.py", line 739, in solve
minimal_hint=minimal_hint)
File "/export/home/cdmelloc/anaconda/lib/python2.7/site-packages/conda/resolve.py", line 507, in solve2
clauses = set(self.gen_clauses(v, dists, specs, features))
File "/export/home/cdmelloc/anaconda/lib/python2.7/site-packages/conda/resolve.py", line 342, in gen_clauses
assert len(clause) > 1, '%s %r' % (fn1, ms)
AssertionError: r-base-3.3.1-6.tar.bz2 MatchSpec(u'_r-mutex 1.* anacondar_1')

Closing. @chazdm feel free to open a new issue if you're still having problem install orca with the latest installation instructions:
https://github.com/plotly/orca#installation
Thank you.


 This now causes dirty checking.
A breakpoint in DirtyCheckProperty.prototype.subscribe reveal that this.obj is the array and this.propertyName is 0. I don't know exactly when this new behavior was introduced.

To my knowledge, this was always the behavior. @jdanyow can confirm. It may have worked without dirty checking in Chrome only, back when Array.observe was a spec. Now that it is no longer being standardized, it has been removed.
Fundamentally, without Array.observe, there is no way to detect changes in indexed items of arrays without dirty checking.
@jdanyow may have some recommendations on alternatives though.

I spoke with @jdanyow in a private gitter and he asked me to log this issue.
I only use Chrome at this stage so you might be right that it only worked with Chrome.
This is not an important feature for us. We rewrote our code in a way that does not bind to an array by index.

@jdanyow I think, minimally, the new databinding docs should probably call out the things that will cause dirty checking and maybe even provide various workarounds for that, if possible.

Early on AccessKeyed didn't observe foo.bar when the binding expression was foo[baz] (baz === 'bar').
Now it does: https://github.com/aurelia/binding/blob/master/src/ast.js#L320
I think we may need to add some additional logic to that ^^^ if-statement to skip observing that part of the expression if key is a number and obj is an array.  The reason being, we can only observe keyed array assignment using dirty-checking so it might be better to go back to the old behavior which didn't observe that part of the expression.
Thoughts?

That sounds reasonable to me :)

For the developer whose code was depending on this functionality there code is broke now. How to achieve the same thing -
Below is the explanation by @jdanyow on gitter -

another user reported an issue because they noticed the binding system was using dirty checking to observe an indexed access of an array
for example, in this expression: displayfieldtype[$index], the old version of aurelia was observing three things:
bindingContext.displayfieldtype
bindingContext.$index
displayfieldtype.$index
in the past, when we had Object.observe, this was all fine. But without O.o, #3 requires dirty checking (which is what the user reported as an issue)
so we stopped observing #3
which is probably causing your issue

How we can achieve same behavior as before or what is the alternate way to do this.


Allow for non-dictionary hyperparameters in automate_training

Description
This pull request does 4 things:

Enable users to use hyperparameters which are not dictionaries in automate_training. For example, the parameter command currently won't work, because it is not a dictionary. We would like to allow for a hyperparameter config file which allows for a format such as:

    {
        'training_parameters': {
            'batch_size': [2, 64],
            'loss': [
                {'name': 'DiceLoss'},
                {'name': 'FocalLoss', 'gamma': 0.2, 'alpha': 0.5}
             ]
        },
        'default_model': {
            'depth': [2, 3, 4]
        },
        'command': ['train', 'test'] # this is not currently allowed
    }

Refactor to simplify the logic in creating the config lists. One issue was that two dictionaries were being zipped together, (param_dict and names_dict), and the order of this mattered. However, Python dictionaries do not conserve order, and so zipped dictionaries are not guaranteed to be in the right order.
Add unit tests for automate_training under unit_tests/test_automate_training.py
Add an example under the Tutorials section in the docs on how to use ivadomed_automate_training

Linked issues
Resolves: https://github.com/ivadomed/ivadomed/issues/587

Pull Request Test Coverage Report for Build 529138993

129 of 138 (93.48%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.7%) to 76.045%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

ivadomed/scripts/automate_training.py
102
111
91.89%

Totals

Change from base Build 519426625:
0.7%

Covered Lines:
5368

Relevant Lines:
7059

💛  - Coveralls

1. Enable users to use hyperparameters which are not dictionaries in `automate_training`.

Very much needed, indeed, thank you!

1. Refactor to simplify the logic in creating the config lists. One issue was that two dictionaries were being zipped together, (`param_dict` and `names_dict`), and the order of this mattered. However, Python dictionaries do not conserve order, and so zipped dictionaries are not guaranteed to be in the right order.

We faced so many issues with that in the past in this script.. thanks for fixing it!!

1. Enable users to use hyperparameters which are not dictionaries in `automate_training`.

Very much needed, indeed, thank you!

1. Refactor to simplify the logic in creating the config lists. One issue was that two dictionaries were being zipped together, (`param_dict` and `names_dict`), and the order of this mattered. However, Python dictionaries do not conserve order, and so zipped dictionaries are not guaranteed to be in the right order.

We faced so many issues with that in the past in this script.. thanks for fixing it!!

1. Enable users to use hyperparameters which are not dictionaries in `automate_training`.

Very much needed, indeed, thank you!

1. Refactor to simplify the logic in creating the config lists. One issue was that two dictionaries were being zipped together, (`param_dict` and `names_dict`), and the order of this mattered. However, Python dictionaries do not conserve order, and so zipped dictionaries are not guaranteed to be in the right order.

We faced so many issues with that in the past in this script.. thanks for fixing it!!

No problem!!


Animation components that can take any React Component and apply animations to them.

I want to write a component that could be used throughout the project ,
for eg , we could give it args [hide, show, rotate ]
Pros-
Easy to debug
Consistent look and feel (everyone could give a different time when performing anim, this would prevent that)
Cons-
Every PR merge must be checked that it uses our animations
Thoughts @twishasaraiya ?

@prophet It is not yet decided which components will be animated in which way. We will be animating DOM elements by selecting experimenting and discuss what would look better. Since GreenSock is a very powerful API we can create some very interesting Animations.
Moreover having a separate componet would not be required since we can do the following
import TweenMax from 'gasp'
class SampleComponent extends React.Componet{
componentDidMount(){
   TweenMax.to(DOM Id, duration, {CSS Property Object });
  }
render(){...}
}

Please do let me if you have any doubts.

Yes thats my point
Imagine one dev make Component1 and other Component2
It'll be hard to force consistency in animations Component 1 may animate for 0.5 sec and Component2 may animate for 0.3 sec
That would produce a really bad and inconsistent ui experience.
So i was suggesting if we could make an animation wrapper ,which would animate a views for anyone who want to make ui component
That would seperate the concern as well So that everyone wouldnt have to know how to animate when they're making a component that is consistent to our app

@prophet1996 I understand different developers will animate stuff differently. That's the reason we will be first developing the entire page including all components and then animation them. One single developer could take an entire page to animate the DOM elements after discussing with others. Once the basic quiz app is running (without animations)  we can discuss further on how to add animations. Besides for now you can work on Landing Page design and animations.


Enable sharing of pn_tls_config_t across TLS sessions

This is regards to a comment by @cliffjansen - https://github.com/skupperproject/skupper-router/pull/765#pullrequestreview-1134515021
This needs to be addressed so there can be an efficient sharing of  pn_tls_config_t object across TLS sessions.

fixed on merge of #810


[Snyk] Security upgrade node from 12.10-buster to 22.8.0-bookworm-slim

Snyk has created this PR to fix 2 vulnerabilities in the dockerfile dependencies of this project.
Keeping your Docker base image up-to-date means you’ll benefit from security fixes in the latest version of your chosen image.
Snyk changed the following file(s):

Dockerfile

We recommend upgrading to node:22.8.0-bookworm-slim, as this image has only 33 known vulnerabilities. To do this, merge this pull request, then verify your application still works as expected.
Vulnerabilities that will be fixed with an upgrade:

Issue
Score

Out-of-bounds Write SNYK-DEBIAN10-LIBWEBP-5893093
  829

Out-of-bounds Write SNYK-DEBIAN10-LIBWEBP-5893093
  829

Out-of-bounds Write SNYK-DEBIAN10-LIBWEBP-5893093
  829

Out-of-bounds Write SNYK-DEBIAN10-LIBWEBP-5893093
  829

CVE-2023-44487 SNYK-DEBIAN10-NGHTTP2-5953390
  829

[!IMPORTANT]

Check the changes in this PR to ensure they won't cause issues with your project.
Max score is 1000. Note that the real score may have changed since the PR was raised.
This PR was automatically created by Snyk using the credentials of a real user.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
📜 Customise PR templates
🛠 Adjust project settings
📚 Read about Snyk's upgrade logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Learn about vulnerability in an interactive lesson of Snyk Learn.

This PR has been marked as stale because it has had no activity in the last 21 days. It will be closed in 3 days if there is no further activity.

This PR has been automatically closed due to inactivity.


Fix enum int comparison

Fix enum int comparison by set the enum value as a int constant
Should Fix #50293

Thanks!

This leads to #56878.
Enums are particularly tricky at the moment. 2 DataType kinds, ENUM and ENUM_VALUE are currently shared for 3 different things:

enum values (Test.One)
variables with enum types (x in var x: Test)
and the actual enum types themselves (Test)


possible bug with teensyTimerTools

Am attempting to run as high a number of steppers on a single teensy3.x  as practicable
need   around 15000PPS max
trying teensyTimerTool   example     but no success
step output defaults to    499.75Hz
regardless of requested spin speed    both positive and negative
except  stepper.spin(0)  where no output at all
is this a fault or incorrect usage
is there a better way to achieve objective?
TIA
Harry Harrison

Hi Harry,
I'm using TeensyTimerTool on a Teens 4.1 at 6000 steps/s, and I'm pretty sure it also worked at 10K.
However, I don't know if 15KHz is possible.
Maybe you should try PWM with ContinuousStepper_AWF.
Best regards,
Benoit

Thanks
will try
Harry


Added table output for slowest tests

Following this discussion on abandoned PR: https://github.com/adamchainz/django-rich/pull/30#issuecomment-2282269423
I found that using a Rich Table to draw the results looks quite nice:

@smithdc1 any thoughts?

Hi Adam -- wow that was quick! A few comments this morning before I head off to the office.

I like using the table layout. One suggestion would be to switch the order of the columns. I think typically in a table you'd have the description first and then the value.

In your image the table is very green, but it is white for me. That must be a terminal setting?

I wondered about using table.caption for the message about hidden durations, but I don't really have a strong opinion on doing this way vs the layout currently proposed. See img below for how it looks without adding any customisation to the caption style/justification.

Hi Adam -- wow that was quick!

Heh, yeah, I was up for a low-stakes open source issue to take my mind off work things!

A few comments this morning before I head off to the office.

Thanks! 🙏

I like using the table layout. One suggestion would be to switch the order of the columns. I think typically in a table you'd have the description first and then the value.

Yes, true. I copied the default output from unittest. I can see two reasons to keep duration first, though. First, it’s much shorter - test paths can get very long, clipping the durations. Second, the durations are probably more relevant information. If your slowest test takes <1s, you might not care about optimizing. If it’s, say, 10s, then you might perk up and be interested, regardless of which test it is
So I think I’ll keep order as-is for now.

In your image the table is very green, but it is white for me. That must be a terminal setting?

Yeah, green-on-black is my terminal theme, because I’m a cool hacker from The Matrix.

I wondered about using table.caption for the message about hidden durations, but I don't really have a strong opinion on doing this way vs the layout currently proposed. See img below for how it looks without adding any customisation to the caption style/justification.

Yes, the caption feature is neat. Changing to use it.


about the psp computing and the desired inputs

Thanks for sharing your job. And I have two questions?
1、The psp computing, In my opinion, dv/dt = -v + RI, and  syn = syn - syn / tau_s + inputs[..., t], so why should syns[...,t] = syn/ tau_s
2. Why did you define the desired output when n_steps >=10 like [0 1 0 1 0 1 0 1 0 1]
In the 5 steps, I can understand may be the first time step, it can not spike, so it is [0 1 1 1 1]
Thanks very much

Thanks for your interest in our work.
1.For the synaptic kernel, usually, the inputs in "syn = syn - syn / tau_s + inputs[..., t]" should be divided by tau_s so that its integration through all the time equals 1.
2. The desired output is manually defined. We didn't explore what kind of output is better for training in this work. You can set it to any other spike trains you want.

Thanks for your interest in our work.
1.For the synaptic kernel, usually, the inputs in "syn = syn - syn / tau_s + inputs[..., t]" should be divided by tau_s so that its integration through all the time equals 1.
2. The desired output is manually defined. We didn't explore what kind of output is better for training in this work. You can set it to any other spike trains you want.

Ok, thanks for your reply

Ok, thanks for your reply


allow dashes, periods, and other RFC6838-compliant characters in header vendor

The current accept header parsing logic treats everything after the first - as the version, whereas it's not uncommon to have dashes in more complex vendor/resource media type definitions (an IANA-registered example is application/vnd.ms-office.activeX+xml)
This change correctly handles dashes in the vendor part, while still assuming what's after the last dash is the version.
The current logic also doesn't allow underscores, ampersands, etc, which are allowed media type characters per RFC 6838. This change makes Grape itself handle these characters correctly, however for them to actually work is contingent on https://github.com/mjackson/rack-accept/pull/17 which unfortunately has been open for more than 6 months (I'll ping maintainer again, but any weight you can throw around there would also be appreciated :smile:)
P/S: It should be noted that the current header versioning logic is very limited and doesn't support formats such as application/vnd.github.v3+json (as what github uses now) I'll try to add a caveat in the README while I add the CHANGELOG entry for this

This is good. It needs a CHANGELOG entry and possibly a README update, please.
I would be down with a monkey-patch of rack-accept and a corresponding test. We have some precedent for patches in https://github.com/ruby-grape/grape/pull/1167 where we monkey-patched virtus.

@dblock I've updated the CHANGELOG, added a README section about Grape's limitations with the structure of versioned mediatypes, and converted those regexes to constants like recommended by @aselder
I'm thinking I can make a followup PR where the appropriate rack-accept call is monkey-patched to allow all the RFC-compliant characters, once this PR is merged.

Merging.


Make it possible to use type "area" for area cards instead of Mushroom template card

What
This provides an option to use type: area instead of mushroom-template-card for Areas, by configuring use_type_area: true.
Along with that an option is also added to set common options for all area cards. Example:
strategy:
  type: custom:mushroom-strategy
  options:
    areas:
      _:
        use_type_area: true

Of course it was already possible to override type in mushroom-strategy, but that wouldn't work with the type: area, since it also requires area: <area id>.
Why

The built in area card in Home Assistant supports pictures, which means that the user of mushroom-strategy now does not have to provide picture URLs for every area.
The built in area-card shows pictures on the entire card, making it easier to see what is on the image (compared to the mushroom template card which only shows the picture as a round icon).

Example
Example of how it can look:

@AalianKhan @ajagnanan would love to hear your input on this 😄

I think it's a good addition! Is there a way to move the section header Areas to align in the right column with the areas? That's happening on my dashboards as well.

@johanfrick Thank you for your effort in enhancing the strategy.
I do like the looks, but I have some objections also...

It's called Mushroom Strategy, designed to auto-populate the dashboard with Mushroom cards, whenever useful and possible.
I'm not sure we should mix all kind of card-styles together, but to keep it at a minimum instead.

I.m.o., If adding support for the HA Area Card, the way to go is to add a new class to the package.
The sole purpose of the current AreaCard class is to create a Mushroom-styled area card.

Adding properties to the configuration is allowed, so the following example should work.
(However, additional properties may be incompatible with Mushroom Strategy.)

    areas:
      biljardrum:
        type: area
        area: biljardrum
        navigation_path: biljardrum

My advice to @AalianKhan is to enable the discussion in the settings of this repository to talk about this request and/or poll the user's opinions.

Yeah, you make a fair point that this is a strategy for Mushroom cards. However, this is also the greatest strategy I've seen for Home Assistant and I think the crowd can be made a lot wider if we allow some more customisation. Many people prefer Mushroom cards and nothing else, but not everyone does.
That being said, I'll give it another think how I can "hide" the intention of not using Mushroom card for some parts. Probably by moving more to the user's configuration of mushroom-strategy.
But let me know if it is not worth the effort, and I'll move forward by only maintaining my own fork.

Locked to continue the discussion at #58

I've unlocked this PR so the commits can be discussed.
Please discuss the more generic things in the discussion: #58

Please review again @DigiLive . I have updated the code according to your comments. I have also updated the README, and the PR description.

@DigiLive Ready for another review. I have updated according to your comments.

Please don't push any other commits as I'm reviewing and tweaking locally now.
I really want to avoid merge conflicts at this point.

@johanfrick Can you evaluate my code changes, please?

@DigiLive I have evaluated the code. It looks reasonable to me. I have also verified it by trying it out locally. I am happy to go forward with this solution. 👍

Anything else needed before merging?

This looks well if the rooms have no temp/humidity sensors. If there are sensors for an area, they show up in the area card and therefore the UI looks too narrow and bad. The easiest solution would be to make them appear in one column.


Bug bounty test - PLEASE DO NOT APPROVE. sauzvq

Bug bounty test - PLEASE DO NOT APPROVE. sauzvq

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


Prepare release azure functions maven plugin

Update function plugin version to 1.5.0 and update release notes
Update function plugin dependencies

Codecov Report

Merging #1087 into develop will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             develop    #1087   +/-   ##
==========================================
  Coverage      36.12%   36.12%
  Complexity       542      542
==========================================
  Files            103      103
  Lines           4482     4482
  Branches         693      693
==========================================
  Hits            1619     1619
  Misses          2717     2717
  Partials         146      146

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 259a2a5...980272b. Read the comment docs.


DOC: scipy.stats: fix documentation issues of multivariate distributions

Reference issue
Addresses #12848
What does this implement/fix?

It checks the first four boxes of issue #12848 and fixes the documentation issue (shown below) of the Notes section.

@mdhaber, @WarrenWeckesser Would appreciate a discussion on the last two boxes (https://github.com/scipy/scipy/issues/12848#issuecomment-731553906) and whether the other inconsistencies (as pointed out in https://github.com/scipy/scipy/issues/12848#issuecomment-731553197) should be resolved here. Thanks!

Some parameters of the methods (e.g. size, abseps, releps) are not defined

I think the suggestion above to have separate "Class Parameters" and "Method Parameters" sections would address this.

Related to the problems above, and true of univariate distributions, too: method names do not link to any documentation

Let's tackle this in a separate PR. It's a bigger, more widespread stats issue.

random_correlation, ortho_group, and unitary_group (multivariate) distributions don't have a frozen distribution class

True, but that doesn't need to be addressed here. Especially if we distinguish between class and method parameters, then it becomes more clear why some parameters are defined at the top of these pages despite them not being used to create a frozen distribution.

matrix_normal distribution has parameter X (capital x) in its pdf and logpdf methods which is inconsistent with other distributions (that have a lower case x instead).

I think that's intentional because it's supposed to be a matrix. But if we have "method parameters" defined in each class documentation page, we can define X there.

I might want to take back what I wrote above and push for a more

I might want to take back what I wrote above and push for a more complete solution. I'll look into how to do it.

Erg let's just make incremental improvements as we can. No sense in leaving this open forever.

Erg let's just make incremental improvements as we can. No sense in leaving this open forever.

Sorry for stalling this for so long. Since no one has taken this up, let's just finish it! I'll look into Sphinx docs and see what I can find.

We're getting a lot of "Math Processing Error"

Do you have any new ideas for getting the Methods to auto-render and link to the documentation of each method?

We can write an extension to do that since I don't think there is a way to tell sphinx to render methods of an object that isn't a type.

If not, then let's remove method parameter documentation from the "Parameters" sections here, merge this, and tackle documenting the methods properly in a separate PR

That sounds good for now!

Aside from the comments above, this is ready and is a good step in the right direction. It does what it says it does: addressing the first four bullets of gh-12848 and then some.
As a follow-up, it would be great to write that extension that allows us to actually render the method documentation, but for now, it is good to define only the parameters of the __call__ method in the top-level multivariate distribution documentation rather than mixing and matching.

If the last commit fixed the things it was supposed to, let's merge. This PR improves the appearance a lot.
Next, let's try to get the method-specific documentation to render. At that time, I think we'll need to distinguish between _doc_random_state and _doc_seed. (Alternatively, we could actually fix the problem and standardize the name to random_state (accepting seed via *kwds for backward-compatibility.)
I see you noticed that random_correlation, ortho_group, and unitary_group weren't freezable here. I promoted that to its own issue.
There is some justification for matrix_normal having X instead of x, since it's a matrix distribution. I agree that it looks funny and it could have been x, but since there is some justification I'm less bothered by this than the rest. Wouldn't mind having it accept both.

If the last commit fixed the things it was supposed to, let's merge.

Sounds good. Thanks for the last change.

The things I intended to fix with that last commit seem fixed. Let's get this in. Thanks @tirthasheshpatel!


Downvote in Q&A bug

Describe the bug
When i press the downvote twice , the upvote is decreasing .
To Reproduce
Steps to reproduce the behavior:

Go to 'Q&A'
Click on 'Downvote twice'
. See error

Expected behavior
Each user can vote only once
Screenshots

Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Assign this under GSSOC'24
Have you read the Code of Conduct?
Yes

@mukilan2815  thanks for pointing, this logic was bugging me, currently the total upvotes is just shown but ideally total upvotes and total downvotes should have been shown. I would be more that happy if u can fix that logic

Hey @Kajol-Kumari
Assign me the issue