Can't store entities with embedded entities which have properties > 1500 bytes

Seems that excluding a top level property doesn't exclude an embedded entities properties from being indexed - on top of that, I don't believe there's a way to exclude an embedded entities individual properties, that would solve my problem too.
Steps to reproduce
Just use this script (I'm running the datastore emulator)
const Datastore = require('@google-cloud/datastore');
const datastore = new Datastore({ projectId: 'datastore-test' });

datastore.insert({
  key: datastore.key('User'),
  data: [
    {
      name: 'description',
      value: {
        text: Buffer.alloc(1501, 'a').toString(),
      },
      excludeFromIndexes: true
    }
  ]
}, (err, result) => {
  if (err) {
    console.error(err);
  } else {
    console.log(result.data);
  }
});

I'd expect there to be no error - the embedded entity ({ text: '...' }) shouldn't be indexed I believe? But it throw an error saying:
Error: The value of property "text" is longer than 1500 bytes.
Environment

OS: OS X Sierra
Node.js: v6.7.0
npm: 3.10.3
@google-cloud/datastore: v0.6.0

Thanks for reporting.
@pcostell is it possible in Datastore to exclude individual properties within an Entity from indexing?

FWIW I've had a play with the datastore save method to support the explicit syntax on nested properties e.g.
datastore.insert({
  key: datastore.key('Stuff'),
  data: [{
    name: 'description',
    value: [{
      name: 'text',
      value: Buffer.alloc(1501, 'a').toString(),
      excludeFromIndexes: true
    }, {
      name: 'long',
      value: true
    }]
  }]
}, handler);

obviously though that wouldn't work as an interface as it would break any properties that have array values e.g. this would break:
datastore.insert({
  key: datastore.key('Stuff'),
  data: [{
    name: 'foo',
    value: [ 1, 2, 3 ]
  }]
}, handler);

For reference, this is the hacked reduction (previously here) function to make this work:
function encodeValues(acc, data) {
  var value;

  if (is.array(data.value)) {
    value = {
      entityValue: {
        properties: data.value.reduce(encodeValues, {})
      }
    };
  } else {
    value = entity.encodeValue(data.value);

    if (is.boolean(data.excludeFromIndexes)) {
      var excluded = data.excludeFromIndexes;
      var values = value.arrayValue && value.arrayValue.values;

      if (values) {
        values = values.map(propAssign('excludeFromIndexes', excluded));
      } else {
        value.excludeFromIndexes = data.excludeFromIndexes;
      }
    }
  }

  acc[data.name] = value;

  return acc;
}

Excluding a top-level entity value will exclude it and all its sub-values from indexing. However, it still must be a valid entity. This means that properties that cannot be indexed should be marked accordingly.
In the Datastore proto API, this is done by passing excludeFromIndexes at the appropriate levels. This is important from an API perspective because it means an entity value is a valid entity (and could be moved to a top-level entity if desired).

@pcostell so am I right in thinking that if a top level value was marked as to be excluded from indexing, it would be safe for this SDK to mark all sub-values to be excluded? Given that even if not explicitly excluded they will still be as they're nested inside a value that was excluded.

That would be safe, but it would represent a departure from the design of the API.

I'm guessing it would be hard to introduce a syntax that would allow excludeFromIndexes on sub properties, while maintaining backwards compatibility @stephenplusplus?
Until that's achieved, would passing down exclude when set on the top level property be viable? I've got the beginnings of it in a branch, happy to make a PR

Yes, this would be breaking, however we could try something like:
datastore.insert({
+ raw: true,
  key: datastore.key('Stuff'),
  data: [
    {
      name: 'description',
      value: [
        {
          name: 'text',
          value: Buffer.alloc(1501, 'a').toString(),
          excludeFromIndexes: true
        },
        {
          name: 'long',
          value: true
        }
      ]
    }
  ]
}, handler);

If raw is set, it would be required that all values inside of data are specified in the longhand/verbose syntax. Any chance I'm overlooking something that makes this unfeasible?

@stephenplusplus I don't think that would work for storing array values?
What about the raw flag needed the explicit encoded value returned by encodeValue? I think that's the proto value? You could also open up the encodeValue function to help users e.g:
datastore.insert({
  key: datastore.key('Stuff'),
  data: {
    description: {
      text: Buffer.alloc(1501, 'a').toString(),
      long: true
    },
    values: [ 1, 2, 3 ],
  }
}

the user could then transform into a raw value by:
datastore.insert({
  raw: true,
  key: datastore.key('Stuff'),
  data: {
    description: Datastore.encodeValue({
      text: Datastore.encodeValue(Buffer.alloc(1501, 'a').toString(), { exclude: true }),
      long: Datastore.encodeValue(true)
    }),
    values: Datastore.encodeValue([ 1, 2, 3 ]),
  }
}

Not sure if I've got the syntax right, but that's the idea. Also more likely the user would do it programmatically.

@stephenplusplus I don't think that would work for storing array values?

Sorry, I've had my head in many APIs lately. Would you mind showing a bit of code that would highlight this problem?

@stephenplusplus  sure, so if I wanted to store the following JS Object:
var personEntity = {
  name: "Mary",
  metadata: {
    bio: "..." // Some long string > 1500 bytes
  },
  subjects: [{
    name: "history",
    credits: 2
  }, {
    name: "french",
    credits: 4
  }, {
    name: "maths",
    credits: 4
  }]
}

I need to have entity.metadata.bio excluded from indexes. Using the raw flag and syntax provided above, I could do this, however I couldn't store the subjects prop as an array e.g.
var rawPersonEntity = [{
  name: "name",
  value: "Mary"
}, {
  name: "metadata",
  value: [{
    name: "bio",
    value: "...", // Some long string > 1500 bytes
    excludeFromIndexes: true
  }]
}, {
  name: "subjects",
  value: [] // What do I do here? An array will indicate explicit syntax of { name, value }
}]

Got it, thank you! Would it make sense to recurse the data property?
var rawPersonEntity = {
  key: datastore.key('Person'),
  data: [
    {
      name: 'name',
      value: 'Mary'
    },
    {
      name: 'metadata',
      data: [
        {
          excludeFromIndexes: true,
          name: 'bio',
          value: '...'
        }
      ]
    },
    {
      name: 'subjects',
      value: [
        {
          name: 'history',
          credits: 2
        },
        // ...
      ]
    }
  ]
}

Otherwise, I think the raw flag on a nested level could have the same effect:
var rawPersonEntity = {
  key: datastore.key('Person'),
  data: [
    {
      name: 'name',
      value: 'Mary'
    },
    {
      name: 'metadata',
      raw: true,
      value: [
        {
          excludeFromIndexes: true,
          name: 'bio',
          value: '...'
        }
      ]
    },
    {
      name: 'subjects',
      raw: false, // (the default value, but explicitly set for demonstration)
      value: [
        {
          name: 'history',
          credits: 2
        },
        // ...
      ]
    }
  ]
}

Do either of these have any quirks, and if not, which is better? If neither, we can still keep trying :)

@stephenplusplus thanks for the options - I think the data seems to make the more sense to me... i.e. value is for more 'basic' types, and data for embedded objects.
It's pretty fringe edge case at this point - and I'm not sure if it's even possible to do, but if you had an array of objects, could you index them?
e.g.
var rawPersonEntity = {
  key: datastore.key('Person'),
  data: [
    {
      name: 'name',
      value: 'Mary'
    },
    {
      name: 'metadata',
      data: [
        {
          excludeFromIndexes: true,
          name: 'bio',
          value: '...'
        }
      ]
    },
    {
      name: 'subjects',
      value: [
        {
          excludeFromIndexes: true, // Is this something that can be done? Is there a reason why it would be done?
          name: 'history',
          credits: 2
        },
        // ...
      ]
    }
  ]
}

Other than that, I can't see any issue with them...Another option would be making an datastore.value style factory - like datastore.key - where you can specify types and the data associated with it e.g.
datastore.insert({
  key: datastore.key('Person'),
  data: datastore.value({
    type: datastore.Entity, // Defaults to 'auto'
    data: {
      name: datastore.value({
        type: String,
        value: 'Mary'
      }),
      metadata: datastore.value({
        type: datastore.Entity,
        value: {
          bio: datastore.value({
            type: String,
            excludeFromIndexes: true,
            value: '...'
          })
        }
      }),
      subjects: datastore.value({
        type: Array,
        value: [
          datastore.value({
            type: datastore.Entity,
            value: {
              name: datastore.value({
                type: String,
                value: 'history',
              }),
              credits: datastore.value({
                type: Number,
                value: 2
              })
            }
          },
          datastore.value({
            type: datastore.Entity,
            value: {
              name: datastore.value({
                type: String,
                value: 'french',
              }),
              credits: datastore.value({
                type: Number,
                value: 4
              })
            }
          },
          datastore.value({
            type: datastore.Entity,
            value: {
              name: datastore.value({
                type: String,
                value: 'maths',
              }),
              credits: datastore.value({
                type: Number,
                value: 4
              })
            }
          }
        ]
      })
    }
  });

Ha - after writing that all out, I realise how incredibly over the top that looks, but it feels robust. Perhaps not as a candidate for quickly writing out simple entities, but perhaps as a way that will work well with a helper utility? e.g. for my use case, I'm converting incoming JSON to an entity, and I want to automatically recursively step through it and add excludeFromIndexes as needed...thoughts?

@stephenplusplus Is this a bug in the client, a bug in the service, or user support to workaround a documented limitation?

Looking forward to seeing an improvement on this front. I also noticed a nested array type is forced to be indexed. Also I was hoping the API would let me store nested JSON but I can't figure out if it's possible to do with this API. Exposing something like a datastore.entry factory method would make sense.

Any updates on this? Happy to make a PR if needed
Also @kzahel it will allow nested JSON if you just give it a JSON object as a property, but just can't specify excludeFromIndexes on nested properties, that's where the factory function would help.

Looking back over this, how about using a Symbol to specify excludeFromIndexes?
You could then use regular ol' syntax in the data prop. But add in a flag using symbols, e.g.
datastore.insert({
  key: datastore.key('Stuff'),
  data: {
    description: {
      text: Buffer.alloc(1501, 'a').toString(),
      long: true,
      [ datastore.EXCLUDE_FROM_INDEXES ]: true
    },
    values: [ 1, 2, 3 ]
  }
}

much like how datastore.KEY can now be used.
I still think a factory method is more explicit, and cleaner, but symbol might be a bit easier to integrate with the current setup.

I'm intrigued! And thank you for your offer to help. @callmehiphop what do you think about using a Symbol the way @bedeoverend demo'd above?

Using the symbol is clever and makes sense, I think. I already have to use datastore.KEY symbol to get the actual key from a result.

On this point (and this might be diverging from the original issue), could you now just use the KEY symbol, rather than key for insert?
e.g.
datastore.insert({
  [datastore.KEY]: datastore.key('Stuff'),
  foo: 'bar'
});

Therefore flattening it out. I guess that'd be tricky for backwards compatibility?

Using a symbol seems fine to me. I prefer the more verbose syntax first proposed over the [datastore.KEY] syntax in the most recent comment.

We can't write string properties over 1500 chars. Is this expected? Is there some way to explicitly mark a property as 'text' instead of 'string'?

Let's say we have an entity with a property of "text" type, i.e. not string.
When the property is updated (with unindexed string), the type of the property is changing from "text" to "string".
This breaks some other software, which expects to have "text" property.

The question is: how to write >1500 chars as a "text"?

Could I ask what the status of this issue is?  I have some entities that have embedded entities that have properties that are >1500 Bytes.  When I try setting excludeFromIndexes: true on the embedded entity I still get an error thrown for its sub-properties that are >1500 Bytes.  Is there some way I can store them?

Just piping in that I'd opened an issue for this internally several days ago, but I'd routed it to the wrong place. Corrected, and looks like @stephenplusplus is aware.

@stephenplusplus This issue may be related to a fixed issue in python:
https://github.com/GoogleCloudPlatform/google-cloud-python/issues/1206

For me, it happens in the web console as well - is that related or am I missing something?

I followed the following steps to exclude from index for indexed properties of an Embedded Entity type from datastore:
Lookup (get) the entity from Cloud Datastore.
Write (update) the entity back to Cloud Datastore with excluded index.

However when I look at the Entities overview page, each of the properties of the Embedded Entity are still indexed even after the update, is this the right behavior?
From the docs for excluding indexes it mentions "The index entries for any existing entities with that property will continue to exist until the entities are updated or deleted."

I just pumped in to this issue. We have data structure where under main entity there is embedded entity (or actually array of entities) that has a property that is longer than 1500 bytes. As we can't exclude this >1500b property from indexing, we can't store even the main entity.
Is there any progress on this? Basically datastore is unusable for us at this point

@jniemin I had the same issue and found 2 workarounds: One is utilizing the hierarchy supported in Datastore - one entity can be a child of another so if the embedded entity is complex - I suggest you take it out into a new entity where the parent of it is the original one.
Another (sort of) workaround I used is just simplifying the embedded entity by taking some properties back to the parent itself - not ideal but in my case it made sense.

Thanks for your patience, everyone. There are a couple of solutions we've talked about, but I'd like to get feedback on one more that might be the most simple. Can you see any "gotchas" using an "excludeFromIndexes" array on the top level to define where the unindexed properties are?
(cc @bedeoverend)
datastore.insert({
  key: datastore.key('Person'),
  excludeFromIndexes: [
    'description',
    'metadata.bio',
    'subjects.name'
  ],
  value: {
    description: '...',
    metadata: {
      bio: '...'
    },
    subjects: [
      {
        name: '...',
        credits: 2
      }
    ]
  }
})

This seems like it would also be more simple than the current "data"/verbose definition syntax for non-nested properties, i.e.
// before
datastore.insert({
  key: datastore.key('Person'),
  data: [
    {
      name: 'description',
      value: '...',
      excludeFromIndexes: true
    }
  ]
})

// after
datastore.insert({
  key: datastore.key('Person'),
  excludeFromIndexes: ['description'],

  // `data` remains a plain JavaScript object:
  data: {
    description: '...'
  }
})

Summoning @JayGoldberg for feedback also. We can implement this if there are no objections to @stephenplusplus's proposed solution.

Small amendment to the above suggestion, since subjects is an array:
datastore.insert({
  key: datastore.key('Person'),
  excludeFromIndexes: [
    'description',
    'metadata.bio',
-   'subjects.name'
+   'subjects[].name'
  ],
  value: {
    description: '...',
    metadata: {
      bio: '...'
    },
    subjects: [
      {
        name: '...',
        credits: 2
      }
    ]
  }
})

Is that amendment necessary? It is unambiguous even in your previous construction.

I think it follows standard embedded property notation, to differentiate between "property of an object" and "property of an object inside of an array". I've also seen this in API response documentation on the Google Docs site. So no, not necessary, but should be more familiar. Willing to be downvoted on that assumption.

PR sent in #2497. Please take a look!

@stephenplusplus thanks for this suggestion! Looks good to me, I like the general concept.
So two potential things:

Is your proposed solution also allowing for exclusion for all nested properties? e.g. Will excluding metadata exclude all properties / nested entities beneath it? Alternatively could a metadata.* be also supported?

Suppose you hold an array of values which don't all follow the same schema:

{
  data: [{
    foo: '...'
  }, {
    bar: '...'
  }]
}

Should this solution also try address not indexing one particular entity's property? e.g. a syntax like: data.0.foo? I'm not sure if this is even supported by datastore's indexing...? But a scenario where this might be appropriate is something like storing a series of metadata objects, and searching for arbitrary values inside them. I'm not sure how valid a use case this is, but just flagging it.
Other than that, I think it looks good 👍

I am pretty sure that trying to do data.0.foo sounds not great:

It is ambiguous in JavaScript because data = {'0': { 'foo': ... }} is distinct from data = [{'foo': ... }].
In the case of differing schemas, @stephenplusplus's current solution still works, since data[].bar just does not match.

I do agree that some concept of * and ** would be useful, but it is technically orthogonal -- we should get the current PR in, and then maybe do that.

I think it follows standard embedded property notation, to differentiate between "property of an object" and "property of an object inside of an array". I've also seen this in API response documentation on the various Google API official docs sites. So no, not necessary, but should be more familiar. Willing to be downvoted on that assumption.

Prior art, got it. I am convinced.

It is ambiguous in JavaScript...
In the case of differing schemas, @stephenplusplus's current solution still works

Fair enough - I guess there could be the scenario of similar / same schemas, but wanting to exclude only one item from being indexed. But, I think that's a big edge case, and I think it would be a bad pattern regardless, so happy to ignore that.

we should get the current PR in, and then maybe do that.

Sounds good to me 👍

Thanks for the "fix", but can this please be updated in the documentation? Personally, I think it's weird that I have to exclude every single subproperty from indexing but the bigger issue is that the documentation currently says that "If you exclude this value from indexing, then all subproperties are also excluded from indexing". This is very misleading (at least it was for me) and it took quite a while to find this issue.
@lukesneeringer Is there already an issue for your "*" concept which would make this issue a lot easier to handle, or can I create that one (I couldn't find one but wanted to double check before creating that)?

Here's the issue for the catch-all feature request: #2510

How do you exclude properties that are not written in camel case?

This worked for me:
datastore.save({
  key: ...,
  data: {
    test: {
      'This is a key': 'This is a string > 1500 bytes ...'
    }
  },
  excludeFromIndexes: [
    'test.This is a key'
  ]
}, ...)


Add support to combine different kind of Charts

or is it already possible.
btw. I love the charts!

@b3t4m1n  Thanks a lot for the support! I was too busy the last two months to contribute to Charts. However, I have a lot of changes locally regarding Multi-Platform support. I will try to push this ASAP because it is a top priority for now.
After that, I'll work on other open issues, including this one.
Could you please give me one example of combined charts, and you can add more details?
Thanks!

like combining the Line Chart and Bar Chart (Stacked or Grouped)


Swiper React: How to change the direction of slides to Vertical?

Check that this is really a bug

[X] I confirm

Reproduction link
https://codesandbox.io/s/swiper-js-react-vertical-qudlqi?file=/src/App.js
Bug description
In Swiper.js you can change the attribute of the direction to vertical and then the slides move vertically. With the Swiper React package if you change to vertical it doesn't work and the slider breaks.
Expected Behavior
The expectation is that when you change direction to vertical the slider will work and slides will move vertically instead of horizontally.
Actual Behavior
Slider breaks and slides are not moving in a vertical direction.
Swiper version
8.3.1
Platform/Target and Browser Versions
Safari, Chrome
Validations

[X] Follow our Code of Conduct
[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.
[X] Make sure this is a Swiper issue and not a framework-specific issue

Would you like to open a PR for this bug?

[ ] I'm willing to open a PR

This is referring to the Swiper React package not the common API. You're referring to a Method above from the API, but there's no documentation on how or the ability to add the Method referenced above to the Swiper React component here: https://swiperjs.com/react


Blender exporter doesn't support null as a camera's parent

Create a camera under a parent in blender. That parent had a rotation applied to it so the camera would face where I wanted it to. But when I exported to babylon, the camera was looking at the place where it was when there were no rotation applied to its parent.

Think this might be related to the order things are re-created when the .babylon is read.  The setting of a camera's parent is a delayed action in FileLoader.js.  If the rotation has already been applied on the parent mesh?, before parent was assigned, not sure if this rotation would be applied to camera.
If correct, then would apply to any exporter, not Blender specific.

Hello this is because the camera has a target to it is constrained to keep looking at this target

We noticed this behavior with a free camera, which I believe isn't constrained.  We will look into this further.

Even freecamera can be target locked

We have also reproduced the issue with object hierarchies that do not include cameras.  We can share a *.blend file that when exported to Babylon demonstrates the issue.

Here is a blender file that reproduces the issue with just an object hierarchy:
https://www.dropbox.com/s/5vuwjrowd86fna0/children-blender.zip?dl=0
What it looks like in Blender:

What it looks like in Babylon.js from the same camera position:

The hierarchy is cone, cylinder, box.  The cone is correct, but the cylinder on the cone is wrong, and so is the box on the cylinder.


Porting Resources into Dashboard

2.5 Issue to track status of resources to port over. Updated based on what is done for 2.5.
Each resource is expected to have a list page, create/edit page and detail page.

[x] Workloads -
[x] Load Balancing -> Ingresses rancher/dashboard#272
[x] Service Discovery -> Services rancher/dashboard#573
[x] Secrets (Secrets, Cert, Registry Credentials) -https://github.com/rancher/dashboard/issues/264
[x] Config Maps - https://github.com/rancher/dashboard/issues/265
[x] Namespaces - #567
[x] Cluster Overview - rancher/dashboard#350
[x] Nodes (No create page) rancher/dashboard#241

These are all tracked in separate tickets at this point and moved remaining resources into a different issue: https://github.com/rancher/dashboard/issues/1147


added OpenMP tuning feature: it's now possible to limit number of Ope…

…nMP threads used by specific components (cpp or batch operators) using regular expressions to match those components

It Compiles and works with exaDEM.


flash of unstyled popup

After answering a review question and hitting the f key, there is a very brief popup before the info section is expanded. Unfortunately it's a light background so it's annoying.
I can't figure out how to capture the markup though to figure out how to style it. It disappears too quickly.
I'll try emulating a low-bandwidth connection.

I don't know if it would help but WK Breeze has it stylized https://community.wanikani.com/t/userstyle-wanikani-breeze-dark/16973 might be worth to inspect the code of it

I'll take a look, but I need to know what the markup looks like (at least the class name of f the pseudo-element.
I'll figure it out eventually.


LWM2M registration timeout

Describe the bug
The lwm2m example throws LWM2M registration timeout . The device seems to connect to the leshan server as i can see that on web interface of leshan-demo-server (which is running on http://localhost:8080 ). the client last update changes in every 30-45 second with new registration id.
uart log:
[00:04:52.172,454]  net_lwm2m_rd_client: RD Client started with endpoint 'nrf52840_pca10056' and client lifetime 30
[00:04:52.682,037]  net_lwm2m_rd_client.sm_send_registration: Non dtls
[00:04:52.682,067]  net_lwm2m_rd_client.sm_send_registration: registration sent [fdde:ad00:beef:0:3696:3458:e373:be67]
[00:04:55.036,499]  net_lwm2m_engine.retransmit_request: Resending message: 0x20001750
[00:04:59.726,745]  net_lwm2m_engine.retransmit_request: Resending message: 0x20001750
[00:05:09.097,259]  net_lwm2m_engine.retransmit_request: Resending message: 0x20001750
[00:05:27.828,308]  net_lwm2m_rd_client: Registration Timeout
[00:05:27.828,308]  net_lwm2m_client_app.rd_client_event: Disconnected
[00:05:27.828,308]  net_lwm2m_client_app.rd_client_event: Registration failure!
To Reproduce
Steps to reproduce the behavior:

cd sample/net/lwm2m

mkdir build && cd build

cmake -GNinja -DBOARD=nrf52840_pca10056 -DOVERLAY_CONFIG=overlay-ot.conf ..
overlay-ot.conf.txt

ninja

Expected behavior
It should successfully connected to the leshan server
Screenshots or console output

Environment (please complete the following information):

OS: Linux
Toolchain: Zephyr-sdk
Commit id : 06d7835

Oddly, I don't see overlay-ot.conf here: https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/net/lwm2m_client
I was going to add one, once https://github.com/zephyrproject-rtos/zephyr/pull/12343 is merged and communication via OT border router confirmed.
But right now, I don't think this is an issue?

I am using overlay-ot.conf defined in echo_client example. I think it is serving it's purpose. please take a look at look if i am missing something in that file. and of course i will check that PR #12343

@mike-scott what is the status here?

I need to merge an OpenThread overlay.conf that I've tested before this can be fixed.  It's not so much of a "bug" as an untested feature atm.

@nashif Do I have the ability to get an OpenThread overlay for LwM2M into 1.14 now that the freeze is active?

Removed bug tag and replaced with feature

got it working after pr merger.

Hi @arn-soft, Can you help to share your overlay-ot.conf file for lwm2m. I test with the overlay-ot.conf.txt you shared in the first post but it can not run. Thanks.

@andynnd Can you open a new issue asking for an overlay-ot.conf to be added to the LwM2M sample?  I have one and will get to it when I'm back from ELC.

@mike-scott I just open a new issue at https://github.com/zephyrproject-rtos/zephyr/issues/18601. Thanks.


Report Godot errors with a timestamp

It would be nice to have errors reported with a timestamp that happened prior to a crash or event.

Logging is managed by https://github.com/godotengine/godot/blob/master/core/io/logger.h
This functionality is not exposed in Godot API, and as such cannot be used in GDExtension/GDScript.
AFAIK, there are two PRs possibly landing in Godot that expose logging:

https://github.com/godotengine/godot/pull/87576
https://github.com/godotengine/godot/pull/91006

For the time being, we can explore a log-based parser and see how performant such approach can be.

We have intermediate solution in place. Waiting for logging to be exposed in the Godot Engine API.

https://github.com/godotengine/godot/pull/91006


Fix hardcoded dimensions

Fix hardcoded dimensions
Fixes #3197 The xml files contain a lot of hardcoded dimensions
Tests performed
Gradle build successfully.

Why there are conflicts with java files if I have not changed that files? Thanks

I guess there are conflicts because of a recent refactoring?
Please rebase from master, I believe that should fix the problem :-)

How I rebase from master? Git says that my branches are updated.

First fetch upstream.
Try this: git rebase -i origin/master

Thanks @yashk2000:

First fetch upstream.
Then try: git rebase -i origin/master

Sorry, these git operations are a bit difficult for me. I don't know what I'm doing, but somehow I've pushed two more commit with "yesterday" as date :confused:. Help needed!

Please ignore this PR, I'm going to open another to try to solve the problems.


Train ML models with different hyper parameters and features

Please describe the use case that requires this feature.
Train and apply multiple regressors and/or classifiers for different hyper parameters and features.
Describe the solution you'd like
Currently the class name of the model is used as a prefix for the keys in the table.
Adding a traitlet for the prefix for these models would allow the user to store the output of multiple ml classes in the table without overwriting the output of other models.

Unfortunately, the config system does not allow having the same class with different configs, so it is at the moment impossible to configure e.g. two EnergyRegressor instances in the reconstructors list with different settings.
This will thus have to wait until we change the config system. Until then, multiple outputfiles have to be used I think.

#1406

The config system is something I think will be overhauled in ctapipe-2.x as it is going to be a large change, for 1.x what we have now is fine and we shouldn't delay because of it (we can just run multiple trainings, for example)


Layoutoption: horizontal layout

Hey.
It would be practical if the tool could be easily integrated into the website. For this, an option to display the posts in a horizontal layout would be great.

Hi, could you post a screenshot of what you are aiming for? As of now, the masonry grid is responsive with a grid of 4/2/1 columns and should quite nice fit on a website...


feat: reworked flag handling

:tada: This PR is included in version 2.10.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Patch provisioning after all crs were created.

Patching the provisioning causes the metal3 pod to restart.
This interferes with creating bmh instances.
Signed-off-by: Alexander Chuzhoy<EMAIL_ADDRESS>Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes # (issue)
Type of change
Please select the appropriate options:

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

Testing
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[ ] Test A
[ ] Test B

Test Configuration:

Versions:
Hardware:

Checklist

[ ] I have performed a self-review of my own code
[ ] If a change is adding a feature, it should require a change to the README.md and the review should catch this.
[ ] If the change is a fix, it should have an issue. The review should make sure the comments state the issue (not just the number) and it should use the keywords that will close the issue on merge.
[ ] A change should not be merged unless it passes CI or there is a comment/update saying what testing was passed.
[ ] PRs should not be merged unless positively reviewed.

/test-ci

CI passed:

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


devon/refactor → develop

merging the new game engine

Codecov Report

Merging #52 into develop will decrease coverage by 5.62%.
The diff coverage is 96.09%.

@@             Coverage Diff             @@
##           develop      #52      +/-   ##
===========================================
- Coverage      100%   94.37%   -5.63%
===========================================
  Files            8        6       -2
  Lines          345      480     +135
  Branches        46       69      +23
===========================================
+ Hits           345      453     +108
- Misses           0       23      +23
- Partials         0        4       +4

Impacted Files
Coverage Δ

dork/game_utils/game_data.py
100% <ø> (ø)
:arrow_up:

dork/__init__.py
100% <100%> (ø)
:arrow_up:

dork/game_utils/factory_data.py
100% <100%> (ø)

dork/repl.py
94.44% <86.66%> (-5.56%)
:arrow_down:

dork/types.py
93.91% <96.29%> (-6.09%)
:arrow_down:

Continue to review full report at Codecov.

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


Can't compile app with Java 8

When compiling my app with Java 8 enabled, i'm getting weird error:
`Error:Execution failed for task ':app:transformClassesWithDesugarForDebug'.

com.android.build.api.transform.TransformException: java.lang.RuntimeException: java.lang.RuntimeException: com.android.ide.common.process.ProcessException: Error while executing java process with main class com.google.devtools.build.android.desugar.Desugar with arguments {--input /home/alex/AndroidStudioProjects/TestJava8/app/build/intermediates/transforms/stackFramesFixer/debug/4.jar --output /home/alex/AndroidStudioProjects/TestJava8/app/build/intermediates/transforms/desugar/debug/5.jar --input /home/alex/AndroidStudioProjects/TestJava8/app/build/intermediates/transforms/stackFramesFixer/debug/0.jar --output /home/alex/AndroidStudioProjects/TestJava8/app/build/intermediates/transforms/desugar/debug/1.jar --input /home/alex/AndroidStudioProjects/TestJava8/app/build/intermediates/transforms/stackFramesFixer/debug/2.jar --output /home/alex/AndroidStudioProjects/TestJava8/app/build/intermediates/transforms/desugar/debug/3.jar --classpath_entry /home/alex/AndroidStudioProjects/TestJava8/app/build/intermediates/classes/debug --classpath_entry /home/alex/AndroidStudioProjects/TestJava8/app/build/intermediates/transforms/stackFramesFixer/debug/0.jar --classpath_entry /home/alex/AndroidStudioProjects/TestJava8/app/build/intermediates/transforms/stackFramesFixer/debug/1.jar --classpath_entry /home/alex/AndroidStudioProjects/TestJava8/app/build/intermediates/transforms/stackFramesFixer/debug/2.jar --classpath_entry /home/alex/AndroidStudioProjects/TestJava8/app/build/intermediates/transforms/stackFramesFixer/debug/3.jar --classpath_entry /home/alex/AndroidStudioProjects/TestJava8/app/build/intermediates/transforms/stackFramesFixer/debug/4.jar --classpath_entry /home/alex/AndroidStudioProjects/TestJava8/app/build/intermediates/transforms/stackFramesFixer/debug/5.jar --classpath_entry /home/alex/AndroidStudioProjects/TestJava8/app/build/intermediates/transforms/stackFramesFixer/debug/6.jar --classpath_entry /home/alex/AndroidStudioProjects/TestJava8/app/build/intermediates/transforms/stackFramesFixer/debug/7.jar --classpath_entry /home/alex/AndroidStudioProjects/TestJava8/app/build/intermediates/transforms/stackFramesFixer/debug/8.jar --classpath_entry /home/alex/AndroidStudioProjects/TestJava8/app/build/intermediates/transforms/stackFramesFixer/debug/9.jar --classpath_entry /home/alex/AndroidStudioProjects/TestJava8/app/build/intermediates/transforms/stackFramesFixer/debug/10.jar --classpath_entry /home/alex/AndroidStudioProjects/TestJava8/app/build/intermediates/transforms/stackFramesFixer/debug/11.jar --classpath_entry /home/alex/AndroidStudioProjects/TestJava8/app/build/intermediates/transforms/stackFramesFixer/debug/12.jar --classpath_entry /home/alex/AndroidStudioProjects/TestJava8/app/build/intermediates/transforms/stackFramesFixer/debug/13.jar --classpath_entry /home/alex/AndroidStudioProjects/TestJava8/app/build/intermediates/transforms/stackFramesFixer/debug/14.jar --classpath_entry /home/alex/AndroidStudioProjects/TestJava8/app/build/intermediates/transforms/stackFramesFixer/debug/15.jar --classpath_entry /home/alex/AndroidStudioProjects/TestJava8/app/build/intermediates/transforms/stackFramesFixer/debug/16.jar --classpath_entry /home/alex/AndroidStudioProjects/TestJava8/app/build/intermediates/transforms/stackFramesFixer/debug/17.jar --classpath_entry /home/alex/AndroidStudioProjects/TestJava8/app/build/intermediates/transforms/stackFramesFixer/debug/18.jar --classpath_entry /home/alex/AndroidStudioProjects/TestJava8/app/build/intermediates/transforms/stackFramesFixer/debug/19.jar --classpath_entry /home/alex/AndroidStudioProjects/TestJava8/app/build/intermediates/transforms/stackFramesFixer/debug/20.jar --classpath_entry /home/alex/AndroidStudioProjects/TestJava8/app/build/intermediates/transforms/stackFramesFixer/debug/21.jar --bootclasspath_entry /home/alex/Android/Sdk/platforms/android-26/android.jar --bootclasspath_entry /home/alex/Android/Sdk/platforms/android-26/optional/org.apache.http.legacy.jar --bootclasspath_entry /home/alex/Android/android-studio/jre/jre/lib/resources.jar --bootclasspath_entry /home/alex/Android/android-studio/jre/jre/lib/rt.jar --bootclasspath_entry /home/alex/Android/android-studio/jre/jre/lib/jsse.jar --bootclasspath_entry /home/alex/Android/android-studio/jre/jre/lib/jce.jar --bootclasspath_entry /home/alex/Android/android-studio/jre/jre/lib/charsets.jar --min_sdk_version 16 --desugar_try_with_resources_if_needed --desugar_try_with_resources_omit_runtime_classes}`

This error is reproducible only when implementation "com.leanplum:Leanplum:+" is in my build.gradle

Not sure why this happens. The actual stack trace does not show that its related to core leanplum sdk.
We are using java8 here by default too...
Can you try to build the sdk from source, and see if you get any other errors/insights?
https://github.com/Leanplum/Leanplum-Android-SDK#build-the-sdk

Hi @benmarten
I was able to build the sdk from source (from master).
But when i put Leanplum.jar into my /libs folder - i got the same error. (implementation "com.leanplum:Leanplum:+" was removed from my build.gradle)

I have the same issue. Any updates?

I can confirm that issue is not present when library is built using AndroidStudio 3.0 and Gradle 4.1. This PR should fix the issue #112

Hi @benmarten
Any update regarding this issue?

Hi @AlexZvonik,
We will add #112 to our next release, and as @milos1290  mention above - it will help.

@AlexZvonik, btw if you change minSdkVersion in your test project to 24 it will compile...

@Enuviel thanks!
Unfortunately i can't change minSdkVersion so i will wait for the next release.

@AlexZvonik Retrolambda? AS3 will show some warning, but that should work until next major release.

We are having the same problem. Using AndroidStudio 3.0 and Gradle 4.1/ Java 8, LeanPlum 3.0.1
Retrolambda solves the problem, thank you @Enuviel

Hi, can you please tell when are planning next release? Thanks.

It's in our current sprint. I think we'll cut a new release branch and start QA today. If there are no issues, release should be coming in a few days...

Do you have any updates on this? Thanks!

https://github.com/Leanplum/Leanplum-Android-SDK/releases/tag/3.0.2

@Enuviel
This bug can be reproduced on the latest SDK version

Hi @AlexZvonik is this issue still present for you?


[SPARK-6675][SQL]Hive setConf issue

Copy of hive configuration to SQLContext Configuration is overwriting the new configurations. So overwriting is disabled to allow newly set configurations to take precedence.

Can one of the admins verify this patch?

ok to test

Test build #30092 has started for   PR 5457 at commit 76f0400.

Test build #30092 has finished for   PR 5457 at commit 76f0400.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.
This patch does not change any dependencies.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/30092/
Test FAILed.

Test build #30165 has started for   PR 5457 at commit 6c2ae87.

Test build #30165 has finished for   PR 5457 at commit 6c2ae87.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.
This patch does not change any dependencies.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/30165/
Test PASSed.

I think the real problem here is that the initialization of the config is lazy, and if we want to fix this the approach should look like: #3895

Can one of the admins verify this patch?

@gvramana would you mind closing this PR since it's mostly gone stale? I believe @marmbrus is suggesting a better fix elsewhere.

@gvramana Seems SPARK-6675 has been fixed in 1.4 branch and master. Can you close this one?


DSEGOG-296 add e2e test suite against real API

Description
Adds an additional playwright test suite that runs against a real API instance to test integration between the front and backend. Note we only test things that test how we communicate with the backend is correct - any extra testing should be done in the mocked e2e tests only.
Most of the file changes are from moving the existing playwright tests into a subfolder
There's one test that doesn't pass when ran against the dev server instead of the CI data - so that test is skipped when not in a CI environment.
Matt said he's willing to maintain the "set up the backend" part of the new workflow
TODO: once this is merged in, re-instate the branch protection rules for the new jobs
Testing instructions
Add a set up instructions describing how the reviewer should test the code

[ ] Review code
[ ] Check Actions build
[ ] Review changes to test coverage
[ ] See if you can run the tests locally against the dev server

Agile board tracking
Closes DSEGOG-296

We found something I thought would be worth raising while trying to run the standard playwright tests initially. When running the e2e tests on a rocky 8 VM we had an permission error on mkdir while it tried to create the playwright-report folder. This was ultimately resolved it by running chmod -R a+rw . to change the permissions of the whole folder. It didn't happen on WSL and it seems the rocky 8 machine used a different user for docker.
While debugging this Viktor pointed out this may have been easier to debug if the tests had their own Dockerfile rather than being on a single line and also only copying in only the required files instead of mounting everything.

We found something I thought would be worth raising while trying to run the standard playwright tests initially. When running the e2e tests on a rocky 8 VM we had an permission error on mkdir while it tried to create the playwright-report folder. This was ultimately resolved it by running chmod -R a+rw . to change the permissions of the whole folder. It didn't happen on WSL and it seems the rocky 8 machine used a different user for docker.
While debugging this Viktor pointed out this may have been easier to debug if the tests had their own Dockerfile rather than being on a single line and also only copying in only the required files instead of mounting everything.

@joelvdavies @joshuadkitenge I think I figured out a fix - if I set it so the container runs as the current user then it works on Linux (both Rocky 8 cloud VM and WSL) (we still use pwuser on Windows but that doesn't have permissions issues so it's fine). As I said, I want to avoid creating a custom docker container as all we want to do is run playwright in the container and ensure it has read & write access to our test code so it can read tests & write back snapshots etc. We would likely still have permissions problems if we had a separate Dockerfile, plus then you'd have to remember to rebuild the Dockerfile each time, which we did previously have a separate Dockerfile and it made running the tests quite annoying.
I think the reason why it worked on WSL is that by default the first user created in WSL is uid 1000, which is the linux default "first user" and so matches the user created in the PW docker container.
The new commands now work on Windows, WSL and a cloud Rocky 8 machine (or at least those are the envs I have tested the new commands against).

@joelvdavies @joshuadkitenge I think I figured out a fix - if I set it so the container runs as the current user then it works on Linux (both Rocky 8 cloud VM and WSL) (we still use pwuser on Windows but that doesn't have permissions issues so it's fine). As I said, I want to avoid creating a custom docker container as all we want to do is run playwright in the container and ensure it has read & write access to our test code so it can read tests & write back snapshots etc. We would likely still have permissions problems if we had a separate Dockerfile, plus then you'd have to remember to rebuild the Dockerfile each time, which we did previously have a separate Dockerfile and it made running the tests quite annoying.
I think the reason why it worked on WSL is that by default the first user created in WSL is uid 1000, which is the linux default "first user" and so matches the user created in the PW docker container.
The new commands now work on Windows, WSL and a cloud Rocky 8 machine (or at least those are the envs I have tested the new commands against).

Yeah, fair enough, I think using docker build in the command before the run could also work but it would take longer to run if there were any image changes and I agree it would also cause a permission issue with the reports as well.
I tested it locally and it worked without any permissions issues 🥳 . Thanks for looking into it. Some of the tests still seem a bit flaky locally but it seems that's just me, the mocked ones are the same and they all pass fine on the CI.


Aqara Wireless Switch found while addind integration but after never shows

Hi
While discovering I see all of my 5 Aqara Wireless Single Switches but when I'm adding they never shows as entities.
lumi.remote.b186acn01
+
lumi.sensor_switch.aq2

Since this component obtains the device state by polling, it cannot monitor the key events of wireless switch in real time, so it is not suitable for such devices.

Thank You for this information.
I would like to ask if polling in quicker intervals will increase battery usage of devices?
I see that default for magnet is 15 sec.
Intervals are located in device_customizes.py - is it safe to modify them or just use customize.yaml?
What is lumi.sensor_wleak time_start_offset?
lumi.gateway.aqhm01 - light is working without any problems but motion is not working (I don't think it's feature of this device).  Anyway, main question about that hub - Is it possible to control Alarm & door bell function?
Sorry for many questions, appreciate this integration!


Error running demo

Hi, just downloaded but having a lot of errors compiling...am I missing something? Please kindly advise..

Hi,
That's normal, I'm in the process of converting the source to swift 3.
I've done a lot of the work during the summer, but with each new Xcode came new changes to be made and I need to finish.
I'll get back to it as soon as I can, but I have a lot of work these days.
Sorry for the inconvenience.


add seqscope

Codecov Report

Merging #35 (dcc27dc) into main (becf7ec) will decrease coverage by 0.17%.
The diff coverage is 92.85%.

@@            Coverage Diff             @@
##             main      #35      +/-   ##
==========================================
- Coverage   85.91%   85.74%   -0.18%
==========================================
  Files          26       26
  Lines        2009     2013       +4
==========================================
  Hits         1726     1726
- Misses        283      287       +4

Impacted Files
Coverage Δ

ngs_tools/chemistry/__init__.py
96.55% <90.90%> (+0.89%)
:arrow_up:

ngs_tools/chemistry/SpatialChemistry.py
95.23% <100.00%> (+0.15%)
:arrow_up:

ngs_tools/utils.py
86.10% <0.00%> (-2.08%)
:arrow_down:

ngs_tools/chemistry/Chemistry.py
83.47% <0.00%> (-0.14%)
:arrow_down:

ngs_tools/logging.py
65.07% <0.00%> (+1.01%)
:arrow_up:

ngs_tools/chemistry/MultimodalChemistry.py
85.71% <0.00%> (+3.57%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Raspberry Pi Zero - ARMv6 image not available

Hi,
thanks for your wonderful product.
I've tried to install Kerberos Agent through docker and everything seems to work until I try to get to the interface. The client (firefox in my case) says it's unable to connect to the server.
I've installed the agent on a raspberry pi Zero with the latest Raspberry Pi OS lite version. I can access the pi through ssh.
the command I entered to launch the service is:
sudo docker run -p 80:80 --name kerberos0 -d kerberos/agent:latest
Maybe I must add that I've encountered this warning, maybe related:
WARNING: The requested image's platform (linux/arm/v7) does not match the detected host platform (linux/arm/v6) and no specific platform was requested
Thanks in advance.

hey @paucazou, thanks! That's a bummer for the moment we do not have a armv6 compatible image. However this is on our roadmap and will be released in the next weeks. For the moment its recommended to run on a Raspberry Pi 2 or higher.

Ok, thanks for your (really quick!) answer. I'll try again then.

no worries and welcome @paucazou, I just renamed the issue to make the issue more obvious

This is now available, we also have static binaries now -> https://github.com/kerberos-io/agent/releases


Referencing documents

Hello, this is more a question than an issue:
what "type" should be set when we want to reference another doc within a Schema?
I've tried:
schema: {
  userId: {
    type: Meteor.Collection.ObjectID
  }
}

But got a failed validation.
Thanks!

For anyone else who lands here it looks like SimpleSchema.RegEx.Id is the way to acomplish this now with stricter validation than just String

if you want to use Mongo.Collection.ObjectID then you always need to specify blackbox: true
    _id: {         type: Mongo.Collection.ObjectID,         blackbox: true     },


Add Common Params Max Threads to GetIsolatedMassesAndCharges for Deconvolution

#1290

#1290

Overload method with parameter for max threads after mzLib changes are finished


Update winit_test and re-enable tests/present_and_fetch

Looks like the test needs to be updated for WASM. The SIGSEGV on macOS is more concerning though.

Hmm, yeah, that is troubling, I'm looking into it.

Oh, I thought I had migrated softbuffer to use objc2 already, it would've prevented this issue...
The issue is fairly simple once you see it, both CALayer and the window reference are not retained (in part due to https://github.com/servo/core-foundation-rs/issues/643), so I think the window ends up being double-freed (or free'd before the CALayer has a chance to release it's own reference to it).

This is unfortunately not going to work on Wasm, because Window::inner_size() will always return None on Window creation. You have to wait for a Resized event for that to work properly.
I guess this is an issue in winit-test, see https://github.com/notgull/winit-test/issues/11.

The test was removed as part of #214, so I'll close this PR. We will revisit this in the future.


[multiplexer] option to skip post/put requests

Add an option to skip post/put requests. Since currently pparam's are all assumed to be multiplexed destination remaps, add regex to distinguish those from feature flag per-remap. Please review!

[approve ci]

can we update the doc here as well ?
https://github.com/apache/trafficserver/blob/master/doc/admin-guide/plugins/multiplexer.en.rst
And please run clang_format as well.

[approve ci]

[approve ci docs]

[approve ci]
[approve ci docs]

[approve ci freebsd]

sorry the overall diff may be hard to read, this shows the last commit better
https://github.com/apache/trafficserver/pull/7233/commits/2d7e18e435b7d8ff5004a40056f62cbcda7e30f7
basically this is to reorder the code blocks in DoRemap() so that if we only do generateRequests() + requests assert + field creation if we determine we don't need to skip, per @shukitchan

@shukitchan please review again

[approve ci]

there are some compilation issues. please check.

[approve ci]

[approve ci docs]


Investigate pytest.CaptureFixture usage problem

Our test/test_execution.py::test_outputs_none_quiet uses the pytest capture fixture to capture the logs to stderr. This works just fine as long is it is the only usage.
I added a second (identical) test, which fails
>       assert "Summary" in caplog.text
E       AssertionError: assert 'Summary' in ''
E        +  where '' = <_pytest.logging.LogCaptureFixture object at 0x7f577401bbd0>.text

So it looks like this fixture isn't being properly reset between tests.
For https://github.com/con/duct/pull/159, it turned out to be better just to add a 3rd execution to the same test.
Additionally, this test should be very quick, but it still takes over 2 seconds to run. We should check out this fixture and make sure we are using it correctly. @yarikoptic wdyt?

would caplog.clear() help?
as for slow -- are you sure it is not 2 sec of duct's execute?  I would expect fixture to be quick.

caplog.clear() doesnt help, but you're correct about the speed. that one is running the test script with duration 1 twice. 2 seconds makes perfect sense

I'm going to close-- if we need to use this more than once, the issue will make itself known.


FakeTokyo properties does not match coupling map

Information

Qiskit Terra version: master
Python version:
Operating system:

What is the current behavior?
The properties for FakeTokyo does not match the coupling map; there are 2Q gates in the properties that are not in the coupling_map, e.,g.
[1, 7]
[17, 18]
[18, 17]

I believe some valid ones are also missing.
This is blocking #5105.
Steps to reproduce the problem
What is the expected behavior?
Suggested solutions

Looking at the git log for the snapshot of the properties: https://github.com/Qiskit/qiskit-terra/commits/master/qiskit/test/mock/backends/tokyo/props_tokyo.json it hasn't been updated in a while. I assume this is because the device isn't online anymore. We've periodically run updates of the snapshots to get new parameters and updated data (for example: https://github.com/Qiskit/qiskit-terra/pull/4567 ) but tokyo doesn't get updated because there is nothing in the backends list for it anymore (or at least for the provider I typically use for updating things).
I think we can fix this a couple of ways, either hand edit the properties, delete the properties for tokyo, or if someone has access to the last properties payload for the device before it was retired we can use that.


issues with automatic version number

It seems, if the package setup.py is not in the git repository root directory, the generated version string is different than in the root dir:
root dir:
python setup.py --version
0.0.post0.dev1+11079f0
subfolder:
python setup.py --version
0.0.1.dev1

This is kind of unintended usage. Did everything else work? Can you explain what you exactly did?
Somehow setuptools_scm switches back to the default versioning.

Mmmh, I feared an answer like this, but in my experience we cannot come around accepting, that the pressure to use pyscaffold is sometimes smaller than the pressure to not have setup.py in the root of a repository. Often for example there are many packages in one repository, because they should have a common version (same version control)...then it makes sense to have them both in subfolders and both have a separate pyscaffold...
As far as I can see, everything except for the versioning is working...of course in order to be really usefull and intended in this scenario, one should be able to tell pyscaffold not to create a repo...

Ok, it should be no problem to let PyScaffold only create a repo if the current directory is not already a git repo. The problem is the strange versioning... do you want to look into it? My guess is it is setuptools_scm related. With a debugger it should be no problem to find the cause. I am on holidays right now and cant do it.

Ok, I can have a look...

I analyzed the issue with the versioning and found the reason. Setuptools has a configuration parameter "root" which defaults to ".".
We can quite easily fix this issue by setting the correct root dir. The root folder can be identified with the following:
 repo_dir = subprocess.Popen(['git', 'rev-parse', '--show-toplevel'], stdout=subprocess.PIPE).communicate()[0].rstrip().decode('utf-8')

Thanks, that was fast. Is this a parameter of setuptools or setuptools_scm? The latter I guess. I'll think with a few changes in integration.py we can resolve this issue. I'll look into it after my holidays.

Thanks to @treebee this is fixed in release v2.4.3!


Unable to find local standard when in dependencies and not devDependencies

StandardJS version? 1.13.0
VSCode version? 1.30.2
StandardJS configuration? Use local package.json
What do you have in the OUTPUT panel?

[Info  - 11:45:24] JavaScript Standard Style server is running.
[Info  - 11:45:24] no standard in package.json
[Info  - 11:45:24] no standard in package.json
[Info  - 11:45:24] JavaScript Standard Style library loaded from: {path_removed}/node_modules/standard/index.js

When standard is installed as a regular dependency rather than a dev dependency it is not found correctly.

standard should not be installed in dependencies, could you tell me your use-case ? @rstrand
I don't think it is necessary to also check if standard is in dependencies, it should be always in devDependencies.


DBCP-566: clearStatementPoolOnReturn

https://issues.apache.org/jira/browse/DBCP-566

Can you please make one more review?


chore: release main

:robot: I have created a release beep boop
@markdown-confluence/cli: 5.4.0
5.4.0 (2023-05-12)
Features

Handle 404 when pageId included in YAML. Set to not publish and remove bad pageId (33dde01)

Dependencies

The following workspace dependencies were updated

devDependencies

@markdown-confluence/lib bumped from 5.3.0 to 5.4.0
@markdown-confluence/mermaid-puppeteer-renderer bumped from 5.3.0 to 5.4.0

@markdown-confluence/lib: 5.4.0
5.4.0 (2023-05-12)
Features

Handle 404 when pageId included in YAML. Set to not publish and remove bad pageId (33dde01)

@markdown-confluence/mermaid-electron-renderer: 5.4.0
5.4.0 (2023-05-12)
Miscellaneous Chores

@markdown-confluence/mermaid-electron-renderer: Synchronize obsidian packages versions

Dependencies

The following workspace dependencies were updated

dependencies

@markdown-confluence/lib bumped from 5.3.0 to 5.4.0

@markdown-confluence/mermaid-puppeteer-renderer: 5.4.0
5.4.0 (2023-05-12)
Miscellaneous Chores

@markdown-confluence/mermaid-puppeteer-renderer: Synchronize obsidian packages versions

Dependencies

The following workspace dependencies were updated

dependencies

@markdown-confluence/lib bumped from 5.3.0 to 5.4.0

obsidian-confluence: 5.4.0
5.4.0 (2023-05-12)
Features

Handle 404 when pageId included in YAML. Set to not publish and remove bad pageId (33dde01)

Dependencies

The following workspace dependencies were updated

dependencies

@markdown-confluence/lib bumped from 5.3.0 to 5.4.0
@markdown-confluence/mermaid-electron-renderer bumped from 5.3.0 to 5.4.0

obsidian-confluence-root: 5.4.0
5.4.0 (2023-05-12)
Features

Handle 404 when pageId included in YAML. Set to not publish and remove bad pageId (33dde01)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/markdown-confluence/markdown-confluence/releases/tag/obsidian-confluence-v5.4.0 :sunflower:

:robot: Release is at https://github.com/markdown-confluence/markdown-confluence/releases/tag/%40markdown-confluence/lib-v5.4.0 :sunflower:

:robot: Release is at https://github.com/markdown-confluence/markdown-confluence/releases/tag/%40markdown-confluence/mermaid-electron-renderer-v5.4.0 :sunflower:

:robot: Release is at https://github.com/markdown-confluence/markdown-confluence/releases/tag/%40markdown-confluence/cli-v5.4.0 :sunflower:

:robot: Release is at https://github.com/markdown-confluence/markdown-confluence/releases/tag/%40markdown-confluence/mermaid-puppeteer-renderer-v5.4.0 :sunflower:

:robot: Release is at https://github.com/markdown-confluence/markdown-confluence/releases/tag/obsidian-confluence-root-v5.4.0 :sunflower: