Is there support for Vue 3

It seems to work but with this warning. Is this something that I should be asking in this repo?
Vue file

<template>

Example

    {{ computedMsg }}

</template>

Ouput
[Vue warn]: Property "computedMsg" was accessed during render but is not defined on instance.
      at <Anonymous ref="VTU_COMPONENT" >
      at <VTUROOT>

       9 | </script>
      10 |
    > 11 | <template>
         |                                         ^
      12 |

      13 |
Example

      14 |     {{ computedMsg }}

@onx2 I am working on this feature this week, you can see the WIP PR here: https://github.com/vuejs/vue-jest/compare/next...feature/script-setu?expand=1
It's basically working, just need to make sure I didn't break anything else and test a bit more. Keep an eye out; I think we can release it this week or so.

@onx2 if you have some time on your hands you could help test this out. Implemented here: https://github.com/vuejs/vue-jest/pull/290

You bet. I'll be able to test it out tomorrow and will let you know

Looks like it's working on that commit hash you linked to:
Vue file

Test file

package.json

So I am running into one error that I think is unrelated but wanted to post just in case. Using this TS shim:
declare module "*.vue" {
  import { defineComponent } from "vue"
  const Component: ReturnType<typeof defineComponent>

  export default Component
}

I'm getting a TS error when mounting with props:
No overload matches this call.
  The last overload gave the following error.
    Argument of type 'DefineComponent<readonly string[] | Readonly<ComponentObjectPropsOptions<Record<string, unknown>>>, unknown, unknown, Record<string, ComputedGetter<any> | WritableComputedOptions<...>>, ... 7 more ..., { ...; } | {}>' is not assignable to parameter of type 'ComponentOptionsWithObjectProps<readonly string[] | Readonly<ComponentObjectPropsOptions<Record<string, unknown>>>, unknown, unknown, Record<string, ComputedGetter<any> | WritableComputedOptions<...>>, ... 6 more ..., { ...; } | {}>'.
      Type 'DefineComponent<readonly string[] | Readonly<ComponentObjectPropsOptions<Record<string, unknown>>>, unknown, unknown, Record<string, ComputedGetter<any> | WritableComputedOptions<...>>, ... 7 more ..., { ...; } | {}>' is not assignable to type 'ComponentOptionsBase<Readonly<{ [x: number]: string; } & { length?: number | undefined; toString?: string | undefined; toLocaleString?: string | undefined; concat?: string[] | undefined; join?: string | undefined; ... 17 more ...; flat?: unknown[] | undefined; }> | Readonly<...>, ... 8 more ..., { ...; } | {}>'.
        Types of property 'setup' are incompatible.
          Type '((this: void, props: Readonly<{ [x: number]: string; } & { length?: number | undefined; toString?: string | undefined; toLocaleString?: string | undefined; concat?: string[] | undefined; join?: string | undefined; ... 17 more ...; flat?: unknown[] | undefined; }> | Readonly<...>, ctx: import("/home/onx2/Documents/pr...' is not assignable to type '((this: void, props: Readonly<{ [x: number]: string; } & { length?: number | undefined; toString?: string | undefined; toLocaleString?: string | undefined; concat?: string[] | undefined; join?: string | undefined; ... 17 more ...; flat?: unknown[] | undefined; }> | Readonly<...>, ctx: import("/home/onx2/Documents/pr...'. Two different types with this name exist, but they are unrelated.
            Type '(this: void, props: Readonly<{ [x: number]: string; } & { length?: number | undefined; toString?: string | undefined; toLocaleString?: string | undefined; concat?: string[] | undefined; join?: string | undefined; slice?: string[] | undefined; ... 16 more ...; flat?: unknown[] | undefined; }> | Readonly<...>, ctx: im...' is not assignable to type '(this: void, props: Readonly<{ [x: number]: string; } & { length?: number | undefined; toString?: string | undefined; toLocaleString?: string | undefined; concat?: string[] | undefined; join?: string | undefined; slice?: string[] | undefined; ... 16 more ...; flat?: unknown[] | undefined; }> | Readonly<...>, ctx: im...'. Two different types with this name exist, but they are unrelated.
              Types of parameters 'ctx' and 'ctx' are incompatible.
                Type 'SetupContext<string[]>' is not assignable to type 'SetupContext<EmitsOptions>'.
                  Type 'EmitsOptions' is not assignable to type 'string[]'.
                    Type 'Record<string, ((...args: any[]) => any) | null>' is missing the following properties from type 'string[]': length, pop, push, concat, and 28 more.ts(2769)
mount.d.ts(34, 25): The last overload is declared here.

Changing the shim to what I have below seems to resolve the issue but I'm not sure of the expected type for the vue shim. Evan posted a while back the one I have above which is why I have it in there.
declare module "*.vue" {
  import { defineComponent, ComponentOptionsWithObjectProps } from "vue"
  const Component: ComponentOptionsWithObjectProps<unknown>

  export default Component
}

I also have this shim issue, it is very difficult to solve due to the dynamic nature of the components that can be passed to mount.
I made this issue: https://github.com/vuejs/vue-test-utils-next/issues/194
Basically you can do
mount(Example, {
  // ...
} as any)

To work around it.
Other than TS errors, everything is working ok?

Aside from the TS error, my tests are passing. :heavy_check_mark:
This is the type def I ended up with:
declare module "*.vue" {
  import { defineComponent, ComponentOptionsWithObjectProps } from "vue"
  const Component: ComponentOptionsWithObjectProps<ReturnType<
    typeof defineComponent
  >>

  export default Component
}

It seems to be working for importing / exporting Vue files from other Vue files, typescript files, as well as the tests. It allows mounting options like slots too, so  I can do things like:
const wrapper = mount(Example, {
    props: { msg: "hello world!" },
    shallow: true,
    slots: {
      default: defineComponent({
        render() {
          return h("div", {}, "Hello world!")
        },
      }),
    },
  })

Whether or not this is the preferred or technically correct way is something to be discussed, but for now it works for me :smile: I'll keep my eyes on that thread you linked to - thanks for the heads up!

@onx2 Out of curiosity, could you try with what we settled for in the Vue CLI?
declare module '*.vue' {
  import type { DefineComponent } from 'vue';
  const component: DefineComponent;
  export default component;
}

It works pretty well in our Vue 3 projects.

Yup, that also works for me!

It's live, 5.0.0-alpha.5.


Firestore operations work offline but future is not resolved

Seems like with the cloud_firestore plugin batches work perfectly except for a strange behavior: when a batch is committed while offline the local version of the database is updated but the commit does not output any resolved future, like it's waiting for a response but the operation is actually completed.
Did anyone catch this issue?

Please upvote instead of +1, me too, ...
Upvotes allow to sort issues by most upvoted (~= priority)

any update on this?

any update or workaround?

fyi similar question from Android dev:

https://stackoverflow.com/questions/46672630/addoncompletelistener-not-called-offline-with-cloud-firestore/46674020#46674020

According to this topic, I believe the correct way to do that could be to not subscribe this future.

@darioielardi
This issue has been moved to https://github.com/FirebaseExtended/flutterfire/issues/696. Any further collaboration will be done there.


chore: expands standalone test coverage

chore(zones): adds test for lack of create zone button
chore(dataplanes): adds test for Zone column
Signed-off-by: Philipp Rudloff<EMAIL_ADDRESS>

As far as I can tell, writing tests using KUMA_MODE doesn’t work. Trying it now just makes these tests fail.
Besides that, we should write tests against the mechanisms we’re actually using (which is API calls to /config) not what we will be using in the future. Once we’re actually using this mechanism, it should be trivial to update the testing approach.


Canonical URLs don't have trailing slash

Hey there swyx! I'm currently doing some spelunking on my own site to make some changes to my SEO strategy based on a course from Monica Lent called SEO for devs... one of the activities she recommended was doing a self-audit of SEO strategy using an SEO extension from Detailed.
To make a long story short, I went and checked your site to see how you structure the title tag for your individual pages (because your site is very much a gold standard), and when I inspected it with the Detailed extension, I noticed that Canonical URLs for your site don't end in trailing slashes, but when I visit your site, each page does have one.  I'm not an expert (far from it), but according to the SEO extension's checks, it's something you might want to look at:

From a quick search of your source code, it looks like you could update the svelte code that renders  canonical links in your pages here to address it: https://github.com/sw-yx/swyxdotio/blob/master/src/routes/article/Article.svelte#L19
I hope that makes sense - just trying to pay forward what I'm learning! Have a great day!

haha gotcha. thank you! may be more string manipulation than i care to do... idk

https://github.com/sw-yx/swyxdotio/commit/5c4ed1ae134bbdcaa5f7de74deb7bd65d179d7d5


Thermostat on Tasmota

See https://github.com/atrovato/Gladys/pull/58

Image atrovato/gladys:tasmota


Cannot seed with updateOrCreate() a sluggable model with a slug

Hello
I'm trying to seed my database by using Twill's ModuleRepository methods.
For instance, I can do this :
use A17\Twill\Repositories\SettingRepository;

    $settingRepository->updateOrCreate([
        'key' => 'google_analytics_id',
        'section' => 'general',
    ], [
        'key' => 'google_analytics_id',
        'section' => 'general',
        'en' => [
            'active' => true,
            'locale' => 'en',
            'value' => 'UA-TEST',
        ],
    ]);

But if I try to seed a sluggable model, it fails :
use App\Repositories\CategoryRepository;

[...]

    $categoryRepository->updateOrCreate([
        'title' => 'Events',
    ], [
        'title' => 'Events',
        'published' => true,
        'slug' => [
             'en' => 'events',
         ],
    ]);

with : Column not found: 1054 Unknown column 'slug' in 'field list' ... which is pretty normal since the column is in another table.
It looks like the "slug" key should be in the getReservedFields() function of the ModuleRepository, no?
I think I'm using the correct array structure since this is what the afterSaveHandleSlugs($object, $fields) function of the HandleSlugs trait expect to have to create or update the slug afterwards.
Thanks for your help !
BR

Hi @tchapi,
You are using the correct structure.
When creating a model, only fillable fields should be sent through the underlying SQL query, so I suspect that you might have slug in your Category model fillable array.

Well I checked and I have not :
<?php

namespace App\Models;

use A17\Twill\Models\Behaviors\HasSlug;
use A17\Twill\Models\Model;

class Category extends Model
{
    use HasSlug;

    protected $fillable = [
        'published',
        'title',
    ];

    public $slugAttributes = ['title'];
    public $checkboxes = ['published'];
}

What other thing might I have overlooked ?

Hi, any hints for me regarding this issue y any chance ?

Hi @tchapi ,
As @ifox mentioned, ModuleRepository is using fill to do the mass assignment: https://github.com/area17/twill/blob/1.2/src/Repositories/ModuleRepository.php#L186
However, since you haven't put slug in your $fillable, this issue is not expected and weird.
I have just created a fresh Twill project followed exactly your model setting, and tried your seed operation in tinker, didn't encounter any issues.
I would recommend you try using ->toSql() to get the raw SQL query to find where goes wrong, or you could post your entire project that I could help to take a look as well.
Hope this helps!

Hello @yanhao-li and thanks for your answer. I will try toSql() and see how it goes.

Ok I think I found the culprit : https://github.com/laravel/framework/blob/5.8/src/Illuminate/Database/Console/Seeds/SeedCommand.php#L62-L64
When running the database:seed command, the Model is unguarded on purpose, which means isFillable() returns true for all attributes, and ignores the fillable array, just like a forceFill().
I've checked by var_dumping everywhere and that is what happens in my case: Model::$unguarded is true when seeding.
Am I missing something ?
Thanks again !


Allow per-controller control of PAAs and CD signing keys.

Fast-tracking platform-specific fix with platform owner review.


Optimization of "newest-per-device" query

The "newest-per-device" was written with a subquery to get the max, which requires reading the table two times. PostgreSQL has window function which allow to do the same in one scan only by calculating timestamp=max(timestamp) over (partition by device_id) newest on first scan.
the index starting with "device_id" was not defined with ASC and then was hash-sharded in distributed databases like YugabyteDB . Adding ASC makes it range sharded so that the scan is already sorted
adding the temperature column a the end if the index makes it a covering index and allows Index Only Scan

Those should be faster on all PostgreSQL and compatible databases. The same should be possible for timescaledb.
Old execution plan on PostgreSQL and PostgreSQL compatible databases, with two scans:
explain (costs off)
SELECT e.device_id, e.temperature FROM events e JOIN (
 SELECT device_id, max(timestamp) as ts FROM events GROUP BY device_id
) newest ON e.device_id=newest.device_id AND e.timestamp = newest.ts;

                                                   QUERY PLAN
-----------------------------------------------------------------------------------------------------------------
 Hash Join
   Hash Cond: (((e.device_id)::text = (events.device_id)::text) AND (e."timestamp" = (max(events."timestamp"))))
   ->  Seq Scan on events e
   ->  Hash
         ->  HashAggregate
               Group Key: events.device_id
               ->  Seq Scan on events

New execution plan with only one Index Only Scan:
  explain (costs off)
  SELECT device_id, temperature from (
   SELECT device_id, temperature, timestamp=max(timestamp) over (partition by device_id) is_newest FROM events
  ) e where is_newest;

                          QUERY PLAN
--------------------------------------------------------------
 Subquery Scan on e
   Filter: e.newest
   ->  WindowAgg
         ->  Index Only Scan using events_device_ts on events

Thanks again @FranckPachot for this contribution and the explanation.


Return actual type instead of document with Client::find

I feel that when Client::find is used that it should return the iterator with the actual type instead of the document. This could be a wrapper around the cursor (maybe similar to how wither does it) or maybe just have it converted into a vector. This should give a more high level feel to the crate since they wouldnt have to convert the document to the type in used with Collection::from_document manually and if they need it they could do it manually. What are your thoughts on it?

Are you thinking of something more like this?
use futures::stream::StreamExt;

use mongod::Collection;

let client = mongod::Client::new();

let mut cursor = client.find::<User, _>(None).await.unwrap();
while let Some(res) = cursor.next().await {
    if let Ok(user) = res {
        println!("{:?}", user);
    }
}

It makes sense to me, its going to be very rare that someone would want the document in raw form. TBH the only reason it is as it is now is because it returns the mongodb::Cursor. But I think you are right, we should wrap it to remove this unnecessary step. Let me see what I can do.

Have addressed this with the commit above.

Upon reflection I changed my mind on this, went for the following approach, as this then allows for us to do this:
use futures::stream::StreamExt;

use mongod::{Collection, TypedCursor};

let client = mongod::Client::new();

let cursor = client.find::<User, _>(None).await.unwrap();
let mut cursor: TypedCursor<User>::from(cursor);
while let Some(res) = cursor.next().await {
    if let Ok(user) = res {
        println!("{:?}", user);
    }
}

But looking at it now I guess the only benefit of this is we can more easily interact with the Document to get things like _id, maybe we should just wrap so we can get that out and force the typed cursor by default? I will have a further play.

Okay finally settled on an approach and have released 0.3.0:
let mut cursor = client.find::<User, _>(None).await.unwrap();
  while let Some(res) = cursor.next().await {
      if let Ok((id, user)) = res {
          println!("{} - {:?}", id, user);
      }
  }


Support non typescript applications

Hi, this looks like a great tool and even something I thought about building myself a lot of times.
I'm curious why you're using the typescript compiler to parse the application instead of babel (with typescript parser).
It has the exact same api and can support both regular javascript and typescript together.

@morsdyce that's a great idea. I only needed it for TypeScript and I was already familiar with TypeScript's AST. But it would be nice to add Babel and to support ES6 as well. 👍


📷 Setup Neo4j Docker Image

Docker Image

[x] Add docker-compose.yml

Resolved in https://github.com/usamazansari/itinerary-assistant/commit/d719e1b22139307aa6197383917b1683dd8c0b09


Enable the sharing location automatically

Hyy,
I want to enable browser geolaction automatically, as i am getting a confirmation dialog while accessing geolocation to allow or deny, i dont want any confirmation dialog.
I want this feature by coding
Please confirm

This is not possible. User has to allow access to their location. This is a privacy concern.


Schema-refactor

Finally, :with and :batch options return type get checked now.

Codecov Report
Patch coverage: 100.00% and project coverage change: +0.64 :tada:

Comparison is base (b163e44) 93.70% compared to head (31c8235) 94.34%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff             @@
##           master      #57      +/-   ##
==========================================
+ Coverage   93.70%   94.34%   +0.64%
==========================================
  Files           6        6
  Lines         397      389       -8
  Branches       10        9       -1
==========================================
- Hits          372      367       -5
+ Misses         15       13       -2
+ Partials       10        9       -1

Impacted Files
Coverage Δ

src/sg/flybot/pullable/schema.cljc
91.05% <100.00%> (+1.74%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Disable the aws-vault-wrapper when checking the chamber version

Description
When running the prereqs script or make prereqs the script check-chamber-version is called. But chamber is wrapped with aws-vault-wrapper meaning that just checking the version with chamber version will try to log you into AWS, which is not desirable.
The solution here is to disable the wrapper for this script. You can now run check-chamber-version and it will spit out this:
/usr/local/bin/chamber
chamber v2.8.2 installed

Warnings

:warning:
Please add the JIRA issue key to the PR title (e.g. MB-123)

  Generated by :no_entry_sign: dangerJS against 96d09717843ca5db37c1aedb5402b6520e45a50a


PD: Webworker shouldn't get parallel requests

Some multi-dispatch actions may trigger a COMPUTE_ROBOT_STATE_TIMELINE_REQUEST before any COMPUTE_ROBOT_STATE_TIMELINE_SUCCESS has happened

This has a potential for race condition bugs. We should find a way to guard against this, perhaps by making the timeline middleware interruptable??

Found a bug caused by this!

Make a protocol, delete all the starting tipracks, add a Transfer. You'll get "insufficient tips" error
Add a tiprack to the initial deck setup. The error doesn't appear to go away! (Invisibly, the error goes away for a millisecond and then comes back!)
If you re-save the transfer step, or do something else to cause the timeline to recompute, the "insufficient tips" error will go away

Cause: When you add a tiprack, a thunk is dispatched which in turn dispatches 2 actions: CREATE_CONTAINER and RENAME_LABWARE.
The 2 actions are dispatched very rapidly, faster then timeline middleware's webworker can compute. So we get 2 calls to worker.postMessage
The 2 computations will finish out of order, as logged below. So the correct timeline is computed, but then erased by a computation based on stale data (via RENAME_LABWARE without seeing CREATE_CONTAINER)
worker result {"context":{"name":"","onmessage":null,"onmessageerror":null},"result":{"standardTimeline":{"timeline":[{"commands":[{"command":"pickUpTip","params":{"pipette":"a5e801d0-35aa-11eb-a44f-31900ef05827","labware":"002eeaf0-3a33-11eb-b8bc-f3f24a57cf69:fixture/fixture_tiprack_10_ul/1","well":"A1"}},{"command":"aspirate","params":{"pipette":"a5e801d0-35aa-11eb-a44f-31900ef05827","volume":5,"labware":"trashId","well":"A1","offsetFromBottomMm":1,"flowRate":3.78}},{"command":"dispense","params":{"pipette":"a5e801d0-35aa-11eb-a44f-31900ef05827","volume":5,"labware":"trashId","well":"A1","offsetFromBottomMm":0.5,"flowRate":3.78}},{"command":"dropTip","params":{"pipette":"a5e801d0-35aa-11eb-a44f-31900ef05827","labware":"trashId","well":"A1"}}],"robotState":{"labware":{"trashId":{"slot":"12"},"002eeaf0-3a33-11eb-b8bc-f3f24a57cf69:fixture/fixture_tiprack_10_ul/1":{"slot":"10"}},"modules":{},"pipettes":{"a5e801d0-35aa-11eb-a44f-31900ef05827":{"mount":"left"}},"liquidState":{"pipettes":{"a5e801d0-35aa-11eb-a44f-31900ef05827":{"0":{}}},"labware":{"trashId":{"A1":{}},"002eeaf0-3a33-11eb-b8bc-f3f24a57cf69:fixture/fixture_tiprack_10_ul/1":{"H1":{},"G1":{},"F1":{},"E1":{},"D1":{},"C1":{},"B1":{},"A1":{},"H2":{},"G2":{},"F2":{},"E2":{},"D2":{},"C2":{},"B2":{},"A2":{},"H3":{},"G3":{},"F3":{},"E3":{},"D3":{},"C3":{},"B3":{},"A3":{},"H4":{},"G4":{},"F4":{},"E4":{},"D4":{},"C4":{},"B4":{},"A4":{},"H5":{},"G5":{},"F5":{},"E5":{},"D5":{},"C5":{},"B5":{},"A5":{},"H6":{},"G6":{},"F6":{},"E6":{},"D6":{},"C6":{},"B6":{},"A6":{},"H7":{},"G7":{},"F7":{},"E7":{},"D7":{},"C7":{},"B7":{},"A7":{},"H8":{},"G8":{},"F8":{},"E8":{},"D8":{},"C8":{},"B8":{},"A8":{},"H9":{},"G9":{},"F9":{},"E9":{},"D9":{},"C9":{},"B9":{},"A9":{},"H10":{},"G10":{},"F10":{},"E10":{},"D10":{},"C10":{},"B10":{},"A10":{},"H11":{},"G11":{},"F11":{},"E11":{},"D11":{},"C11":{},"B11":{},"A11":{},"H12":{},"G12":{},"F12":{},"E12":{},"D12":{},"C12":{},"B12":{},"A12":{}}}},"tipState":{"pipettes":{"a5e801d0-35aa-11eb-a44f-31900ef05827":false},"tipracks":{"002eeaf0-3a33-11eb-b8bc-f3f24a57cf69:fixture/fixture_tiprack_10_ul/1":{"H1":true,"G1":true,"F1":true,"E1":true,"D1":true,"C1":true,"B1":true,"A1":false,"H2":true,"G2":true,"F2":true,"E2":true,"D2":true,"C2":true,"B2":true,"A2":true,"H3":true,"G3":true,"F3":true,"E3":true,"D3":true,"C3":true,"B3":true,"A3":true,"H4":true,"G4":true,"F4":true,"E4":true,"D4":true,"C4":true,"B4":true,"A4":true,"H5":true,"G5":true,"F5":true,"E5":true,"D5":true,"C5":true,"B5":true,"A5":true,"H6":true,"G6":true,"F6":true,"E6":true,"D6":true,"C6":true,"B6":true,"A6":true,"H7":true,"G7":true,"F7":true,"E7":true,"D7":true,"C7":true,"B7":true,"A7":true,"H8":true,"G8":true,"F8":true,"E8":true,"D8":true,"C8":true,"B8":true,"A8":true,"H9":true,"G9":true,"F9":true,"E9":true,"D9":true,"C9":true,"B9":true,"A9":true,"H10":true,"G10":true,"F10":true,"E10":true,"D10":true,"C10":true,"B10":true,"A10":true,"H11":true,"G11":true,"F11":true,"E11":true,"D11":true,"C11":true,"B11":true,"A11":true,"H12":true,"G12":true,"F12":true,"E12":true,"D12":true,"C12":true,"B12":true,"A12":true}}}},"warnings":[{"type":"ASPIRATE_FROM_PRISTINE_WELL","message":"Aspirating from a pristine well. No liquids were ever added to this well"}]}],"errors":null},"substeps":{"fb70edb0-3a32-11eb-b8bc-f3f24a57cf69":{"substepType":"sourceDest","multichannel":false,"commandCreatorFnName":"transfer","parentStepId":"fb70edb0-3a32-11eb-b8bc-f3f24a57cf69","rows":[{"volume":5,"activeTips":{"pipette":"a5e801d0-35aa-11eb-a44f-31900ef05827","labware":"002eeaf0-3a33-11eb-b8bc-f3f24a57cf69:fixture/fixture_tiprack_10_ul/1","well":"A1"},"source":{"well":"A1","preIngreds":{},"postIngreds":{}},"dest":{"well":"A1","preIngreds":{},"postIngreds":{"__air__":{"volume":5}}}}]}}}}
makeWorker.js?44ce:28

worker result {"context":{"name":"","onmessage":null,"onmessageerror":null},"result":{"standardTimeline":{"timeline":[],"errors":[{"type":"INSUFFICIENT_TIPS","message":"Not enough tips to complete action"}]},"substeps":{"fb70edb0-3a32-11eb-b8bc-f3f24a57cf69":{"substepType":"sourceDest","multichannel":false,"commandCreatorFnName":"transfer","parentStepId":"fb70edb0-3a32-11eb-b8bc-f3f24a57cf69","rows":[{"volume":5,"activeTips":{"pipette":"a5e801d0-35aa-11eb-a44f-31900ef05827","labware":"002eeaf0-3a33-11eb-b8bc-f3f24a57cf69:fixture/fixture_tiprack_10_ul/1","well":"A1"},"source":{"well":"A1","preIngreds":{},"postIngreds":{}},"dest":{"well":"A1","preIngreds":{},"postIngreds":{"__air__":{"volume":5}}}}]}}}}

What should timeline middleware do when it's already computing?
Ideally, cancel the webworker's task... ?
At least, ignore its results!
Definitely: avoid using stale data!
Memoization must respond correctly:

prevTimelineArgs & prevFeatureFlags - derived from selectors AFTER the action passed into the middleware is given the opportunity to update the state. Used to determine timelineNeedsRecompute. If we're already computing, and we get an action that does NOT result in these being changed, then we don't need to recompute. If we're already computing, and we get an action that DOES result in these being changed, we DO need to recompute (and can ignore the in-progress computation if possible)

prevSubstepsArgs - like the above, derived from selectors AFTER the action passed into the middleware is given the opportunity to update the state. Used to determine whether the substeps need to be recomputed (if the timeline needs to be recomputed, the substeps do too, but sometimes eg renaming a labware, we only need the substeps. Conditions:

In all cases, if we need to recompute the timeline, we necessarily need to recompute the substeps bc right now the timeline is an input into the substep generation process.
If we're already computing the timeline + substeps, and we get an action that does NOT result in substep args being changed (but don't need to recompute the timeline again), we don't have to recompute substeps.
Same as above if we're already computing just substeps.
If we're already computing the timeline + substeps, and we get an action that DOES change substep args, we need to recompute substeps. Ideally, we could wait for the in-progress timeline to finish, and use that to run the substeps.
If we're already computing just substeps, and we get an action that DOES change substep args, we need to recompute substeps. Ideally we could abort the current computation.

QUESTION: calculating the substeps alone will create a COMPUTE_ROBOT_STATE_TIMELINE_SUCCESS that contains the cached timeline. This can easily lead to stale data problems. Can we just exclude the timeline from the action when we were just using the cached one?
QUESTION: can we decouple substep generation so that it doesn't need the timeline as its input? It's regenerating a timeline anyway... why does it really need a timeline as input? Maybe these 2 things can be independent!
INVESTIGATE: instead of making users wait for the worker to finish an in-progress computation while we know we want to recompute anyway, can we interrupt it somehow to save time? This might mean making generateRobotStateTimeline + generateSubsteps allow interruption via some callback etc that checks if computation should continue. Or maybe there's something we can take advantage of in the webworker API itself?

prevSuccessAction - unlike the above, which are results of selectors looking at the new state, this one is a way we cache the result of the computation. Really here we care about the payload, which is the result of the webworker's work. If we're already computing, this is STALE and should not be used.


Add spotless plugin to gradle build and configure license header

This PR adds the Spotless plugin to this repository and configures it to use a header file to set the license header for .java files. The file diff consists of the changes to build.gradle plus changes to source files to fix header formatting and to add headers that were missing.
The diff for the build.gradle file has some commented out lines. These will be uncommented in a follow-up PR. I'm doing this as a two-step process because I want the license headers to be updated for every source file, but I don't want to update the code formatting for every source file because of the size of the diff it would create.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Rebase.


Ajax not working

Ajax not firing after 5 requests did you find a solution ?

Yes, Problem was with routers. I will add redirect to home page after all AJAX request.


arch/armv7-a: Update the macro definition in gic.h

Summary
from https://developer.arm.com/documentation/ihi0048/b.
and Sync armv7r gic/timer with armv7-a
Impact
Testing
internal

@pkarashchenko this patch pass the internal test, please ao ahead to merge it.


Prepend SHA256d with an all zero block

An open question is whether this feature should be implemented in CryptoJPM (and crypto++ finally) or not.
For details, see related pull request in pycrypto project: https://github.com/dlitz/pycrypto/pull/127

I just re-read the parts in the book and saw that you're right about double-hashing and prepending zeros.
This implementation of double-hash will prepend zeroes.
I'd say we prepend a blockszie of zeroes, if we know the blocksize and if not just the double digestsize (for SHA-3 which doesn't seem to have a Blocksize...)

Give me ~24 hours to add the patch for prepending the zeroes.
Your pull request will be merged.


keep original timestaps with copy

mix.copyDirectory('resources/plugins', 'public/plugins');
is it possible to keep original timestamp while copy?
The original files changes very rarely but deploy process (via rsync) copy it to production server every time, because they have changed their update timestamp after mix.copy command

I think this is a wont fix. Some tools don't preserve timestamp metadata. I would consider such metadata to be volatile and could change regardless of whether or not the content of the file has changed. I'd say this is a very limited use case. If you're using rsync I recommend using the --checksum flag. This will copy files that have changed in size or content but not based on timestamp.


css not applied on pdf generated using database queues

PHP Version:>=5.6.4

Description:
css not applied on pdf generated using database queues
I am using snapy pdf plugin

This could be an issue with the package and not the framework. Open an issue on their repo.


Fix 'ignoring return value' warning with gcc 9.3

Without this fix, GCC 9.3.0 generates the following warning when
comparing shared_ptr to nullptr:
extern/doctest.h:1239:49: error: ignoring return value of ‘bool std::operator!=(const std::shared_ptr<_Tp>&, std::nullptr_t) [with _Tp = Luau::Module; std::nullptr_t = std::nullptr_t]’, declared with attribute nodiscard [-Werror=unused-result]
 1239 |         DOCTEST_DO_BINARY_EXPRESSION_COMPARISON(!=, " != ", DOCTEST_CMP_NE) //!OCLINT bitwise operator in conditional

Just pushed the same changes instead of merging the PR as there were other changes that conflicted with it and this was easier. Thanks!


[Feature][transform] 2.3.1中transform sql取消了多source关联join，仅允许简单sql,后续还能恢复吗

Search before asking

[X] I had searched in the feature and found no similar feature requirement.

Description
transform 2.3.0中可以在sql使用复杂sql，如多源join，2.3.1中transform V2中sql query仅支持简单sql，后续是否考虑恢复复杂sql
Usage Scenario
1
Related issues
1
Are you willing to submit a PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

thanks for your feedback.
As a global project, please update the issue title and description in English, thx

I will not support join operation in the future.

why


Avoid caching a snapshot of custom props

ConfigurationImpl which is provided to plugin impl cached a snapshot of custom props indefinitely.  However other props were not cached in this way.  This change removes the indefinited caching of custom props.

ServerConfigurationFactory maintains a cache of the configuration hierarchy.  It would be nice if we reduced caching / re-used existing caches when possible.
There are a couple of possibilities:

Use ServerConfigurationFactory as is?
Use caffeine in ServerConfigurationFactory and use that instead of caching here?
Use the caching here and eliminate ServerConfigurationFactory?

When the prop store was modified, the caching n ServerConfigurationFactory was maintained to preserve functionality.  Not necessarily because it was a optimum configuration, but served to isolate property storage from additional changes at that time.

It would be nice if we reduced caching / re-used existing caches when possible.

This caching is driven by avoiding recomputation of custom props in the SPI impl.  Specifically when a plugin is given a ServiceEnvironment the plugin could execute code like the following and if there was no caching the each call to getTableCustom() would recompute the tables set of custom props.
// some function in a plugin
void MyObj createMyObj(ServiceEnvironment env, Table tid){
    var p1 =  env.getConfiguration(tid).getTableCustom().get("prop1");
    var p2 =  env.getConfiguration(tid).getTableCustom().get("prop2");
    var p3 =  env.getConfiguration(tid).getTableCustom().get("prop3");
    var p4 =  env.getConfiguration(tid).getTableCustom().get("prop4");
    return new MyObj(p1,p2,p3,p4);
}

Use ServerConfigurationFactory as is?

The SPI return a custom interface, so will need some sort of wrapper unless we make AccumuloConfiguration implement the SPI config interface .

Use caffeine in ServerConfigurationFactory and use that instead of caching here?

Does ServerConfigurationFactory continue to cache deleted tables?  I took a quick look and it appears it may, but not completely sure. If it does then that probably should addressed, even if its independent from this.
If we went the route of making AccumuloConfiguration implement the SPI config interface, then we could just return whatever ServerConfigurationFactory returns w/o wrapping it, so this may be a viable way forward.

Use the caching here and eliminate ServerConfigurationFactory?

This is SPI impl code meant for plugins, a lot of internal code does not use this SPI and accesses config directly using internal non-SPI/API method calls.  I


Fixes to functional test failures on Windows

Copied latest code of the Uri class from VS Code repo.
Some of our old tests were incorrect. When using VS Code for paths:

Uri class will prefix paths with / on unix
Uri class will lower case the drive letter (if the path is a windows style path, irrespective of OS)

To keep things consistent, I've modified tests that failed to ensure we use Uri.file(...).fsPath to get a file path that can be compared against.
I.e. in extensions we use Uri.file or Uri.parse and the file path returned from the fsPath property is slightly altered from the intput. Hence the tests should take this into account and compare paths using the fsPath property of a uri object.
Basically everything is a change to the tests.

Codecov Report

Merging #7940 into master will decrease coverage by 27.85%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           master    #7940       +/-   ##
===========================================
- Coverage   59.27%   31.41%   -27.86%
===========================================
  Files         498      243      -255
  Lines       22305     9596    -12709
  Branches     3581     1429     -2152
===========================================
- Hits        13221     3015    -10206
+ Misses       8262     6556     -1706
+ Partials      822       25      -797

Impacted Files
Coverage Δ

src/client/providers/serviceRegistry.ts
0% <0%> (-100%)
:arrow_down:

src/client/common/variables/serviceRegistry.ts
0% <0%> (-100%)
:arrow_down:

...t/datascience/jupyter/jupyterDataRateLimitError.ts
0% <0%> (-100%)
:arrow_down:

...lient/datascience/jupyter/jupyterSelfCertsError.ts
0% <0%> (-100%)
:arrow_down:

src/client/datascience/jupyter/jupyterUtils.ts
0% <0%> (-100%)
:arrow_down:

src/client/interpreter/serviceRegistry.ts
0% <0%> (-100%)
:arrow_down:

src/client/common/utils/regexp.ts
0% <0%> (-100%)
:arrow_down:

src/client/common/utils/icons.ts
0% <0%> (-100%)
:arrow_down:

...rc/client/common/errors/moduleNotInstalledError.ts
0% <0%> (-100%)
:arrow_down:

src/client/terminals/serviceRegistry.ts
0% <0%> (-100%)
:arrow_down:

... and 397 more

Continue to review full report at Codecov.

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

@rchiodo Please re-review


unknown field "trigger_rules" in v1alpha1.Jwt

Bug description
Expected behavior
Steps to reproduce the bug
Version (include the output of istioctl version --remote and kubectl version)
How was Istio installed?
Environment where bug was observed (cloud vendor, OS, etc)
Affected product area (please put an X in all that apply)
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
Additionally, please consider attaching a cluster state archive by attaching
the dump file to this issue.

Which version of Istio are you using?  Where is this error appearing?
The api/authentication/v1alpha1/policy.proto field trigger_rules is at least 9 months old.

Could you provide some additional information about this?

Hi All, Thanks for the info, i understood the issue. Its regarding with the istio version . We are sorted out

Thanks @vishdv for the update, Closing the issue now.


fix race condition in pipe tests

wait for destination stream to finish writing before reading it back to
verify
Suspect this will resolve flakyness of TravisCI tests.
See also #912 (which I think should now be closed without
merge)
(Sorry, created a new PR instead of #913 due to my git/github rebase-fu failing repeatedly. See #913 for the backstory and #912 will be closed)

Whew...it actually passed the first time. Had fingers crossed for that one.


Feature Request: Specify credentials for Windows Authentication

SQL Operations Studio Version: 0.23.6 (MacOS)

I was excited to try SQL Ops Studio for Mac however it's fallen at the first hurdle by not allowing me to specify account details for connecting using Windows Authentication, something that other 3rd Party products (like TeamSQL) allows.
It would be great to be able to add specific credentials for Windows Auth as well as SQL Auth, to enable non-domain accounts on MacOS to connect.

Agreed. This is also a major issue with SSMS, as well. When using the elevated account access methodigy, in many cases the interactive user account does not have access to the SQL Server. This requires us (on Windows) to Run As on SSMS. It's inconvenient and it would be ideal if we could simply specify the appropriate credentials instead.

As a bandaid...
If you are on OSX (and I'm assuming quite similar steps on Linux) you can use KRB5CCNAME to force a different credential cache for the app.  This is useful in cases of having a 'normal' account and an 'elevated' account, where you primarily want to connect to databases using the elevated account.  Not as useful for 2+ Windows accounts that act as SQL logins.
This is all manual, can probably be wrapped in a bash script and made non-interactive.

Create a ticket for the elevated account

kinit --keychain elevated_account
This will change your default credential cache!
--keychain will store your password in the OSX keychain.

Switch back to your default account cache (interactive)

kswitch -i

View list of your principals and caches

klist -l
Copy down the cache name of your elevated account

Launch SQLOPS with env override for your credential cache

KRB5CCNAME='ccache_name' open /Applications/SQL\ Operations\ Studio.app

@nathairtras does ur solution depend on macOS to be connected to AD ?
We have macs that are not connected to AD account but all our sql logins through domain accounts. With this approach we can’t connect the Mac to AD but want to use sql studio to use windows credentials...

Hey @kburtram, this is the suggestion I was speaking to you last night at the Oregon SQL Meeting.  This feature would be great for all platforms.

Has there been any word on when this will make it into the schedule? Being able to avoid using runas would be a lifesaver.
Just as a comment, it would be great to be able to manage the credential in a single location, and apply it to multiple connections (to account for password changes, etc)

Consider this use case: I'm a consultant, that has to connect to different client-provided databases, with client-provided credentials, often in domain\user form. As I'm working on multiple projects, out of a mac that does not belong to any of those client companies, I'd rather not join my computer to clients AD.
Sadly, my current workaround is to use a different tool where client has provided domain\user type of credentials.

This would be a great relief when added, we have production on different domain and logging in from workstation is not possible without this option.

Also casting my vote for this feature. I'm a Linux guy (currently Ubuntu 18.04, but I've been know to run Arch as well) in a Windows shop. I currently use Aqua Data Studio to connect to SQL Server, and it has an option to allow me to specify my domain, username, and password to connect using a domain account from a non-domain machine. Something similar would be amazing for this tool.

A certain necessity! Please add.

I'm in the same boat as @tmikoss:

Consider this use case: I'm a consultant, that has to connect to different client-provided databases, with client-provided credentials, often in domain\user form. As I'm working on multiple projects, out of a mac that does not belong to any of those client companies, I'd rather not join my computer to clients AD.

I guess I'm going to go back to Aqua Data Studio for now too... But I would rather SQL Ops Studio had this feature.

Plus one for this feature. I can get on when I'm on the domain from work, but from home when I'm just on the VPN... not so much. I can connect with Python over FreeTDS just fine with Windows Auth credentials from home, but not Azure Data Studio!
I'd rather not have to dive into Kerberos on my Mac or Linux machines at home. There be dragons...

Adding my plus one too.  Really would be very helpful all around.

I'm a plus one also.  This is a gotta have...

This is the thing that holds me back from primarily using Azure Data Studio.
Def. a +1 from me! :)

I would like to add that this would be a useful feature when connecting from a Mac. It would be nice if this feature is ported over to SSMS, not having to use runas would be amazing (since runas will have SSMS run in the profile of the user, sometimes I forgot and save things to the Desktop, etc...).
At least in PowerShell/Windows, it's so easy to execute things as a different user by providing a Credential object, I dunno why SSMS/Azure Data Studio do not support supplying a different Windows AD credential. And Azure Active Directory does not work for non-Azure SQL databases. -m

+1 from this me on this feature. I use both Mac and PC (AD-Joined).  For security purposes, the accounts we use for DB functions & development are not our regular AD accounts. The lack of the ability to specify the AD account limits what we can do.

Plus one for this feature. Not being able to manually input Windows Auth credentials is the only thing stopping me from using this on the Mac consistently.

+1 for me as well. Runas is just an annoying workaround.

My vote for this, too. Cannot use this tool towards several of the databases having personal user accounts which are not in my local AD.

my vote as well,

I will need this too, please implement it ;)

Great tool, very light weight, fast and intuitive, but this keeps me from using it at the moment unfortunately

Is this on anyone's radar? Over 2 years of requests and no real comment outside of workarounds.

Hey, @kburtram can you provide any update?

@rivens623 currently .Net SqlClient (the SQL Server driver we use) doesn't support using multiple AD identities in the same context.  When we investigated this it looks like the best option would be a capability to manually provide a kerberos ticket to the client for each connection, since this also would enable various Integrated Auth scenarios on non-Windows clients as well.  We opened this issue against SqlClient component to add this capability https://github.com/dotnet/SqlClient/issues/305.
Currently SqlClient backlog is pretty filled up through at least end of June.  So we are discussing how to fund this SqlClient update sooner if possible as part of a broader set of work items we're doing to improve our Authentication experience.  For example, we have a major update to our AAD login experience shipping in the Feb release this week.
@aaomidi is driving our overall authentication experience enhancements.  @aaomidi did I missing anything above?  As far as ETA, I expect that April would be the earliest this may be available?

Thanks for the update @kburtram!

Any updates on this subject, now it is June?

I''d also really like to see this happen and am curious about the current status...

Hey all, this is going to take a bit longer as it's not in our immediate plans. There is also some technical stuff we need to figure out to get this working with the best possible experience.
These technical discussions are happening concurrently with the work we're doing for the rest of the project.
Please use the emoji responses to show interest in this as that makes it easier to push this one forward.


Backup PGP key / Review Maven Central Metadata

Just to make sure, everything is allright when we release our 2.0.0 version.
https://central.sonatype.org/publish/requirements/

Metadata fixed in this commit: https://github.com/andregasser/bigbone/commit/7f2816ba2f02b827f9740cf4e86b75f390cd5740

Backing keys up using this guide here: https://www.howtogeek.com/816878/how-to-back-up-and-restore-gpg-keys-on-linux/

Done


package.json

npm WARN engine<EMAIL_ADDRESS>wanted: {"node":">= 4.2.0"} (current: {"node":"0.10.40","npm":"2.13.3"})
npm WARN deprecated<EMAIL_ADDRESS><EMAIL_ADDRESS>is no longer maintained. Upgrade to<EMAIL_ADDRESS>npm WARN deprecated<EMAIL_ADDRESS>Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated<EMAIL_ADDRESS>Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN optional dep failed, continuing<EMAIL_ADDRESS>npm WARN engine<EMAIL_ADDRESS>wanted: {"node":">=0.12.0","iojs":">=1.0.0"} (current: {"node":"0.10.40","npm":"2.13.3"})
npm WARN engine<EMAIL_ADDRESS>wanted: {"node":">=0.12"} (current: {"node":"0.10.40","npm":"2.13.3"})
npm WARN engine<EMAIL_ADDRESS>wanted: {"node":">=0.12"} (current: {"node":"0.10.40","npm":"2.13.3"})
npm WARN engine<EMAIL_ADDRESS>wanted: {"node":">=0.12"} (current: {"node":"0.10.40","npm":"2.13.3"})
npm WARN deprecated<EMAIL_ADDRESS>Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm ERR! Windows_NT 6.2.9200
npm ERR! argv "C:\Users\Fedya\AppData\Local\atom\app-1.8.0\resources\app\apm\bin\node.exe" "C:\Users\Fedya\AppData\Local\atom\app-1.8.0\resources\app\apm\node_modules\npm\bin\npm-cli.js" "--globalconfig" "C:\Users\Fedya\.atom\.apm\.apmrc" "--userconfig" "C:\Users\Fedya\.atom\.apmrc" "install" "C:\Users\Fedya\AppData\Local\Temp\d-116529-1068-3dlknj\package.tgz" "--target=0.36.8" "--arch=ia32" "--msvs_version=2012"
npm ERR! node v0.10.40
npm ERR! npm  v2.13.3
npm ERR! file C:\Users\Fedya.atom.apm\grim\1.5.0\package\package.json
npm ERR! code EJSONPARSE
npm ERR! Failed to parse json
npm ERR! Unexpected token '\u0000' at 1:1
npm ERR!
npm ERR! ^
npm ERR! File: C:\Users\Fedya.atom.apm\grim\1.5.0\package\package.json
npm ERR! Failed to parse package.json data.
npm ERR! package.json must be actual JSON, not just JavaScript.
npm ERR!
npm ERR! This is not a bug in npm.
npm ERR! Tell the package author to fix their package.json file. JSON.parse

That sounds like npm issue #10686

@prettydiff : this issue? https://github.com/npm/npm/issues/10686

Yes, that one.


Feature: ES-SQL Integration - Excel

Open Distro support for ODBC Driver in Excel with the M connector

@anirudha is it possible to open a feature to allow integration with Power BI or is it redundant?

Yes!! Power BI M connector we will  start work in about a week. Should be ready in a couple of months


synology_dsm camera enhancement

The problem

Dear @Quentame
Since i noticed that the good woking synology camera integration will be removed in HA 0.118, I investigated the enhanced synology_dsm integration in the current HA 0.116.0.dev. (I already posted this in a feature request, but it seems that the module is used seldomly https://community.home-assistant.io/t/synology-dsm-camera-enhancements/229763. Therefore I try to get in contact with you using that issue)
Behaviour of new synology_dsm integration (camera) in contrast to the deprecated one:
I found out that the new synology_dsm integration tends to create problems by showing this 8MP streams using HLS (no mjpeg) at all (this seems to be the new default). The delay is worse > 10 sec if its working.
My Samsung S7 (ha app and browser) and also my older PC which worked well for presenting the lovelace interface up to now often struggle with the fixed 8MP camera streams - see environment.
I also noticed thats its vital to create an administrative user instead of an surveilance station user.
The old integration used mjpeg for presenting (very fast <= 3 sec delay) with medium stream resolution, which is sufficient for a mounted tablet at all.
Perhaps the current documentation could be enhanced to first mention the capability of the camera enhancement and second to explain how to use the camera stuff of the synology_dsm module (perhaps explain how to create a lovelace object and which options (save picture / save movie is available).
Environment

Home Assistant Core release with the issue: 0.116.0.dev
Last working Home Assistant Core release (if known): -
Operating environment (OS/Container/Supervised/Core): RASPI 4 4GB Docker ARM from offical project
Integration causing this issue: synology_dsm
Link to integration documentation on our website: https://www.home-assistant.io/integrations/synology_dsm/

My configuration:
I personally use 4 x 8MP cameras with three streams connected to the synology NAS 713+. All three streams are configured: One with 8MP, one with 1MP and one as a kind of thumbnail stream.
Problem-relevant configuration.yaml

none - configured via integration

Traceback/Error logs

none

Additional information
At the end i dream to have an easy to use dashboard for my camera modules:

fast/low delay stream in terms of an overview for lovelace (i.e. using mid resolution and mjpeg is OK)
abillity to manually switch to the highest resultion HLS stream for active watching
save pictures and streams (then with the higest quality)
navigate through the history (independent if realized using synology nas or HA technology)

I have several ideas to improve that module:

Create a configuration item to configure the available resolution for streaming in lovelace (perhaps interactively)
Create a configuration item to configure the available streaming technology HLS or mjpeg for lovelace (perhaps interactively)
Enable actions to save the stream and also pictures in a pre-defined quality (independend what lovelace presents) either built in lovelace or using Synology NAS methods (I am not aware of).
History module (perhaps realized using the new HA media capabilities).

What do you think? Do you see any chance to get some ideas into the integration?

Hi !
Thanks for your feedback on testing and great ideas of improvements !!! :bulb:
I love the idea to add the media_browser capability to Surveillance Station with an history media_player.
The camera platform uses RTSP to get the stream from cameras.
Taking a snapshot or record a camera stream is built in the HA camera platorm, so it should work (not tested actually).
I can check the resolution/protocol involed in camera streams, but I don't have an ETA for you since I have multiple integrations to maintain.
@shenxn : Would you like to take a look ?
Thanks a lot.

Linked with home-assistant/core#40490 & home-assistant/core#39838

@Quentame I'll look into it but I'm currently working on another integration that needs quick fix. Since there seems to be a lot of problems, I think it is better to move the removing schedule to a latter release. At least we should fix all those problems before removing the old one.

@shenxn

Since there seems to be a lot of problems, I think it is better to move the removing schedule to a latter release.

From https://community.home-assistant.io/t/synology-dsm-camera-enhancements/229763 , I see 2 problems:

[issue] Create a configuration item to configure the available resolution for streaming in lovelace (perhaps interactively)
[issue] Create a configuration item to configure the available streaming technology HLS or mjpeg for lovelace (perhaps interactively)
[shipped] Enable actions to save the stream and also pictures in a pre-defined quality (independend what lovelace presents) either built in lovelace or using Synology NAS methods (I am not aware of).
[feature_request] History module (perhaps realized using the new HA media capabilities).

Have you seen more ?

I think it is better to move the removing schedule to a latter release. At least we should fix all those problems before removing the old one.

I agree, we can do that.

@Quentame So there is one more. Allow users to add only cameras (no system monitoring sensors) with a non-administrative account.

Dear @shenxn
dear @Quentame
I love you passion to work on that! Great!
From my perspective it could be also an idea, if you additionally put the capability of the old integration into the new one (using HLS and medium resolution) as a parallel second stream (for each camera). Then you get rid of the old integration as planned and the new one has a additional feature. If I am not wrong, its a more or less a different API call (but I am not a progammer).
Regarding the user account: It was a remark not more. I personally can live with that!

Dear @shenxn
dear @Quentame
today i notice that the synology_dsm integration doesn't provide the status (HA state recording) if the stream is recorded by the Disk station itself. I only see the state idle. Is it possible to enhance your integration too?

today i notice that the synology_dsm integration doesn't provide the status (HA state recording) if the stream is recorded by the Disk station itself. I only see the state idle. Is it possible to enhance your integration too?

Tested on my side and working.
Be careful of your home mode setting.

I do not use the home mode feature. Its off.

if the stream is recorded by the Disk station itself

What do you mean with Disk Station ?
Now, when there is the [REC] icon on the Surveillance Station camera, the recording status is well retrieved in HA.

I mean my Synology DS713+
Interesting, I don't see that in the entities provided by synology_dsm integration (is always idle), while the old synology integration presents the correct status.


Update ammonite-repl to 2.3.8-32-64308dc3

Updates com.lihaoyi:ammonite-repl from 2.3.8-4-88785969 to 2.3.8-32-64308dc3.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.lihaoyi", artifactId = "ammonite-repl" } ]

labels: library-update, semver-pre-release

Superseded by #747.


Pin a windows on Top

Description of the new feature / enhancement
A button or a shortcut to keep a window on top even when clicking on other opened windows.
Scenario when this would be used?
This will be useful for multitasking, where you are just trying to rewrite or look at something in the browser and then type it in another app where you have the one of the windows on the top and working with the other.
Supporting information
No response

Duplicate of #13


[TASK-4] As a user, I can automatically enter the home dashboard once logged in

https://github.com/minhnimble/android-surveys-list/projects/1#card-46081236
What happened
When users are logged in previously, they will be redirected to the home dashboard without having to enter login credentials again. If the session is expired, users will see the login screen as usual.
Also, fixing some refactor comments:

https://github.com/minhnimble/android-surveys-list/pull/4#discussion_r499491347
https://github.com/minhnimble/android-surveys-list/pull/7#discussion_r500703916
https://github.com/minhnimble/android-surveys-list/pull/7#discussion_r500704140
https://github.com/minhnimble/android-surveys-list/pull/7#discussion_r500126186

Insight
Acceptance Criteria

[x] Implement auto-refresh token logic flow
[x] Implement token expired logic flow
[x] Connect to refresh token API
[x] Fix refactor comments from previous PRs

Proof Of Work

@minhnimble Please add UnitTest for new code changes (UnitTest, ViewModel, ...) 🙏 It would be better if UnitTest included in each PR 😅

I am creating a separate PR for unit test, not put everything in one PR 😅

@minhnimble UnitTest included would be nice for reviewers and we could update the code to testable if needed earlier.

@minhnimble I notice that you have checked session in Onboarding screen. Any reason why we recheck here? 🙏

oh this is for kicking user out of this Home screen back to Onboarding screen to sign in again if that user has an expired token and the app cannot refresh it using refresh token api. The1 Android also has this logic in its Main screen 🙏

I'm wondering that shall we show error message when refreshing token failed here? Could it makes more sense if we return to login screen instead of show error message? 🙏

we are at Onboarding screen (Login screen) already, so how can we return to it again, I don't get your point 🤔

oh this is for kicking user out of this Home screen back to Onboarding screen to sign in again if that user has an expired token and the app cannot refresh it using refresh token api. The1 Android also has this logic in its Main screen 🙏.
I strongly believe this is for time sensitive situation when users still has a local valid token in Onboarding screen but when it reaches Home screen, it becomes invalid and at that time, the application can't connect to refresh token api and we have to kick that user back to Onboarding screen

I understand what you mean, but in The1 project, it is definitely different case because we dont have Splash screen in The1.
About your case, we already checked it in Onboarding, why do we need to check it again? Seems it is duplicated 🤔  How do you think? 🙏

we are at Onboarding screen (Login screen) already, so how can we return to it again, I don't get your point 🤔

Ah I see, I think we can display a general message like Session expired. Please login again. for that.

I understand what you mean, but in The1 project, it is definitely different case because we dont have Splash screen in The1.
About your case, we already checked it in Onboarding, why do we need to check it again? Seems it is duplicated 🤔 How do you think? 🙏
🙏
Hmm, let me run more testings on this case to check if it is really needed, thanks for spotting out

Ah I see, I think we can display a general message like Session expired. Please login again. for that.

That would also make sense, yeah definitely will update to that message, nice catch 👍

@minhnimble Please resolve all comments in this PR 🙏  Create new PR for fixing comments is unnecessary 😅

@minhnimble Please resolve all comments in this PR 🙏 Create new PR for fixing comments is unnecessary 😅

yeah I know, the previous PR was huge so I have to split, this one is a small PR and thus I will definitely put related fixes in here 👍

@hoangnguyen92dn @manh-t there are few things I'd like to address here:

The review should not be opinionated, I understood that we are having a few differences in our architecture in different projects; this should not be taken as the only source of truth and enforce the others. It will create a mixed weird hotpot and the project will never be done. The target here for the review is:

We should make sure that @minhnimble will not make any serious/common mistake
All the codes should be testable, architecture solution can be different, but as long as he can test his codes, we shouldn't police his solution. This suppresses the other's idea of expressing their own creativity, which is NOT good.

By complying with these guidelines to review, we can move at a faster pace and learn from the other's perspective as well. This is usually the way we review the assignment of a candidate if you guys still remember how I and @luongvo did the review with you before 🙏  Let me know if you have any questions.

From my previous comment, my idea is remove refreshToken, and we could rename current loginByPasswordWithEmail to authenticate for common usage (Login and Refresh token)
Ex:
   @POST("/api/v1/oauth/token")
   fun authenticate(
       @Body request: OAuthRequest
   ): Flowable<OAuthResponse>

I am not sure if you use this technique before but using the sealed class OAuthRequest like this doesn't work since Retrofit doesn't recognize the request class you paste in, it just consider checking the sealed OAuthRequest class and since there is no property, it send an empty request up. Can you share the full working implementation?

Please use git squash to reduce the number of commits for the next PRs.

yes sure 👍


Add new priority modes to --spawn-with-priority

In #1929 it was pointed out that, when using --spawn-with-priority, the workload tends to be unevenly spread. Agents with fewer spawn will not have any spawn with as high a priority as agents with more spawn. Because work is assigned to available agents with the highest priority first, work ends up assigned only to agents with more spawn, and no work is assigned to the agents with fewer spawn (until the agents with more spawn become busy). This PR changes --spawn-with-priority to be a string flag, letting the user choose the priority assignment.
Example commands:
# Existing behaviour: Start 5 agents with default priority.
buildkite-agent start --build-path=~/tmp --spawn=5

# No longer valid (no value provided for --spawn-with-priority)
buildkite-agent start --build-path=~/tmp --spawn=5 --spawn-with-priority

# New behaviour: Start 5 agents with priorities [0, 1, 2, 3, 4].
buildkite-agent start --build-path=~/tmp --spawn=5 --spawn-with-priority=ascending

# New behaviour: Start 5 agents with priorities [0, -1, -2, -3, -4].
buildkite-agent start --build-path=~/tmp --spawn=5 --spawn-with-priority=descending

# New behaviour: Start 5 agents with priorities [42, 43, 44, 45, 46].
buildkite-agent start --build-path=~/tmp --spawn=5 --spawn-with-priority=ascending --priority=42

# New behaviour: Start 5 agents with priorities [42, 41, 40, 39, 38].
buildkite-agent start --build-path=~/tmp --spawn=5 --spawn-with-priority=descending --priority=42

Fixes #1929
Edit: changed from using an experiment to a single flag
Edit 2: changed from inverse to a variety of options.
Edit 3: fixed the example commands
Edit 4: changed away from the bool-like flag (fully breaking change)

I made it a string flag (value required).

@DrJosh9000 What do you think about closing this one, with an eye to making the behaviour from #2004 the default behaviour in the next major release?

I'm closing this with an eye to making descending-spawn-priority the default, as suggested by @dabarrell.


Delete row popup, pass function to component

Griddle version
1.13.1
Expected Behavior
Grid has 2 columns with item id and item name.
Click on a link in the column with the id. The link contains the item id. Popup opens and asks if you really want to delete this item and shows item name.
I want to pass the item id, item name and the function to delete the item  to the custom component.
Before the item gets deleted it should show a popup. What is the best way to pass the function?
currently I can only pass the data row as shown in example
const data = [
  {
    "name": "Mayer Leonard",
    "city": "Kapowsin"
  },
  {
    "name": "Koch Becker",
    "city": "Johnsonburg"
  }
];

<Griddle
  data={data}
  plugins={[plugins.LocalPlugin]}
  components={{
    Layout: ({ Table }) =>

  }}
  pageProperties={{
    pageSize: 2
  }}
  >
  <RowDefinition>
    <ColumnDefinition
      id="name"
      title="Persons"
      customComponent={enhancedWithRowData(MyCustomComponent)}
    />
  </RowDefinition>
</Griddle>

Custom component
const MyCustomComponent = (value, griddleKey, rowData) {
    return (

               <a className="action" src={{`/test/delete/${value}/`}} onClick={call passed funtion?}>Delete

    );
}

I created a custom component and passed the function in the extradata. Maybe the documentation about the extradata could be a bit more comprehensive.


Added a comment on mailhog for local docker development

Now that mailhog is available as a container for local docker development, this note should help people on how to use it

closing this PR as it is merged with PR #553


CHIP Pairing should be able to return timeout errors

Problem
CHIP pairing attempts never time out.
For example pairing with a non-existent accessory appears to go on forever.
Proposed Solution
The pairing session should be able to time out

Resolved with:
https://github.com/project-chip/connectedhomeip/pull/5849


Version 0.0.1

First publish of the package:)
Checklist:

[x] Add ability to redact by key
[x] Add unit tests to see that key redaction happens on all record elements.
[x] Change ignore keys to be a set so that the in check happens faster.
[x] Remove bugs that mutated the data itself, now, only the info displayed by the logger is redacted.
[x] Removed args from ignore key list, since we want to apply the redacted logic to args as well.
[x] Updated unit tests to ensure no data mutation is occurring
[x] Updated README.md

cc: @danwald

Nice, you already have pypi publish ..


Feeding partition

Environment:

Python version [3.6.8]
Spark version [2.3.3]
TensorFlow version [1.14.0]
TensorFlowOnSpark version [1.4.3]
Cluster version [yarn 2.7]

Describe the bug:
When I set a max_steps which step has be triand, It will be Feeding partition and has no progress. what should i do??
Logs:
2019-12-19 16:51:12,694 INFO (MainThread-8681) Skipping training since max_steps has already saved.
2019-12-19 16:51:12,716 INFO (MainThread-8721) mgr.state='running'
2019-12-19 16:51:12,717 INFO (MainThread-8721) Feeding partition <itertools.chain object at 0x7fc2be3a3668> into input queue <multiprocessing.queues.JoinableQueue object at 0x7fc2be3a36a0>
[Stage 1:>                                                         (0 + 4) / 20]
...

you can add "data_feed.terminate()" in last line . This will close dataFeed quene.

I'm assuming that this is resolved.  Feel free to re-open otherwise.


Add validation required fix and corresponding package tests

Function Required had, I suppose, not desired behaviour due to not correct usage of reflect package.
Also I added some tests to validate package because there were not that many of them.

I am not that sure but aren't these CI ("to long") errors kinda common for the current branch? Am I supposed care about them in this pull request to make it accepted?

lgtm
sorry I fixed those in anohter branch


List of segments

Future suggestion: provide a list of segments to choose from when starting a timer.
Perhaps based on existing segments in the current timer block, with an option to type in a new one.
Or, based on a pre-defined list.
When switching between the same named segments during the work day, having to type them in can lead to errors.
Thanks!

So, just to clarify, when starting a new segment you want to have the ability to use a pre-defined segment name for a new segment? That sounds like a good idea.
Any reason you're not just using sub-segments by continuing an existing segment, though?

Fair question. I actually missed that functionality as the additional
buttons for sub-segments do not appear when a timer is running.
I will actually try using sub segments and see how that goes.
But, yes, my initial query was for a pre-defined segment name.
Thanks for the quick reply!
Dion
On Fri, Nov 4, 2022 at 2:28 PM Ellpeck @.***> wrote:

So, just to clarify, when starting a new segment you want to have the
ability to use a pre-defined segment name for a new segment? That
sounds like a good idea.
Any reason you're not just using sub-segments by continuing an existing
segment, though?
—
Reply to this email directly, view it on GitHub
https://github.com/Ellpeck/ObsidianSimpleTimeTracker/issues/7#issuecomment-1303981434,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APY26UDBMLLMALOAKBN5YTTWGVIWDANCNFSM6AAAAAARXNFYBY
.
You are receiving this because you authored the thread.Message ID:
@.***>

Hi @dionvansevenant, is your suggestion / feature request still relevant or could the problem be solved by using the sub-segments?
Thank you very much!

Okay, I'll close this then! :)


Add setting to disable token rotation animation?

It would be great if you could add a setting to disable token's animating their rotation (either by holding Shift + Mousewheel, Ctrl + Mousewheel, Shift + WASD, or using your module and moving the token in different directions). It causes all kinds of visual problems in game. The module About Face added this setting and it's really helped, but unfortunately About Face has a lot of bloat with their direction indicators that causes all kinds of problems with other modules. Autorotate is a lot leaner of a module, and would be my preferred choice if moving tokens didn't look so janky because of the rotation animation.

Ok, so it looks like what About Face does is patch the internal animation procedure:
toggleAnimateFrame(value) {
    if (value) libWrapper.register(MODULE_ID, "CanvasAnimation._animateFrame", _animateFrame, "OVERRIDE");
    else libWrapper.unregister(MODULE_ID, "CanvasAnimation._animateFrame");
}

function _animateFrame(deltaTime, animation) {
	const { attributes, duration, ontick } = animation;

	// Compute animation timing and progress
	const dt = this.ticker.elapsedMS; // Delta time in MS
	animation.time += dt; // Total time which has elapsed
	const pt = animation.time / duration; // Proportion of total duration
	const complete = animation.time >= duration;
	const pa = complete ? 1 : animation.easing ? animation.easing(pt) : pt;

	// Update each attribute
	try {
		for (let a of attributes) {
			// Snap to final target
			if (complete) {
				a.parent[a.attribute] = a.to;
				a.done = a.delta;
			}

			// Continue animating
			else {
				const da =
					a.delta *
					((a.attribute == "rotation" && [2, 3].includes(game.aboutFace.disableAnimations)) ||
					((a.attribute == "scaleX" || a.attribute == "scaleY") && [1, 3].includes(game.aboutFace.disableAnimations))
						? 1
						: pa);
				a.parent[a.attribute] = a.from + da;
				a.done = da;
			}
		}

		// Callback function
		if (ontick) ontick(dt, animation);
	} catch (err) {
		// Terminate the animation if any errors occur
		animation.reject(err);
	}

	// Resolve the original promise once the animation is complete
	if (complete) animation.resolve(true);
}

I would prefer not to do this, as it's really something that should probably be fixed in Foundry itself - the current behavior is arguably a bug.
There might be a way to do this without patching Foundry by separating the rotation and movement changes, but I would have to test first.

I noticed this same "animation" behavior. So if I'm understanding correctly this is a core feature and has nothing to do with this mod?

I noticed this same "animation" behavior. So if I'm understanding correctly this is a core feature and has nothing to do with this mod?

@Shuggaloaf Correct. When a token's position (including rotation) is changed, Foundry does a "linear" animated transition from the old position/rotation to the new one. Foundry's current API doesn't provide any way to customize this animation, so a module developer's only solution is to patch its implementation.

@Varriount Thanks for the reply.
It's too bad that the animation plays out over the whole move when you drag it long distances. The animation actually looks good when you're just moving from square to square.
If it could turn first, then move I think that would be ideal. I'm guessing that's probably something that can't be done within the module though?
Or maybe a better solution is do not animate if being moved more than 1 square/step but allow animation if only 1.


Edit & Create meet up

create_meetup page
edit_meetup page
datetime widget for selecting date.
fab -> create_meetup
consumer not yet added, manager also not yet added.

@iAlanx3 is this ready for review?

rebased onto main and added consumers to edit meetup view.
still missing

parse the locationController.text into a latlng and send it to the meetup manager via editMeetup
raise an error if user tries to a set a new maxAttendees that is < the currNumAttendees (maybe display this number too)
add router push from detailed meetup view's "edit" pop up menu button
edit router.dart: replace the placeholder edit thread view with this new edit meetup view


feat(rbac): show error for permission duplicate entry

Fixes: https://github.com/janus-idp/backstage-plugins/issues/1068
New implementation:
Based on UX input this PR now disables selected permissions.
https://github.com/janus-idp/backstage-plugins/assets/20724543/0b958264-9d70-437d-8e37-035cd97244a0
Old implementation:
This PR adds validations to show field level error for permission fields that are not unique for the same plugin.
https://github.com/janus-idp/backstage-plugins/assets/20724543/a00538a8-a3a6-468b-9ad5-a9f8d7d9d9c3

Is this expected ?

Hi @divyanshiGupta I wonder if it makes sense to disable a permission if it's already selected from the dropdown and it's present with the policies selected in the list?I think we are doing this behaviour  in the users and groups selection, right?
If user removes the permission policy row by using the '-' sign, we can enable it in the dropdown. That way, we can avoid the user having duplicates and the situation @divyanshiGupta has showed. WDYT?

Hi @divyanshiGupta I wonder if it makes sense to disable a permission if it's already selected from the dropdown and it's present with the policies selected as a row?I think we are doing this behaviour of disabling selected users/groups in the users and groups selection, right? If user removes the permission policy row by using the '-' sign, we can enable it in the dropdown. That way, we can avoid the user having duplicates and the situation @debsmita1 has shown. WDYT?

@parvathyvr Yes I did that for add members dropdown and it makes sense to disable selected permissions for permissions dropdown as well. I have made the changes PTAL.

Hi @divyanshiGupta I wonder if it makes sense to disable a permission if it's already selected from the dropdown and it's present with the policies selected as a row?I think we are doing this behaviour of disabling selected users/groups in the users and groups selection, right? If user removes the permission policy row by using the '-' sign, we can enable it in the dropdown. That way, we can avoid the user having duplicates and the situation @debsmita1 has shown. WDYT?

@parvathyvr Yes I did that for add members dropdown and it makes sense to disable selected permissions for permissions dropdown as well. I have made the changes PTAL.

Thanks for making the changes @divyanshiGupta . LGTM!
Just to make sure-now when the user removes the row of a permission policy using '-', that particular  permission becomes enabled and can be selected from the dropdown again, right?

Hi @divyanshiGupta I wonder if it makes sense to disable a permission if it's already selected from the dropdown and it's present with the policies selected as a row?I think we are doing this behaviour of disabling selected users/groups in the users and groups selection, right? If user removes the permission policy row by using the '-' sign, we can enable it in the dropdown. That way, we can avoid the user having duplicates and the situation @debsmita1 has shown. WDYT?

@parvathyvr Yes I did that for add members dropdown and it makes sense to disable selected permissions for permissions dropdown as well. I have made the changes PTAL.

Thanks for making the changes @divyanshiGupta . LGTM! Just to make sure-now when the user removes the row of a permission policy using '-', that particular permission becomes enabled and can be selected from the dropdown again, right?

Yes @parvathyvr.
https://github.com/janus-idp/backstage-plugins/assets/20724543/25a8e57a-71a2-4abb-a8bc-8f2ada118ade

/approve


Named custom cargo profiles

Rendered

More links:

Pre-RFC discussion
A very early reference implementation (for 0.33).

Is it worthwhile keeping test and bench outputs in target/debug and target/release?

It's very helpful to be able to run test binary under gdb, or the bench binary under a profiler. These have unpredictable paths already, so a different location would be fine, but they should be persisted in an accessible location.

The RFC doesn't mention cross-compilation. Cargo changes target/release to target/<platform triple>/release when cross-compiling. Presumably dir-name would be too?

Might be orthogonal, but many times i really wished that there's a profile that build the current crate in dev mode but all its dependencies in release mode.

Yes, a different profile for the workspace and dependencies outside of the workspace would be fantastic.

I definitely want something iike this. The "Direct cargo build flags alternative" option wouldn't really change the status quo for me.
The justfile in my project boilerplate already works around the lack of this functionality by using custom CARGO_TARGET_DIR values to simulate it in tasks like kcov.
The downside is that, due to that and my justfile forcing CARGO_BUILD_TARGET to always have a value for the sake of consistency, I treat invoking cargo subcommands directly as unsupported, purely because the odds are high that they'll act as if I'd just run cargo clean.
Another former downside that wasn't specifically due to custom profiles (rather, it was about opt-level = "z" only being valid in nightly builds) but which shows how far I'm willing to go was how hacky it was for my justfile to use sed to rewrite and then restore Cargo.toml as part of the build process under certain conditions.
(On the plus side, cargo-make's @rust script runner should make it more robust to pull that trick, since I could use toml_edit for my crazy hacks.)

The dev profile receives the dir-name = "debug" attribute, so that its final outputs are emitted to target/debug, as existing Rust developers will expect this behavior. This should be added in the official documentation for the Cargo manifest, to make this fact clearer for users.
A debug profile name is not allowed, with a warning saying to use the already established dev name.

Why is it so important for the profile to be named dev that it justifies this special-casing, this hard-coded exception to letting projects define their own profile names, and this potential point of confusion?
I couldn't find a justification for that.

Do we really need pre-defined profiles for test, bench and/or doc, or can we make them obsolete?

Assuming we take it as a given that we're not going to accept the convenience regression of requiring users to do some setup before they can run cargo test and/or cargo doc, can you elaborate on what the alternative would look like?

@ssokolow:

Why is it so important for the profile to be named dev that it justifies this special-casing, this hard-coded exception to letting projects define their own profile names, and this potential point of confusion?

I couldn't find a justification for that

The main issue is backward compatibility. If the alternative is to abolish the dev profile name in favor of the debug name, it would break existing projects' assumptions about the affects of the [profile.dev] clauses to the cargo build command (without any --profile parameter). Another alternative, is to emit to a target/dev directory instead of target/debug directory, but that would break current assumptions about the default cargo build output directories. Now, if we take neither of the aforementioned alternatives and we allow for a debug profile to be defined, then unwary people may expect the default cargo build command (i.e. without any --profile parameter) to be affected by it, and be surprised when it isn't. This is the problem I've had in mind. Perhaps someone can think of a better solution.

Assuming we take it as a given that we're not going to accept the convenience regression of requiring users to do some setup before they can run cargo test and/or cargo doc, can you elaborate on what the alternative would look like?

The alternative would be for bench to use the release profile (unless --profile is specified), and for doc and test to use dev (unless --profile is specified), and to remove these predefined profiles from code and documentation.

The RFC doesn't mention cross-compilation. Cargo changes target/release to target/<platform triple>/release when cross-compiling. Presumably dir-name would be too?

Yes, that would be the expected behavior. Should update the RFC.

Might be orthogonal, but many times i really wished that there's a profile that build the current crate in dev mode but all its dependencies in release mode.

@crlf0710 @kornelski  I think this is achievable with profiles overrides (currently in nightly cargo).
Combined with this RFC's changes, it would be even better, because you could have these overrides under a custom profile, retaining the standard functionality with the dev profile.
For example:
[profile.dev-deps-release]
inherits = "release"
[profile.dev-deps-release.overrides."*"]
opt-level = 2

(See Unstable Features - The Cargo Book

The main issue is backward compatibility. If the alternative is to abolish the dev profile name in favor of the debug name, it would break existing projects' assumptions about the affects of the [profile.dev] clauses to the cargo build command (without any --profile parameter). Another alternative, is to emit to a target/dev directory instead of target/debug directory, but that would break current assumptions about the default cargo build output directories.

Ahh, yes. I'd forgotten about that existing mismatch. Hazard of putting together a project template once and then not needing to modify it much, I guess.

How about:
[profiles.debug]
real debug settings here

[profiles.dev]
inherits = "debug"
dir = "debug"

Maybe dev profile name could be used only as a fallback? If there's profiles.debug in Cargo.toml, then use that. Otherwise try profiles.dev. That would keep backwards compatibility, and allow eventually deprecating and removing the dev name.
It's for development only, so it doesn't affect crate users, and the developer will see any deprecation notices.

So the suggestion as I understand - having a debug profile defined will affect the default cargo build, cargo test, and cargo doc profile to be debug instead of dev. We can limit the emission of the warning to the case where there are customization on the dev profile.
However I am not sure it puts the dev profile on a full deprecation path, at least not during 1.x Rust, because the Cargo.toml of many old crates will probably still remain without a debug profile defined, and with dev customized.
This may be a good, but I'd feel better with more votes on the matter. Pinging @ehuss @matklad @Manishearth.

(I'm not really a cargo person, and while I've written a profile RFC before I don't have strong opinions on this. I recall the cargo team having plans about profiles, though)

@ehuss, thanks for investing the time to review!

What happens if the user specifies --release --profile=foo?
Is --release an alias for --profile=release?

I'd suggest the following:

Using --profile and --release together will emit an error unless --profile=release.
Using --release on its own will be equivalent to specifying --profile=release

Currently the profile is driven by the command, cargo target (--test uses test, --bench uses bench, --all-targets uses a mixture, etc.), and the --release flag.  Does Cargo continue to behave that way if no profile is chosen?  I'm concerned that is a little confusing, but the alternative (only using one profile) would also be problematic.

Yes. I think it would be too late to deprecate this functionality.

doc is currently unused, and I think has some issues that would prevent it from being reintroduced. I would prefer to leave out doc in the discussion here and leave it for future consideration.

Agreed.

There should be restrictions on valid profile names.  I'm thinking the same as a package name (validate_package_name) would be a good start, though maybe it should be even more restrictive?

Yes, let's take the restriction from package names: Name must not be empty, use only alphanumeric characters or - or _.

Can you add a link to the PR description to https://internals.rust-lang.org/t/strawman-pre-rfc-custom-profiles/6412 which had a very similar proposal?

Was not aware of it. Sure.

Does cargo test --profile=foo build all crates with the foo profile?  Currently cargo test is a little strange in that dependencies are built with dev/release.  I'm thinking this might be a good opportunity to change that, so that test/bench are less special.  The drawback is that it takes longer to compile if you change the test profile (since it can't share dependencies with dev), but it may be worthwhile.

It's very good that you brought this up. If I understood correctly, only the special test crate is built with the test profile all the dependencies including the current crate are built with either dev or release, depending on whether --release is provided (this includes both dependencies and dev-dependencies). This is what the Cargo docs say:
# The release profile, used for `cargo build --release` (and the dependencies
# for `cargo test --release`, including the local library or binary).

The existing functionality has the advantage that in cargo test --release the a test crate code which makes heavy use of dependencies for testing runs fast due to the optimized dependencies, while the test crate itself is still in debug mode, having more checks and emitting full backtraces for itself. Do we want to regress on this behavior? It may depends on how much logic people put inside their test crates, and we may need more data or user feedback for deciding.

Do we want to regress on this behavior? It may depends on how much logic people put inside their test crates, and we may need more data or user feedback for deciding.

I'm not sure. I'll ask the team if there's any opinion on this.

Does cargo test --profile=foo build all crates with the foo profile?  Currently cargo test is a little strange in that dependencies are built with dev/release.

Discussed this with the team. I think we all agree that we should remove the special casing for test/bench, and make them behave like a normal profile (that is, they don't treat dependencies differently).  If someone really wants to only apply profile settings to the local crate, they can use "*" profile override to achieve something close to the old behavior.  If you want to add that as a note to this RFC, that would be fine.
I'd like to move this forward, as I think we're all :+1: on the basic concept of adding named profiles.
@rfcbot fcp merge

@rfcbot reviewed

Thanks! Regarding this discussion:

Maybe dev profile name could be used only as a fallback? If there's profiles.debug in Cargo.toml, then use that. Otherwise try profiles.dev. That would keep backwards compatibility, and allow eventually deprecating and removing the dev name.
It's for development only, so it doesn't affect crate users, and the developer will see any deprecation notices.

So the suggestion as I understand - having a debug profile defined will affect the default cargo build, cargo test, and cargo doc profile to be debug instead of dev. We can limit the emission of the warning to the case where there are customization on the dev profile.
However I am not sure it puts the dev profile on a full deprecation path, at least not during 1.x Rust, because the Cargo.toml of many old crates will probably still remain without a debug profile defined, and with dev customized.
This may be a good, but I'd feel better with more votes on the matter. Pinging @ehuss @matklad @Manishearth.

It's the main point still standing, i.e whether to have this fallback or keep the RFC as it is. I'm assuming this can be a version 2.0 material?

Huzzah! This RFC has been merged!
Tracking issue: https://github.com/rust-lang/cargo/issues/6988


Add import.meta transform in Bundler

The Bundlers assumes modules in and modules out, but by moving the location of files it changes the answer of import.meta. The Bundler should have it's own import.meta transform that can assume import.meta support in the output, but just fixes up the .url property so that it returns the original file URL.
So
import.meta
should become:
{...import.meta, url: new URL(relativePathFromBundleToOriginal, import.meta.url).toString()}

Do I understand correctly that with this fix we will not be able to check import.meta.url to detect whether the app is bundled or not as I was assuming, e. g. like this:
let isUnbundled = this.importPath.endsWith(`${this.constructor.is}.js`);

Apparently my assumption was wrong, so I'll close #204 in favor of this issue.
There is a regression in comparison with HTML imports, though: we can do recursive HTML imports check and detect whether the specific import has been loaded or not, but AFAIK that is not possible with the current native ES modules implementation.

Do I understand correctly that with this fix we will not be able to check import.meta.url to detect whether the app is bundled or not

Correct. import.meta.url is used in Polymer elements to resolve URLs to assets correctly. It needs to return the original URL of the module.
We're considering adding something like import.meta._bundleUrl to point to the actual bundled module's URL.

There is a regression in comparison with HTML imports, though: we can do recursive HTML imports check and detect whether the specific import has been loaded or not, but AFAIK that is not possible with the current native ES modules implementation.

I don't quite understand this. What check could you do with HTML imports?

@justinfagnani there is the code we're currently using: https://github.com/vaadin/vaadin-development-mode-detector/blob/master/vaadin-development-mode-detector.html#L17
The idea is that, if the app is bundled, then Polymer should be included into some bundle (usually the app shell, when using CLI) and the polymer-element.html should not be imported.

That seems very unnecessary. Bundler will take care of rewriting imports to the correct bundle, so you don't need to remove the import of polymer-element.html.

https://github.com/Polymer/tools/pull/300 <- should address

@justinfagnani the code which I referenced above is not meant to remove the import, but to detect whether the app is bundled or not, based on it's presence.

#300 fixed this and its now merged into master. Closing.

@web-padawan if you have needs beyond having bundler transform instances of import.meta in bundled modules replaced with a stand-in value that provides the same values, including a preserved value for url, let's open a new issue to track that.

"polymer-cli": "^1.7.7",
getting the below error on Opera 54 with es5-bundled.
esm-bundled works fine.

@ranjeet-choudhary es5-bundled should be transforming all instances of import.meta -- Can you verify whether this is still an issue with latest polymer-cli?


｢my @a = 1 … 9999999｣ is not lazy, explain it somewhere

This is a continuation of RT #130480.
Our docs say:

The sequence operator is a generic operator to produce lazy lists.

Well, is it? Seems like it produces Seq-s, not lazy lists. Lazy lists can be obtained, for example, from .list-ing a Range (.. operator, not ...), or by lazy-ing a Seq.
And getting back to the ticket:
my @a = 1 … 9999999

↑ This is not lazy at all. But with our current documentation it is fair to assume that it should be lazy.
We should improve our docs on … first. Then perhaps document another trap?

Ah, another thing to note is that this is actually lazy:
my @a = 1 … ∞

Also, some discussion: https://irclog.perlgeek.de/perl6/2017-01-02#i_13836946

:+1:

my \a = 1 … 9999999;
Is also lazy. This should go into containers with a link from ....

Minimum number? No.

Well, the documentation says it produces lazy lists. I guess that's all wrong.
But what's the alternative? It produces lazy lists when it's used outside a variable or when numbers are humongous? Is there a test for that in roast?

There are a few tests in roast. Let me see what I can glean from that.

But what's the alternative?
FWIW

> (1 … 9999999).is-lazy
False
> (1 … 9999999).lazy.is-lazy
True

Lazy lists are only generated by … if the endpoint is infinity. I just
changed that in the documentation. Please check that it's correct now. It
was simply wrong in the initial description.

I have described it according to the roast tests, which only return lazy
sequences if the endpoint is */Inf. Please check out the new description,
flag what's wrong and change the issue accordingly, because according to
the roast test, 1 … 9999999 should never be lazy.

Still not right, it doesn't matter if the endpoint is Inf or not, everything will be generated on demand.
Try something like this maybe to see it: my $x := (0, {say “I’m here $_”; $_ + 1} … 42); say $x[3]

My 2¢: use term "lazy" less.
It's really adds a lot of confusion as it can mean "values generated on-demand" (as opposed to right-away) and all of our Seqs are like that, and it can also mean "infinite-like", which is what .is-lazy flag represents.

The … always produces Seq that produce values on-demand
Assignment to @ is "mostly-eager" and will reify Seqs immediately, unless they're infinite-like, in which case it'll reify them only on-demand

Here's an example that shows this. The first Seq has a * endpoint, so it's infinite-like (marked as .is-lazy) and you can see assigned is printed before reifying: The second Seq only goes up to 3 so it's not infinite-like and the assignment reifies it right away,
$ perl6 -e 'my @a = {say "reifying"; ++$} … *; say "assigned"; say @a[^2]'
assigned
reifying
reifying
(1 2)

$ perl6 -e 'my @a = {say "reifying"; ++$} … 3; say "assigned"; say @a[^2]'
reifying
reifying
reifying
assigned
(1 2)

You can also force non-infinite-like Seqs to be treated as infinite-like with the lazy routine call:
$ perl6 -e 'my @a = lazy ({say "reifying"; ++$} … 3); say "assigned"; say @a[^2]'
assigned
reifying
reifying
(1 2)

And you can see that it's the assignment to @ var that causes immediate reification of non-infinite-like Seqs and that they normally produce values on-demand with this example:
my $s := ({say "reifying"; ++$} … 3); say "assigned"; say $s[^2]'
assigned
reifying
reifying
(1 2)

"assigned" is printed before any values were generated.

2018-04-20 18:39 GMT+02:00 Zoffix Znet<EMAIL_ADDRESS>
My 2¢: use term "lazy" less.
It's really adds a lot of confusion as it can mean "values generated
on-demand" (as opposed to right-away) and all of our Seqs are like that,
and it can also mean "infinite-like", which is what .is-lazy flag
represents.

The … always produces Seq that produce values on-demand
Assignment to @ is "mostly-eager" and will reify Seqs immediately,
unless they're infinite-like, in which case it'll reify them only on-demand

But assignment is outside the scope of this particular issue and paragraph.
Such as it is now, it does avoid mentioning "lazy" in favor of "on
demand".

Here's an example that shows this. The first Seq has a * endpoint, so
it's infinite-like (marked as .is-lazy) and you can see assigned is
printed before reifying: The second Seq only goes up to 3 so it's not
infinite-like and the assignment reifies it right away,
$ perl6 -e 'my @a = {say "reifying"; ++$} … *; say "assigned"; say @a[^2]'
assigned
reifying
reifying
(1 2)
$ perl6 -e 'my @a = {say "reifying"; ++$} … 3; say "assigned"; say @a[^2]'
reifying
reifying
reifying
assigned
(1 2)
You can also force non-infinite-like Seqs to be treated as infinite-like
with the lazy routine call:
$ perl6 -e 'my @a = lazy ({say "reifying"; ++$} … 3); say "assigned"; say @a[^2]'
assigned
reifying
reifying
(1 2)
And you can see that it's the assignment to @ var that causes immediate
reification of non-infinite-like Seqs and that they normally produce values
on-demand with this example:
my $s := ({say "reifying"; ++$} … 3); say "assigned"; say $s[^2]'
assigned
reifying
reifying
(1 2)
"assigned" is printed before any values were generated.

Maybe add "reification" to glossary and/or something to the traps page.

Maybe add "reification" to glossary and/or something to the traps page.

It (or a form of it) is already there: https://docs.perl6.org/language/glossary#Reify
Doesn't show in search, presumably due to that indexing bug.

I didn't know that page was also affected...

Anyway, if no further work is needed on this particular issue, allow me to close it if you don't want to change the title or repurpose it for something else.


Add Licence transforms to Code Superpipeline.

Why are these changes needed?
Update the KFP super-pipeline for code modules with the new license transforms.
Related issue number (if any).
#388

The PR is blocked by https://github.com/IBM/data-prep-kit/pull/257