SeaORM SQLite types are now non lossy

See https://github.com/SeaQL/sea-query/pull/735/files
we can now attempt to have sqlite back as the primary “initial app” store, as it should now keep information about timestamp columns.
In the past the SQLite implementation lost type information as the migrations were applied and so when generating back entities we got compilation errors. This made us move to Postgres in development as a standard, and move SQLite into the shadows as “supported but..”.
We can now return SQLite to development configuration in favor of helping people get started more easily with less friction.

This would be awesome!

@jondot I think SeaORM needs to reach v0.31.0 at least (v0.31.0-rc4 as of writing), the last release v0.30.7 doesn't include the aforementioned commit. Maybe there are other changes that loco needs to adapt to.

I've just finished testing this out, actually, the Sqlite variant works well, it required upgrading sea-orm-cli to rc3 as well, and types get discovered correctly.
Where I bumped into a wall is seamlessly moving between Postgres and Sqlite.

Postgres generated DateTimeWithTimezone
Sqlite generated DateTimeUtc

And since we have user-land code, these types could not co-exist. I played with everything a bit but had to take a guess, where even if I use sea-orm-cli it doesn't use the same bits the sea-orm core is using, which is why I was getting this difference. Since I am in no-mans-land (manually upgrading to rc versions all around), I'm OK with this, and I'll just park this issue and wait for sea-orm to advance a bit more with their versions before retrying.
/cc @billy1624
I'm optimistic this will eventually work and we'll return to co-driving both Sqlite and Postgres

Hey everyone, that's correct! SQLite types is now non-lossy

https://github.com/SeaQL/sea-query/blob/71055a3ff53e3f673e902a8c53817866a945d800/src/backend/sqlite/table.rs#L163-L167
https://github.com/SeaQL/sea-query/pull/735

Postgres generated DateTimeWithTimezone

I'm pretty sure the CLI before generates Postgres columns as DateTimeWithoutTimezone with the time being automatically converted into UTC (which incidentally matches SQLite's DateTimeUtc).
Not sure if the latest CLI still generates this data type since I have ditched the CLI in favor of editing the migration files myself.


Fix potential risk of STM32L4XX uart send mechanism

Fix potential risk of STM32L4XX uart send mechanism
1. Use "post" mechanism to send out UART data
2. One task would not send out UART until all data of last frame send out, when the UART in READY status
3. Not block in loop only happen UART send fail

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


Update for launch

I use this command to change everything to not be executable: find * -type f -perm '+rwx' | xargs chmod -x


treewide: use auto diskSize for make-disk-image

since we now have auto size for disk image we should actually use them where its convenient.
what I did previously: https://github.com/NixOS/nixpkgs/pull/89331

@ofborg eval

Partially reverted in https://github.com/NixOS/nixpkgs/pull/120481, but I suspect this whole PR should be reverted until the problem is resolved: the auto value uses the bytes on disk value from du, not the length of the file. Since most of our builders run ZFS with compression, these images fail to build.


Container With Most Water

https://leetcode.com/problems/container-with-most-water/

Please assign this to me

@Zaman3027  go ahead 👍


Does the library support Qery?

Hi
Looking at the library to use to talk to serf. I notice there is a client.event() function. Do you support serf query as well as events?
Thanks

Hey @donmstewart. If we don't, more than happy to review a PR adding such functionality!


[ Testing ] Improve logging in integration/unit tests

Description
As a user of the testing harness I'd like to (1) know what commands to run in the case of linting errors and (2) see a dump of the parsed terraform plan/output in JSON format to aid in debugging failed tests
Acceptance Criteria
Reference: [Done-Done Checklist] (https://github.com/Microsoft/code-with-engineering-playbook/blob/master/Engineering/BestPractices/DoneDone.md)

[ ] If a linting command fails, the command that can be used to fix the errors is displayed
[ ] A dump of the parsed terraform plan/output in JSON format is displayed to stdout

Closing in favor of https://github.com/microsoft/orion/issues/21


chore(ndm): add ndm charts

This PR adds helm charts for standalone NDM installation.
NDM  component will have its own service account and RBAC. So following Kubernetes resource are
created for NDM that is not shared with other OpenEBS components:

ClusterRole: ( Default name is openebs-ndm)
ClusterRoleBinding: ( Default name is openebs-ndm)
ServiceAccount : ( Default name is openebs-ndm)

NDM Daemonset default name : openebs-ndm
NDM deployment default name: openebs-ndm-operator
NDM configmap default name:  openebs-ndm-config
Signed-off-by: Ashutosh Kumar<EMAIL_ADDRESS>Special notes for your reviewer:

Currently, for this chart, the namespace where NDM needs to be deployed needs to be created prior.
(Need some discussion and should be fixed in this PR)

There has been a change in match label selectors for the NDM pods. See following for the comparison

Older Helm Chart Based NDM Daemon Set:
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: {{ template "openebs.fullname" . }}-ndm
  labels:
    app: {{ template "openebs.name" . }}
    chart: {{ template "openebs.chart" . }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
    component: ndm
    openebs.io/component-name: ndm
    openebs.io/version: {{ .Values.release.version }}
spec:
  updateStrategy:
    type: "RollingUpdate"
  selector:
    matchLabels:
      app: {{ template "openebs.name" . }}
      release: {{ .Release.Name }}
      component: ndm
  template:
    metadata:
      labels:
        app: {{ template "openebs.name" . }}
        release: {{ .Release.Name }}
        component: ndm
        openebs.io/component-name: ndm
        name: openebs-ndm
        openebs.io/version: {{ .Values.release.version }}

Current Helm Chart Based NDM Daemon Set:
apiVersion: apps/v1
kind: DaemonSet
metadata:
  annotations:
    deprecated.daemonset.template.generation: "1"
    meta.helm.sh/release-name: pascal
    meta.helm.sh/release-namespace: openebs
  creationTimestamp: "2020-08-26T15:28:33Z"
  generation: 1
  labels:
    app: openebs-ndm
    app.kubernetes.io/managed-by: Helm
    chart: openebs-ndm-0.8.0
    component: ndm
    heritage: Helm
    openebs.io/component-name: ndm
    openebs.io/version: 0.8.0
    release: pascal
spec:
  selector:
    matchLabels:
      app: openebs-ndm
      component: ndm
      release: pascal
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: openebs-ndm
        chart: openebs-ndm-0.8.0
        component: ndm
        heritage: Helm
        name: openebs-ndm
        openebs.io/component-name: ndm
        openebs.io/version: 0.8.0
        release: pascal

Older Helm Chart Based NDM Operator:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ template "openebs.fullname" . }}-ndm-operator
  labels:
    app: {{ template "openebs.name" . }}
    chart: {{ template "openebs.chart" . }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
    component: ndm-operator
    openebs.io/component-name: ndm-operator
    openebs.io/version: {{ .Values.release.version }}
    name: ndm-operator
spec:
  replicas: {{ .Values.ndmOperator.replicas }}
  strategy:
    type: "Recreate"
    rollingUpdate: null
  selector:
    matchLabels:
      app: {{ template "openebs.name" . }}
      release: {{ .Release.Name }}
  template:
    metadata:
      labels:
        app: {{ template "openebs.name" . }}
        release: {{ .Release.Name }}
        component: ndm-operator
        name: ndm-operator
        openebs.io/component-name: ndm-operator
        openebs.io/version: {{ .Values.release.version }}

Current Helm Chart Based NDM operator:
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
    meta.helm.sh/release-name: pascal
    meta.helm.sh/release-namespace: openebs
  creationTimestamp: "2020-08-26T15:28:33Z"
  generation: 1
  labels:
    app: openebs-ndm-operator
    app.kubernetes.io/managed-by: Helm
    chart: openebs-ndm-0.8.0
    component: openebs-ndm-operator
    heritage: Helm
    openebs.io/component-name: openebs-ndm-operator
    openebs.io/version: 0.8.0
    release: pascal
spec:
  replicas: 1
  selector:
    matchLabels:
      app: openebs-ndm-operator
      component: openebs-ndm-operator
      release: pascal
  strategy:
    type: Recreate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: openebs-ndm-operator
        chart: openebs-ndm-0.8.0
        component: openebs-ndm-operator
        heritage: Helm
        openebs.io/component-name: openebs-ndm-operator
        openebs.io/version: 0.8.0
        release: pascal

Notable Changes As Part of Best Practice:

The labels of ndm daemonset and ndm operator yaml comes from helper.tpl. This is more maintainable and less error prone.
Clean up on image values is segregated in Values.yaml file.

Outputs ( Installing NDM )
$ kubectl create ns openebs
namespace/openebs created

$ kubectl get ns
NAME              STATUS   AGE
default           Active   97d
kube-node-lease   Active   97d
kube-public       Active   97d
kube-system       Active   97d
openebs           Active   7s

$ helm install pascal ./ndm
NAME: pascal
LAST DEPLOYED: Wed Aug 26 20:58:33 2020
NAMESPACE: openebs
STATUS: deployed
REVISION: 1
TEST SUITE: None
# Service Account
$ kubectl get sa -n openebs --show-labels
NAME          SECRETS   AGE    LABELS
default       1         8h     <none>
openebs-ndm   1         2m5s   app.kubernetes.io/managed-by=Helm

# Cluster Role
$ kubectl get clusterrole pascal-openebs-ndm --show-labels
NAME                 CREATED AT             LABELS
pascal-openebs-ndm   2020-08-26T15:28:33Z   app.kubernetes.io/managed-by=Helm

# Cluster Role Binding
$ kubectl get clusterrolebinding pascal-openebs-ndm --show-labels
NAME                 ROLE                             AGE     LABELS
pascal-openebs-ndm   ClusterRole/pascal-openebs-ndm   3m31s   app.kubernetes.io/managed-by=Helm

# CRDs
$ kubectl get crd
NAME                           CREATED AT
blockdeviceclaims.openebs.io   2020-08-26T14:59:29Z
blockdevices.openebs.io        2020-08-26T14:59:29Z

# NDM Daemonset
$ kubectl get ds -n openebs --show-labels
NAME                 DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE   LABELS
pascal-openebs-ndm   3         3         3       3            3           <none>          87s   app.kubernetes.io/managed-by=Helm,app=openebs-ndm,chart=openebs-ndm-0.8.0,component=ndm,heritage=Helm,openebs.io/component-name=ndm,openebs.io/version=0.8.0,release=pascal

# NDM operator
$ kubectl get deploy -n openebs --show-labels
NAME                          READY   UP-TO-DATE   AVAILABLE   AGE     LABELS
pascal-openebs-ndm-operator   1/1     1            1           6m14s   app.kubernetes.io/managed-by=Helm,app=openebs-ndm-operator,chart=openebs-ndm-0.8.0,component=openebs-ndm-operator,heritage=Helm,openebs.io/component-name=openebs-ndm-operator,openebs.io/version=0.8.0,release=pascal

# NDM Pods
k8s@master1-ashutosh:~/go_projects/src/openebs/charts/charts$ kubectl get pod -n openebs --show-labels
NAME                                          READY   STATUS    RESTARTS   AGE   LABELS
pascal-openebs-ndm-dkxcf                      1/1     Running   0          7m    app=openebs-ndm,chart=openebs-ndm-0.8.0,component=ndm,controller-revision-hash=86589c47bc,heritage=Helm,name=openebs-ndm,openebs.io/component-name=ndm,openebs.io/version=0.8.0,pod-template-generation=1,release=pascal

pascal-openebs-ndm-gpg7v                      1/1     Running   0          7m    app=openebs-ndm,chart=openebs-ndm-0.8.0,component=ndm,controller-revision-hash=86589c47bc,heritage=Helm,name=openebs-ndm,openebs.io/component-name=ndm,openebs.io/version=0.8.0,pod-template-generation=1,release=pascal

pascal-openebs-ndm-operator-db6df758d-5wv7m   1/1     Running   0          7m    app=openebs-ndm-operator,chart=openebs-ndm-0.8.0,component=openebs-ndm-operator,heritage=Helm,openebs.io/component-name=openebs-ndm-operator,openebs.io/version=0.8.0,pod-template-hash=db6df758d,release=pascal

pascal-openebs-ndm-pk58h                      1/1     Running   0          7m    app=openebs-ndm,chart=openebs-ndm-0.8.0,component=ndm,controller-revision-hash=86589c47bc,heritage=Helm,name=openebs-ndm,openebs.io/component-name=ndm,openebs.io/version=0.8.0,pod-template-generation=1,release=pascal

Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[ ] Variables are documented in the README.md
[ ] Title of the PR starts with chart name (e.g. [stable/openebs])

Each repo will have its own charts, and PR https://github.com/openebs/node-disk-manager/pull/488, with same set of changes has been merged in NDM repository.


loading screens (again) sorry :(

Describe your bug here.
So i fixed the 4 errors that the powershell gave me now its giving me this error
source/Cache.hx:1 0 0: characters 3-6 : Unexpected for

if you can help please do!
this is my Cache file
Cache.zip
also im not on 5.1 im on the version with shaders
Command Prompt/Terminal logs (if existing)
source/Cache.hx:100: characters 3-6 : Unexpected for

had to make the 1 0 0 spaced so it wont be an emoji
Are you modding a build from source or with Lua?
Source
What is your build target?
Windows
Did you edit anything in this build? If so, mention or summarize your changes.
nope

Why would you label this as a bug

Why would you label this as a bug

dont know but i fixed it

hey what is the custom build with shaders?

hey what is the custom build with shaders?

its in psych engine runs


Link changes

One link I cant resolve: /home/evaw/evaw/workspace/paperspace-automation/Graphcore-Pytorch-fork/schnet-graph-network/static_resources/schnet_arch.png NON-EXISTENT

Got lost from the branch: https://github.com/graphcore/Graphcore-Pytorch-fork/blob/schnet-notebook/get-started/static_resources/schnet_arch.png
Can you add it back in?


Remove Schema Object example and Media Type example

There are too many types of examples currently in OpenAPI, v3.1 is going to see another one come in as part of JSON Schema 2019-09.
In OpenAPI v3.1, here are all the places you could put examples just for a response:
/infinite-examples:
  get:
    operationId: infinite-examples
    responses:
      "200":
        description: OK
        content:
          application/json:
            schema:
              properties:
                name:
                  type: string
                  # OpenAPI Schema Object Example
                  example: stowford
                coordinates:
                  description: We couldn't pick a format for coordinates so we support
                  pretty much all of them.
                  # JSON Schema Examples from 2019-09
                  examples:
                  - "52.377956, 4.897070"
                  - [52.377956, 4.897070]
                  - { lat: 52.377956, lon: 4.897070 }
              required:
                - name
                - coordinates

              # OpenAPI Schema Object Example (but for an object)
              example:
                name: freddy
                coordinates: "52.377956, 4.897070"

            # OpenAPI Media Type Example
            example:
              name: finn
              coordinates: "52.377956, 4.897070"

            # OpenAPI Media Type Examples
            examples:
              arbitrary example name:
                value:
                  name: finns evil twin
                  coordinates: "52.377956, 4.897070"

Thankfully "OpenAPI Media Type Example" and "OpenAPI Media Type Examples" are a xor so its always going to be one or the other, but this is still really complex for tool maintainers to support. Over at Stoplight it's caused untold confusion, and we're still not quite supporting all of them correctly despite various attempts to get it right, and with v3.1 adding more it's just going to make our tooling and our user interfaces more complicated.
We can cope with being confused, but I think it's generally bad for the ecosystem: tooling vendors and end users alike, to have umpteen different ways to do the same thing.
So, I propose getting rid of 2/5 types of example:

example in the Schema Object
example in the Media Type / Parameters

1 seems easy. Yes, it's a little more typing to write:
examples:
- stowford
# or
examples: [stowford]

instead of
example: stowford

but we're already deprecating it, and just like nullable, let's kill it instead of dragging it out.

~Deprecated: The example property has been deprecated in favor of the JSON Schema examples keyword.~ 👋

As for media type example and parameter example, that's an easy one too, because again folks can use examples in the OpenAPI form: Map[string, [Example Object](#exampleObject) \| [Reference Object](#referenceObject)], or they can do example stuff inside the schema (using examples in the JSON Schema-ish way).
Whatever we do, taking an axe to some of these 5 approaches will be helpful for end users and tooling vendors who are just tying to figure out how to show examples, in docs, mocks, etc.
For more insight into the plethora of examples we currently have, I done a giant blog post. You'll laugh. You'll cry. You'll have questions. https://phil.tech/2020/openapi-examples/

Some previous discussion in #953

I'm not sure how multiple examples would be used in practice, so I think I'm missing the value of making this change. Currently, OpenAPI expects a field to have a type, a description, an example (shaped like the type), maybe a default. It's simple to understand and I run into a lot of newcomers to OpenAPI for whom this is only just simple enough. If it's the general aim to adopt as much of a JSON Schema approach as possible then changing to match their example format could make some sense, but I'm not sure I've seen the usefulness for OpenAPI-only users. Especially not if those users aren't using a lot of helper tooling.
Where it does make sense to have multiple examples is in the responses, where more than one thing or type of thing might come back - it makes sense to me that we have multiple examples in that context. Does anyone have some use cases in mind where having multiple examples values on each field would be helpful? I am currently uneasy about this change so tell me what I haven't understood!

@lornajane When we debated adding example or examples to JSON Schema years ago, we settled on examples as people had reasons for wanting it.  It is sufficiently long ago that I do not recall the reasons, but if we want to both conform to standard JSON Schema (avoid contradicting the spec) and provide clear guidance on usage (there should be one right way to do it, if possible), then that means examples.  We're not going to go change that 4 drafts and 5 years after adding it when it's never been reported as a problem to us over the years.  Goodness knows people report plenty of other things 😅
Nothing's stopping people from supporting example if they're dead set on it, but the proposal here is that one recommendation is better than many, if you only want one that satisfies the two constraints I listed, then that's the one that it has to be.
I don't mean to be a grump, but no one gets everything they want in this.  Sometimes it's more important to look at what constraints we want to satisfy than to look at the specific options.  Then the question is "do we want to violate these constraints?" which is simpler than "which of these almost-the-same options, all of which have people who want or don't want them should we fight over for the next month based on personal opinions?"  Because in my experience that's what happens.  We can argue over how burdensome it is to add an s and put [] around the value or we can choose our constraints.
If we don't care about those two constraints then just leave it all in there I guess.

From TSC meeting:

example in OpenAPI Schema object should be seriously considered for removal.  No objections raised except for Lorna who is concerned about removing example for a property.
example in Media Type Object should be less seriously considered for removal.  The concern is about about the impact on readability/writeability.

Please add comments..

Both @handrews comment above and today's discussion in the TSC call are illuminating and helpful (also if you didn't read Phil's post, it's well worth it). We reflected a bit on who is our main "target" when the needs of either not-specialist developer or not-complex APIs run into the depth of people who work on very complex projects, using JSON Schema. TSC by its very nature is mostly (and should be) populated by the latter group and I feel we do lose sight of the first group. This change definitely doesn't favour "ordinary" API publishers, but maybe "just pick one" is the best approach for both groups!
If we drop one example keyword, the simplest from an education point of view is to drop them all - the different structures of examples, some with and some without keys, is still a stumbling block but that is already here, we're not degrading anything. Can these changes be handled by conversion tooling? Are we planning to add this into the 3.1 release?

We reflected a bit on who is our main "target" when the needs of either not-specialist developer or not-complex APIs run into the depth of people who work on very complex projects, using JSON Schema. TSC by its very nature is mostly (and should be) populated by the latter group and I feel we do lose sight of the first group.

There's a bit of a confusing statement over there, suggesting that JSON Schema is for more complex projects. I'm not sure that's a fair differentiation. Yes later drafts of JSON Schema have some more powerful keywords available that were added after the version of JSON Schema that OpenAPI pegged to for v3.0, but it's not a "power users only" type of thing. OpenAPI suggests you can use JSON Schema keywords, so people consider the schema object to be JSON Schema, so they google for "how to do foo in JSON Schema" then do things that will make some tools fall over, and others support it. So more tools support an awkward mixture of both syntax, which perpetuates the idea that it's actually JSON Schema even though its not...
Beginners suffer the most from all this confusion, as they have to navigate the complexities of varying compatibility of different tools.
So JSON Schema is not for advanced people, its for anyone. Furthermore this change doesn't ignore beginners, it is focused on giving them one less approach to chose between, with the result of whatever we pick being clearly documented in the Getting Started Documentation so nobody has to be confused, and google around, finding disparate information based on all the different types of examples in different places across different versions of OAS2 and OAS3 and JSON Schema from blog posts going back years and years.
There's a few groups, personas, that I see.

People writing OpenAPI YAML by hand
who are not very experienced, no idea what to write, keep googling things, finding mixed information
who are more experienced, who want to wear their keyboard out as little as possible writing the least YAML
People writing OpenAPI with a GUI, DSL, or Annotations

Persona 1.i are being solved with Getting Started documentation. 1.ii are going to have to suck it up and add a newline and a - for schema object examples (which hasn't caused any problems for the JSON Schema community) and use a dictionary for their examples (which adds the ability to have example pairs) or if that's annoying they can use schema examples...
Persona 2 see no change at all.
Whether OpenAPI is aimed to be easier for humans or computers to use is then a separate conversation, because I will NEVER remember if its:

content.responses.application/json.200.schema
responses.application/json.content.200.schema
responses.application/json.200.content.schema
responses.application/json.content.200.schema

If we want to target OpenAPI to be easy for humans to read, write, and memorize, we need to start from scratch. That may have been an objective for Swagger 1.x but IMHO I think that objective might have failed somewhere between v2 and v3. Not a unique opinion.
This doesn't mean we should just throw readability out and always do everything in the more verbose way possible, but when it comes to a choice of "less typing" vs "improved functionality" we seem to pick the latter.

I feel like this discussion is losing track of a key issue here:  @lornajane is raising a very important general point.  However, in this specific case, putting square brackets around something because it's a list and not a scalar is not a significant amount of complexity.  It is not an unusual data structure.  The syntax is simple and universal across all usages of JSON and many other systems.  It is not being used in a non-intuitive way.  It is exactly what it looks like: a list of examples.
When we talk about beginner vs advanced, "only one way to do it" is definitely pro-beginner.  And while "scalar" may technically be easier than "list", I assert that particularly to a new beginning-level user, it is not a problem at all.
It is mildly confusing and more complex to people who are used to example, but in time this will go away and people will learn examples from the start.  That steady state is what we should design for.
I would be more inclined to weigh complexity if we were, for example, talking about more options for explode, or a new way to organize Response Objects.  Those things are not standard JSON data structures with standard JSON meanings.


Errors in Dev tools while navigating Search results

I see following errors in console while navigation search results in today's insiders

Looks like a check for event.payload being null is missing.


Laravel 5.5 internal requests always returning JsonResponse

Q
A

Bug?
yes

New Feature?
no

Framework
Laravel

Framework version
5.5.14

Package version
v2.0.0-alpha1

PHP version
7.1.6

Actual Behaviour
When migrated from Larvel 5.4 to 5.5 the internal requests don't pass through the Eloquent (or any other) objects anymore, a JsonResponse object is now being returned by Illuminate/Routing/Router::toResponse(). In Laravel 5.4 this returned an Illuminate/Http/Response object. Which seems to be the source of the issue.
Expected Behaviour
Getting the Eloquent (or any other) object directly on internal requests.
Steps to Reproduce
Dumping any Eloquent result via an api internal request
// Webroute
$dispatcher = app('Dingo\Api\Dispatcher');
Route::get('/testapi', function () use ($dispatcher) {
$data = $dispatcher->get('api/testapi');
dump($data);
});
...
// Api Route
$api->get('testapi', 'Api\TestController@index');
...
// TestController
public function index()
{
$data = User::first();
return $data;
}
Possible Solutions
Not sure about an solution.

I found this problem too and I solved by creating a class and using it as a response to API http call.
In your endpoint controller
return new APIResponse([     		'status_code' => $code,     		'message' => $msg,     		'errors' => $errors     	], $code);
The class to use
`
class APIResponse extends \Symfony\Component\HttpFoundation\Response {
public function setContent( $content ) {
    $this->content = $content;
    $this->setEtag(sha1(json_encode($this->content)));
    $this->headers->set('Content-Type', 'json');
    return $this;
}

public function getContent()
{
    if (defined('INTERNAL_REQUEST')) {
        return $this->content;
    }
    return json_encode($this->content);
}

public function getOriginalContent() {
    return $this->content;
}

public function sendContent() {
    echo json_encode($this->content);
}

}`
to retrieve the eloquent model (or collection) you must define a costant in your view controller
if (!defined('INTERNAL_REQUEST')) define('INTERNAL_REQUEST', "true");
I know it's ugly to use constants, there are better solutions.

Same problem...
However @Vijon, it's not clear to me how you solved the problem

Anyone could help solving this trouble?

Hi @fede91it
...I think markdown cutted some piece of my (old) code.
I resolved this issue by extending the Symfony HTTP response class and using it when the API controller methods want to output something.
Example:
class APIController {
        public function wantOneUser( $id ) {
             $user = User::findOrFail($id);
             return APIResponse( [
                   'user' => $user
             ]);
        }
}

the APIResponse is
class APIResponse extends \Symfony\Component\HttpFoundation\Response {

    public function setContent( $content ) {
        $this->content = $content;
        $this->setEtag(sha1(json_encode($this->content)));
        $this->headers->set('Content-Type', 'json');
        return $this;
    }

    public function getContent()
    {
        if (defined('INTERNAL_REQUEST')) {
            return $this->content;
        }
        return json_encode($this->content);
    }

    public function getOriginalContent() {
        return $this->content;
    }

    public function sendContent() {
        echo json_encode($this->content);
    }
}

the ugly part is that you must define a constant such this
public function call( $routeName, $params = null, $data = null ) {
        if (!defined('INTERNAL_REQUEST')) define('INTERNAL_REQUEST', "true");
        // ^^^^^^ YOU MUST DEFINE THIS
        $dispatcher = app('Dingo\Api\Dispatcher');
        $router = app('Dingo\Api\Routing\Router');
        ...
        ...
        ...

I'll try thanks!
Any idea why no one of official developers looked at this bug since October 2017??

Maybe it's not really a bug, don't know

In my opinion, it's a serious bug.
If an Eloquent Collection is converted into an array it loses all the functionality of the model, dynamic attributes for example.

@skaero how do you apply your middleware to internal requests? The middleware doesn't trigger

Hey guys
I had a look at the dingo code, and it seems like this particular change is in Laravel entirely and not anything dingo related, so I'm not sure it is a "bug" in dingo.
However at the same time, I am not sure I see the problem here. If you have a situation where you need the raw result (let's say collection returned) of a request, you could abstract that into a service call, and call the same service function in both controllers. This way you also save on the overhead of having to instantiate a new controller just for that functionality.
I will write a short example in case it is unclear
`
ServiceClass {
public function getEntities() {
...
return $collection;
}
}
....
SimpleController {
public function getAllEntities() {
$collectionOfEntities = $this->serviceClass->getEntities();
return $this->response->collection($collectionOfEntities, ...);
}
}
ComplexController {
public function doSomething() {
$collectionOfEntities = $this->serviceClass->getEntities();
......
return $this->response->whatever()...
}
}
`
Keen to hear any thoughts on that. Probably this is an important issue to figure out before tagging 2.0.0 final.

@fede91it You need to add that middleware to all of your API routes not to the request where you actually make the api call.
@specialtactics That would involve rewriting the entire app to support that and you would loses all of the dingo functionality of being able to specify the user, domain, and api version.

@skaero @fede91it  and others, I have done a simple test to prove the bug, but I seem to get a collection returned.
You can inspect here:
https://github.com/specialtactics/l5-api-boilerplate-demo/blob/master/app/Http/Controllers/ForumController.php
https://github.com/specialtactics/l5-api-boilerplate-demo/blob/master/app/Http/Controllers/PostController.php
This is a totally clean repo with the latest version of the dingo package. I actually have some boilerplate code to fix this exact problem for the post endpoint, but even after uncommenting it, it still returns the post object.
I am wondering if you can provide an example codebase with the latest version of this package / laravel to demonstrate the error? I have actually had it before as well so I don't doubt it exists (or did), but I seem to have a hard time reproducing it locally.

@skaero YOU GOT IT. It works like a charm! Excellent job!

@fede91it Can you confirm if this is still an issue in the latest version of dingo? (2.0.1).
And if it is, would you mind sharing any code samples?

Yes, same issue also in 2.0.1
The only way is to use the ApiInternalRequest middleware, as suggested by @skaero

@fede91it Would you mind posting a proof-of-concept here which demonstrates the bug? I have had trouble reproducing it, so I think it comes down to some specific set of circumstances.

You don't have that problem? If you do an internal requested you get a Collection?
I only get arrays
Anyway I'll prepare a little repo for demonstration

@fede91it Yes, I get a collection or eloquent model (depending on the request). I think it depends on some specific circumstances, which is why I'd appreciate a working example.

I'm running into this same problem but not with an internal call. I am getting drastically different objects when I run Laravel 5.8 than when I run 5.4. The older versions of Laravel include the model name whereas the new ones do not. Predictably, this is wreaking some havoc for me.
Dingo 2.1
Here's an example Laravel 5.4:
{   "user": {     "id": 15,     "firstname": "Jon",     "lastname": "Doe",     "phone": null,     "email"<EMAIL_ADDRESS>    } }
But when we upgrade to Laravel 5.8
{   "id": 15,   "firstname": "Jon",   "lastname": "Hegranes",   "phone": null,   "email"<EMAIL_ADDRESS>}
Going through hundreds of endpoints to reconfigure them to return named models instead of this is not really an option.
It would appear the way Laravel handles this has changed and Dingo has not.
Does anyone have any suggestions to get me back to Option 1?

@joshuaziering Discussed on slack, basically outcome is Dingo/League have used the latter approach for a while now (and not sure if it's to do with Laravel), so longer term I advise you move to that, and it also makes more sense in general.
Short term, you can use your own transformers to change the structure of the returned data to make it like you want it. This should be a fairly easy workaround.

@joshuaziering I actually ran into that as well, you can quickly fix by adding the following middleware to all of your api routes. It works for both internal requests and direct calls to the API:
<?php

namespace App\Http\Middleware;

use Closure;

class ApiInternalRequest {

    /**
     * Handle an incoming request.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Closure  $next
     * @return mixed
     */
     public function handle($request, Closure $next)
     {
        // handle the api request
        $response = $next($request);

        // get the original content
        $original_content = $response->getOriginalContent();

        // package the api response
        return response($original_content);
     }
}

@joshuaziering while unfortunate, this is nonetheless worth a try until we can revisit the "need" for Dingo at a later date.
I'm surprised there isn't a better work around. I realize this change falls in a bit of a gray area since it's Laravel that's pre-formatting such responses as an array which prevents Dingo from properly formatting the response.
However, while I'm not familiar with the internal wiring of Dingo, I imagine there's a way to register their own middleware or bump their position higher in the lifecycle as to replicate the previous behavior.

@skaero This worked a treat. Thank you.


Follow new styleguide

With the new editor style guide merged, we should make sure the emacs port is properly following it

I can do this today if you want


How do you just disable linting without disabling the linter plugin?

Description of the problem or steps to reproduce
I am not really a fan of linting in terminal based text editors. Therefore I wanted to disable it, but all I could do was disabling the linter plugin itself. But when disabling the linter plugin micro always complains about some unknown function when executing:
Plugin misspell: misspell:8: attempt to index a non-table object(nil) with key 'makeLinter'
stack traceback:
	misspell:8: in main chunk
	[G]: ?

Press enter to continue

Is there a way to just disable linting?
Specifications

Version: 2.0.11
Commit hash: 225927b9
Compiled on August 09, 2022
OS: Garuda Linux (Arch)
Terminal: alacritty (fish)

Looks like the problem is not with the linter plugin itself but with the misspell plugin which depends on the linter enabled. So it looks like you can just disable the misspell plugin too, and that will solve your problem (assuming that you don't need spell checking either).
I see the misspell plugin implementation is trivial and just calls the linter: https://github.com/micro-editor/updated-plugins/blob/master/micro-misspell-plugin/misspell.lua
Perhaps it can be slightly improved to prevent the issue you faced: if linter is nil (i.e. the linter plugin disabled), just do nothing.

Yes this works (I don't want spellchecking either in my case). But I will keep the issue open if someone wants to improve the misspell plugin.


Provide a mechanism to customise aspects of the generated Slack messages.

This change makes it possible to customise the prefix, Slack username and icon emoji of generated Slack messages.

Apologies, raised in error. Closing.


Update future refund error handling

When a refund date is entered for the future the error message wasn't displaying correctly.
screenshot
Added a test for the correct handling and then updated the locale file to display the proper message
Pivotal ticket

I always wonder if it's better to test these kind of things only on model level (which is faster) or to use feature tests.
But it's totally fine, let's merge it 👍


Adds details of setting up a HA master-slave pair

@nakomis what do you think of @drigodwin 's suggestion: "would this not be better as a multiple section sub-section similar to locations?" I'm fine with either.
It's also worth adding a note (where you say ./bin/brooklyn ...) that they should see the appropriate docs for if they are using RPMs/deb install.

PR comments addressed

LGTM; merging.


Invoke-DbaDatabaseClone

Is this a feature OR bug:
feature after 1.0
Details
Understanding data security in cloned databases created using DBCC CLONEDATABASE
Perhaps we can use Clone-DbaDatabase as an alias.

We have Invoke-DbaDbClone


Need a couple of confirmation about vlxff intructions

suppose the data in memory is 'abc\0', and after vlbff is used to load:

vl=3, or vl =4?
the tail element( VLMAX>index >= vl) also need to be zero'd, right?
When an element > 0 raises an exception, the spec says :" If an element > 0 raises an exception, that element and all following elements in the destination vector register are not modified, and the vector length vl is reduced to the number of elements processed without a trap. " it is not aligned with common standard of the spec:
a. tail elements are not zero'd.
b. vstart is not used, we choose to modify vl.

The data values do not affect the behavior of the instruction.  '\0' has no special significance.

??? I don't get it, vlbff will trap when it meets 0, and then vl will be updated accordingly. my understanding is wrong?

Yeah, I think there is a misunderstanding. “These instructions execute as a
regular load except that they will only take a trap on element 0.” The data
value doesn’t matter.
The strlen code example shows how to use these instructions when the goal
is to detect a 0 data value:
https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc#77-unit-stride-fault-only-first-loads
On Fri, Jul 5, 2019 at 3:14 AM wwang0<EMAIL_ADDRESS>wrote:

??? I don't get it, vlbff will trap when it meets 0, and then vl will be
updated accordingly. my understanding is wrong?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-v-spec/issues/241?email_source=notifications&email_token=AAH3XQVUTBIM2S4LCPTFFKTP54NIBA5CNFSM4H6EBGXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZJEUJQ#issuecomment-508709414,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAH3XQTO2AWODEXY2BYSDYLP54NIBANCNFSM4H6EBGXA
.

What does 'element 0' mean? doesn't it mean the data value is 0?

It means "the zeroth element in a vector", not "an element whose value is 0".
The way the instruction works is:

If no exceptions are encountered, it behaves the same as a normal unit-stride load.
If an exception is encountered on element number i, and i > 0, then vl is set to i, and no exception is taken.
If an exception is encountered on element number 0, then the exception is taken.

The instruction really puzzled me for a long time. Can I know why we have such instruction?　I also don't quite understand the example fo strlen,  the example has chance to access memory elements after '\0', which should be illegal and might trigger memory access trap(or may not),  how does trap hanlder of system decide the trap is no harm or harm?

The instruction supports vectorizing loops whose trip count isn't known at entry (i.e. while loops), with strlen being a good example.
In the strlen example, the vlbff instruction might access elements past \0, but it will never trap on elements past \0, so the trap handler does not need to do anything special.  This works because the instruction's semantics are to reduce vl rather than taking the exception.

I see. then my last question is why the exception of element 0 is taken?　Thanks!

Faulting on element 0 handles the case that a page fault should occur, e.g., because the middle of the string has been paged out.  Consider these two examples (assuming VLMAX = 32):

String abc\0 at address 0x1ff0; the page at 0x2000 is paged out.  The first vlbff will attempt to load bytes 0x1ff0 to 0x200f.  Since loading 0x2000 would cause an exception, vl is reduced to 16 (== 0x2000 - 0x1ff0) and no exception is taken.  Because a 0 byte was detected, we exit the strip-mine loop, and no exception occurs.

Same scenario, except the string is abcdefghijklmnopqrstuvwxyz\0, so part of the string is paged out.  On the first iteration, vl is reduced to 16, but since no zero byte was found, the loop will continue.  On the second iteration, the exception is detected on the zeroth element, so the exception will really be taken this time.  Once the page fault is handled, the loop will find the zero byte on that same loop iteration, and we'll exit the loop.

Hopefully those two examples help.

Now I understand it completely. Thanks for your patience to explain it to me!

Cool!

I probably have the real last question, in v spec, it says:
"
If an element > 0 raises an exception, that element and all following elements in the destination
vector register are not modified.
"
But we usually zero the tail element, but not keep them not modified, right?

Let’s postpone that question for now, as tail-zeroing semantics are still being debated.


Removing redundant downloads

Added check for presence of matrix_files(tmp_dir) folder and creation if not existing. Added check for accession.h5ad file in matrix_files and downloaded if not existing. Added check for spatial folder within matrix_files and creation/download if not existing. Added check for reference .csv files and downloaded if not existing. Removed the deletion of matrix_files at the end.

Looks good to me!


Consider removing support for unregistered attributes

Request description
In the v0.9 release, which has 1mo forward/backward compatibility, unregistered attributes are allowed as long as their values use types / attributes that are representable in VHLO. Prior to offering v1.0 long-term compatibility guarantees in 2023, we should better understand the use cases for unregistered attributes and make a decision on whether they should be permitted or not. Ideally, the use cases for unregistered attributes should be natively supported in StableHLO.

FWIW, spec.md provides a list of unregistered attributes which have corresponding tickets in our repository. Search for "At the moment, StableHLO programs in the wild sometimes contain attributes which are not described in this document".
This list doesn't cover all uses of unregistered attributes, because at the moment consumers and producers are free to communicate with each other with whatever attributes they want, but I figured that it'd still come in handy.

Another interesting issue we've seen is unregistered attributes with validation, for example TF SavedModel Dialect. This validates things like tf_saved_model.exported_names must be a child of FuncOp.
This doesn't work well with VHLO conversion, since converting funcs to vhlo.func_v1 can cause this validation to fail when a saved model is converted to StableHLO and serialized.
We should consider:

Offer a pass which drops unregistered (discardable) attributes that can be used prior to serialization.
Prefix dialect-specific unregistered attributes with vhlo. during serialization / strip suring deserialization to prevent validation errors of portable artifacts.


Small Tweaks

While navigating other websites and how they setup their cookie pages I see the following things:

Last updated all cookies on X date (maybe this could be tied to each group or all groups) - since third parties could add/remove cookies that they use over time.
Expiration/Lifespan/Duration for each cookie
Type for each cookie (Essential / Strictly Necessary, Targeting/Advertising, Analytics / Performance, Unclassified, etc)
First party or third party for each cookie
A <details> tag to save page space (optional - nice to have, but not sure if lawyers would like it you are "hiding" them unless clicked to be revealed)

Maybe adding these things to the database as non-required fields would help maintenance via admin and give users the option to include them or not. Otherwise, not a big deal if no PR is made since this stuff could be added to the cookie description as their own sentence or a programmer could make changes by overriding the templates.
There may be laws that require these small pieces of information to be stated which is why I bring it up but I am not a lawyer so not entirely sure. Erroring on the side of caution here. Plus hopefully helping others out by giving them more info that they might want to include.
Example:
https://stripe.com/cookie-settings
https://stripe.com/cookies-policy/legal

I think I'd opt for a swappable model here so users can override the models/templates as needed for their specific legislation.
Tentatively putting this for the 1.0 release, as that would solidify the public API.

https://github.com/openwisp/django-swappable-models
To create swappable models for the Django Cookie Consent app, you can follow these steps:

Create a new Django app in your project called cookie_consent_custom or something similar.
Create a models.py file in the cookie_consent_custom app with the following code:

from django.db import models
from cookie_consent.models import CookieGroup, Cookie

class CustomCookieGroup(CookieGroup):
    pass

class CustomCookie(Cookie):
    pass

In your project's settings.py file, add cookie_consent_custom to the INSTALLED_APPS list.

Add the following lines to your settings.py file to make the CookieGroup, Cookie, and CookieConsent models swappable:

COOKIE_CONSENT_CUSTOM_COOKIE_GROUP_MODEL = 'cookie_consent_custom.CustomCookieGroup'
COOKIE_CONSENT_CUSTOM_COOKIE_MODEL = 'cookie_consent_custom.CustomCookie'
COOKIE_CONSENT_CUSTOM_COOKIE_CONSENT_MODEL = 'cookie_consent_custom.CustomCookieConsent'

Run python manage.py makemigrations and python manage.py migrate to create the new database tables for the swappable models.

You might run into some errors when doing this yourself:
django.core.exceptions.FieldError: Local field 'name' in class 'CookieGroup' clashes with field of the same name from base class 'CookieGroup'.
The error message you are seeing is because you are trying to define a field in your custom model with the same name as a field in the base model. This is not allowed in Django because it would cause a conflict when trying to access the field.
To avoid this error, you should give your custom field a different name. For example, if you want to create a custom CookieGroup model with a field for the group's name, you could define it like this:
from django.db import models
from cookie_consent.models import CookieGroup, Cookie, CookieConsent

class CustomCookieGroup(CookieGroup):
    custom_name = models.CharField(max_length=255)

In this example, the custom field is named custom_name instead of name, which avoids the conflict with the base CookieGroup model's name field.
You can do the same for any other fields you want to customize in your swappable models. Just make sure to give them unique names to avoid conflicts with the base models.
To keep some of the model fields from the original model with the same name in the new model when creating swappable models in Django, you can use the db_column attribute in your custom model's field definition.
For example, let's say you want to create a custom CookieGroup model that adds a new field called description, but you want to keep the original name field with the same name. You could define the custom model like this:
from django.db import models
from cookie_consent.models import CookieGroup, Cookie, CookieConsent

class CustomCookieGroup(CookieGroup):
    description = models.CharField(max_length=255)
    name = models.CharField(max_length=255, db_column='name')

In this example, the name field in the custom model has the same name as the name field in the base CookieGroup model, but it uses the db_column attribute to specify a different database column name. This allows you to keep the same field name in your code while avoiding conflicts with the base model's field.
You can use the db_column attribute in the same way for any other fields you want to keep with the same name in your custom models.
cookie_consent_custom.Cookie.cookiegroup2: (fields.E304) Reverse accessor 'CookieGroup.cookie_set' for 'cookie_consent_custom.Cookie.cookiegroup2' clashes with reverse accessor for 'cookie_consent.Cookie.cookiegroup'.
    HINT: Add or change a related_name argument to the definition for 'cookie_consent_custom.Cookie.cookiegroup2' or 'cookie_consent.Cookie.cookiegroup'.

The error message you are seeing is because you have two models, Cookie and cookie_consent_custom.Cookie, that both have a foreign key to the CookieGroup model. Django is trying to create a reverse accessor for each of these foreign keys, but the default name for the reverse accessor clashes between the two models.
To fix this error, you can add a related_name argument to one or both of the foreign key fields. For example, you could add a related_name to the cookiegroup field in the Cookie model like this:
from django.db import models
from cookie_consent.models import CookieGroup

class Cookie(models.Model):
    cookiegroup = models.ForeignKey(
        CookieGroup,
        on_delete=models.CASCADE,
        related_name='custom_cookies',
    )

In this example, the related_name argument is set to 'custom_cookies', which creates a new reverse accessor for the CookieGroup model that won't clash with the default reverse accessor created by the cookie_consent app.
You can do the same for the cookiegroup2 field in the cookie_consent_custom.Cookie model, or choose a different related_name value for each field to avoid conflicts.
### Example Swappable Model:
cookie_consent_custom models.py:
from django.db import models
from cookie_consent.models import CookieGroup, Cookie

class CookieType(models.Model):
    name = models.CharField(max_length=20)

    def __str__(self):
        return self.name

    class Meta:
        verbose_name = 'Cookie Type'
        verbose_name_plural = 'Cookie Types'
        ordering = ('name',)

class CookieGroup(CookieGroup):
    name2 = models.CharField('Name', max_length=100, blank=True, db_column='name')
    description2 = models.TextField('Description', blank=True, db_column='description')
    is_required2 = models.BooleanField('Is required',help_text='Are cookies in this group required.',default=False, db_column='is_required')
    is_deletable2 = models.BooleanField('Is deletable',help_text='Are cookies in this group deletable.', default=True, db_column='is_deletable')
    ordering2 = models.IntegerField('Ordering', default=0, db_column='ordering')
    created2 = models.DateTimeField('Created', auto_now_add=True, blank=True, db_column='created')
    updated = models.DateTimeField('Updated', blank=True)

    class Meta:
        verbose_name = 'Cookie Group'
        verbose_name_plural = 'Cookie Groups'
        ordering = ('ordering',)

    def __str__(self):
        return self.name

class Cookie(Cookie):
    cookiegroup2 = models.ForeignKey(CookieGroup,on_delete=models.CASCADE, db_column='cookiegroup', related_name='cookiegroup')
    cookietype2 = models.ForeignKey(CookieType, default=1, on_delete=models.SET_NULL, null=True, db_column='cookietype')
    name2 = models.CharField('Name', max_length=256, db_column='name')
    description2 = models.TextField('Description', blank=True, db_column='description')
    path2 = models.TextField('Path', blank=True, default="/", db_column='path')
    domain2 = models.CharField('Domain', max_length=256, blank=True, db_column='domain')
    duration = models.CharField('Duration', max_length=256)
    created2 = models.DateTimeField('Created', auto_now_add=True, blank=True, db_column='created')

    class Meta:
        verbose_name = 'Cookie'
        verbose_name_plural = 'Cookies'

    def __str__(self):
        return "%s %s%s" % (self.name, self.domain, self.path)

cookie_consent_custom admin.py:
from django.contrib import admin

from .models import CookieGroup, Cookie, CookieType

class CookieTypeAdmin(admin.ModelAdmin):
    readonly_fields = ('id',)
    list_display_links = ('name',)
    list_display = ('id', 'name',)
    search_fields = ('id', 'name',)
    ordering = ('id',)

class CookieGroupAdmin(admin.ModelAdmin):
    readonly_fields = ('id',)
    list_display_links = ('name',)
    list_display = ('id', 'name', 'description', 'is_required', 'is_deletable', 'ordering', 'created',)
    search_fields = ('id', 'name',)
    ordering = ('id',)

class CookieAdmin(admin.ModelAdmin):
    readonly_fields = ('id',)
    list_display_links = ('cookiegroup',)
    list_display = ('id', 'cookiegroup', 'cookietype2', 'name', 'description', 'path', 'domain', 'duration', 'created',)
    search_fields = ('id', 'name',)
    ordering = ('id',)

admin.site.register(CookieType, CookieTypeAdmin)
admin.site.register(CookieGroup, CookieGroupAdmin)
admin.site.register(Cookie, CookieAdmin)

@9mido while looking at libraries for swappable models, I'm not entirely confident that's a responsible decision since I'm not seeing much activity. Given that Django now supports JSONField on all major databases, would that be an escape hatch that can work?

You can override the admin form and register your own custom form that writes to keys of the JSON Field
You can provide your own templates to display the additional data from the JSON Field
If necessary, you can do proper queries on the data inside

What do you think?

@sergei-maertens What if the user needed more than 1 JSON Field? It may take a beginner a lot longer trying to figure out what you said to do in your bullet points compared to simply adding a few fields in the django model like most beginners know how to do. I do think using a JSON Field is a creative way of doing this that I would have never thought was possible. But a swappable model and a JSON Field each have pros and cons. Maybe we can have both?
Pros of JSONField:

Flexibility: Store flexible and variable data structures.
Simplified Schema Changes: Add or remove fields dynamically.
Querying and Manipulation: Convenient querying and manipulation methods.
Easy Integration: Seamless integration with Django's database infrastructure.
Atomic Updates: Support for efficient in-place modifications.
Space Efficient: More space efficient than a related table if data doesn't repeat.

Cons of JSONField:

Limited Database Compatibility: Not available in all database backends.
Performance Considerations: Performance implications with complex queries or large objects.
Lack of Schema Validation: No enforcement of data integrity and validation.
Lack of Referential Integrity: Cannot enforce foreign key relationships.

Pros of Swappable Model:

Extensibility: Highly customizable and extendable architectures without making huge changes to your codebase.
Ease of customization: Easy customization of Django User model.
Modular Architecture: Fits well into modular designs and pluggable apps.

Cons of Swappable Model:

Increased Complexity: Adds complexity to the project (relationships, maintenance, etc.)
Potential for Errors: Problems if swapping is not handled correctly.
Database Migration: Challenging migration process, potential for data loss.

What if the user needed more than 1 JSON Field?

That's a bit weird imo - the point is that you can decide what your data model is and drop it in there as you see fit. The data for two fields would easily fit into a single JSON field if you use a dict to structure/serialize that data with a key that's recognizable for yourself.

... too simply adding a few fields in the django model

There are essentially two ways to be able to do that:

the fields are added to the models shipped in the library. I'm worried this is a slippery slope - there'll be always be yet another field that's relevant for someone's use case and we can't keep adding all fields everyone requests.
we make the model swappable, so that users can add their own fields. This comes with a serious technical cost as this now needs to be maintained, migrations need to be managed, there is a risk of us adding future fields that will break other people's models... and it's using a private internal Django API. While it has been stable, I try to avoid using internal Django API because of the potential maintenance burden.

So I think I'd need some solid examples of requirements that wouldn't work with a JSONField to justify the drawbacks of swappable models. The original examples in this post give pure metadata examples that do not require integrity guarantees (like foreign keys provide) and would easily be achieved with JSONField.
Combined with the admin, you can (with a little bit of work) define your own form for the admin that makes it seem like they are actual separate fields which handles saving the data into the proper "slots" in the JSONField (that would be a good documentation page/recipe!), which handles your input validation for you.


JIRA Collector - Unable to fetch data into feature collection

Hi,
I am trying to configure Jira collector to fetch the stories into MongoDB. Code is able to connect to the jira instance and it is retrieving data only into scope and team collections but no data is being retrieved into feature collection.
Following is my application.properties file, there is no error in the logs, is there anything else that needs to be configured?
server.ssl.enabled = false
dbname=sampledb
dbhost=localhost
dbport=27017
dbreplicaset=false
dbhostport=[host1:port1,host2:port2,host3:port3]
dbusername=testuser
dbpassword=xxxx
logging.file=./logs/jira.log
feature.pageSize=100
feature.deltaStartDate=2016-03-01T00:00:00.000000
feature.masterStartDate=2016-03-01T00:00:00.000000
feature.deltaCollectorItemStartDate=2016-03-01T00:00:00.000000
feature.cron=0 * * * * *
feature.queryFolder=jiraapi-queries
feature.storyQuery=story
feature.epicQuery=epic
feature.jiraProxyPort=9000
feature.jiraBaseUrl=https://jira.xxx.xxx/
feature.jiraQueryEndpoint=rest/api/2/
feature.jiraCredentials=xxxxxxxxx
feature.jiraOauthAuthtoken=
feature.jiraOauthRefreshtoken=
feature.jiraOauthRedirecturi=
feature.jiraOauthExpiretime=
feature.jiraStoryIds[0]=20
feature.jiraStoryIds[1]=6
feature.jiraEpicId=5
feature.jiraIssueTypeNames=Story,Epic
feature.jiraSprintDataFieldName=customfield_XXXX
feature.jiraEpicIdFieldName=customfield_YYYY
feature.jiraStoryPointsFieldName=customfield_ZZZZ
feature.jiraTeamFieldName=project
feature.collectorItemOnlyUpdate=true
feature.maxNumberOfFeaturesPerBoard=1000
feature.jiraBoardAsTeam=true
feature.refreshTeamAndProjectHours=3
lastRefreshTime=0
lastExecuted=0
Logs:
2022-05-03 17:25:07,912 [taskScheduler-1] INFO  c.c.d.collector.CollectorTask - Project Data Collected 2150       12s
2022-05-03 17:25:08,049 [taskScheduler-1] INFO  c.c.d.collector.CollectorTask - Board Issues Refreshed           0s
2022-05-03 17:25:08,052 [taskScheduler-1] INFO  c.c.d.collector.FeatureCollectorTask - Collected 12722 teams and 2150 projects
2022-05-03 17:25:08,055 [taskScheduler-1] INFO  c.c.d.collector.CollectorTask - Finished                       543s
2022-05-03 17:25:08,055 [taskScheduler-1] INFO  c.c.d.collector.CollectorTask - Finished running Collector=Jira timeTaken=543980 collectorItems=0
2022-05-03 17:26:00,000 [taskScheduler-1] INFO  c.c.d.collector.CollectorTask - Getting Collector: Jira
2022-05-03 17:26:00,186 [taskScheduler-1] INFO  c.c.dashboard.client.RestClient - makeRestCall op=GET url=https://xxx.xxx.xxx/rest/api/2/issuetype status=200 duration=180
2022-05-03 17:26:00,193 [taskScheduler-1] INFO  c.c.d.collector.CollectorTask - Starting Collector=Jira
2022-05-03 17:26:00,193 [taskScheduler-1] INFO  c.c.d.collector.CollectorTask - -----------------------------------
2022-05-03 17:26:00,193 [taskScheduler-1] INFO  c.c.d.collector.CollectorTask - https://xxx.xxx.xxx/
2022-05-03 17:26:00,193 [taskScheduler-1] INFO  c.c.d.collector.CollectorTask - -----------------------------------
2022-05-03 17:26:00,193 [taskScheduler-1] INFO  c.c.d.collector.FeatureCollectorTask - JIRA Collector is set to work in Board mode
2022-05-03 17:26:00,193 [taskScheduler-1] INFO  c.c.d.collector.FeatureCollectorTask - Hours since last run = 0. Collector is only collecting updated/new issues.
2022-05-03 17:26:00,195 [taskScheduler-1] INFO  c.c.d.collector.CollectorTask - Finished                         0s

Hi,
Any inputs on this is really helpful?
As suggested in few other forums, tried with feature.jiraTeamFieldName as blank and with Any but that did not help. I do not see any teams field in the rest api output.
Data is getting populated in scope, teams and collectors collections but not in feature collection.

Yes I found the same issue as well. Any leads is appreciated.


Fix book descript image issue

Hi, this is my first pull request. I'm glad to take any advice on how to redo it. I'm sending because I think this update to goodreads-user-scraper is going to be pretty helpful.
Changes
Both changes affect scraper/books.py.

addressed: Crashes due to error from not finding id="description" read shelf #3
This prevents the application from crashing when certain books do not have descriptions or at least is there is no <div id="description" tag in the html of the book page. So this fix is to just check if the soup.find("div, {"id": "description"}) is None. If it is none then return "No description found" for the json file.

The code fixed is shown in comment of reported issue.

addressed:  Crashing when no cover image is found in book #4
Again, not sure its a fix but certainly prevents crashing of the test script when there is no cover image in the book website.
Added to book.py :

lines 91-95 get_book_image method
line 109 call get_book_image method

See comment on #4


Unable to assign public ips to container created using LXD. Are they any specific bridge network requirements?

The template below is mostly useful for bug reports and support questions.
Feel free to remove anything which doesn't apply to you and add more information where it makes sense.
Required information

Distribution:
Distribution version:
The output of "lxc info" or if that fails:

Kernel version:
LXC version:
LXD version:
Storage backend in use:

Issue description
A brief description of what failed or what could be improved.
Steps to reproduce

Step one
Step two
Step three

Information to attach

[ ] any relevant kernel output (dmesg)
[ ] container log (lxc info NAME --show-log)
[ ] main daemon log (/var/log/lxd.log)
[ ] output of the client with --debug
[ ] output of the daemon with --debug

LXD only cares about layer 2 networking. If you have a bridge that includes a physical network interface to the outside world, then all your containers will be getting IPs from whatever DHCP server is running on that network.
The default bridge we provide on Ubuntu is merely a convenience that happens to work on all setups (laptops on wifi, servers, ...) but we expect folks in production environment to just setup their own networking.
Be that macvlan on a physical interface, their own custom bridge or whatever SDN they feel like using.

I created a bridge in my networking (br0) and assigned bridge to lxd using lxd.init which prompts for the bridging network.Later,Inside the container I have asssigned my public ip and made sure that i can ping it from another server.But unfortunately , The containers could get access to the internet.I have assigned statically the ips from dhcp servers.Could you find a solution for this?

Is that inside a virtual machine or some restricted network? Virtual switches (like those from OpenStack and VMWare) as well as some corporate switches have been known to reject multiple MAC addresses behind a single "physical" port.


Add global PHP dependencies configured in .platform.app.yaml

Install global PHP dependencies in the container, as configured in .platform.app.yaml

Looking at the most important global dependencies early... In general it's best practice to not use global composer dependencies, but rather to put them into the project. But I guess if we have people using these... it's not hard to support.
The more things we put into the Dockerfile, the longer the initial startup is (first time for project).
I'm not sure we should fiddle with python/python2/python3/ruby at this point.
nodejs is another thing; ddev is already maturing in this regard, And the ability to add npm packages globally is interesting, and not hard. Assuming that dependencies work out.
One thing we need to sort out as we do this... Where can mainline DDEV learn from Platform.sh usage; What features should just be implanted in the project?

Dependencies can be important for many users. Global Composer dependencies should be fine here. I'm fine with only dealing with PHP deps.

Where can mainline DDEV learn from Platform.sh usage

Not sure to understand what you're asking. My guess is that the Platform.sh docs should be a good starting point.

What features should just be implanted in the project?

These are represented by the issues I created 😉, in regards to the assigned milestones (1.0, 1.1, 1.2) . Unless I'm missing something.

PHP dependencies are actually only Composer packages, so it can be anything that is installable globally using Composer.
Example: psysh/psysh / composer g install psysh/psysh


Update Question/Issue

I'm running MacOS and want to understand how to correctly update an existing installation of the program.  When a new version is available, can I simply overwrite the executable in my directory and reboot my computer, or do I need to use Terminal to stop, uninstall the previous version, install the new version, and restart the service?  I've been overwriting the executable each time but I don't know how to verify that the service is the latest version.  Also, please let me know if there's a better way or different medium to ask questions.

Hi!
Yes, that's all you have to do. Just replace the executable with the new version.
Or use Homebrew.

Awesome thank you for the quick response and for developing this amazing software!

Thank you!


[v0.0.17] Issue running the command mila code

Make sure you can reproduce the issue with the latest version available
pip install milatools --upgrade
[milatools command e.g. mila code ...]

Yes I did
What command did you run?
[e.g. mila code ...]
mila code Research/DomainGeneralization --alloc --gres=gpu:1 -c 4 --mem=24000
Describe the bug
A clear and concise description of what the bug is. If there is an error
traceback, please paste it here.
Traceback (most recent call last):
File "C:\ProgramData\miniconda3\lib\site-packages\milatools\cli\commands.py", line 43, in main
auto_cli(milatools)
File "C:\ProgramData\miniconda3\lib\site-packages\coleo\cli.py", line 656, in auto_cli
result = run_cli(entry, args, **kwargs)
File "C:\ProgramData\miniconda3\lib\site-packages\coleo\cli.py", line 628, in run_cli
return call(opts=opts, args=args)
File "C:\ProgramData\miniconda3\lib\site-packages\coleo\cli.py", line 587, in thunk
result = fn(*args)
File "C:\ProgramData\miniconda3\lib\site-packages\milatools\cli\commands.py", line 285, in code
remote = Remote("mila")
File "C:\ProgramData\miniconda3\lib\site-packages\milatools\cli\remote.py", line 84, in init
connection.open()
File "C:\ProgramData\miniconda3\lib\site-packages\fabric\connection.py", line 636, in open
self.client.connect(**kwargs)
File "C:\ProgramData\miniconda3\lib\site-packages\paramiko\client.py", line 459, in connect
self._auth(
File "C:\ProgramData\miniconda3\lib\site-packages\paramiko\client.py", line 717, in _auth
self._agent = Agent()
File "C:\ProgramData\miniconda3\lib\site-packages\paramiko\agent.py", line 406, in init
self._connect(conn)
File "C:\ProgramData\miniconda3\lib\site-packages\paramiko\agent.py", line 79, in _connect
ptype, result = self._send_message(cSSH2_AGENTC_REQUEST_IDENTITIES)
File "C:\ProgramData\miniconda3\lib\site-packages\paramiko\agent.py", line 96, in _send_message
self._conn.send(struct.pack(">I", len(msg)) + msg)
File "C:\ProgramData\miniconda3\lib\site-packages\paramiko\win_pageant.py", line 126, in send
self._response = _query_pageant(data)
File "C:\ProgramData\miniconda3\lib\site-packages\paramiko\win_pageant.py", line 93, in _query_pageant
pymap.write(msg)
File "C:\ProgramData\miniconda3\lib\site-packages\paramiko_winapi.py", line 176, in write
dest = self.view + self.pos
TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. Ubuntu 22.04, Mac OS 12.5, Windows 11, etc.]

Windows 10
Additional context
Add any other context about the problem here.

If I use command without GPU allocation like:
mila code Research/DomainGeneralization
Then VS code works.


Output validator custody file in pcli-compatible format

This changes the output of a generated validator's identity key to be compatible with the pcli "custody.json" format, by extracting pcli's Wallet struct into the wallet crate and using that to output the spend key.

I don't think we should call this "wallet", since it's only used by the SoftHSM code and doesn't contain any data that people would normally call wallet data.


Pixie CLI failing validation on K3s

Describe the bug
I'm attempting to install Pixie into a K3s cluster and the cluster check fails stating that the cluster type is unsupported.  Looking at the Pixie docs, K3s is listed as being supported.
Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.6+k3s1", GitCommit:"418c3fa858b69b12b9cefbcff0526f666a6236b9", GitTreeState:"clean", BuildDate:"2022-04-28T22:16:18Z", GoVersion:"go1.17.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.6+k3s1", GitCommit:"418c3fa858b69b12b9cefbcff0526f666a6236b9", GitTreeState:"clean", BuildDate:"2022-04-28T22:16:18Z", GoVersion:"go1.17.5", Compiler:"gc", Platform:"linux/amd64"}

Running Cluster Checks:
 ✔    Kernel version > 4.14.0
 ✔    Cluster type is supported
 ✔    K8s version > 1.16.0
 ✔    Kubectl > 1.10.0 is present
 ✔    User can create namespace
 ✕    Cluster type is in list of known supported types  ERR: Cluster type is not in list of known supported cluster types. Please see: https://docs.px.dev/installing-pixie/requirements/

Node Info:
Linux kubernetes-vm 5.13.0-1024-gcp #29~20.04.1-Ubuntu SMP Thu Apr 14 23:15:00 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Installing Pixie into the same cluster using Helm works successfully.
To Reproduce
Steps to reproduce the behavior:

Build K3s cluster
Attempt Pixie deploy via CLI
Shed a single tear :(

Expected behavior
I would expect Pixie to install without issues as K3s is listed as supported.

The CLI is failing because k3s is missing from our allowedClusterTypes list: https://github.com/pixie-io/pixie/blob/main/src/pixie_cli/pkg/utils/checks.go#L68
As a temporary workaround, you can use --check=false when deploying Pixie:
px deploy --check=false

The fix for this has landed, but won't be available until the next CLI release.


Support a maximum batch size per DataSource

Add the maxBatchSizePhase interpreter which splits fetches to data sources with a maximum batch size in to multiple sequential fetches. This required a change to Concurrent to return a InMemoryCache instead of a DataSourceCache making it possible to combine multiple caches for sequential batches.
Refactor the processConcurrent method which is used in the coreInterpreter (previously called interpreter) by using XorT instead of nested if / else and Option.fold and by extracting some helper methods.
Give some members of the Fetch constructors a better name (eg. FetchMany.as to FetchMany.ids)
Create the Fetch.multiple method which makes it possible to create a Fetch[List[...]] directly (using FetchMany underneath). This can currently (and previously) be done by using sequence or traverse, but multiple doesn't have the overhead of inspecting the Fetch structure to find independent fetches which can be parallelized.

Current coverage is 75.87% (diff: 92.04%)

Merging #76 into master will increase coverage by 6.13%

@@             master        #76   diff @@
==========================================
  Files             8          8
  Lines           195        228    +33
  Methods         190        226    +36
  Messages          0          0
  Branches          5          2     -3
==========================================
+ Hits            136        173    +37
+ Misses           59         55     -4
  Partials          0          0

Powered by Codecov. Last update 26f7b45...cb60e82

Outstanding work, well done! :shipit:


awi-ciroh: update outdated display name for image choice

The date for old image was incorrect and it is fixed in this PR. Please review and merge. Thank you!
@arpita0911patel

Thanks @sepehrkrz


Terminals opened in Code adopt malformed $PATH (breaks virtualenv)

Environment data

VS Code version: 1.25.1
Extension version (available under the Extensions sidebar): 2018.7.1
OS and version: MacOS 10.13.6
Python version (& distribution if applicable, e.g. Anaconda): 2.7.15/3.7.0 installed via homebrew
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): virtualenv/virtualenvwrapper
Relevant/affected Python packages and their versions: N/A

Actual behavior
Terminals opened with "Pthon: Create Terminal" or "Open New Terminal" command open with a $PATH that has the active virtualenv at the end, rather than the beginning:
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/alexw/.virtualenvs/foobarenv3x/bin
Even though the calling terminal has $PATH = /Users/alexw/.virtualenvs/foobarenv3x/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
Expected  behavior
Child terminals should have $PATH=/Users/alexw/.virtualenvs/foobarenv3x/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin, same as the terminal code was launched from.
Steps to reproduce:
-In a terminal, I activate a virtualenv, my_env (workon my_env)
At this point:
$ echo $PATH
/Users/alexw/.virtualenvs/my_env/bin:....

-Launch code into this environment (my_env) $ code .
-open example.py in that directory.
At this point:
my python interpreter according to the bottom left corner of the debug view is the python 3.x installed into my_env, so that's correct.
If I open developer tools and check "process.env" at console, $PATH is prepended as above - which is what I'd expect.
-open a terminal with "Python: create terminal" or "open a new terminal"
At this point:
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/alexw/.virtualenvs/foobarenv3x/bin

Notably, my virtualenv is in the path, but APPENDED rather than PREPENDED, as it is in both "process.env" and the $PATH of the original calling terminal window.
This leads to all sorts of downstream problems, like auto-opened terminals installing linters and such in the system environment rather than the virtualenv, etc.
Logs
Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)
"Cannot edit in read-only editor" (I'm not really sure what I'm supposed to do here)

Output from Console under the Developer Tools panel (toggle Developer Tools on under Help)
INFO no standard startup: panel is active
/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:270 [Extension Host] Python Extension: Linter 'pylint' is not installed. Please install it or select another linter". Error: Module 'pylint' not installed.
	at PythonExecutionService.<anonymous> (/Users/alexw/.vscode/extensions/ms-python.python-2018.7.1/out/client/common/process/pythonProcess.js:96:27)
	at Generator.next (<anonymous>)
	at fulfilled (/Users/alexw/.vscode/extensions/ms-python.python-2018.7.1/out/client/common/process/pythonProcess.js:12:58)
	at <anonymous>
t.log @ /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:270
/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:2364 Linter pylint is not installed.
e.onDidNotificationChange @ /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:2364

Further info - debugging seems broken, due to this. When one clicks "run", I guess the file in question is run in a new terminal that gets created with the malformed path.

Thanks for supplying the extra information. We are planning on going over our conda environment logic this release (and you've already been part of that conversation so thanks x2!).
I've reproduced this information locally on Ubuntu 18.04 using a conda 4.4.0/python 3.6.1 version installed via pyenv. I've activated a conda environment in my terminal (called issue2333) and invoked code . from within that environment.
Here's the terminal's environment:
(issue2333) dekeeler@dek-laptop-lnx:~/dev/github/d3r3kk/test/issue2333$ printenv | grep -i py
PYENV_ROOT=/opt/python/pyenv
CONDA_PREFIX=/opt/python/pyenv/versions/anaconda3-4.4.0/envs/issue2333
CONDA_PATH_BACKUP=/opt/python/pyenv/shims:/opt/python/pyenv/bin:/home/dekeeler/perl5/bin:/home/dekeeler/.nvm/versions/node/v8.11.2/bin:/home/dekeeler/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/dekeeler/.dotnet/tools
PYENV_SHELL=bash
PATH=/opt/python/pyenv/versions/anaconda3-4.4.0/envs/issue2333/bin:/opt/python/pyenv/shims:/opt/python/pyenv/bin:/home/dekeeler/perl5/bin:/home/dekeeler/.nvm/versions/node/v8.11.2/bin:/home/dekeeler/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/dekeeler/.dotnet/tools

...and here's the environment reported within Code's interactive terminal:
dekeeler@dek-laptop-lnx:~/dev/github/d3r3kk/test/issue2333$ printenv | grep -i py
PYENV_ROOT=/opt/python/pyenvCONDA_PREFIX=/opt/python/pyenv/versions/anaconda3-4.4.0/envs/issue2333
CONDA_PATH_BACKUP=/opt/python/pyenv/shims:/opt/python/pyenv/bin:/home/dekeeler/perl5/bin:/home/dekeeler/.nvm/versions/node/v8.11.2/bin:/home/dekeeler/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/dekeeler/.dotnet/toolsSNAP_COOKIE=6W8xGmk1jyDQ0RF798gtMVr41tm30Y5PylCyhBM3WJfyPYENV_SHELL=bash
SNAP_CONTEXT=6W8xGmk1jyDQ0RF798gtMVr41tm30Y5PylCyhBM3WJfy
PATH=/opt/python/pyenv/shims:/opt/python/pyenv/bin:/home/dekeeler/perl5/bin:/opt/python/pyenv/versions/anaconda3-4.4.0/envs/issue2333/bin:/opt/python/pyenv/shims:/opt/python/pyenv/bin:/home/dekeeler/perl5/bin:/home/dekeeler/.nvm/versions/node/v8.11.2/bin:/home/dekeeler/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/dekeeler/.dotnet/tools

The path does seem to come from elsewhere (I am confident this is a known issue), and is not aware of the current active conda environment yet.
If I look at the status bar in VSCode, I see this too:

...and if I hover:

...which tells me we actually do have the right information
handy. But if I run the Python: Create Terminal command I get this:

When I click on the status bar interpreter, I see the command bar open up with this information:

and as expected, you can see that the current interpreter is just set to python (the system one, presumably, based on my current PYENV shims in the PATH).
If I select the actual environment I want  though (issue2333) and then attempt to open a terminal, everything works as expected.

Something to consider as we investigate opportunities for improvement #2288, @ericsnowcurrently.

@alexwhittemore yes, if you have to explicitly select the interpreter you want to work, else Python: Create Terminal doesn't know what environment to activate (we have nothing to do with Open New Terminal). Does this mean your issue has been taken care of?

@alexwhittemore  Also remember that we don't support active virtual environments from the terminal as you have previously expected.

Actually, this is super odd - now that I revisit this, my entire previous post seems no longer to be true.
No virtualenv:
Alexs-MBP-2018:~/Desktop
› echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
Alexs-MBP-2018:~/Desktop
› which python
/usr/local/bin/python
Alexs-MBP-2018:~/Desktop
› python --version
Python 2.7.15
Alexs-MBP-2018:~/Desktop
› code .

(The default-selected python, per hovering over the python item in the bottom left, is highlighted)

That is, in the default case, the default-selected interpreter isn't the correct path. But I think that's probably a trick of symlinks, since the python shell that comes up ultimately is correct.
In a virtualenv:
Alexs-MBP-2018:~/Desktop
› workon plotter_env
(plotter_env) Alexs-MBP-2018:~/Desktop
› echo $PATH
/Users/alexw/.virtualenvs/plotter_env/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
(plotter_env) Alexs-MBP-2018:~/Desktop
› which python
/Users/alexw/.virtualenvs/plotter_env/bin/python
(plotter_env) Alexs-MBP-2018:~/Desktop
› python --version
Python 3.7.0
(plotter_env) Alexs-MBP-2018:~/Desktop
› code .

(when I hover, the python path is just "python")

Notice here that python is detected as the wrong version:

all references to `python` in this virtualenv are, in fact, python 3.x
If I select that python anyway, the $PATH of newly opened terminals doesn't get corrected (or rather, prepended) like in my previous post.
And at this point, when I hover over the "Python" item bottom left, it shows the correct path (the Python.app version from the select interpreters screenshot), but it still says Python 2.7.15. Like it's showing the path from the settings item, but the `process.env.path` isn't correct, and it's pulling the python version info from a naive execution of `python --version`
So at this point, that previous workaround is totally nonfunctional and I can't get code to use the correct python interpreter no matter what I set or try.

@alexwhittemore this whole issue has gotten rather wordy and hard to follow. 😉 Are you launching VS Code from a terminal with an activated virtual environment and expecting it to work? How are you creating the environment? What is your settings.json saying your Python settings are?

Honestly, I'm not even sure what the long and short of it is, at this point.
Recall that
Alexs-MBP-2018:~/Desktop
› cat ~/.virtualenvs/postactivate
#!/bin/bash
# This hook is sourced after every virtualenv is activated.

if [ ! -d $VIRTUAL_ENV/Python.app ]; then
  echo Fixing OSX Python display issues...
  fix-osx-virtualenv $VIRTUAL_ENV
fi

that's to make a magic framework build wrapper around the python that gets put in the virtualenv.
It seems if I leave that incantation active in postactivate, vscode totally breaks - I can't select the interpreter - it sees the right path but with the wrong python version reflected, and when I select it, newly created child terminals fail to launch with the right $PATH still.
If I remove that from postactivate and just do it myself, manually, once, code seems to work, provided I manually select the interpreter such that

(test_env) Alexs-MBP-2018:~/Desktop
› cat .vscode/settings.json
{
    "python.pythonPath": "/Users/alexw/.virtualenvs/test_env/bin/python"
}

One thing that's still odd: with that settings.json entry, if I launch code, the terminal that's automatically open at launch doesn't have the right path, even though the interpreter is set correctly per hovering over the "Python" item in the bottom left.

If I then create a new one with Shift-Cmd-P Python: Create Terminal, I see:

It looks like code sees that my selected interpreter is in a virtualenv, and actually calls the activate script when launching a terminal? Maybe that's why my postactivate modification is fouling things up?

Also, not strictly related, but in response to your earlier post (Sorry, looks like we happened to post coincidently!):

Also remember that we don't support active virtual environments from the terminal as you have previously expected.

What I don't get is, even if this is the case, how is it possible that the $PATH 1:2:3:4:5 becomes 2:3:4:5:1 when VSCode is launched from the terminal? I don't even know how that's possible without deliberate modification, and it seems to me like everything would "just work" the way I intuitively expect it to if that path simply didn't get mangled.

@alexwhittemore yeah, it sounds like your shell setup is a bit too magical for us. 😉 If that fix-osx-virtualenv is screwing with your PATH then it will definitely not do what you want as we won't be following PATH in the extension itself from the terminal you ran that command in post-launch.
And the terminals are working as expected. I think what you want is #1387 which will activate automatically for any normal terminal versus having to use Python: Create Terminal to get automatic environment activation.

I'm going to close this as I think the issue is a misunderstanding about what we can and cannot handle. If you think that's wrong, @alexwhittemore , then just let us know.

(First, thanks for putting up with my walls-of-text, I wish I knew how to make them more concise than they are without leaving out critical info)
I'm actually not so sure about that, and what you mention with issue 1387 actually makes me think there's even MORE going on here out of the ordinary than what we've talked about.
Let me start by clearing up some of the water I muddied in my last couple posts, as I've just done some exhaustive differential diagnosis in a clean macOS virtual machine where there's no way there are any confounding variables.
There are four variables at play here - python 2 vs 3, virtualenvwrapper and thus virtualenv, this fix-osx-virtualenv wrapper, and vscode itself.
Starting with fix-osx-virtualenv: I've verified that it doesn't interfere at all in any of my test cases EXCEPT with a python3 virtualenv, and for a reason that's easily worked-around. It doesn't change the PATH at all - I think it compiles to a Python.app that contains the binary you started with, which is all macOS needs to make all of its GUI APIs work correctly.
What was getting in the way there: you need to call fix-osx-virtualenv  to set up the magic Python.app in your virtualenv. The more-robust way to do that is in $WORKON_HOME/postactivate, which gets called every time you activate a virtualenv. Therefore, the check for the magic .app happens EVERY time the environment is activated, in case somehow it hadn't yet. But whatever that command does, it's like 5% broken in python 3.x, and it completes successfully, but it messes up vscode somehow in the case of vscode launched from an activated python3 virtualenv.
The solution to that is to put the magic check in $WORKON_HOME/postmkvirtualenv - only check for the magic Python.app when you make the virtualenv, and that code never runs after that.
With that out of the way:
So the proper workflow here to get a working vscode that executes your python in the virtual environment context is this:

mkvirtualenv -p python3 my_env # Or without -p, if you just want 2.7.x
workon my_env # This isn't strictly necessary, but you probably want your OS-terminal window in the venv while you're working, and it doesn't impact Code either way in the nominal case.
in Code, make a launch.json by adding a configuration (in my case, it's always python: current file)
In code, make a settings.json by shift-cmd-p "Python: Select Interpreter" and picking your virtualenv interpreter, regardless of whether that's what Code already reflects in the status bar bottom-left.
In my case, specifically, with the fix-osx-virtualenv shim in there, there will be two detected interpreter paths under the virtualenv directory, and the proper one to select is the Python.app one. Namely, my working settings.json:

{
    "python.pythonPath": "/Users/alexw/.virtualenvs/3_python_env/Python.app/Contents/MacOS/Python"
}

Even though at the terminal,
(3_python_env) macos-high-sierra:3_python_test alexw$ which python
/Users/alexw/.virtualenvs/3_python_env/bin/python

That part I totally don't understand, but I've established that it's immaterial - pick the Python.app path and all works perfectly.
Okay, so why do I think there is still some actual bug here?
Fundamentally, VSCode mangles $PATH, and I don't know of any good reason for it, which I think is fundamentally wrong whether it supports "activate virtualenv at temrinal; code .; everything works" functionality or not.
As a test, I did the following at a clean system terminal:
macos-high-sierra:~ alexw$ export PATH="/Users/alexw/.virtualenvs/3_python_env/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"
macos-high-sierra:~ alexw$ echo $PATH
/Users/alexw/.virtualenvs/3_python_env/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
macos-high-sierra:3_python_test alexw$ code .

Then, in the integrated terminal:
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/alexw/.virtualenvs/3_python_env/bin

So without doing ANYTHING else, Code upends my PATH. And I'm convinced, pending evidence, that this mangling is the root cause for why I can't simply workon my_env; code . and carry on with my day, as I can under Windows.
BUT I've got a test of that theory, and simultaneously a workaround!
Here's my whole ~/.bash_profile, annotated for clarity. The relevant part is the last block
# Do all the setup things that virtualenvwrapper demands
export WORKON_HOME=$HOME/.virtualenvs
source /usr/local/bin/virtualenvwrapper.sh

# This is a fix for electron apps, specifically code, under parallels with a macOS guest
# Parallels graphics system doesn't play nice with macOS and electron.
# These apps must be launched with "app --disable-gpu". The function below silently turns "code <dir>" into "code --disable-gpu <dir>"
alias code='function __code() { code $* --disable-gpu; unset -f __code; }; __code'

# This shenanigans activates orphaned virtual environments in VSCode.
# If VIRTUAL_ENV is set, you know that you're in a child shell launched from inside a virtualenv.
# I thought about just adding it back to the front of the path, but decided it'd be cleaner to do
# a full <workon the_env> just in case.
if [ -z ${VIRTUAL_ENV+x} ]; then
    :
    #echo "VIRTUAL_ENV is unset”
else
    # VIRTUAL_ENV is set to something.
    if [[ $PATH == ${VIRTUAL_ENV}* ]]; then
        # VIRTUAL_ENV is set but also is already at the beginning of the PATH
        :
    else
        echo VIRTUAL_ENV is set to $VIRTUAL_ENV, but is not at start of PATH. Reactivating.
        workon `basename $VIRTUAL_ENV`
        #PATH="${VIRTUAL_ENV}:${PATH}”
    fi
fi

Basically, I noticed that all the vscode contexts that I think SHOULD still have the virtualenv environment, and which have a mangled PATH, still have VIRTUAL_ENV set from the parent shell. So I figured, any time I open a shell, if that's set but the PATH is wrong, I should make sure the virtualenv in question is re-activated. This could break things in esoteric edge cases where I explicitly want something higher on my PATH than the venv, but otherwise, it achieves my exact desired result.
To test, I create a new project dir (with no .vscode/, no settings.json, no launch.json).
$ workon my_env
(my_env) $ code .

I then add a launch config (python: current file). my_env is already activated on all embedded terminals in Code, and when I click run, everything works as expected, launching the virtualenv python in the virtualenv context. In other words, this little bit of hackery achieves exactly the behavior I see under Windows by simply un-mangling the PATH.
Ok ok ok, so what about the "even more going on"? I'll hop on over to 1387 to chime in, might as well keep things in straight lines!

So we don't touch your PATH, which is how I know this isn't our doing. 😉 The closest we come to touching your PATH is when we activate an environment on your behalf.
As for why which python is something you're not expecting from your Python.app, I would do an ls -l and see if your Python.app isn't just a symlink.

Maybe YOU don't, but SOMEONE sure is, and I'd love to know who.
I just spun up a totally new, fresh, virgin, not-even-updated High Sierra virtual machine. Haven't installed homebrew, aftermarket Python, nothing.
I downloaded and installed code, opened it once to run the "install code command" command, installed the Python extension, then closed it.
In a terminal window,
extra-super-virgin-macos:~ alexw$ export PATH="/Users/alexw/Desktop:$PATH"
extra-super-virgin-macos:~ alexw$ echo $PATH
/Users/alexw/Desktop:/usr/local/bin:/usr/bin:/usr/sbin:/sbin
extra-super-virgin-macos:~ alexw$ code .

In fact, this environment is SO virgin the guest additions aren't installed yet and copy/paste doesn't work, so pardon any possible typos.
Back over in Code: Python: Create Terminal
extra-super-virgin-macos:~ alexw$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/alexw/Desktop

That is, on an utterly virgin system, vscode is somehow taking the PATH and doing bad things to it.
Of course, maybe by "we" you mean "the vscode-python team." But it's certainly vscode, and not something external to it, unless its some kind of OS-interaction-level bug.

@alexwhittemore yes, when I use the royal "we" I mean this repo and not VS Code. So the weird PATH manipulation seems to be a VS Code thing (make sure you have absolutely no extensions installed to verify), so I would report the issue to them.

Did just that - reproduced with a completely clean installation. Bug report here: https://github.com/Microsoft/vscode/issues/56125
Thanks!


Basic Security

Take the following security measures:

[x] Https by default
[x] Throttling requests
[x] Api key
[x] Check Json Web Tokens (JWT)

Throttling has been implemented, but is currently hard-coded. See weddini/spring-boot-throttling/issues/3

fixed with 51695a2