Limit the preloaded images.

Am using Owl Carousel to make a slide image. Need only to display 4 images. And need to achieve  lazy load for images.
Have tried to use your plug-in, it works such as loading the first 3 images on the first time and on slide it loads the 4th image.
My requirement is to load first 2 images on first time and on slide to load the consecutive images.
Like when I view the first slide image the second slide image should be pre loaded. And when I go to second slide the third image should be loaded as well.
Is there any way to achieve this.

Yes, this is basically possible. But lazysizes is actually quite good in distinguishing preload time and crucial loading time.
In case your owl carousel is above the fold and you load it you will likley experience the following:
lazysizes first only loads the first image and then loads the other two images. This means although lazysizes loads a little bit more than you want, the crucial thing(s) have a higher priority in download. This was an important part in designing lazysizes. And for me it was also important, that near the view images are always preloaded.
I really would suggest that you live with this. I don't think it is bad behavior.
If you want to change this, here is how you can do so:
//the configuration should be done before lazysizes and immediately (not inside a domready wrapper):
window.lazySizesConfig = window.lazySizesConfig || {};

window.lazySizesConfig.expand = 225;
window.lazySizesConfig.expFactor = 1.4;

In case your owl carousel does not span the hole viewport width, you might also add the attribute data-expand="auto" to all lazyload elements inside of your carousel.
The data-expand attribute is normally used for something else (I.e.: To override the JS config for expand and expFactor). But in case it is not a number it still uses the JS configuration, but forces lazysizes to always check for nesting visibility. (This also adds some CPU performance penalty.)

Thank you @aFarkas  Will look on it. And thanks lot for your suggestion.

@gladsonrobinson
I have added a new option (hFac). Which allows you to modify the horizontal expand without changing the vertical expand.
With this you can do this:
//the configuration should be done before lazysizes and immediately (not inside a domready wrapper):
window.lazySizesConfig = window.lazySizesConfig || {};

window.lazySizesConfig.hFac = 0.4;

As I said, this won't give you full control (unless you use the data-expand attribute), but should come closer to your needs without sacrificing the normal preload.
This option is currently only available in the master branch.

Speaking of carousels, I'm using Vue-Carousel and for the life of me, I can't get lazysizes to not load the first 2 large images at the same time.  I've tried this for giggles:
window.lazySizesConfig = window.lazySizesConfig || {};
window.lazySizesConfig.loadMode = 0
window.lazySizesConfig.expand = 0
window.lazySizesConfig.expFactor = 0
window.lazySizesConfig.hFac = 0
and it looks like these settings are taking effect because things don't really load until the second I see them (which I know isn't ideal, but great for testing configs) ..No matter what, even when I have 2 images with 100px margin between them, they still load at the same time (2 out of 12).
I'd really like the 1st large image to load, and then wait until prloadAfterLoad time to fetch the rest.


Don't do ajax reload at stratup if records are provided

Currently, w2grid always reloads records at render time if url property is provided. For me, this is undesirable since splitting loading of grid to two http requests generates overhead (backend framework needs to load twice) and slows down considerably, but I still need later sorting and stuff through AJAX. My suggestion therefore is to not reload grid by AJAX at init time if both "url" and "records" are provided.

I found this can be achieved like this:
$('#grid').w2grid({
		name: 'grid',
		columns: some_columns,
        records: some_records,
        onRefresh: function(bla) {
            this.url = some_url;
        }
});

I still think this should be default behaviour, though

Thanks for your suggestion. The easiest way is to not set url property when creating a grid. URL property can be set at any time after that and calling .reload() will trigger pull from the server.
You can do this
$('#grid').w2grid(...)
grid.url = 'some_url'
grid.reload()

If url property is set, it does not matter if you set .records property, it will still going pull it from server.
On the other hand, the grid should pull records only one time when it is rendered (refresh does not pull records). If there is second request, I will track it down and fix. However, it is possible, you render grid twice.


feat: add samlify example

hmm I started with the blues stack and added a few files.  Should I start with a different one, or did I change it too much? Thanks!

@christopherpickering Best is to start with the __template folder of this repo as a basis and add only the bare minimum to get your example working

@MichaelDeBoey how's it looking now? You can squash when you merge?
Thanks!

Cool, I'll rename. Yeah, the submodule is used for the dev to show the example SAML login.

Sorry that was a messy name change, but should be good now.

Thanks, I removed the submodule (now cloning the idp instead) and updated the lint.

@MichaelDeBoey thank bro, wish I coulda been a programmer like you 😀 unfortunately, some of us never get out of kindergarten

shucks didn't mean to close it.

unfortunately, some of us never get out of kindergarten

@christopherpickering No need to make these kind of comments imo
I'm just trying to make sure your code adheres to the standards we use in our code/this repo, that's all 🤷♂
So if you feel offended by them: I'm sorry, 'cause that's not what I'm trying to do at all.

unfortunately, some of us never get out of kindergarten

@christopherpickering No need to make these kind of comments imo I'm just trying to make sure your code adheres to the standards we use in our code/this repo, that's all 🤷♂
So if you feel offended by them: I'm sorry, 'cause that's not what I'm trying to do at all.

😁 I'm not offended, just jealous that I didn't see all that stuff you recommended when I went through it :) Wishing you could review all my code!

I'm not offended

Oh OK, then I misunderstood your comment 🙈

@MichaelDeBoey thanks, is there another linter you run to find more ways to improve the code, or have a better set of es rules than the default? Or have a style guide I can check out? I'm wondering how I can improve my code from the beginning. Thanks!

@MichaelDeBoey I think I've gotten everything taken care of 👍🏽

Hi @christopherpickering!
Are you still interested in getting this one merged?
If so, please rebase onto latest main & implement remarks

@MichaelDeBoey I ended up writing an auth strategy for remix-auth. This pr can probably be closed unless you would like it added.


Upgrade to Spring Boot 1.5.10

Upgrade the Spring Boot dependency to version 1.5.10.

Code complete.


Manifest Versioning Build Tasks (netframework version)

Azure DevOps Extensions
Manifest Versioning
Platform
Azure DevOps Services
Azure DevOps Server (TFS) Version
No response
Extension Version
No response
Describe the bug
.Net Framework version doesn't work. the version is not updated as I expect. it is still the one defined in AssemblyInfo.cs
name: '1.$(date:yyyy).$(DayOfYear)$(rev:.r)'

task: VersionAssemblies@3
inputs:
Path: '$(Build.SourcesDirectory)'
VersionNumber: '$(Build.BuildNumber)'
InjectVersion: true
VersionRegex: '\d+.\d+.\d+.\d+'
FilenamePattern: 'AssemblyInfo.*'
Field: 'AssemblyVersion'
OutputVersion: 'OutputedVersion'

Repo Steps

Go to '...'
Click on '....'
Scroll down to '....'
See error
...

Expected Behavior
No response
Logging Information
No response

Can you run the pipeline with diagnostics on (check the box when queuing the run or set a variable system.debug=true) and upload the log here so I can see what is happening
The detailed logs usually shows what the issue is (commonly one of search paths being wrong).
Also can I check the version of .NET framework you are targeting, this task is for .NET 4.8 and older, you need to use the >NET Core one for newer versions

I have two projects in one solution, the second one is a lib project.
looks like you have update them,
##[debug]VstsTaskSdk 0.10.0 commit 787a46ec0a2df5b4d12c2e801bd3f319975c054c
##[debug]INPUT_PATH: 'D:\a\1\s'
##[debug]INPUT_VERSIONNUMBER: '1.2023.151.4'
##[debug]INPUT_INJECTVERSION: 'true'
##[debug]INPUT_VERSIONREGEX: '\d+.\d+.\d+.\d+'
##[debug]INPUT_OUTPUTVERSION: 'OutputedVersion'
##[debug]INPUT_FIELD: 'AssemblyVersion'
##[debug]INPUT_FILENAMEPATTERN: 'AssemblyInfo.'
##[debug]Source Directory: D:\a\1\s
##[debug]Filename Pattern: AssemblyInfo.
##[debug]Version Number/Build Number: 1.2023.151.4
##[debug]Version Filter to extract build number: \d+.\d+.\d+.\d+
##[debug]Field to update (all if empty): AssemblyVersion
##[debug]Inject Version: true
##[debug]Output: Version Number Parameter Name: OutputedVersion
##[debug]Using the version number directly
##[debug]Extracted Version: 1.2023.151.4
##[debug]Will apply 1.2023.151.4 to 2 files.
##[debug]Updating only the 'AssemblyVersion' version
##[debug]D:\a\1\s\www\Properties\AssemblyInfo.cs - version applied
##[debug]Updating only the 'AssemblyVersion' version
##[debug]D:\a\1\s_source\dotnet_******************_\Properties\AssemblyInfo.cs - version applied
##[debug]Set the output variable 'OutputedVersion' with the value 1.2023.151.4
##[debug]Processed: ##vso[task.setvariable variable=OutputedVersion;]1.2023.151.4
but my debug is still not what I expected in the debug("version": "1.0.8551.24590",)
System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.ToString()

Looks it is finding your assembly.cs files and updating the expect fields, so are running this versioning task BEFORE you run the compile the project?
Most of the tasks in the extension, including both the .NET versioning tasks, updates the source file, so should be run prior to the compile.
The exceptions are the DACPAC version which has to be done after the compile and the the XML/JSON ones that are not compiled

Yes, before build

task: VersionAssemblies@3
inputs:
Path: '$(Build.SourcesDirectory)'
VersionNumber: '$(Build.BuildNumber)'
InjectVersion: true
VersionRegex: '\d+.\d+.\d+.\d+'
FilenamePattern: 'AssemblyInfo.*'
Field: 'AssemblyVersion'
OutputVersion: 'OutputedVersion'

script: echo '$(Build.BuildNumber)'

script: echo '$(OutputedVersion)'

task: VSBuild@1
inputs:
solution: '$(solution)'

I did a dirty publish.
I can see assemblyinfo.cs of the second project (lib) has been updated correctly.
// [assembly: AssemblyVersion("1.0.")]
[assembly: AssemblyVersion("1.2023.151.12")]
##[debug]D:\a\1\s_source\dotnet_*****************_\Properties\AssemblyInfo.cs - version applied
and from Metadata of dll, I can see it is correct.
but the main project (below) was not updated.
still old one: [assembly: AssemblyVersion("1.0.*")]
##[debug]D:\a\1\s\www\Properties\AssemblyInfo.cs - version applied  (seems wrong here)

So, if I understand you correctly,..

D:\a\1\s\www\Properties\AssemblyInfo.cs has not been updated, even though the version task log says it has been updated.

Is there anything in your build that could cause the file D:\a\1\s\www\Properties\AssemblyInfo.cs to be reverted as part of the pipeline prior to building the www project?
Or any way the www.dll could have been cached and not rebuilt?

I  "cat the two assemblyinfo.cs" out after VersionAssemblies task.
one changed:
// You can specify all the values or you can default the Build and Revision Numbers
// by using the '' as shown below:
// [assembly: AssemblyVersion("1.0.")]
[assembly: AssemblyVersion("1.2023.151.16")]
[assembly: AssemblyFileVersion("<IP_ADDRESS>")]
one doesn't change:
// by using the '' as shown below:
[assembly: AssemblyVersion("1.0.")]

I have simplified pipeline, nothing should be in except VersionAssemblies task

stage: build
jobs:

job:
steps:
- task: NodeTool@0
inputs:
versionSpec: '14.x'
- task: Npm@1
inputs:
command: 'install'
workingDir: 'www'
- task: gulp@0
inputs:
gulpFile: 'www/gulpfile.js'
targets: 'sass-compile'
gulpjs: 'node_modules/gulp/bin/gulp.js'
enableCodeCoverage: false
- task: NuGetToolInstaller@1
- task: NuGetCommand@2
inputs:
command: 'restore'
restoreSolution: '$(solution)'
vstsFeed: '9c01d89b-0458-41c5-bdb0-4d18902c2f0e/1f26eb19-a087-4efa-8cf9-30c13bc23954'

task: VersionAssemblies@3
inputs:
Path: '$(Build.SourcesDirectory)'
VersionNumber: '$(Build.BuildNumber)'
InjectVersion: true
VersionRegex: '\d+.\d+.\d+.\d+'
FilenamePattern: 'AssemblyInfo.*'
Field: 'AssemblyVersion'
OutputVersion: 'OutputedVersion'

script: echo '$(Build.BuildNumber)'

script: echo '$(OutputedVersion)'

script: cat '$(Build.SourcesDirectory)_source\dotnet****************\Properties\AssemblyInfo.cs'

script: cat '$(Build.SourcesDirectory)\www\Properties\AssemblyInfo.cs'

one changed:
// You can specify all the values or you can default the Build and Revision Numbers
// by using the '' as shown below:
// [assembly: AssemblyVersion("1.0.")]
[assembly: AssemblyVersion("1.2023.151.16")]
[assembly: AssemblyFileVersion("<IP_ADDRESS>")]
one doesn't change:
// by using the '' as shown below:
[assembly: AssemblyVersion("1.0.")]

And yes, your understanding is correct.
D:\a\1\s\www\Properties\AssemblyInfo.cs has not been updated, even though the version task log says it has been updated.

Ok, I need to try to replicate this, what Visual Studio template type is the WWW based on ?

yes, it should be asp.net MVC

I have build a worked example of my understanding of your usage. It is in a public Azure DevOps project so you can see the code and pipeline.
I have checked it is updating the assemblyinfo.cs files and that the resultant DLLs have the expected versions.
As I cannot reproduce your issue, can you see how this working example differs from your code?

Thank you very much for your efforts.

Did you get anywhere with your pipeline?

I tried another task for "assemblyinfo". And it worked for me. I might try your .net core one when it is time. Thank you for your help.

seems another task is working for one of my solution. but failed on another solution by not changing the version. interesting. I will try to see if I can find the reason.

Yes, that makes sense as the parameter you are passing into the task to detect the version is VersionRegex: '\d+.\d+.\d+.\d+'
Your solution is one fix, the other is to alter the regex filter to match your needs
Glad you are sorted


[FLINK-20680][table-common] Fails to call var-arg function with no parameters

What is the purpose of the change
Fix the issue to call a var-arg function with no parameters.
Brief change log

Fix the validation logic in ExtractionUtils::isInvokable
Add a hive test

Verifying this change
New test case
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): no
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn/Mesos, ZooKeeper: no
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? no
If yes, how is the feature documented? NA

@twalthr Thank you for review and merge the code !

@twalthr Thank you for review and merge the code !


Nested filter on related model not working

(Prisma2/nexus)
I am using the following (simplified) model:
model Staff {
  id         String       @default(cuid()) @id @unique
  user       User?
  active     Boolean?
}
model User {
  id         String        @default(cuid()) @id @unique
  email      String        @unique
  staff      Staff?
}

Using photon, the following query works:
  const staff = await photon.users.findMany({
    where: {
      staff: { active: true },
    },
  });

However, the following graphql query, exposed through nexus-prisma, fails:
query {
  findManyUser(
    where: { staff: { active: true } }
  ) {
    id
    email
  }
}

with the error message:
Field "active" is not defined by type QueryFindManyUserWhereInput.

The nexus-prisma type generation seems to be incorrect, active should not be of type QueryFindManyUserWhereInput, I think.

@jasonkuhrt this is also quite an important bug to fix for nexus-prisma to work with prisma2.
It's currently impossible to filter on related fields in nexus-prisma, but I think this is needed for many GraphQL queries. The actual photon query works, but nexus-prisma does not generate the correct types.
If you want to give me some pointers where to start looking in the nexus-prisma code, I can also try to investigate myself.

@iherger would love to. In a few weeks/months from September onward (when I start full time) I could. But not yet 😅.
But rest assured this is high priority.

@iherger if you can put up a repro repo, that would help 🙏

Thanks, @jasonkuhrt .
Here is a repro repo: https://github.com/iherger/nexus-prisma-nestedfilter
After installing, run
yarn seed
yarn test

This should show that the following photon query works without problems:
  const users = await photon.users.findMany({
    where: { staff: { active: { equals: true } } }
  });

Now, when you start the server (yarn start), and run the following query:
{
  findManyUser (where: {staff: {active: {equals: true}}}) {
    email
  }
}

it fails with the error message `Field "active" is not defined by type QueryFindManyUserWhereInput.
I now realise that this is probably not such a common use-case (filtering on 1-1 relations), but it's still a bug...
The much more common use-case is #354, which deservers attention first.

Thanks so much. Yeah working on a fix for that one.

but not for the fields of input types makes the input type's names less predictable.

On the other hand, [...] will create a lot more clutter/confusion in the final schema

Cannot say with high confidence but I would aim for less cluttered schema right now. Wouldn't be surprised if this were not the optimal choice though. In fact it may depend on app case-by-case, the schema patterns in use, etc. I'm weary to over-design before getting more feedback and real-world examples.

find another approach to solve the problem

I think we can close this issue with the PostWhereInput solution you've identified. However I have more thoughts, very likely falling out of scope and into a potential future feature.
You mention:

As a side-effect of the filtering and ordering arguments customization [...] nexus-prisma needs to come up with inputs names scoped to their parent type + field name

Because we can only customize on one level of depth, the type of the field QueryUsersWhereInput.post won't ever be customized anyway

Users can customize top-level Input Object. However they might now. When they do not, qualification (namespacing) is not needed.
Users cannot customize nested Input Objects. But maybe one day they can. At that time we would need to revisit qualification namspacing.
My point is, we don't need a static decision here. We can dedupe and namespace in accordance with what is actually going on in the user's codebase. Furthermore, we can expose config tuning for these mechanisms, not unlike the ideas in #169
So, I guess what I'm trying to say is, the decision between:

but not for the fields of input types makes the input type's names less predictable.
...
On the other hand, [...] will create a lot more clutter/confusion in the final schema

is not so significant, as I think we achieve:

find another approach to solve the problem.

But later.
Make sense?

Users cannot customize nested Input Objects. But maybe one day they can. At that time we would need to revisit qualification namespacing.

We originally went with the current solution (everything aliased) for consistency/predictability with namings and in anticipation that we might indeed allow one day for nested input object types customization, in which case changing the naming strategy would result in a breaking change.
Now that I realize how much clutter it’d create if it was properly implemented, I tend to agree with your solution (aliasing only if an input type is customized), in combination with the idea of dedupe vs qualification config tuning
Side note: It'll, however, make #396 partially impossible, as we won't be able to pre-alias all input types because it'll depend on the users' input. It'll still be possible for field names though

aliasing only if an input type is customized

I could see this leading to more churn in the GQL schema. Two ways I see giving users control over this:

Config tuning (always qualify)
Composable InputObject types API

import { WhereInput } from '@generated/nexus-prisma'

export default objectType({
  name: 'User',
  args: {
    // New DSL features here
    name: WhereInput({ name: 'MyWhatever', ... })
  },
  definition(t){
    t.model.name()
  }
})


cmsGetPostScriptCSA returns decimals formatted according to locale which breaks PS parsing

If i'm using a program in Catalan (or any other locale that uses , as decimal separator instead of . like german) calling cmsGetPostScriptCSA gives me stuff like
/BlackPoint [0,000000 0,000000 0,000000]
/WhitePoint [0,964200 1,000000 0,824900]
which is wrong and will make the PS parser unhappy
This is because %f in vsnprintf obeys locale rules as it thinks it's talking to a human instead of to a machine.
As far as i know there's no way to tell printf to do what we want here other than do stuff like
char *old = setlocale(LC_NUMERIC, "C");
printf stuff;
setlocale(LC_NUMERIC, old);
looking at the code i think it could work since everything seems to call _cmsIOPrintf which seems likes it's used from cmsps2.c which would imply it's always "talking PS" and never "talking to the user"
Want me to propose a merge request to do that?

actually setlocale is not that awesome since it changes the locale of the whole app that may not be what other threads want.
If you can depend on posix existing, there's uselocale that is per thread. If you need windows support, i'd suggest just rolling out your own double formatting code like we have in poppler (you can have a look if it's ok for your code to be GPL2+GPL3)

setlocale is not thread safe and can be very harmful. I will document the behaviour of cmsGetPostScriptCSA and let the end use to decide when revert to default "C" locale before calling postscript generation. Anything other than that would introduce data races. Writing another printf is not an option for a small lib like this one.

This is a very sad decision.
You're basically making cmsGetPostScriptCSA unusable, because what is the called of cmsGetPostScriptCSA supposed to do?
You can actually fix it properly by having your own double formatting code, the caller of cmsGetPostScriptCSA can't.

How do you feel about this? (needs applying to more places)
It's a bit lame but should fix the problems and not be super CPU-time consuming
diff --git a/src/cmsps2.c b/src/cmsps2.c
index d101e8d..511ff24 100644
--- a/src/cmsps2.c
+++ b/src/cmsps2.c
@@ -358,6 +358,22 @@ void EmitHeader(cmsIOHANDLER* m, const char* Title, cmsHPROFILE hProfile)

 }

+static
+char *format_doubles_ensure_dots(const char *fmt, ...)
+{
+    va_list argList, argList2;
+    va_start(argList, fmt);
+    va_copy(argList2, argList);
+    size_t needed = vsnprintf(NULL, 0, fmt, argList) + 1;
+    char  *buffer = malloc(needed);
+    vsprintf(buffer, fmt, argList2);
+    for (int i = 0; i < needed; ++i) {
+        if (buffer[i] == ',') buffer[i] = '.';
+    }
+    va_end(argList2);
+    va_end(argList);
+    return buffer;
+}

 // Emits White & Black point. White point is always D50, Black point is the device
 // Black point adapted to D50.
@@ -365,14 +381,15 @@ void EmitHeader(cmsIOHANDLER* m, const char* Title, cmsHPROFILE hProfile)
 static
 void EmitWhiteBlackD50(cmsIOHANDLER* m, cmsCIEXYZ* BlackPoint)
 {
+    char *blackPoint = format_doubles_ensure_dots("%f %f %f", BlackPoint -> X, BlackPoint -> Y, BlackPoint -> Z);

-    _cmsIOPrintf(m, "/BlackPoint [%f %f %f]\n", BlackPoint -> X,
-                                          BlackPoint -> Y,
-                                          BlackPoint -> Z);
+    _cmsIOPrintf(m, "/BlackPoint [%s]\n", blackPoint);

     _cmsIOPrintf(m, "/WhitePoint [%f %f %f]\n", cmsD50_XYZ()->X,
                                           cmsD50_XYZ()->Y,
                                           cmsD50_XYZ()->Z);
+
+    free(blackPoint);
 }

That could work.
I have some (bad) exprerience on setlocale. To me, anything but the "C" default is basically broken. Code that otherwise would  nicely be portable gets more and more complexity and issues and all is caused by setlocale. Embedded doesn't work or just crashes on  some combinations. On the other hand, sprintf does nice things on float point precission, some of those are not easely portable, so sprintf is a great helper. Your solution may seem a little bit hackish, but I like it. Does its job, solves the issue nicely and  without side effects, so thank you so much, i will integrate  this code in a day or two.
Regards
M.

fixed by bde08cc2a8972f17cf1f00082e413e0934625afd

Are you 100% sure that things that end up in _cmsIOPrintf can't have commas?
There seem to be some stuff that is %s, i.e. normal text, we wouldn't want to fix decimals and then break something else that actually expected to have a , in there ^_^

And i just saw the comment saying "no commas are needed", so i guess you checked :)
Thanks, i guess i can apply a similar temporary fix in poppler


Test the full flow of CI

Context
Now in this repository we have multiples projects samples of diverse stacks, today the test we do is to run Pipelinit on these repositories and check if a determined output is generated, but with at least one project for each stack it is now just a technical task to test them directly on the CI platforms we support.
Goal

Create a project
Get one of the test repositories inside the Pipelinit CLI
Runs the latest version of Pipelinit
Upload the project on a platform with the generated files
Checks the result of the execution of CI jobs

Implementation
At first, we can use the projects we already use as test and run the CI on the platforms accordingly

[X] GitHub
[ ] GitLab

For GitHub Actions, we already have some parts implemented  that uses the octokit client to commit inside and project and Open a Pull request:

https://github.com/pipelinit/landing-page/blob/main/netlify/functions/github-commit-pr.ts

On Gitlab it is possible to compact our projects to upload them easily

https://docs.gitlab.com/ee/api/project_import_export.html
And there are instructions on the API on how to open a PR and create a commit
https://docs.gitlab.com/ee/api/commits.html#create-a-commit-with-multiple-files-and-actions
https://docs.gitlab.com/ee/api/merge_requests.html#create-mr

The GitHub full test can be made with https://github.com/pipelinit/github-pipeline-tester

Running as expected
Well done @marianesoares @lilianeconstantino!


"Shipped" components are not behaving as expected. When we import the components inside a components library and then export the component library to import in another environment the AutoWidthLabel and Elevation are missing from the library components.

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.

duplicate


Text2text task link redirects to text2text

I don't know if it should be hub that I'm opening the issue here, but basically we have only one task for both text generation and text2text generation (because they're pretty much the same) but the widget link redirects to non-existent text2text  task page. (You can see below) (The task name is "Text Generation" and it covers text2text as well)
@osanseviero @beurkinger

a

Good point, I think I implemented this link a bit too hastily.
Before doing anything I need to know:

what are the tasks share the same task page ?
what are the tasks that don't have a task page ?

@merveenoyan @osanseviero

@beurkinger it's only this one, that "Text Generation" task page is shared by Text-Generation and Text-2-text generation.
I tested the rest and there's no problem.

Hmmm this will need new code logic both on the hf_hub and moon-landing side I think 🤔


Response of sendTextMessage

Hey Folks,
i'm trying to send a textmessage via javascript for days now and i have no idea why it's not working.
I'm getting 3 answers for 1 request (The Procedure is the same as the python code). Does anybody has an idea?

Hello @dwndmr do you find the solution for sending text message?


Fix Wallaby.start_session_opts type spec - passing :driver doesn't do anyting

See https://github.com/keathley/wallaby/blob/master/lib/wallaby.ex#L80
While I agree that the :driver option could be useful, currently it's not implemented.

There's a conflict, I'll rebase

@mhanberg Nice find, done!


When parts of the program are changed in a hot reload, but not executed during the reassemble, warn that a restart may be needed.

(Do not merge: requires a Dart roll that has not yet landed.)
For example, if one reloads with no change, the message is unchanged:
Performing hot reload...
Reloaded 0 of 524 libraries in 899ms.

A change in a build method for a widget currently in use, or a const field or helper function used by such a build method, also results in no extra message.
If one reloads with a change to main, the message now warns that main hasn't executed:
Performing hot reload...
Reloaded 1 of 524 libraries in 1,951ms.

The following program elements were changed by the reload, but did not run when the view was reassembled. If this code only runs at start-up, you will need to restart ("R") for the changes to have an effect.
 - main (lib/main.dart:12)

A similar message will appear for changes to the build method of some widget that isn't currently in use, or a change to code that only runs in response to user input like a touch event.

This is fantastic.
 modulo some nits

This broke the build. reloadSources now comes back with JSON-RPC error 110: https://flutter-dashboard.appspot.com/api/get-log?ownerKey=ahNzfmZsdXR0ZXItZGFzaGJvYXJkclgLEglDaGVja2xpc3QiOGZsdXR0ZXIvZmx1dHRlci85MDAyODgxM2E4OWEzZGU4MTU0MTQ0ZTZlMGYxZWRiZTkwZGMyZTRmDAsSBFRhc2sYgICAgIDkyQgM


babe: fix report_equivocation weight

This wasn't using the correct formula as extracted from the benchmarks model (was missing the components that scale with the number of validators).

should be good to go, aside from that likely correction.

We are done with our review for this PR - please refer to issues #1, #2, #3 and #4 in the internal tracker.


Unit Test discovery executes code found in any __init__.py file, causing odd effects.

Type: Bug

Create a folder, with a __init__.py file in it
Write print('Hello world') in the __init__.py file
Save (CTRL + S)
Watch Python Test Log output print Hello world

With a simple print, this is not an issue, but statements that create instances to be used globally, can very quickly cascade. In my case, I am using logging in another class, which I am creating an instance of to be used globally, causing Unit Test Discovery to constantly create a new log file, and logging to it.
 This is done automatically by unittest. If you run unittest from the command line you should see the same behavior and therefore has to do with unittest and not something the extension is doing. Thanks!

Running unittest manually through the command line, even with discovery, does not do this. I've never had this issue up until a couple of weeks ago, and had used unittesting way before this started occurring.
Can the automatic unit test discovery that the extension keeps running on every file save be disabled, and if so, how? I really do not see the point of test discovery having to execute every single __init__.py file in my project, creating or overwriting multiple files across it, just to search for unittests. I could understand if I was trying to run the tests, but this happens every single time I hit "save changes", in any file, in the project.

Hi- you can do the following to stop it running every time a file is saved: "python.testing.autoTestDiscoverOnSaveEnabled": false. Hopefully this will help too!


Gcp key detector

Please check if the PR fulfills these requirements

[X] Tests for the changes have been added

[X] Docs have been added / updated

[ ] All CI checks are green

What kind of change does this PR introduce?
This changes adds to detect-secrets a new plugin to find Google Cloud API keys and oauth2 client ids.

What is the current behavior?
When detect secrets finds a GCP API key in code, it shows the key as 64base key and as GCP Keys.
With oauth2 cgp client-id the detect-secrets does not find it as secrets.

What is the new behavior (if this is a feature change)?
With the currently changes, the detect secrets is now able to correctly show infos about GCP Keys.

Does this PR introduce a breaking change?
No changes are need.

Other information:
Hi, I'am Lucas and I working on a team where we are interested on using Detect-secrets in our CI pipeline. Although this projects is already completed and it has much plugins, we miss some of detections like GCP, Firebase and Facebook tokens plugins. And that's the reason I'am making this pull request, to help detect-secrets to help us and the community in general.

Hi. Please merge master to your branch to re-run CI.

I have seen this PR stale for over a year - can we try it again?

@chrislin22 if you need these changes, feel free to open a PR yourself with what's in here so we can review and merge that instead


Support SemanticKITTI dataset

This is a development requirement documentation of a feature we wish to collaborate with the community.
In this issue, we wish to welcome the community developers to participate in the support of SemanticKITTI dataset.
Steps

Implement the SemanticKITTIDataset
Add unit tests to test your code
Add KITTI Dataset for 3D Semnantic Segmentation introduction in doc

Resources

Offical paper: https://arxiv.org/abs/1904.01416
Experimental API for reference in MMDet3D: https://github.com/open-mmlab/mmdetection3d/blob/master/mmdet3d/datasets/semantickitti_dataset.py

@ZCMax Hi, I also want to pick this issue and have discussed the development plan with Wenwei Zhang. Thanks!


Tween Scatter Plot example please

Please :)

How's this: https://svelte.dev/repl/d94a3d12a8dc4408a8389b2601fdea03?version=3.38.2

No bad! But doesn’t use tween?

On Sep 22, 2021, at 19:00, Daniel Nass @.***> wrote:

How's this: https://svelte.dev/repl/d94a3d12a8dc4408a8389b2601fdea03?version=3.38.2
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

It uses tweened stores — are you talking about something else?


about the adjmatrix

Hi, can you tell me how did you initailze your adj_matrix without the NPZ file?

嗨，你能告诉我如何在没有 NPZ 文件的情况下启动你的adj_matrix吗？

Have you solved the problem? I wonder if you can communicate with me.

你好，你们运行结果和原论文接近吗


pivot_root complains Invalid argument

Hi ,
I am using diego with garden-linux to start a container,but pivot_root(wshd.c#L776) complains Invalid argument. my os is centos 7.1 and I have upgraded kernel to 4.0.2 compiled with auft4.0 module.
Is there any other kernel support for pivot_root?
the garden-linux-stdout.log
{"timestamp":"1431546463.278645992","source":"garden-linux","message":"garden-linux.pool.nevp5f9irno.creating","log_level":1,"data":{"session":"2.2"}}
{"timestamp":"1431546463.278743505","source":"garden-linux","message":"garden-linux.pool.nevp5f9irno.acquired-pool-resources","log_level":1,"data":{"session":"2.2"}}
{"timestamp":"1431546463.465993166","source":"garden-linux","message":"garden-linux.pool.nevp5f9irno.created","log_level":1,"data":{"session":"2.2"}}
{"timestamp":"1431546463.564160347","source":"garden-linux","message":"garden-linux.garden-server.bulk_info.got-bulkinfo","log_level":1,"data":{"handles":[""],"session":"4.74"}}
{"timestamp":"1431546463.680500031","source":"garden-linux","message":"garden-linux.pool.nevp5f9irno.start.command.failed","log_level":2,"data":{"argv":["/var/vcap/data/garden-linux/depot/nevp5f9irno/start.sh"],"error":"exit status 1","exit-status":1,"session":"<IP_ADDRESS>","stderr":"pivot_root: Invalid argument\nError waiting for acknowledgement from child process\n","stdout":"","took":"214.221802ms"}}
{"timestamp":"1431546463.680669546","source":"garden-linux","message":"garden-linux.pool.nevp5f9irno.start.failed-to-start","log_level":2,"data":{"error":"exit status 1","session":"2.2.4"}}
{"timestamp":"1431546463.680748224","source":"garden-linux","message":"garden-linux.pool.destroy.destroying","log_level":1,"data":{"id":"nevp5f9irno","session":"2.3"}}
{"timestamp":"1431546463.731221914","source":"garden-linux","message":"garden-linux.pool.destroy.command.failed","log_level":2,"data":{"argv":["/var/vcap/packages/garden-linux/garden-bin/destroy.sh","/var/vcap/data/garden-linux/depot/nevp5f9irno"],"error":"exit status 1","exit-status":1,"id":"nevp5f9irno","session":"2.3.1","stderr":"/var/vcap/data/garden-linux/depot/nevp5f9irno/destroy.sh: line 27: kill: (6599) - No such process\n","stdout":"","took":"41.399822ms"}}
{"timestamp":"1431546463.731603861","source":"garden-linux","message":"garden-linux.garden-server.create.failed","log_level":2,"data":{"error":"container: start: exit status 1","request":{"handle":"41717c36-71cc-4f9c-ac4d-41def7c1e0c3-ab38b89a91944b12848411a93335a6cf","rootfs":"/var/vcap/packages/rootfs_cflinuxfs2","properties":{"executor:action":"{\"timeout\":{\"action\":{\"serial\":{\"actions\":[{\"emit_progress\":{\"start_message\":\"\",\"success_message\":\"\",\"failure_message_prefix\":\"Failed to set up docker environment\",\"action\":{\"download\":{\"from\":\"http://file-server.service.consul:8080/v1/static/docker_app_lifecycle/docker_app_lifecycle.tgz\",\"to\":\"/tmp/docker_app_lifecycle\",\"cache_key\":\"builder-docker\"}}}},{\"emit_progress\":{\"start_message\":\"Staging...\",\"success_message\":\"Staging Complete\",\"failure_message_prefix\":\"Staging Failed\",\"action\":{\"run\":{\"path\":\"/tmp/docker_app_lifecycle/builder\",\"args\":[\"-outputMetadataJSONFilename\",\"/tmp/docker-result/result.json\",\"-dockerRef\",\"<IP_ADDRESS>:8080/lvguanglin/kodexplorer:latest\",\"-dockerRegistryAddresses\",\"<IP_ADDRESS>:8080\",\"-insecureDockerRegistries\",\"<IP_ADDRESS>:8080\",\"-cacheDockerImage\"],\"env\":[{\"name\":\"VCAP_APPLICATION\",\"value\":\"{\\\"limits\\\":{\\\"mem\\\":256,\\\"disk\\\":1024,\\\"fds\\\":16384},\\\"application_version\\\":\\\"10d506e1-79d6-48be-aa8c-017817689b46\\\",\\\"application_name\\\":\\\"kod\\\",\\\"version\\\":\\\"10d506e1-79d6-48be-aa8c-017817689b46\\\",\\\"name\\\":\\\"kod\\\",\\\"space_name\\\":\\\"admin\\\",\\\"space_id\\\":\\\"7b633d82-73fb-47e2-bf2d-24734bf68f9a\\\"}\"},{\"name\":\"VCAP_SERVICES\",\"value\":\"{}\"},{\"name\":\"MEMORY_LIMIT\",\"value\":\"256m\"},{\"name\":\"CF_STACK\",\"value\":\"cflinuxfs2\"},{\"name\":\"DIEGO_DOCKER_CACHE\",\"value\":\"true\"}],\"resource_limits\":{\"nofile\":16384},\"privileged\":true}}}}]}},\"timeout\":900000000000}}","executor:allocated-at":"1431546463252012459","executor:cpu-weight":"100","executor:disk-mb":"6144","executor:egress-rules":"[{\"protocol\":\"all\",\"destinations\":[\"<IP_ADDRESS>-<IP_ADDRESS>\"],\"log\":false},{\"protocol\":\"all\",\"destinations\":[\"<IP_ADDRESS>-<IP_ADDRESS>\"],\"log\":false},{\"protocol\":\"all\",\"destinations\":[\"<IP_ADDRESS>-<IP_ADDRESS>\"],\"log\":false},{\"protocol\":\"all\",\"destinations\":[\"<IP_ADDRESS>-<IP_ADDRESS>\"],\"log\":false},{\"protocol\":\"all\",\"destinations\":[\"<IP_ADDRESS>-<IP_ADDRESS>\"],\"log\":false},{\"protocol\":\"tcp\",\"destinations\":[\"<IP_ADDRESS>/0\"],\"ports\":[53],\"log\":false},{\"protocol\":\"udp\",\"destinations\":[\"<IP_ADDRESS>/0\"],\"ports\":[53],\"log\":false},{\"protocol\":\"all\",\"destinations\":[\"<IP_ADDRESS>-<IP_ADDRESS>\"],\"log\":false},{\"protocol\":\"all\",\"destinations\":[\"<IP_ADDRESS>-<IP_ADDRESS>\"],\"log\":false},{\"protocol\":\"all\",\"destinations\":[\"<IP_ADDRESS>-<IP_ADDRESS>\"],\"log\":false},{\"protocol\":\"all\",\"destinations\":[\"<IP_ADDRESS>-<IP_ADDRESS>\"],\"log\":false},{\"protocol\":\"all\",\"destinations\":[\"<IP_ADDRESS>-<IP_ADDRESS>\"],\"log\":false},{\"protocol\":\"tcp\",\"destinations\":[\"<IP_ADDRESS>/0\"],\"ports\":[53],\"log\":false},{\"protocol\":\"udp\",\"destinations\":[\"<IP_ADDRESS>/0\"],\"ports\":[53],\"log\":false},{\"protocol\":\"tcp\",\"destinations\":[\"<IP_ADDRESS>\"],\"ports\":[8080],\"log\":false}]","executor:env":"null","executor:log-config":"{\"guid\":\"41717c36-71cc-4f9c-ac4d-41def7c1e0c3\",\"index\":0,\"source_name\":\"STG\"}","executor:memory-mb":"1024","executor:metrics-config":"{\"guid\":\"\",\"index\":0}","executor:monitor":"null","executor:owner":"executor","executor:result":"{\"failed\":false,\"failure_reason\":\"\",\"stopped\":false}","executor:rootfs":"/var/vcap/packages/rootfs_cflinuxfs2","executor:setup":"null","executor:start-timeout":"0","executor:state":"created","tag:domain":"cf-app-staging","tag:lifecycle":"task","tag:result-file":"/tmp/docker-result/result.json"},"privileged":true},"session":"4.71"}}
{"timestamp":"1431546463.769743919","source":"garden-linux","message":"garden-linux.garden-server.destroy.failed","log_level":2,"data":{"error":"unknown handle: 41717c36-71cc-4f9c-ac4d-41def7c1e0c3-ab38b89a91944b12848411a93335a6cf","handle":"41717c36-71cc-4f9c-ac4d-41def7c1e0c3-ab38b89a91944b12848411a93335a6cf","session":"4.75"}}

df -h

Filesystem     Type      Size  Used Avail Use% Mounted on
devtmpfs       devtmpfs  2.0G     0  2.0G   0% /dev
tmpfs          tmpfs     2.0G     0  2.0G   0% /dev/shm
tmpfs          tmpfs     2.0G  8.3M  2.0G   1% /run
tmpfs          tmpfs     2.0G     0  2.0G   0% /sys/fs/cgroup
/dev/vda1      ext4       38G   11G   25G  30% /
/dev/vda3      ext4       38G  1.5G   34G   5% /var/vcap/data
tmpfs          tmpfs     1.0M   28K  996K   3% /var/vcap/data/sys/run
/dev/loop0     ext4      120M  1.6M  115M   2% /tmp
cgroup         tmpfs     2.0G  8.0K  2.0G   1% /tmp/garden-/cgroup
none           aufs       38G  1.5G   34G   5% /var/vcap/data/garden-linux/overlays/ngsn71i2p5t/rootfs
none           aufs       38G  1.5G   34G   5% /var/vcap/data/garden-linux/overlays/ngsn71i2p5t/rootfs

/proc/mounts

proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
devtmpfs /dev devtmpfs rw,nosuid,size=2008488k,nr_inodes=502122,mode=755 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,nodev,mode=755 0 0
tmpfs /sys/fs/cgroup tmpfs rw,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd 0 0
pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/net_cls cgroup rw,nosuid,nodev,noexec,relatime,net_cls 0 0
cgroup /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0
cgroup /sys/fs/cgroup/hugetlb cgroup rw,nosuid,nodev,noexec,relatime,hugetlb 0 0
configfs /sys/kernel/config configfs rw,relatime 0 0
/dev/vda1 / ext4 rw,relatime,data=ordered 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=29,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
mqueue /dev/mqueue mqueue rw,relatime 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,relatime 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
/dev/vdb2 /var/vcap/data ext4 rw,relatime,data=ordered 0 0
tmpfs /var/vcap/data/sys/run tmpfs rw,relatime,size=1024k 0 0
/dev/loop0 /tmp ext4 rw,relatime,data=ordered 0 0
/dev/vdb2 /var/vcap/data/garden-linux/graph/aufs ext4 rw,relatime,data=ordered 0 0
cgroup /tmp/garden-/cgroup tmpfs rw,relatime,mode=755 0 0
cgroup /tmp/garden-/cgroup/cpuset cgroup rw,relatime,cpuset 0 0
cgroup /tmp/garden-/cgroup/blkio cgroup rw,relatime,blkio 0 0
cgroup /tmp/garden-/cgroup/memory cgroup rw,relatime,memory 0 0
cgroup /tmp/garden-/cgroup/devices cgroup rw,relatime,devices 0 0
cgroup /tmp/garden-/cgroup/freezer cgroup rw,relatime,freezer 0 0
cgroup /tmp/garden-/cgroup/net_cls cgroup rw,relatime,net_cls 0 0
cgroup /tmp/garden-/cgroup/perf_event cgroup rw,relatime,perf_event 0 0
cgroup /tmp/garden-/cgroup/hugetlb cgroup rw,relatime,hugetlb 0 0
none /var/vcap/data/garden-linux/overlays/nerqi07c98r/rootfs aufs rw,relatime,si=3d779c18ad618124 0 0
devpts /var/vcap/data/garden-linux/overlays/nerqi07c98r/rootfs/dev/pts devpts rw,relatime,mode=600,ptmxmode=666 0 0
none /var/vcap/data/garden-linux/overlays/nerqi07c98r/rootfs aufs rw,relatime,si=3d779c18ad618124 0 0
devpts /var/vcap/data/garden-linux/overlays/nerqi07c98r/rootfs/dev/pts devpts rw,relatime,mode=600,ptmxmode=666 0 0
none /var/vcap/data/garden-linux/overlays/nevp5f9irno/rootfs aufs rw,relatime,si=3d779c18ad61d124 0 0
devpts /var/vcap/data/garden-linux/overlays/nevp5f9irno/rootfs/dev/pts devpts rw,relatime,mode=600,ptmxmode=666 0 0
none /var/vcap/data/garden-linux/overlays/nevp5f9irno/rootfs aufs rw,relatime,si=3d779c18ad61d124 0 0
devpts /var/vcap/data/garden-linux/overlays/nevp5f9irno/rootfs/dev/pts devpts rw,relatime,mode=600,ptmxmode=666 0 0

hi
I've replaced pivot_root with MS_MOVE and chroot at wshd.c#L776,then the  first container create successfully,stage complete,but the next container start failed with clone: Operation not permitted.
here is my changes at wshd.c#L776
 736 int child_run(void *data) {
 737   wshd_t *w = (wshd_t *)data;
 738   int rv;
 739   char pivoted_lib_path[PATH_MAX];
 740   size_t pivoted_lib_path_len;
           ......
 769 #if 0
 770   rv = mkdir("tmp/garden-host", 0700);
 771   if (rv == -1 && errno != EEXIST) {
 772     perror("mkdir");
 773     abort();
 774   }
 775
 776   rv = pivot_root(".", "tmp/garden-host");
 777   if (rv == -1) {
 778     perror("pivot_root");
 779     abort();
 780   }
 781 #else
 782  rv = system("mkdir -p -m 0700 tmp/garden-host/var/vcap/data");
 783   if (rv == -1 && errno != EEXIST) {
 784     perror("mkdir");
 785     abort();
 786   }
 787
 788  if (mount(w->root_path,"/", NULL, MS_BIND|MS_MOVE, NULL)) {
 789     perror("mount");
 790     abort();
 791  }
 792
 793  rv = system("mount -t aufs -o br:/var/vcap/data=rw none tmp/garden-host/var/vcap/data");
 794   if (rv == -1) {
 795     perror("mount");
 796     abort();
 797   }
 798
 799   rv = chroot(".");
 800   if (rv == -1) {
 801     perror("chroot");
 802     abort();
 803   }
 804 #endif

the error
"stderr":"clone: Operation not permitted\n/var/vcap/data/garden-linux/depot/njer0gqurvc/start.sh: line 25:  5178 Aborted
(core dumped) ./bin/wshd --run ./run --lib ./lib --root $rootfs_path --title \"wshd: $id\" --userns enabled\n"

the full garden-linux-stdout.log
{"timestamp":"1431703811.151561260","source":"garden-linux","message":"garden-linux.pool.njer0gqurvb.creating","log_level":1,"data":{"session":"2.1"}}
{"timestamp":"1431703811.151650667","source":"garden-linux","message":"garden-linux.pool.njer0gqurvb.acquired-pool-resources","log_level":1,"data":{"session":"2.1"}}
{"timestamp":"1431703812.074441910","source":"garden-linux","message":"garden-linux.pool.njer0gqurvb.created","log_level":1,"data":{"session":"2.1"}}
{"timestamp":"1431703812.461045265","source":"garden-linux","message":"garden-linux.pool.njer0gqurvb.start.started","log_level":1,"data":{"session":"2.1.4"}}
{"timestamp":"1431703812.461694956","source":"garden-linux","message":"garden-linux.garden-server.create.created","log_level":1,"data":{"request":{"handle":"14c95c19-b04d-4f53-8b88-143a838a3ec2-36cd890165df4e1ba38fee40d5a65ecd","rootfs":"/var/vcap/packages/rootfs_cflinuxfs2","properties":{"executor:action":"{\"timeout\":{\"action\":{\"serial\":{\"actions\":[{\"emit_progress\":{\"start_message\":\"\",\"success_message\":\"\",\"failure_message_prefix\":\"Failed to set up docker environment\",\"action\":{\"download\":{\"from\":\"http://file-server.service.consul:8080/v1/static/docker_app_lifecycle/docker_app_lifecycle.tgz\",\"to\":\"/tmp/docker_app_lifecycle\",\"cache_key\":\"builder-docker\"}}}},{\"emit_progress\":{\"start_message\":\"Staging...\",\"success_message\":\"Staging Complete\",\"failure_message_prefix\":\"Staging Failed\",\"action\":{\"run\":{\"path\":\"/tmp/docker_app_lifecycle/builder\",\"args\":[\"-outputMetadataJSONFilename\",\"/tmp/docker-result/result.json\",\"-dockerRef\",\"<IP_ADDRESS>:8080/lvguanglin/kodexplorer:latest\",\"-dockerRegistryAddresses\",\"<IP_ADDRESS>:8080\",\"-insecureDockerRegistries\",\"<IP_ADDRESS>:8080\",\"-cacheDockerImage\"],\"env\":[{\"name\":\"VCAP_APPLICATION\",\"value\":\"{\\\"limits\\\":{\\\"mem\\\":256,\\\"disk\\\":1024,\\\"fds\\\":16384},\\\"application_version\\\":\\\"22940dc8-2507-4006-8f9e-76a14e2fc83d\\\",\\\"application_name\\\":\\\"kod\\\",\\\"version\\\":\\\"22940dc8-2507-4006-8f9e-76a14e2fc83d\\\",\\\"name\\\":\\\"kod\\\",\\\"space_name\\\":\\\"admin\\\",\\\"space_id\\\":\\\"7b633d82-73fb-47e2-bf2d-24734bf68f9a\\\"}\"},{\"name\":\"VCAP_SERVICES\",\"value\":\"{}\"},{\"name\":\"MEMORY_LIMIT\",\"value\":\"256m\"},{\"name\":\"CF_STACK\",\"value\":\"cflinuxfs2\"},{\"name\":\"DIEGO_DOCKER_CACHE\",\"value\":\"true\"}],\"resource_limits\":{\"nofile\":16384},\"privileged\":true}}}}]}},\"timeout\":900000000000}}","executor:allocated-at":"1431703811127977304","executor:cpu-weight":"100","executor:disk-mb":"6144","executor:egress-rules":"[{\"protocol\":\"all\",\"destinations\":[\"<IP_ADDRESS>-<IP_ADDRESS>\"],\"log\":false},{\"protocol\":\"all\",\"destinations\":[\"<IP_ADDRESS>-<IP_ADDRESS>\"],\"log\":false},{\"protocol\":\"all\",\"destinations\":[\"<IP_ADDRESS>-<IP_ADDRESS>\"],\"log\":false},{\"protocol\":\"all\",\"destinations\":[\"<IP_ADDRESS>-<IP_ADDRESS>\"],\"log\":false},{\"protocol\":\"all\",\"destinations\":[\"<IP_ADDRESS>-<IP_ADDRESS>\"],\"log\":false},{\"protocol\":\"tcp\",\"destinations\":[\"<IP_ADDRESS>/0\"],\"ports\":[53],\"log\":false},{\"protocol\":\"udp\",\"destinations\":[\"<IP_ADDRESS>/0\"],\"ports\":[53],\"log\":false},{\"protocol\":\"all\",\"destinations\":[\"<IP_ADDRESS>-<IP_ADDRESS>\"],\"log\":false},{\"protocol\":\"all\",\"destinations\":[\"<IP_ADDRESS>-<IP_ADDRESS>\"],\"log\":false},{\"protocol\":\"all\",\"destinations\":[\"<IP_ADDRESS>-<IP_ADDRESS>\"],\"log\":false},{\"protocol\":\"all\",\"destinations\":[\"<IP_ADDRESS>-<IP_ADDRESS>\"],\"log\":false},{\"protocol\":\"all\",\"destinations\":[\"<IP_ADDRESS>-<IP_ADDRESS>\"],\"log\":false},{\"protocol\":\"tcp\",\"destinations\":[\"<IP_ADDRESS>/0\"],\"ports\":[53],\"log\":false},{\"protocol\":\"udp\",\"destinations\":[\"<IP_ADDRESS>/0\"],\"ports\":[53],\"log\":false},{\"protocol\":\"tcp\",\"destinations\":[\"<IP_ADDRESS>\"],\"ports\":[8080],\"log\":false}]","executor:env":"null","executor:log-config":"{\"guid\":\"14c95c19-b04d-4f53-8b88-143a838a3ec2\",\"index\":0,\"source_name\":\"STG\"}","executor:memory-mb":"1024","executor:metrics-config":"{\"guid\":\"\",\"index\":0}","executor:monitor":"null","executor:owner":"executor","executor:result":"{\"failed\":false,\"failure_reason\":\"\",\"stopped\":false}","executor:rootfs":"/var/vcap/packages/rootfs_cflinuxfs2","executor:setup":"null","executor:start-timeout":"0","executor:state":"created","tag:domain":"cf-app-staging","tag:lifecycle":"task","tag:result-file":"/tmp/docker-result/result.json"},"privileged":true},"session":"4.97"}}
{"timestamp":"1431703812.603288174","source":"garden-linux","message":"garden-linux.garden-server.limit-memory.limited","log_level":1,"data":{"handle":"14c95c19-b04d-4f53-8b88-143a838a3ec2-36cd890165df4e1ba38fee40d5a65ecd","resulting-limits":{"limit_in_bytes":1073741824},"session":"4.114"}}
{"timestamp":"1431703812.604401112","source":"garden-linux","message":"garden-linux.garden-server.limit-disk.limited","log_level":1,"data":{"handle":"14c95c19-b04d-4f53-8b88-143a838a3ec2-36cd890165df4e1ba38fee40d5a65ecd","resulting-limits":{},"session":"4.115"}}
{"timestamp":"1431703812.605396271","source":"garden-linux","message":"garden-linux.garden-server.limit-cpu.limited","log_level":1,"data":{"handle":"14c95c19-b04d-4f53-8b88-143a838a3ec2-36cd890165df4e1ba38fee40d5a65ecd","resulting-limits":{"limit_in_shares":1024},"session":"4.116"}}
{"timestamp":"1431703813.511303425","source":"garden-linux","message":"garden-linux.garden-server.stream-in.streamed-in","log_level":1,"data":{"destination":"/tmp/docker_app_lifecycle","handle":"14c95c19-b04d-4f53-8b88-143a838a3ec2-36cd890165df4e1ba38fee40d5a65ecd","session":"4.123"}}
{"timestamp":"1431703813.534037590","source":"garden-linux","message":"garden-linux.garden-server.run.spawned","log_level":1,"data":{"handle":"14c95c19-b04d-4f53-8b88-143a838a3ec2-36cd890165df4e1ba38fee40d5a65ecd","id":1,"session":"4.124","spec":{"path":"/tmp/docker_app_lifecycle/builder","args":["-outputMetadataJSONFilename","/tmp/docker-result/result.json","-dockerRef","<IP_ADDRESS>:8080/lvguanglin/kodexplorer:latest","-dockerRegistryAddresses","<IP_ADDRESS>:8080","-insecureDockerRegistries","<IP_ADDRESS>:8080","-cacheDockerImage"],"env":["VCAP_APPLICATION={\"limits\":{\"mem\":256,\"disk\":1024,\"fds\":16384},\"application_version\":\"22940dc8-2507-4006-8f9e-76a14e2fc83d\",\"application_name\":\"kod\",\"version\":\"22940dc8-2507-4006-8f9e-76a14e2fc83d\",\"name\":\"kod\",\"space_name\":\"admin\",\"space_id\":\"7b633d82-73fb-47e2-bf2d-24734bf68f9a\"}","VCAP_SERVICES={}","MEMORY_LIMIT=256m","CF_STACK=cflinuxfs2","DIEGO_DOCKER_CACHE=true","CF_INSTANCE_IP=<IP_ADDRESS>","CF_INSTANCE_PORT=","CF_INSTANCE_ADDR=","CF_INSTANCE_PORTS="],"privileged":true,"rlimits":{"nofile":16384}}}}
{"timestamp":"1431703936.468245745","source":"garden-linux","message":"garden-linux.garden-server.run.exited","log_level":1,"data":{"handle":"14c95c19-b04d-4f53-8b88-143a838a3ec2-36cd890165df4e1ba38fee40d5a65ecd","id":1,"session":"4.124","status":0}}
{"timestamp":"1431703936.491443872","source":"garden-linux","message":"garden-linux.garden-server.stream-out.streamed-out","log_level":1,"data":{"handle":"14c95c19-b04d-4f53-8b88-143a838a3ec2-36cd890165df4e1ba38fee40d5a65ecd","session":"4.191","source":"/tmp/docker-result/result.json"}}
{"timestamp":"1431703936.525891066","source":"garden-linux","message":"garden-linux.pool.destroy.destroying","log_level":1,"data":{"id":"njer0gqurvb","session":"2.2"}}
{"timestamp":"1431703936.732522011","source":"garden-linux","message":"garden-linux.pool.njer0gqurvc.creating","log_level":1,"data":{"session":"2.3"}}
{"timestamp":"1431703936.733243465","source":"garden-linux","message":"garden-linux.pool.njer0gqurvc.acquired-pool-resources","log_level":1,"data":{"session":"2.3"}}
{"timestamp":"1431703937.232765198","source":"garden-linux","message":"garden-linux.garden-server.bulk_info.got-bulkinfo","log_level":1,"data":{"handles":["14c95c19-b04d-4f53-8b88-143a838a3ec2-36cd890165df4e1ba38fee40d5a65ecd"],"session":"4.202"}}
{"timestamp":"1431703938.795627594","source":"garden-linux","message":"garden-linux.pool.njer0gqurvc.create-rootfs.fetch.using-cached","log_level":1,"data":{"layer":"e9e06b06e14c2f7d8df0251e3bb852c3a10a70639498163d4f180a823c18fdfc","repo":{"Scheme":"docker","Opaque":"","User":null,"Host":"<IP_ADDRESS>:8080","Path":"/656f760c-dd3e-473a-5b1e-3e93a1bdf937","RawQuery":"","Fragment":""},"session":"<IP_ADDRESS>","tag":"latest"}}
{"timestamp":"1431703938.811636209","source":"garden-linux","message":"garden-linux.pool.njer0gqurvc.create-rootfs.fetch.using-cached","log_level":1,"data":{"layer":"a82efea989f94b1d9fac76e26e37b0bbde11047a3afcaa47064949dfa3b3209b","repo":{"Scheme":"docker","Opaque":"","User":null,"Host":"<IP_ADDRESS>:8080","Path":"/656f760c-dd3e-473a-5b1e-3e93a1bdf937","RawQuery":"","Fragment":""},"session":"<IP_ADDRESS>","tag":"latest"}}
{"timestamp":"1431703938.818046093","source":"garden-linux","message":"garden-linux.pool.njer0gqurvc.create-rootfs.fetch.using-cached","log_level":1,"data":{"layer":"37bea4ee0c816e3a3fa025f36127ef8ef0817b3f8fcd7b49eb7b26064f647bb0","repo":{"Scheme":"docker","Opaque":"","User":null,"Host":"<IP_ADDRESS>:8080","Path":"/656f760c-dd3e-473a-5b1e-3e93a1bdf937","RawQuery":"","Fragment":""},"session":"<IP_ADDRESS>","tag":"latest"}}
{"timestamp":"1431703938.820479155","source":"garden-linux","message":"garden-linux.pool.njer0gqurvc.create-rootfs.fetch.using-cached","log_level":1,"data":{"layer":"07f8e8c5e66084bef8f848877857537ffe1c47edd01a93af27e7161672ad0e95","repo":{"Scheme":"docker","Opaque":"","User":null,"Host":"<IP_ADDRESS>:8080","Path":"/656f760c-dd3e-473a-5b1e-3e93a1bdf937","RawQuery":"","Fragment":""},"session":"<IP_ADDRESS>","tag":"latest"}}
{"timestamp":"1431703938.824012756","source":"garden-linux","message":"garden-linux.pool.njer0gqurvc.create-rootfs.fetch.using-cached","log_level":1,"data":{"layer":"517815ed3b48c1d331c638222476def0701aac80d95f269196f486d9c2fda1db","repo":{"Scheme":"docker","Opaque":"","User":null,"Host":"<IP_ADDRESS>:8080","Path":"/656f760c-dd3e-473a-5b1e-3e93a1bdf937","RawQuery":"","Fragment":""},"session":"<IP_ADDRESS>","tag":"latest"}}
{"timestamp":"1431703938.826012611","source":"garden-linux","message":"garden-linux.pool.njer0gqurvc.create-rootfs.fetch.using-cached","log_level":1,"data":{"layer":"818587b938e2895ba834b1bcfb9fb343a0223b854b5274b22b51f51a07d85829","repo":{"Scheme":"docker","Opaque":"","User":null,"Host":"<IP_ADDRESS>:8080","Path":"/656f760c-dd3e-473a-5b1e-3e93a1bdf937","RawQuery":"","Fragment":""},"session":"<IP_ADDRESS>","tag":"latest"}}
{"timestamp":"1431703938.827690840","source":"garden-linux","message":"garden-linux.pool.njer0gqurvc.create-rootfs.fetch.using-cached","log_level":1,"data":{"layer":"6ed9791740bb195a436c8d49cef72975c301c380d094d8debb435b36ba2a676f","repo":{"Scheme":"docker","Opaque":"","User":null,"Host":"<IP_ADDRESS>:8080","Path":"/656f760c-dd3e-473a-5b1e-3e93a1bdf937","RawQuery":"","Fragment":""},"session":"<IP_ADDRESS>","tag":"latest"}}
{"timestamp":"1431703938.838202953","source":"garden-linux","message":"garden-linux.pool.njer0gqurvc.create-rootfs.fetch.using-cached","log_level":1,"data":{"layer":"9e26734a362bcf4ed6e676d84e8fec3b12f0fffb0e47512502a47b4e4107efa3","repo":{"Scheme":"docker","Opaque":"","User":null,"Host":"<IP_ADDRESS>:8080","Path":"/656f760c-dd3e-473a-5b1e-3e93a1bdf937","RawQuery":"","Fragment":""},"session":"<IP_ADDRESS>","tag":"latest"}}
{"timestamp":"1431703938.851776600","source":"garden-linux","message":"garden-linux.pool.njer0gqurvc.create-rootfs.fetch.using-cached","log_level":1,"data":{"layer":"ae55a5f5d1b1e2c7f5fae1f605b622a2e617e078de29e1598b5b81cac26a3704","repo":{"Scheme":"docker","Opaque":"","User":null,"Host":"<IP_ADDRESS>:8080","Path":"/656f760c-dd3e-473a-5b1e-3e93a1bdf937","RawQuery":"","Fragment":""},"session":"<IP_ADDRESS>","tag":"latest"}}
{"timestamp":"1431703938.863435268","source":"garden-linux","message":"garden-linux.pool.njer0gqurvc.create-rootfs.fetch.using-cached","log_level":1,"data":{"layer":"2f8a64ec2ddca1b1153fa7b5578f80bef0869c9716860d6d542eb0baa5f180b1","repo":{"Scheme":"docker","Opaque":"","User":null,"Host":"<IP_ADDRESS>:8080","Path":"/656f760c-dd3e-473a-5b1e-3e93a1bdf937","RawQuery":"","Fragment":""},"session":"<IP_ADDRESS>","tag":"latest"}}
{"timestamp":"1431703938.865911961","source":"garden-linux","message":"garden-linux.pool.njer0gqurvc.create-rootfs.fetch.using-cached","log_level":1,"data":{"layer":"6a19719adbbb295f382901bf3843baf985905c5f8fea2ac125c25ba3f1332ff7","repo":{"Scheme":"docker","Opaque":"","User":null,"Host":"<IP_ADDRESS>:8080","Path":"/656f760c-dd3e-473a-5b1e-3e93a1bdf937","RawQuery":"","Fragment":""},"session":"<IP_ADDRESS>","tag":"latest"}}
{"timestamp":"1431703938.868163347","source":"garden-linux","message":"garden-linux.pool.njer0gqurvc.create-rootfs.fetch.using-cached","log_level":1,"data":{"layer":"2b61682f643631d4eaaed4b19b710a6d2fd5ee26b1a4e0625776f22fac8834b7","repo":{"Scheme":"docker","Opaque":"","User":null,"Host":"<IP_ADDRESS>:8080","Path":"/656f760c-dd3e-473a-5b1e-3e93a1bdf937","RawQuery":"","Fragment":""},"session":"<IP_ADDRESS>","tag":"latest"}}
{"timestamp":"1431703938.870290279","source":"garden-linux","message":"garden-linux.pool.njer0gqurvc.create-rootfs.fetch.using-cached","log_level":1,"data":{"layer":"c00e2e6dec9b6ea98bad15d295e60bcd30480c7494bab8ac7cf082ff7b00f6f6","repo":{"Scheme":"docker","Opaque":"","User":null,"Host":"<IP_ADDRESS>:8080","Path":"/656f760c-dd3e-473a-5b1e-3e93a1bdf937","RawQuery":"","Fragment":""},"session":"<IP_ADDRESS>","tag":"latest"}}
{"timestamp":"1431703938.873536587","source":"garden-linux","message":"garden-linux.pool.njer0gqurvc.create-rootfs.fetch.using-cached","log_level":1,"data":{"layer":"c156d5d0a6d9254916881864614037bcc78fb9111c3115129e37aa30e6c96c31","repo":{"Scheme":"docker","Opaque":"","User":null,"Host":"<IP_ADDRESS>:8080","Path":"/656f760c-dd3e-473a-5b1e-3e93a1bdf937","RawQuery":"","Fragment":""},"session":"<IP_ADDRESS>","tag":"latest"}}
{"timestamp":"1431703938.875455141","source":"garden-linux","message":"garden-linux.pool.njer0gqurvc.create-rootfs.fetch.using-cached","log_level":1,"data":{"layer":"2ad2c5b9cd3df751d0d7fce65ab2c36720bcb4bbdf2d19bfad2261e6df527269","repo":{"Scheme":"docker","Opaque":"","User":null,"Host":"<IP_ADDRESS>:8080","Path":"/656f760c-dd3e-473a-5b1e-3e93a1bdf937","RawQuery":"","Fragment":""},"session":"<IP_ADDRESS>","tag":"latest"}}
{"timestamp":"1431703938.877588034","source":"garden-linux","message":"garden-linux.pool.njer0gqurvc.create-rootfs.fetch.using-cached","log_level":1,"data":{"layer":"0f25e059c8092425096dfc53d647d39aef5fbb94fed7303a89f82cffbd3ab77a","repo":{"Scheme":"docker","Opaque":"","User":null,"Host":"<IP_ADDRESS>:8080","Path":"/656f760c-dd3e-473a-5b1e-3e93a1bdf937","RawQuery":"","Fragment":""},"session":"<IP_ADDRESS>","tag":"latest"}}
{"timestamp":"1431703938.879557848","source":"garden-linux","message":"garden-linux.pool.njer0gqurvc.create-rootfs.fetch.using-cached","log_level":1,"data":{"layer":"24f5858adb90b5b82ce7d9c03982273783df25742bedac72bb48394dfaf95526","repo":{"Scheme":"docker","Opaque":"","User":null,"Host":"<IP_ADDRESS>:8080","Path":"/656f760c-dd3e-473a-5b1e-3e93a1bdf937","RawQuery":"","Fragment":""},"session":"<IP_ADDRESS>","tag":"latest"}}
{"timestamp":"1431703938.882761478","source":"garden-linux","message":"garden-linux.pool.njer0gqurvc.create-rootfs.fetch.using-cached","log_level":1,"data":{"layer":"d343430986f7ee37d1c817b617ea18d6c917f5a6747b0d5b60c91f44f95d297a","repo":{"Scheme":"docker","Opaque":"","User":null,"Host":"<IP_ADDRESS>:8080","Path":"/656f760c-dd3e-473a-5b1e-3e93a1bdf937","RawQuery":"","Fragment":""},"session":"<IP_ADDRESS>","tag":"latest"}}
{"timestamp":"1431703938.885256767","source":"garden-linux","message":"garden-linux.pool.njer0gqurvc.create-rootfs.fetch.using-cached","log_level":1,"data":{"layer":"ac1d1fec2d54b18c425ca8556712f3cb6e894721f44c116b60b24c4bca1cd7cc","repo":{"Scheme":"docker","Opaque":"","User":null,"Host":"<IP_ADDRESS>:8080","Path":"/656f760c-dd3e-473a-5b1e-3e93a1bdf937","RawQuery":"","Fragment":""},"session":"<IP_ADDRESS>","tag":"latest"}}
{"timestamp":"1431703938.895916939","source":"garden-linux","message":"garden-linux.pool.njer0gqurvc.create-rootfs.fetch.using-cached","log_level":1,"data":{"layer":"63ae5a65c5ced9c8cc7592dda607babbb0882dbf9a599601d11f363eec2e9901","repo":{"Scheme":"docker","Opaque":"","User":null,"Host":"<IP_ADDRESS>:8080","Path":"/656f760c-dd3e-473a-5b1e-3e93a1bdf937","RawQuery":"","Fragment":""},"session":"<IP_ADDRESS>","tag":"latest"}}
{"timestamp":"1431703938.905521631","source":"garden-linux","message":"garden-linux.pool.njer0gqurvc.create-rootfs.fetch.using-cached","log_level":1,"data":{"layer":"f059ba32415e8633b85a565589465852de82249b0e63a17b92eea956149beca0","repo":{"Scheme":"docker","Opaque":"","User":null,"Host":"<IP_ADDRESS>:8080","Path":"/656f760c-dd3e-473a-5b1e-3e93a1bdf937","RawQuery":"","Fragment":""},"session":"<IP_ADDRESS>","tag":"latest"}}
{"timestamp":"1431703938.908298016","source":"garden-linux","message":"garden-linux.pool.njer0gqurvc.create-rootfs.fetch.using-cached","log_level":1,"data":{"layer":"f070f667386159ce92323a79f8493b57a52eed43b778a0a69a167b2b7b840aae","repo":{"Scheme":"docker","Opaque":"","User":null,"Host":"<IP_ADDRESS>:8080","Path":"/656f760c-dd3e-473a-5b1e-3e93a1bdf937","RawQuery":"","Fragment":""},"session":"<IP_ADDRESS>","tag":"latest"}}
{"timestamp":"1431703938.911014080","source":"garden-linux","message":"garden-linux.pool.njer0gqurvc.create-rootfs.fetch.using-cached","log_level":1,"data":{"layer":"4f3c18a21972e083acf8106461e05230d9bb066cc97602c82b707728f0872e85","repo":{"Scheme":"docker","Opaque":"","User":null,"Host":"<IP_ADDRESS>:8080","Path":"/656f760c-dd3e-473a-5b1e-3e93a1bdf937","RawQuery":"","Fragment":""},"session":"<IP_ADDRESS>","tag":"latest"}}
{"timestamp":"1431703940.381715536","source":"garden-linux","message":"garden-linux.pool.njer0gqurvc.created","log_level":1,"data":{"session":"2.3"}}
{"timestamp":"1431703940.483354568","source":"garden-linux","message":"garden-linux.pool.njer0gqurvc.start.command.failed","log_level":2,"data":{"argv":["/var/vcap/data/garden-linux/depot/njer0gqurvc/start.sh"],"error":"exit status 134","exit-status":134,"session":"<IP_ADDRESS>","stderr":"clone: Operation not permitted\n/var/vcap/data/garden-linux/depot/njer0gqurvc/start.sh: line 25:  5178 Aborted                 (core dumped) ./bin/wshd --run ./run --lib ./lib --root $rootfs_path --title \"wshd: $id\" --userns enabled\n","stdout":"","took":"101.324924ms"}}
{"timestamp":"1431703940.483603716","source":"garden-linux","message":"garden-linux.pool.njer0gqurvc.start.failed-to-start","log_level":2,"data":{"error":"exit status 134","session":"2.3.4"}}
{"timestamp":"1431703940.483704090","source":"garden-linux","message":"garden-linux.pool.destroy.destroying","log_level":1,"data":{"id":"njer0gqurvc","session":"2.4"}}
{"timestamp":"1431703940.644583225","source":"garden-linux","message":"garden-linux.pool.destroy.destroyed","log_level":1,"data":{"id":"njer0gqurvc","session":"2.4"}}
{"timestamp":"1431703940.644735813","source":"garden-linux","message":"garden-linux.garden-server.create.failed","log_level":2,"data":{"error":"container: start: exit status 134","request":{"handle":"14c95c19-b04d-4f53-8b88-143a838a3ec2-22940dc8-2507-4006-8f9e-76a14e2fc83d-e2ca7a6b-12dc-4bd3-6a73-a5036f1ebc55","rootfs":"docker://<IP_ADDRESS>:8080/656f760c-dd3e-473a-5b1e-3e93a1bdf937","properties":{"executor:action":"{\"parallel\":{\"actions\":[{\"run\":{\"path\":\"/tmp/lifecycle/launcher\",\"args\":[\"app\",\"/home/vcap/run.sh\",\"{\\\"cmd\\\":[\\\"/bin/bash\\\"],\\\"workdir\\\":\\\"/home/vcap\\\"}\"],\"env\":[{\"name\":\"VCAP_APPLICATION\",\"value\":\"{\\\"limits\\\":{\\\"mem\\\":256,\\\"disk\\\":1024,\\\"fds\\\":16384},\\\"application_version\\\":\\\"22940dc8-2507-4006-8f9e-76a14e2fc83d\\\",\\\"application_name\\\":\\\"kod\\\",\\\"version\\\":\\\"22940dc8-2507-4006-8f9e-76a14e2fc83d\\\",\\\"name\\\":\\\"kod\\\",\\\"space_name\\\":\\\"admin\\\",\\\"space_id\\\":\\\"7b633d82-73fb-47e2-bf2d-24734bf68f9a\\\"}\"},{\"name\":\"VCAP_SERVICES\",\"value\":\"{}\"},{\"name\":\"MEMORY_LIMIT\",\"value\":\"256m\"},{\"name\":\"CF_STACK\",\"value\":\"cflinuxfs2\"},{\"name\":\"DIEGO_DOCKER_CACHE\",\"value\":\"true\"},{\"name\":\"PORT\",\"value\":\"8080\"}],\"resource_limits\":{\"nofile\":16384},\"log_source\":\"APP\"}}]}}","executor:allocated-at":"1431703936704536967","executor:cpu-weight":"1","executor:disk-mb":"1024","executor:egress-rules":"[{\"protocol\":\"all\",\"destinations\":[\"<IP_ADDRESS>-<IP_ADDRESS>\"],\"log\":false},{\"protocol\":\"all\",\"destinations\":[\"<IP_ADDRESS>-<IP_ADDRESS>\"],\"log\":false},{\"protocol\":\"all\",\"destinations\":[\"<IP_ADDRESS>-<IP_ADDRESS>\"],\"log\":false},{\"protocol\":\"all\",\"destinations\":[\"<IP_ADDRESS>-<IP_ADDRESS>\"],\"log\":false},{\"protocol\":\"all\",\"destinations\":[\"<IP_ADDRESS>-<IP_ADDRESS>\"],\"log\":false},{\"protocol\":\"tcp\",\"destinations\":[\"<IP_ADDRESS>/0\"],\"ports\":[53],\"log\":false},{\"protocol\":\"udp\",\"destinations\":[\"<IP_ADDRESS>/0\"],\"ports\":[53],\"log\":false}]","executor:env":"[{\"name\":\"INSTANCE_GUID\",\"value\":\"e2ca7a6b-12dc-4bd3-6a73-a5036f1ebc55\"},{\"name\":\"INSTANCE_INDEX\",\"value\":\"0\"}]","executor:log-config":"{\"guid\":\"14c95c19-b04d-4f53-8b88-143a838a3ec2\",\"index\":0,\"source_name\":\"CELL\"}","executor:memory-mb":"256","executor:metrics-config":"{\"guid\":\"14c95c19-b04d-4f53-8b88-143a838a3ec2\",\"index\":0}","executor:monitor":"{\"timeout\":{\"action\":{\"run\":{\"path\":\"/tmp/lifecycle/healthcheck\",\"args\":[\"-port=8080\"],\"env\":null,\"resource_limits\":{\"nofile\":1024},\"log_source\":\"HEALTH\"}},\"timeout\":30000000000}}","executor:owner":"executor","executor:result":"{\"failed\":false,\"failure_reason\":\"\",\"stopped\":false}","executor:rootfs":"docker://<IP_ADDRESS>:8080/656f760c-dd3e-473a-5b1e-3e93a1bdf937","executor:setup":"{\"serial\":{\"actions\":[{\"download\":{\"from\":\"http://file-server.service.consul:8080/v1/static/docker_app_lifecycle/docker_app_lifecycle.tgz\",\"to\":\"/tmp/lifecycle\",\"cache_key\":\"\"}}]}}","executor:start-timeout":"60","executor:state":"created","tag:domain":"cf-apps","tag:instance-guid":"e2ca7a6b-12dc-4bd3-6a73-a5036f1ebc55","tag:lifecycle":"lrp","tag:process-guid":"14c95c19-b04d-4f53-8b88-143a838a3ec2-22940dc8-2507-4006-8f9e-76a14e2fc83d","tag:process-index":"0"},"env":["INSTANCE_GUID=e2ca7a6b-12dc-4bd3-6a73-a5036f1ebc55","INSTANCE_INDEX=0"]},"session":"4.199"}}
{"timestamp":"1431703940.679794788","source":"garden-linux","message":"garden-linux.garden-server.destroy.failed","log_level":2,"data":{"error":"unknown handle: 14c95c19-b04d-4f53-8b88-143a838a3ec2-22940dc8-2507-4006-8f9e-76a14e2fc83d-e2ca7a6b-12dc-4bd3-6a73-a5036f1ebc55","handle":"14c95c19-b04d-4f53-8b88-143a838a3ec2-22940dc8-2507-4006-8f9e-76a14e2fc83d-e2ca7a6b-12dc-4bd3-6a73-a5036f1ebc55","session":"4.203"}}

thanks

@vito @tsaleh @hiremaga @flavorjones
any help or advice is pretty good,thanks.

I'm afraid this isn't appropriate for a bug report. Please could you post to cf-dev instead?
Also, for future reference, you may care to read through how to ask questions the smart way.

@glyn
yes,i'm not sure it's a bug or not. it's maybe a incompatible problem with centos 7 systemd system.I had raise the issue in diego repo pivot_root complains invalid argument and they advice me raise it here to get your help.
1,pivot_root complains invalid argument in my scenario.
2,the clone complains Operation not permitted when the second container create.
I just need your advice and help for this issue not bug report.that's why i rasie both here.

@guanglinlv Sorry we've given you the run around. The problem is that we haven't yet started supporting centos or systemd, so we can't really help you. I'm hoping that if you pose your questions on a suitable mailing list, someone who has faced the same issues may be able to give you some tips. github issues, on the other hand, have a very limited audience and 3rd parties are unlikely to chime in.

hi @glyn
I have fix the pivot_root problem by mount --make-rprivate /. but umount2("/tmp/garden-host", MNT_DETACH) hang up the VM at wshd.c#839. so I have to delete the umount2,i'm not sure is there any other impact or not.
reference:

<a href=lxc-start: Invalid argument - pivot_root syscall failed>https://github.com/lxc/lxc/issues/61
Make container root fs private before starting container

BTW,is there a plan the support for centos?
thank you all the same.

We've talked about CentOS in the past, but currently there are no plans to support it.

FWIW @guanglinlv , I hit the same problem with the CentOS 7 stemcell and Concourse. Bit of a disappointment since I have a preference for RedHat/CentOS.

FYI
the Compatible problems with centos7:
P1, consul agent component start failed
S1: nmap-ncat is incompatible with the Healthcheck script of consul agent.
rpm -qa|grep ncat
rpm -e nmap-ncat-6.40-4.el7.x86_64
wget http://ftp.pbone.net/mirror/ftp5.gwdg.de/pub/opensuse/repositories/home:/assmannst/RedHat_RHEL-6/x86_64/netcat-1.10-891.2.x86_64.rpm
rpm -ivh netcat-1.10-891.2.x86_64.rpm

P2, pivot_root complain invalid argument
S2: the mount of root file system is shared in centos7
cat > /usr/lib/systemd/system/make-mount-private.service <<EOF
[Unit]
Description=Remounting root FS as private to use with Garden-linux
[Service]
Type=simple
RemainAfterExit=yes
ExecStart=/bin/mount --make-rprivate /
[Install]
WantedBy=multi-user.target
EOF
systemctl enable make-mount-private.service

P3, umount after pivot_root cause the vms hang up
S3: the user namespace  feature is incompatible in centos7. the workaround is let privileged true in resource_pool.go#L513
P4, the garden container destroy failed and cant get the cpu/mem information used cf app
S4: the /sys/fs/cgroup/cpu and /sys/fs/cgroup/cpuacct is combined in centos7. so we have to modify garden container setup to fix that.
all of the above problem i have fixed and integrate into my private repo garden-linux.
https://github.com/guanglinlv/garden-linux/commit/4a2fd58cad2a4190ac51ff1ff22e55485e3d86dc
https://github.com/guanglinlv/garden-linux/commit/3bf3114fbc465df90b9ae49086a72861732f66c1
this repo also support two customsize features:

directly network configuration in container
commit container rootfs and save out.

hope this post will help someone.thanks.

hi guanglin
We are deploying CF4.2 in SLES12(kernel 3.12.48.~). We came up with a problem the same as "pivot_root complain with invalid argument". We are wondering to find a way to solve it . Additionally, we find that there is a  different result from the unshare command running in SLES12 and Ubuntu 10.04.4.
In Ubuntu:
We created 3 directory: /root/test/1  /root/test/2  /root/test/3, each has a file such as 1.txt;2.txt;3.txt. Creating a script "test.sh" to mount 1/2 to 3, using overlayfs.
The result is that 3.txt under /root/test/3 directory will not be covered.
In SUSE12:
We created 3 directory: /root/test/1  /root/test/2  /root/test/3, each has a file such as 1.txt;2.txt;3.txt. Creating a script "test.sh" to mount 1/2 to 3, using overlayfs.
The result is that 3.txt under /root/test/3 directory will  be covered with 1.txt and 2.txt.
So which is correct? Is this something relationship with the pivot_root?

hi guangli,
In your solution for pivot_root complain, you replaced the pivot_root with MS_MOVE and chroot at wshd.c.
In the originally script , it uses "tmp/garden-host" . But in your script, it changed to " tmp/garden-host/var/vcap/data".
Why?

hi Guanglin
First of all , we used your S2 to solve the P2.  And then we faced the P3---umount after pivot_root could not work!
We trace the process ,and found the root cause is in mount.c as below:
int mount_umount_pivoted_root(const char *path) {
mount_lines_t dst;
size_t i;
int rv;
int retry;
mount__umount_paths_for_pivoted_root(&dst, path);
/* Iterate over paths to umount */
for (i = 0; i < dst.mount_len; i++) {
rv = umount(dst.mount_lines[i]);
for (retry = 0; rv == -1 && retry < 4; retry++) {
  if (errno != EBUSY) {
    break;
  }
  sleep(1);
  fprintf(stdout, "umount(%s):retry due to EBUSY\n", dst.mount_lines[i]);
  rv = umount(dst.mount_lines[i]);
}

if (rv == -1) {
  fprintf(stderr, "umount(%s): %s\n", dst.mount_lines[i], strerror(errno));
  return rv;
}

}
return 0;
}
I think the root cause is that the system can not umount the directory totally.
Could you give us some advise?

Hi @gary-guwenjun , sorry for late response.
#1 if you work with systemd system,you just need to create a new systemd service,It's make-mount-private here. whatever it is just a name.
#2 it's different of P3, umount will hang up my system, i just disable user namespace for garden container. just let RootUID is zero in resource_pool.go#L513
BTW, All of the above problem i posted is related with Diego or garden not warden.
thanks.

hi guanglin
Very appreciate for your comments!
Since SUSE is in deep  partner ship with Huawei ,and Huawei is the member of CF. Does Huawei has a SUSE Version for CF ?  And what OS is Huawei's CF based?

@gary-guwenjun
As far as i can see, we had used CF with Ubuntu or centos7, SUSE is not there.


JSON type throws error on certain types of valid JSON on create and update

Thank you @Jolg42  for addressing the previous two JSON issues:

https://github.com/prisma/prisma-client-js/issues/691
https://github.com/prisma/prisma/issues/2619#event-3397870489

This issue is the last (I think) for end-to-end JSON typing to work.
Bug description
We get a TypeScript error during a create or update for valid JSON in a JSON column if it contains optional properties like this.
type UserJSON = {
  name: string
  age?: number
}

The reason this happens is because TypeScript transforms the value of the age property by adding undefined so that it becomes number | undefined. The preceding type and the following type are identical:
type UserJSON = {
  name: string
  age?: number | undefined
}

This is a known limitation of TypeScript. It cannot distinguish a missing property from a property which can be set to undefined. https://github.com/microsoft/TypeScript/issues/13195
How to reproduce

Create any prisma model with a JSON column
Do a create or update to the JSON column with a valid JSON object that has an optional property

This code clarifies why this happens:
// JSON values from `type-fest` as used in Prisma
export type JsonObject = {[Key in string]?: JsonValue};
export interface JsonArray extends Array<JsonValue> {}
export type JsonValue = string | number | boolean | null | JsonObject | JsonArray;

type User = {
  name: string,
  age?: number
}

type IsUserJSON = User extends JsonObject ? true : false
// false but should be true

Expected behavior
The way to fix it is to define a UJsonValue like this and use that to type JSON values in a create or update:
// JSON values with `undefined` allowed
export type UJsonObject = { [Key in string]?: UJsonValue }
export interface UJsonArray extends Array<UJsonValue> {}
export type UJsonValue =
  | undefined
  | string
  | number
  | boolean
  | null
  | UJsonObject
  | UJsonArray

type User = {
  name: string
  age?: number
}

type IsUserUJSON = User extends UJsonObject ? true : false
// true

The most accurate and strictest way to type this is to have the find methods return a JsonValue and the create and update methods to accept a UJsonValue.
This works because JSON data coming out of Prisma is guaranteed to be in the restrictive JsonValue type. It never contains undefined.
In an end to end API, that value comes out of the database will then be typed into something like User.
The end user makes a change and saves it to Prisma. The JSON data coming into Prisma should accept UJsonValue. If it is typed to accept JsonValue, we get a TypeScript error even though User is valid JSON.
The less accurate method is to add undefined to JsonValue and be done with it; however, this affects users that are strictly typing their API against JsonValue as typed in type-fest. It won't affect me and I think most users because if it flows through an API, that API has to accept undefined or else it breaks whenever there is an optional property (ie. same problem in a different place).
In order of desirability, it goes like this:

JsonValue for find and UJsonValue for create and update (Fixes all cases)
JsonValue extended with undefined (solves all my use cases and probably most people)
JsonValue as it is (breaks valid JSON with optional properties on create and update)

## Prisma information
Beta 2.0.0-beta7
Environment & setup

OS: Mac OS
Database: PostgreSQL
Prisma version: 2.0.0-beta7
Node.js version: 12.16.2

Thanks for raising the issue @thesunny !
If we add undefiend, we also would need to add Date, as you could pass in dates, which are persisted as strings with JSON.stringify.
Then I'm wondering if we don't just want to support any, as we're fine with everything, as long as it's serializable.
Is there anything from your side that speaks against using any here?

Hi @timsuchanek,
I think it's prudent to apply the Principle of Least Surprise https://en.wikipedia.org/wiki/Principle_of_least_astonishment
One of the criticisms of old MySQL was that it would silently type cast things that in other databases would raise errors.
In the same way, it feels surprising to me to pass in a Date, a Function an enum or a class and get back a string. In a situation where I intend this to happen, it makes sense to need to be explicit and cast them to a string.
For me, the principle of least surprise for an ORM is that if I put a certain type of data in, it comes back as the same type.
undefined is different because we aren't trying to add an invalid data type undefined into the database. We instead want to be able to create data types with optional values which are valid values for a JSON column type.
Due to a limitation in TypeScript, we can't actually describe optional values without also adding undefined. This is a limitation in TypeScript at the moment https://github.com/microsoft/TypeScript/issues/13195. If it is ever fixed, I'd recommend at that time to remove undefined from create and update.
Also, for clarity, for data coming out of Prisma (ie. find), keeping it as JSON can help move data through an API like in nextjs that can only accept JSON values.

Thanks for the elaborate answer and the kind words.
We'll call your UJsonValue InputJsonValue to keep it with our existing conventions.

Thanks a lot for reporting 🙏
This issue is fixed in the latest dev version of @prisma/cli.
You can try it out with npm i -g @prisma/cli@dev.
In case it’s not fixed for you - please let us know and we’ll reopen this issue!

Hi @timsuchanek
Thanks for the update. Really appreciate the work you and everyone on your team put into Prisma.


Unpacking group keys is refused in multi-columns groups

Describe the bug
Unpacking group keys is refused in multi-columns groups, group key is wrongly assumed to be a str
To Reproduce
import pandas as pd
df = pd.DataFrame({"a": [0, 1, 2], "b": [4, 5, 6], "c": [7, 8, 9]})
for (k1, k2), g in df.groupby(["a", "b"]):
    print(k1, k2)

Script output
0 4
1 5
2 6

mypy output
foo.py:5: error: Unpacking a string is disallowed
foo.py:6: error: Cannot determine type of "k1"
foo.py:6: error: Cannot determine type of "k2"
Found 3 errors in 1 file (checked 1 source file)

Please complete the following information:

OS: Ubuntu 22.04
python=3.9.13
pandas=1.4.3
pandas-stubs=<IP_ADDRESS>710
mypy=0.961

Issue is in definition of __iter__() in pandas-stubs/core/groupby/groupby.pyi.  Should use what is in pandas source which is Iterator[tuple[Hashable, NDFrameT]] as the return type.
PR welcome.

We can't really support this with static typing, because the iterator produces a Tuple[Hashable, NDFrameT] .  The issue here is that the first component of the tuple could be another tuple (as in the case here) or could be a singular value.
>>> df = pd.DataFrame({"a": [0, 1, 2], "b": [4, 5, 6], "c": [7, 8, 9]})
>>> for k, g in df.groupby(["a", "b"]):
...     print(k, type(k))
...
(0, 4) <class 'tuple'>
(1, 5) <class 'tuple'>
(2, 6) <class 'tuple'>
>>> for k, g in df.groupby("a"):
...     print(k, type(k))
...
0 <class 'int'>
1 <class 'int'>
2 <class 'int'>

Since the groupby argument directly affects what the iterator produces, we can't track that.
The PR I created #148 does address partially this issue by improving the return type of __iter__(), but to do what you want here with respect to typing would need to be done as follows:
for k, g in df.groupby(["a", "b"]):
    k1, k2 = cast(Tuple[int, int], k)
    print(k1, k2)

Could have something like the following (I don't think it is worth it and it would also only work with tuple):
class DataFrame:
    @overload
    def groupby(keys: tuple[Hashable]) -> GroupByClass[tuple[Hashable]]: ...
    @overload
    def groupby(keys: tuple[Hashable, Hashable]) -> GroupByClass[tuple[Hashable, Hashable], DataFrame]: ...
    # ...
    @overload
    def groupby(keys: tuple[Hashable, ...]) -> GroupByClass[tuple[Hashable, ...], DataFrame]: ...

TuplesT = TypeVar("TuplesT", bound=tuple)
class GroupByClass(Generic[TuplesT, NDFrameT]):
    def __iter__(self) -> Iterator[tuple[TuplesT, NDFrameT]]: ...

I did something close to the above idea.  Might not catch some esoteric cases, but does differentiate between grouping by a list versus grouping by a single value.  See https://github.com/pandas-dev/pandas-stubs/pull/148/commits/383e1bf9821d5cafe72286844c6223cf2d48d319


Delete button moves the post it note

If you click delete on a post it, it occasionally moves the post it to the delete button location.
Not clear what causes this.

Changed onClick to onPointerDown to match the onPointerDown event on the card, and called preventDefault and stopPropagation on the delete button.


Resource endpoints

Added resource endpoints and base data structures.

Well, I'd like to see the schema creation in something like Flyway or Liquibase to version the database properly from the beginning.
Yah, but it's imho not the best decision to drive involvment in this project if it's using something unusual for spring projects.
Hm, the domain model feels artificial to me. Why did you implement these DTOs?
Ah sorry, it were too many lines. Only skimmed through. Now I see you added UnsupportedOperationException. :-)
Ok. :-)


Add timestamp attribute

🤔 What's changed?
While the timestamp attribute is not part of the JUnit or Surefire XSD in practice it seems to be a common enough property[1] that we can add it without expecting any of the popular tools to break.
Closes: #44

https://github.com/testmoapp/junitxml

🏷 What kind of change is this?

:zap: New feature (non-breaking change which adds new behaviour)

📋 Checklist:

[x] I agree to respect and uphold the Cucumber Community Code of Conduct
[ ] I've changed the behaviour of the code

[ ] I have added/updated tests to cover my changes.

[x] My change requires a change to the documentation.

[ ] I have updated the documentation accordingly.

[ ] Users should know about my change

[ ] I have added an entry to the "Unreleased" section of the CHANGELOG, linking to this pull request.

Great then we just have to update the docs.


Explain how it works?

Would be great to have a section on the readme (or elsewhere) that explains some particulars of how this app works. Specifically looking to know:

where the config of the app is

looks like in OS defaults -- eg inside ~/Library/Application\ Support/IPFS\ Desktop for macos

how the app finds the local ipfs repo

looks like the app config file points to default installation spot via a string in the app config (~/Library/Application\ Support/IPFS\ Desktop/config.json/.ipfsConfig/path -- LGTM 👍)

which version of the ipfs binary the app uses

looks like its own, from within /Applications/IPFS\ Desktop.app/Contents/Resources/app.asar.unpacked/node_modules/go-ipfs-dep/go-ipfs/ipfs version

how the app starts up the ipfs daemon (ie, what flags? )

looks like w/ the options passed into here: https://github.com/ipfs-shipyard/ipfs-desktop/blob/master/src/utils/daemon.js#L56

All the choices LGTM 👍.
(Ran into these questions trying to figure out why my cli ipfs's node is pointing to a different repo than IPFS Desktop's ipfs node. The ipfs in my $PATH was using a different repo than the default)

Hey @jbenet! Those are, indeed, good questions. I've just added a section to the README answering those questions 😄


Make cesium-unity compatible with the shared asset changes in cesium-native.

As we've discussed previously, we're not intending to fully implement the shared assets system in Unity at this point, as there are currently higher priority items that we need to get to. However, the changes made in cesium-native to support shared assets currently break the cesium-unity build. This change is the absolute minimum required to get cesium-unity working with the shared-assets branch of cesium-native. It doesn't implement the shared asset depot or change texture creation in any way.

@azrogers seems like the previous CI failures were flubs, so don't worry about them anymore. I'll give this a lookover later today.


Add (curr_node_id, bag,  error) to process table

There is no community available except the FlowBuild documentation.

What would you like to be added:
Columns (curr_node_id, bag,  error) to process table
Why is this needed:
Avoids join process_state table to process. It helps Analytics.

[] this issue need to update on docs? if yes where?
Wherever the documents of database models are.

[] this issue interact with a plugin or application? if yes spe
No.

Anything else we need to know:
No

this should not be dealt by the api.


ClickHouse support

Thanks for your awesome work! Can you add ClickHouse Support?

Thanks for your awesome work! Can you add ClickHouse Support?

I'm afraid now @mtxr hand is full, maybe if you have a seperate project that support his, he will be okay with it sir.

@ChugunovRoman so far I've been trying not to add new drivers to enhance the currently existing ones. The project is growing a lot, and that's awesome, but the worklaod has increased a lot for me to take over all issues.
But I've developed a tool to help developers to quick start in a new drivers. This tool generates some boiler plates stuff where you can start on.
I'll close this issue for to to keep track for the enhancements and bugs.
I'll be glad to merge a PR with this new driver if you are able to work on it. Reach me out if you need any help, I'll be happy to assist.

Hi!
I would like to try to implement ClickHouse support, I'll start working on this in the near future.
@mtxr , should we reopen this?

Done. Here you can get it if you still need this.
@ChugunovRoman

Done. Here you can get it if you still need this.
@ChugunovRoman

Thanks! I installed and use this tools.
But how to execute sql query via short keys?

@ChugunovRoman As i can see here short keys are not supported(or implemented), but maybe VS Code supports binding short keys for commands.

@ChugunovRoman As i can see here short keys are not supported(or implemented), but maybe VS Code supports binding short keys for commands.

there is not a command for execute a query :(

SQLTools has two commands to run a query.
First will open an input popup and you can type a query in it, but in this
case SQLTools will not be able to autocomplete and all.
Second will run a current query(.sql) file.
What do you mean by saying "execute"?
[image: image.png]
вт, 24 нояб. 2020 г. в 11:39, Roman<EMAIL_ADDRESS>
@ChugunovRoman https://github.com/ChugunovRoman As i can see here
https://vscode-sqltools.mteixeira.dev/features/executing-queries short
keys are not supported(or implemented), but maybe VS Code supports binding
short keys for commands.
there is not a command for execute a query :(
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mtxr/vscode-sqltools/issues/409#issuecomment-732715130,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKCH5H3J6B2JLL6L65LOG6LSRNPM5ANCNFSM4I7IMDRA
.


Revert ttl when request failed

Is there an existing issue that is already proposing this?

[X] I have searched the existing issues

Is your feature request related to a problem? Please describe it
I set throttle 1 request per minute. I don't want to make user wait for failed requests.
Describe the solution you'd like
Revert expirationTime when request failed (Exception occur)
Teachability, documentation, adoption, migration strategy
No response
What is the motivation / use case for changing the behavior?
apply throttle only for succeed requests.

What are the conditions for a request failing? If a request makes it all the way through an endpoint, but fails at the last step, is that a failed request? Part of rate limiting is to manage the number of interactions the server is handling at a given time, and to ensure that it can keep up. If these are slow or long running database interactions, it may not make sense to reset the number of interactions even on a failure, as they could be very resource intensive.


Need to add a sleep mod that as long as 50%? players in survival are sleeping, the night is skipped

Add feature in branch feature/skip-night. Needs testing

tested


✏ [TASK]: Review nginx port variables

Task Description

Currently there are two variables referring to upstream ports that are a little confusing:
https://github.com/UCL-MIRSG/ansible-collection-infra/blob/370891833ae00d7bfd46ba0d18ea5c416e810b95/roles/nginx/templates/nginx_reverse_proxy.j2#L14-L23
We should have a look to see if both are needed and if they are we should think of more descriptive names.
### Related Work Items

Yeah I find them confusing too. The previous variable names were:
stream {
    upstream dicom {
        server localhost:{{ xnat_dicom_port }};
    }

    server {
        listen {{ dicom_port }};
        proxy_pass dicom;
    }
}

Deprecated due to #126


Program demonstrating Constructors

Add resources not codes
Add resources like courses, certifications, roadmaps, notes, cheat sheet, etc