Validation unique and excluding current record

This is very good job I wanted to use it on my Rad4PHP CRUD (www.rad4php.com) scaffolding generator, while testing the usage I come across problem in validation when updating and checking for unique validation attribute it errors to field value already taken (it does not exclude the current record from this check): e.g $validator=Validator::make(Input::all(),array(
    'username'            =>'required|unique:users,username,'.$id,
    'email'                =>'required|unique:users,email,'.$id,
    'password'            =>'required',
    'repassword'        =>'required|same:password'
    ));

I do not have this problem on MySql only MongoDB, Any advise and suggestion to resolve it highly appreciated

I have sorted this problem as follows:
(please note this workaround is ok for MongoDB only)
edit (laravel bas folder)/vendor/laravel/framework/src/illuminate/Validation.php
change at line 1009:
$idColumn = isset($parameters[3]) ? $parameters[3] : 'id';
to
$idColumn = isset($parameters[3]) ? $parameters[3] : '_id';
Since mongodb uses _id for id field and not id as in MySql and other databases.
I have tested this and works perfect with my Rad4PHP CRUD generator (www.rad4php.com)

Its never a good practice to edit the vendor source.
You could simply make your model use primary key as id.
protected $primaryKey = '_id';

You are absolutely right kodeline but unfortunately there is no way around this problem but to modify the source code, I have tried your  suggestion but did not work (still does not exclude the current record from checking unique rule).
So it is up to jessegers to sort this problem, meanwhile my workaround is fine as long as you are using Mongodb.
Thanks

You are absolutely right  but unfortunately there is no way around this problem but to modify the source code, I have tried your suggestion but did not work (still does not exclude the current record from checking unique rule).
So it is up to jessegers to sort this problem, meanwhile my workaround is fine as long as you are using Mongodb.
Thanks M A Shalash M.Sc. B.Sc.

 On Thursday, 15 January 2015, 22:48, Ahsen M<EMAIL_ADDRESS>wrote:

Its never a good practice to edit the vendor source.
You could simply make your model use primary key as id.
protected $primaryKey = '_id';—
Reply to this email directly or view it on GitHub.

Inside Model
public static function rules ($id=0, $merge=[]) {
return array_merge(
[
'username'  => 'required|min:3|max:12|unique:users,username' . ($id ? ",$id" : ''),
'email'     => 'required|email|unique:member'. ($id ? ",id,$id" : ''),
'firstname' => 'required|min:2',
'lastname'  => 'required|min:2',
],
$merge);
}
Validation on create:
$validator = Validator::make($input, User::rules());
Validation on update:
$validator = Validator::make($input, User::rules($id));
Validation on update, with some additional rules:
$extend_rules = [
'password'       => 'required|min:6|same:password_again',
'password_again' => 'required'
];
$validator = Validator::make($input, User::rules($id, $extend_rules));
Giving me an error
exception: the match filter must be an expression in an object

Hi SanJay1688
According to Laravel docs,I use rules as follows:
protected $rules =array(
'username'	 => 'required|unique:users,username,{id}',
);
Use my generater at (www.rad4php.com)  it will generate CRUD scaffolding and all the models, views, routes ...
If you  wait a week I will upload a new version with graphical interface.
Thanks

i like how L5 handle validations, You have different class which extends formRequest. Maybe take a look at that. Cleaner and effective code.

Why was this closed? I'm having the exact same issue. Is there a stable workaround?

After digging into the source code a bit you will find this:
/vendor/laravel/framework/src/Illuminate/Validation/Validator.php
`/**
* Get the excluded ID column and value for the unique rule.
*
* @param  array  $parameters
* @return array
*/
protected function getUniqueIds($parameters)
{
$idColumn = isset($parameters[3]) ? $parameters[3] : 'id';
    return [$idColumn, $parameters[2]];
}`

It's looking for a 3rd parameter to define the id field.
Simply put your rule should look like this: 'email' => 'required|email|unique:users,email,'.$id.',_id',
Thats:
'{field}'         => '{rules}:{targetTable/Collection},{targetColumn},{exclusionRecord/ID},{exclusionColumn}',
I bet this is somewhere in the documentation but why the hell use the short way of finding information?

THIS IS AN EASY SOLUTION
Just add $this->route('id') as the third parameter
if your route was defined like this:
Route::put('{company}', 'CompanyController@update')
        ->name('update');

then your parameter name is "company"
So in your FormRequest:
public function rules()
{
    $rules = [
        'url' => [
            'required',
            'url',
            'unique:companies,url,'.$this->route('company') ?? 0
        ],
    ];
    // dd($rules); << check yourself

    return $rules;
}

This FormRequest works the same for insert or update.
this line will instruct to ignore "0" in case of insert
$this->route('company') ?? 0


Move filters to Redux

Moved fitlers field values to the redux store and made a first selector for the filtered plugin list

Closing #83


Full file path not being fed to SWC CLI

I have a file packages/xpackage/server/src/tests/y-test.ts, which I am trying to compile with the swc_rule.
Problem
The compiled output file is empty.
Configuration
swc(
  name = "y_test_swc",
  srcs = ["y-test.ts"],
  source_maps = True,
  swcrc = "//packages/xpackage:.swcrc",
)

Possible Cause
Current subcommand being run by swc_rule:
SUBCOMMAND: # //packages/xpackage/server/src/tests:y_test_swc [action 'Transpiling with swc //packages/xpackage/server/src/tests:y_test_swc [swc packages/xpackage/server/src/tests/y-test.ts]', configuration: 2dbb605ac0825292323b7a4585cb36cd7762af7e47ba3ff3f3e09310b3ca4246, execution platform: @local_config_platform//:host]
(cd /private/var/tmp/_bazel_riyavsinha/903eebc477abc3a7df81d5ec7291fe86/execroot/workspace_name && \
  exec env - \
    SWC_BINARY_PATH=external/swc_darwin-x64/swc.darwin-x64.node \
  bazel-out/darwin-opt-exec-2B5CBBC6/bin/external/aspect_rules_swc/swc/_cli_launcher.sh --source-maps true --config-file packages/xpackage/.swcrc server/src/tests/y-test.ts --out-file bazel-out/darwin-fastbuild/bin/packages/xpackage/server/src/tests/y-test.js --no-swcrc -q)

Because the input file is being given as server/src/tests/y-test.ts instead of packages/xpackage/server/src/tests/y-test.ts (the packages/xpackage stripped away), maybe the file is not being recognized/input to swc in the first place, and so it outputs a blank file?
(There is also no error thrown for this, and only by opening the compiled file can you see that it is blank, though this may be an issue with swc?)

--out-file bazel-out/darwin-fastbuild/bin/packages/xpackage/server/src/tests/y-test.js looks right.
What's in your .swcrc?

SWCRC:
{
  "jsc": {
    "parser": {
      "syntax": "typescript",
      "tsx": false,
      "decorators": true,
      "dynamicImport": false
    },
    "transform": {
      "legacyDecorator": true,
      "decoratorMetadata": true
    },
    "target": "es2016"
  },
  "module": {
    "type": "commonjs",
    "strict": false,
    "strictMode": true,
    "lazy": false,
    "noInterop": false
  },
  "sourceMaps": true
}

Oh interesting, removing the swcrc attribute makes it compile with the correct input file:
Config:
swc(
  name = "cron_test_swc",
  srcs = ["cron-test.ts"],
  source_maps = True,
)

Subcommand run:
SUBCOMMAND: # //packages/xpackage/server/src/tests:y_test_swc [action 'Transpiling with swc //packages/xpackage/server/src/tests:y_test_swc [swc packages/xpackage/server/src/tests/y-test.ts]', configuration: 2dbb605ac0825292323b7a4585cb36cd7762af7e47ba3ff3f3e09310b3ca4246, execution platform: @local_config_platform//:host]
(cd /private/var/tmp/_bazel_riyavsinha/903eebc477abc3a7df81d5ec7291fe86/execroot/workspace_name && \
  exec env - \
    SWC_BINARY_PATH=external/swc_darwin-x64/swc.darwin-x64.node \
  bazel-out/darwin-opt-exec-2B5CBBC6/bin/external/aspect_rules_swc/swc/_cli_launcher.sh --source-maps true packages/xpackage/server/src/tests/y-test.ts --out-file bazel-out/darwin-fastbuild/bin/packages/xpackage/server/src/tests/y-test.js --no-swcrc -q)

I tried moving my .swcrc to the workspace root, which produced this command, which looks more correct:
SUBCOMMAND: # //packages/xpackage/server/src/tests:y_test_swc [action 'Transpiling with swc //packages/xpackage/server/src/tests:y_test_swc [swc packages/xpackage/server/src/tests/y-test.ts]', configuration: 2dbb605ac0825292323b7a4585cb36cd7762af7e47ba3ff3f3e09310b3ca4246, execution platform: @local_config_platform//:host]
(cd /private/var/tmp/_bazel_riyavsinha/903eebc477abc3a7df81d5ec7291fe86/execroot/workspace_name && \
  exec env - \
    SWC_BINARY_PATH=external/swc_darwin-x64/swc.darwin-x64.node \
  bazel-out/darwin-opt-exec-2B5CBBC6/bin/external/aspect_rules_swc/swc/_cli_launcher.sh --source-maps true --config-file .swcrc packages/xpackage/server/src/tests/y-test.ts --out-file bazel-out/darwin-fastbuild/bin/packages/xpackage/server/src/tests/y-test.js --no-swcrc -q)

ERROR: /Users/riyavsinha/Projects/workspace_name/packages/xpackage/server/src/tests/BUILD:20:4: Transpiling with swc //packages/xpackage/server/src/tests:y_test_swc [swc packages/xpackage/server/src/tests/y-test.ts] failed: (Exit 1): _cli_launcher.sh failed: error executing command bazel-out/darwin-opt-exec-2B5CBBC6/bin/external/aspect_rules_swc/swc/_cli_launcher.sh --source-maps true --config-file .swcrc packages/xpackage/server/src/tests/y-test.ts --out-file ... (remaining 3 argument(s) skipped)

So, because the .swcrc is now in the root, it looks like it passes the correct full path to the CLI packages/xpackage/server/src/tests/y-test.ts.
(The error comes from //:.swcrc being passed to the CLI as .swcrc, which it doesn't like for some reason)

This is probably happening because of the "relativizing" of paths:
https://github.com/aspect-build/rules_swc/blob/main/swc/private/swc.bzl#L83

Yeah I agree, swc behavior changes based on the config file path. I'm not sure if that's actually desirable or if it ought to change upstream.

Hm, so the path relativizing in this repo's rule is not the cause?
In my initial custom swc rule I believe it worked without modifying paths in the rule implementation:
args.add("--config-file", ctx.file.swcrc.path)
args.add_all([src.path for src in ctx.files.srcs])

@gregmagolan added that comment
# Pass in the swcrc config if it is set; if it is
# then source paths are expected to be relative to the swcrc directory

But yeah, it seems broken to me as-is.

Odd, I had trouble with it initially with the full path when passing an swcrc file and had to make it relative to work. Something change upstream?


disk storage updates

updates to satisfy audit ticket https://jira.iohk.io/browse/CAD-1944

Closing this. If this is still relevant please re-open a new PR.


list index out of range

face_recognition version: latest
Python version: 2.7
Operating System: Mac OS 10

Description
Applying face_recognition.face_encodings to a few images. Some of them work fine, others show "list index out of range" error.
0, 1, 3 work; 2, 4 do not.

What I Did
known_image = face_recognition.load_image_file("face_2.jpg")
known_encoding = face_recognition.face_encodings(known_image)[0]

I found dlib cannot detect face from the third and fifth images. But I do not understand why because all images are cropped from one image, on which 5 faces been successfully detected.

First, you can check the length of the array returned from face_recognition.face_encodings(known_image) before accessing [0] to prevent the basic error. If no faces are detected, the array will be empty.
Second, dlib is trying to find a face within the image. It's not trying to decide if the whole image is a face. Since you already have the images cropped to the whole face, you can skip the step of face detection by telling face_recognition where the face is located like this:
known_image = face_recognition.load_image_file("face_2.jpg")

# Since the image is already cropped, we know the face location is just the whole image size
face_location = (0, known_image.shape[1], known_image.shape[0], 0)

# Pass in an array of known face locations to skip the step of face detection
known_encoding = face_recognition.face_encodings(known_image, [face_location])[0]

print(known_encoding)

array([-0.07084331,  0.13144939,  0.06481101, -0.05566324, -0.10227886,
        0.02378505, -0.02929443, -0.16121498,  0.09502754, -0.09116761,
        0.16282618,  0.01120954, -0.22670874, -0.07019024,  0.07189877,
        0.08362474, -0.13715625, -0.04159784, -0.13862796, -0.04521821,
        0.06266126,  0.09748268,  0.06780834, -0.03782643, -0.09195558,
       -0.32051048, -0.06524452, -0.07020397,  0.02561777, -0.06362872,
        0.02519293, -0.03309638, -0.25325459, -0.05337401, -0.04081663,
        0.02959361, -0.1108077 , -0.10953825,  0.20097654, -0.03071829,
       -0.19747683,  0.10650204,  0.05199543,  0.17633158,  0.20601764,
       -0.08934571, -0.00882005, -0.07672026,  0.15298177, -0.20318791,
        0.06232864,  0.14546208,  0.10586035,  0.09767602,  0.07987885,
       -0.03630037,  0.09194864,  0.12821943, -0.18550503,  0.01531077,
        0.16177645, -0.11098912, -0.0145441 , -0.00749754,  0.13307199,
        0.06760155, -0.06180105, -0.12176102,  0.0763557 , -0.10216746,
       -0.0853331 ,  0.01694381, -0.12842602, -0.12923945, -0.33743614,
        0.06042334,  0.28734946,  0.14279479, -0.21950229, -0.00438824,
       -0.12347218,  0.02389126,  0.0859604 ,  0.06279413, -0.01622978,
       -0.06947765, -0.07259755,  0.09392088,  0.17706268, -0.02612238,
       -0.02010851,  0.31076789,  0.10003579, -0.02693687,  0.03024578,
        0.05860615, -0.10163979, -0.08813927, -0.1216615 ,  0.03181211,
        0.0669135 , -0.1004982 ,  0.00465229,  0.19129516, -0.24604803,
        0.23892471, -0.00085283, -0.00195196,  0.07778236, -0.06403588,
       -0.03284847, -0.00111775,  0.07869174, -0.20308636,  0.21220191,
        0.12809221, -0.01532205,  0.09983703,  0.0276077 ,  0.06673215,
       -0.07806585,  0.00037921, -0.20924436, -0.12015466,  0.05508876,
        0.06190829,  0.0230726 ,  0.07592089])

That will run a lot faster anyway.

Thanks a lot! mate

Sure thing! It was a good question. :)


Unexpected line-break in integrated powershell terminal after using Terminal:Clear command

VSCode Version: 1.50.1
OS Version: Windows 10.0.19041 (x64)

Steps to Reproduce:

Open integrated powershell terminal
Have multiple lines on screen (type random commands or press return a couple of times)
Use keyboard shortcut for workbench.action.terminal.clear. In my case it is set to ctrl+L. Or use the Terminal:Clear  command from the command palette (ctrl+shift+P).
Now that terminal is cleared and the cursor is at the top, start typing again. After 2 characters, the cursor will suddenly drop to the previous location before the clear command, leaving blank space.

Here is a GIF of this issue:

Does this issue occur when all extensions are disabled?: Yes

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:
* [the keyboard shortcut of clearing the terminal doesn't work rightly (#95411)](https://www.github.com/microsoft/vscode/issues/95411)

Does not appear to be a duplicate.

/duplicate https://github.com/microsoft/vscode/issues/75141


Queue ext host terminal onData events when terminal ID is not yet set

https://github.com/Microsoft/vscode/blob/7396416d7a35f1a4187c558dc050908d60a1f632/src/vs/workbench/api/node/extHostTerminalService.ts#L294

Verification steps?

Verification Steps:
Create an extension with this command:
context.subscriptions.push(vscode.commands.registerCommand('terminalTest.createAndSend', () => {
	const terminal = vscode.window.createTerminal(`Ext Terminal #${NEXT_TERM_ID++}`);
	if((<any>terminal).onDidWriteData) {
		(<any>terminal).onDidWriteData(data => {vscode.window.showInformationMessage('Hello World!');});
	}
	terminal.sendText("echo 'Sent text immediately after creating'");
}));

When you execute the command, confirm that the 'Hello World!' info message shows. Do this five or so more times since this is a race condition.


Fix login to docker.io

Fix BZ https://bugzilla.redhat.com/show_bug.cgi?id=1309739#c4
@rhatdan @aweiteka @miminar
This is already fixed from docker-1.10.x+. fedora-1.9 branch doesn't have this fix though, since we're about to push 1.10.3 in updates-testing
Signed-off-by: Antonio Murdaca<EMAIL_ADDRESS>

LGTM


Fix: Formatting example.ipynb and Latex (ALAN)

This is a commit to fix the formatting issues in the ROI() example.ipynb usage, as per Meretes comment there was latex and formating issues that made it hard to understand what the function was doing under the hood.

nice thank you!


[FEATURE] Allow Arguments with alternative / custom names.

Is your feature request related to a problem
Is your feature request related to a problem? Yes
In this example I'd like to use the name id_ internally, but for the CLI I would like to provide an alternative name id:
def user(id_: Optional[str] = typer.Argument(None)):
   ...

For Commands and Options, this is already possible using @app.command("foo") and typer.Option(..., "--foo", "-f").
For Arguments it seems there is no way of doing this... if there was it would be nice to include a section for it in the docs, similar to CLI Option Name
The solution you would like
Maybe this:
typer.Argument(None, "id")

or
typer.Argument(None, name="id")

?

You would use the metavar field:
@app.command()
def print_id(id_: str = typer.Argument(..., metavar="id")):
    print(id_)

Usage: typerarg.py [OPTIONS] id

Arguments:
  id  [required]

Options:
  --install-completion  Install completion for the current shell.
  --show-completion     Show completion for the current shell, to copy it or
                        customize the installation.

  --help                Show this message and exit.

Ah, thanks a lot!  I guess I was intuitively looking for it to have its own section. Commands and Options do have extra sections for this:

Custom Command Name
CLI Option Name

I didn't expect to find it in the CLI Arguments with Help section.
Just some feedback from someone new to typer :-)
Otherwise I'm really amazed by the project, same as FastApi. Both are such a joy to code with!

Thanks for the help here @daddycocoaman ! 👏  🙇
If that solves the original problem, then you can close this issue @feluxe  ✔

Sorry for the long delay! 🙈  I wanted to personally address each issue/PR and they piled up through time, but now I'm checking each one in order.


Change label collaborations

SunbirdEd - Portal

Changing the labels of the Collaborations page(from workspace). like a board - Function, etc.,

Please choose the applicable option
Example

[x] Applicable
[ ] Not applicable

Type of change
Please choose the appropriate options.

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

Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented on my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules

Do not approve this PR, someone can delete if possible


X11 unsoundness when using minifb with threads

In the course of helping @Egggg with a SIGSEGV: invalid memory reference, I generated the following backtrace with llvm's address sanitizer.
...
==17541==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x55588bdc8f70 bp 0x7f69f1968560 sp 0x7f69f1967d18 T7)
...
    #0 0x55588bdc8f70 in __sanitizer::internal_strlen(char const*) /rustc/llvm/src/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_libc.cpp:167:10
    #1 0x55588bda2af1 in __interceptor_strdup /rustc/llvm/src/llvm-project/compiler-rt/lib/asan/asan_interceptors.cpp:450:17
    #2 0x7f69e65c6858  (/usr/lib64/libX11.so.6+0x54858)
    #3 0x7f69e65c6b6c  (/usr/lib64/libX11.so.6+0x54b6c)
    #4 0x7f69e65c7307 in _XlcCreateLocaleDataBase (/usr/lib64/libX11.so.6+0x55307)
    #5 0x7f69e65cb4cf  (/usr/lib64/libX11.so.6+0x594cf)
    #6 0x7f69e65caa42  (/usr/lib64/libX11.so.6+0x58a42)
    #7 0x7f69e65cb278 in _XlcCreateLC (/usr/lib64/libX11.so.6+0x59278)
    #8 0x7f69e65ec760 in _XlcUtf8Loader (/usr/lib64/libX11.so.6+0x7a760)
    #9 0x7f69e65d295d in _XOpenLC (/usr/lib64/libX11.so.6+0x6095d)
    #10 0x7f69e65d2ada in _XrmInitParseInfo (/usr/lib64/libX11.so.6+0x60ada)
    #11 0x7f69e65ba424  (/usr/lib64/libX11.so.6+0x48424)
    #12 0x7f69e65bdb1e in XrmGetStringDatabase (/usr/lib64/libX11.so.6+0x4bb1e)
    #13 0x7f69e659a093  (/usr/lib64/libX11.so.6+0x28093)
    #14 0x7f69e659a2f5 in XGetDefault (/usr/lib64/libX11.so.6+0x282f5)
    #15 0x7f69f654f212 in _XcursorGetDisplayInfo (/usr/lib64/libXcursor.so.1+0x5212)
    #16 0x7f69f654f328 in XcursorGetDefaultSize (/usr/lib64/libXcursor.so.1+0x5328)
    #17 0x7f69f6551815 in XcursorLibraryLoadCursor (/usr/lib64/libXcursor.so.1+0x7815)
    #18 0x55588bea37f9 in minifb::os::posix::x11::DisplayInfo::load_cursor::he0d374523fbba6d7 /home/<username>/.cargo/registry/src/github.com-1ecc6299db9ec823/minifb-0.23.0/src/os/posix/x11.rs:258:18
    #19 0x55588bea31e4 in minifb::os::posix::x11::DisplayInfo::init_cursors::hd98ce9731dc012ad /home/<username>/.cargo/registry/src/github.com-1ecc6299db9ec823/minifb-0.23.0/src/os/posix/x11.rs:245:27
    #20 0x55588be9ef78 in minifb::os::posix::x11::DisplayInfo::new::h13afc602d291ed56 /home/<username>/.cargo/registry/src/github.com-1ecc6299db9ec823/minifb-0.23.0/src/os/posix/x11.rs:114:9
    #21 0x55588bea5475 in minifb::os::posix::x11::Window::new::hf38318783718700e /home/<username>/.cargo/registry/src/github.com-1ecc6299db9ec823/minifb-0.23.0/src/os/posix/x11.rs:351:21
    #22 0x55588bf51450 in minifb::os::posix::Window::new::h589266c9654934f2 /home/<username>/.cargo/registry/src/github.com-1ecc6299db9ec823/minifb-0.23.0/src/os/posix/mod.rs:47:42
    #23 0x55588bfc1306 in minifb::Window::new::hcb0be08bd6ce344a /home/<username>/.cargo/registry/src/github.com-1ecc6299db9ec823/minifb-0.23.0/src/lib.rs:247:9
...<stack trace continues up>...

After some investigation I found that minifb does not appear to run XInitThreads when it initializes it's X11 instance. Because of this, when used by multiple threads minifb calls into X11 code without proper thread synchronization.
The following is a minimal reproducible example. The error should be seen if run with RUSTFLAGS=-Zsanitizer=address cargo +nightly run.
use minifb::{Window, WindowOptions};
use std::thread::*;
use std::time::Duration;

fn main() {
    for _ in 0..10 {
        spawn(|| {
            let _ = Window::new("test", 100, 100, WindowOptions::default()).unwrap();
        });
    }
    sleep(Duration::from_secs_f32(10.0));
}

Adding the following code before calling Window::new results in address sanitizer not reporting any memory violations, and the code working as expected
let xlib = xlib::Xlib::open().unwrap();
if unsafe { (xlib.XInitThreads)() } == 0 {
     panic!("failed to init X11 threads")
}

Thanks for the report. It should be noted that on some OSes (such as macOS) creating windows on anything but the main thread is not supported (this is enforced by the macOS APIs and nothing minifb can do anything about) a
As minifb aims to behave the same across all platforms I think it would be better simply disallow window creation on anything, but the main thread.

I decided to implement your suggestion. Thanks! It's included in version 0.24 that has been published


⚠ Bofrost.de has degraded performance

In 2f5c581, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 843 ms

Resolved: Bofrost.de performance has improved in 8623ebb after 7 minutes.


[BUG] - Date Input margins VS Input margins

NextUI Version
<EMAIL_ADDRESS>Describe the bug
When the labelPlacement is set to outside, Input and DateInput behave differently, which makes it very hard to align a section with both Inputs and DateInputs. When inspected, I managed to see that the label of the Input component in positioned in an absolute manner (on top of its margin, whereas the label component of the DateInput is positioned regularly (in the components content).
Your Example Website or App
No response
Steps to Reproduce the Bug or Issue

Create a section / div
Make that div flex flex-col space-y-10
Add 2 Input components
Add 1 DateInput component underneath them
See? the spacing is different

Expected behavior
Labels that are positioned outside should be a part of the component's content, not margin
Screenshots or Videos

Operating System Version
All
Browser
Chrome

please share a minimal reproducible environment

Closing - inactivity


Djangonaut Space Program

Since the names and urls are being fetched from data.json, I moved one entry from the index.html to data.json.
The website works as intended.

Appreciate, Can you change this long name to "Djangonaut Space Program" only.

Appreciate, Can you change this long name to "Djangonaut Space Program" only.

Done, please merge if everything looks ok.
Thanks


Make json optional in tests

I think we should activate the tests for json serialization only when nlohmann_json has been found on the system as many people will likely not have it installed.

:+1:


Split MessageSerializer into reader and writer so that reading and writing threads do not share the same buffer

The original MessageSerializer was using the same byte array for both read and write ops. Those reads and writes happen in different threads. To avoid potential conflicts between the read and write threads I have split the MessageSerializer into MessageReader and MessageWriter, each holding its own byte array buffer.
The issue is actually not critical at the moment, because the ops do not happen to interleave: client sends one message and then only receives without sending. This might perhaps change in the future, when we start supporting build cancellation. Anyway, I find the split conceptually cleaner.
That was about the first two commits
Now about the third commit, that I'd like to hear your opinion about:
Having done the split, I am struggling about the necessity of the byteBuf in the reader and writer
The byteBufs do not seem to make much sense performance-wise, because the underlying Data[Input|Output]Streams are are backed by custom Socket[Output|Input]Streams https://github.com/mvndaemon/mvnd/blob/ba56664e2cecafdb77981687b507bb82e57dd7ac/common/src/main/java/org/jboss/fuse/mvnd/common/DaemonConnection.java#L66-L67
that have a ByteBuffer https://github.com/mvndaemon/mvnd/blob/ba56664e2cecafdb77981687b507bb82e57dd7ac/common/src/main/java/org/jboss/fuse/mvnd/common/DaemonConnection.java#L159
So why could we not further simplify MessageReader and MessageWriter by removing the byteBuf and the [read|write]UTF methods and use java.io.Data[Inpiut|Output]Stream.[read|write]UTF(String) instead?
We'd end up with less code and in theory also a bit better perf. WDYT?

It seems this PR goes back and forth (adding classes + removing those).
At the end, it seems to be about removing the Serializer instance and make the code into static methods and removing the read/writeUTF methods to delegate to the ones from DataInput/OutputStream.
That sounds good to me, but we may want to simplify the commits a bit.

Thanks, squashed.


User driven development

Let users/clients decide (based on likes?) which feature to develop next

moved to priv


Need to expire cookies in minutes instead of days.

I checked the source codes a bit but can't find a way set expiration period in minutes. The only supported option is to set expiry in # of days. If setting cookies in length shorter than a day is not supported, is there a plan to do so?

You could probably do something like 0.00x to specify the expiry in minutes but i have to check if that works currently

I tried, but unfortunately it didn’t work.
Get Outlook for iOShttps://aka.ms/o0ukef

From: Julian Sigmund @.>
Sent: Thursday, June 22, 2023 5:52:12 PM
To: pixelmund/svelte-kit-cookie-session @.>
Cc: Rico Chen @.>; Author @.>
Subject: Re: [pixelmund/svelte-kit-cookie-session] Need to expire cookies in minutes instead of days. (Issue #56)
You could probably do something like 0.00x to specify the expiry in minutes but i have to check if that works currently
—
Reply to this email directly, view it on GitHubhttps://github.com/pixelmund/svelte-kit-cookie-session/issues/56#issuecomment-1603361059, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAIZI56Y2DT2S6CFP42RC23XMS5AZANCNFSM6AAAAAAZO2M6F4.
You are receiving this because you authored the thread.Message ID: @.***>

How do you set the expiry date? I have been trying to use .set() but when I retrieve the session, the "expires" property is undefined whereas the rest of my properties are maintained.

It is now possible to set the type of expiry with the expires_in option, which should be of type days | hours | minutes | seconds


Forall is acting funny!

Here is a sample, tell me what you think.
/*
CREATE AND POPULATE THE TABLE WITH

DROP TABLE IF EXISTS r.cho_named_edges;
CREATE TABLE r.cho_named_edges
(
 from_nm text
, to_nm text
);
INSERT INTO r.cho_named_edges (from_nm, to_nm) VALUES
  ('star lord', 'gamora') , ('star lord', 'groot')
, ('star lord', 'drax') , ('gamora', 'drax')
, ('groot', 'drax') , ('drax', 'rocket')
, ('rocket', 'mantis') , ('mantis', 'yondu')
, ('mantis', 'nebula') , ('yondu', 'nebula')
;

chpl -M/Users/buddha/github/cdo/src/ faerr.chpl

 */
use Cdo, Postgres;

var DB_HOST="localhost",
    DB_USER="buddha",
    DB_PWD="buddha",
    DB_NAME="buddha",
    con = PgConnectionFactory(host=DB_HOST, user=DB_USER, database=DB_NAME, passwd=DB_PWD);

var q = """
SELECT from_nm, to_nm FROM r.cho_named_edges ORDER BY from_nm, to_nm;
""";

var cursor = con.cursor();
cursor.query(q);

/*
 Should return 10 rows
 */
var i: int = 0;
writeln("=== FOR LOOP ===");
for row in cursor {
  writeln("from: ", row['from_nm'], "\tto: ", row['to_nm']);
  i += 1;
}
writeln("Expected 10 rows, got ", i);

var cursor2 = con.cursor();
cursor2.query(q);

/*
 Should also return 10 rows
 */
var j:int = 0;
writeln("\n=== FORALL LOOP ===");
forall row in cursor with (+ reduce j) {
  writeln("from: ", row['from_nm'], "\tto: ", row['to_nm']);
  j += 1;
}
writeln("Expected 10 rows, got ", j);
writeln("Okay, I usually get 9 rows, not 10");

Updated with @daviditen  answer to this SO

@buddha314 , I sent an example that worked well. I followed the @daviditen suggestion.
Here is the example:
https://github.com/marcoscleison/cdo/blob/cd837690db3ababd02871b7ebe66296d36242071/examples/parallel3.chpl#L20
There was another issue related to cursor.rowcount() method. For Postgres it was returning 1 if the query was a success but with zero rows. Now, it returns the real number of rows. If an error is present it can return -1.

So does this mean forall row in cursor {} will now return all 10 rows or did this just fix the rowcount()?

Here is the example:
https://github.com/marcoscleison/cdo/blob/03ca8cc20436dd771271e75d1b8d0b19a6bddda5/examples/parallel3.chpl#L32
The issue was caused because I considered the Chapel range as inclusive, but the ransge is exclusive. So the forall loop handler was missing one row.


Find foreign keys from information_schema

We would like to determine the dependencies that exist
among tables. This will help us know the order in which
to dump them. So, as a first step, we find all foreign
keys.

Thanks @rafaeljesus for the review. I've implemented your recommendations :)

👍

Going to close this for now, as it doesn't fit our use case.


Removed duplicate "during"

"present during during URL generation" -> "present during URL generation"

Hi @BrianSzuter, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, DNFBOT;

@BrianSzuter, Thanks for signing the contribution license agreement so quickly! Actual humans will now validate the agreement and then evaluate the PR.
Thanks, DNFBOT;


Statistical queries, Demographics report - fix counting of Nutrition group encounters

#1279

Trivial change. Merging.


Add more journals

Adding 398 journal files

Hi! Thanks you for adding those journals. I'll be adding some commits to this PR to make the tests pass with all the new test-cases and merge it soon after.

Thanks again for contributing to this project! Journals have now been merged!


Add DelayStart to feature WasherDryer

Adds the DelayStart feature to Washer Dryer devices that use the @CP_UX30_CARD_DELAY_SET key for Delay Set

Fixes #785


Devise with Sendgrid API

All help I have found for using Devise with Sendgrid is based around the SMTP method.
Is there a step-by-step setup for using Devise with the the Sendgrid API?
It would be great to have a single known-to-work approach rather than patching together pieces of a possible solution.

Please use the mailing list or StackOverflow for questions/help, where a wider community will be able to help you. We reserve the issues tracker for issues only.


Support for Google TPU?

Hi,
Thank you for developing the repository. Are there possible plans to include TPU support?
Branch: Dev
Regards
Tim

pytorch lightning supports TPU. It should be a quick modification of this function without modification of anything else
https://github.com/kwea123/nerf_pl/blob/2ca26add4f85218a97f6825e3eb0b9db19e7bab5/train.py#L167-L177
You can have a look on pytorch lightning doc of how to enable it (also upgrade pytorch lightning to latest version if needed).

Thank you.
I have made those changes and it addresses the TPU but unfortunately seems to crash soon after executing.
RuntimeError: Cannot access data pointer of Tensor that doesn't have storage
Exception in device=TPU:6: Cannot access data pointer of Tensor that doesn't have storage
Traceback (most recent call last):
  File "/home/username/anaconda3/envs/nerf_pl/lib/python3.6/site-packages/torch_xla/distributed/xla_multiprocessing.py", line 329, in _mp_start_fn
    _start_fn(index, pf_cfg, fn, args)
  File "/home/username/anaconda3/envs/nerf_pl/lib/python3.6/site-packages/torch_xla/distributed/xla_multiprocessing.py", line 323, in _start_fn
    fn(gindex, *args)
  File "/home/username/anaconda3/envs/nerf_pl/lib/python3.6/site-packages/pytorch_lightning/trainer/distrib_parts.py", line 523, in tpu_train
    self.run_pretrain_routine(model)
  File "/home/username/anaconda3/envs/nerf_pl/lib/python3.6/site-packages/pytorch_lightning/trainer/trainer.py", line 899, in run_pretrain_routine
    False)
  File "/home/username/anaconda3/envs/nerf_pl/lib/python3.6/site-packages/pytorch_lightning/trainer/evaluation_loop.py", line 278, in _evaluate
    output = self.evaluation_forward(model, batch, batch_idx, dataloader_idx, test_mode)
  File "/home/username/anaconda3/envs/nerf_pl/lib/python3.6/site-packages/pytorch_lightning/trainer/evaluation_loop.py", line 447, in evaluation_forward
    output = model.validation_step(*args)
  File "/home/username/nerf_pl/train.py", line 126, in validation_step
    results = self(rays)
  File "/home/username/anaconda3/envs/nerf_pl/lib/python3.6/site-packages/torch/nn/modules/module.py", line 889, in _call_impl
    result = self.forward(*input, **kwargs)
  File "/home/username/nerf_pl/train.py", line 67, in forward
    self.train_dataset.white_back)
  File "/home/username/nerf_pl/models/rendering.py", line 226, in render_rays
    N_importance, det=(perturb==0)).detach()
  File "/home/username/nerf_pl/models/rendering.py", line 42, in sample_pdf
    inds = searchsorted(cdf, u, side='right')
  File "/home/username/anaconda3/envs/nerf_pl/lib/python3.6/site-packages/torchsearchsorted/searchsorted.py", line 51, in searchsorted
    searchsorted_cpu_wrapper(a, v, out, left_side)
RuntimeError: Cannot access data pointer of Tensor that doesn't have storage
Traceback (most recent call last):
  File "train.py", line 182, in <module>
    trainer.fit(system)
  File "/home/username/anaconda3/envs/nerf_pl/lib/python3.6/site-packages/pytorch_lightning/trainer/trainer.py", line 777, in fit
    xmp.spawn(self.tpu_train, args=(model,), nprocs=self.num_tpu_cores, start_method=start_method)
  File "/home/username/anaconda3/envs/nerf_pl/lib/python3.6/site-packages/torch_xla/distributed/xla_multiprocessing.py", line 394, in spawn
    start_method=start_method)
  File "/home/username/anaconda3/envs/nerf_pl/lib/python3.6/site-packages/torch/multiprocessing/spawn.py", line 188, in start_processes
    while not context.join():
  File "/home/username/anaconda3/envs/nerf_pl/lib/python3.6/site-packages/torch/multiprocessing/spawn.py", line 144, in join
    exit_code=exitcode
torch.multiprocessing.spawn.ProcessExitedException: process 5 terminated with exit code 17


Prepare the current knowledge graph for the new ontology

We have a knowledge graph with a ton of company data already. Investigate if we can easily migrate all of that data over. If not, drop the entire DB.
Acceptance Criteria:

A hosted knowledge graph ready to accept new vertices and edges

We're going move to an entirely new DB and let it rebuild.
It's not worth rebuilding each key for each company.
closing.


pkg/polymer/test/register_test fails on IE10

 Issue by jmesserly
Originally opened as dart-lang/sdk#18870

see this log for example:
http://build.chromium.org/p/client.dart/builders/dart2js-ie10-win8-html-be/builds/6858/steps/dart2js-ie10 tests/logs/stdio

 Comment by jmesserly

the error looks like:
pre>Function code 1:1                                    Function code
                    packages/polymer/src/js/polymer/polymer.js 32:23111  init
                    register_test.html_bootstrap.dart.js 16440:7         callMethod$2
                    register_test.html_bootstrap.dart.js 16443:7         callMethod$1
                    register_test.html_bootstrap.dart.js 20129:5         Polymer_registerSync
                    register_test.html_bootstrap.dart.js 23603:7         <fn>
                    register_test.html_bootstrap.dart.js 26461:7         _testFunction$0
                    register_test.html_bootstrap.dart.js 26588:7         <fn>
                    register_test.html_bootstrap.dart.js 7530:7          <fn>
                    register_test.html_bootstrap.dart.js 9487:7          runUnary$3

 Comment by jmesserly

Added Pkg-Polymer label.

 Comment by jmesserly

not sure who it will be assigned to, but yet should fix for 1.5

Removed the owner.
Added Accepted label.

 Comment by jmesserly

hmmm, what's scary about this error: we successfully called Polymer.js, but "this" was null... That shouldn't happen given that the Dart code is:
new JsObject.fromBrowserObject(poly).callMethod('init');
... and it works in other dart2js environments like Firefox.

 Comment by jmesserly

and message is:
Test failed: Caught NullError: Unable to get property 'getAttribute' of undefined or null reference (Error 5007)

 Comment by jmesserly

Removed Area-Polymer label.
Added Area-Pkg label.

 Comment by kasperl

Is this something we should get fixed for 1.5, John?

Set owner to @jmesserly.

 Comment by jmesserly

Where was this fixed? In dart-lang/sdk@708ce2d93e63a804b86c7b3608cbb31db00cfec5?

Yup.

Do we need to bring anything to trunk to improve our test coverage there? Am I right in assuming that if we don't pull over the polymer package changes, we will continue to test the old version of polymer on trunk -- leaving us with less than ideal test coverage there?

That's a great idea. Yeah, merging pkg/[observe,template_binding,polymer,polymer_expressions,web_components] into trunk would improve coverage against latest versions of packages.

 Comment by jmesserly

I'm looking at the IE things. This issue seems even more widespread after the latest polymer/platform roll.

Set owner to @jmesserly.

 Comment by jmesserly

Added Fixed label.

 Comment by kasperl

Where was this fixed? In dart-lang/sdk@708ce2d93e63a804b86c7b3608cbb31db00cfec5?

 Comment by kasperl

Do we need to bring anything to trunk to improve our test coverage there? Am I right in assuming that if we don't pull over the polymer package changes, we will continue to test the old version of polymer on trunk -- leaving us with less than ideal test coverage there?


chore: update repo by service bot

This is a routine update from cc-service-bot based on the service.yml in your repo. This PR
should be approved and merged as soon as CI passes.

CHANGELOG
FILE NAME - CHANGED BY - COMMIT MESSAGE
Makefile - framework - chore: update repo Makefile
.gitignore - framework - chore: update repo .gitignore


ubuntu/armhf image

Kindly consider having an ARM image, even if prominently marked "EXPERIMENTAL - MAY BLOW UP".
These base Ubuntu images work on a few different development boards (like the ODROID series and the Raspberry Pi 2), and there would be no shortage of folk willing to test them (I myself intend to take a stab at building one, given that I have most of the requirements working independently).

Online labs is curently building some sort of hardware cloud based on arm socs.
http://labs.online.net/try-it
Ask them as i know they already have a registry for that.

Thanks, but isn't there something more... public?

Yup all of the images are available at => https://registry.hub.docker.com/repos/armbuild/
And the source repo is available at github => https://github.com/online-labs
This is imo a good start point to build your own arm images.

Finally got round to checking this. Thanks - am going to see if I can get swarm to build on ARMv7...

@rcarmo any news on this ?

Not yet. I've gone and built OVS for ARM and got sort of sidetracked. No ETA...

Closing due to lack of activity. Please reopen if you wish to continue discussing it.


[CPU] LLaMA F32 execution crashes when data tiling enabled

We current get a segfault when running LLaMA on F32 and data tiling (not ukernels) is enabled. It only crashes when the input is 1x4096. It works for 1x8 and 1x64 inputs. It also works for all the shapes without data tiling enabled (IREE default).
I use the following compilation command:
iree-compile --iree-hal-target-backends=llvm-cpu --iree-llvmcpu-target-cpu=cascadelake \
  --iree-input-type=stablehlo --iree-llvmcpu-target-triple=x86_64-unknown-linux-gnu \
  --iree-input-demote-f64-to-f32=false --iree-input-demote-i64-to-i32=false \
  --iree-llvmcpu-link-embedded=false --iree-opt-data-tiling=true --iree-llvmcpu-enable-microkernels=false \
  llama-linalg-dynamic.mlir -o llama-linalg-dynamic.vmfb

The crash seems to happen at the tensor.unpack operation in dispatch forward_dispatch_26_generic_32xDxD_f32:
hal.executable public @forward_dispatch_26 {
  hal.executable.variant public @system_elf_x86_64, target = <"llvm-cpu", "system-elf-x86_64", {cpu = "cascadelake", cpu_features = "+cmov,+mmx,+popcnt,+sse,+sse2,+sse3,+ssse3,+sse4.1,+sse4.2,+avx,+avx2,+fma,+avx512f,+bmi,+bmi2,+aes,+pclmul,+avx512vl,+avx512bw,+avx512dq,+avx512cd,+avx512vnni,+adx,+clflushopt,+clwb,+cx16,+cx8,+crc32,+f16c,+fsgsbase,+fxsr,+invpcid,+lzcnt,+movbe,+pku,+prfchw,+rdrnd,+rdseed,+sahf,+x87,+xsave,+xsavec,+xsaveopt,+xsaves,+evex512", data_layout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128", link_embedded = false, native_vector_size = 64 : index, target_triple = "x86_64-unknown-linux-gnu", ukernels = false}> {
    hal.executable.export public @forward_dispatch_26_generic_32xDxD_f32 ordinal(0) layout(#hal.pipeline.layout<push_constants = 7, sets = [<0, bindings = [<0, storage_buffer, ReadOnly>, <1, storage_buffer, ReadOnly>, <2, storage_buffer>]>]>) {
    ^bb0(%arg0: !hal.device, %arg1: index, %arg2: index):
      %x, %y, %z = flow.dispatch.workgroup_count_from_slice %arg1, %arg2
      hal.return %x, %y, %z : index, index, index
    }
    builtin.module {
      func.func @forward_dispatch_26_generic_32xDxD_f32() {
        %c32_i64 = arith.constant 32 : i64
        %c1 = arith.constant 1 : index
        %cst = arith.constant 0.000000e+00 : f32
        %cst_0 = arith.constant 11.3137083 : f32
        %c0 = arith.constant 0 : index
        %0 = hal.interface.constant.load[0] : i32
        %1 = hal.interface.constant.load[1] : i32
        %2 = hal.interface.constant.load[2] : i32
        %3 = hal.interface.constant.load[3] : i32
        %4 = hal.interface.constant.load[4] : i32
        %5 = hal.interface.constant.load[5] : i32
        %6 = hal.interface.constant.load[6] : i32
        %7 = arith.extui %0 : i32 to i64
        %8 = arith.extui %1 : i32 to i64
        %9 = arith.shli %8, %c32_i64 : i64
        %10 = arith.ori %7, %9 : i64
        %11 = arith.index_castui %10 : i64 to index
        %12 = arith.index_castui %2 : i32 to index
        %13 = arith.extui %3 : i32 to i64
        %14 = arith.extui %4 : i32 to i64
        %15 = arith.shli %14, %c32_i64 : i64
        %16 = arith.ori %13, %15 : i64
        %17 = arith.index_castui %16 : i64 to index
        %18 = arith.extui %5 : i32 to i64
        %19 = arith.extui %6 : i32 to i64
        %20 = arith.shli %19, %c32_i64 : i64
        %21 = arith.ori %18, %20 : i64
        %22 = arith.index_castui %21 : i64 to index
        %23 = flow.dispatch.workload.ordinal %17, 0 : index
        %24 = flow.dispatch.workload.ordinal %22, 1 : index
        %25 = hal.interface.binding.subspan set(0) binding(0) type(storage_buffer) alignment(64) offset(%11) flags(ReadOnly) : !flow.dispatch.tensor<readonly:tensor<32x2x?x16x16xf32>>{%23}
        %26 = hal.interface.binding.subspan set(0) binding(1) type(storage_buffer) alignment(64) offset(%c0) flags(ReadOnly) : !flow.dispatch.tensor<readonly:tensor<1x1x?x?xf32>>{%24, %24}
        %27 = hal.interface.binding.subspan set(0) binding(2) type(storage_buffer) alignment(64) offset(%12) : !flow.dispatch.tensor<writeonly:tensor<32x?x?xf32>>{%24, %24}
        %28 = flow.dispatch.tensor.load %25, offsets = [0, 0, 0, 0, 0], sizes = [32, 2, %23, 16, 16], strides = [1, 1, 1, 1, 1] : !flow.dispatch.tensor<readonly:tensor<32x2x?x16x16xf32>>{%23} -> tensor<32x2x?x16x16xf32>
        %29 = flow.dispatch.tensor.load %26, offsets = [0, 0, 0, 0], sizes = [1, 1, %24, %24], strides = [1, 1, 1, 1] : !flow.dispatch.tensor<readonly:tensor<1x1x?x?xf32>>{%24, %24} -> tensor<1x1x?x?xf32>
        %30 = tensor.empty(%24, %24) : tensor<32x?x?xf32>
        %unpack = tensor.unpack %28 inner_dims_pos = [1, 2] inner_tiles = [16, 16] into %30 : tensor<32x2x?x16x16xf32> -> tensor<32x?x?xf32>
        %31 = linalg.generic {indexing_maps = [affine_map<(d0, d1, d2) -> (d0, d1, d2)>, affine_map<(d0, d1, d2) -> (d0, d1, d2)>], iterator_types = ["parallel", "parallel", "parallel"]} ins(%unpack : tensor<32x?x?xf32>) outs(%30 : tensor<32x?x?xf32>) {
        ^bb0(%in: f32, %out: f32):
          %32 = linalg.index 1 : index
          %33 = linalg.index 2 : index
          %34 = arith.cmpi eq, %24, %c1 : index
          %35 = arith.select %34, %c0, %32 : index
          %36 = arith.select %34, %c0, %33 : index
          %extracted = tensor.extract %29[%c0, %c0, %35, %36] : tensor<1x1x?x?xf32>
          %37 = arith.addf %extracted, %cst : f32
          %38 = arith.divf %in, %cst_0 : f32
          %39 = arith.addf %38, %37 : f32
          linalg.yield %39 : f32
        } -> tensor<32x?x?xf32>
        flow.dispatch.tensor.store %31, %27, offsets = [0, 0, 0], sizes = [32, %24, %24], strides = [1, 1, 1] : tensor<32x?x?xf32> -> !flow.dispatch.tensor<writeonly:tensor<32x?x?xf32>>{%24, %24}
        return
      }
    }
  }
}

@MaheshRavishankar, let me know if you can spot what's going on with the current IR or need the IR before dispatch creation/data tiling.

You know I might be seeing something similar in a different context.

Actually strike that. Is this a compile time crash or runtime crash?

Could you send the original IR? If possible, stripped IR.

I understand you don't see anything weird in the unpack op? The crash happens when running the model with that specific shape. Let me think how I can share it. The file is 27GB :). Let's see if I can remove the weights. I'll also check if I can repro the crash by running this dispatch in isolation.

I think this looks OK to me. Doesnt raise any red flags... if anything, you probably want to check the stack size this is using (I am assuming you arent disabling the stack size check, in which case its OK). Also not using microkernels, so its not something to do with bad offset calculation that could have been a possibility. So overall I dont see any red flags.

Thanks! With ukernels it doesn't even compile. This could be related to the stack though, because the shape is dynamic and it only fails with the larger input shape.

Thanks! With ukernels it doesn't even compile. This could be related to the stack though, because the shape is dynamic and it only fails with the larger input shape.

Then you should have had a compile time failure. The compile command above is not disabling the check.

I understand you don't see anything weird in the unpack op? The crash happens when running the model with that specific input shape. Let me think how I can share more IR. The file is 27GB :). Let's see if I can remove the weights. I'll also check if I can repro the crash by running this dispatch in isolation.

Maybe a mlir bytecode file would work? Maybe uploaded on cloud or somewhere? Otherwise, you could just elide the weights and send that, that is cool with me. I will just run this through iree-reduce to see if we can get something more easily understandable.

We are trying to understand some of the legal constraints in regard to some of these models right now so I wouldn't be able to share the whole model just yet.
However, after some investigation, and looking at the dumped IR, I can see that the segfault happens in the transpose op generated by the tensor.unpack. It crashes on the first load of the sequence of scalar loads generated for the transpose:
    0x7ffff7fb9094 <forward_dispatch_18_generic_32xDxD_f32+6068>    xor    %r8d,%r8d                                                                                │
│    0x7ffff7fb9097 <forward_dispatch_18_generic_32xDxD_f32+6071>    cmp    $0x8,%r14                                                                                │
│    0x7ffff7fb909b <forward_dispatch_18_generic_32xDxD_f32+6075>    jb     0x7ffff7fb9117 <forward_dispatch_18_generic_32xDxD_f32+6199>                                                                                │
│    0x7ffff7fb909d <forward_dispatch_18_generic_32xDxD_f32+6077>    nopl   (%rax)                                                                                │
│  > 0x7ffff7fb90a0 <forward_dispatch_18_generic_32xDxD_f32+6080>    vmovss -0x1c(%rax,%r8,4),%xmm0                                                                                │
│    0x7ffff7fb90a7 <forward_dispatch_18_generic_32xDxD_f32+6087>    vmovss %xmm0,-0x1c(%rdx,%r8,4)                                                                                │
│    0x7ffff7fb90ae <forward_dispatch_18_generic_32xDxD_f32+6094>    vmovss -0x18(%rax,%r8,4),%xmm0                                                                                │
│    0x7ffff7fb90b5 <forward_dispatch_18_generic_32xDxD_f32+6101>    vmovss %xmm0,-0x18(%rdx,%r8,4)                                                                                │
│    0x7ffff7fb90bc <forward_dispatch_18_generic_32xDxD_f32+6108>    vmovss -0x14(%rax,%r8,4),%xmm0                                                                                │
│    0x7ffff7fb90c3 <forward_dispatch_18_generic_32xDxD_f32+6115>    vmovss %xmm0,-0x14(%rdx,%r8,4)                                                                                │
│    0x7ffff7fb90ca <forward_dispatch_18_generic_32xDxD_f32+6122>    vmovss -0x10(%rax,%r8,4),%xmm0                                                                                │
│    0x7ffff7fb90d1 <forward_dispatch_18_generic_32xDxD_f32+6129>    vmovss %xmm0,-0x10(%rdx,%r8,4)                                                                                │
│    0x7ffff7fb90d8 <forward_dispatch_18_generic_32xDxD_f32+6136>    vmovss -0xc(%rax,%r8,4),%xmm0                                                                                │
│    0x7ffff7fb90df <forward_dispatch_18_generic_32xDxD_f32+6143>    vmovss %xmm0,-0xc(%rdx,%r8,4)                                                                                │
│    0x7ffff7fb90e6 <forward_dispatch_18_generic_32xDxD_f32+6150>    vmovss -0x8(%rax,%r8,4),%xmm0                                                                                │
│    0x7ffff7fb90ed <forward_dispatch_18_generic_32xDxD_f32+6157>    vmovss %xmm0,-0x8(%rdx,%r8,4)                                                                                │
│    0x7ffff7fb90f4 <forward_dispatch_18_generic_32xDxD_f32+6164>    vmovss -0x4(%rax,%r8,4),%xmm0                                                                                │
│    0x7ffff7fb90fb <forward_dispatch_18_generic_32xDxD_f32+6171>    vmovss %xmm0,-0x4(%rdx,%r8,4)                                                                                │
│    0x7ffff7fb9102 <forward_dispatch_18_generic_32xDxD_f32+6178>    vmovd  (%rax,%r8,4),%xmm0                                                                                │
│    0x7ffff7fb9108 <forward_dispatch_18_generic_32xDxD_f32+6184>    vmovd  %xmm0,(%rdx,%r8,4)                                                                                │
│    0x7ffff7fb910e <forward_dispatch_18_generic_32xDxD_f32+6190>    add    $0x8,%r8                                                                                │
│    0x7ffff7fb9112 <forward_dispatch_18_generic_32xDxD_f32+6194>    cmp    %r8,%r15                                                                                │
│    0x7ffff7fb9115 <forward_dispatch_18_generic_32xDxD_f32+6197>    jne    0x7ffff7fb90a0 <forward_dispatch_18_generic_32xDxD_f32+6080>

So I think it could be related to the address computation of the slice extracted from %40 = flow.dispatch.tensor.load %23, offsets = [%arg0, %38, %39, 0, 0], sizes = [16, %36, %37, 16, 16], strides = [1, 1, 1, 1, 1] : !flow.dispatch.tensor<readonly:tensor<32x2x?x16x16xf32>>{%17} -> tensor<16x?x?x16x16xf32> that end up being consumed by the transpose:
  %workgroup_id_x = hal.interface.workgroup.id[0] : index
  %workgroup_count_x = hal.interface.workgroup.count[0] : index
  %workgroup_id_y = hal.interface.workgroup.id[1] : index
  %workgroup_count_y = hal.interface.workgroup.count[1] : index
  %workgroup_id_z = hal.interface.workgroup.id[2] : index
  %workgroup_count_z = hal.interface.workgroup.count[2] : index
  %27 = affine.apply affine_map<()[s0] -> (s0 * 16)>()[%workgroup_id_z]
  %28 = affine.apply affine_map<()[s0] -> (s0 * 16)>()[%workgroup_count_z]
  scf.for %arg0 = %27 to %c32 step %28 {
    %29 = affine.apply affine_map<()[s0] -> (s0 * 64)>()[%workgroup_id_y]
    %30 = affine.apply affine_map<()[s0] -> (s0 * 64)>()[%workgroup_count_y]
    scf.for %arg1 = %29 to %22 step %30 {
      %31 = affine.min affine_map<(d0)[s0] -> (-d0 + s0, 64)>(%arg1)[%22]
      %32 = affine.apply affine_map<()[s0] -> (s0 * 64)>()[%workgroup_id_x]
      %33 = affine.apply affine_map<()[s0] -> (s0 * 64)>()[%workgroup_count_x]
      scf.for %arg2 = %32 to %22 step %33 {
        %34 = affine.min affine_map<(d0)[s0] -> (-d0 + s0, 64)>(%arg2)[%22]
        %35 = flow.dispatch.tensor.load %25, offsets = [%arg0, %arg1, %arg2], sizes = [16, %31, %34], strides = [1, 1, 1] : !flow.dispatch.tensor<writeonly:tensor<32x?x?xf32>>{%22, %22} -> tensor<16x?x?xf32>
        %36 = affine.apply affine_map<(d0) -> (d0 ceildiv 16)>(%31)
        %37 = affine.apply affine_map<(d0) -> (d0 ceildiv 16)>(%34)
        %38 = affine.apply affine_map<(d0) -> (d0 floordiv 16)>(%arg1)
        %39 = affine.apply affine_map<(d0) -> (d0 floordiv 16)>(%arg2)
        %40 = flow.dispatch.tensor.load %23, offsets = [%arg0, %38, %39, 0, 0], sizes = [16, %36, %37, 16, 16], strides = [1, 1, 1, 1, 1] : !flow.dispatch.tensor<readonly:tensor<32x2x?x16x16xf32>>{%17} -> tensor<16x?x?x16x16xf32>
        %41 = scf.for %arg3 = %c0 to %c16 step %c1 iter_args(%arg4 = %35) -> (tensor<16x?x?xf32>) {
          %42 = scf.for %arg5 = %c0 to %31 step %c16 iter_args(%arg6 = %arg4) -> (tensor<16x?x?xf32>) {
            %43 = affine.min affine_map<(d0)[s0] -> (-d0 + s0, 16)>(%arg5)[%31]
            %44 = scf.for %arg7 = %c0 to %34 step %c16 iter_args(%arg8 = %arg6) -> (tensor<16x?x?xf32>) {
              %45 = affine.min affine_map<(d0)[s0] -> (-d0 + s0, 16)>(%arg7)[%34]
              %46 = affine.apply affine_map<(d0) -> (d0 floordiv 16)>(%arg5)
              %47 = affine.apply affine_map<(d0) -> (d0 floordiv 16)>(%arg7)
              %extracted_slice = tensor.extract_slice %40[%arg3, %46, %47, 0, 0] [1, 1, 1, 16, 16] [1, 1, 1, 1, 1] : tensor<16x?x?x16x16xf32> to tensor<1x1x1x16x16xf32>
              %extracted_slice_1 = tensor.extract_slice %arg8[%arg3, %arg5, %arg7] [1, %43, %45] [1, 1, 1] : tensor<16x?x?xf32> to tensor<1x?x?xf32>
              %extracted_slice_2 = tensor.extract_slice %extracted_slice[0, 0, 0, 0, 0] [1, 1, 1, 16, 16] [1, 1, 1, 1, 1] : tensor<1x1x1x16x16xf32> to tensor<16x16xf32>
              %48 = tensor.empty() : tensor<16x16xf32>
              %transposed = linalg.transpose ins(%extracted_slice_2 : tensor<16x16xf32>) outs(%48 : tensor<16x16xf32>) permutation = [0, 1]
              %extracted_slice_3 = tensor.extract_slice %transposed[0, 0] [%43, %45] [1, 1] : tensor<16x16xf32> to tensor<?x?xf32>
              %inserted_slice = tensor.insert_slice %extracted_slice_3 into %extracted_slice_1[0, 0, 0] [1, %43, %45] [1, 1, 1] : tensor<?x?xf32> into tensor<1x?x?xf32>

There are quite a few affine.apply ops to look at but I haven't had the time just yet. I also disabled the generic vectorizer and the problem is still there so that's closing the circle even more...
It would be great if somebody else can help taking a look.

Nice find! Little bit constrained for folks here too. (But I am happy you are looking at data tiling for llama, that was on the horizon). If it helps you can disable fusion of unpack with consumers by just commenting out  the body of the if here https://github.com/openxla/iree/blob/bb51f6f1a1b4ee619fb09a7396f449dadb211447/compiler/src/iree/compiler/Dialect/Flow/Transforms/FormDispatchRegions.cpp#L491 and just returning false. At least that will side-step this issue and you can be unblocked.

@dcaballe @jpienaar @qcolombet @julianwa We probably need an assignee to help look at this one.

I'll also check if I can repro the crash by running this dispatch in isolation.

@dcaballe were you able to repro just with this dispatch?
Maybe @pzread can help?
If nobody picked it up by then, I may be able to help.
I'll sync with @dcaballe offline for how to get the model.

I had some time to investigate this a bit more.

https://github.com/openxla/iree/blob/bb51f6f1a1b4ee619fb09a7396f449dadb211447/compiler/src/iree/compiler/Dialect/Flow/Transforms/FormDispatchRegions.cpp#L491
and just returning false. At least that will side-step this issue and you can be unblocked.

Thanks! This prevents the unpack op to be fused but the execution still crashes on the (now not fused) unpack op. I've been looking at the IR dump a bit more and found something suspicious after the TileAndDistributeToWorkgroups pass. This is the IR before that pass:
module {
  func.func @forward_dispatch_18() {
    %c32_i64 = arith.constant 32 : i64
    %0 = hal.interface.constant.load[0] : i32
    %1 = hal.interface.constant.load[1] : i32
    %2 = hal.interface.constant.load[2] : i32
    %3 = hal.interface.constant.load[3] : i32
    %4 = hal.interface.constant.load[4] : i32
    %5 = hal.interface.constant.load[5] : i32
    %6 = hal.interface.constant.load[6] : i32
    %7 = hal.interface.constant.load[7] : i32
    %8 = arith.extui %0 : i32 to i64
    %9 = arith.extui %1 : i32 to i64
    %10 = arith.shli %9, %c32_i64 : i64
    %11 = arith.ori %8, %10 : i64
    %12 = arith.index_castui %11 : i64 to index
    %13 = arith.extui %2 : i32 to i64
    %14 = arith.extui %3 : i32 to i64
    %15 = arith.shli %14, %c32_i64 : i64
    %16 = arith.ori %13, %15 : i64
    %17 = arith.index_castui %16 : i64 to index
    %18 = arith.extui %4 : i32 to i64
    %19 = arith.extui %5 : i32 to i64
    %20 = arith.shli %19, %c32_i64 : i64
    %21 = arith.ori %18, %20 : i64
    %22 = arith.index_castui %21 : i64 to index
    %23 = arith.extui %6 : i32 to i64
    %24 = arith.extui %7 : i32 to i64
    %25 = arith.shli %24, %c32_i64 : i64
    %26 = arith.ori %23, %25 : i64
    %27 = arith.index_castui %26 : i64 to index
    %28 = flow.dispatch.workload.ordinal %22, 0 : index
    %29 = flow.dispatch.workload.ordinal %27, 1 : index
    %30 = hal.interface.binding.subspan set(0) binding(0) type(storage_buffer) alignment(64) offset(%12) flags(ReadOnly) : !flow.dispatch.tensor<readonly:tensor<32x2x?x16x16xf32>>{%28}
    %31 = hal.interface.binding.subspan set(0) binding(1) type(storage_buffer) alignment(64) offset(%17) : !flow.dispatch.tensor<writeonly:tensor<32x?x?xf32>>{%29, %29}
    %32 = flow.dispatch.tensor.load %30, offsets = [0, 0, 0, 0, 0], sizes = [32, 2, %28, 16, 16], strides = [1, 1, 1, 1, 1] : !flow.dispatch.tensor<readonly:tensor<32x2x?x16x16xf32>>{%28} -> tensor<32x2x?x16x16xf32>
    %33 = tensor.empty(%29, %29) : tensor<32x?x?xf32>
    %unpack = tensor.unpack %32 inner_dims_pos = [1, 2] inner_tiles = [16, 16] into %33 : tensor<32x2x?x16x16xf32> -> tensor<32x?x?xf32>
    flow.dispatch.tensor.store %unpack, %31, offsets = [0, 0, 0], sizes = [32, %29, %29], strides = [1, 1, 1] : tensor<32x?x?xf32> -> !flow.dispatch.tensor<writeonly:tensor<32x?x?xf32>>{%29, %29}
    return
  }
}

If we look at %32 = flow.dispatch.tensor.load %30, offsets = [0, 0, 0, 0, 0], sizes = [32, 2, %28, 16, 16], strides = [1, 1, 1, 1, 1] : !flow.dispatch.tensor<readonly:tensor<32x2x?x16x16xf32>>{%28} -> tensor<32x2x?x16x16xf32>, we pass a constant 0 and 2 for the offset and size of the second dimension. That seems correct as the actual dim size of the tensor is 2.
However, after tiling and distributing:
--- After Tile + Distribute ---
func.func @forward_dispatch_18() {
  %c32 = arith.constant 32 : index
  %c2 = arith.constant 2 : index
  %c1 = arith.constant 1 : index
  %c32_i64 = arith.constant 32 : i64
  %0 = hal.interface.constant.load[0] : i32
  %1 = hal.interface.constant.load[1] : i32
  %2 = hal.interface.constant.load[2] : i32
  %3 = hal.interface.constant.load[3] : i32
  %4 = hal.interface.constant.load[4] : i32
  %5 = hal.interface.constant.load[5] : i32
  %6 = hal.interface.constant.load[6] : i32
  %7 = hal.interface.constant.load[7] : i32
  %8 = arith.extui %0 : i32 to i64
  %9 = arith.extui %1 : i32 to i64
  %10 = arith.shli %9, %c32_i64 : i64
  %11 = arith.ori %8, %10 : i64
  %12 = arith.index_castui %11 : i64 to index
  %13 = arith.extui %2 : i32 to i64
  %14 = arith.extui %3 : i32 to i64
  %15 = arith.shli %14, %c32_i64 : i64
  %16 = arith.ori %13, %15 : i64
  %17 = arith.index_castui %16 : i64 to index
  %18 = arith.extui %4 : i32 to i64
  %19 = arith.extui %5 : i32 to i64
  %20 = arith.shli %19, %c32_i64 : i64
  %21 = arith.ori %18, %20 : i64
  %22 = arith.index_castui %21 : i64 to index
  %23 = arith.extui %6 : i32 to i64
  %24 = arith.extui %7 : i32 to i64
  %25 = arith.shli %24, %c32_i64 : i64
  %26 = arith.ori %23, %25 : i64
  %27 = arith.index_castui %26 : i64 to index
  %28 = hal.interface.binding.subspan set(0) binding(0) type(storage_buffer) alignment(64) offset(%12) flags(ReadOnly) : !flow.dispatch.tensor<readonly:tensor<32x2x?x16x16xf32>>{%22}
  %29 = hal.interface.binding.subspan set(0) binding(1) type(storage_buffer) alignment(64) offset(%17) : !flow.dispatch.tensor<writeonly:tensor<32x?x?xf32>>{%27, %27}
  %30 = tensor.empty(%27, %27) : tensor<32x?x?xf32>
  %dim = tensor.dim %30, %c1 : tensor<32x?x?xf32>
  %dim_0 = tensor.dim %30, %c2 : tensor<32x?x?xf32>
  %workgroup_id_x = hal.interface.workgroup.id[0] : index
  %workgroup_count_x = hal.interface.workgroup.count[0] : index
  %workgroup_id_y = hal.interface.workgroup.id[1] : index
  %workgroup_count_y = hal.interface.workgroup.count[1] : index
  %workgroup_id_z = hal.interface.workgroup.id[2] : index
  %workgroup_count_z = hal.interface.workgroup.count[2] : index
  %31 = affine.apply affine_map<()[s0] -> (s0 * 64)>()[%workgroup_id_z]
  %32 = affine.apply affine_map<()[s0] -> (s0 * 64)>()[%workgroup_count_z]
  scf.for %arg0 = %31 to %c32 step %32 {
    %33 = affine.min affine_map<(d0) -> (64, -d0 + 32)>(%arg0)
    %34 = affine.apply affine_map<()[s0] -> (s0 * 64)>()[%workgroup_id_y]
    %35 = affine.apply affine_map<()[s0] -> (s0 * 64)>()[%workgroup_count_y]
    scf.for %arg1 = %34 to %dim step %35 {
      %36 = affine.min affine_map<(d0)[s0] -> (64, -d0 + s0)>(%arg1)[%dim]
      %37 = affine.apply affine_map<()[s0] -> (s0 * 64)>()[%workgroup_id_x]
      %38 = affine.apply affine_map<()[s0] -> (s0 * 64)>()[%workgroup_count_x]
      scf.for %arg2 = %37 to %dim_0 step %38 {
        %39 = affine.min affine_map<(d0)[s0] -> (64, -d0 + s0)>(%arg2)[%dim_0]
        %40 = affine.apply affine_map<(d0) -> (d0 ceildiv 16)>(%36)
        %41 = affine.apply affine_map<(d0) -> (d0 ceildiv 16)>(%39)
        %42 = affine.apply affine_map<(d0) -> (d0 floordiv 16)>(%arg1)
        %43 = affine.apply affine_map<(d0) -> (d0 floordiv 16)>(%arg2)
        %44 = flow.dispatch.tensor.load %28, offsets = [%arg0, %42, %43, 0, 0], sizes = [%33, %40, %41, 16, 16], strides = [1, 1, 1, 1, 1] : !flow.dispatch.tensor<readonly:tensor<32x2x?x16x16xf32>>{%22} -> tensor<?x?x?x16x16xf32>
        %45 = tensor.empty(%33, %36, %39) : tensor<?x?x?xf32>
        %unpack = tensor.unpack %44 inner_dims_pos = [1, 2] inner_tiles = [16, 16] into %45 {lowering_config = #iree_codegen.lowering_config<tile_sizes = [[64, 64, 64], [1, 16, 16]]>} : tensor<?x?x?x16x16xf32> -> tensor<?x?x?xf32>
        %46 = arith.extui %6 : i32 to i64
        %47 = arith.extui %7 : i32 to i64
        %48 = arith.shli %47, %c32_i64 : i64
        %49 = arith.ori %46, %48 : i64
        %50 = arith.index_castui %49 : i64 to index
        flow.dispatch.tensor.store %unpack, %29, offsets = [%arg0, %arg1, %arg2], sizes = [%33, %36, %39], strides = [1, 1, 1] : tensor<?x?x?xf32> -> !flow.dispatch.tensor<writeonly:tensor<32x?x?xf32>>{%50, %50}
      }
    }
  }
  return
}

We pass %42 and %40 as offset and size for the second dimensions. These values depend on the newly introduced loop     scf.for %arg1 = %34 to %dim step %35, where %dim comes from:
  %30 = tensor.empty(%27, %27) : tensor<32x?x?xf32>
  %dim = tensor.dim %30, %c1 : tensor<32x?x?xf32>

I'm not sure how the constant 0 and 2 offset and size of an input tensor load end up depending on the dynamic dimension of a tensor.empty operation.
Then, if we look at how that dimension (%27) is computed:
  %6 = hal.interface.constant.load[6] : i32
  %7 = hal.interface.constant.load[7] : i32

  %23 = arith.extui %6 : i32 to i64
  %24 = arith.extui %7 : i32 to i64
  %25 = arith.shli %24, %c32_i64 : i64    <==== !!!!
  %26 = arith.ori %23, %25 : i64
  %27 = arith.index_castui %26 : i64 to index

We are shifting left by 32, which would result in a pretty large number (unless %24 is zero). That dimension has size 2 so that might explain the OOB read...
Thoughts? @MaheshRavishankar

I briefly talked to Mahesh, and he mentioned that there might be a bug in the tiling interface implementation of unpack op. This implementation is at mlir/lib/Dialect/Tensor/IR/TensorTilingInterfaceImpl.cpp

Quick update here: Not much progress, but I found and fixed a bug in the lowering of tensor.unpack. (See https://github.com/llvm/llvm-project/pull/68423)
I don't believe this is what we hit here though.
@bviyer is helping on this issue too now.
If it is not fixed by then, I may be able to help again starting next Friday.

Hi @bviyer - Did you make any progress on this?

FYI, I will help take a look at it since I implemented most of unpack things. I will get into this early next week.

FYI, I will help take a look at it since I implemented most of unpack things. I will get into this early next week.

Sounds good @hanhanW!
I don't expect to have time for this before Wednesday, so you'll beat me at it :).
Let me know if you need help.

The shifting left by 32 is not introduced by distribution. They indicate to the size of unpacked dimension. They are introduced before the start of codegen (maybe flow level?) If shifting left by 32 is an issue, something might be off on flow side.
Can you dump and attach input traces for forward_dispatch_18? So we can try to reproduce it just with this dispatch?

Thanks, @hanhanW! The IR dump is here: https://gist.github.com/dcaballe/00caafef75fa568745d9b0572d947585. What do you mean by input traces? We haven't been able to run the dispatch in isolation because it has dynamic shapes and the extract executable benchmark doesn't support them. Happy to follow any instructions to get what you need.
I think @bviyer had some findings to share from last week that I don't see here. Would you mind posting them here in case they are useful for Hanhan? Thanks!

HI @hanhanW, I briefly looked into this bug and this is what I came across. This may (or may not) be useful as this is just a data-point:
@qcolombet mentioned that it passes fine then the sizes less than or equal to  48 (e.g. --input=1x48xi64) but fail on  49 or above (e.g. --input=1x49xi64). I tried to dump output with both cases and I found that things went wrong in the SetEncoding pass. When I dug in further, I saw that when you disable the "SetBatchMatmul" pattern, the whole thing works. I dug a bit further (but couldn't get more) . I think there is some issue in handling unknown tensor sizes in the padAndSetEncoding() function. I didn't get time to dig further and get more concrete evidence.

Good find! Can you attach the MLIR file and command so I can try to repro it locally? Thank you!

I think it's the same dispatch and flags shared above. You should add --compile-from=executable-sources to compile that dispatch only.

are we any closer on solving this issue?

What would the runtime flags be? I tried --function=forward_dispatch_26 and forward_dispatch_26_generic_32xDxD_f32, but they all complain about function with the given name not found;.

@dcaballe sent me the file, thanks! I'm able to reproduce it locally. I will take a deeper look tomorrow.

It looks like a bug in batch_matmul. I am able to run the model if I disable SetEncoding on batch_matmul. I.e., remove the SetBatchMatmulEncoding pattern from SetEncodingPass. Trying to reduce the reproducer now...
https://github.com/openxla/iree/blob/05928c502339d33d27262f577f900b59f2f6dfac/compiler/src/iree/compiler/GlobalOptimization/SetEncoding.cpp#L331C6-L335

I found a bug in materialization patterns, preparing a fix and testing now.

#map = affine_map<()[s0, s1] -> ((s1 ceildiv s0) * s0)>
func.func @pack_batch_matmul_fill_partial_dynamic(%arg0: tensor<16x?x4096xf32>, %arg1: tensor<16x4096x4096xf32>) -> tensor<16x?x4096xf32> {
  %c16 = arith.constant 16 : index
  %c8 = arith.constant 8 : index
  %c0 = arith.constant 0 : index
  %c1 = arith.constant 1 : index
  %c4096 = arith.constant 4096 : index
  %cst = arith.constant 0.000000e+00 : f32
  %dim = tensor.dim %arg0, %c1 : tensor<16x?x4096xf32>
  %0 = iree_linalg_ext.set_encoding %arg0 : tensor<16x?x4096xf32> -> tensor<16x?x4096xf32, #iree_linalg_ext.encoding<user = BATCH_MATMUL, role = LHS, element_types = [f32, f32, f32], original_type = tensor<16x?x4096xf32>>>
  %1 = iree_linalg_ext.set_encoding %arg1 : tensor<16x4096x4096xf32> -> tensor<16x4096x4096xf32, #iree_linalg_ext.encoding<user = BATCH_MATMUL, role = RHS, element_types = [f32, f32, f32], original_type = tensor<16x4096x4096xf32>>>
  %2 = affine.apply #map()[%c8, %dim]
  %3 = tensor.empty(%c16, %2, %c4096) : tensor<?x?x?xf32, #iree_linalg_ext.encoding<user = BATCH_MATMUL, role = RESULT, element_types = [f32, f32, f32], original_type = tensor<16x?x4096xf32>>>
  %4 = linalg.fill ins(%cst : f32) outs(%3 : tensor<?x?x?xf32, #iree_linalg_ext.encoding<user = BATCH_MATMUL, role = RESULT, element_types = [f32, f32, f32], original_type = tensor<16x?x4096xf32>>>) -> tensor<?x?x?xf32, #iree_linalg_ext.encoding<user = BATCH_MATMUL, role = RESULT, element_types = [f32, f32, f32], original_type = tensor<16x?x4096xf32>>>
  %5 = linalg.batch_matmul ins(%0, %1 : tensor<16x?x4096xf32, #iree_linalg_ext.encoding<user = BATCH_MATMUL, role = LHS, element_types = [f32, f32, f32], original_type = tensor<16x?x4096xf32>>>, tensor<16x4096x4096xf32, #iree_linalg_ext.encoding<user = BATCH_MATMUL, role = RHS, element_types = [f32, f32, f32], original_type = tensor<16x4096x4096xf32>>>) outs(%4 : tensor<?x?x?xf32, #iree_linalg_ext.encoding<user = BATCH_MATMUL, role = RESULT, element_types = [f32, f32, f32], original_type = tensor<16x?x4096xf32>>>) -> tensor<?x?x?xf32, #iree_linalg_ext.encoding<user = BATCH_MATMUL, role = RESULT, element_types = [f32, f32, f32], original_type = tensor<16x?x4096xf32>>>
  %6 = iree_linalg_ext.unset_encoding %5 : tensor<?x?x?xf32, #iree_linalg_ext.encoding<user = BATCH_MATMUL, role = RESULT, element_types = [f32, f32, f32], original_type = tensor<16x?x4096xf32>>> -> tensor<?x?x?xf32>
  %extracted_slice = tensor.extract_slice %6[0, 0, 0] [16, %dim, 4096] [1, 1, 1] : tensor<?x?x?xf32> to tensor<16x?x4096xf32>
  return %extracted_slice : tensor<16x?x4096xf32>
}

The bug is in EmptyOp materialization pattern. It does not infer correct sizes for the new tensor.empty op. https://github.com/openxla/iree/pull/15359 fixes the logic, so they can be inferred correctly.
To repro the bug: iree-opt --iree-linalg-ext-materialize-encoding repro.mlir, it generates:
#map = affine_map<()[s0] -> (s0 ceildiv 8)>
module {
  func.func @foo(%arg0: tensor<16x?x4096xf32>, %arg1: tensor<16x4096x4096xf32>) -> tensor<16x?x4096xf32> {
    %c2 = arith.constant 2 : index
    %c1 = arith.constant 1 : index
    %cst = arith.constant 0.000000e+00 : f32
    %dim = tensor.dim %arg0, %c1 : tensor<16x?x4096xf32>
    %0 = affine.apply #map()[%dim]
    %1 = tensor.empty(%0) : tensor<16x?x1024x8x4xf32>
    %pack = tensor.pack %arg0 inner_dims_pos = [1, 2] inner_tiles = [8, 4] into %1 : tensor<16x?x4096xf32> -> tensor<16x?x1024x8x4xf32>
    %2 = tensor.empty() : tensor<16x512x1024x8x4xf32>
    %pack_0 = tensor.pack %arg1 outer_dims_perm = [0, 2, 1] inner_dims_pos = [2, 1] inner_tiles = [8, 4] into %2 : tensor<16x4096x4096xf32> -> tensor<16x512x1024x8x4xf32>
    %3 = tensor.empty(%c2) : tensor<16x?x512x8x8xf32>
    %4 = linalg.fill ins(%cst : f32) outs(%3 : tensor<16x?x512x8x8xf32>) -> tensor<16x?x512x8x8xf32>
    %5 = linalg.batch_mmt4d ins(%pack, %pack_0 : tensor<16x?x1024x8x4xf32>, tensor<16x512x1024x8x4xf32>) outs(%4 : tensor<16x?x512x8x8xf32>) -> tensor<16x?x512x8x8xf32>
    %6 = tensor.empty(%dim) : tensor<16x?x4096xf32>
    %unpack = tensor.unpack %5 inner_dims_pos = [1, 2] inner_tiles = [8, 8] into %6 : tensor<16x?x512x8x8xf32> -> tensor<16x?x4096xf32>
    return %unpack : tensor<16x?x4096xf32>
  }
}

The %3 = tensor.empty(%c2) : tensor<16x?x512x8x8xf32> is wrong.


Saleor 3391 tests for staff members

I want to merge this change because I created tests for staff users

PR intended to be tested with API branch:
Screenshots

Pull Request Checklist

[ ] This code contains UI changes
[ ] All visible strings are translated with proper context including data-formatting
[ ] Attributes [data-test-id] are added for new elements
[ ] Changes are mentioned in the changelog
[ ] The changes are tested in different browsers and in light/dark mode

Test environment config

API_URI=https://qa.staging.saleor.cloud/graphql/

Task linked: SALEOR-3391 Create tests for staff members


Improve bt_device object to include more details about the device

Including bt_device object to have firmware version, and firmware details as part of the object, instead of separate preferences, ideally includes bootloader, fwver, etc.

Should we change the device type from friend to devKit1?

There are two different objects basically holding the same information to an extent. And both of them are dependent on each other.
class DeviceInfo {
  String modelNumber;
  String firmwareRevision;
  String hardwareRevision;
  String manufacturerName;
  DeviceType type;
  }

The DeviceInfo object has methods to read characteristics to get data like the firmware version, hardware name etc., But it depends on BtDeviceStruct to differentiate between device type using the type property. And in many places in the code, both of them are being used together.
class BTDeviceStruct {
String name;
String id;
int? rssi;
List<int>? fwver;
DeviceType? type;
}

Both of them can be combined together to have a unified object for device details.
 class BtDevice {
   String name;
   String id;
   int? rssi;
   DeviceType type;
   BtDeviceInfo? btDeviceInfo;
  }

class BtDeviceInfo {
 String modelNumber;
 String firmwareRevision;
 String hardwareRevision;
 String manufacturerName;
 }

The BtDevice will also includes methods to convert BluetoothDevice (from flutter_blue_plus) to BtDevice etc., apart from the already existing methods, getters and setters. The BtDeviceInfo is basically DeviceInfo but renamed to DeviceInfo

Closing it as it has been clubbed with #828


'QuerySetSequence' object has no attribute '_cloning'

I'm getting an exception when using QuerySetSequence with django-cacheops:
>>> from models import TestModel
>>> from queryset_sequence import QuerySetSequence
>>> q = QuerySetSequence(TestModel.objects.all())
>>> q.all()
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/usr/local/lib/python3.5/site-packages/django/db/models/query.py", line 777, in all
    return self._clone()
  File "/usr/local/lib/python3.5/site-packages/cacheops/query.py", line 227, in _clone
    if self._cloning:
  File "/usr/local/lib/python3.5/site-packages/queryset_sequence/_inheritance.py", line 71, in __getattribute__
    (name, attr))
AttributeError: 'QuerySetSequence' object has no attribute '_cloning'

Cacheops monkeypatches QuerySet and adds some new properties and methods to it: https://github.com/Suor/django-cacheops/blob/master/cacheops/query.py#L542
What I'm trying to achieve is autocomplete field for GenericForeignKey using django-autocomplete-light (https://django-autocomplete-light.readthedocs.io/en/master/gfk.html), but with caching.
I have tried to add '_cloning' and other patched fields to QuerySetSequence's descendant INHERITED_ATTRS, but with no result.
Could you propose a workaround for it?

👎 for monkey patching, but that doesn't fix your problem.
I'd expect that adding them to INHERITED_ATTRS would work, how are you attempting to modify that? Because of the implementation it pulls this property at creation time and uses it inside of a scoped function (see https://github.com/percipient/django-querysetsequence/blob/0c5d4db627e087de2020654e13cf239c11bf3f20/queryset_sequence/_inheritance.py#L29-L30 and https://github.com/percipient/django-querysetsequence/blob/0c5d4db627e087de2020654e13cf239c11bf3f20/queryset_sequence/_inheritance.py#L54-L72), which might make it hard to modify. I hadn't really considered something wanting to modify those.

Thanks for the explanations. If I understand right, the inheritance dosn't help me with modifying INHERITED_ATTRS. I tried to modify them inplace, but there are too many other methods and properties to add to QuerySet and QuerySetSequence.
I created an issue in cacheops: https://github.com/Suor/django-cacheops/issues/259


Sierra hang

After updating my MacBook to Sierra, I got a new hang that I don't think I've seen before:
Date/Time:       2016-10-17 20:19:06 +1300
OS Version:      Mac OS X 10.12 (Build 16A323)
Architecture:    x86_64
Report Version:  25

Data Source:     Stackshots

Command:         Quicksilver
Path:            /Applications/Quicksilver.app/Contents/MacOS/Quicksilver
Version:         1.4.2 (401A)
Parent:          launchd [1]
PID:             1410

Event:           hang
Duration:        0.99s (process was unresponsive for 13107 seconds before sampling)
Steps:           10 (100ms sampling interval)

Hardware model:  MacBookPro9,2
Active cpus:     4

Fan speed:       1997 rpm

--------------------------------------------------
Timeline format: stacks are sorted chronologically
Use -i and -heavy to re-report with count sorting
--------------------------------------------------

Heaviest stack for the main thread of the target process:
  10  start + 1 (libdyld.dylib + 21077) [0x7fffcf491255]
  10  NSApplicationMain + 1237 (AppKit + 27274) [0x7fffb8015a8a]
  10  -[NSApplication run] + 926 (AppKit + 245693) [0x7fffb804afbd]
  10  -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1637 (AppKit + 7698667) [0x7fffb87668eb]
  10  _DPSNextEvent + 1093 (AppKit + 292341) [0x7fffb80565f5]
  10  _BlockUntilNextEventMatchingListInModeWithFilter + 71 (HIToolbox + 199638) [0x7fffb995fbd6]
  10  ReceiveNextEventCommon + 432 (HIToolbox + 200097) [0x7fffb995fda1]
  10  RunCurrentEventLoopInMode + 240 (HIToolbox + 200556) [0x7fffb995ff6c]
  10  CFRunLoopRunSpecific + 420 (CoreFoundation + 542836) [0x7fffba3bf874]
  10  __CFRunLoopRun + 1894 (CoreFoundation + 545334) [0x7fffba3c0236]
  10  __CFRunLoopDoBlocks + 356 (CoreFoundation + 546548) [0x7fffba3c06f4]
  10  __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 12 (CoreFoundation + 672716) [0x7fffba3df3cc]
  10  ___LSScheduleNotificationFunction_block_invoke_2 + 51 (LaunchServices + 104213) [0x7fffbb58f715]
  10  HIToolboxLSNotificationCallbackAllASNsFunc + 571 (HIToolbox + 631870) [0x7fffb99c943e]
  10  SendEventToEventTargetWithOptions + 43 (HIToolbox + 33167) [0x7fffb993718f]
  10  SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 428 (HIToolbox + 33606) [0x7fffb9937346]
  10  DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1708 (HIToolbox + 37077) [0x7fffb99380d5]
  10  ??? (<B49A61DD-1113-3ED1-A23C-B9FADC304D9A> + 242331) [0x10c6f429b]
  10  -[NSNotificationCenter postNotificationName:object:userInfo:] + 66 (Foundation + 28899) [0x7fffbbdc00e3]
  10  _CFXNotificationPost + 667 (CoreFoundation + 358939) [0x7fffba392a1b]
  10  -[_CFXNotificationRegistrar find:object:observer:enumerator:] + 2018 (CoreFoundation + 363058) [0x7fffba393a32]
  10  ___CFXNotificationPost_block_invoke + 50 (CoreFoundation + 631570) [0x7fffba3d5312]
  10  _CFXRegistrationPost + 427 (CoreFoundation + 632235) [0x7fffba3d55ab]
  10  __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12 (CoreFoundation + 632492) [0x7fffba3d56ac]
  10  ??? (<B49A61DD-1113-3ED1-A23C-B9FADC304D9A> + 245383) [0x10c6f4e87]
  10  -[NSObject(NSKeyValueObserverNotification) didChangeValueForKey:] + 118 (Foundation + 75062) [0x7fffbbdcb536]
  10  NSKeyValueDidChange + 486 (Foundation + 276052) [0x7fffbbdfc654]
  10  NSKeyValueNotifyObserver + 350 (Foundation + 277949) [0x7fffbbdfcdbd]
  10  ??? (<B49A61DD-1113-3ED1-A23C-B9FADC304D9A> + 253412) [0x10c6f6de4]
  10  ??? (<B49A61DD-1113-3ED1-A23C-B9FADC304D9A> + 253506) [0x10c6f6e42]
  10  ??? (<B49A61DD-1113-3ED1-A23C-B9FADC304D9A> + 191435) [0x10c6e7bcb]
  10  -[NSNotificationCenter postNotificationName:object:userInfo:] + 66 (Foundation + 28899) [0x7fffbbdc00e3]
  10  _CFXNotificationPost + 667 (CoreFoundation + 358939) [0x7fffba392a1b]
  10  -[_CFXNotificationRegistrar find:object:observer:enumerator:] + 2018 (CoreFoundation + 363058) [0x7fffba393a32]
  10  ___CFXNotificationPost_block_invoke + 50 (CoreFoundation + 631570) [0x7fffba3d5312]
  10  _CFXRegistrationPost + 427 (CoreFoundation + 632235) [0x7fffba3d55ab]
  10  __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12 (CoreFoundation + 632492) [0x7fffba3d56ac]
  10  ??? (<B49A61DD-1113-3ED1-A23C-B9FADC304D9A> + 77218) [0x10c6cbda2]
  10  ??? (<B49A61DD-1113-3ED1-A23C-B9FADC304D9A> + 27801) [0x10c6bfc99]
  10  ??? (<B49A61DD-1113-3ED1-A23C-B9FADC304D9A> + 26207) [0x10c6bf65f]
  10  _dispatch_barrier_sync_f_slow + 402 (libdispatch.dylib + 54762) [0x7fffcf4665ea]
  10  _dispatch_thread_event_wait_slow + 85 (libdispatch.dylib + 109678) [0x7fffcf473c6e]
  10  __ulock_wait + 10 (libsystem_kernel.dylib + 107446) [0x7fffcf5c03b6]
 *10  hndl_unix_scall64 + 22 (kernel + 696134) [0xffffff80002a9f46]
 *10  unix_syscall64 + 582 (kernel + 6464358) [0xffffff800082a366]
 *10  ulock_wait + 993 (kernel + 5944129) [0xffffff80007ab341]
 *10  thread_block_reason + 222 (kernel + 1111278) [0xffffff800030f4ee]
 *10  ??? (kernel + 1115851) [0xffffff80003106cb]
 *10  machine_switch_context + 206 (kernel + 2118942) [0xffffff800040551e]

Process:         Quicksilver [1410]
Path:            /Applications/Quicksilver.app/Contents/MacOS/Quicksilver
Architecture:    x86_64
Parent:          launchd [1]
UID:             503
Task size:       171 MB
CPU Time:        <0.001
Note:            Unresponsive for 13107 seconds before sampling
Note:            3 idle work queue threads omitted

Full details at https://gist.github.com/danielcompton/fbf8177775bc886fa1c832eae86f721e

I'm not sure if my problems are related but I've been having a lot of latency issues triggering quicksilver since my Sierra upgrade, sometimes a few seconds before it will come up. This morning I noticed quicksilver up there with Chrome in my battery usage too.

Maybe related as well:  i'm having similar lagginess / crashiness but on El Capitan 10.11.8, with QS 1.4.2 (401A).
Symptoms:  On startup i can trigger QS once.  On subsequent trigger QS no longer responds.  Maybe 2 to 3 minutes later the pane pops up.  At other times the pane never pops up and i can see in Activity Monitor that QS is Not Responding and must be force quit.  So essentially unusable.
I can't say for sure WHEN this began, it's been a while though.  Perhaps since upping to OS X 10.11.
Not too much in Console.app to indicate what's happening:
12/13/16 9:37:16.091 AM Quicksilver[14604]: Unknown error calling sqlite3_step (11: database disk image is malformed) rs
12/13/16 10:03:40.272 AM Quicksilver[14604]: assertion failed: 15G1108: libxpc.dylib + 78286 [54D1328E-054E-3DAA-89E2-375722F9D18F]: 0x87

The gist indicates that there’s something related to disk mounting going on. Do you have any Event Triggers for “Disk Mounted” or “Disk Ejected”? Is QS indexing anything on an external drive?

This is a weird gist actually. The Binary Image section makes me think we're not even fully started, but maybe that's a red herring... Also, would be nice to know what B49A61DD-1113-3ED1-A23C-B9FADC304D9A refers to, in case that's not our code...

This is for 1.4.2:
% dwarfdump --uuid Quicksilver.app/Contents/MacOS/Quicksilver
UUID: 8E3D64D5-EA74-306B-8DD7-ECEBC6E10DFE (x86_64) Quicksilver.app/Contents/MacOS/Quicksilver

Each plug-in has its own binary or course, but none of them are loaded. That is weird.

find ~/Library/Application\ Support/Quicksilver/PlugIns  -type f -perm +111 -print -exec dwarfdump --uuid {} 2&>1 \; | grep B49A61DD-1113-3ED1-A23C-B9FADC304D9A ?
This gives me no results here (caveat, I'm still on 10.11). Maybe try against /Applications ?

Give this test build a try and let me know if it’s any better. The version should show as “1.5.2:mine”.
https://cl.ly/0c3v0M031t3L

@danielcompton  - we haven't heard back from you in a while, so we're going to close this. Hopefully the latest build fixed this for you!


Add process to clean out stagnate files

While Attachments Portlet hydrates files, there does not seem to be process to remove files that are no longer in use. A process should be developed where attachments that have not been accessed in long period (i.e. 30 days) are deleted.

I assume you mean "from the file system?"  (not the database)


Can't do a type assertion on an empty array with a branded type.

Bug Report

🔎 Search Terms

type assertion
branded type
empty array

🕗 Version & Regression Information
Every version.
⏯ Playground Link
Playground link with relevant code
💻 Code

export type Foo = number & {__brand__: 'foo'};
const a = 3 as Foo; // OK

export type Bar =  Array<number|string> &{ __brand__: 'bar'; }
const createOpCodes = [] as Bar; // KO

🙁 Actual behavior
const createOpCodes = [] as Bar;
throws :
Conversion of type 'never[]' to type 'Bar' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first.
🙂 Expected behavior
Should work fine without having to resort to a intermediate assertion like const createOpCodes = [] as unknown[] as Bar;

This follows pretty directly from the rules about which assertions are and aren't allowed. Is there something different about this case in particular, or are you just saying all assertions should always be allowed?

@RyanCavanaugh Perhaps if [] is being asserted, it should have the contextual type of unknown[] instead of never[] to allow it to be downcasted to a branded type?


Improved verbosity in case of unexpected errors.

Issue
In case of certain unexpected errors, more information about the errors can be gained by printing out the body of the error that contains the root cause.  This PR is to understand if something similar can be done to provide more information in case of certain errors or whether this has been discussed before.
Reproducing the issue
While using buildkit, that, in turn uses containerd, we see that when it tries to push an image to a registry where the quota has been met, we get a simple message - 403 unexpected error from containerd. However, on further inspections, we can see that the error body contains more information about the error that can help the user. To reproduce the issue, we try pushing to a registry that has been filled up (most registries have quotas).
Fix
One possible fix could be to do what I have done in the PR. However, there are other options too. I am looking for some feedback on this topic to mitigate this pain point. I have attached screenshots of how similar changes can help users get to the root cause more easily. In case the error code is 403, generally there is a reason why the request has been denied and the body should hold more answers.
Current error message

Much more helpful message

Thanks, but please sign the commit for DCO
https://github.com/apps/dco
(run git commit -a -s --amend, and make sure that the Signed-off-by: NAME <EMAIL> line with your real name is included in the commit message)

For debugging the raw request bodies, a proxy should be used. We want to prevent dumping any raw body to error messages. It is worth looking into why these particular errors don't run through the error parse code which would give you the information you are looking for (https://github.com/containerd/containerd/blob/main/remotes/docker/errcode.go)

@AkihiroSuda Thanks a lot for your help.
@dmcgowan Thanks a lot for your prompt response. I will look into why this particular message isn't getting parsed like it should. I understand that we would not want to dump the entire message. I will get back to this thread once i have more information as to why this might be happening.


[SP-10245] cannot access message of undefined

ran this against the API tests and everything passed.


FixedPoint operations have a few problems

It does not seem possible to express a Fixed with a negative binaryPoint
Multiplication should not shift either argument
Other problems to come

I just pushed a new test FixePointMathSpec that fails on a number of the problems.
There may be some problems in test with subtraction

Just want to make a note here -- for the purposes of range propagation, +%, -% range should expand to next power of 2 - 1. I didn't do that in my old ChiselDSP stuff.

I added a new Issue 255 for Range Propagation and put this comment there
too.
Chick Markley
Staff Programmer -- Aspire Lab
University of California, Berkeley
583-2 Soda Hall, Berkeley, CA 94720-1776
<EMAIL_ADDRESS>On Mon, Aug 29, 2016 at 6:25 PM, Angie Wang<EMAIL_ADDRESS>wrote:

Just want to make a note here -- for the purposes of range propagation,
+%, -% range should expand to next power of 2 - 1. I didn't do that in my
old ChiselDSP stuff.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ucb-bar/firrtl/issues/254#issuecomment-243306372, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA4WV8VkvTt-IC1EIyuZ45zBIgKr_-Ieks5qk4Z0gaJpZM4JufN2
.


Missing Photo

https://openbenches.org/bench/1166
Photo has Tweeted though....
https://twitter.com/openbenches/status/898455323543056384

Discussion
https://twitter.com/isleofmandan/status/898457160446869504
Looks like both photos were attached to 1164. Which was then unpublished.
1166 was published with no photo.
Bug in editing?

Caused by editing then uploading a duplicate https://twitter.com/isleofmandan/status/898495968710184960


DET-9 Update AWS SDK and Joda-Time dependencies

Using Java 8 with older dependencies has issues concerning signed AWS requests.
Signed-off-by: Steffan Westcott<EMAIL_ADDRESS>

Yes i can confirm that is the latest SDK go when your ready


Log4j2 MetricsAppender is not detected

We can apply the log4j-core module as an annotation processor to metrics-log4j2 in order to avoid setting a package in the log4j2 configuration.
This creates a discoverable META-INF/org/apache/logging/log4j/core/config/plugins/Log4j2Plugins.dat resource to allow plugins to be discovered at runtime.

@arteam @dhatanian did you mean to reference and close #1355? I don’t think this issue is fixed.

@carterkozak no apologies, I must have referenced the wrong issue number when writing that commit.
The issue I meant to refer is #1355


Update all programming examples with tilize/untilize

This is one of the prog examples that's missing utilize / untilize:
https://github.com/tenstorrent-metal/tt-metal/blob/main/tt_metal/programming_examples/eltwise_sfpu/eltwise_sfpu.cpp

fyi @SeanNijjar and @mbahnasTT

I spent a bit of time to update the code samples to add tilize and cleaned up a few other small things. Tomorrow I'm going to figure out my tokens and review the PR process.


Fix Config Loading (NWB Inspector)

This PR ensures that the DANDI configuration is directly passed to the NWB Inspector, instead of the related "dandi" key.
This fixes the following error when attempting to run the Inspector:

@garrettmflynn Oh geez, sorry about that. 100% my fault for forgetting the API for those downstream ones don't take the simple string


Use Cajita particle grid communication

Replace internal functionality with Cajita

Waiting on https://github.com/ECP-copa/Cabana/pull/443


TS2322: Type 'number' is not assignable to type 'Timer'.

Depending on the context (browser or Node), setTimeout returns a
different type.
Here we ruse the ReturnType of setTimeout instead of NodeJS.Timeout.
See: https://nodejs.org/api/timers.html#timers_settimeout_callback_delay_args
See: https://developer.mozilla.org/en-US/docs/Web/API/setTimeout

That's pretty clever, I didn't know about that API

Still works in nodejs mode. Thanks @goneri!


CSS Suggestion Hover Effect overlaps with scrollbar

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version: Visual Studio Code Version 1.70.2
OS Version: Windows 10

Steps to Reproduce:
When I explain this I am going to use CSS as an example!

Open Visual Studio Code
Create a CSS (Cascading Style Sheets) File
foo
Let it open up the suggestion section
Use arrow or Cursor pointer to hover over a suggestion

Here's an image of what I mean!

I haven't tested it with any other Code Languages, I'm just aware it exists on CSS

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.70.2. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

Updated comment to fix mistake in version.
Set to 1.70.2, forgot the 0 :c

Our scrollbars are transparent and overlay the contents they scroll


Main config parameters are applied to all Multiple domain tracking entries

Description
When configuring Multiple domain tracking, all parameters given to the main config are applied to the other includes as well. Even with overriding the params in the config for the other domain(s).
Expected behavior
I believe the params should only be applied to the given domains.
Actual behavior
When configuring Multiple domain tracking, all parameters given to the main config are applied to the other includes as well. Even with overriding the params in the config for the other domain(s).
Environment
<EMAIL_ADDRESS>
Operating system: Mac OSX 10.15.6
Browser and version: Chrome 84.0.4147.89

Reproducible Demo
We have a "rollup" Google Analytics Account, this will receive all events from all our websites. Therefor we initialize the rollup account with the Multiple Domain Tracking configuration, just like we did on Vue-GTAG version 1.6.2. Except the result now is that the default params for rollupId is ignored and is populated with the params from the main config.
const defaultParams = {
    anonymize_ip: true,
    send_page_view: false,
    custom_map: {}
}

export const getDefaultParams = () => defaultParams

const config = {
    config: {
        id: conceptId,
        params: {
            ...getDefaultParams(),
            ...{
                optimize_id: optimizeId,
                custom_map: customMap
            }
        }
    },
    includes: [{
        id: rollupId,
        params: getDefaultParams()
    }]
}

// Internally use the vue-gtag module.
// https://github.com/MatteoGabriele/vue-gtag
Vue.use(VueGtag, config)

@MatteoGabriele any updates regarding if this is desired behavior? I assume this might fly under the radar for most people.

@MatteoGabriele any updates regarding if this is desired behavior? I assume this might fly under the radar for most people.

I will have a look in the following weeks probably, still pretty busy right now, unfortunately.
Thanks for your feedback.
I'm also working on the redesign for Vue 3 as well so I will try to squeeze this in

@MatteoGabriele I really appreciate it, thank you.

:tada: This issue has been resolved in version 1.14.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket: