Annotations for ...args ?

(also posted on SO : http://stackoverflow.com/questions/37490255/how-do-i-annotate-this-function-for-flow )
I have this function in a file where I use Flow
// @flow
...
  static promiseWrapper(fn, ...args) {
    return new Promise(
      async function(resolve, reject) {
        try {
          await fn(...args);
          resolve();
        } catch (e) {
          reject(e);
        }
      }
    )
  }
...

How would I go about annotating this ?
Thanks.

Although I am not sure what you try to accomplish here and without criticising the leanness of this code,... here is my typed solution:
class Foo {
  // We are using generics <U, T> to define the input type / output type (may be the same... I don't know the use-cases)
  static promiseWrapper<U, T>(fn: (...args: Array<U>) => Promise<T>, ...args: Array<U>): Promise<T> {
    return new Promise(async (resolve, reject) => {
      try {
        // I felt like handling the return value of this await function
        const ret = await fn(...args);
        resolve(ret);
      } catch (e) {
        reject(e);
      }
    });
  }
}

// Most of the type inference comes from this function
function fun(...args: Array<number>): Promise<string> {
  const ret = args.reduce((result, num) => (result + num), 0);
  return Promise.resolve(ret.toString());
}

const myProm = Foo.promiseWrapper(fun, 1, 2, 3);

// Here, total should be inferred as string, since our `fun` function returns a Promise<string>
// Generic function definition <T> picks this up correctly :-)
myProm.then((total) => {
  // $ExpectError : total should be inferred as string, hence it should fail on numerical addition
  const foo: number = total + 1;

});

Hope this helps :-)

Let me spend some time to "compile" this and give a try in the code.
Thanks so much !

So I ended up with this in the end:
  static promiseWrapper<T>(fn: (...args: Array<any>) => Promise<T>, ...args: Array<any>): Promise<T> {
    return new Promise(async (resolve, reject) => {
      try {
        const ret = await fn(...args);
        resolve(ret);
      } catch (e) {
        reject(e);
      }
    });
  }

since I have calls like:
await Common.promiseWrapper (this.someFunc1, someObject, someNumber);

await Common.promiseWrapper (this.someFunc2, [someObj.userId], otherObj.id);

where the functions are declared as:
 async someFunc1 (idea: Object, state: number): Promise {
  ...
 }

static async someFunc2 (users: Array<string>, element: string, qId: ?string = undefined, aId: ?string = undefined): Promise {
  ...
}

Make sense ?
Thanks again for your help!

Hey,
I guess this should work... just a few tips:

Anytime you are using any, you risk to run into runtime errors... you should prefer mixed instead, which is basically the same, but it forces you to explicitly drill down the specific type of the parameter inside the fn function (seems tedious, but is important for error prevention)

instead of writing static async someFunc2(... qid: ?string = undefined ...) you can write static async someFunc2(... qid?: string ...)

In ES6, a default parameter will only be used, when the passed function is actually undefined... you you are repeating yourself... with ?: string, you can either pass undefined or a string!
Hope this helps :-)

cool, thanks @ryyppy! This doesn't seem like a bug so I'm gonna close it, but let me know if not. @ryyppy, you should reply on Stack Overflow and pick up some rep :)

Very good points @ryyppy, makes perfect sense ! I will definitely make those changes.
Thanks again for an awesome job on Flow!
P.S. makes me feel like I'm writing in my fave language: Swift ;)


Add DynamoDB provider to the providers list

Amazon DynamoDB data store adaptor for ASP.NET Core Identity.

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

@blowdart ok?

Sure

39772210aa519666eedbbfb2ad9bf484062b062e


precompiled release?

give >:(

u can build it

Git always has a stroke when i try 2 clone it
it thinks the assets repo doesnt exist
On Tue, Mar 29, 2022 at 3:59 PM minhlongnotdev @.***>
wrote:

u can build it
—
Reply to this email directly, view it on GitHub
https://github.com/UnlegitMC/Luminous/issues/2#issuecomment-1081348574,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKQRM7H546CDBIFX5XOEWF3VCJWXVANCNFSM5LDKUBMA
.
You are receiving this because you authored the thread.Message ID:
@.***>


ReferenceError: Cannot access 'CanvasBase' before initialization

Thanks for this great lib. I was able to use it for an hour, everything worked perfectly. Then I tried a rebuild after an ns clean, and it doesn't work anymore and I don't really understand why since I doesn't changed anything since my last builds.
Here is the error I get when I launch my application on the android emulator:
ReferenceError: Cannot access 'CanvasBase' before initialization
System.err: Unable to create application com.tns.NativeScriptApplication: com.tns.NativeScriptException: Error calling module function
System.err: ReferenceError: Cannot access 'CanvasBase' before initialization
System.err: File: (file:///data/data/my.app/files/app/vendor.js:700:58)
System.err:
System.err: StackTrace:
System.err: CanvasBase(file:///data/data/my.app/files/app/vendor.js:700:59)
System.err:     at ./node_modules/@nativescript-community/ui-canvas/canvas.android.js(file: app\webpack:\myapp\node_modules\@nativescript-community\ui-canvas\canvas.android.js:476:42)
System.err:     at __webpack_require__(file: app\webpack:\myapp\webpack\bootstrap:19:0)
System.err:     at ./node_modules/@nativescript-community/ui-canvas/canvas.common.js(file:///data/data/my.app/files/app/vendor.js:710:65)
System.err:     at __webpack_require__(file: app\webpack:\myapp\webpack\bootstrap:19:0)
System.err:     at ./node_modules/@nativescript/webpack/dist/loaders/nativescript-worker-loader/index.js!./node_modules/vue-loader/lib/index.js??vue-loader-options!./app/components/pages/home/CircularGauge.vue?vue&type=script&lang=js&(file:///data/data/my.app/files/app/bundle.js:4006:91)
System.err:     at __webpack_require__(file: app\webpack:\myapp\webpack\bootstrap:19:0)
System.err:     at ./app/components/pages/home/CircularGauge.vue?vue&type=script&lang=js&(file:///data/data/my.app/files/app/bundle.js:5994:240)
System.err:     at __webpack_require__(file: app\webpack:\myapp\webpack\bootstrap:19:0)
System.err:     at ./app/components/pages/home/CircularGauge.vue(file:///data/data/my.app/files/app/bundle.js:5459:101)
System.err:     at __webpack_require__(file: app\webpack:\myapp\webpack\bootstrap:19:0)
System.err:     at ./node_modules/@nativescript/webpack/dist/loaders/nativescript-worker-loader/index.js!./node_modules/vue-loader/lib/index.js??vue-loader-options!./app/components/pages/home/HomeCard.vue?vue&type=script&lang=js&(file:///data/data/my.app/files/app/bundle.js:4157:72)
System.err:     at __webpack_require__(file: app\webpack:\myapp\webpack\bootstrap:19:0)
System.err:     at ./app/components/pages/home/HomeCard.vue?vue&type=script&lang=js&(file:///data/data/my.app/files/app/bundle.js:6007:235)
System.err:     at __webpack_require__(file: app\webpack:\myapp\webpack\bootstrap:19:0)
System.err:     at ./app/components/pages/home/HomeCard.vue(file:///data/data/my.app/files/app/bundle.js:5498:96)
System.err:     at __webpack_require__(file: app\webpack:\myapp\webpack\bootstrap:19:0)
System.err:     at ./node_modules/@nativescript/webpack/dist/loaders/nativescript-worker-loader/index.js!./node_modules/vue-loader/lib/index.js??vue-loader-options!./app/components/pages/Home.vue?vue&type=script&lang=js&(file:///data/data/my.app/files/app/bundle.js:1841:89)
System.err:     at __webpack_require__(file: app\webpack:\myapp\webpack\bootstrap:19:0)
System.err:     at ./app/components/pages/Home.vue?vue&type=script&lang=js&(file:///data/data/my.app/files/app/bundle.js:5760:231)
System.err:     at __webpack_require__(file: app\webpack:\myapp\webpack\bootstrap:19:0)
System.err:     at ./app/components/pages/Home.vue(file:///data/data/my.app/files/app/bundle.js:4847:92)
System.err:     at __webpack_require__(file: app\webpack:\myapp\webpack\bootstrap:19:0)
System.err:     at ./node_modules/@nativescript/webpack/dist/loaders/nativescript-worker-loader/index.js!./node_modules/vue-loader/lib/index.js??vue-loader-options!./app/components/pages/App.vue?vue&type=script&lang=js&(file:///data/data/my.app/files/app/bundle.js:1806:67)
System.err:     at __webpack_require__(file: app\webpack:\myapp\webpack\bootstrap:19:0)
System.err:     at ./app/components/pages/App.vue?vue&type=script&lang=js&(file:///data/data/my.app/files/app/bundle.js:5747:230)
System.err:     at __webpack_require__(file: app\webpack:\myapp\webpack\bootstrap:19:0)
System.err:     at ./app/components/pages/App.vue(file:///data/data/my.app/files/app/bundle.js:4813:91)
System.err:     at __webpack_require__(file: app\webpack:\myapp\webpack\bootstrap:19:0)
System.err:     at ./app/main.js(file:///data/data/my.app/files/app/bundle.js:19:79)
System.err:     at __webpack_require__(file: app\webpack:\myapp\webpack\bootstrap:19:0)
System.err:     at __webpack_exec__(file:///data/data/my.app/files/app/bundle.js:9318:39)
System.err:     at (file:///data/data/my.app/files/app/bundle.js:9319:221)
System.err:     at __webpack_require__.X(file: app\webpack:\myapp\webpack\runtime\startup entrypoint:6:0)
System.err:     at (file:///data/data/my.app/files/app/bundle.js:9319:47)
System.err:     at (file:///data/data/my.app/files/app/bundle.js:9324:3)
System.err:     at require(:1:266)

Here the import line that cause the error :
import { Paint, Cap, createRectF, Style } from '@nativescript-community/ui-canvas'

If I remove the createRectF, the error disappears and the application runs. I tried to replace createRectF by createRect but the error still occurs.
Which platform(s) does your issue occur on?

Android API Q Emulator

Please, provide the following version numbers that your issue occurs with:

CLI: 8.0.1
Cross-platform modules: @nativescript/core/package.json:version -> 8.0.11
Runtime(s):  "@nativescript/android": "8.0.0"
@nativescript-community/ui-canvas": "^4.2.13"
@nativescript/core": "~8.0.8"
"nativescript-vue": "^2.9.0",

If you have no idea where it can come from I will try tomorrow to create a repo with where the error is reproducible but I'm not even sure I can do it because the error appeared when I did not change anything in the code.
It seems to be more of a configuration/build problem on my side. I tried to reclone my project, and rebuild it from scratch but it's still the same. However, I'm a bit stuck because I have no way to make this error disappear.

Ok sorry I found where the problem came from I may have opened the exit a little too quickly though it is not in my habits, here is the solution:
This code causes the error :
    draw({ canvas }) {
      // const paint = new Paint()
      const rect = createRectF(0, 0, 10, 10)
    },

This code resolve the error :
const paint = new Paint()
const rect = createRectF(0, 0, 10, 10)

So basically you just have to create an instance of Paint before doing anything if I understand correctly. Is this a normal behavior?
I was sure I didn't modify any code but finally I did, sorry! At least this issue will serve the next person who makes the same mistake as me 😅

@Julien-R44 dont be sorry you found an issue. It means i have a circular import dependency somewhere in the lib.
Thanks you for investigating! Use your trick for now, i will find and fix the issue

@Julien-R44 do you still have the issue?


Can a context have both a "public" and a "private" heap?

Hi, the question is simple: can a thread have both a public heap, where the objects are shared with the other threads in the heap, and a private heap, where the declared objects can be accessed only by that thread? How to do it?
Thank you!

You could create multiple Duktape heaps: they're isolated from each other, and sharing references (or anything else) won't even work.
Inside a single Duktape heap there's no such isolation. But that's generally not needed: if code A creates an object but doesn't provide any reference to code B, there's no way code C (assuming it is Ecmascript) could access the object. So just ensuring references are not available is enough.
For example, if you create two separate global spaces (duk_push_thread_new_globalenv()), they will have separate global objects and no shared references by default. An object created in one environment, even when registered as a global, won't be visible in the other.

i don't understand how to avoid providing references to other threads in the same heap. If in a thread i do something like this "duk_eval_string(ctx, "'var i = 0;)";  it would be visible to all the threads in the same heap, is it right? how to avoid it?

Suppose you create two global objects using duk_push_thread_new_globalenv(). Call them A and B.
If script code in A does:
var foo = { hello: 'there' };

that object will exist in the same Duktape heap as B. But no code in B has a way to read foo or reference the target object.
So yes, it would be visible to B if it had the reference, but without the reference it isn't.

ok, but if then i want to declare an object visible from both the threads? i'm trying to wrap semophores of an RTOS so they have to be shared among threads but i also want to have the possibility of declaring objects visible only by one thread. Is it possible?

There's no way to "declare" an object as such, but you can just provide a reference from code A to code B (or vice versa) in some way. Note that you can't provide access to a variable (foo) but rather the value (the object).
One way to do that is via C code:
duk_get_global_string(ctx_A, "foo");  /* read the object reference */
duk_xcopy_top(ctx_B /*to*/, ctx_A /*from*/, 1 /*count*/); /* move it to another stack */
duk_pop(ctx_A);  /* remove from A */
duk_put_global_string(ctx_B, "foo");  /* register as global in B */

Now code B will see a global variable 'foo' pointing to the same object. The variables are not "linked" in that writing a new value to 'foo' in A or B won't change the other. Only the referenced object is shared.
Note that you don't need to read the reference from a global object or store it to a global object. You can just as well read the property of some object in A and store the value in some object in B. All that matters is that the reference gets copied.

which is, in practice, the difference between threads in different heaps and threads with different global enviroments? why should i choose the first option or the second one?

I'm confused what you mean by "thread" - are you talking about native threads?  If so a single Duktape heap is not threadsafe and you will need to create a separate one for each thread.
Note that different heaps can't share objects at all, at least not without serialization.

@edoardomazzella I think most of these issues should be covered by http://duktape.org/guide.html#threading and the links there.
In short, one Duktape heap == one object pool for garbage collection, with only one native thread allowed at a time.
If you have two (or more) Duktape heaps, you can't mix them in API calls or move objects between heaps. Everything that happens between the heaps must be serialized.

@edoardomazzella Closing this now, please reopen if something is unanswered.

ok thank you both, i understood some important things. There is just another question i have that is not very clear in the documentation: inside a certain heap can i suspend the Duktape execution and act on another heap before the duk_resume?

That's safe, as long as the two threads don't try to use the heap simultaneously.

thank you!


Fix 5-1 pandas and sns calls

Hello,
there are currently two problems with the README of 5.1:
df.corr
The default value of df.corr()'s numeric_only parameter changed to False in 2.0.
Therefore the code in the notebook throws an error when executed.
I set the parameter back to True, which fixes the notebook.
sns.FacetGrid
The name of the size parameter has changed to height.
I fixed that as well.
There is also a change in the handling of sns color palettes, where you now have to assign the hue parameter to x, but I did not include that change, yet. Let me know, if you would like me to add it.
Best regards,
Maik

@microsoft-github-policy-service agree company="University of Applied Sciences Osnabrueck"


Potential Fix for What's new in Windows 10 link

The link for What's new in Windows 10 did not remove the md on the production side
adding a ./ as a potential fix but if you know of a different fix feel free to adjust too

@computeronix,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

The problem is not a ./ it is that someone added .md to the link. The link should just go to the filename without the extension.

@computeronix
If you would like to make the suggested change in this pull request, I can merge it into the content.

I'm taking care of the baby. I'll not be able to make changes until this afternoon.

My request was for computeronix to make the change so that he can get credit for the update on the topic. There is nothing more required for you to do, Greg. Just enjoy baby-time :)

This has been corrected as suggested  removed the . in the ./
Then removed .md
Thank you!


Added support for LPC11U34_421 and AppNearMe's MicroNFCBoard

Hi all,
Changed the Copyright year to 2015. With the new commit all default tests pass except for the Serial loop test as USBTX and USBRX are NC.

Not just for this PR, it might be beneficial when adding a new platform , to share the test results in description of PR.

@0xc0170 Sure, the table that singletest.py spits out looks quite ugly in GitHub though:
Test summary:
+---------+-------------------------+-----------+-------------+---------------------------------------+--------------------+---------------+-------+
| Result  | Target                  | Toolchain | Test ID     | Test Description                      | Elapsed Time (sec) | Timeout (sec) | Loops |
+---------+-------------------------+-----------+-------------+---------------------------------------+--------------------+---------------+-------+
| OK      | APPNEARME_MICRONFCBOARD | ARM       | DTCT_1      | Simple detect test                    |        5.53        |       10      |  1/1  |
| OK      | APPNEARME_MICRONFCBOARD | ARM       | EXAMPLE_1   | /dev/null                             |        8.5         |       10      |  1/1  |
| OK      | APPNEARME_MICRONFCBOARD | ARM       | MBED_10     | Hello World                           |        5.35        |       10      |  1/1  |
| OK      | APPNEARME_MICRONFCBOARD | ARM       | MBED_11     | Ticker Int                            |       16.42        |       20      |  1/1  |
| OK      | APPNEARME_MICRONFCBOARD | ARM       | MBED_12     | C++                                   |        6.3         |       10      |  1/1  |
| OK      | APPNEARME_MICRONFCBOARD | ARM       | MBED_16     | RTC                                   |        9.81        |       15      |  1/1  |
| OK      | APPNEARME_MICRONFCBOARD | ARM       | MBED_2      | stdio                                 |        5.92        |       20      |  1/1  |
| OK      | APPNEARME_MICRONFCBOARD | ARM       | MBED_23     | Ticker Int us                         |       16.47        |       15      |  1/1  |
| OK      | APPNEARME_MICRONFCBOARD | ARM       | MBED_24     | Timeout Int us                        |       16.58        |       15      |  1/1  |
| OK      | APPNEARME_MICRONFCBOARD | ARM       | MBED_25     | Time us                               |       16.32        |       15      |  1/1  |
| OK      | APPNEARME_MICRONFCBOARD | ARM       | MBED_26     | Integer constant division             |        6.31        |       10      |  1/1  |
| OK      | APPNEARME_MICRONFCBOARD | ARM       | MBED_34     | Ticker Two callbacks                  |        16.4        |       15      |  1/1  |
| OK      | APPNEARME_MICRONFCBOARD | ARM       | MBED_A1     | Basic                                 |        6.3         |       10      |  1/1  |
| OK      | APPNEARME_MICRONFCBOARD | ARM       | MBED_A21    | Call function before main (mbed_main) |        6.3         |       10      |  1/1  |
| TIMEOUT | APPNEARME_MICRONFCBOARD | ARM       | MBED_A9     | Serial Echo at 115200                 |       20.58        |       10      |  0/1  |
| OK      | APPNEARME_MICRONFCBOARD | ARM       | MBED_BUSOUT | BusOut                                |        7.33        |       15      |  1/1  |
+---------+-------------------------+-----------+-------------+---------------------------------------+--------------------+---------------+-------+
Result: 15 OK / 1 TIMEOUT

@0xc0170

Result
Target
Toolchain
Test ID
Test Description
Elapsed Time (sec)
Timeout (sec)
Loops

OK
APPNEARME_MICRONFCBOARD
ARM
DTCT_1
Simple detect test
5.53
10
1/1

OK
APPNEARME_MICRONFCBOARD
ARM
EXAMPLE_1
/dev/null
8.5
10
1/1

OK
APPNEARME_MICRONFCBOARD
ARM
MBED_10
Hello World
5.35
10
1/1

OK
APPNEARME_MICRONFCBOARD
ARM
MBED_11
Ticker Int
16.42
20
1/1

OK
APPNEARME_MICRONFCBOARD
ARM
MBED_12
C

6.3

OK
APPNEARME_MICRONFCBOARD
ARM
MBED_16
RTC
9.81
15
1/1

OK
APPNEARME_MICRONFCBOARD
ARM
MBED_2
stdio
5.92
20
1/1

OK
APPNEARME_MICRONFCBOARD
ARM
MBED_23
Ticker Int us
16.47
15
1/1

OK
APPNEARME_MICRONFCBOARD
ARM
MBED_24
Timeout Int us
16.58
15
1/1

OK
APPNEARME_MICRONFCBOARD
ARM
MBED_25
Time us
16.32
15
1/1

OK
APPNEARME_MICRONFCBOARD
ARM
MBED_26
Integer constant division
6.31
10
1/1

OK
APPNEARME_MICRONFCBOARD
ARM
MBED_34
Ticker Two callbacks
16.4
15
1/1

OK
APPNEARME_MICRONFCBOARD
ARM
MBED_A1
Basic
6.3
10
1/1

OK
APPNEARME_MICRONFCBOARD
ARM
MBED_A21
Call function before main (mbed_main)
6.3
10
1/1

TIMEOUT
APPNEARME_MICRONFCBOARD
ARM
MBED_A9
Serial Echo at 115200
20.58
10
0/1

OK
APPNEARME_MICRONFCBOARD
ARM
MBED_BUSOUT
BusOut
7.33
15
1/1

OK
APPNEARME_MICRONFCBOARD
uARM
DTCT_1
Simple detect test
5.35
10
1/1

OK
APPNEARME_MICRONFCBOARD
uARM
EXAMPLE_1
/dev/null
8.36
10
1/1

OK
APPNEARME_MICRONFCBOARD
uARM
MBED_10
Hello World
5.51
10
1/1

OK
APPNEARME_MICRONFCBOARD
uARM
MBED_11
Ticker Int
16.3
20
1/1

OK
APPNEARME_MICRONFCBOARD
uARM
MBED_12
C++
6.3
10
1/1

OK
APPNEARME_MICRONFCBOARD
uARM
MBED_16
RTC
9.42
15
1/1

OK
APPNEARME_MICRONFCBOARD
uARM
MBED_2
stdio
5.72
20
1/1

OK
APPNEARME_MICRONFCBOARD
uARM
MBED_23
Ticker Int us
16.34
15
1/1

OK
APPNEARME_MICRONFCBOARD
uARM
MBED_24
Timeout Int us
16.41
15
1/1

OK
APPNEARME_MICRONFCBOARD
uARM
MBED_25
Time us
16.34
15
1/1

OK
APPNEARME_MICRONFCBOARD
uARM
MBED_26
Integer constant division
6.27
10
1/1

OK
APPNEARME_MICRONFCBOARD
uARM
MBED_34
Ticker Two callbacks
16.39
15
1/1

OK
APPNEARME_MICRONFCBOARD
uARM
MBED_A1
Basic
6.25
10
1/1

OK
APPNEARME_MICRONFCBOARD
uARM
MBED_A21
Call function before main (mbed_main)
6.23
10
1/1

TIMEOUT
APPNEARME_MICRONFCBOARD
uARM
MBED_A9
Serial Echo at 115200
20.32
10
0/1

OK
APPNEARME_MICRONFCBOARD
uARM
MBED_BUSOUT
BusOut
7.33
15
1/1

OK
APPNEARME_MICRONFCBOARD
GCC_ARM
DTCT_1
Simple detect test
5.36
10
1/1

OK
APPNEARME_MICRONFCBOARD
GCC_ARM
EXAMPLE_1
/dev/null
8.66
10
1/1

OK
APPNEARME_MICRONFCBOARD
GCC_ARM
MBED_10
Hello World
5.3
10
1/1

OK
APPNEARME_MICRONFCBOARD
GCC_ARM
MBED_11
Ticker Int
16.33
20
1/1

OK
APPNEARME_MICRONFCBOARD
GCC_ARM
MBED_12
C++
6.24
10
1/1

OK
APPNEARME_MICRONFCBOARD
GCC_ARM
MBED_16
RTC
9.75
15
1/1

OK
APPNEARME_MICRONFCBOARD
GCC_ARM
MBED_2
stdio
5.85
20
1/1

OK
APPNEARME_MICRONFCBOARD
GCC_ARM
MBED_23
Ticker Int us
16.34
15
1/1

OK
APPNEARME_MICRONFCBOARD
GCC_ARM
MBED_24
Timeout Int us
16.38
15
1/1

OK
APPNEARME_MICRONFCBOARD
GCC_ARM
MBED_25
Time us
16.3
15
1/1

OK
APPNEARME_MICRONFCBOARD
GCC_ARM
MBED_26
Integer constant division
6.21
10
1/1

OK
APPNEARME_MICRONFCBOARD
GCC_ARM
MBED_34
Ticker Two callbacks
16.31
15
1/1

OK
APPNEARME_MICRONFCBOARD
GCC_ARM
MBED_A1
Basic
6.24
10
1/1

OK
APPNEARME_MICRONFCBOARD
GCC_ARM
MBED_A21
Call function before main (mbed_main)
6.24
10
1/1

TIMEOUT
APPNEARME_MICRONFCBOARD
GCC_ARM
MBED_A9
Serial Echo at 115200
20.5
10
0/1

OK
APPNEARME_MICRONFCBOARD
GCC_ARM
MBED_BUSOUT
BusOut
7.3
15
1/1

Thanks. The very last thing, can you sign http://developer.mbed.org/contributor_agreement/ ? I'll go ahead and merge this then.

Thanks Martin, I just signed it.


Starknet relayer implements checkable

note: e2e CI will not pass due to breaking changes in core + broken CI test
it should build properly once: https://github.com/smartcontractkit/chainlink/pull/8340 is merged


Week 26 Blog Updates and Improvements - Jeffrey Lee

[x] Completed Notes and Hacks for 2.4a+b
[x] Complete Database in SQL DB with CRUD and Menu Functionality (Will Show in VSCode)

Debug Screenshot:

2.4a Notebook Link
2.4b Notebook Link

2.7
Jeffrey had exceptional code and explains it very well. He has observations on code cells but no notes. He has CRUD,MENU, and made a sqlite table.

I am satisfied with the grade and the CODING aspect of my work, I was a bit lazy in not wanting to finish my notes for the two notebook concepts and mostly focused on the database and CRUD. In the future, I will balance all aspects of my work when preparing for live reviews. I have definitely met the standards for creating and implementing the database.


Specify the path of swagger/index.html

Hi,
is there a way to specify a different swagger/index.html? I cannot find a way. Or can someone find where in the code that points to the swagger/index.html file?
Thanks!

anyone ?


[5.7] Add validation for explicit / implicit model binding.

This is my first pull request so I hope everything is ok.
I'm not yet sure if I should describe this as a feature or as a bug fix. This is an attempt to fix the issue described in #26239. They still need to add a function getRouteKeyValidator to their Models.
It adds getRouteKeyValidator which return null or a Validator instance. This instance is then used to validate the value for the key in implicit / explicit model binding. I've choosen to keep the current behaviour (no validation).
I have added tests to assure that everything works correctly. There are four extra tests:

explicit binding with correct value for validation
explicit binding with incorrect value for validation
implicit binding with correct value for validation
implicit binding with incorrect value for validation

Let me know if there are more changes needed.

is this ever merged ?


update the wining modal

Signed-off-by: Amul Agrawal<EMAIL_ADDRESS>

Please review the requeust.


Update devise.rb

Fixes issue #505
I fixed the email validation line in config/initializers/devise.rb
Describe the changes you have made in this pr -
Changed line 173 from "config.email_regexp = /\A[^@\s]+@[^@\s]+\z/" to "config.email_regexp = /^\w+([.-]?\w+)@\w+([.-]?\w+)(.\w{2,3})+$/"
Screenshots of the changes (If any) -

https://github.com/CircuitVerse/CircuitVerse/blob/master/app/controllers/group_members_controller.rb#L35 This is the line you need to check

Okay, now i also changed the utils.rb which is actually responsible for the email validation. I think it should work correctly now.

Coverage decreased (-0.4%) to 82.071% when pulling fdc43055bf76a51e9fd9c052feb7fb33b69aeaef on chambin0:master into 6569232a75d650e5123363c7f51280129df87f9b on CircuitVerse:master.

Update PR title, squash commits and provide meaningful commit message


App switching

Teacher view:
Allow the teacher to select an app
Allow the teacher to change the app at any stage by clicking on the classroom tab
Student View:
Display the app that has been selected by the teacher
Out of Scope/V2:
Adding new or custom apps (only allow Google Docs, Snap and Scratch).

looking really good so far. Do you think google Docs and Scratch are the right two for us to focus on for now? Maybe we should drop google docs (just becuase of the need to sign in (and the complexity around that)? Alternatively it could be a good example of a signin required app. You could just make this page the landing page for students when docs is selected? (that way if they are logged in they head straight to the app, otherwise they login)


[FLOC-3740] Add call to obtain container state

The flocker.apiclient.FlockerClient does not contain an operation to call the /state/containers API.
Adding it to support the benchmarking requirement to measure creation of a container and waiting for it to start.
The code is almost a combination of the call to obtain Dataset state and obtain Container configuration.
Code for both the fake and real containers need additional information to be transferred from configuration to state during synchronization.  The FakeFlockerClient copies configuration to state during synchronization.  The tests for the real FlockerClient copy the applications data from the persistence service to the cluster state service.

Looks great!
A little surprised to be doing work adding support for container agent and container status, but if it makes benchmarking work easier, I'm all for it.
One note about using unicode keys that you should probably consider, otherwise merge when tests are sufficiently green. Thanks!


nixos/waybar: restart service

Motivation for this change
Waybar sometimes fails, especially when sway is being started. This should circumvent some headaches.
Things done
Restart waybar automatically after 5 seconds.
Related: https://github.com/NixOS/nixpkgs/issues/57602

[X] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Notify maintainers
cc @FlorianFranzen @minijackson @Synthetica9

I haven't tried it yet, but it seems fine and pretty useful to me!

What's the root cause of the failure? I would prefer to solve it upstream than restarting and hoping for the best.

I haven't identified a single root cause yet. But I observe my waybar sometimes restarting when I change display configuration via kanshi and when sway starts up.
I also think it is best practice to have this kind of service restart automatically. There is no good reason to stop waybar while sway is running and if people still want it for some reason, they can override it.

I stopped using Waybar, so I don't really care anymore.


Python Image Builds

:tada: This PR is included in version 0.6.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Check login() method exists, punt to setUser()

Description
As Discussed in Discord, in CSV import and export jobs use login() if the method is available in the guard, else punt to setUser().
Visual changes
No visual changes
Functional changes

[x] Code style has been fixed by running the composer cs command.
[x] Changes have been tested to not break existing functionality.
[x] Documentation is up-to-date.

Why does Filament interact with the guard inside a job?
Also, can you link the Discord discussion? I can't find it.

It was in a private channel. This PR is to undo a breaking change that was made a few weeks ago, we are removing login() altogether in v4.


did any one tested it with django 4.06 python 3.10

Hi all did any one tested it with django 4.06 python 3.10
actually i want to import and export to postgresql where my django app uses many to many fields and also the foreign keys i tried with django-import-export which prints ID only of foreign key and many to many but not the name. did anyone resolved this issue

Hi
Yes it gets tested on build using tox with latest django version and on python 3.10.
Import of many to many fields is supported.  I suggest use the 3.0 beta.  The tests and example app may help you solve your issue.

Thanx a lot for guiding this much after hours of struggle i came to know that we can retrieve the Name of FK instead of id by def.dehydrate
and then i fall into an issue that the fields i whitelisted to export are were not taken into account by django import export it was exporting the default fields data. i was trying to extract only few of the fields.
issue is by below code only the field which is dehydrated is getting exported all others are skipped/not exported
class MemberResource(resources.ModelResource):
    Brand=Field()
    class meta:
        model = model
        fields=('title','Brand')
    def dehydrate_Brand(self, obj):
        return str(obj.Brand.title)

class modelAdmin(ImportExportModelAdmin):
    resource_class = MemberResource
    list_display=['title','Model_code','Chipset','chipset_description','Brand','categories']
    search_fields = ['title','Model_code','Chipset',]
    fields=('title','Model_code','Chipset','chipset_description','image','Brand','Cat')
admin.site.register(model,modelAdmin)

any one here can point out the mistake

All above mentioned issues were resolved can close the question
now i am facing issues with importing data to database which contains many to many and foreign keys

Awesome, glad to hear it!


control directory for .snap.new files

I am working on a project that uses bazel (which is very strict about hermiticity and directories).  In order to make insta play well in this ecosystem, I would like to be able to designate a specific directory that it will write output files to and then to pass that directory to insta review for acceptance.
Roughly something like:
INSTA_NEW_SNAP_DIR=... $TEST_RUNNER
INSTA_NEW_SNAP_DIR=... cargo insta review

Do you think that such a change would be accepted if offered?

Does snapshot_path do this? https://github.com/mitsuhiko/insta/blob/8753f2cc59284bd8bc8c645594e524fd16495423/insta/src/settings.rs#L480-L487

I haven't used bazel much myself, but it's also worth checking out INSTA_WORKSPACE_ROOT (and may require CARGO_MANIFEST_DIR until #614 is merged) to set paths across all tests. @thoughtpolice had similar-sounding issues in https://github.com/mitsuhiko/insta/issues/575.
Keen to support this sort of setup, so will close the gap if one still exists.

My current (very hacky) environment has a test:
use insta;

#[test]
fn test_all() {
  insta::with_settings!({snapshot_path => "/Users/beaker/dev/bronto/bronto/tool/e2e/"}, {
    insta::glob!("e2e/*.c", |path| {
      let input = std::fs::read_to_string(path).unwrap();
      insta::assert_snapshot!(input);
    })
  });
}

which when run fails with trying to write the .snap.new file (I think).
$ bazel test //bronto/tool:runner_test --test_env=INSTA_WORKSPACE_ROOT=$(pwd) --test_env=CARGO_MANIFEST_DIR=$(pwd)
WARNING: Build option --test_env has changed, discarding analysis cache (this can be expensive, see https://bazel.build/advanced/performance/iteration-speed).
INFO: Analyzed target //bronto/tool:runner_test (0 packages loaded, 4556 targets configured).
FAIL: //bronto/tool:runner_test (see /private/var/tmp/_bazel_beaker/66706307a1c7f7ec3458df3c2b2f96d7/execroot/_main/bazel-out/darwin_x86_64-fastbuild/testlogs/bronto/tool/runner_test/test.log)
INFO: From Testing //bronto/tool:runner_test:
==================== Test output for //bronto/tool:runner_test:

running 1 test
test test_all ... FAILED

failures:

---- test_all stdout ----
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Snapshot Summary ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Snapshot file<EMAIL_ADDRESS>Snapshot<EMAIL_ADDRESS>Source: bronto/tool/runner.rs:8
Input file: bronto/tool/e2e/id.c
────────────────────────────────────────────────────────────────────────────────
Expression: input
────────────────────────────────────────────────────────────────────────────────
+new results
────────────┬───────────────────────────────────────────────────────────────────
          0 │+int id(int noep) { return noep; }
────────────┴───────────────────────────────────────────────────────────────────
thread 'test_all' panicked at bronto/tool/runner.rs:8:7:
called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I have played around with a bunch of things to help it find the .snap files and can get that to work reliably, however, whenever the test wants to write a .snap.new it fails with a permission error.  That is the setting I am trying to control (without much luck).

@fowles I don't get the permission error yet, but I see some other problems. Will have a look. At the very least we should say what file it was trying to write to...

@fowles #631 should give us a better error — do you want to try that?
I fixed one other issue. I have a couple of other things I want to look at, but otherwise don't know a precise reason behind the issue you see.

Thanks!  I will try this in the next day or two.

I also refactored the code that handles paths, so I would now be quite surprised if INSTA_WORKSPACE_ROOT doesn't work, though not 100% as don't have a test case.
If you find there is still an issue, please reopen / add a new issue and I'll investigate.


[IRGen] Emit bit for @main into entry section.

The _swift5_entry section contains a relative pointer to the entry-point function (spelled variously _main and @main depending on context). Support differentiating whether that entry point originates from a type annotated @main or something else (i.e. main.swift) via a second relative-pointer-sized field.  For now, that field is just a bit: 1 if there is a type annotated @main, 0 otherwise.  In the future, that field could be a relative pointer to the type descriptor for the type.

@swift-ci please test

@swift-ci please test

Potentially!  Like the description says

In the future, that field could be a relative pointer to the type descriptor for the type.

On the one hand, having a relative-pointer sized field which is non-zero just when there's a type annotated @main is a slightly more minimal ABI to commit to--that field could be upgraded to a full relative pointer later.  And perhaps keeping a reference to the descriptor would keep things alive unnecessarily.  On the other hand, maybe we're not saving much by not committing to that further ABI now.
What do you think, @jckarter?

It's a good question. I was thinking that, if we're putting a flag bit there now, we would need to take another word to store a descriptor later. But on the other hand, having a flag word reserved is probably a good idea for adding future flags too. So this is probably fine as is.

Makes sense.  I changed it over from being "a bit and eventually perhaps a type descriptor relative pointer" to instead being "a flag word containing a bit indicating that the entry point comes from @main and perhaps will eventually contain a bit indicating that there is a type descriptor that appears after the flag word".  That's NFC on x86_64 and arm64, but indicates the future direction.

@swift-ci please test


[BUG] Playwright won't initialise when console thread blocked

System info

Playwright Version: [v1.40.0]
Operating System: Windows 10, Windows Server 2016
Browser: Chromium
Other info:

Source code

[x] I provided exact source code that allows reproducing the issue locally.

In addition to playwright, requires:

serilog-sinks-console
serilog-sinks-async

I have included serilog as this is how I have been able to replicate the issue.
using Microsoft.Playwright;
using Serilog;

Log.Logger = new LoggerConfiguration()
	.WriteTo.Async(a => a.Console())
	.CreateLogger();

int i = 1;
while (true)
{
	File.AppendAllText("./data.txt", DateTime.Now.ToString("hh:mm:ss.fff") + "\n");
	var playwright = await Playwright.CreateAsync();
	//var browser = await playwright.Chromium.ConnectOverCDPAsync("http://localhost:9222");
	//await browser.DisposeAsync();
	Log.Information(i.ToString());
	await Task.Delay(2000);
	playwright.Dispose();
	i++;
}

Steps

Run the code as a windows console application (unsure if the occurs on other platforms)
Select the console screen text to block console IO. This causes serilog to be unable to write logs to console and blocks the background serilog thread. See this link for more details.
Playwright.CreateAsync() is unable to run due to the thread being blocked and hangs indefinitely

Expected
Playwright.CreateAsync() is successful. Code continues to run and write timestamps to file/iterations to console.
Actual
Playwright.CreateAsync() hangs indefinitely. Code does not continue to run and timestamps stop being written to file/iterations to console.
Playwright Thread

Serilog Thread

Seems like the line which hangs is: Console.OutputEncoding = new UTF8Encoding(false);. Does this also hang without Playwright - like just executing this line after your use your Serilog log library?

Yes I see the same hanging behaviour using just your line instead of the Playwright line

Sounds like a bug in Serilog or .NET in my opinion. I recommend fing a bug on Serilog side.

Sure thing, will do. Thanks @mxschmitt

Closing as per above then!


Using delay in setup() depends on object property ordering

When trying to set {delay: true} in a mocha.setup() call, it only works if the delay property is set before the ui property.
Here's some reproduction steps for Chrome.
<!doctype html>

    <link rel="stylesheet" href="mocha.css" />

In the case where it doesn't work, the global run() method is undefined.
The issue is that mocha.setup() just iterates over the properties and calls their corresponding methods
for (var opt in opts) this[opt](opts[opt]);

And in the ui method, the pre-require event is emitted, and it's in those event handlers that the global "run" method is supposed to be registered:
context.run = mocha.options.delay && common.runWithSuite(suite);

However, if the ui method is called before the delay method, then mocha.options.delay will not be set and the global run method will not be defined.

@hollomancer I think #1800 should fix this issue and all comments were addressed, but the pr-needs-work label was never removed. If there is something else that needs to be done, please let me know and I'll be happy to make the changes.

PR needs review again

Any updates on this? This is still an issue for karma-mocha and it should be an easy fix.

mocha.setup = function(opts) {
  if (typeof opts === 'string') {
    opts = {ui: opts};
  }

  var optsKeys = Object.keys(opts);
  if (optsKeys.length > 1) {
    var _opts = {};
    // Sort object by keys
    optsKeys.sort().forEach(function(key) {
      _opts[key] = opts[key];
    });
    optsKeys = null;
    opts = _opts;
  }

  for (var opt in opts) {
    if (opts.hasOwnProperty(opt)) {
      this[opt](opts[opt]);
    }
  }
  return this;
};

easy fix, more difficult to test without refactors.  and yes, we need a real test.  #1800 added a test, but not an automated one.

Sounds like there are 2 bugs right now.

{delay: false} enables the delay
the bug from this issue

Perhaps something like below to fix both issues?
if ('delay' in opts && opts['delay'] === true) {
  this.delay();
}
var self = this;
Object.keys(opts)
  .sort()
  .filter(function(opt) {
    return opt !== 'delay';
  })
  .forEach(function(opt) {
    if (Object.prototype.hasOwnProperty.call(opts, opt)) {
      self[opt](opts[opt]);
    }
  });

@boneskull What level of testing would we need with this do u think? AFAIK html reporter tests are not ready, could introduce a unit-level somewhere.

This should now be fixed in the latest PR.


feature request: telling user when new version is available

guys, could anybody make a PR for this <3

thanks @nader-zouaoui and @AdrielBento <3


Have StackView::pop() return the item that was popped off

This is the implementation of my suggestion in #165. Let me know what you think.

Good idea - and thank you very much!
Could you just update the documentation for the pop_layer method?
Thanks again!

I just realized I hadn't checked the examples, and they're failing because of these changes. I'll need to get those fixed up, too.

The examples use Cursive::pop_layer, which hasn't been changed yet. I think they are compiled during cargo test, which is run on each PR, so you're good for now :)
Though updating Cursive::pop_layer will indeed require some modifications there.

Using Into<Box<View>> itself may prove a bit difficult:

We need impl <V: View> Into<Box<View> for V, which conflicts with impl <T, U: From<T>> Into<U> for T
We can't define impl <V: View> From<V> for Box<View> since it conflicts with impl<T> From<T> for T

Even if we use a custom IntoBoxedView trait, we would need specialization anyway, since Box<View> implements View`.

It may fail to compile with non-default features? I didn't test those.

Now I realize the pop'ed view will actually contain a ShadowView<Layer<V>> (or sometimes just a Layer<V>), which we may not want to re-wrap in a second layer and shadow view.
Ideally the pop_layer would unwrap the V from there. Or alternately a method would allow to add a "raw" view, without any wrapper.
It starts to sound a little more complex than the original use-case warrants. Retrieving pop'ed views is still a nice-to-have features, but if the goal is to switch the order of views in a StackView, there may be easier ways (like StackView::bring_to_front() or similar methods).

Another problem I just found: we're not getting the correct implementation of Into<Box<V>> when giving a Box<View>. That's because View is unsized, so doesn't match V: View + 'static.
This means Box<View> != Box<V>, so we don't get impl <T> From<T> for T. Instead, Box<View> is treated as a View and re-boxed from impl <T> From<T> for Box<T>.

I've been thinking about this a lot this weekend and I think my current solution, as it stands, would be pretty unsafe overall. Even if we solve the double-boxing issue, consider this scenario

I push some View to a StackView. For example purposes, let's say it's a TextView.
That TextView gets wrapped in a Layer, which gets wrapped in a ShadowView.
I later go to pop that TextView off, expecting a TextView. Instead, I get a ShadowView, and the downcast attempt fails and panics because of it. That's surprising, and definitely violates the principle of least astonishment.

Not to mention that pushing a freshly-popped object will wrap it another Layer and ShadowView. I don't think this is the right approach to this problem. I'll think about better, safer solutions for this kind of thing. I still think that pop_layer should return the top View, but there's gotta be a better way to do that than what I have right now.

Adding unwrap to the ViewWrapper is a great idea, and I'm surprised it's not there already.
But as is, the StackView only has a Vec<Box<View>> - it doesn't even know it has a ViewWrappers.
One solution could be to change StackView to instead store Vec<ShadowView<Layer<Box<View>>>>, and configure ShadowView to enable/disable the shadows through a variable. This way, the StackView can call unwrap twice as you mentioned.
Unfortunately, it's not trivial to get the static type of the view from there: the content of the children doesn't have the Any bound (we can't have a Box trait object with two bounds: Box<View + Any> is invalid), so the best we can do currently is use call_on_any to access the view itself. We don't know if the view even has an ID, so we'd need to use the (non-yet implemented) view path with an empty path (indicating the root view) to select it. This would give us a &mut access to the view, on which we could call std::mem::replace to extract the actual view. Phew!
The last few steps could be made a bit easier if we had View: Any. I'm thinking of adding that; this would mean any type implementing View would need to be 'static, but since we currently have a 'static bound on StackView::add_layer, this is virtually already the case. This does close the door to my dream of eventually removing this 'static bound, but maybe it's for the best.

I must admit - this is pushing the limits of my knowledge of the Rust type system. I don't mind learning, as long as you don't mind teaching.

Wow, thanks for the verbosity. I think I understand. Let me see if I get this right, correct me where I'm wrong:

Views aren't Any (well, now they are, but they weren't.) This means we can't (couldn't) call Box::downcast on any Box<View>.
Now that View is bound by Any, we can do the above. 🎉🎉🎉
Since StackView stores its children either as ShadowView<Layer<T>> or Layer<T> (depending on whether shadow is needed), this adds a layer of annoyance that we need to work around. Your suggestion is to add a field to determine whether the ShadowView is actually active or not, so we can always have the same wrapping of ShadowView<Layer<T>> - whether shadows are active or not.

Assuming my understanding is correct, as an aside I'd say this is the point where we'd want to introduce a new private type, or have the Child structure handle this discrepancy (rather than adding an active field to the ShadowView struct - it feels redundant).

Since we can't verify at compile-time that the popped-off item is going to be of some T, we use Box::downcast to either return Some(T) (with the and_then chain), statically typed, because Box<T> where T: Any is magic.

I'm going to look at the source some more, and probably close this PR and start over when I feel like I've got something I can send you - I didn't make many changes, no skin off my back. Thanks so much for the write-up, it helped me understand the situation a lot better.

Views aren't Any (well, now they are, but they weren't.) This means we can't (couldn't) call Box::downcast on any Box.
Now that View is bound by Any, we can do the above. 🎉🎉🎉

Correct!

Since StackView stores its children either as ShadowView<Layer> or Layer (depending on whether shadow is needed), this adds a layer of annoyance that we need to work around. Your suggestion is to add a field to determine whether the ShadowView is actually active or not, so we can always have the same wrapping of ShadowView<Layer> - whether shadows are active or not.

Assuming my understanding is correct, as an aside I'd say this is the point where we'd want to introduce a new private type, or have the Child structure handle this discrepancy (rather than adding an active field to the ShadowView struct - it feels redundant).

Indeed, a cleaner solution would be to have a private enum that could be either ShadowView<Layer<T>> or Layer<T>.

*Since we can't verify at compile-time that the popped-off item is going to be of some T, we use Box::downcast to either return Some(T) (with the and_then chain), statically typed, because Box where T: Any is magic.

Actually, the and_then chain here is mostly due to the fact the ViewWrapper::into_inner returns a Result (since it could fail to return the inner view, in some rare cases).
We don't actually need to downcast the view here; we could stop right before, return the unwrapped Box<View>, and let the user downcast if needed. But I feel it's much nicer for the users not to have to downcast it themselves.
Argh, but I hoped users could still call it with T = View, so that they could still get a Box<View> if they didn't know the actual type, but it turns out they can't - we can only downcast to a concrete type, not to a trait object, even if it's the very same trait we are starting from... :(
Oh well, I guess we'll have to return the Box<View> itself then, and either let users downcast it themselves, or add another function to downcast it for them (depending on how common a use-case it really is).

In commit 1b7170e3084ba8408566f231840165e93eb59184, StackView implement this enum solution to store either a ShadowView<Layer<Box<View>>> or a Layer<BoxView<T>>, and in commit bd9b6a695b739815872a10982d27149002e6e061 pop_layer return this Box<View>.
Next thing will be find a way to not re-box a Box<View> when adding a new layer.

Let's consider the use-case of pop'ing a view, and putting it back (possibly later), repeated multiple times:
cursive.add_layer(Dialog::new());

for i in 0..20 {
    let layer = cursive.pop_layer();
    cursive.add_layer(layer);
}

The target is to avoid resulting in a large chain of nested boxes.
One solution is to add a dedicated method to add a boxed view: this is easy to implement, but starts to crown the API.
The other solution is to find some polymorphism to allow add_layer to behave differently if given a Dialog (where it needs to be boxed) and a Box<View> (where it should not be boxed). One problem being that Box<View> implements View, so technically it would always be valid to re-box it. What we want it some specialization to skip this step when not necessary - and as the wording suggests, it looks like the specialization feature would make this easier (or even possible at all).
StackView::add_layer_at needs a Box<View>. It currently takes a <T: View> and box it in a Box<View> as its first instruction.
So what we need is a trait to result in a Box<View>, implemented for <T: View>, and with a specialization for Box<View> (or maybe for Box<T: ?Sized + View>?).
This sounds a lot like Into<Box<View>>. The problem is that this is not implemented for T: View, so we wouldn't be able to pass Dialog::new() directly.
Two solution from there: find a way to implement Into<Box<View>> for T: View, or create our own trait.

Trying directly impl <T: View> Into<Box<View>> for T fails with a conflicting implementation, as the standard library already provides impl<T, U: From<T>> Into<U> for T.
Trying impl <T: View> From<T> for Box<View> conflicts with impl<T> From<T> for T
Creating our own IntoBoxedView trait runs into the same conflicting implementation issue, since Box<View> implements View.

Specialization would at least enable the third point, and maybe the others, but it's not here yet.
Another solution is to do this check at runtime, by exploiting the fact that View: Any: we can check if view.is::<Box<View>>, but then I'm not sure how to actually convert view into the Box<View>, as it seems Any only allow downcasting references. :S

Note: we couldn't actually use Box::downcast, as it's only defined for Box<Any>, not Box<AnyView>; and it wasn't easy to get a Box<Any> from a Box<AnyView>.
So I just added AnyView::as_boxed_any to solve this part: we can now actually downcast a Box<AnyView> to a Box<TextView>.

I think I found a solution!
First, the whole View/AnyView is now simpler: instead of AnyView: View, we now have View: AnyView (any AnyView is still auto-implemented for any T: View). It feels like a cyclic type dependency, but it works, so champagne! This means we only have to worry about Box<View> now, not Box<AnyView>.
Second, I added a IntoBoxedView trait, and implemented it on Box<View> and any T: View. It's like Into<Box<View>>, but it actually works for T: View. StackView::add_layer and similar methods now use this for a trait bound instead of T: View, which means a Box<View> can be taken as argument and isn't re-boxed.
In order to have this implementation and to avoid specialization (which isn't stable yet), I had to remove impl View for Box<View>. This means Box<View> is no longer considered a View. This isn't a problem for add_layer since we use IntoBoxedView instead, but it does mean Box<View> cannot be used as-is in some view wrappers like Layer. For those (less common) cases, I added a ViewBox type, which is really just a wrapper around a Box<View> and implements View.

This is all in master, and should finally resolve the problem addressed by this PR.


Provide docker image for diagram generation

Provide docker image for diagram generation. Docker image should be built as a part of release pipeline and published to docker hub.

Closed by #38


search port 9443 for REST API

Hi,
I don't see any port 9443 for REST API in your dockerfile ?
Which current dockerfile use RESTAPI
Do you have webconsole in this docker ?
Regards
OK i found
https://hub.docker.com/r/ibmcom/mq
/c/Program\ Files/Docker\ Toolbox/docker pull ibmcom/mq
/c/Program\ Files/Docker\ Toolbox/docker run
--env LICENSE=accept
--env MQ_QMGR_NAME=QM1
--publish 1414:1414
--publish 9443:9443
--detach
ibmcom/mq
https://localhost:9443/ibmmq/console/login.html

Yes, the web server is enabled.  Having the PORT in the Dockerfile is optional, and doesn't affect the runtime, unless you tell Docker to expose all ports with the --publish-all flag.


Endpoint parameters are not being detected when controller functions are separated in multiple CommonJS files

I have the following structure (I'm using the https://github.com/davibaltar/example-swagger-autogen-with-router code and just did the changes I needed to reproduce the issue):

src/

index.js
routes.js
controllers/

users/

index.js

users2/

add.js
get.js
index.js

swagger.js

This is my swagger.js file:
const swaggerAutogen = require('swagger-autogen')()

const doc = {
   info: {
       version: "1.0.0",
       title: "My API",
       description: "Documentation automatically generated by the <b>swagger-autogen</b> module."
   },
   host: "localhost:3000",
   basePath: "/",
   schemes: ['http', 'https'],
   consumes: ['application/json'],
   produces: ['application/json'],
}

const outputFile = './swagger-output.json'
const endpointsFiles = ['./src/index.js']

swaggerAutogen(outputFile, endpointsFiles, doc).then(() => {
   require('./src/index')           // Your project's root file
});

In src/router.js I'm importing the controllers  for the post and get routes (yes, I have two directories for the users controller for a reason that I'll explain later on, bear with me).
const express = require('express')

// const usersController = require('./controllers/users')
const usersController = require('./controllers/users2')

const router = express.Router()

router.post('/users', usersController.add)
router.get('/users/:id', usersController.get)

module.exports = router

The controller has a index file and each function is in its own file:
src/controllers/users2/index.js
module.exports = {
  add: require('./add'),
  get: require('./get'),
};

src/controllers/users2/add.js
module.exports = async (req, res, next) => {
  const user = req.body.user;
  res.status(201).json({
      data: user,
      message: 'Authentication successed'
  })
};

src/controllers/users2/get.js
module.exports = async (req, res, next) => {
  const users = []
  const data = users.find(e => e.id === req.params.id)

  res.status(200).json({
    data: [],
    message: 'Successfully found'
  })
};

If I run the autogen, the body parameter for the post is not detected, as if it couldn't reach the src/controllers/users2add.js file for some reason.
If I add the functions add and get directly to the  controller index file (what I am doing in src/controllers/users/index.js as shown below, and that's why I have two different user directories), the body parameter is detected and added to the swagger file.
src/controllers/users/index.js
module.exports = {
  add: async (req, res, next) => {
    const user = req.body.user;

    res.status(201).json({
        data: user,
        message: 'Authentication successed'
    })
  },
  get: async (req, res, next) => {
    const users = []
    const data = users.find(e => e.id === req.params.id)

    res.status(200).json({
        data: [],
        message: 'Successfully found'
    })
	},
};

UPDATE: after further investigation, I believe this issue is related to importing modules using require.
If I rewrite files in folder src/controllers/users2 as ES Modules, the parameters are detected and added to the output file:
src/controllers/users2/index.js
import * as add from './add';
import * as get from './get';

export {
  add,
  get
};

src/controllers/users2/add.js
export default add = async (req, res, next) => {
  const user = req.body.user;
  if(user) {
    res.status(201).json({
        data: user,
        message: 'Authentication successed'
    })
  } else {
    res.status(500).json({
      message: 'Error'
    })
  }
};

src/controllers/users2/get.js
export default get = async (req, res, next) => {
  const users = []
  const data = users.find(e => e.id === req.params.id)

  res.status(200).json({
    data: [],
    message: 'Successfully found'
  })
};

Hi @hgcordeiro. Sorry for the delay and thank you for opening the issue with a sample code!
Unfortunately the lib is not prepared to for this kind of pattern (CommonJS):
module.exports = {
  add: require('./add'),
  get: require('./get'),
};

I had not thought about this case when I made the implementations for CommonJS. I'll try to implement it as soon as possible. Any news, I'll post it here. Thanks!

The version 2.23.3 has fixed that, but if the problem persists, let me know.

Hello @davibaltar.
Thanks for your response and for fixing the issue!


python implementation for calculating link indexes in FCI calculation

Dear PYSCF developers,
Is there any existing python implementation for calculating the link index table for each of the CI strings (alpha or beta) in an CI calculation ?
thanks,
Souloke

Here is an example https://github.com/pyscf/pyscf/blob/master/pyscf/fci/test/test_cistring.py#L53

@sunqm  thank you for the example.

Hi @SoulokeSen , thanks for asking. Has your question been answered?

Feel free to reopen


Feature/plv

The phase_analysis module of elephant has yet, just one function, namely the spike_triggered_average() also known as STA. We want to increase this number of functions by implementing the phase_locking_value() or PLV and several more.
The current version of PLV takes array-objects as input.
Open Point of Discussion:
Which representations of the input-phases should be available?
neo.AnalogSignal, List of List, ..., etc.

Hello @ojoenlanuca! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file elephant/test/test_phase_analysis.py:

Line 312:75: W291 trailing whitespace

Coverage increased (+0.03%) to 89.943% when pulling 720a16a65fb14339ed6164d99112bbd7c05c5dd4 on INM-6:feature/plv into cc19b17f1e2697eaa6d503c5fe326b4504cccf9a on NeuralEnsemble:master.

def phase_locking_value(phases_x, phases_y) inteface should be used.


Version 6.2.X does not work good with Ethers.JS

Expected Behavior
Ethers.JS method "sendTransaction" (used both directly and as a part of the contract method execution) should work correctly with Ganache and make properly signed transactions.

Current Behavior
Ethers.JS fails to sign transaction because it seems like Ganache is changing some of its fields under the hood, causing the txHash mistmatch, what leads to the nasty error - basically, making it completely unusable:
Error: Transaction hash mismatch from Provider.sendTransaction. (expectedHash="0xf6878651c3eefc608e4852a4fdcf28dd9319f950b78dfb0dcf6d726ab2dd153b", returnedHash="0xf9b4f394391c0f14b22337a0d496bc36d2c54f7fce2f061c4e98e3710afbe355")
You can fix it by reverting Ganache back to the v6.1.8, but damn, that's not a real solution.

Steps to Reproduce (for bugs)

Install Ganache of the version 6.2.X.
Install ethers.js of the version 4.0.X (no idea how it is going to work on the older versions).
Try sending transactions or calling contract methods.
Check error details.

Your Environment

Version used: v6.2.3
Version of Truffle/Remix/Other tools used: Ethers 4.0.13.
NodeJS Version: [ ] 6.x, [ ] 7.x (unsupported), [ ] 8.x, [x] 9.x
Operating System and version (include distro if Linux): OS X.
Link to your project or repro gist: Private.
Commit hash to use with above link for reproduction: Private.
I intend to submit a pull request to fix this issue: [ ]

Related issues:
https://github.com/ethers-io/ethers.js/issues/275

Thanks @sweetpalma 	Fixed in<EMAIL_ADDRESS>Also added a note about connecting ethers.js to ganache-cli in our readme.md.


jetson-tx2-4gb: Cannot find partition mts-bootpack

I'm trying to add support for Jetson-TX2-4GB variation as described in L4T-tegra186-32.2.0-r0/Linux_for_Tegra/jetson-tx2-4GB.conf:
# p2771-0000-0888.conf: configuration for T186-A02 te770m P3489 SKU888

BPFDTB_FILE=tegra186-a02-bpmp-lightning-p3489-a00-00-te770m.dtb;
source "${LDK_DIR}/p2771-0000.conf.common";
EMMC_BCT=P3489_Sku888_4GB_Hynix_4GB_lpddr4_204Mhz_P138_A02_l4t.cfg
DTB_FILE=tegra186-quill-p3489-0888-a00-00-base.dtb;
TBCDTB_FILE=tegra186-quill-p3489-0888-a00-00-base.dtb;

PROD_CONFIG="tegra186-mb1-bct-prod-storm-p3489-1000-a00.cfg";
PINMUX_CONFIG="tegra186-mb1-bct-pinmux-quill-p3489-1000-a00.cfg";
PMIC_CONFIG="tegra186-mb1-bct-pmic-lightning-p3489-1000-a00.cfg";
PMC_CONFIG="tegra186-mb1-bct-pad-quill-p3489-1000-a00.cfg";
BOOTROM_CONFIG="tegra186-mb1-bct-bootrom-quill-p3489-1000-a00.cfg";
ROOTFSSIZE=14GiB;

I've created a custom machine based on jetson-tx2, and a flashvars overlay with the values from above mapped in and added to FILESEXTRAPATHS_prepend. From the doflash log it appears all of my values are being used as expected.
conf/machine/jetson-tx2-4gb.conf:
#@TYPE: Machine
#@NAME: jetson-tx2-4gb
#@DESCRIPTION: Machine configuration for Jetson-TX2-4GB

MACHINEOVERRIDES = "jetson-tx2:${MACHINE}"
KERNEL_DEVICETREE ?= "_ddot_/_ddot_/_ddot_/_ddot_/nvidia/platform/t18x/quill/kernel-dts/tegra186-quill-p3489-0888-a00-00-base.dtb"
EMMC_BCT ?= "P3489_Sku888_4GB_Hynix_4GB_lpddr4_204Mhz_P138_A02_l4t.cfg"
ROOTFSSIZE = "14GiB"

include conf/machine/jetson-tx2.conf

recipes-bsp/tegra-binaries/files/jetson-tx2-4gb/flashvars:
FLASHVARS="BPFDTB_FILE PINMUX_CONFIG PMIC_CONFIG PMC_CONFIG PROD_CONFIG BOOTROM_CONFIG MISC_CONFIG SCR_CONFIG SCR_COLD_BOOT_CONFIG DEV_PARAMS"
BPFDTB_FILE=tegra186-a02-bpmp-lightning-p3489-a00-00-te770m.dtb
PINMUX_CONFIG=tegra186-mb1-bct-pinmux-quill-p3489-1000-a00.cfg
PMIC_CONFIG=tegra186-mb1-bct-pmic-lightning-p3489-1000-a00.cfg
PMC_CONFIG=tegra186-mb1-bct-pad-quill-p3489-1000-a00.cfg
PROD_CONFIG=tegra186-mb1-bct-prod-storm-p3489-1000-a00.cfg
BOOTROM_CONFIG=tegra186-mb1-bct-bootrom-quill-p3489-1000-a00.cfg
MISC_CONFIG=tegra186-mb1-bct-misc-si-l4t.cfg
SCR_CONFIG=minimal_scr.cfg
SCR_COLD_BOOT_CONFIG=mobile_scr.cfg
DEV_PARAMS=emmc.cfg

However flashing never succeeds. It always fails when attempting to write mts-bootpack.
[   5.8439 ] Writing partition APP with core-image-minimal.img
[   5.8470 ] [................................................] 100%
[  24.7333 ] Writing partition mts-bootpack with mce_mts_d15_prod_cr_sigheader.bin.encrypt
[  24.7548 ] 000000000d0d000d: o open partition %s.
[  24.7703 ]
[  24.7704 ]
Error: Return value 13
Command tegradevflash_v2 --pt flash.xml.bin --create

[0012.017] I> Writing APP partition.
[0030.924] I> Writing mts-bootpack partition.
[0030.928] E> Cannot find partition mts-bootpack
[0030.932] E> NV3P_SERVER: Failed to open partition mts-bootpack.

I thought this was a fairly simple overlay but it's giving me more trouble that I expected. Have you seen anything like this before? Is it related to the oem_sign flag not validating?
Sorry for the verbose copy paste - I don't have the files on a public repo yet for linking. If I can get this working I would be happy to submit a pull request as it's a board variation supported by Nvidia.

You shouldn't need the MACHINEOVERRIDES setting in the machine configuration file, but otherwise that all looks right.  If you can shoot me a copy of the full log of a flash.sh run  from the stock L4T, a full log of your failed flashing from your meta-tegra build, and a listing of the contents of the tegraflash.zip package, I'll take a look and see if I can help track down the problem.

Solved. After staring at it for over a week and comparing every file used in the doflash log to the stock flash log.
I finally noticed that the ROOTFSSIZE = "14GiB" value I had copied from L4T-tegra186-32.2.0-r0/Linux_for_Tegra/jetson-tx2-4GB.conf was not being used.
Once I converted it to ROOTFSPART_SIZE ?= "15032385536" the doflash went perfectly. Here's my current jetson-tx2-4gb.conf.
#@TYPE: Machine
#@NAME: Nvidia Jetson TX2 4GB
#@DESCRIPTION: Machine configuration for Nvidia Jetson TX2 4GB variant

KERNEL_DEVICETREE ?= "_ddot_/_ddot_/_ddot_/_ddot_/nvidia/platform/t18x/quill/kernel-dts/tegra186-quill-p3489-0888-a00-00-base.dtb"
ROOTFSPART_SIZE ?= "15032385536"
EMMC_BCT ?= "P3489_Sku888_4GB_Hynix_4GB_lpddr4_204Mhz_P138_A02_l4t.cfg"
TEGRA_BOARDID ?= "3489"
TEGRA_FAB ?= "300"

include conf/machine/jetson-tx2.conf

Is this BSP configuration something you would want in the meta-tegra repo? I'd be happy to submit a pull request for the conf and flashvars if you'd like. Otherwise I'll keep it in my custom layer and carry on with my project.
Thanks for all your hard work!

Yes, please do.  Thanks!


Support Ubuntu 16.04 (xenial)

Used to exist in @qzio's fork (https://github.com/qzio/cookbook-apt-docker), but he has since removed that branch, which causes problems for us since we use it from some of our Berksfiles.
This PR takes it into our own fork of the cookbook, into the master branch.

This patch should not be needed anymore since upstream fixed it

@qzio When we say "upstream" here, I guess you refer to https://github.com/chef-cookbooks/docker as you mention in https://github.com/st-isidore-de-seville/cookbook-apt-docker/pull/9:

For ref: https://github.com/chef-cookbooks/docker supports 16.04 now-days.
I guess this will never be merged, closing.

Is the docker cookbook a drop-in replacement to the cookbook-apt-docker? Are they 100% compatible?
(We still have Berksfiles that refer to this branch, so we can't really kill it until they are all updated one way or the other.)

@perlun I haven't tested but cookbook-apt-docker doesn't seem to be maintained anyway.
chef-cookbooks/docker are able to install docker from docker's apt repositories.
(Docker have changed their apt repo, to old might still work, but I wouldn't rely on it too much...)

(Docker have changed their apt repo, to old might still work, but I wouldn't rely on it too much...)

Yeah, I've seen that the package names have changed a bit also. The old repo only has versions up through 17.05, 17.06 is not available from there. So in eCraft Platform we're using the other, newer cookbook.


Better Trial Chamber Implementation Ideas

I am interested in improving the way Trial Chambers are currently implemented, share your ideas here! Thanks.

Maybe have the trial spawners spawn as normal spawners, and have they player manually place their indicated patterns in and have anvil drop on the mob to "push them in" to convert to their respective trial spawners?

As I understand the biggest issue with the spawners is their frequency and lack of difficulty in a skyblock word. I think a nice way to tackle both of these problems would be conditionally generating the entire trial chambers structure (shown below) if a user has something like bad omen from the Ominous Bottle effect and is within the trial chambers structure. Likewise after clearing, the chamber would despawn after a couple of minutes of set time (so he user can get out and doesn't fall into the void and no eyesore permanent blocks remain). A condition that the chambers can't start spawning if more than one existing block is inside the bounds would be required, to prevent accidental bad omen effects spawning chambers in the players existing builds, destroying them. Although with this approach the same structure could be reused, given the incompatibility of skyblock with exploration and the tools like MiniHUD or chunkbase required to even find the now hidden structures I think it's a reasonable vanilla-like alternative.

I'm also in favour of the above entity based spawnerless approach, it would be straight forward to automate and I'm assuming easier to implement as well.

What if we bring a mob to the trial chamber, and this will start a trial chamber event (like the spawners do), and then the last one killed, has a chance to drop the key, If having the ominous effect, then it would be a ominous trial event, with a change to drop the ominous key. Could this make it more interesting?
When the event is complete, a vault might spawn, so it can be opened with a key.

For now I just made it so Trial Chambers are just a breeze spawner, and a normal vault and ominous. But I am still open to improving it.

I like the direction this is going, but I still have three problems with the current implementation. First, it is extremely unbalanced. Players can get endgame items like golden apples and diamonds from vaults almost at day 1. My suggestion to fix this would be to have the player use something like blaze powder on the spawner to set the entity to Breeze and ignite the spawner. It would fit with the theme of the spawner and be balanced.
Second, the spawners do not reset after 30 minutes like they do in vanilla. This is happening because the EntityType is set using SpawnerBlockEntity instead of Spawner, and it can be fixed by modifying only a few lines of code in SkyBlockStructures. I checked the nbt data of skyblock generated spawner block entities after I applied the fix, and it was identical to a vanilla generated one. This problem would be automatically fixed by implementing spawner ignition in a way similar to SpawnEggItem.
Finally, I think that spawner and vault postitions should be slightly randomized instead of being in a line. It fits better with the theme of the mod and allows spawners to be farmed more easily without breaking vaults.

I like the idea of having to set the spawners to activate, and good to know about the issue with the spawners not resetting.
technically with the change of their only being 1 spawner, and their only being 1 of each vault type it would take a ton of bridging and luck to get specific items.
In general, the trial chambers don't really fit Minecraft anyways and at least from I've heard in, they just aren't a feature players generally like, so it's hard to fit an already poor feature into skyblock in an interesting way.
I can randomize the position of the spawner and the vaults, maybe have 1 spawner, and 2 vaults, the spawner isn't activated. if you bring a blaze to the overworld, it turns into a breeze, once it's a breeze and you get breeze rod, you can use that to turn the spawner into a breeze spawner. Maybe also have ways to turn the spawner into other mobs.
I think that would be reasonable.

I seem to have a bug where the ominous vaults seem to take regular trial keys instead of expected ominous trial keys.
As for the implementation I disagree with:

First, it is extremely unbalanced. Players can get endgame items like golden apples and diamonds from vaults almost at day 1.

Trial chambers provide an alternative to villager conversion and emerald farming instead of foxes (for getting apple saplings from wandering trader) in the early game, breaking the forced and very linear progression currently in the game. Likewise the loot is randomized and single use meaning that you'd likely need to visit several chambers in order to get the 8.3% golden apple drop and even the key/ emeralds aren't guaranteed. As for diamonds or other random loot, that can likewise be acquired renewably in normal survival's "day 1" with villagers so it doesn't feel game breaking imo. I will admit that the difficulty is laughable with the spawner dropping breezes into the void most of the time, which I think if fixed could make this quite a nice alternative game play experience.

Trial chambers provide an alternative to villager conversion and emerald farming instead of foxes (for getting apple saplings from wandering trader) in the early game, breaking the forced and very linear progression currently in the game. Likewise the loot is randomized and single use meaning that you'd likely need to visit several chambers in order to get the 8.3% golden apple drop and even the key/ emeralds aren't guaranteed.

That's a good point,  since the golden apple isn't guaranteed and is pretty low drop chance, you very well may spend more time/resources bridging around than just following the regular progression. It also is kind of interesting to have multiple ways of doing things.

Second, the spawners do not reset after 30 minutes like they do in vanilla. This is happening because the EntityType is set using SpawnerBlockEntity instead of Spawner, and it can be fixed by modifying only a few lines of code in SkyBlockStructures. I checked the nbt data of skyblock generated spawner block entities after I applied the fix, and it was identical to a vanilla generated one. This problem would be automatically fixed by implementing spawner ignition in a way similar to SpawnEggItem.

I'm looking into what you are saying about the spawners not resetting, I just tested using a tick warp and the spawner reset normally after 30 minutes for me. When you say SpawnerBlockEntity and Spawner, those aren't used for Trial Chambers.

Upcoming version has Trial Spawner starting 8 blocks away from the 2 vaults.
The Trial Spawner now starts deactivated, you can bring a blaze to the overworld to convert it to a breeze (won't happen if its nametagged)
A breeze rod can now be used to activate a trial spawner to become a breeze trial spawner.
Feel free to open a new issue if this isn't satisfactory.


Yellow scrollbar on macOS

Is there an existing issue outlining your improvement?

[X] I have searched the existing issues and my improvement has not been raised yet.

What would you like to see added and/or changed?
When scrolling in certain windows, I see a thick yellow scrollbar, but don't see any theming options to customise this in any way (size or colour). Am I missing something here?
Thanks!

Hey :wave:,
So the variables for theming the Scrollbar seem to be implemented in the ui.theme.json shown below, where secondaryAccentColor is yellow:
https://github.com/catppuccin/jetbrains/blob/c05b72dcbf2976a0c9adc399952c97f70382dd3a/generateFlavours/ui.theme.json#L323-L330
This isn't customisable through the IDE and would require compiling and building the plugin yourself to change this value. As a side note, I'm not sure why we override it to be yellow on macOS only, think it's best to make it the same as what's specified in the editor.xml:
https://github.com/catppuccin/jetbrains/blob/c05b72dcbf2976a0c9adc399952c97f70382dd3a/generateFlavours/editor.xml#L73-L76
It seems like there are conflicting configurations in these two files for macOS, which I'm honestly not sure how that's ended up like that. I think it would be best to make the colour the same across all 3 operating systems.

Any chance this will be fixed soon?

I'll have a look this weekend, should be an easy fix but honestly forgot about it!


Ejecting... scripts already exists in your app folder. We cannot continue as you would lose all the changes in that file or directory. Please move or delete it (maybe make a copy for backup) and run this command again.

Description

JSS react has scripts folder already, now npm run eject needs to create scripts folder too, so this is conflicting. Hence the error:
Ejecting... scripts already exists in your app folder. We cannot continue as you would lose all the changes in that file or directory. Please move or delete it (maybe make a copy for backup) and run this command again.
Steps followed to resolve:

Rename existing scripts folder to some other name.
Execute npm run eject again.
Merge the contents of newly created folder with the renamed folder.
Execute jss start but it is throwing errors.

Errors
index.js:1749 Fetch API cannot load file:///D:/Vipul/jss-react-ejected-app/node_modules/eslint-loader/dist/Linter.js. URL scheme must be "http" or "https" for CORS request.
index.js:1749 Fetch API cannot load file:///D:/Vipul/jss-react-ejected-app/node_modules/eslint-loader/dist/cacheLoader.js. URL scheme must be "http" or "https" for CORS request.
index.js:1749 Fetch API cannot load file:///D:/Vipul/jss-react-ejected-app/node_modules/loader-fs-cache/index.js. URL scheme must be "http" or "https" for CORS request.
Fetch API cannot load file:///D:/Vipul/jss-react-ejected-app/node_modules/graceful-fs/graceful-fs.js. URL scheme must be "http" or "https" for CORS request.
main.chunk.js:10 Uncaught Error: Module build failed (from ./node_modules/eslint-loader/dist/cjs.js): TypeError: Cannot read property 'forEach' of undefined     at Linter.parseResults (D:\Vipul\jss-react-ejected-app\node_modules\eslint-loader\dist\Linter.js:121:13)     at Linter.printOutput (D:\Vipul\jss-react-ejected-app\node_modules\eslint-loader\dist\Linter.js:85:26)     at cache (D:\Vipul\jss-react-ejected-app\node_modules\eslint-loader\dist\cacheLoader.js:46:14)     at D:\Vipul\jss-react-ejected-app\node_modules\loader-fs-cache\index.js:139:9     at D:\Vipul\jss-react-ejected-app\node_modules\graceful-fs\graceful-fs.js:57:14     at FSReqWrap.oncomplete (fs.js:135:15)     at Object../src/index.js (http://localhost:3000/static/js/main.chunk.js:10:7)     at __webpack_require__ (http://localhost:3000/static/js/bundle.js:786:30)     at fn (http://localhost:3000/static/js/bundle.js:151:20)     at Object.0 (http://localhost:3000/static/js/main.chunk.js:22:18)     at __webpack_require__ (http://localhost:3000/static/js/bundle.js:786:30)     at checkDeferredModules (http://localhost:3000/static/js/bundle.js:46:23)     at Array.webpackJsonpCallback [as push] (http://localhost:3000/static/js/bundle.js:33:19)     at http://localhost:3000/static/js/main.chunk.js:1:99
./src/index.js TypeError: Cannot read property 'forEach' of undefined
It looks like eject is not supported here by JSS, if eject is not supported then how to override webpack configuration, there are some modules, like rewire but it is not supported anymore, so what way to go?

@manu1222 Fixed in #323. You can run npm run eject:script that will automatically eject react application and save scripts folder. If you will have any problems, feel free to reopen issue

@sc-illiakovalenko I'm getting below message:
Ejecting...
scripts already exists in your app folder. We cannot continue as you would lose all the changes in that file or directory. Please move or delete it (maybe make a copy for backup) and run this command again.
npm ERR! code 1
npm ERR! path E:\manu\eject-jss
npm ERR! command failed
npm ERR! command C:\windows\system32\cmd.exe /d /s /c react-scripts eject
npm ERR!      C:\AppData\Local\npm-cache_logs\2021-04-02T14_57_31_604Z-debug.log

@sc-illiakovalenko Just saw previous message, npm run eject:script and it worked, but I thought jss eject would also work.


Use nix 2.24 for eval ci task

We are currently seeing occasional "Stack overflows". Nix 2.24 has a better mechanism for detecting stack overflows because it's not using the segfault handler to primarily detect it:
Depends on https://github.com/NixOS/nixpkgs/pull/357753

Will do a test run first.

Here is an example run: https://github.com/Mic92/nixpkgs/pull/38
My my branch was at: https://github.com/Mic92/nixpkgs/commit/e81e723e97457b75c58e112a1966aa1a359aa881

Manual backport: https://github.com/NixOS/nixpkgs/pull/361168


update jemalloc

Hi, this pr tries to update jemalloc to the same version (11bfb0dcf85f7aa92abd30524bb1e42e18d108c6) as rust-lang/rust depends on.

Thanks!


Buggy behavior with maxNativeZoom

Take a look at and zoom in:
http://jsbin.com/peratajixi/1/edit?js,output
The map disappears until it loads the wrong tile(s). This issue does not occur if I do not use fallback or when not specifying maxNativeZoom.

Hi,
Thank you for the report and for the JSBin!
Please can you check if that version fixes your issue?
https://github.com/ghybs/Leaflet.TileLayer.Fallback/blob/fb360932f9a6f278b7f0611f81e0aef3197de47a/src/fallback.js
(you can either build the dist file on your machine, or just copy-paste the content of that file on that commit into the v1.0.0 dist file)

Seems to work like a charm! Correct tiles and everything. Thanks a lot for the quick fix!

Thank you for your confirmation!


Cannot find module 'unist-util-is/lib/index.js' or its corresponding type declarations

Initial checklist

[X] I read the support docs
[X] I read the contributing guide
[X] I agree to follow the code of conduct
[X] I searched issues and couldn’t find anything (or linked relevant results below)

Affected packages and versions
<EMAIL_ADDRESS>Link to runnable example
No response
Steps to reproduce
After upgrading from 4.1.1 to 4.1.2 I receive the errors below:

<EMAIL_ADDRESS>build:esm
tsc

node_modules/unist-util-visit/lib/index.d.ts:32:24 - error TS2307: Cannot find module 'unist-util-is/lib/index.js' or its corresponding type declarations.
32   Check extends import('unist-util-is/lib/index.js').Test
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
node_modules/unist-util-visit/lib/index.d.ts:115:24 - error TS2307: Cannot find module 'unist-util-is/lib/index.js' or its corresponding type declarations.
115   Check extends import('unist-util-is/lib/index.js').Test
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
node_modules/unist-util-visit/lib/index.d.ts:132:24 - error TS2307: Cannot find module 'unist-util-is/lib/index.js' or its corresponding type declarations.
132   Check extends import('unist-util-is/lib/index.js').Test = string
Expected behavior
No type declaration errors.
Actual behavior
Receive type declaration errors.
Affected runtime and version
<EMAIL_ADDRESS>Affected package manager and version
<EMAIL_ADDRESS>Affected OS and version
macos
Build and bundle tools
No response

If you throw away your node_modules and package locks, and install again, it should be fixed.

You can see that they are published to npm:

https://www.npmjs.com/package/unist-util-visit?activeTab=explore
https://www.npmjs.com/package/unist-util-is?activeTab=explore

Got it. After removing node_modules, and re-installing the packages, fixed the issue.
Thanks @wooorm

Cool :)


Add new i18n locales

Issue Description
Adding terra-i18n support for new locales:

ar
es-US
es-ES
pt-BR
fr-FR

We also need to add the translations in core/clinical components: https://github.com/cerner/terra-core/issues/806
Issue Type

[ ] New Feature
[x] Enhancement
[ ] Bug
[ ] Other

https://github.com/cerner/terra-core/pull/800

This has been released in<EMAIL_ADDRESS>


Help: Create Nested List

Hi,
Is there any example to create nested list where you can either use numbering or bullet points?

Sean Benoit wrote a script for FPDF that makes either ordered or ordered lists. It doesn't look like it would be too much trouble to adapt it to gofpdf. It appears to support nested lists by means of the Indent record value, although it doesn't look like the automatic numbering accounts for changes in indentation.
See http://www.fpdf.org/en/script/script56.php

pdfdeck (which uses gofpdf) supports lists
see:
https://github.com/ajstarks/deck
https://github.com/ajstarks/deck/tree/master/cmd/pdfdeck
https://github.com/ajstarks/deck/blob/master/examples/deck.pdf

Please reopen issue if the links provided by @ajstarks don't meet your needs.

Hi, I just stumbled upon this thread while looking for a way to do something similar to this. Is there a way add bullet points in a cell on an individual basis? Like inserting a single unicode character? Sorry to use this as a support thread but I'm really struggling to find a way to do this

Unfortunately, gofpdf is really limited when it comes to unicode. It only handles fonts that are stored in code pages, that is, sets of up to 256 characters. What may help you is the Zapf Dingbats codepage that is included in all PDF readers. Here is an example:
package main

import (
	"fmt"
	"github.com/jung-kurt/gofpdf"
	"os"
)

func main() {
	const fontHt = 18
	pdf := gofpdf.New("P", "mm", "A4", "")
	lineHt := pdf.PointToUnitConvert(fontHt)
	pdf.AddPage()
	for j := 1; j < 12; j++ {
		pdf.SetFont("zapfdingbats", "", fontHt/4)
		pdf.CellFormat(5, lineHt, "\x6c", "", 0, "R", false, 0, "")
		pdf.SetFont("times", "", 18)
		pdf.CellFormat(5, lineHt, fmt.Sprintf(" Item %d", j), "", 1, "L", false, 0, "")
	}
	err := pdf.OutputFileAndClose("bullet.pdf")
	if err != nil {
		fmt.Fprintf(os.Stderr, "error writing to bullet.pdf: %s\n", err)
	}
}

nice! thank you very much for the example!


Detect whether children are defined

I wanted to build a component where the children are optional and that depending on  the presence of children the output is different.
I tried to detect it via children|length but since it also contains whitespace (see example below) that did not work.
    {% #menu title="Test" %}
    {% /menu %}

In this example children|length returns a number > 0 since there is whitespace.
    {% #menu title="Test" %}{% /menu %}

Here children|length returns 0.
Is this possible at all to detect this?

Have you tried children.strip|length?


Add "turbone" differential reflectivity colormap

This adds a trimmed version of matplotlib bone and matplotlib turbo with a break in hue but no break in lightness. I personally like using this with a vmin of -2 and a vmax of 8 for radar differential reflectivity products.
This is designed to be better for CVD friendliness than RefDiff as the only lightness reversal takes place at 1dB (I see this as the threshold between ice and light rain). I can't decide if it would be better to move this to 0 dB (spherical targets).
Standard disclaimer that I am not color vision deficient and can only go based off what the graphs tell me. Criticisms from those more knowledgable on the subject are welcomed and encourged!

it probably makes more sense to plot turbone_r with viscm rather than standard turbone since usually 0dB (hail) is surrounded by heavy rain. here's that:

@wx4stg Thanks for the PR! The changes look good to me! With regards to the question on moving the light reversal, I'm unsure. And can see if someone else has more insight on that.


Vim9: cannot capture output of Ex command with "execute()" inside "<C->e" mapping

Describe the bug
In Vim9 script, we cannot capture the output of an Ex command with execute() inside a <C-\>e  mapping.
To Reproduce
Run this shell command:
vim -Nu NONE -S <(cat <<'EOF'
    vim9
    cno <F3> <c-\>e Func()<cr>
    setline(1, ['abc', 'ddd', 'aef', 'ggg', 'ahi'])
    var output: string
    def g:Func(): string
        output = execute('g/^a/#', '')
        return ''
    enddef
    feedkeys(":\<F3>", 'xt')
    echo output
EOF
)

An empty string is echo'ed.
Expected behavior
This is echo'ed:
1 abc
3 aef
5 ahi

Environment

Vim version: 8.2 Included patches: 1-2371
OS: Ubuntu 16.04.7 LTS
Terminal: xterm(363)

Additional context
The exact same code works as expected if Func() is rewritten as a legacy function:
vim9
cno <F3> <c-\>e Func()<cr>
setline(1, ['abc', 'ddd', 'aef', 'ggg', 'ahi'])
var output: string
fu g:Func()
    let s:output = execute('g/^a/#', '')
    return ''
endfu
feedkeys(":\<F3>", 'xt')
echo output

1 abc
3 aef
5 ahi

In Vim9 script g/pat/# does nothing, because # starts a comment.  You can use g/pat/number.

In Vim9 script g/pat/# does nothing, because # starts a comment.  You can use g/pat/number.


Limitation of max image size is 512?

I want to get a sharper image to I set the param image_size to 1024, however, the latter half image is totally gray. Then I change image_size to 640 and 768, still some part of the output image is gray. So I guess maybe there is a max limitation?
And if it is true, is there an easy way to modify the code?
Thank you

There is no limitation on image size other than your available memory and patience; however you may need to use different parameters for larger images. If you are seeing flat image regions then you might trt removing the TV regularization (-tv_weight 0)


meta-labgrid: update to recent master

This gives us an updated labgrid which, among other things fixes an issue that arises when using multiple USB-SD-Muxes or SD-Wires.
See labgrid-project/labgrid#1198 for more informations.

This gives us an updated labgrid which, among other things fixes an issue that arises when using multiple USB-SD-Muxes or SD-Wires.

Clarification: this can also happen with a single SD-Mux/SD-Wire. The disk and control paths (obviously) cannot point to a different Mux, though.


Revert "Merge main commits with secondary"

Reverts ajsharda17/OpenSourced-Discord-Bots#2

Accidental, confusion, sorry


raftstore: improve the bucket split strategy

What is changed and how it works?

Issue Number: Close #13671,
base #15637
What's Changed:

there are three reason may cause the bucket not split:
1. split check tick will refresh bucket info even info the bucket version not change
2. the suspect buckets only conside the increment flow
3. all the bucket increment flows are reset if one bucket is updated.

To solve this, bucket stats only record the increment flow and reset it after meta size updated.

Related changes
Check List
Tests

Unit test
Integration test

Side effects
Release note
None

/merge

/run-test retry=5


How to get top-N results?

Hi @tmbdev , thanks for your reply in https://github.com/tmbdev/clstm/issues/24, it is perfect!
I have another question and have commented in https://github.com/tmbdev/clstm/issues/24.
Here I copy the question for easier retrieval for other people.
Can the predict interface provide top-N results?
That will be helpful for better results and finding weakness of datasets.
Thanks.

No, the predict interface does not give you top-N. To get top-N, you'd have to implement a beam decoder or some other decoder.
I'm planning on hooking up the OpenFST library to the CLSTM library. That gives you one simple option for top-N computations (plus a lot more).

Beam search implementations:
https://github.com/amaas/stanford-ctc/search?l=cpp&q=beam&utf8=✓
https://github.com/search?l=cpp&q="beam+search"+"ctc"&ref=searchresults&type=Code&utf8=✓


Please display time zone on status home page and incident details page

It would be very helpful if I didn't have to click through to GitHub issues to see what timezone a status update was made in. For example, on Incident 59, I can see that a maintenance was in play at 9:40:56pm, but what timezone was that? I was attempting to troubleshoot some significant Hosted Weblate interface lag time and I wasn't sure if a maintenance was actually still happening. Adding a timezone to these two templates would clarify things very simply:

Thank you, @nijel - I just saw this notification and have started a discussion over at upptime. Cheers!


Decide which email address to use for code of conduct

@john-romein Could we use your email address as the point of contact in the code of conduct? See #44 for a pull request containing a standard text.

Yes

Merged.


[BUG] Missing Participation Data in Primetime

Is there an existing issue for this?

[X] I have searched the existing issues

Have you installed the latest development version of the package(s) in question?

[X] I have installed the latest development version of the package.

If this is a data issue, have you tried clearing your nflverse cache?
I have cleared my nflverse cache and the issue persists.
What version of the package do you have?
4.6.1
Describe the bug
Hello - very quick question: at the end of last season the participation data for games outside of TNF / SNF / MNF / playoff games was unavailable. I checked the load_participation information for 2024 -
part_nfl <- load_participation(c(2024), include_pbp = T)
and there was nothing. Is there a status update on what participation data, if any, will be available this season.
Reprex
part_nfl <- load_participation(c(2024), include_pbp = T)

Expected Behavior
I (hoped) that data would be populated for this season.
nflverse_sitrep
── System Info ─────────────────────────────────────────────────────────────────────────────────────────────
• R version 4.3.3 (2024-02-29 ucrt) • Running under: Windows 11 x64 (build 22631)
── Package Status ──────────────────────────────────────────────────────────────────────────────────────────
   package installed  cran        dev   behind
1 nflfastR     4.6.1 4.6.1 <IP_ADDRESS>13      dev
2 nflreadr     1.4.0 1.4.1   <IP_ADDRESS> cran;dev
── Package Options ─────────────────────────────────────────────────────────────────────────────────────────
• No options set for above packages
── Package Dependencies ────────────────────────────────────────────────────────────────────────────────────
• cachem      (1.0.8)   • grid       (4.3.3)    • purrr      (1.0.2)
• cli         (3.6.2)   • hms        (1.1.3)    • R6         (2.5.1)
• codetools   (0.2-19)  • janitor    (2.2.0)    • rappdirs   (0.3.3)
• compiler    (4.3.3)   • jsonlite   (1.8.8)    • rlang      (1.1.3)
• cpp11       (0.4.7)   • lattice    (0.22-5)   • snakecase  (0.11.1)
• curl        (5.2.1)   • lifecycle  (1.0.4)    • splines    (4.3.3)
• data.table  (1.15.4)  • listenv    (0.9.1)    • stats      (4.3.3)
• digest      (0.6.35)  • lubridate  (1.9.3)    • stringi    (1.8.3)
• dplyr       (1.1.4)   • magrittr   (2.0.3)    • stringr    (1.5.1)
• fansi       (1.0.6)   • Matrix     (1.6-5)    • tibble     (3.2.1)
• fastmap     (1.1.1)   • memoise    (2.0.1)    • tidyr      (1.3.1)
• fastrmodels (1.0.2)   • methods    (4.3.3)    • tidyselect (1.2.1)
• furrr       (0.3.1)   • mgcv       (1.9-1)    • timechange (0.3.0)
• future      (1.33.2)  • nlme       (3.1-164)  • tools      (4.3.3)
• generics    (0.1.3)   • parallel   (4.3.3)    • utf8       (1.2.4)
• globals     (0.16.3)  • parallelly (1.37.1)   • utils      (4.3.3)
• glue        (1.7.0)   • pillar     (1.9.0)    • vctrs      (0.6.5)
• graphics    (4.3.3)   • pkgconfig  (2.0.3)    • withr      (3.0.0)
• grDevices   (4.3.3)   • progressr  (0.14.0)   • xgboost    (<IP_ADDRESS>)
── Not Installed ───────────────────────────────────────────────────────────────────────────────────────────
• nflseedR  • nflplotR
• nfl4th    • nflverse

Screenshots
No response
Additional context
No response

As of now it looks like the data source closed completely. We will see if there's a chance to get back primetime games at least. But at the moment it looks like it's gone.

there is no pbp_participation_2024.parquet file! @mrcaseb are you saying that there will never be pbp data for 2024?

Yes https://x.com/john_b_edwards/status/1832091502895579354


mergify: add support for 3.9 backports

ci: remove mergify rules for release-v3.7

This commit removes mergify rules to backport PR
to release-v3.7 branch.

ci: add mergify rules for release-v3.9

This commit adds mergify rules to backport PR
to release-v3.9 branch.

@mergifyio rebase

@mergifyio queue

All ci tests are green.
Manually merging since this modifies mergifyio configuration.


DMS coordinates not detected

Describe the bug

28˚ 55' 19"N 77˚ 23' 14"W   not found.
28:55:19N, 77:23:14W found.

degree symbol was never accounted for in patterns file.
Fixed in geocoords_patterns