Class mixins shouldn't require a specific signature of constructors

TypeScript Version: 2.2.0-dev.20170209
Code
Requiring mixins to have a constructor signature of constructor(...args: any[]) causes a few problems:

Node v4, which is an active LTS, doesn't support rest and spread syntax. We avoid it and can run our output on Node v4 even when targeting ES6. The mixin constructor requirements prevent this.

It's common to have mixins that want to provide a specific constructor. These will usually be applied last to create a concrete class. This is impossible now, so you have to create a new concrete class with only a constructor to give it the correct signature.

For a mixin that does have constructor argument requirements, it's very cumbersome to extract arguments out of ...args.

Here's an approximation of a case I hit. I have two classes that that share a base class:
class Base {
  foo: string[];
}

class A extends Base {}

class B extends Base {}

Later, I want to add some functionality to via mixins to create two new classes:

type Constructor<T extends object> = new (...args: any[]) => T;
interface Magic {}
const Magic = <T extends Constructor<Base>>(superclass: T): Constructor<Magic>& T =>
  class extends superclass implements Magic {
    constructor(foo: string[]) {
      super();
      this.foo = foo;
    }
  };

const MagicA = Magic(A);
const MagicB = Magic(A);

And I want MagicA and MagicA to have a constructor that takes a single argument. I know the code will work because I know the constructors of A and B, but the type checker is unhappy.
First, the Constructor type is wrong in this case because I know the signature I want. I'd actually like to write:
type BaseConstructor = new() => Base;
type MagicConstructor = new(foo: string[]) => Magic;
interface Magic {}

const Magic = <T extends BaseConstructor>(superclass: T): MagicConstructor & T =>
  class extends superclass implements Magic {
    constructor(foo: string[]) {
      super();
      this.foo = foo;
    }
  };
const MagicA = Magic(A);
const MagicB = Magic(A);

Expected behavior:
This works
Actual behavior:
Error: "Type 'T' is not a constructor function type." on the extends clause.

+1 - My use case is also about constructor dependency injection. My mixin restricts the possible base classes, and that base class has constructor dependencies. I would like to force subclasses of the mixin to provide the correct dependencies to the constructor. Just like is possible with regular (sub)classes. And if the constructor signature of the restricted base class changes, then there should be compilation errors.
I currently use the following workaround:
class MyDependency {
}

class MyBaseType {
    // Changing the constructor signature here will not cause an error
    // inside the MyMixin constructor
    constructor(readonly dep: MyDependency) {
    }
}

type Constructor<T extends object> = new (...args: any[]) => T;

type MyBaseTypeConstructor = new (dep: MyDependency) => MyBaseType;

function MyMixin<T extends MyBaseTypeConstructor>(base: T) {
    // Ideally this cast would not be required
    // For now it solves the "Type 'T' is not a constructor function type"
    const baseConstructor: Constructor<MyBaseType> = base;

    return class extends baseConstructor {
        constructor(dep: MyDependency) {
            super(dep); // This call is not type-checked, because of ...any[] rest argument
        }
    };
}

class ExampleUsage extends MyMixin(MyBaseType) {
        constructor(dep: MyDependency) {
            super(dep); // This should be type-checked to be the same signature as MyBaseType
        }
}

With this workaround, changing only the MyBaseType constructor signature will give you compilation errors (which is what I want). However, you should not forget to change the MyMixin constructor after changing MyBaseTypeConstructor to the correct signature, since you will not get any more errors after changing just MyBaseTypeConstructor. That would be a problem, because subclasses of MyMixin should cause compilation errors at this point. Luckily, after updating the constructor inside MyMixin you will get the remaining errors which you would need to fix.

Another common pattern in JavaScript is to pass an options object containing properties that any constructor can read, regardless of order. Any constructor in the super() call stack can just pluck whatever it needs.
function Foo(Base = class {}) {
  return class Foo extends Base {
    constructor(options) { console.log(options.foo) }
  }
}

function Bar(Base = class {}) {
  return class Bar extends Base {
    constructor(options) {
      console.log(options.bar)
    }
  }
}

class Baz extends Foo(Bar()) {
  constructor() {
    super()
  }
}

@trusktr With type assertions anything is possible 😊. This well for the users of the mixin (although authoring the mixin is a bit of dark magic):
type ComposeConstrucrtor<T, U> =
    [T, U] extends [new (a: infer O1) => infer R1,new (a: infer O2) => infer R2] ? {
        new (o: O1 & O2): R1 & R2
    } & Pick<T, keyof T> & Pick<U, keyof U> : never

function Foo<T extends new (o: any) => any>(Base: T) {
    class Foo extends (Base as new (...a: any[]) => {}) {
        constructor(options: { foo: string }) {
            super(options)
            console.log(options.foo)
        }
        foo() {}
        static foo() {}
    }
    return Foo as ComposeConstrucrtor<typeof Foo, T>
}

function Bar<T extends new (o: any) => any>(Base: T) {
    class Bar extends (Base as new (...a: any[]) => {}) {
        constructor(options: { bar: string }) {
            super(options)
            console.log(options.bar)
        }
        bar() {}
        static bar() {}
    }

    return Bar as ComposeConstrucrtor<typeof Bar, T>
}

class Baz extends Foo(Bar(class { }))  {
    constructor(options: { foo: string, bar: string, whatever: string }) {
        super(options)
        console.log(options.whatever)
    }
    baz() {}
    static baz() {}
}
let baz = new Baz({ bar: "", foo: "", whatever: ""});
baz.bar();
baz.baz();
baz.foo()

Baz.foo();
Baz.bar();
Baz.baz();

@trusktr With type assertions anything is possible 😊. This well for the users of the mixin (although authoring the mixin is a bit of dark magic):
type ComposeConstrucrtor<T, U> =
    [T, U] extends [new (a: infer O1) => infer R1,new (a: infer O2) => infer R2] ? {
        new (o: O1 & O2): R1 & R2
    } & Pick<T, keyof T> & Pick<U, keyof U> : never

function Foo<T extends new (o: any) => any>(Base: T) {
    class Foo extends (Base as new (...a: any[]) => {}) {
        constructor(options: { foo: string }) {
            super(options)
            console.log(options.foo)
        }
        foo() {}
        static foo() {}
    }
    return Foo as ComposeConstrucrtor<typeof Foo, T>
}

function Bar<T extends new (o: any) => any>(Base: T) {
    class Bar extends (Base as new (...a: any[]) => {}) {
        constructor(options: { bar: string }) {
            super(options)
            console.log(options.bar)
        }
        bar() {}
        static bar() {}
    }

    return Bar as ComposeConstrucrtor<typeof Bar, T>
}

class Baz extends Foo(Bar(class { }))  {
    constructor(options: { foo: string, bar: string, whatever: string }) {
        super(options)
        console.log(options.whatever)
    }
    baz() {}
    static baz() {}
}
let baz = new Baz({ bar: "", foo: "", whatever: ""});
baz.bar();
baz.baz();
baz.foo()

Baz.foo();
Baz.bar();
Baz.baz();

@trusktr With type assertions anything is possible 😊. This well for the users of the mixin (although authoring the mixin is a bit of dark magic):
type ComposeConstrucrtor<T, U> =
    [T, U] extends [new (a: infer O1) => infer R1,new (a: infer O2) => infer R2] ? {
        new (o: O1 & O2): R1 & R2
    } & Pick<T, keyof T> & Pick<U, keyof U> : never

function Foo<T extends new (o: any) => any>(Base: T) {
    class Foo extends (Base as new (...a: any[]) => {}) {
        constructor(options: { foo: string }) {
            super(options)
            console.log(options.foo)
        }
        foo() {}
        static foo() {}
    }
    return Foo as ComposeConstrucrtor<typeof Foo, T>
}

function Bar<T extends new (o: any) => any>(Base: T) {
    class Bar extends (Base as new (...a: any[]) => {}) {
        constructor(options: { bar: string }) {
            super(options)
            console.log(options.bar)
        }
        bar() {}
        static bar() {}
    }

    return Bar as ComposeConstrucrtor<typeof Bar, T>
}

class Baz extends Foo(Bar(class { }))  {
    constructor(options: { foo: string, bar: string, whatever: string }) {
        super(options)
        console.log(options.whatever)
    }
    baz() {}
    static baz() {}
}
let baz = new Baz({ bar: "", foo: "", whatever: ""});
baz.bar();
baz.baz();
baz.foo()

Baz.foo();
Baz.bar();
Baz.baz();

@justinfagnani On a related note, have you had any problems using mixins inside of other mixins? It doesn't seem to work, saying ___ is not a constructor function when applying a mixin in the extends part of another mixin: https://github.com/microsoft/TypeScript/issues/32004


"wrapSelection.patterns" won't work in settings.json

I tired adding your wrapSelection.patterns from your readme file to my settings.json:
"wrapSelection.patterns": {
		"log": "console.log(`${text}`, ${text})",
		"promise": "new Promise((yeah, nah) => yeah(${text}))",
		"=>": "() => ${text}"
	}

But VS code says "Unknown configuration setting".
And I can't add custom wrapping patterns.
Am I doing anything wrong?

same question

Having the same problem here. And when I search Settings for @ext:konstantin.wrapSelection, nothing comes up.

Yep. Not working 😆

Fixed in version 0.7.0
Sorry for the delay 😔


chore: Bump cypari2 to 2.1.5 and document new Python requirements

This will reconcile development and production versions, while maintaining the ability to develop on Ubuntu 20.04.

Kate, your situation is most relevant to this PR, hence the request to you if you have time before you go.


Update the Azure.Monitor installation command

If not specify the released version, installation of Azure.Monitor will return error:There are no stable versions available.
Update the command by specifying the latest version -v 1.0.0-beta.3

@ChenCheng368 : Thanks for your contribution! The author(s) have been notified to review your proposed change. @peiliu

@ktoliver : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#label:"aq-pr-triaged"

@minnieliu Could you review the proposed update?
Also, note that the metadata author attribute should contain your Microsoft-linked GitHub user name. Thanks!

@ChenCheng368 This is very stale now, is it still needed?

@ChenCheng368 @ProbablePrime - Can you review this old PR and determine whether it needs to be closed or merged?
IMPORTANT: When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.

#sign-off


Make the process-pull-requests (Rosie) calls in the jobs get skipped if $PULL_REFS is set

Extracted from e-mail discussion @stevekuznetsov

Should be able to do
if [[ -z "${PULL_REFS:-}" ]]; then
    process-pull-requests ...
fi

We'll need to make the change in `sjb/templates/test_case.xml.

Is this template generated from somewhere or we need to do the change directly into it?

Btw I only see test_pull_requests being called in there.

The template is the source of truth, no need to update anywhere. Yes, sorry, test_pull_requests is the name of the Ruby script.


Update production

Coverage remained the same at 100.0% when pulling ba518d3dc7bf2a286a8667a466e94f05dd7bf2bd on dev into 2ccf66afa4568b543130f3978f78015e88ee7109 on production.


Fix inline kwargs parsing to not consider all inline hashes kwargs

Hashes that are implicitly constructed in method sends like foo(10 => 20) were being treated as keyword arguments, which could lead to crashes in dispatchCallSymbol and further down the pipeline.
Motivation

Fixing problems with keyword arguments that can lead to crashes.
Test plan

See included automated tests.

We have a policy of testing changes to Sorbet against Stripe's codebase before
merging them. I've kicked off a test run for the current PR.  When the build
finishes, I'll share with you whether or how it failed. Thanks!
Stripe employees can see the build results here:
→ https://go/builds/bui_IyioeAL9gb5gfW
→ https://go/builds/bui_IyioHVnL1dNYxU

We have a policy of testing changes to Sorbet against Stripe's codebase before
merging them. I've kicked off a test run for the current PR.  When the build
finishes, I'll share with you whether or how it failed. Thanks!
Stripe employees can see the build results here:
→ https://go/builds/bui_IzjSZao9qGBEQE
→ https://go/builds/bui_IzjSI4M9RFvWn3

Successful run on stripe-ci here: https://go/builds/bui_Izkz1tm4bgAlnS


Split up this value for shows; Sonarr - Number of seasons / episodes (also unavailable)

Is your feature request related to a problem? Please describe.
No
Describe the solution you'd like
What I would like to see is the following. I currently need to select media type season to be able to use the following:
        - operator: AND
          action: equals
          firstValueName: Plex - Amount of available episodes
          firstValue: 1
          secondValueName: Sonarr - Number of seasons / episodes (also unavailable)
          secondValue: 12
          result: false

However, I personally think this option should also be available when selecting media type show. This would allow for a more granular approach. Currently it will automatically select amount of seasons, instead of episodes when media type show is selected. Having to switch to season could end up removing just a few seasons instead of the entire show, or requires a lot of workaround to make that work..
Describe alternatives you've considered
None, I have not managed to work around it. Splitting it would be the best of both worlds.
Additional context
No

I believe this should become a separate show-only rule. It's definitely doable!


Network specific address decoding

Issue 1
Currently indexer decodes and stores SS58 addresses in a generic Substrate format, i.e with prefix 5. I think it would be good enhancement to make it detect the format prefix and decode addresses as belonging to the specific network. Polkadot addresses start with a prefix 1, Kusama G, H, F, etc. letters.
For more information about address formats, click here.
This PR will fix this issue by detecting network address prefix and injecting it to registry, so that addresses are stored in a correct format.
Issue 2
If you try to index remote Substrate archive node, both Scanner and Indexer fails to connect to websocket address with this error:
Error: WebSocket is not connected

The code is:
  ...
  const wsUrl = 'wss://kusama-rpc.polkadot.io';
  const wsProvider = new WsProvider(wsUrl, 100);

  const scanner = new Scanner({
    wsProvider,
  });
  ...

Strangely this error disappears if you instantiate ApiPromise from the WsProvider instance.
...
  const wsUrl = 'wss://kusama-rpc.polkadot.io';
  const wsProvider = new WsProvider(wsUrl, 100);
  const _api = await ApiPromise.create({ provider: wsProvider });

  const scanner = new Scanner({
    wsProvider,
  });
...

This issue arises only while indexing remote nodes, local sync nodes work fine.
Changes made in the indexer.ts file also fix this issue.

About issue2. I ran the test case (it connects to wss://kusama-rpc.polkadot.io, use the command npx jest Scanner.test to run) and there is no Error: WebSocket is not connected.
.

About issue2. I ran the test case (it connects to wss://kusama-rpc.polkadot.io, use the command npx jest Scanner.test to run) and there is no Error: WebSocket is not connected.
.

Test cases run fine. The issue arises when I try to run a scanner or indexer in a NodeJs file.

About issue2. I ran the test case (it connects to wss://kusama-rpc.polkadot.io, use the command npx jest Scanner.test to run) and there is no Error: WebSocket is not connected.
.

test passes for me as well, but if you try to run a script using Scanner or Indexer it won't connect to remote websocket address. See examples here

About issue2. I ran the test case (it connects to wss://kusama-rpc.polkadot.io, use the command npx jest Scanner.test to run) and there is no Error: WebSocket is not connected.
.

test passes for me as well, but if you try to run a script using Scanner or Indexer it won't connect to remote websocket address. See examples here

I did not find the error.
> node scanner.js
blockN: 4816032 - author: H7Ycyo6X2MQvmNMCFcPbGUiD4bhj3Mhr3oNNmuzHF5d2dmX


boards: holyiot_yj16019: Fix radio capabilities

holyiot_yj16019 board uses nRF52832 SoC, which does not have 802.15.4
radio. Therefore, 802.15.4 should not be listed in it's capabilities.
Fixes #17480.
Signed-off-by: Robert Lubos<EMAIL_ADDRESS>

@rlubos if this is to be back-ported, pls, add the label

@ioannisg holyiot_yj16019 board doesn't seem to be present in the 1.14 branch


Buckets of elements of different sizes

I am attempting to use webdataset to support loading a dataset with subsections/buckets organized by image size.
To do this, I've organized the files such that each bucket has its own designated folder, each filled with tars of images of that size, then create a webdataset object for each. then each dataset is made into an iterator object just calling datasets[i] = iter(datasets[i]), and then at each step of training, sample a random index. weighted by the number of elements we have precalculated, and call next() to get a batch
However this seems to be causing memory issues that scale in some unusual ways.
On

2 nodes, 6 workers, the training survives 1 step before running out of memory
2 nodes, 2 workers, it survives for 6 steps
2 nodes, 1 worker we get 14 steps in
and at 1 node, 2 worker you can get in a whole 270 steps.

looking a cpu memory usage, it seems to increase ~7gb with each step give or take, but given a 1TB RAM allownace it often dies before hitting that limit
Have tried some other experiments to better understand this as well. for instance, trying out only 2 datasets, and trying to alternate between the two every 4 steps. To get a sense of, is it the switching itself thats causing the issue? does memory continue to increase with each switch? after switching does it stay constant.
Does this seem like a logical way to approach what I am trying to do? If not, are there any other possible solutions through webdataset? Previously having worked with dataloaders that sample from subbuckets, I've used the map style datasets through torch making use of the sampler object you can pass through

Sorry for the long delay.
WebDataset does not retain any samples unless you ask it to explicitly (e.g. in a shuffle buffer).
In you case, just be sure not to use shuffle in each of the component datasets; instead, create a new IterableDataset and then pipeline that with the shuffle method. The code looks something like this:
class MyBucketSampler(IterableDataset):
    ...
    def __iter__(self):
        ...

bucketsampler = MyBucketSampler(...)

dataset = wds.DataPipeline(
    bucketsampler,
    wds.shuffle(...),
    wds.batched(...),
)

I think your code bucketsampler should be an iterator that randomly samples from all the tarfiles of every bucket. In your demo code, the data is merely fetched randomly, shuffled and collated, but it doesn’t ensure that all the data in a single batch comes from the same bucket. Such an approach won’t achieve the purpose of bucket training.


added dictionary for abbreviations

brief description of changes
I want to resolve #158 with this PR.
I looked at Urban dictionary as requested in the issue. However, I did not find any pattern with which I can find the abbreviation or extract its expanded form. So, I have added a dictionary for looking up of requested abbreviation. The dictionary contains the most popular abbreviations mentioned in Urban dictionary. Let me know if this is okay or if you have any suggestions.

@AngeloGiacco ok, I thought only abbreviation was needed and the meaning section in urban dictionary sometimes contained a lot of text. Maybe this could be updated in future with some more logic.


Convoy glusterfs driver didn't remove volume when use "docker volume rm "

daemon/docker.go
`
request := &api.VolumeDeleteRequest{
                    VolumeName: volume.Name,

		// By default we don't want to remove the volume because probably we're using NFS

		ReferenceOnly: true,

	}

`
so, when i use "docker volume rm volume volume-0c76ed1c8201494a"
directory and files like "/var/lib/rancher/convoy/glusterfs/mounts/vol1/volume-0c76ed1c8201494a/*" will leave over,
this will be improvment?

It's intended because for NFS(which is most of our use case) we don't want to delete user data, unless user ask us to do it. User is likely want to share volume between containers.


[Question] Update CLI to new versions?

On mac, enabled from gui the cli, I think at version 1.0.0 or something like that, and now the new version arrived.
cotfas:~ work$ maestral status
Maestral v1.0.3 has been released, you have v1.0.3.beta1. Please use your package manager to update.
I have stopped the cli daemon and then I copied the app from the dmg to the /Applications folder, I have went to gui and uninstalled and installed the cli back, and in the terminal I keep seeing is the beta release, this also applies to the GUI, it shows as beta, eventhought I have downloaded the 1.0.3 from the github release tab:
https://github.com/SamSchott/maestral/releases/download/v1.0.3/Maestral.dmg
Anyway, updating from CLI how it is done? is there a command easier to simplify the whole process?
Thank you.

Sorry about that, the app bundle on GitHub had the wrong release number (even though it actually was production code). So it keeps prompting for an update... I have replaced now with the correct version.
There is however no need to reinstall the CLI. The install button only creates a symlink to the CLI which is contained inside the app bundle. As long as you don’t move the app to a different location, it will keep working through updates.

And when updating to new versions, I guess I have to do a cli maestral stop, then update? Right? :)

Yes! I don’t think macOS allows you to replace the app while it’s running (at least I hope it doesn’t).


Module jakarta.activation not found, required by org.jvnet.staxex

For Java11 analysis we are testing the with latest TomEE8, there we found a problems with stax-ex 1.8.1. We run the tools jdeps from the JDK.
Exception in thread "main" java.lang.module.FindException: Module jakarta.activation not found, required by org.jvnet.staxex        at java.base/java.lang.module.Resolver.findFail(Resolver.java:877)        at java.base/java.lang.module.Resolver.resolve(Resolver.java:191)        at java.base/java.lang.module.Resolver.resolve(Resolver.java:140)        at java.base/java.lang.module.Configuration.resolve(Configuration.java:411)        at java.base/java.lang.module.Configuration.resolve(Configuration.java:245)        at jdk.jdeps/com.sun.tools.jdeps.JdepsConfiguration.<init>(JdepsConfiguration.java:117)        at jdk.jdeps/com.sun.tools.jdeps.JdepsConfiguration$Builder.build(JdepsConfiguration.java:563)        at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.buildConfig(JdepsTask.java:589)        at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:543)        at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:519)        at jdk.jdeps/com.sun.tools.jdeps.Main.main(Main.java:49)
b9396664146e447b9d92d67072c39647714e30e8 This commit has changed all kind of references from javax.activitation to jakarta.activitation.
The Java module (not the Maven module) where activation is defined is javax.activation.
Stax-ex defines the module-info.java where the dependencies are defined.
That now also contains jakarta.activation as dependency, but that does not exit.
Do to this all jdeps checks we run with stax-ex on the classpath fail, so we don't have results for other dependencies as well.
#21 Might be related to this as well.

I created a pull request #23 for this ticket

jakarta.activation java module exists, see the project's pom, which has dependency on:
        <dependency>
            <groupId>jakarta.activation</groupId>
            <artifactId>jakarta.activation-api</artifactId>
            <version>1.2.1</version>
        </dependency>

where jakarta.activation module is defined. Should you need the same module with the implementation, use:
        <dependency>
            <groupId>com.sun.activation</groupId>
            <artifactId>jakarta.activation</artifactId>
            <version>1.2.1</version>
        </dependency>

@lukasj Thanks for your reply.
I guess the confusion comes because developers are looking for the replacement of javax.activation which is only one jar. Only that jar is replaced.
jakarta.activation does not have a dependency on jakarta.activation-api and jakarta.activation only advertises javax.activitation.
stax-ex has a maven dependency on jakarta.activation-api, but that did not make it in TomEE (yet).

that's all related to the donation of JavaEE to Eclipse.org, I believe. If a replacement for 'javax.activation' is needed then the artifact is 'jakarta.activation' (api+impl bundle), for the naming convention, see: https://wiki.eclipse.org/JakartaEE_Maven_Versioning_Rules (google can help to find JavaEE related original version of that document).
For the maven coordinates related changes, see: https://wiki.eclipse.org/New_Maven_Coordinates


Missing instance of FromSQLValue Instant

perhaps there is an obvious reason this is missing? Or just overlooked? the ToSQLValue for it exists.

I'm happy to make a PR if it's just overlooked

@dwhitney Please do if you are still interested!
P.S. Sorry for late response!

Fixed bb493e59832a1ce0594b278112ea49477e0a276c


Does not support spring data elasticsearch?

Does this support spring data elastic search? It seems that 9300 port is needed, but you do not give

Currently, the port 9300 is not published on purpose for simplicity. This image is aiming to provide the opportunity to explore what ES and Kibana are like quickly so it is intended to run as a single node. Still, I'm positively thinking to change this policy if there are lots of requests.


Selectively delegating some supervisor domain external interrupts

Some TEE OSes may have a requirement to toggle the interrupt enable bit from the REE. For instance, OPTEE calls spin_lock_xsave() to disable both FIQ and IRQ during some critical sections. It seems like the riscv porting effort has to upgrade this operation to a sbi-call even with smsdia in SMMTT. This is because msdeie is an m-mode register, and SDEIE is only available in mie, which means delegation of this type of interrupt to s-mode is impossible. This is a good security choice as s-mode domain should not interfere with interrupts belonging to others. Every thing related to inter-domain managements should be done by the RDSM. However, this may increase the latency or complexity to do interrupt management when the relationship between some domains are not symmetric (Linux + OPTEE).
To achieve the improved latency without sacrificing security. Should we consider adding following 2 changes?

Make SDEIE visible in sie so delegation works.
Add an m-mode MAXLEN CSR msdeideleg E.g. to selectively determine if any of a supervisor domain external interrupts are able to be delegated.

Interrupts for an inactive s-mode domain only get delegated into the hart if mie.SDEIE is set, and the bit representing the s-mode domain in msdeie and msdeideleg is set. Interrupts for an inactive domain where msdeie is true but msdeideleg is not set still trigger a m-mode interrupt.
This type of delegation does not mean the running s-mode domain should process interrupts from an inactive s-file domain. Instead, this delegation works as a mask-able notification for the running s-mode domain.

It seems like the riscv porting effort has to upgrade this operation to a sbi-call even with smsdia in SMMTT.

That is not necessary. The supervisor domain should can mask its own external interrupt globally using sstatus.SIE or locally using sie.SEIE. While clearing SIE disables all interrupts - timer, external, software, LCOFI, etc. - clearing SEIE disables external interrupts.

Make SDEIE visible in sie so delegation works.

SDEI is a M-mode local interrupt that indicates to the RDSM that there are pending external interrupts for one or more of the supervisor domains. This interrupt is used by the scheduler in RDSM to determine if it should schedule a supervisor domain for execution. It is not useful to delegate this interrupt to any supervisor domain.

This is because msdeie is an m-mode register, and SDEIE is only available in mie, which means delegation of this type of interrupt to s-mode is impossible. This is a good security choice as s-mode domain should not interfere with interrupts belonging to others. Every thing related to inter-domain managements should be done by the RDSM. However, this may increase the latency or complexity to do interrupt management when the relationship between some domains are not symmetric (Linux + OPTEE).

I've raised similar question in previous issue: https://github.com/riscv/riscv-smmtt/issues/5#issuecomment-1751931055
For ARM, OP-TEE has higher permission than Linux. (Let me call it unilaterally-mistrusting domains here.)
When CPU is running OP-TEE context, ARM can directly inject Linux interrupt (non-secure interrupt, FIQ) into OP-TEE, without EL3 secure monitor intervention.
That means when CPU is running in S-mode supervisor domain, Other supervisor domain's interrupt "notification" can be directly injected into current supervisor domain, without M-mode RDSM intervention.
It can improve the performance of interrupt handling when the system adopts unilaterally-mistrusting domains model.
In short, I think what @AndybnACT wants is "FIQ in RISC-V".

Make SDEIE visible in sie so delegation works.

I think it is unnecessary to make the whole MSDEIE visible for S-mode supervisor domain.
We can just let mip.MSDEIP and mie.MSDEIE (refer to Smmtt section 6.4 - Machine Interrupt registers) be delegated to S-mode supervisor domain by corresponding bits in mideleg.
Active supervisor domain can determine if there is an "FIQ" in the handler of sip.SSDEIP by
if (sip.SSDEIP == 1 /* any SD interrupt pending */ && sip.SEIP == 0 /* current SD interrupt pending */) {
    /* Yield control to other supervisor domains */
}

FIQ can be enabled/disabled by sie.SSDEIE, so that active supervisor domain only accepts sip.SEIP.
Hi @ved-rivos, What do you think for this ?
I remember you mentioned RISC-V should have "mutually-mistrusting SDs".
But since RISC-V is highly bespoke architecture, some vendors may want to adopt "unilaterally-mistrusting domains model".
Then we can define such flexibility into the spec to not restrict the system behavior.

Hi @gagachang,

I think it is unnecessary to make the whole MSDEIE visible for S-mode supervisor domain, unless you want to control interrupt delegation per domain.

I didn't propose this. S-mode should not see and control MSDEIE. It is a violation of domain security. Interrupt delegation should be controlled by RDSM. The idea I proposed is to give RDSM a way to relate closely coupled domains (Linux + OPTEE). e.g. to decide interrupts for selected domains can be sent as a notification to an active domain. And this kind of notification is maskable within the active domain.
RDSM has to inject such notification to the active domain without this. If this happens when the active domain does not intend to receive interrupts of the related domain (e.g. mask off FIQs when running OPTEE), then the active domain has to tell RDSM to delay such notification. Such mechanism may not be trivial to implement in the software.

Hi @AndybnACT
I see. Something wrong in my last comment.
The mie.MSDEIE should not be controlled by SD, so it should not be delegated directly.
It depends on the implementation of "FIQ".
From Ved's comment (https://github.com/riscv/riscv-smmtt/issues/5#issuecomment-1753242541)
FIQ can be a kind of virtual interrupt.
Active SD can mask/unmask that virtual interrupt directly.
(From Andes' OPTEE prototype, we use a fake PLIC interrupt source to be this virtual interrupt.)
While the inactive SD's interrupt trapped to RDSM, RDSM can "pend" that virtual interrupt for active SD, and mret back to active SD.
FIQ will be taken only when active SD unmasks that virtual interrupt.
It seems you propose sie.SDEIE to be this virtual interrupt, am I correct?

We can just let mip.MSDEIP and mie.MSDEIE (refer to Smmtt section 6.4 - Machine Interrupt registers) be delegated to S-mode supervisor domain by corresponding bits in mideleg.
Active supervisor domain can determine if there is an "FIQ" in the trap handler by

I don't think this alone fits in the security model of SMMTT. Delegating the entire SDEI to a domain gives it the ultimate privilege to see or ignore all interrupts on the platform.
So that's the reason why I listed the second proposed change. Let m-mode have a fine grain control of "interrupts from which domain is delegated". Only interrupts from a domain, where msdeideleg has corresponding bit set, is sent to and is maskable to the active domain when SDEIE is delegated in mdeleg. Interrupts from other domains work as what the original spec defines.

FIQ can be a kind of virtual interrupt.
Active SD can mask/unmask that virtual interrupt directly.

Yes, this is a good way to forward the FIQ. RDSM has to temporarily disable interrupts from the inactive domain source before mret back. I was thinking that then the s-mode domain must make a sbi call to ask RDSM to re-enable it after the domain unmask FIQs. But in fact if we raise an virtual interrupt in RDSM, then the s-mode domain can trap into the entry point to perform managed-exit once the domain unmask FIQs.
However, as you mentioned, this would cause extra m-mode round trips on FIQs delivery path. I have not done many in OPTEE and perhaps this is another topic. But I am wondering what makes OPTEE need managed exit, because Linux doesn't need it.

@gagachang The RDSM should not have any info of any task migration by design - it is the role of the SDSM (the security monitor in the supervisor domain) to activate the right TA context on the pCPU/pHart selected by the host (Linux) and save it on an interrupt that was delegated to it or emulated by the RDSM.
Please see the models described in the cove spec (which is one of the use cases of supervisor domains) - see section "5.3. TSM operation and properties" in this spec

Thanks Ravi! I checked section 5.3 and it aligns our thought here.
Yes, RDSM should have simple design. Task migration is per OS implementation.
From paragraph of section 5.3:

On an S-mode interrupt, the TSM hart context is saved by the
TSM and keeps the interrupt pending. The TSM may then TEERET to the host OS/VMM with
explicit information about the interruption provided via the pending interrupt to the OS/VMM.

We are thinking if we can improve the performance of "notifying TSM that there is an OS/VMM's interrupt".
And also a simple way for active SD to control whether it wants to receive the notification or not. (Proposed by @AndybnACT)
In current Smmtt design, inactive SDs interrupts always trap to M-mode RDSM (by mip.MSDEIP).
It is RDSM's responsibility to inform active SD to suspend its execution (e.g., by pending active SD's virtual interrupt and mret).
This would cause extra M-mode round trips on this information delivery.
If vendor wants to deploy unilaterally-mistrusting domains model (e.g., Linux + OP-TEE), we can define a faster way into Smmtt to eliminate that round trips.

right - this is by design, as we do not want one SD to prevent/modify the delivery of any interrupts meant for another SD.

It's correct for mutually-mistrusting SDs.
Could we have more options (or extension of Smsdia) for Secure/Non-secure SDs ?

@gagachang can you clarify what does Secure/Non-Secure SDs mean?

@gagachang can you clarify what does Secure/Non-Secure SDs mean?

Hi @rsahita Sure!
They are akin to Normal world and Secure world in ARM TrustZone.
Secure SD = Secure World OS (ex: OP-TEE)
Non-secure SD = Non-secure World OS (Linux)
Secure world has higher system permission than normal world:

Secure OS can directly access Non-secure OS memory space.
Secure OS can map non-secure physical memory into its page tables.
Secure OS can receive Non-secure interrupt notification (i.e., FIQ) without EL3 firmware interleave, and yield control to Non-secure world to handle that FIQ. Without EL3 firmware interleave gets greater interrupt performance.

Above bullet 1 and 2 can be kind of shared-memory in MTT.
But bullet 3 needs interrupt delegation, which is proposed by this issue.

I suggest discussing in terms of RISC-V architecture. When a Secure-SD is executing, there might be one of the following interrupts pending for non-secure-SD that may require switching out of the currently executing secure-SD to the non-secure-SD - External Interrupt, Timer Interrupt, other local interrupts such as High priority RAS interrupt, Low priority RAS interrupt, high-power or over-temperature event  (not ratified), debug/trace interrupt (not ratified) or other custom interrupts.
In case of ARM architecture I believe FIQ used to represent a higher priority interrupt than IRQ but starting ARMv8 I believe that is not true and FIQ are generally designated for use as secure interrupt and so would just be only delegated to secure-SD exclusively (or shared somehow between the secure monitor and the secure SD).
While what is being discussed here could possibly provide an external interrupt notification to the secure-SD, the RDSM still needs to provide a notification interrupt to the SD on occurrence of all other forms of interrupts. Given that there is no concept of "Fast" interrupt vs. "Slow" interrupt, I am not sure there is much motivation to add complexity and exposures (covert channels, avenues for denial of service, etc.) by delegating just the external interrupt.

Hi @ved-rivos
Refer to ARM documents, they use FIQ as Group 1 interrupts from other security state [1]. (Group 0 is group of interrupts that should be handled in EL3)

External Interrupt, Timer Interrupt, other local interrupts such as High priority RAS interrupt, Low priority RAS interrupt, high-power or over-temperature event (not ratified), debug/trace interrupt (not ratified) or other custom interrupts.

Yes, you're right, RISC-V has so many local interrupts, while most of ARM interrupts are routed into GIC and become IRQ/FIQ.
IMHO, local interrupts are always belong to active SD (ensured and context switch by RDSM), otherwise they must trap and dispatched by RDSM.
I am also thinking if "CLIC, or its interrupt sources" can also be selected (like we select APLIC by SDICN), but it might be too complex.

I am not sure there is much motivation to add complexity and exposures (covert channels, avenues for denial of service, etc.) by delegating just the external interrupt.

If platform chooses this model, that implies active SD is trusted by other SDs.
It is an open option for vendors. Vendors can still choose mutually-distrusting model.
[1]: https://developer.arm.com/documentation/ihi0069/latest/

I hope none of the information you pasted is encumbered information. I am choosing not to visit the links you have pasted here.
For the secure/non-secure SD scenarios we only need to be able to delegate the MSDEIP to the secure SD. We can rename this interrupt to SDEIP and make the corresponding bit writable in mip.

@ved-rivos

I hope none of the information you pasted is encumbered information.

Are you asking if FIQ has a patent ?

For the secure/non-secure SD scenarios we only need to be able to delegate the MSDEIP to the secure SD. We can rename this interrupt to SDEIP and make the corresponding bit writable in mip.

Thanks! I think it is correct direction.
I guess current design would be
if (mip.SDEIP && !msdeip[SDICN]) {
    /* There is an interrupt from other SD. */
    if (mideleg[32]) {
        /* Trap to S-mode to notify active SD directly. */
        sip.SDEIP = 1
    } else {
        /* Trap to M-mode, M-mode should notify active SD. */
    }
}

BTW, @AndybnACT proposed msdeideleg to let m-mode have a finer-grained control of "interrupts from which domain is delegated". So not all other SDs' interrupts will be delegated to the active SD. @AndybnACT would you have some comments?
if (mip.SDEIP && !msdeip[SDICN]) {
    /* There is an interrupt from other SDs. */

    /* Assume interrupt is from interrupt controller N, which is bound with another SD. */
    if (msdeideleg[N]) {
        /* Trap to S-mode to notify it directly. */
        sip.SDEIP = 1
    } else {
        /* Trap to M-mode, M-mode should notify active SD. */
    }
}

BTW, @AndybnACT proposed msdeideleg to let m-mode have a finer-grained control of "interrupts from which domain is delegated". So not all other SDs' interrupts will be delegated to the active SD. @AndybnACT would you have some comments?

Sorry I don't quite understand the first "if" clause. Shouldn't mip.SDEIP be decided after resolving msdei[pe]? I am trying to write down the pseudo code according to my understanding. It should probably be something like this when the spec is unmodified:
/*  external s-domain interrupt */
if (msdeip & msdeie)
    mip.MSDEIP = 1

IIUC, the likely happening one is:
/*  external s-domain interrupt */
if (msdeip & msdeie) {
    /* mip.SDEIE is writable so is able to be delegated into s-mode  */
    mip.SDEIP = 1
}

The one I proposed add a layer of control. It controls whether each s-domain external interrupt is delegated along with mdeleg.SDEIE.
/*  external s-domain interrupt */
if (msdeip & msdeie) {
        mip.SDEIP = 1
}

/* Delegation */
if ((~msdeideleg) & msdeip & msdeie) {
    /* causes trap into m-mode */
}
if (mdeleg.SDEIE && (msdeideleg & msdeip & msdeie)) {
    /* delegates to s-mode */
}

I am not sure if this can complicate the spec too much. What if msdeie & msdeideleg has the active domain's bit set, and delegated? Or, does it violates the privilege spec? There should be a cleaner way to do it.

Skip them in hardware side may increase performance, since RDSM doesn't need to set/clear msdeie every domain context-switch.

I don't think performance may be a big concern since msdeie is a hart-private csr, and it's likely that msdeie would be touched anyway. But I do appreciate it because this makes the spec cleaner.
Since interrupts from the active domain go through mip.seip, one may deselect mdeleg.seie to have the interrupt trapped into m-mode. smsdia introduce a way to do the same thing. Active domain's interrupt causes a trap into m-mode if msdeie has the active domain's bit set.
if ((msdeip & msdeie) & ~(1 << msdcfg.SDICN)) {
        mip.SDEIP = 1
}

What I proposed is to simply make mideleg[MSDEIP] writable and allow this interrupt to be delegated to the SD.

What I proposed is to simply make mideleg[MSDEIP] writable and allow this interrupt to be delegated to the SD.

Thanks @ved-rivos ! That's a cleaner way to achieve our feature.

smsdia introduce a way to do the same thing.

Active domain's interrupts are already controlled to be delegated or not by mideleg[SEIP].
That's why I felt msdeie[SDICN] and msdeip[SDICN] can be skipped by ISA when constructing mip.SDEIP
Otherwise, when we want to delegate active SD's external interrupts, we must set mideleg[SEIP] and clear msdeie[SDICN] respectively.
Anyway, if the programmers are cautious about this, it might not be problem.

FYI @AndybnACT @gagachang PR #40

closing this as PR #40  has been acked by Andy.


[Typography] headlineMapping semantics

Problem description
const headlineMapping: { [key: Type]: string } = {
  display4: 'h1',
  display3: 'h1',
  display2: 'h1',
  display1: 'h1',
  headline: 'h1',
  title: 'h2',
  subheading: 'h3',
  body2: 'aside',
  body1: 'p',
};

I think title should use h1 as it is used for the page title in the App Bar. I also don't understand why body2 uses aside. How can you know the semantic context in advance? I have used body2 many times in our apps and it's never used as an aside.
Which makes me wonder, why have these opinionated defaults in the first place? I'm genuinely curious as to what the reasoning behind this was. As far as I know, the Guidelines don't mention anything about coupling the styles to semantic elements.
Versions

Material-UI: next v1.0.0-alpha.13

I have been using this demo for the choice of the default element. I'm not sure it's the best choices, still, that's a good default, to begin with. I'm happy to take discuss potential changes.

Ok, I see now. Makes me wonder why they chose these. I'll do some digging.

I'm closing that issue for now. If you want to change any of the default element, feel free to submit a PR and to defend your case. Thanks for raising that concern 👍 .


Clean up the debug menus

Some debug options do not function or are not clear.
Add some more useful or entertaining options to the menus for testing and for actual usage purposes.
Manual screen rotation?
Certain advanced options toggles (pitch rates for one example)?
Fullscreen toggle?
Clearer volume modification?
Part of this will take place in Lua, but also in the Debug Overlay in the code.

dealt with somewhat
efa0767a3a0912854264bc98f8050efc0725ce20
339b91b3b30403e1ca35d9a192e23e636d90f6fc


SNIP-6 security clarifications

Add clarification about how the data to sign must include the chain id and the account address to avoid signature replays

hi @ArielElp can we please merge this one, it's a clear improvement that will improve safety


Text in braces in math environments is highlighted incorrectly.

Here's a minimal example showing the errors:
\documentclass{amsart}

\begin{document}
Text in braces in math environments is highlighted incorrectly.

For instance the \texttt{equation} or \texttt{align} environments:
\begin{equation}
  \frac{a}{b} % Arguments are in text mode, but should be math
  { c^2 } % Contents of {...} are in text mode but should be math
\end{equation}
\begin{align}
  \frac{a}{b} % Arguments are in text mode, but should be math
  a = b
  { c^2 } % Contents of {...} are in text mode but should be math
\end{align}

However, inline math works:
$
  \frac{a}{b} % Arguments are in math mode as expected.
  { c^2 } % Contents of {...} are in math mode as expected.
$

Displayed equations also work:
\[
  \frac{a}{b} % Arguments are in math mode as expected.
  { c^2 } % Contents of {...} are in math mode as expected.
\]
\end{document}

I'm using Neovim with tree-sitter-latex version 2ae2021d7b224fb6aa57b760e0d146059f943bb8 (latest as of the time of writing).
Please let me know if I can help trace down the issue in any way.

Here's a screenshot:

Please show the parsed output (:InspectTree) rather than a screenshot (which depends on queries and colorschemes, none of which are relevant to this repo).

Here's the output of :InspectTree on the same file:
(class_include) ; [1:1 - 22]
path: (curly_group_path) ; [1:15 - 22]
path: (path) ; [1:16 - 21]
(generic_environment) ; [2:1 - 27:14]
begin: (begin) ; [2:1 - 16]
name: (curly_group_text) ; [2:7 - 16]
text: (text) ; [2:8 - 15]
word: (word) ; [2:8 - 15]
(text) ; [3:1 - 5:66]
word: (word) ; [3:1 - 4]
word: (word) ; [3:6 - 7]
word: (word) ; [3:9 - 14]
word: (word) ; [3:16 - 17]
word: (word) ; [3:19 - 22]
word: (word) ; [3:24 - 35]
word: (word) ; [3:37 - 38]
word: (word) ; [3:40 - 50]
word: (word) ; [3:52 - 63]
word: (word) ; [5:1 - 3]
word: (word) ; [5:5 - 12]
word: (word) ; [5:14 - 16]
word: (generic_command) ; [5:18 - 34]
command: (command_name) ; [5:18 - 24]
arg: (curly_group) ; [5:25 - 34]
(text) ; [5:26 - 33]
word: (word) ; [5:26 - 33]
word: (word) ; [5:36 - 37]
word: (generic_command) ; [5:39 - 52]
command: (command_name) ; [5:39 - 45]
arg: (curly_group) ; [5:46 - 52]
(text) ; [5:47 - 51]
word: (word) ; [5:47 - 51]
word: (word) ; [5:54 - 66]
(math_environment) ; [6:1 - 9:14]
begin: (begin) ; [6:1 - 16]
name: (curly_group_text) ; [6:7 - 16]
text: (text) ; [6:8 - 15]
word: (word) ; [6:8 - 15]
(generic_command) ; [7:3 - 8:9]
command: (command_name) ; [7:3 - 7]
arg: (curly_group) ; [7:8 - 10]
(text) ; [7:9 - 9]
word: (word) ; [7:9 - 9]
arg: (curly_group) ; [7:11 - 13]
(text) ; [7:12 - 12]
word: (word) ; [7:12 - 12]
(line_comment) ; [7:15 - 62]
arg: (curly_group) ; [8:3 - 9]
(text) ; [8:5 - 7]
word: (word) ; [8:5 - 5]
word: (superscript) ; [8:6 - 7]
superscript: (word) ; [8:7 - 7]
(line_comment) ; [8:11 - 65]
end: (end) ; [9:1 - 14]
name: (curly_group_text) ; [9:5 - 14]
text: (text) ; [9:6 - 13]
word: (word) ; [9:6 - 13]
(math_environment) ; [10:1 - 14:11]
begin: (begin) ; [10:1 - 13]
name: (curly_group_text) ; [10:7 - 13]
text: (text) ; [10:8 - 12]
word: (word) ; [10:8 - 12]
(generic_command) ; [11:3 - 13]
command: (command_name) ; [11:3 - 7]
arg: (curly_group) ; [11:8 - 10]
(text) ; [11:9 - 9]
word: (word) ; [11:9 - 9]
arg: (curly_group) ; [11:11 - 13]
(text) ; [11:12 - 12]
word: (word) ; [11:12 - 12]
(line_comment) ; [11:15 - 62]
(text) ; [12:3 - 3]
word: (word) ; [12:3 - 3]
(text) ; [12:7 - 7]
word: (word) ; [12:7 - 7]
(curly_group) ; [13:3 - 9]
(text) ; [13:5 - 7]
word: (word) ; [13:5 - 5]
word: (superscript) ; [13:6 - 7]
superscript: (word) ; [13:7 - 7]
(line_comment) ; [13:11 - 65]
end: (end) ; [14:1 - 11]
name: (curly_group_text) ; [14:5 - 11]
text: (text) ; [14:6 - 10]
word: (word) ; [14:6 - 10]
(text) ; [16:1 - 7]
word: (word) ; [16:1 - 7]
(text) ; [16:10 - 27]
word: (word) ; [16:10 - 15]
word: (word) ; [16:17 - 20]
word: (word) ; [16:22 - 27]
(inline_formula) ; [17:1 - 20:1]
(generic_command) ; [18:3 - 19:9]
command: (command_name) ; [18:3 - 7]
arg: (curly_group) ; [18:8 - 10]
(text) ; [18:9 - 9]
word: (word) ; [18:9 - 9]
arg: (curly_group) ; [18:11 - 13]
(text) ; [18:12 - 12]
word: (word) ; [18:12 - 12]
(line_comment) ; [18:15 - 55]
arg: (curly_group) ; [19:3 - 9]
(text) ; [19:5 - 7]
word: (word) ; [19:5 - 5]
word: (superscript) ; [19:6 - 7]
superscript: (word) ; [19:7 - 7]
(line_comment) ; [19:11 - 59]
(text) ; [22:1 - 30]
word: (word) ; [22:1 - 9]
word: (word) ; [22:11 - 19]
word: (word) ; [22:21 - 24]
word: (word) ; [22:26 - 30]
(displayed_equation) ; [23:1 - 26:2]
(generic_command) ; [24:3 - 25:9]
command: (command_name) ; [24:3 - 7]
arg: (curly_group) ; [24:8 - 10]
(text) ; [24:9 - 9]
word: (word) ; [24:9 - 9]
arg: (curly_group) ; [24:11 - 13]
(text) ; [24:12 - 12]
word: (word) ; [24:12 - 12]
(line_comment) ; [24:15 - 55]
arg: (curly_group) ; [25:3 - 9]
(text) ; [25:5 - 7]
word: (word) ; [25:5 - 5]
word: (superscript) ; [25:6 - 7]
superscript: (word) ; [25:7 - 7]
(line_comment) ; [25:11 - 59]
end: (end) ; [27:1 - 14]
name: (curly_group_text) ; [27:5 - 14]
text: (text) ; [27:6 - 13]
word: (word) ; [27:6 - 13]

Can you maybe minimize that example so one can see what's going on?

Looks correct to me, as far as the tree is concerned.  AFAICT, (text) is a generic node for any non-special character; it is not the same as (text_mode).
Any highlight errors are query issues and belong at nvim-treesitter.

OK, on a second machine (with the same configs) I see the highlighting all correct. Regardless, from the output of InspectTree it looks like it isn't a treesitter issue. I'll trace down the problem and open a new issue if I can reproduce it consistently.
Sorry to bother you and thanks for the quick responses.


Seaborn Plotting?

Since we will be moving to Pandas for storing tables, etc., should we look at using seaborn for data descriptive plots? For example, seaborn can make the corner plots very nicely, and also allow the user to pass their preferred colormap.

I like seaborn and I use it all the time, but at the same time is an experimental package from a Stanford PhD, don't know how long it will be supported, so I am hesitant to include in core functionalities.
I think one of the good things about seaborn is that you can import it before 3ML and it will automatically modify your plots.
Do you want to try that? If it doesn't work we might evaluate including it in setup.py .

Ah, yes, this always works.
The feature I like is the native pandas handling. However, if you feel seaborn will fade away, then we can always deal with this ourselves.


How to compute the ATE in the paper?

How to compute the ATE in the paper?  I didnot find the code to compute the pose error ATE.
Besides, I find the pose accuracy will decline when the training iteration beyond 3k or 4k. Can you provide some solution?

Hi, sorry, maybe pose accuracy will not decline when the training iteration beyond 3k or 4k.
Could you provide me some advices that how to compute the ATE?  Is the output of the flowmap extrinsic directly compared （ATE）with the colmap output extrinsic after each iteration?

The code that computes ATE is here.
The ATE is computed with respect to the extrinsics provided by the data loader. For real-world data, there are no ground-truth extrinsics, and so the ATE is computed with respect to poses that are known to be reasonable (e.g., COLMAP poses) instead.
There are two reasons why ATE wouldn't necessarily improve beyond 3-4k steps:

Since the ATE is computed with respect to poses that aren't really ground truth, past a certain point, improving pose quality won't lower ATE (i.e., the ground truth is inaccurate).
The optimization has converged. Since FlowMap uses estimated optical flow, it could theoretically achieve zero loss but not have perfect poses (i.e., FlowMap's results are inaccurate).


injectFirst prop not functioning properly, material UI styles still injected last

--------------^ Click "Preview" for a nicer view!
We primarily use GitHub as an issue tracker. For usage and support questions, please check out the resources below. Thanks!

Read the documentation.
Ask questions on StackOverflow using the tag material-ui.
Chat with the community on Spectrum.
Ping us on Twitter.

This started happening a few days ago. Before then, the material UI styles were properly injecting first, allowing me to override some of them using standard css. Here are the version numbers for my installed libraries:
"@material-ui/core": "^4.1.3",
"@material-ui/icons": "^4.2.1",
"@material-ui/styles": "latest",
"@material-ui/system": "^4.3.2",

Let me know if there is any other information I can provide that would be helpful and I will happily do so.

Your issue has been closed because it does not conform to our issue requirements.
Please provide a full reproduction test case. This would help a lot 👷 .
A live example would be perfect. This codesandbox.io template may be a good starting point. Thank you!

@garrett-flash check for duplicates of @material-ui/styles in your dependencies.

That was the issue, thank you!


formatQuery for MongoDB output does not match regular output when using ruleGroups

Hi Jake,
First of all, brilliant component. I love how simple and lightweight it is, and how easy it is to use. I might have found a bug though.
I was testing this on a little personal side project I'm working on and encountered a discrepancy between the output when formatting the query for MongoDB and the component's actual output.

I was expecting the output for MongoDB to look more like this:
  {
    "$or": [
      {
        "role": {
          "$regex": "front end"
        }
      },
      {
        "location": {
          "$regex": "remote"
        }
      },
      {
        "$and": [
          {
            "keywords": {
              "$regex": "react"
            }
          }
        ]
      }
    ]
  }

I also have a codesandbox here with a minimal reproducible example: https://codesandbox.io/s/quirky-scott-iqrqz1
Thanks!

Thanks for the kind words! And that's an excellent, detailed report which I very much appreciate. :)
If I remember correctly, this behavior is intentional. formatQuery will, in the "mongodb" case anyway, collapse any groups that only contain one rule down to that rule by itself.
Is it causing a problem? If so, I'm happy to reevaluate that decision.

Thank you for the quick response.
Oh is that what is going on? Thinking about it, that does make sense for it to do that. Does it cause a problem? Not at the moment, and again when I think about it I don't feel like it will cause a problem. I guess I'll test it out on some data for a bit to confirm that.
Fantastic component though. I'm using it not just to make a user-friendly query GUI for my side project, but also to learn the difference between different db query languages.

That's fantastic that you're using it as a learning tool. Honestly I never considered that as a use case in and of itself, although I've certainly been using the development of the component as a learning opportunity. Maybe I'll think about putting something more formal together for the docs site.


Always match cookies with a wild card domain

Cookies instantiated without a domain get their domain property set
to "*" by default, which seems to imply that they should match any
domain, but matchDomain() did not treat them as such.

Change matchDomain() to return true for cookies with domain of "*"

Am I misunderstanding how this should work, or is that the expected functionality?

Hi, thanks for the PR!
I don't actually think cookies can be domain-less, or have a wildcard domain field?

I don't think that's part of the standard, but Cookie() will set the domain property to * if one isn't provided, so I assumed the intention was to match everything. As it currently stands, matchDomain() tries to match "*" and returns false. Even though I wouldn't want my browser doing this, I can see why it might be helpful for testing things.

Ah, silly me - I see now! In that case, this looks great :+1: If you could fix the lint error and maybe squash the 2nd commit so it only results in a single one, we can go ahead and merge this!


don't conflict with website docs examples dir that hold the index

I really need to find a better way to build docs.
I've pushed changes on the docs website to accomodate for that.

@Carreau  What exactly is the problem?

This PR is throwing 401 errors on Travis. Do you have any idea why?

This PR is throwing 401 errors on Travis. Do you have any idea why?

Yes, it is because the token cannot be decrypted on travis in PRs, to tds resintall -so get rate limitted.
secret are not decrypted on PR otherwise anybody submitting a PR could just 'echo DECRYPTED_TOKEN' on do things on your behalf. Token only get decrypted once merged in master.
I'm dont' know if there is a way around that, if we can have something similar without actually hitting github. Or generate a token that we allow to be decrypted on PR and that have no-access to anything, except increase github API rate limit.

This is no longer needed since this repo now only builds the API docs.


feat(trigger-event): create helper for triggering events

This helper was based on this one and refactored for our own development environment.

@willamesoares o coverage caiu, provavelmente a spec não ta cobrindo os statements, da uma olhada no codecov lá ou olha o coverage local


Added FastPT bias model

Thanks for doing this. A very quick look at the code looks good. Do you have any validation plots showing the different terms are recovered correctly?
There are some fast-pt examples here:
https://github.com/JoeMcEwen/FAST-PT/blob/master/examples/fastpt_examples.ipynb
We could for example do an np.allclose against the data from the figure at Out[11] in that notebook?

Good idea, will do that!

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@5351ca2). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #50   +/-   ##
=========================================
  Coverage          ?   68.56%
=========================================
  Files             ?       29
  Lines             ?     1740
  Branches          ?        0
=========================================
  Hits              ?     1193
  Misses            ?      547
  Partials          ?        0


feature: add automatic printing for bare identifiers

This change adds a pass that expands bare identifier statements into print statements. Since bare identifier statements were side-effect free and would have been optimized out, this shouldn't break any existing functionality or programs.
Fixes #431
Checklist

[x] Language changes are updated in man/adoc/bpftrace.adoc
[x] User-visible and non-trivial changes updated in CHANGELOG.md
[x] The new behaviour is covered by tests

This is very neat. I can't think of any potential issues at the moment (btw only glanced at code). Makes me think of implicit returns in rust.
One thought is we probably want to update the one-liner tutorial with an example of this: https://github.com/bpftrace/bpftrace/blob/master/docs/tutorial_one_liners.md#lesson-2-hello-worldhttps://github.com/bpftrace/bpftrace/blob/master/docs/tutorial_one_liners.md#lesson-2-hello-world
And maybe even the tools in tools/.
But probably good to first have a discussion on this feature.

+1 This is great for the one-liner use case! I definitely want to take some time to think about the implications of allowing this syntax though. Like @danobi, I can't think of any immediate issues.
Why is it that tuples are not supported e.g. BEGIN { (1, "hello"); or the result of a function call? Is that just out of scope for this initial implementaiton?

Also some additional unit and runtime tests would be good to add.

I'm good with letting this sit and marinate for a little while, I also think it's good to be careful about what's allowed and what's not. I'm just going through older issues and knocking out a fix or implementation to learn more about the internals. I'll circle back on this one in a few weeks and see how everyone feels (including myself!), and then update docs and tests more thoroughly.

 Any thoughts @fbs @viktormalik @ajor ?
I'm trying to think of the potential downsides or what future syntax this might get in the way of. We would, of course, feature gate this to start if we added it.


WIP App cancellation token

This would add cancellation token support to the async App methods. Is that something you'd be interested in?

Looking good - what do you think @GregorBiswanger?

@danielmarbach @robertmuehsig I think this is important for a clean and solid code... Thank you @danielmarbach for your support... Can you implement it on the other Electron.cs API classes too? :)

App cancellation token ready for review

Should or could this be merged?


Handling 302 statuses

Hello! I'm trying to implement some testing on an endpoint that upon success performs a redirect. However, it looks like the redirect is getting past chakram and directly loading the page that is redirected to. I'd like to validate the status and the Location header. Is this possible in Chakram, or am I just doing things wrong? Thanks in advance. Code example below.
        var loginRequest = chakram.get(url);

        it('should return 302', function(){
          expect(loginRequest).to.have.status(302);
          return chakram.wait();
        });

        it ('should redirect to localhost', function(){
          return expect(loginRequest).to.have.header('Location', /(http:\/\/localhost?token=[^\s]{2,})/);
        });

The request library, which chakram is built on top of, has a few options for controlling redirects. I think followRedirect which is by default is true needs to be set to false. Something like this (untested):
        var loginRequest;
        before(function() {
          loginRequest = chakram.get(url, {
               followRedirect: false
          });
          return loginRequest;
        });

        it('should return 302', function(){
          return expect(loginRequest).to.have.status(302);
        });

        it ('should redirect to localhost', function(){
          return expect(loginRequest).to.have.header('Location', /(http:\/\/localhost?token=[^\s]{2,})/);
        });

@dareid That worked like a charm. Thank you! And for future reference, maybe it should be more well noted in the docs that chakram uses the request module for requests, so questions like this can reference the request docs first :smiley:


HIVE-25010: Create TestIcebergCliDriver and TestIcebergNegativeCliDriver

What changes were proposed in this pull request?
New iceberg specific TestIcebergCliDriver and TestIcebergNegativeCliDriver

Why are the changes needed?

Does this PR introduce any user-facing change?

How was this patch tested?

Thanks, @marton-bod and @pvary for the review.


Implement updating Quick Add list based on the selected ion server

Each ion server will have it's own Quick Add list. On the self-hosted ion side this is being tracked in: https://github.com/CesiumGS/cesium-ion/issues/6591

cesium-native changes: https://github.com/CesiumGS/cesium-native/pull/773


Fixed code example

Added missing slash to "create pool" structure

Closed since the product team fixed this.


Add Support For Prometheus Metrics

Is your feature request related to a problem? Please describe.

I'd like to monitor the descheduler using Prometheus metrics. Metrics should only be collected when run without the --dry-run CLI option.
Describe the solution you'd like

Add an optional configuration option(CLI option?) to enable exposing Prometheus metrics. At this point in time I have not given much thought to exactly which metrics and labels the descheduler would expose.
Describe alternatives you've considered

I have considered using the descheduler logs with log aggregation software for monitoring the descheduler. I also considered using the k8s events generated by the descheduler in combination with eventrouter. The eventrouter does provide some simple Prometheus metrics for events that it collects.
What version of descheduler are you using?
descheduler version: v0.18.0
Additional context

Currently the descheduler is run as a Job or CronJob this makes it difficult for Prometheus to scrape metrics from the descheduler pod because it is not long lived. One option is to have descheduler push metrics using the Prometheus pushgateway.

Currently the descheduler is run as a Job or CronJob this makes it difficult for Prometheus to scrape metrics from the descheduler pod because it is not long lived

The scheduler can run as a long lived pod with the --descheduling-interval flag. This is actually what we chose to prefer in the OpenShift Descheduler Operator because it also allowed us to not yet depend on CronJobs (which are still beta)

/assign

@seanmalloy any particular metrics in mind? I can quickly think of:

number of pods evicted per each strategy
number of pods failed to be evicted per each strategy

@seanmalloy any particular metrics in mind? I can quickly think of:

number of pods evicted per each strategy
number of pods failed to be evicted per each strategy

@ingvagabund yep that is pretty much it. See below for some additional details. I'm open to suggestions.
Metrics

name
type
description

build_info
gauge
constant 1

pods_evicted_success
counter
total number of pods successfully evicted

pods_evicted_failed
counter
total number of pods failed eviction

The metric names can be changed. There is probably some k8s best practice for naming Prometheus metrics. We should follow those guidelines to determine the names of the metrics.
Labels
The pods_evicted_success and pods_evicted_failed metrics should have these labels.

namespace
descheduler strategy name

The build_info metric should have these labels.

Go version
Descheduler version
Git SHA1
Git Branch

One thing I forgot...
We need a separate metric or maybe a label to differentiate when using --dry-run CLI option and not using the --dry-run CLI option. I'd like to be able to collect metrics and see what descheduler would do without evicting any pods.

With --dry-run set you will be evicting the same pods all over again. Will the metrics be still useful for you (e.g. with the same pod counted 1000 times)

With --dry-run set you will be evicting the same pods all over again. Will the metrics be still useful for you (e.g. with the same pod counted 1000 times)

@ingvagabund after thinking about it I believe you are correct. I edited the original description to remove the requirement of collecting metrics when the --dry-run CLI option is used.

@farah I see that this issue is currently assigned to you. I'm just checking in to see if you have any questions or need any assistance. We are trying to complete this feature as part of the descheduler v0.20.0 release which should be sometime in December.
Thanks!

👍 for this feature. @seanmalloy I see v0.20.0 was released 6 days ago but didn't see mentions of prometheus metrics collection in the changelog. Is this feature still in the works and do you have an estimate on ETA?

👍 for this feature. @seanmalloy I see v0.20.0 was released 6 days ago but didn't see mentions of prometheus metrics collection in the changelog. Is this feature still in the works and do you have an estimate on ETA?

This feature was not implemented for v0.20.0. Maybe for the v0.21.0 release. For sure I'm hoping sometime in 2021.

Is there currently any PRs open for this? The last activity was a couple months ago so it may be safe to assume this is open for anyone interested in contributing!

I looked into it but this is above my skill level, happy for someone else to look into it.
/unassign

/unassign @farah

Is there currently any PRs open for this? The last activity was a couple months ago so it may be safe to assume this is open for anyone interested in contributing!

Correct. Basically we need someone to volunteer to write the code to implement this feature. It's on my extended todo list, but I don't have time to do this right now. So not assigning myself at the moment.
/help

A good first step for implementation would be adding some of these metrics to podEvictor (https://github.com/kubernetes-sigs/descheduler/issues/503). I'll have some time to work on this, unless someone else is interested

WIP PR for discussion: https://github.com/kubernetes-sigs/descheduler/pull/505

This feature will ship with descheduler v0.21.0.


remove template

Remove the broken /set template command in the CLI. This is an alternative to #5613 that doesn't add another parameter to the /api/chat endpoint.
Given the /set template command was broken for 6 months and only one person noticed (thank you @protosam) I think it's probably safe to remove this.

In the beginning I didn't even notice a problem at all, I believed the models I tested just had high biases towards what they were generating.
Using the same models in ollama, huggingface transformers, and mlx, led me to realizing ollama wasn't working right. That led me to debugging it.
This does seem like a really good feature to help drive adoption by users that aren't developers. The logic here is that Joe found this really cool tool called Ollama and isn't a programmer. Joe spends his free time constantly tweaking his arch linux distro or fixing things that break after an upgrade. Despite Joe's lack of programming expertise, Joe is happy to learn about a new command called hammer and use to smack down every *.nail file he sees. Users like this are the ones that find new use cases for technologies and end up working in companies where hammer gets deployed because he had good things to say about it.
I'm not a Joe, but I do like seeing Joe get some wins, because Joe is going to be supporting the things I work on for a while. The more Joe can do on his own, the more I can focus on my tasks.

@protosam I really appreciate you finding/reporting the issue, and spending all that time trying to debug the templates! (I can't thank you enough, honestly).
What I'm worried about is that Joe shouldn't have to figure out the template. We just need Ollama to work, so if we give him a broken template and an editor which is difficult to use, it doesn't really help anyone out (let alone Joe). The Modelfile still works if you want to test out a template, and I think it's probably a lot easier to get templates working when you can use a normal text editor to write it.


Scaling problems

There are some problems with sprites scaling:

The same icon is used in both places. The icon at the top has font-size: 10px, the second icon has font-size: 7px. Everything is OK only when font-size is half-size smaller (5px). I understand that it happens because icon size doesn't fit anymore to the current background-position. But when I changed background-position manually for such cases, Safari, FF and Chrome displayed scaled icon differently, sometimes icon looked good on webkit but was cropped a bit in FF.
Is there any solution for an ultimate sprite scaling?

I'm finding this as an issue, too. It's different from webkit to FF. Changing these to exact pixels is the only fix I've found but that defeats the purpose of many of these features... not able to scale by font size....
Is there any fix out there?

I've found that some of my sprites scale well while others have this bug. I suppose it depends on: 1) if initial size of svg canvas is even 2) if there are paddings between sprites in the spritesheet 3) some svg files had multiple layers not merged in groups, it looks strange, but they scaled incorrectly. But it's rather difficult to reproduce the bug to be sure.


consider adding visual feedback when an entity is created

If you are inspecting one entity, and then create another entity, it is easy to miss that the attributes panel switched over to the new entity.
Random ideas:

Animate collapse + uncollapse of panels
Flash the border of the attribute panel

When you add a component too (perhaps scrolling to the new component?)


Read Time value in sidebar

Problem
I want to know the time taken to read a document.
Idea
A read time value for each file in the sidebar. From what I've read, the typical reading speed is 200-300 words per minute. A plugin for VS Code sets the default reading speed to 200 to calculate reading time for a document. It would be great if this value was customisable, just like the "Words per page" value is. The displayed value could use s, m, h suffixes: 48s, 5m, 1h 23m.
Thanks!

I've been waiting for someone to request this. Won't take long to implement.
Due to space constraints, I'll like go with a single measure for each note, e.g.:
'10s read' (anything from 1 second up to 1 minute)
'10m read' (from 1 minute up to 180 minutes)
'10h read' (3 hours and up)
With a digit of precision after the decimal.

Right, if abbreviations are toggled on it would just be 10.2h or whatever.
You make a good point, 5h32m is still more compact than some of the other count types...I'll give that some more thought.

Thanks for making it happen! If I encounter any issues, I'll let you know.


Select * statement sorts columns alphabetically

Environment
Knex version: 0.21.5
Database + version:sqlite3 5.0.0
OS: macOS Catalina 10.15.5 (19F101)
I have a table with fields like instructor_1, instructor_2, ..., instructor_11, and so on.
Query like:
db('myTable').select()
//or
db.raw('SELECT * FROM myTable')

returns object with columns sorted alphabetically instead of in order of CREATE TABLE statement.
So instructor_1, instructor_11,...
The results are correct and the columns not sorted when I don't use knex.
Is it intentional?

IIRC There might be code in knex that does this sorting. It probably was intentional originally, but I don't think that knex should do that. At least for update statements that sorting was removed (because with inserts order of the updates is significant).

I dont reproduce the problem in 1.0.4:

The table :


Make EAGLContext.currentContext invulnerable from other frameworks.

The engine doesn't yet have a good mechanism to protect its EAGLContext.currentContext from being mistakenly used by other frameworks, as well as making sure the EAGLContext.currentContext it uses is not polluted by other frameworks.
Consider this scenario:
We set the currentContext to "flutterContext" and some framework X who is also using the EAGLContext runs some operations that does something with the EAGLContext. X thinks it is the only player who is handling the EAGLContext so it directly works on the EAGLContext without setting the currentContext.
In this case X is polluting the "flutterContext" without the flutter engine's knowledge.
This recently caused a crash in the Google Map plugin https://github.com/flutter/flutter/issues/31152 which has been temporary fixed in https://github.com/flutter/engine/pull/9377
The PR was only an bandaid fixing the crash; however, we need a fully working solution to protect the "flutterContext".
cc @chinmaygarde @amirh

dup with https://github.com/flutter/flutter/issues/41620 closing this issue.


Increase version for Migrations to 3.1 as well

"dotnet saturn migration" fails due to incompatible netcoreapp version in Migrations project.
Getting started guide will fail at this step for newbies.

Thanks!


Simplify control-plane by merging api and web into a single server component

What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #976
Does this PR introduce a user-facing change?:

Simplify control-plane by merging api and web into a single server component

Thanks for the great job. We just wanted to do it as soon as possible:-)


add: npm usages

Hello Mudgen, I have developed an npm package based on your diamond-2 library. It allows for one-click setup of a development framework and includes upgrade and replacement scripts based on your code modifications. I believe it can significantly lower the barrier for entry-level users. Could you please take a look at it?
see npm: https://www.npmjs.com/package/solidity-framework
see github: https://github.com/VegieDoggie/solidity-framework

I'd like to add that the interface management in the solidity-framework is organized on a facet-by-facet basis, which means it doesn't support deploying or upgrading individual interfaces separately. This deliberate design choice is made with the consideration that as interfaces evolve in a production environment, managing them individually would become increasingly complex. To ensure that interface replacements and upgrades are done correctly, it's essential to establish dedicated documentation, which can be quite complex. This is why I believe managing interfaces on a facet-by-facet basis is necessary.

Great to see this!


[Question] What features use the SMTP configuration ?

The question is : what happen and what is the features of Portus can not use without an SMTP configuration ?
Can I avoid to set an SMTP server ?
Thank you,

The idea is that in some places Portus needs to send an email. Right now, and if I recall correctly, this only happens when users forget their passwords. In this case, they can go to a form in which, upon entering their email, will send them a mail with some instructions. That being said, in the future there might be other features that might need to send emails.

Can I avoid to set an SMTP server ?

Then Portus will assume that sendmail has been configured locally (the default command then is /usr/sbin/sendmail -i -t).
Hope things are more clear now :smile:

Thank you, that's clear for me ! :)


Inconsistency found between the bolt and http drivers in Neo4j 3.0.3

From @jqp5000 on July 14, 2016 15:19
While coding a poc with Spring Neo4j using spring boot I came across what it seems to be an inconsistent behavior between the Bolt driver and the Http driver. Basically after saving a rich relationship between 2 nodes the test fails to load it when using the Bolt driver, however the exact same test succeeds when trying with the Http driver.
The sample project can be downloaded from github
It's a very basic/straight forward test, the only pre-requisite is that you will need to have Neo4j 3 installed with the Bolt connector enabled with authentication disabled. The tests consist in running the exact same code each time with a different driver.
When running 'mvn clean install' 2/3 tests will fail:
my.neo4j.poc.test.unit.BoltDriverTest will FAIL
my.neo4j.poc.test.unit.EmbeddedDriverTest will FAIL
my.neo4j.poc.test.unit.HttpDriverTest will SUCCEED

Neo4j Version: 3.0.3  (neo4j-ogm 2.0.3)
Operating System: Windows 10
API: Java API (Spring)
Steps to reproduce

Run the BoltDriverTest, EmbeddedDriverTest, and the HttpDriverTest.

Expected behavior
All 3 tests should succeed.
Actual behavior
Only the Http test succeeds, the Embbeded and the Bolt test fail.
Copied from original issue: neo4j/neo4j#7581

From @luanne on July 15, 2016 0:19
@jqp5000 thanks for reporting this, could you please report OGM issues here https://github.com/neo4j/neo4j-ogm/issues?

@jqp5000 the reason the relationship entity cannot be mapped is because the start and end node are unavailable with this query:
 @Query("MATCH (a:BankAccount)-[r:HAS_CONTACT]->(p:Person) " +
            "WHERE ID(a)={accountId} " +
            "RETURN r,")
    Iterable<Contact> findByAccountId(@Param("accountId") Long accountId);

You need to return these nodes to be able to construct a valid relationship entity, like this:
 @Query("MATCH (a:BankAccount)-[r:HAS_CONTACT]->(p:Person) " +
            "WHERE ID(a)={accountId} " +
            "RETURN r,a,p")
    Iterable<Contact> findByAccountId(@Param("accountId") Long accountId);

It's a side effect of the HTTP endpoint that allows this to pass- the start and end node are returned by this endpoint anyway.
Please see http://graphaware.com/neo4j/2016/04/06/mapping-query-entities-sdn.html for more info.

Thank you Luanne! it's working, now.


$1 positional argument duplicated in a query using named bindings and nested cte

Environment

Elixir version (elixir -v): Elixir 1.11.0 (compiled with Erlang/OTP 23)
Database and version (PostgreSQL 9.4, MongoDB 3.2, etc.): PostgreSQL (all version are affected)
Ecto version (mix deps): ecto 3.5.2, ecto_sql 3.5.1,
Database adapter and version (mix deps): postgrex 0.15.6
Operating system: mac

Current behavior
In a query using with_cte and named bindings,

Elixir query
    %Postgrex.Interval{} = interval = Dashboards.appropriate_interval(date_range)
    IO.inspect(interval, label: "interval")

    agg_values =
      Value.with_sensors(widget)
      |> OrganizationSensor.with_org_sensor(opts)
      |> join(:inner, [v], stm in subquery(Widget.Measurement.measurements_query(widget)),
        as: :stm,
        on: stm.measurement == v.measurement_name
      )
      |> group_by([_], fragment("1, 2, 3"))
      |> where([v], v.timestamp >= ^date_range.start and v.timestamp <= ^date_range.end)
      |> select([v, org_sensor: os, stm: stm], %{
        bucket: time_bucket(^interval, v.timestamp),
        sensor_name: os.name,
        measurement: stm.measurement,
        value: avg(v.value)
      })
      |> IO.inspect(label: "agg_values")

    "agg_values"
    |> with_cte("agg_values", as: ^agg_values)
    |> group_by([_], fragment("1, 2"))
    |> order_by([_], fragment("1 DESC"))
    |> select([agg_v], %{
      bucket: agg_v.bucket,
      sensor_name: agg_v.sensor_name,
      measurement_names: array_agg(agg_v.measurement),
      values: array_agg(agg_v.value)
    })
    |> IO.inspect(label: "final query")

$1 positional argument is duplicated:

Generated SQL
WITH "agg_values" AS (
WITH "sensors_cte" AS (
		SELECT
			s3. "id" AS "id",
			s3. "identifier" AS "identifier",
			s3. "name" AS "name",
			s3. "description" AS "description",
			s3. "lat" AS "lat",
			s3. "lon" AS "lon",
			s3. "custom_config" AS "custom_config",
			s3. "config" AS "config",
			s3. "image" AS "image",
			s3. "sensor_type_id" AS "sensor_type_id",
			s3. "inserted_at" AS "inserted_at",
			s3. "updated_at" AS "updated_at"
		FROM
			"groups" AS g0
		INNER JOIN (
				SELECT
					sg0. "id" AS "id",
					sg0. "path" AS "path"
				FROM
					"groups" AS sg0
				WHERE (sg0. "id" = $1)) AS s1 ON (g0. "id" = s1. "id")
			OR ARRAY [g0."id"] <@ s1. "path"::uuid []
		INNER JOIN "groups_sensors" AS g2 ON g2. "group_id" = g0. "id"
		INNER JOIN "sensors" AS s3 ON s3. "id" = g2. "sensor_id"
)
	SELECT
		to_timestamp((extract('epoch' FROM v0. "timestamp")::int + extract('epoch' FROM $1::interval)::int / 2) / extract('epoch' FROM $2::interval)::int * extract('epoch' FROM $3::interval)::int) AS "bucket", s2. "name" AS "sensor_name", s3. "measurement" AS "measurement", avg(v0. "value") AS "value"
	FROM
		"values" AS v0
	INNER JOIN "sensors_cte" AS s1 ON v0. "sensor_id" = s1. "id"
	INNER JOIN (
			SELECT
				ss0. "organization_id" AS "organization_id",
				ss0. "sensor_id" AS "sensor_id",
				ss0. "public?" AS "public?",
				ss0. "owner?"

I'll try to come up with a small reproducible example.

Thanks @syfgkjasdkn! To be clear, it is duplicated when it should not. One should be $1 and the other should be $2, correct? Btw, it would help me a lot if you can reduce this examples a bit further (although you already did a great job in reducing it). :)

Hi @josevalim!

One should be $1 and the other should be $2, correct?

Yes, otherwise the time_bucket macro which is expanded to
to_timestamp((extract('epoch' FROM v0. "timestamp")::int + extract('epoch' FROM $1::interval)::int / 2) / extract('epoch' FROM $2::interval)::int * extract('epoch' FROM $3::interval)::int)

receives $1 instead of of $2, and that's a problem since $1 is a sensor uuid, and $2 is an interval.

Btw, it would help me a lot if you can reduce this examples a bit further

I'm still reducing it :) I think the problem starts to appear when there are 3 nested CTEs.

@josevalim Hi! I'm sorry to bother you, but would it be possible to cut a release with this fix? Please :)

Done.


The Kivy language issue does not work when writing in the mapp.kv file or writing code directly in Python. I get this error

Os:linux/ub
Py:3.10.13
Kivy:2.3.0

By default kivy will attempt to load a kv file with the same name as the app.  So myapp.kv is getting loaded even if you do not load it explicitly.  If you are still having trouble share your code (not a picture of your code) on one of the support forums and I would be happy to help you.
This is a support issue please bring this issue to one of the support channels:
DIscord: https://discord.com/invite/eT3cuQp
Kivy users group: https://groups.google.com/g/kivy-users


Create rule DDF00035: Within a StudyVersion, a codeSystem, and a codeSystemVersion, code and decode must be one-to-one.

Create rule defined for cdisc-org/ddf-core-poc#142

I used the is_not_unique_relationship function to test that only 1 version of a codeSystem is used and the code-decode combinations are unique. However the last one I would like to check within a codeSystem. I cannot add that within information to the is_not_unique_relationship function. The is_not_unique_set is also not working because if you repeatedly use the same combination of codeSystem and codeSystemVersion or code and decode then it will give output. I also tried distinct but that gave a lot of program errors.
So the is_not_unique_relationship is the best option with the caveat that if multiple coding systems use the same code it will trigger output. I have added this to the positive test results.
Ticket #103 covers this issue. So the finalization of the rule is blocked by this ticket.

Test data ran as expected.  Negative data gave 8 errors.  Positive data gave no errors.

Saving copy of POC rule definition before overwriting for DDF4:
Authorities:
  - Organization: 'CDISC'
    Standards:
      - Name: USDM
        References:
          - Citations:
              - Cited Guidance: 'USDM'
                Document: 'USDM v2.6'
            Origin: USDM Conformance Rules
            Release Notes: ''
            Rule Identifier:
              Id: 'DDF00035'
              Version: '1'
            Validator Rule Message: ''
            Version: '1.0'
        Version: '3.0'
Check:
  any:
    - name: codeSystem
      operator: is_not_unique_relationship
      value: codeSystemVersion
    - name: decode
      operator: is_not_unique_relationship
      value: code
Core:
  Id: CORE-000427
  Status: Draft
  Version: '1'
Description: 'Within a submitted StudyVersion, a codeSystem and a
  codeSystemVersion, and code and decode must be one-to-one.'
Executability: Fully Executable
Outcome:
  Message: 'Within a submitted StudyVersion, multiple codeSystemVersions are used
    for the same codeSystem, and/or multiple decodes are used for a the same
    code.'
  Output Variables:
    - parent_entity
    - parent_id
    - parent_rel
    - id
    - codeSystem
    - codeSystemVersion
    - code
    - decode
Rule Type: Record Data
Scope:
  Entities:
    Include:
      - Code
Sensitivity: Record


fix(install): don't escape path to scoped packages in subdeps

Close #394

I'm currently getting "Module @org/pkg@version not found" on private modules. Is this PR supposed to solve that? I installed pnpm from a Git clone of this branch but the issue seems to persist.

Maybe, but I am not sure. I your private package used by another dependency?

No. I'm running pnpm install inside the root of a package that depends directly upon the failing package.

Could you please post the content of the pnpm-debug.log to gist?

I could but I'd have to obfuscate a few package names. It's pretty clear though. It's still replacing slashes with %2F:
  251 http 404: "https://registry.npmjs.org/@org-name%2Fpackage-name"

It should encode the package name when it requests a package from the registry, so this is different. You can create a separate issue, but try to provide more details, please.

Will do!


add image support

For the override text should allow an image/html fragment to further customize UI

resolved per commit 4a55df9

4a55df9


Bug: Serialization failing

Hi there,
I have a particular circumstance where the serialization is not consistent with what I am seeing on the screen.
I have built a plunker to demonstrate this. This plunker is based on the original serialization demo. The plunker may be found here.
The plunker shows 5 blocks displayed in a single gridstack. At start up, it uses makeWidget to create the blocks. I have added an id to each block, so it can be tracked.
When you change the location of a block, a change event fires, and I output the serialized content into the text box. So you will be able to see what the location is of each block after dragging and dropping, much like when you click on the Save button. Mind you, if you click on Save, it makes no difference; the block is still in the wrong location in the json.
Run the plunker, maximize your screen, and stretch the running panel until you can see at least three tiles (I say this, because I've seen a scenario where the tiles aren't painted properly and only show up top to bottom. I don't know if that's a problem - it could be a plunker only issue and is not something I need to solve now.)
Take tile 2 and drag it to position x=1, y=0. It should now be the only tile located on the top row, and the full width tile should now appear pushed down onto the second row.
Next pick up tile 2 and drag it to position x=0, y=0. Once you place this, tile 5 appear next to tile 2. It has taken tile 5 from the bottom of the gridstack, and placed it automatically in position x=6,y=0.
Take a look at the output in the text box. It shows:
[
    {
        "id": "tile1",
        "x": 0,
        "y": 7,
        "w": 12,
        "h": 5
    },
    {
        "id": "tile2",
        "x": 0,
        "y": 0,
        "w": 6,
        "h": 7
    },
    {
        "id": "tile3",
        "x": 0,
        "y": 12,
        "w": 6,
        "h": 7
    },
    {
        "id": "tile4",
        "x": 6,
        "y": 12,
        "w": 6,
        "h": 7
    },
    {
        "id": "tile5",
        "x": 6,
        "y": 19,
        "w": 6,
        "h": 7
    }
]

Note that it thinks tile 5 is still located at position x=6, y=19, which is now wrong as it should be x=6, y=0.
To demonstrate that this is not some sort of delay issue, if you now click on the Save button, it will still output the same wrong data.

This is the craziest thing. What on earth is making 5 move up?

Holy smokes. I think you just exemplified https://github.com/troolee/gridstack.js/pull/672 , which I had just asked for an example of. I'm not positive, but I can say for sure that it's erasing the y-values for the CSS, so the widget appears moved but it isn't actually moved dun dun dunnn. I'll try to see if the PR fixes the issue when I have a chance.

@tonywr71 Can you try using the src dev branch and see if this works any better? Via https://github.com/troolee/gridstack.js/pull/672 I've tested against my own project and it does fix the weird reordering. I don't know if it'll fix your actual serialization problem but maybe it was just caused by this other issue.

That version is all good! See new plunker here.
I didn't realise that I could already access your new version. I'll have to create a scripts folder and import it from there instead of npm.

Awesome! - Actually, you can still access it from npm.
https://stackoverflow.com/questions/39732397/install-specific-branch-from-github-using-npm
Just remember to stop using the develop branch when the new one is out. So glad that this fixes your issue!

Awesome! - Actually, you can still access it from npm.
https://stackoverflow.com/questions/39732397/install-specific-branch-from-github-using-npm

but npm install git://github.com/github.com/troolee/gridstack.js#1.0.0-dev --save
won't be always getting the latest code since the rev isn't increasing and I assume it gets cached locally, no ?

I can confirm that using the dev branch causes issues with npm. The sooner this product is released and versioning started, the better. Thanks for this awesome product!


Plugin configured, webhook set-up but is only posting to #general channel

Hi!
I've installed this plugin for our Discourse forum (http://forum.opensavannah.org) to push forum topics to the #opensavannah channel on Slack. I've configured this single channel as the one for the webhook to post to, and the channel itself recognizes that an incoming webhook has been installed on it.
But the posts are instead going to the default #general channel instead of the #opensavannah channel as specified in the Webhook set-up with Slack.
Has anyone else ran into this issue?

I've configured this single channel as the one for the webhook to post to

Did you do that in Slack or in Discourse?
Maybe the channel you choose in Slack is ignored (and perhaps that is a bug either in the code or in the documentation).
I'd recommend checking what you see as the Filter rules in Discourse under Admin > Plugins and then choose Slack on the left.
Those can be configured there or by slash commands in Slack.

This issue was resolved thanks to @mcwumbly. Thanks!


Support: Warn not to use unoptimized build for benchmarking

Adding the color codes may add some extra noise when output is redirected, but I think it's still worth it to make sure it's easily seen by users (and it still shows up when cating the file). We can also do it selectively be detecting if stdout is a tty or not, but making that fully portable isn't entirely trivial.

Imho, since we are not using color anywhere else in Charm++, it might not be necessary here either. How does this handle running with ++quiet?

Imho, since we are not using color anywhere else in Charm++, it might not be necessary here either. How does this handle running with ++quiet?

It doesn't get printed with ++quiet (neither does the rest of the preamble).
I'm not married to the color idea, I just thought it'd be good to make it as evident as possible so that people would actually notice it.

Imho, since we are not using color anywhere else in Charm++, it might not be necessary here either. How does this handle running with ++quiet?

It doesn't get printed with ++quiet (neither does the rest of the preamble).

Ok.

I'm not married to the color idea, I just thought it'd be good to make it as evident as possible so that people would actually notice it.

Imho, we can't use color here. Not everyone uses white-on-black terminals, and depending on the color scheme the user has chosen that warning might be almost invisible. It is also not super portable (color in Windows terminals is weird, and we have seen issues in the cmake build where the color deactivation failed for some reason, which leads to all text printed in yellow).
I'd also argue that the warning is a bit too verbose, and would prefer just attaching (debug build) or (production build) to the end of the Charm++ version printed just before these warnings, but I'm happy to be overruled on that.

Imho, since we are not using color anywhere else in Charm++, it might not be necessary here either. How does this handle running with ++quiet?

It doesn't get printed with ++quiet (neither does the rest of the preamble).

Ok.

I'm not married to the color idea, I just thought it'd be good to make it as evident as possible so that people would actually notice it.

Imho, we can't use color here. Not everyone uses white-on-black terminals, and depending on the color scheme the user has chosen that warning might be almost invisible. It is also not super portable (color in Windows terminals is weird, and we have seen issues in the cmake build where the color deactivation failed for some reason, which leads to all text printed in yellow).

That's a fair concern, I'll take the color stuff out.

I'd also argue that the warning is a bit too verbose, and would prefer just attaching (debug build) or (production build) to the end of the Charm++ version printed just before these warnings, but I'm happy to be overruled on that.

I agree that the current warning is on the verbose side, I was coming from the position that if our concern was people using these builds for benchmarks, then we should be specific about telling them not to and giving them instructions on how to build to do so. That being said, perhaps just saying whether the build is a Debug or Release build is sufficient. I'm interested in hearing other opinions on this as well.

I think the outputs are still hard to catch, can we add some prefix like WARNING: to make it more visible?

@matthiasdiener It looks like CMake does not enable error checking by default like the old build system does.

@matthiasdiener It looks like CMake does not enable error checking by default like the old build system does.

CC: #2839


add flea offer button interrupts with flea market filters

How to reproduce:

search for any item in your inventory
done

cant close it

Originally written by d33v

you didn't follow the instructions

Originally written by naterade

what does that even mean

Originally written by d33v

When you click "New Issue", there is a whole template that you are meant to follow. You are not following it

Originally written by DrakiaXYZ

why do i have to follow the instructions when most of the issues doesnt?

Originally written by d33v

Issue template not followed.

Originally written by Terkoiz


STYLE: Add elx::ComponentInstaller, simplify elxInstallMacro(_classname)

Moved most of the code from the definition of elxInstallMacro(_classname) from "elxMacro.h" to a new file "elxComponentInstaller.h", and a new class template, elx::ComponentInstaller.
Aims to improve code readability and ease further maintenance.

nice!