script exists SHA should return proper arguments

It currently returns a pointless array with returned value from the redis server:
redis.script('exists', sha, function (err, result) {
 // the result:
 // arguments { '0': null, '1': [ 1 ] }
});

What I would have expected is that result would hold the value 0 or 1 depending on what redis returned not an array where I would have to look for the first value.
Redis server responses:
SCRIPT EXISTs 1e29fabb9c911e8c38ba56a8f1135e062d39d3a4
1) (integer) 1
SCRIPT EXISTS e0e1f9fabfc9d4800c877a703b823ac0578ff8dba
1) (integer) 0

Server details:
redis_version:2.9.3
redis_git_sha1:cb598cdd
redis_git_dirty:0
arch_bits:64
multiplexing_api:kqueue

+1

This is fixed in newer versions.


Appointment endpoints

.idea should be removed for the PR and added to .gitignore

I have not found where AppointmentService is called


xmind8: Update to version 3.7.9

Closes #XXXX

Relates to #XXXX

Autoupdate missing

Although there is a trackable page (https://www.xmind.net/download/previous/), which says XMind 8 v3.7.9, we cannot assure file name (xmind-8-update9-windows.zip) and extract_dir is always in the same pattern.
Therefore, I think the better way is to accept that we have to update this package *maunally, unless we managed to track the file name by other means (e.g. a bot that downloads the file and checks version number regularly)

Therefore, I think the better way is to accept that we have to update this package *maunally, unless we managed to track the file name by other means (e.g. a bot that downloads the file and checks version number regularly)

Seems fair.
On a future note, this can be a candidate for updating via the new proposed repository UpdateTracker.

In fact, I successfully downloaded the version using https://www.xmind.net/xmind/downloads/xmind-8-update9-windows.zip, and no problems were found during the installation. At least for now, the extract_dir is still xmind 8 update 9.
In addition, you can download its latest portable version (zip) at https://www.xmind.net/download/xmind8/.
It is worth mentioning that the update frequency of this software is very slow, so maybe we don't need to update it frequently.
thank you for your reply.
发件人: Rashil @.>
发送时间: 2021年11月13日 0:38
收件人: @.>
抄送: @.>; @.>
主题: Re: [ScoopInstaller/Extras] xmind8: Update to version 3.7.9 (PR #7312)
Therefore, I think the better way is to accept that we have to update this package *maunally, unless we managed to track the file name by other means (e.g. a bot that downloads the file and checks version number regularly)
Seems fair.
On a future note, this can be a candidate for updating via the new proposed repository UpdateTracker.
―
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FScoopInstaller%2FExtras%2Fpull%2F7312%23issuecomment-967254320&data=04|01||df34f96aa1c848c3545508d9a5fad9e4|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637723319077077474|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=AB6klUPkBBmjQ3xBVJ%2F%2F7tutvBOIr%2BD6wwR4NuE3O70%3D&reserved=0, or unsubscribehttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FALJTY5OUW4ZEI7SZ7TEI73DULU7IFANCNFSM5H5EAFZA&data=04|01||df34f96aa1c848c3545508d9a5fad9e4|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637723319077087462|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=FTLmgg0lVR66A5nYzhMHMolSfz31zE04YpjJNaym6fo%3D&reserved=0.
Triage notifications on the go with GitHub Mobile for iOShttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04|01||df34f96aa1c848c3545508d9a5fad9e4|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637723319077087462|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=YYYM3k0wUQrS9%2F8WgxBUZRprYHr%2B36lxkcghDe9LJFg%3D&reserved=0 or Androidhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04|01||df34f96aa1c848c3545508d9a5fad9e4|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637723319077097452|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=Ko%2Bkkh9ZXyLPgHrVgtO5w39W5nwnVto0FFRDP%2BwfKIM%3D&reserved=0.

In fact, I successfully downloaded the version using https://www.xmind.net/xmind/downloads/xmind-8-update9-windows.zip, and no problems were found during the installation. At least for now, the extract_dir is still xmind 8 update 9.
In addition,@issaclin32, you can download its latest portable version (zip) at https://www.xmind.net/download/xmind8/.
It is worth mentioning that the update frequency of this software is very slow, so maybe we don't need to update it frequently.


Refactor Textfield to be a container with separate icon and input (ala DecoratedTextfield)

Rename DecoratedTextfield to something else to match React Spectrum's icon usage

This could end up as something like this:
<div class="spectrum-Textfield">
  <input class="spectrum-Textfield-input">
  <svg class="spectrum-Textfield-icon">
</div>

That is, all textfields have a wrapper, and all textfields can have an icon in them that is automatically positioned correctly.

It was discussed that error text should go in a surrounding label component.

Closed with https://github.com/adobe/spectrum-css/pull/537


Provided reference to union case type not recognized

Whenever a type provider emits code that uses a generated subclass of a union type, F# compiler fails to resolve it.
See https://github.com/Jand42/TP-error
Error: The module/namespace 'Microsoft.FSharp.Core.FSharpChoice`2' from compilation unit 'FSharp.Core' did not contain the namespace, module or type 'Choice1Of2'
Tested with VS2015 and VS15 Preview 4 (updated to FSharp.Core 4.1).

@Jand42 This is more or less expected - provided union types are not supported, nor are subtypes of union types supported in the F# language.


Enable fail on warning for docs

Coverage remained the same at 60.665% when pulling daeb711879317995c625b7e74bb9fe16178dc705 on jtschladen:fix-docs into 2fb595046f008e680cad78171d7c7a80953f3854 on Netflix:master.

Thanks for massive PR bringing Docs back into shape


Get XPRESS interface working again

The XPRESS interface has been minimally maintained since migrating to cvxpy 1.0. I don't think anyone has tested changes from cvxpy's 1.0 -> 1.1 upgrade.
Per a comment on #382 , a community license (suitable for running unittests with cvxpy) can be installed with pip install xpress. I installed XPRESS in this way, and ran the full suite of unittests. Upon doing this, all tests fail.
The initial cause of this failure is that the function XPRESS.apply in xpress_conif.py doesn't return anything. A correct implementation of XPRESS.apply would return the tuple (data, inv_data) already defined in that function.
Pinging @merraksh , since you mentioned volunteering to get this working again.

@merraksh has this moved at all? Let me know if you need help. We can discuss here, or perhaps over the phone / skype if you'd like.

@rileyjmurray this moved a bit. There are substantial changes to both the quadratic solver and some changes to the conic one. I'm working on the branch https://github.com/fico-xpress/cvxpy/tree/update-xpress and currently failing a few tests due to wrong solution translation (CVXPY is expecting a different value of the solution/objective value than reported).

@rileyjmurray we can discuss it here or on the phone (ping me at pietrobelotti at fico dot com); work laptop doesn't do skype (but can use Zoom). Either way I think I need to figure out how apply/invert methods work as I think those are currently incorrect in the Xpress interface.

@rileyjmurray the current fork master fails test_dqcp.py with ECOS even though I haven't touched that part of the code. Also, for some reason minimization problems with <= constraints are checked against positive dual values while the result obviously has nonpositive dual values.

@merraksh thanks for the replies! I only have experience with the conic interfaces, so I'll speak to those first.
Generally speaking, the objective value and the primal variables should be easy to map back to CVXPY. If you're encountering issues with this step, it likely means the constraints in the XPRESS problem are not being specified in a way consistent with what CVXPY intends. For LP interfaces there is usually no confusion here. To see if you are stuck at this phase or somewhere else, see my notes on testing at the end of this comment.
Dual variables are often a sticking point in solver interfaces. I'll go into those in more detail below.
Give the ideas in this comment a try. If you still encounter trouble, we can schedule a zoom call.
Dual variable signs
Often one needs to flip the sign on a solver's dual variable; this happens because of how CVXPY considers the relationship between primal and dual problems.

CVXPY begins by working with a primal-dual pair as described in Chapter 5 of https://web.stanford.edu/~boyd/cvxbook/.

Linear inequality constraints are always rewritten to a form con = (expr <= 0) for an appropriate expression expr. From there we associate a nonnegative dual variable to con.
Linear equality constraints of the form con = (expr_left == expr_right) are translated to con = (expr_left - expr_right == 0).

CVXPY takes the opposite convention when it comes to general cone constraints. If you have a constraint of the form expr in K for K as either SOC, ExpCone, or PSD, we introduce a dual variable dv and augment the Lagrangian by - cp.scalar_product(dv, expr).

These policies imply that for all constraints other than expr1 == expr2, CVXPY's dual variable will be "nonnegative" in the appropriate sense (i.e. literally nonnegative for inequality constraints, nonnegative eigenvalues for PSD constraints, etc...).
Conic dual variable assumptions
For LP models, there isn't much to dual variables other than getting the signs right. However for general conic models (SOC, ExpCone, PSD) there can be other issues. CVXPY makes assumptions about how primal cones are represented, and that ends up affecting how a dual cone needs to be represented. A common example here is a second order cone constraint. CVXPY assumes
SOC(n) = { (t, x) in R^{n+1} : ||x||_2 <= t },

which is of course different from
OtherSOC(n) = { (x,t) in R^{n+1} : ||x||_2 <= t}.

These forms are related to each other by simple transformations. If your solver interface works with OtherSOC rather than SOC, you need to account for the different convention for both primal and dual variables.
Testing advice
Pass all relevant LP tests before trying to pass tests with SOC, ExpCone, or PSD constraints.
When you're in the prototyping phase, it can be helpful to create custom tests which only check for certain functionality. For example- a test which only cares about the optimal objective and primal values. The ingredients for such a test are found in tests/solver_test_helpers.py; you can put your intermediate tests under the heading for XPRESS in tests/test_conic_solvers.py. Here is an example of a test for a second order cone program, which does not check dual variables
from solver_test_helpers import socp_1

def test_socp_1_primal(places=4):
    sth = socp_1()
    sth.solve(solver='XPRESS')
    sth.verify_objective(places)
    sth.verify_primal_values(places)
    pass

It's possible that you couldn't run the above test, if you encountered a runtime error in sth.solve(). Such runtime errors could happen if you tried to save a dual variable of an incorrect shape. If you really are only trying to test primal functionality, you could temporarily modify cvxpy/constraints/second_order.SOC.save_dual_value with a try-catch block. Of course, such a try-catch block would need to be removed before a PR, but that's easy.

@merraksh I noticed your CVXPY fork hasn't had activitiy since our last exchange of comments. Would you like to setup a call this week, so I can help in areas where you might be stuck?

@rileyjmurray I'm quite busy at the moment, but we can set up a call in a couple of weeks. I'll follow up with an invite. Thanks!

@rileyjmurray I'm available now. Sorry for the long silence. Let me know if you want to set up a call tomorrow (Friday) or next week.

@merraksh no worries. Your timing is actually quite good, since I'm just now wrapping up a fix of an incorrect (and very confusing!) naming convention in the solver interfaces. I'll probably create the PR today or tomorrow. Once that PR is merged we can setup a call.

Sounds good!

@merraksh #1020 is the PR I mentioned above.

Hi,

I can see that PR is merged. We can chat about Xpress next week if you're available.

Thanks,
Pietro

Sent: Saturday, May 09, 2020 at 3:07 AM
From: "rileyjmurray"<EMAIL_ADDRESS>To: "cvxgrp/cvxpy"<EMAIL_ADDRESS>Cc: "Pietro Belotti"<EMAIL_ADDRESS>"Mention"<EMAIL_ADDRESS>Subject: Re: [cvxgrp/cvxpy] Get XPRESS interface working again (#923)

@merraksh #1020 is the PR I mentioned above.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Next week works; I'll send you an email.

The XPRESS parameter MAXTIME is not working.

@rodfloripa Can you elaborate? Please note that, as per https://www.fico.com/fico-xpress-optimization/docs/latest/solver/optimizer/HTML/MAXTIME.html, when a feasible solution is not found, the solver stops after |MAXTIME| seconds if MAXTIME is negative. If MAXTIME is positive, the solver goes on after MAXTIME seconds until a solution is found.

I think that the cvxpy interface is not working,I have the latest cvxpy version from source(github).
That's what I tried: result = prob.solve(cp.XPRESS,verbose = True,MAXTIME=-60).  The solver didn't
stop after 60 seconds.

Is it working @rileyjmurray ?

@rodfloripa
You can check the implementation of the interface in xpress_conif.py.
There you can find a comment about the solver options:
       # Set options
        #
        # The parameter solver_opts is a dictionary that contains only
        # one key, 'solver_opt', and its value is a dictionary
        # {'control': value}, matching perfectly the format used by
        # the Xpress Python interface.

I only have two parameters,'festol' and 'bargaptarget'
Can I include 'maxtime'?
the Xpress Python interface.
    self.prob_.setControl({i: solver_opts[i] for i in solver_opts
                           if i in xp.controls.__dict__})

    if 'bargaptarget' not in solver_opts:
        self.prob_.controls.bargaptarget = 1e-30

    if 'feastol' not in solver_opts:
        self.prob_.controls.feastol = 1e-9

Ok, hard coding xpress_conif.py it worked


Fix deprecated PHP 7.4 Function ReflectionType::__toString()

Fix is what's suggested on https://www.php.net/manual/en/reflectionparameter.gettype.php
It checks for an updated interface, which should be compatible with PHP >= 7.0 as stated in composer.json
Optionally $type->getName() without instanceof check can be used, but then it will work on PHP >= 7.1.0

Fixed in 3c75937063f3e41623665ee76cc197d24fb8b414, thanks.


Fix escaping by using RFC compliant parser

By configuring the CSVReader with an RFC-compliant parser the escaping is fixed.

update opencsv dependency to version 5.9
add test

Kudos https://stackoverflow.com/questions/6008395/opencsv-in-java-ignores-backslash-in-a-field-value.
Resolves #496.

Functional review: @TobiasNx (see the notes in https://github.com/metafacture/metafacture-core/issues/496#issuecomment-2422710496 )
Code review: @blackwinter

+1

Deployed to production, closed.


s2i windows support

With this PR, unit and integration tests pass on Windows.

fixes #620

@jim-minter did you try running hack/test-stirunimage.sh  as well ?

[test]

@jim-minter the fixes comment has to be in the PR summary for it to close the issue.

@gabemontero this is now also working against hack/test-stirunimage.sh on Windows.
@bparees I believe this is now good for review.

FWIW the scripts that I'm using to build a Windows VM for testing are at https://github.com/jim-minter/packer-windows/tree/local .  I'm working on making them more consumable.  This PR works against the Windows 7 and Windows 2012R2 builds (the only two I've tried up to now).

@bparees all changes made.

lgtm, please squash

For instance, https://github.com/openshift/source-to-image/pull/625/commits/607c6d4e398c8a72f9e3bbec75f9b52a30498ba1 is interesting enough by itself to deserve its own PR and code review, testing... not sure how much that is related to "s2i Windows support".

https://github.com/openshift/source-to-image/pull/625/commits/564ecc4653acfec35aa74570bc3a8343d359b38c is another nice one that would benefit everybody, doesn't need to be blocked by the review of so many other things.

https://github.com/openshift/source-to-image/pull/625/commits/fdfa4e5fdaa7cbbd557f5bf8e110b97e124466a5 is another good candidate for it's own PR. Very good job :+1:
I would be sad to see all of those nice changes squashed into a single commit saying "s2i Windows support", when in fact many of the changes have nothing to do with Windows.

@bparees, @rhcarvalho is reluctant to see these commits squashed, I am too FWIW.

@jim-minter i agree there is some logical separation to be done, i doubt it's 17 commits though. can you factor it down to 2-3 commits (windows support, tar streaming, govet/shadowing cleanup)?  it will be easier to dig through the history/see what changed/revert things if there are fewer total commits to manage.

More & smaller commits will make my live easier when rebasing some changes I have locally for integration tests... great work here @jim-minter, appreciated.

Adding a compiled C binary hack/sigintwrap/sigintwrap.exe to support Windows/cygwin? Sounds scary to me.

rebased, but not yet ready to be considered for merge

Adding a compiled C binary hack/sigintwrap/sigintwrap.exe to support Windows/cygwin? Sounds scary to me.

@rhcarvalho Yeah.  I think it's minimal and necessary and I don't have a better alternative.  Ping me on IRC if you want to discuss the gory detail.

@bparees I'm hoping this is ready to merge now.  In conjunction with https://github.com/openshift/vagrant-openshift/pull/520, something like the following commands can be used by the CI system to stand up a Windows instance and test s2i:
set -ex

export VAGRANT_VAGRANTFILE=hack/windows/Vagrantfile
vagrant up --provider=aws
trap "vagrant destroy" EXIT
vagrant sync-sti -c -s windows
vagrant test-sti --all -d windows

@jim-minter this is excellent work I'm looking forward to seeing merged.
WRT to the sigintwrap, could we have a README.md in hack/windows/sigintwrap to explain to whoever will be looking at it:

Why we need it (Windows support using Cygwin, plus any other relevant information)
How to build it (including which environment, dependencies, ...)

As a bonus, would be nice if we could detect in CI that the source code in sigintwrap.c matches the binary.

Will do.  Actually, as part of
https://github.com/openshift/vagrant-openshift/pull/520 , the Windows
testing AMI will have everything needed to build this (just Cygwin gcc +
make), so I'll stop checking in the binary and have it built as part of
the testing.

@rhcarvalho all suggested changes pushed - thanks for the brainstorming on those test routines.  As a result I've put the ToSlashCygwin bits into util, which I think is a big improvement.  Maybe not quite as smart as what you suggested, but definitely much better.

To the extent of what I could review, LGTM. Bravo to @jim-minter!

@jim-minter just address @rhcarvalho's remaining comments on how you're logging error messages (level and format string) and then lgtm.

@bparees all done, thanks

@jim-minter @bparees I tested this branch to see if it fixed #301 (incremental builds hanging for 2min after "Done extracting tar stream"), but in fact it is making incremental builds worse, they hang for ever for me.
My recommendation would be to split the non-Windows-related changes into a separate PR that we can test further, without blocking the Windows support.
Goroutine dump from a hang (see the issue for more details on what code is being run):

I1129 10:40:41.588211    2159 tar.go:379] Creating /tmp/s2i506683693/upload/artifacts/.cabal/share/x86_64-linux-ghc-8.0.1/server-0.0/response
I1129 10:40:41.588280    2159 tar.go:389] Extracting/writing /tmp/s2i506683693/upload/artifacts/.cabal/share/x86_64-linux-ghc-8.0.1/server-0.0/response
I1129 10:40:41.588394    2159 tar.go:325] Creating directory /tmp/s2i506683693/upload/artifacts/.ghc
I1129 10:40:41.588571    2159 tar.go:325] Creating directory /tmp/s2i506683693/upload/artifacts/.ghc/x86_64-linux-8.0.1
I1129 10:40:41.588695    2159 tar.go:325] Creating directory /tmp/s2i506683693/upload/artifacts/.ghc/x86_64-linux-8.0.1/package.conf.d
I1129 10:40:41.588855    2159 tar.go:333] Creating directory /tmp/s2i506683693/upload/artifacts/.ghc/x86_64-linux-8.0.1/package.conf.d
I1129 10:40:41.588883    2159 tar.go:379] Creating /tmp/s2i506683693/upload/artifacts/.ghc/x86_64-linux-8.0.1/package.conf.d/groups-<IP_ADDRESS>-53wMJ09LBR64aEJqWveBMG.conf
I1129 10:40:41.588948    2159 tar.go:389] Extracting/writing /tmp/s2i506683693/upload/artifacts/.ghc/x86_64-linux-8.0.1/package.conf.d/groups-<IP_ADDRESS>-53wMJ09LBR64aEJqWveBMG.conf
I1129 10:40:41.589106    2159 tar.go:357] Done extracting tar stream

^\I1129 10:53:57.521299    2159 docker.go:926] Removing container "3f978659a9b321357f457edcfda75d4d20d6c73422f3cc57ad8556e1053fb271" ...
I1129 10:53:58.127071    2159 docker.go:930] Removed container "3f978659a9b321357f457edcfda75d4d20d6c73422f3cc57ad8556e1053fb271"
goroutine 44 [running]:
github.com/openshift/source-to-image/pkg/docker.(*stiDocker).RunContainer.func2(0xc15a20, 0xc4203a9b80)
        /home/rodolfo/openshift/src/github.com/openshift/source-to-image/_output/local/go/src/github.com/openshift/source-to-image/pkg/docker/docker.go:936 +0xf4
github.com/openshift/source-to-image/pkg/util/interrupt.(*Handler).signal.func1()
        /home/rodolfo/openshift/src/github.com/openshift/source-to-image/_output/local/go/src/github.com/openshift/source-to-image/pkg/util/interrupt/interrupt.go:102 +0xb5
sync.(*Once).Do(0xc420329820, 0xc4202e7f30)
        /usr/local/go/src/sync/once.go:44 +0xdb
github.com/openshift/source-to-image/pkg/util/interrupt.(*Handler).signal(0xc420329800, 0xc15a20, 0xc4203a9b80)
        /home/rodolfo/openshift/src/github.com/openshift/source-to-image/_output/local/go/src/github.com/openshift/source-to-image/pkg/util/interrupt/interrupt.go:103 +0x60
github.com/openshift/source-to-image/pkg/util/interrupt.(*Handler).Run.func1(0xc4202dd4a0, 0xc420329800)
        /home/rodolfo/openshift/src/github.com/openshift/source-to-image/_output/local/go/src/github.com/openshift/source-to-image/pkg/util/interrupt/interrupt.go:75 +0x82
created by github.com/openshift/source-to-image/pkg/util/interrupt.(*Handler).Run
        /home/rodolfo/openshift/src/github.com/openshift/source-to-image/_output/local/go/src/github.com/openshift/source-to-image/pkg/util/interrupt/interrupt.go:76 +0x103

goroutine 1 [chan receive]:
github.com/openshift/source-to-image/pkg/docker.(*stiDocker).holdHijackedConnection(0xc420302280, 0x870800, 0x0, 0x0, 0xc11d60, 0xc420098098, 0xc11d60, 0xc4200980a8, 0xc19460, 0xc420028558, ...)
        /home/rodolfo/openshift/src/github.com/openshift/source-to-image/_output/local/go/src/github.com/openshift/source-to-image/pkg/docker/docker.go:857 +0x170
github.com/openshift/source-to-image/pkg/docker.(*stiDocker).RunContainer.func3(0x0, 0x0)
        /home/rodolfo/openshift/src/github.com/openshift/source-to-image/_output/local/go/src/github.com/openshift/source-to-image/pkg/docker/docker.go:977 +0x7c4
github.com/openshift/source-to-image/pkg/util/interrupt.(*Handler).Run(0xc420329800, 0xc4201830f0, 0x0, 0x0)
        /home/rodolfo/openshift/src/github.com/openshift/source-to-image/_output/local/go/src/github.com/openshift/source-to-image/pkg/util/interrupt/interrupt.go:78 +0x133
github.com/openshift/source-to-image/pkg/docker.(*stiDocker).RunContainer(0xc420302280, 0x7fff84862674, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
        /home/rodolfo/openshift/src/github.com/openshift/source-to-image/_output/local/go/src/github.com/openshift/source-to-image/pkg/docker/docker.go:1007 +0x904
github.com/openshift/source-to-image/pkg/build/strategies/sti.(*STI).Save(0xc4202ad000, 0xc42029a000, 0x1f, 0xc4202eac80)
        /home/rodolfo/openshift/src/github.com/openshift/source-to-image/_output/local/go/src/github.com/openshift/source-to-image/pkg/build/strategies/sti/sti.go:470 +0xaa7
github.com/openshift/source-to-image/pkg/build/strategies/sti.(*STI).Build(0xc4202ad000, 0xc42029a000, 0x0, 0x0, 0x0)
        /home/rodolfo/openshift/src/github.com/openshift/source-to-image/_output/local/go/src/github.com/openshift/source-to-image/pkg/build/strategies/sti/sti.go:200 +0xd38
main.newCmdBuild.func1(0xc42008b440, 0xc4201dccc0, 0x3, 0x6)
        /home/rodolfo/openshift/src/github.com/openshift/source-to-image/_output/local/go/src/github.com/openshift/source-to-image/cmd/s2i/main.go:156 +0x75c
github.com/openshift/source-to-image/vendor/github.com/spf13/cobra.(*Command).execute(0xc42008b440, 0xc4201dcc00, 0x6, 0x6, 0xc42008b440, 0xc4201dcc00)
        /home/rodolfo/openshift/src/github.com/openshift/source-to-image/_output/local/go/src/github.com/openshift/source-to-image/vendor/github.com/spf13/cobra/command.go:603 +0x439
github.com/openshift/source-to-image/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc42008afc0, 0xc420183eb0, 0xc4202592d0, 0xc42008bd40)
        /home/rodolfo/openshift/src/github.com/openshift/source-to-image/_output/local/go/src/github.com/openshift/source-to-image/vendor/github.com/spf13/cobra/command.go:689 +0x367
github.com/openshift/source-to-image/vendor/github.com/spf13/cobra.(*Command).Execute(0xc42008afc0, 0xc420183ea8, 0x1)
        /home/rodolfo/openshift/src/github.com/openshift/source-to-image/_output/local/go/src/github.com/openshift/source-to-image/vendor/github.com/spf13/cobra/command.go:648 +0x2b
main.main()
        /home/rodolfo/openshift/src/github.com/openshift/source-to-image/_output/local/go/src/github.com/openshift/source-to-image/cmd/s2i/main.go:414 +0x660

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
        /usr/local/go/src/runtime/asm_amd64.s:2086 +0x1

goroutine 5 [chan receive]:
github.com/openshift/source-to-image/vendor/github.com/golang/glog.(*loggingT).flushDaemon(0xc2c700)
        /home/rodolfo/openshift/src/github.com/openshift/source-to-image/_output/local/go/src/github.com/openshift/source-to-image/vendor/github.com/golang/glog/glog.go:882 +0x7a
created by github.com/openshift/source-to-image/vendor/github.com/golang/glog.init.1
        /home/rodolfo/openshift/src/github.com/openshift/source-to-image/_output/local/go/src/github.com/openshift/source-to-image/vendor/github.com/golang/glog/glog.go:410 +0x21d

goroutine 6 [syscall]:
os/signal.signal_recv(0xc15a20)
        /usr/local/go/src/runtime/sigqueue.go:116 +0x157
os/signal.loop()
        /usr/local/go/src/os/signal/signal_unix.go:22 +0x22
created by os/signal.init.1
        /usr/local/go/src/os/signal/signal_unix.go:28 +0x41

goroutine 9 [IO wait]:
net.runtime_pollWait(0x7fed21ea02a0, 0x72, 0x3)
        /usr/local/go/src/runtime/netpoll.go:160 +0x59
net.(*pollDesc).wait(0xc420292fb0, 0x72, 0xc4200349d0, 0xc420012068)
        /usr/local/go/src/net/fd_poll_runtime.go:73 +0x38
net.(*pollDesc).waitRead(0xc420292fb0, 0xc13ba0, 0xc420012068)
        /usr/local/go/src/net/fd_poll_runtime.go:78 +0x34
net.(*netFD).Read(0xc420292f50, 0xc4202a2000, 0x1000, 0x1000, 0x0, 0xc13ba0, 0xc420012068)
        /usr/local/go/src/net/fd_unix.go:243 +0x1a1
net.(*conn).Read(0xc4200283f8, 0xc4202a2000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
        /usr/local/go/src/net/net.go:173 +0x70
net/http.(*persistConn).Read(0xc420296400, 0xc4202a2000, 0x1000, 0x1000, 0x638df0, 0xc420034b58, 0x4099fd)
        /usr/local/go/src/net/http/transport.go:1261 +0x154
bufio.(*Reader).fill(0xc4201dd320)
        /usr/local/go/src/bufio/bufio.go:97 +0x10c
bufio.(*Reader).Peek(0xc4201dd320, 0x1, 0xc420034bbd, 0x1, 0x0, 0xc4201dd800, 0x0)
        /usr/local/go/src/bufio/bufio.go:129 +0x62
net/http.(*persistConn).readLoop(0xc420296400)
        /usr/local/go/src/net/http/transport.go:1418 +0x1a1
created by net/http.(*Transport).dialConn
        /usr/local/go/src/net/http/transport.go:1062 +0x4e9

goroutine 10 [select]:
net/http.(*persistConn).writeLoop(0xc420296400)
        /usr/local/go/src/net/http/transport.go:1646 +0x3bd
created by net/http.(*Transport).dialConn
        /usr/local/go/src/net/http/transport.go:1063 +0x50e

goroutine 43 [select, locked to thread]:
runtime.gopark(0x871248, 0x0, 0x833662, 0x6, 0x18, 0x2)
        /usr/local/go/src/runtime/proc.go:259 +0x13a
runtime.selectgoImpl(0xc4202d8f30, 0x0, 0x18)
        /usr/local/go/src/runtime/select.go:423 +0x11d9
runtime.selectgo(0xc4202d8f30)
        /usr/local/go/src/runtime/select.go:238 +0x1c
runtime.ensureSigM.func1()
        /usr/local/go/src/runtime/signal1_unix.go:304 +0x2f3
runtime.goexit()
        /usr/local/go/src/runtime/asm_amd64.s:2086 +0x1

goroutine 16 [IO wait]:
net.runtime_pollWait(0x7fed21ea01e0, 0x72, 0x5)
        /usr/local/go/src/runtime/netpoll.go:160 +0x59
net.(*pollDesc).wait(0xc4202935d0, 0x72, 0xc42003b9d0, 0xc420012068)
        /usr/local/go/src/net/fd_poll_runtime.go:73 +0x38
net.(*pollDesc).waitRead(0xc4202935d0, 0xc13ba0, 0xc420012068)
        /usr/local/go/src/net/fd_poll_runtime.go:78 +0x34
net.(*netFD).Read(0xc420293570, 0xc4202de000, 0x1000, 0x1000, 0x0, 0xc13ba0, 0xc420012068)
        /usr/local/go/src/net/fd_unix.go:243 +0x1a1
net.(*conn).Read(0xc420028450, 0xc4202de000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
        /usr/local/go/src/net/net.go:173 +0x70
net/http.(*persistConn).Read(0xc420296500, 0xc4202de000, 0x1000, 0x1000, 0x638df0, 0xc42003bb58, 0x4099fd)
        /usr/local/go/src/net/http/transport.go:1261 +0x154
bufio.(*Reader).fill(0xc4202dc120)
        /usr/local/go/src/bufio/bufio.go:97 +0x10c
bufio.(*Reader).Peek(0xc4202dc120, 0x1, 0xc42003bbbd, 0x1, 0x0, 0xc4202dc180, 0x0)
        /usr/local/go/src/bufio/bufio.go:129 +0x62
net/http.(*persistConn).readLoop(0xc420296500)
        /usr/local/go/src/net/http/transport.go:1418 +0x1a1
created by net/http.(*Transport).dialConn
        /usr/local/go/src/net/http/transport.go:1062 +0x4e9

goroutine 34 [select]:
net/http.(*persistConn).writeLoop(0xc420296500)
        /usr/local/go/src/net/http/transport.go:1646 +0x3bd
created by net/http.(*Transport).dialConn
        /usr/local/go/src/net/http/transport.go:1063 +0x50e

goroutine 53 [semacquire]:
sync.runtime_notifyListWait(0xc4203061c0, 0x0)
        /usr/local/go/src/runtime/sema.go:267 +0x122
sync.(*Cond).Wait(0xc4203061b0)
        /usr/local/go/src/sync/cond.go:57 +0x80
io.(*pipe).read(0xc420306180, 0xc42037c000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
        /usr/local/go/src/io/pipe.go:47 +0x102
io.(*PipeReader).Read(0xc4200980a0, 0xc42037c000, 0x1000, 0x1000, 0x43f91a, 0xc4202d4728, 0x2)
        /usr/local/go/src/io/pipe.go:129 +0x4c
bufio.(*Reader).fill(0xc4202d46d8)
        /usr/local/go/src/bufio/bufio.go:97 +0x10c
bufio.(*Reader).ReadSlice(0xc4202d46d8, 0xa, 0x2b, 0x7fed21e53320, 0x4547a0, 0x7fed21ef3960, 0x2b)
        /usr/local/go/src/bufio/bufio.go:330 +0xb5
bufio.(*Reader).ReadBytes(0xc4202d46d8, 0x7a370a, 0x1, 0xc42037c000, 0x2, 0x2, 0xc4202d4788)
        /usr/local/go/src/bufio/bufio.go:408 +0x66
bufio.(*Reader).ReadString(0xc4202d46d8, 0x100a, 0x1000, 0xc42037c000, 0x1000, 0x1000)
        /usr/local/go/src/bufio/bufio.go:448 +0x38
github.com/openshift/source-to-image/pkg/docker.StreamContainerIO.func1(0xc11d20, 0xc4200980a0, 0x870828, 0x0, 0xc42035e660)
        /home/rodolfo/openshift/src/github.com/openshift/source-to-image/_output/local/go/src/github.com/openshift/source-to-image/pkg/docker/util.go:167 +0xa8
created by github.com/openshift/source-to-image/pkg/docker.StreamContainerIO
        /home/rodolfo/openshift/src/github.com/openshift/source-to-image/_output/local/go/src/github.com/openshift/source-to-image/pkg/docker/util.go:182 +0x89

goroutine 22 [IO wait]:
net.runtime_pollWait(0x7fed21ea0120, 0x72, 0x6)
        /usr/local/go/src/runtime/netpoll.go:160 +0x59
net.(*pollDesc).wait(0xc4202f0220, 0x72, 0xc4200359d0, 0xc420012068)
        /usr/local/go/src/net/fd_poll_runtime.go:73 +0x38
net.(*pollDesc).waitRead(0xc4202f0220, 0xc13ba0, 0xc420012068)
        /usr/local/go/src/net/fd_poll_runtime.go:78 +0x34
net.(*netFD).Read(0xc4202f01c0, 0xc42030a000, 0x1000, 0x1000, 0x0, 0xc13ba0, 0xc420012068)
        /usr/local/go/src/net/fd_unix.go:243 +0x1a1
net.(*conn).Read(0xc420098038, 0xc42030a000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
        /usr/local/go/src/net/net.go:173 +0x70
net/http.(*persistConn).Read(0xc42006a400, 0xc42030a000, 0x1000, 0x1000, 0x638df0, 0xc420035b58, 0x4099fd)
        /usr/local/go/src/net/http/transport.go:1261 +0x154
bufio.(*Reader).fill(0xc4200926c0)
        /usr/local/go/src/bufio/bufio.go:97 +0x10c
bufio.(*Reader).Peek(0xc4200926c0, 0x1, 0xc420035bbd, 0x1, 0x0, 0xc4202dc660, 0x0)
        /usr/local/go/src/bufio/bufio.go:129 +0x62
net/http.(*persistConn).readLoop(0xc42006a400)
        /usr/local/go/src/net/http/transport.go:1418 +0x1a1
created by net/http.(*Transport).dialConn
        /usr/local/go/src/net/http/transport.go:1062 +0x4e9

goroutine 23 [select]:
net/http.(*persistConn).writeLoop(0xc42006a400)
        /usr/local/go/src/net/http/transport.go:1646 +0x3bd
created by net/http.(*Transport).dialConn
        /usr/local/go/src/net/http/transport.go:1063 +0x50e

goroutine 27 [IO wait]:
net.runtime_pollWait(0x7fed21ea0060, 0x72, 0x7)
        /usr/local/go/src/runtime/netpoll.go:160 +0x59
net.(*pollDesc).wait(0xc4202f0450, 0x72, 0xc4200379d0, 0xc420012068)
        /usr/local/go/src/net/fd_poll_runtime.go:73 +0x38
net.(*pollDesc).waitRead(0xc4202f0450, 0xc13ba0, 0xc420012068)
        /usr/local/go/src/net/fd_poll_runtime.go:78 +0x34
net.(*netFD).Read(0xc4202f03f0, 0xc420318000, 0x1000, 0x1000, 0x0, 0xc13ba0, 0xc420012068)
        /usr/local/go/src/net/fd_unix.go:243 +0x1a1
net.(*conn).Read(0xc420098080, 0xc420318000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
        /usr/local/go/src/net/net.go:173 +0x70
net/http.(*persistConn).Read(0xc42006a500, 0xc420318000, 0x1000, 0x1000, 0x30, 0xc420037b58, 0x43ea0c)
        /usr/local/go/src/net/http/transport.go:1261 +0x154
bufio.(*Reader).fill(0xc4200930e0)
        /usr/local/go/src/bufio/bufio.go:97 +0x10c
bufio.(*Reader).Peek(0xc4200930e0, 0x1, 0x0, 0x1, 0x0, 0xc420417440, 0x0)
        /usr/local/go/src/bufio/bufio.go:129 +0x62
net/http.(*persistConn).readLoop(0xc42006a500)
        /usr/local/go/src/net/http/transport.go:1418 +0x1a1
created by net/http.(*Transport).dialConn
        /usr/local/go/src/net/http/transport.go:1062 +0x4e9

goroutine 28 [select]:
net/http.(*persistConn).writeLoop(0xc42006a500)
        /usr/local/go/src/net/http/transport.go:1646 +0x3bd
created by net/http.(*Transport).dialConn
        /usr/local/go/src/net/http/transport.go:1063 +0x50e

goroutine 40 [IO wait]:
net.runtime_pollWait(0x7fed21e9ffa0, 0x72, 0x8)
        /usr/local/go/src/runtime/netpoll.go:160 +0x59
net.(*pollDesc).wait(0xc4203206f0, 0x72, 0xc4202e59d0, 0xc420012068)
        /usr/local/go/src/net/fd_poll_runtime.go:73 +0x38
net.(*pollDesc).waitRead(0xc4203206f0, 0xc13ba0, 0xc420012068)
        /usr/local/go/src/net/fd_poll_runtime.go:78 +0x34
net.(*netFD).Read(0xc420320690, 0xc42034c000, 0x1000, 0x1000, 0x0, 0xc13ba0, 0xc420012068)
        /usr/local/go/src/net/fd_unix.go:243 +0x1a1
net.(*conn).Read(0xc420028540, 0xc42034c000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
        /usr/local/go/src/net/net.go:173 +0x70
net/http.(*persistConn).Read(0xc420296600, 0xc42034c000, 0x1000, 0x1000, 0x638df0, 0xc4202e5b58, 0x4099fd)
        /usr/local/go/src/net/http/transport.go:1261 +0x154
bufio.(*Reader).fill(0xc4202dd260)
        /usr/local/go/src/bufio/bufio.go:97 +0x10c
bufio.(*Reader).Peek(0xc4202dd260, 0x1, 0xc4202e5bbd, 0x1, 0x0, 0xc42035e360, 0x0)
        /usr/local/go/src/bufio/bufio.go:129 +0x62
net/http.(*persistConn).readLoop(0xc420296600)
        /usr/local/go/src/net/http/transport.go:1418 +0x1a1
created by net/http.(*Transport).dialConn
        /usr/local/go/src/net/http/transport.go:1062 +0x4e9

goroutine 41 [select]:
net/http.(*persistConn).writeLoop(0xc420296600)
        /usr/local/go/src/net/http/transport.go:1646 +0x3bd
created by net/http.(*Transport).dialConn
        /usr/local/go/src/net/http/transport.go:1063 +0x50e

goroutine 59 [semacquire]:
sync.runtime_notifyListWait(0xc420306138, 0xc400000246)
        /usr/local/go/src/runtime/sema.go:267 +0x122
sync.(*Cond).Wait(0xc420306128)
        /usr/local/go/src/sync/cond.go:57 +0x80
io.(*pipe).write(0xc4203060c0, 0xc4203cc008, 0x8000, 0x8001, 0x0, 0x0, 0x0)
        /usr/local/go/src/io/pipe.go:89 +0x191
io.(*PipeWriter).Write(0xc420098098, 0xc4203cc008, 0x8000, 0x8001, 0x1, 0x0, 0x0)
        /usr/local/go/src/io/pipe.go:156 +0x4c
github.com/openshift/source-to-image/vendor/github.com/docker/docker/pkg/stdcopy.StdCopy(0xc11d60, 0xc420098098, 0xc11d60, 0xc4200980a8, 0xc11060, 0xc4202dd860, 0x0, 0x0, 0x0)
        /home/rodolfo/openshift/src/github.com/openshift/source-to-image/_output/local/go/src/github.com/openshift/source-to-image/vendor/github.com/docker/docker/pkg/stdcopy/stdcopy.go:161 +0x429
github.com/openshift/source-to-image/pkg/docker.(*stiDocker).redirectResponseToOutputStream(0xc420302280, 0x0, 0xc11d60, 0xc420098098, 0xc11d60, 0xc4200980a8, 0xc11060, 0xc4202dd860, 0x0, 0x0)
        /home/rodolfo/openshift/src/github.com/openshift/source-to-image/_output/local/go/src/github.com/openshift/source-to-image/pkg/docker/docker.go:826 +0xd2
github.com/openshift/source-to-image/pkg/docker.(*stiDocker).holdHijackedConnection.func1(0xc42035f0e0, 0xc420302280, 0x7cad00, 0xc11d60, 0xc420098098, 0xc11d60, 0xc4200980a8, 0xc42039cd00)
        /home/rodolfo/openshift/src/github.com/openshift/source-to-image/_output/local/go/src/github.com/openshift/source-to-image/pkg/docker/docker.go:839 +0x8c
created by github.com/openshift/source-to-image/pkg/docker.(*stiDocker).holdHijackedConnection
        /home/rodolfo/openshift/src/github.com/openshift/source-to-image/_output/local/go/src/github.com/openshift/source-to-image/pkg/docker/docker.go:840 +0x10c
+ docker run --name test -d -p 8080:8080 -u 1001 test
/usr/bin/docker-current: Error response from daemon: Conflict. The name "/test" is already in use by container b4ccdd34918f05586ff580e4b8684c76a77bca04d625c102aaad0c7419ee1853. You have to remove (or rename) that container to be able to reuse that name..
See '/usr/bin/docker-current run --help'.
+ sleep 0.01
+ curl -sS localhost:8080
+ grep -q Welcome
curl: (7) Failed to connect to localhost port 8080: Connection refused
+ echo '  * create app FAILED'
  * create app FAILED
+ exit 1

(FWIW, I haven't had time to analyze the goroutine dump)

@jim-minter @bparees I tested this branch to see if it fixed #301 (incremental builds hanging for 2min after "Done extracting tar stream"), but in fact it is making incremental builds worse, they hang for ever for me.

are there no incremental build tests in our bucket?  we need to fix that.

are there no incremental build tests in our bucket? we need to fix that.

IIRC there are, but they don't capture the problem.

@bparees ready to go

@bparees your 2 additional changes pushed

[merge]


Does not zoom towards mouse pointer with hbox/wbox

Hi, I stumbled upon some weird zooming behavior which might be a bug. Consider
using Makie
Nx, Ny = 10, 15
X = LinRange(-1,1, Nx)
Y = LinRange(-1,1, Ny)

s1 = surface(X, Y, X .+ Y')
s2 = surface(X, Y, X .* Y')
hbox(s1,s2) |> display

When I use the mouse to zoom on the lower pane (s1), it zooms towards the mouse pointer, but in the upper pane (s2), it zooms towards a point lying above the plot window. Likewise, using vbox instead, the rightmost plot (s2) zooms towards a point right of the plot window.
I’m on a mac if that makes a difference.

I see what you are saying. The zooms are distinctly different. It's worth noting that the zoom of the top figure does seem to be affected by where the mouse is, just not to the same extent as the bottom figure.

Ah, I guess I'm missing to normalize the mouse position to the window rectangle somewhere^^

Seems to be fixed


#10266 (Hana) Public Synonyms

I had multiple issues with Hana around public synonyms and the case did spread a bit into the Generic* package.
The starting point was the following: Hana supports synonyms and public synonyms. Public synonyms are used a lot for data dictionary, e.g. PUBLIC.TABLES points to SYS.TABLES. A normal synonyms are used often for cross schema access.
Examples:
1 select * from PUBLIC.TABLES; (schema + synonym)
2 select * from SYS.TABLES; (schema + table/view)
3 select * from TABLES; (public synonym)
4 select * from MYSCHEMA.TABLE1; (schema + table/view)
5 select * from TABLE1; (table/view in selectedschema)
6 select * from MYSCHEMA.REMOTETABLE1; (schema + synonym)
7 select * from REMOTETABLE1; (synonym in selectedschema)
For all these cases

auto complete
column binding (when executing the query);

must work.
When testing only case 2), 4) and 5) did work, and these are the ones where neither a local nor a public synonym had been involved.
The first required change was to add an indication what the public schema is. When a query without a schema is executed, the logic tries to find the table in the selected schema and if not found, must now try for public synonyms. So we must know what schema the public synonym is.
For that I followed the isVirtual() approach and added an interface DBSPublicSynonymSchema and GenericSchema implements it.
Next is the getChildren() and getChild(). They return the TableCache only but must return synonyms as well. Hence I modified the GenericObjectContainer. Problem is, the variables tableCache and synonyms are different. In Oracle a SynonymCache class was added. Instead I changed the synonyms from ArrayList to Map (sorted). This is sort of a poor man's cache. If an ArrayList is fine, a simple Map should be as well.
Finally I had to modify the autocomplete code in certain points to support the missing 4 combinations from above list of seven queries.
One thing I did not however: When a object name without a schema is typed, e.g. "select * from tab..." I do not add the public synonyms to the list. It depends on the persona. An administrator will hate to be forced typing "select * from public.tab..." because he is using these mostly. A normal developer would hate to get the 2000 synonyms shown, all with generic names, instead of the objects in his schema. I decided to focus on the latter persona.
Regarding side effects, I have tested as much as I can. Hana builds on the Generic classes so does SQL Server and two more. As they do not add a public synonym schema (yet), there shouldn't be a negative side effect. Does any of these databases even support public synonyms? For local synonyms it depends on how those database supporting those (SQL Server only) behave. It might actually be that they lack from the same issue as Hana did with synonyms and then this PR would allow the same enhancement there as well.

We have similar issues with Oracle public synonyms.
I need to explore it a bit more.

Hmmmm. Yes and No. I have made changes in the Generic* classes but the Oracle classes are not using those. There you use your own classes, implementing the interfaces directly.
Hence I would assume these two solutions do not share anything and there is no "global" solution solving both at once.
The root cause are the getChildren()/getChild() methods in the interface definition. Everybody can implement whatever he wants there. For a proper solution we would need to remove those and have methods like

getTable()
getView()
getSynonym()
getPublicSynonym()
getFromCandidate() .... which is the union of above

Looking forward to hear how close to reality I came with my statement. ;-)

I need to review it after 8.0 release. Too major code impact and we'll probably change synonyms model by that time.

I need to review it after 8.0 release. Too major code impact and we'll probably change synonyms model by that time.

So. Based on your code, another PR was created. https://github.com/dbeaver/dbeaver/pull/11825
Fix will be available in version 21.0.2  [April 05, 2021]
The main tasks for synonyms in autocompletion were solved.
And also synonyms were added to the list of DB Metadata Search.
Thank you for your contribution!


Fix more problems with zero width things.

This should close #757. It should also allow for stop() and printf() to be used with zero-width fields.

I have no merge powers, so if there's no more feedback someone else should merge this when they get around to it.

Jack and Adam aren't around today. Let me know how urgent it is because I think I have merge powers


Update README with local usage

Closes #36

Closing in favor of https://github.com/widefix/actual_db_schema/pull/51
Thanks for your contribution @mikitsik !


Protocol and profile versions are not float

The FitFile.protocol_version, profile_version are just strings "major.minor" (i.e. "int dot int" format), not floats. Floats are inaccurate representations.
I propose to create a custom class FitVersion with fields major, minor and __str__ func with proper formatting. And maybe magic functions for comparison (__eq__, __gt__, ...).  Can make a PR for that.

PR to address this here: https://github.com/dtcooper/python-fitparse/pull/135


Default document not served when directory name contains a period.

If the directory name contains a period ".",  when accessing that directory not served default document (index.html).

/dot.dir/index.html is works fine.
/dot.dir/ is 404.

https://gentle-sand-0f46f010f.azurestaticapps.net/
Also, I cannot find a document with a filename that can be used as the default document.

Hi @takekazuomi, thanks for reporting this! We will take a look. As for right now we always look for index.html as our default document. It is not currently configurable.

This should be fixed now. Please let us know if the issue persists.

It works fine now. Thank You for your great job.


Added .idea/ to VisualStudio.gitignore

Reasons for making this change:
Added folder .idea which is created by the JetBrains Rider IDE for .NET projects.
See https://rider-support.jetbrains.com/hc/en-us/articles/207097529-What-is-the-idea-folder-

در تاریخ سه‌شنبه ۱۹ آوریل ۲۰۲۲، ۲۱:۲۸ Alexander Batishchev <
@.***> نوشت:

Reasons for making this change:
Added folder .idea which is created by the JetBrains Rider IDE for .NET
projects.
See
https://rider-support.jetbrains.com/hc/en-us/articles/207097529-What-is-the-idea-folder-
You can view, comment on, or merge this pull request online at:
https://github.com/github/gitignore/pull/4043
Commit Summary

43135ef
https://github.com/github/gitignore/pull/4043/commits/43135ef3caebd932bb6ce0ce5c260711989e7343
Added .idea/ to VisualStudio.gitignore

File Changes
(1 file https://github.com/github/gitignore/pull/4043/files)

M VisualStudio.gitignore
https://github.com/github/gitignore/pull/4043/files#diff-342878122d2254a439602361da4b6c0cfaf01ce7c3c87c1f40b2ba438c01e957
(1)

Patch Links:

https://github.com/github/gitignore/pull/4043.patch
https://github.com/github/gitignore/pull/4043.diff

—
Reply to this email directly, view it on GitHub
https://github.com/github/gitignore/pull/4043, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AYZFZ75FWNCM6KNKAIEPB43VF3Q4ZANCNFSM5TZOMLJQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Hello?

Bump.

Bump


Feature request: faster GridsearchCV with XGBoost

XGBoost constructs a DMatrix object from the input X, y data it
receives. On its first time calling train with this DMatrix, it
caches statistics (histograms) about each column in the DMatrix. For
wide datasets, computing these stats can be very
time-consuming. Running one example grid search with a 1000-column
matrix (x 100k rows), using GridsearchCV was 2.8x longer than building
a DMatrix once manually for each fold and calling xgboost.train in a
loop. Profiling shows that the time goes to both DMatrix building and
stats computation.
GridsearchCV CV caching essentially works with pandas or numpy-style
objects with separate X and y. DMatrix includes both X and y in the
same object, so it needs a slight hack to fit into the current framework.
One option is to allow users to supply a custom replacement for the
_extract method in methods.py. For XGBoost, a user would supply something like:
    def _extract_dmatrix(self, X, y, n, is_x=True, is_train=True):
        if self.cache is not None and (n, is_x, is_train) in self.cache:
            return self.cache[n, is_x, is_train]
        if not is_x:
            return None

        inds = self.splits[n][0] if is_train else self.splits[n][1]
        x_part = _safe_indexing(X, inds)
        y_part = _safe_indexing(y, inds)

        import xgboost as xgb
        # TODO: in practice, there may be additional params like weights
        result = xgb.DMatrix(x_part, y_part)
        print("Converted to dmatrix for cache with _extract_dmatrix")

        if self.cache is not None:
            self.cache[n, is_x, is_train] = result
        return result

This returns None for the y and a DMatrix with X and y with is_x, so
it is abusing the interface a bit, though it seem to work. Note that
this also requires a custom XGBoost wrapper with a fit method
accepting a DMatrix, but that is very short.
Thoughts? Better ways to do this and cache DMatrix objects? Thanks!
This relates to Issue #443, which is also looking for advice on XGBoost gridsearch.
Tagging @trivialfis for possible better ideas...

That will clean up the sklearn/xgboost side nicely, but right now dask ml can't support a dmatrix earlier in the pipeline for caching. In the PoC I posted, I think it would eliminate the ugly XGBoostWrapper but not the caching changes.

Let me take a look into dask ml s implementation.

XGBoost is an important case, and if something simple enough can be done to support it, then that might be possible.  It's a bit of a trade off with special-casing, but certainly worth investigating.
Alternatively, we might expand this request and add some generality.  Right now the logic for hyper-parameter optimization is fairly tied to Numpy-style slicing.  This is great if you're using Numpy, but can introduce challenges if you're using anything else like Pandas, RAPIDS, CuPy, XGBoost, or whatever comes next.  We might consider looking into what a minimal set of pluggable operations would look like that would allow for supporting any of these systems.
If we can easily separate the cross validation and hyper-parameter selection logic from the slicing logic then that would probably make it easy for other teams to add support for additional libraries somewhat cleanly, and in a way that optimized performance for that library.
Naively this seems doable, but I don't have much recent exposure to this codebase.  cc'ing@TomAugspurger @stsievert , who might know more.

Consider also the case where you need a non-standard CV split, like a time-based split for series data. Allowing a user-provided splitter (that can populate the cache) would allow all of those weird cases without having to implement them natively.

I will try to improve the scikit learn interface so users don't have to construct the DMatrix.
For performance, wouldn't caching all this splited matrices blow up GPU memory?
Lastly as we are refactoring the DMatrix, it will only contain the sketches in the future, so for splitting dataset, relying on cudf/cupy is the better way to go.  No need to place specialized code for DMatrix in dask.

@trivialfis what can we do to cache the sketches from run to run on the same data if the dmatrix is not reused?

Hi, @TomAugspurger - I'm wondering if you have any thoughts on generalizing the caching API to allow custom user splitter functions to support non-numpy-style caching items.  Thanks!

Apologies for the delay, I'm a bit busy with pandas things currently. Will
take some time to digest this later in the week.
On Wed, Feb 5, 2020 at 8:32 AM John Zedlewski<EMAIL_ADDRESS>wrote:

Hi, @TomAugspurger https://github.com/TomAugspurger - I'm wondering if
you have any thoughts on generalizing the caching API to allow custom user
splitter functions to support non-numpy-style caching items.  Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dask/dask-ml/issues/605?email_source=notifications&email_token=AAKAOIXGAFNXPHLLYSI3JVLRBLEXPA5CNFSM4KN4NNZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEK3UETA#issuecomment-582435404,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAKAOIUXWIZA7CDYMGZ7ZTTRBLEXPANCNFSM4KN4NNZQ
.

Allowing a user-provided splitter (that can populate the cache) would allow all of those weird cases without having to implement them natively

So to be clear you're now suggesting not that we allow pluggable _extract functions, but that we allow for user-defined splitting objects.  Is this the same as the cv= input or is it something different?  (Please excuse my ignorance here, I haven't logged a ton of time looking at the internals here).

So I wonder if we might be able to do something like the following:
from sklearn.model_selection._split import StratifiedKFold

class XGBoostStratifiedKFold(StratifiedKFold):
    def split(self, X, y):
        ... # custom code

search = dask_ml.model_selection.GridSearchCV(cv=XGBoostStatifiedKFold())

Or something like that
If that works then maybe we could also build a few of these out in dask-ml and dispatch on them based on the input type of X?  (we do similar dispatching in dask.dataframe and dask.array)

Sorry for being slow here.  Let me try to summarize the problem here and please correct me if I'm wrong.  The problem is, we want to have a cache managed by dask, but  for user defined types.  Is this correct?  I think we encountered something similar before as we want a place to store the concatenated partitions in each worker.  So is it possible to design such a data independent cache in dask?

I don't think that core Dask will ever manage any sort of cache.  That's probably out of scope.  XGBoost seems to already cache histograms on the DMatrix objects though, so that should be fine.  Things would be ok if we can make it so that dask-ml is comfortable consuming DMatrix objects.  But this would be incredible scope creep in the library, so instead we're looking into how we can make things pluggable, so that we can easily extend support for different input types.
@JohnZed is this also where your head is?

on generalizing the caching API

I thought there's a caching API (like an API one can use the cache stuffs ... ).  Apologies...

@mrocklin - I wrote sloppily when I said custom splitters, sorry about that. The custom extract is what is needed. GridsearchCV already takes a custom cv parameter that can yield a custom splitting strategy. However, the _extract method in methods.py assumes numpy-style indexing where X and y are to be cached separately. (This is the part that interacts poorly with dmatrix, the splitting strategy is fine.)
So I think a custom extractor that returns a custom-extracted object (as in the PoC) is not too intrusive but provides reasonable user experience with an understandable API. And it would use exactly the cache mechanism that lives in dask-ml gridsearch now, just caching a user-returned object like custom_extract_fn(X, y, indices) rather than the result of safe_indexing(X, indices)

I'm against the idea of making the _extract method in particular dispatchable, just because it is buried so deeply within a bunch of different systems.

User calls GridSearchCV
That calls build_graph_cv
That uses the cv_split function in a graph
Which does one check, and then creates a CVCache object
Which calls extract
Which calls _extract # <--- the thing you want to change

Making a contract around _extract seems unwise, given all of the internal details around it.  We should probably attempt to avoid making really deep systems like this when we can, just because it makes things hard to generalize and modify in the future.
It seems like we might be able to remove the cv_split function entirely, and use the CVCache class instead (perhaps moving the checking within the constructor)
https://github.com/dask/dask-ml/blob/ff1b0af3af25080b12dd2f194d041db489505463/dask_ml/model_selection/methods.py#L156-L158
And then we accept a CVCache class as an optional input?  That's only about one step away from the user, and they can modify a bunch of stuff if they want to, not just this one part of it.  We're adding more systemic flexibility than a patch for one use case.
However if we do this then we're expanding the API contract around caching, so now someone would need to think somewhat hard about what the possible use cases for this might be, and make sure that the API we're publishing is unlikely to make any of those future use cases difficult.
To be clear, I'm not green-lighting anything (I don't have enough on-the-ground ML experience to do that confidently).  I'm just trying to give a sense of what things look like to me at the moment.


DNM: repro failing pg_regress

https://github.com/neondatabase/neon/pull/8105#issuecomment-2178342259

Ok, finally got a run done. debug is 8x slower 🤯

https://github.com/neondatabase/neon/pull/8105#issuecomment-2180278013

Closing this, I'm going to merge the underlying PR


Font Size Table Size

From<EMAIL_ADDRESS>on August 13, 2014 10:39:30
Hello just some simple suggestions
Would be nice if u could allow changing of font size and/or
allow users to enlarge view.
Am using it to print out table r/s , its kinda small.
Great program by the way :)
Original issue: http://code.google.com/p/wwwsqldesigner/issues/detail?id=183

From ondrej.zara on August 25, 2014 02:35:01
Hi,
you are free to adjust the font size using custom CSS. There is not fixed font size specified; the app inherits its button look from your browser/operating system. Feel free to add your (print-specific) stylesheet with better styling that suits your needs.
Status: Done


Release channel UI

It is not currently clear how to determine what the stable / nightly versions are, and what features / bug fixes they include.
We should expose a UI (perhaps a web interface at releases.flynn.io) which shows the following:

the current stable / nightly version
a changelog containing features / bug fixes which are included in a release since the last version (perhaps a list of pull requests)

The changelog would require us to track historic versions of a channel (we currently just store the current channel version) so we could determine the changes since the last version on that channel.
We could take this a step further and have a bot which adds comments to GitHub pull requests when they are released to the stable / nightly channel, so anyone landing on a PR knows the relevant versions they need to benefit from the change.
As an FYI, here is how I currently determine the current stable / nightly version using tuf-client (requires golang to install):
$ go get github.com/flynn/go-tuf/cmd/tuf-client

$ tuf-client init https://dl.flynn.io/tuf <<< '[{"keytype":"ed25519","keyval":{"public":"6cfda23aa48f530aebd5b9c01030d06d02f25876b5508d681675270027af4731"}}]'

$ tuf-client get https://dl.flynn.io/tuf /channels/stable
v20160512.0

$ tuf-client get https://dl.flynn.io/tuf /channels/nightly
v20160519.0

A first pass at the UI is available at https://releases.flynn.io.
Some work is needed on the design (I am no designer :smile:) but the relevant information is all there.
The source is available at https://github.com/flynn/flynn-releases.

Oh and you can get the same information as JSON from https://releases.flynn.io/api/channels

That is awesome. 👍


Feature/22 support filtering

Description

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[ ] I have signed the Adobe Open Source CLA.
[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Not sure how extensible this is
the filter method has a reasonably simple signature ATM, should be easy to extend that further in the future (potentially with static methods alaGraphQlQueryBuilder.xxx() to pass in more complicated filters
support for expressions like (num > 2 AND num < 5)
this is already supported
Not all Operators can be used with all data types...
yes, client validation of this is impossible without loading the schema to the client and checking before executing a query. Overall I'd think this will happen mostly during development time, therefore fine to check on server.
We don't have support for specifying logical operators (AND, OR) - maybe not a must have for the first iteration?
Yes, AND-only for now (but I also think OR is rarely needed, and then there is always the possibility to either hand-craft or use a persisted query)
Defining a filter per field looks nice, but might be a limiting factor if we support more filter features.
I'd leave it in as shortcut for simple cases, more advanced cases should be done by "dedicated top-level filter calls"
I didn't have the time to check myself, but: Are filters on nested fields handled correctly? Or do we only support filters on top-level fields?
ATM only top-level fields to start with

We also have other options than IGNORE_CASE, for example _sensitiveness for the comparison of double values.
this is actually not ideal at the moment, IGNORE_CASE currently does not take a value ("auto-sets to true"), but _sensitiveness does take a value, so I have to refactor this a little bit.


blobs of diego 2.1.0

Hi, at the https://github.com/cloudfoundry/diego-release/blob/v2.1.0/config/blobs.yml
I read:
proxy/envoy-0e1d66377d9bf8b8304b65df56a4c88fc01e87e8.tgz
AND
tar/tar-1503683828.tgz.
I need to download their source code; could you please tell me the download location of both of them or at least the versions of those two packages so I can search them on the net?
Thanks a lot in advance for your support.

@luisapace for envoy, the sha in the filename (e.g. 0e1d66377d9bf8b8304b65df56a4c88fc01e87e8) correspond to the commit on https://github.com/envoyproxy/envoy that was used to compile the binary. You can find the source code for this particular binary here: https://github.com/envoyproxy/envoy/tree/0e1d66377d9bf8b8304b65df56a4c88fc01e87e8.
I just want to be clear that we make no guarantees that this is true. We currently extract the binary from this docker image and use the output of envoy --version to determine the sha. It is up to the envoyproxy team to ensure that the sha in the output corresponds to the correct git commit sha.
regarding the tar blob i am not sure where that came from. @sunjayBhatia do you remember where you got this tar binary for this story https://www.pivotaltracker.com/n/projects/1156164/stories/151173124 ?
I will go ahead and close this github issue. feel free to reopen if there are any unanswered questions. if you do, please explain your use case and why you are looking for the source code.

Hi, any news about the second question? (download location of the source code of tar/tar-1503683828.tgz).
My use case: we want to use Diego and to approve that use I've to analyze the source code of Diego and all compile and runtime dependencies chain to verify that - both - code and licenses do not have any problem from a license point of view.

@luisapace the source for the tar blob is here: https://github.com/cloudfoundry/bsdtar
Here is the pipeline where it was built: https://garden-windows.ci.cf-app.com/teams/main/pipelines/tar/jobs/build-tar/builds/10
Hope this helps. Let us know if you need anything further!


Updating UG DG, wilbur.md

Codecov Report

Merging #128 (b83a7f0) into master (8d91779) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #128   +/-   ##
=========================================
  Coverage     74.65%   74.65%
  Complexity      673      673
=========================================
  Files           107      107
  Lines          1969     1969
  Branches        223      223
=========================================
  Hits           1470     1470
  Misses          443      443
  Partials         56       56

Continue to review full report at Codecov.

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


[Godot 4.4 dev3] Fallback to OpenGL 3 not working on iPad 6th gen

Tested versions

Reproducible in 4.4 dev3

System information
Ipad 6th gen - iPad OS 17.5.1
Issue description
Title, I tried deploying and opening an app on an iPad 6th gen (iPadOS 17.5.1), but it doesn't work (manually setting the renderer from forward_plus or mobile to gl_compatibility does work, but it makes the fallback option completely pointless).
Console output on Xcode:
Godot Engine v4.4.dev3.official.f4af8201b - https://godotengine.org
Metal 3.1 - Forward Mobile - Using Device #0: Apple - Apple A10 GPU (Apple3)

MTLValidateFeatureSupport, line 6575: error 'Texture Cube Array is only supported on MTLGPUFamilyApple4 and later.'

MTLValidateFeatureSupport:6575: failed assertion 'Texture Cube Array is only supported on MTLGPUFamilyApple4 and later.'

Steps to reproduce
Export iOS project and open it.
Minimal reproduction project (MRP)
Can be tested with an empty project, as the fallback option in the project settings is enabled by default, so no MRP needed.

Fallback seems to only work if a specific rendering API is completely unsupported. Check of its capabilities is done after fallback checks (in rendering_device->initialize instead of rendering_context->initialize()). This is the same for all platforms.


Do not add TouchBar support

The TouchBar on my MacBook Pro display nothing, it is way too much empty!

I certainly couldn't fail to upvote this more.


LDP-1028 - Add support for modals

As discussed, supporting modules is not really the scope of a drupal connector module. It's better solved elsewhere, e.g. in its own module.


Removal of FlushGeneratedImagesTask was not documented.

This task appears to have been superseded by a new task called RegenerateCachedImagesTask but it was not documented, so FlushGeneratedImagesTask simply appeared to have vanished. This will update the documentation to reflect this change for both v3.2 (separate PR) and v3.3.

PR for the 3.2 branch https://github.com/silverstripe/silverstripe-framework/pull/5274

p.s. Here's the commit where this appears to have changed:
https://github.com/silverstripe/silverstripe-framework/commit/8908a6bcd7d1c6b812ecb12b2213d6f6598fd619
NOTE: I'm not sure if both PR's are necessary (one against 3.2 and another against 3.3) so feel free to close this one if the other one for 3.2 can be merged up into 3.3.

We only need it in the lowest branch and it'll be merged up periodically


how can i build the source code

as you can see i have 118 errors i just wanted to look trough the source to make sure it isnt a virus

To build the source yourself you need to add the game's dlls as reference, if you don't know how to do so try to search on YouTube or Google and you should find a bunch of tutorials, you will also need to build it as release to avoid other errors or performance issues, you can do so from the top bar on Visual Studio.

Add me on discord so i can send you the files
discord: Proofex

Add me on discord so i can send you the files discord: Proofex

youre not accepting friend requests


Doc Enhancement: Browse doc by area of interest

Any individual will likely not need to read all of Zowe doc. There is likely a specific component(s), or task they want to perform for their role.
Do one of the following:

Automatically present content based on user choice. For example, the user clicks a button "system programmer" and is shown only tasks that a sys prog performs. Or, they click "Zowe CLI" and see only cli-related content.
Or, if the automation is not feasible:
Create a map to areas of the site based on role or interest. The user can refer to the map and choose applicable concepts to learn about.

This is very similar to issue https://github.com/zowe/community/issues/472. So seems there are several dimensions of grouping content:

by role (sys programmar, app developer, devops engineer, contributor, etc)
by component (z/OS component, Zowe CLI, Zowe Explorer, etc)
by skill level (basic, advanced)

A map would be helpful. For each dimension, it can further drill down. So I might be a new app developer interested in developing a Zowe Desktop plug-in, and I can select all three dimensions to get a list of topics. Would be interesting to see how this is designed. A working session where different squads identify their roles and topics might be good.


geos-src: don't exclude source from package

It doesn't work though because the size of source is too big. I added after I tried to publish the crate.

Do you have the error by any chance? Normally, it should just work since cargo is supposed to checkout submodules as well. Or am I missing something?

Would exclude = ["source/*"] work better?

No, you can only exclude what is not needed by CMake. See if the commit I just sent makes it small enough. Otherwise we can also exclude web, but that requires patching CMakeList.txt since there isn't an option to turn it off.

It would be simpler to instead run git submodule update --init in build.rs.

Yes, that is also possible.

However, the package when I built it now is 8mb which is less than the 10mb limit. Only a couple of mb when compressed.

And if libgeos makes an update over-reaching this limit, we'll be back to this issue. Wouldn't it be better to just have to update the submodule and not worry about it being too big directly?

Sure. There are other crates that do it that way.

I let you handle the update? ;)

I think the current implementation is fine but I can wait for you to test more things. Please tell me once it's ready for you so I can review it.

Hi,
I reverted back to ignoring the tests only. We won't get any surprises from libgeos with static since we have to manually update the submodules. I would prefer to deal with it then, presumably by also excluding web. I was also made aware that builds happen offline in many cases, e.g. on docs.rs.
Does that work for you?
Regards, Gaute

It's fine for now. Let's hope we won't have bad surprise... I'll make a new release after merging this PR.

Thanks!

The three crates have been published.

Thanks, works perfectly.

The current one doesn't work with cargo publish --dry-run. But you could
use the one that excludes the tests.
tir. 22. mar. 2022, 15:55 skrev Guillaume Gomez @.***>:

I think the current implementation is fine but I can wait for you to test
more things. Please tell me once it's ready for you so I can review it.
—
Reply to this email directly, view it on GitHub
https://github.com/georust/geos/pull/104#issuecomment-1075285516, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAN367PFMWOBF3G4GKOOETVBHNMJANCNFSM5RLA533A
.
You are receiving this because you authored the thread.Message ID:
@.***>


kbfs failures

I tried rsyncing ~85GB dir to kbfs. I got error: rsync: write failed on  : Transport endpoint is not connected (107)
rsync error: error in file IO (code 11) at receiver.c(393) [receiver=3.1.2]
Now /keybase has KBFS_NOT_RUNNING link and there is no way to start kbfs again. run_keybase returns: Job for kbfs.service failed because a timeout was exceeded.
~/.local/share/keybase has grown to ~60GB.
This happens second time. Deleting ~/.local/share/keybase allows to restart service but deletion of this folder is painfully slow as it contains tons of small files.
my log id: cb6789a950feafae0003eb1c

Now I see in dmesg kbfsfuse got killed by oom-kill. kbfsfuse allocated ~18GB of memory. Is there something which can be done about it?

Thanks for the report.  I'm surprised that kbfsfuse would have that much memory in use -- it should top out at around 1.5 GB.  (It's possible it had 18 GB of virtual, not resident memory, allocated at once, but virtual memory shouldn't trigger oom-killer as far as I know, so that's weird.)
The logs you sent indicate that KBFS was getting killed and restarted about once a minute by something on your machine (I guess oom-killer?) -- again, it seems weird that it would be able to allocate much memory in that time. Also, the logs include some memory profiles that shows it at about 156 MB of memory allocated around the most recent time it was killed.  So again, weird.
You do have about 32 GB still left in your journal to flush to our servers.  If you want, you can run some commands to get rid of that unflushed data, and then try to flush again when you're ready.  If you do want to try that, do this:

Stop Keybase and KBFS completely.
Run this command from a terminal:

mv $HOME/.local/share/keybase/kbfs_journal/v1/0120dcbba65cd9f10f897219b90003dac167-d6fc1f16fa61b7e4 $HOME/.local/share/keybase/kbfs_journal/v1/d6fc1f16fa61b7e4.bkp

Restart Keybase and KBFS>

Then, once you verify that everything is ok and you haven't lost any data that wasn't backed up somewhere else, you can delete the whole $HOME/.local/share/keybase/kbfs_journal/v1/d6fc1f16fa61b7e4.bkp directory.
It would be nice to figure out why KBFS is being killed though.  Maybe you can watch top and see what the reported resident memory is before it's killed?

Please find below what i have in dmesg about oom-kill activity. Maybe it will shed some light.
[2601810.697259] Tasks state (memory values in pages):
[2601810.697260] [  pid  ]   uid  tgid total_vm      rss pgtables_bytes swapents oom_score_adj name
[2601810.697267] [    558]     0   558    26475       34    98304       36             0 lvmetad
[2601810.697269] [    998]     0   998    47169       66   208896      141             0 thermald
[2601810.697270] [   1003]     0  1003   108581      196   352256      202             0 ModemManager
[2601810.697271] [   1008]     0  1008    10027       23   118784       50             0 cron
[2601810.697273] [   1009]   102  1009    65758      165   151552      308             0 rsyslogd
[2601810.697274] [   1010]     0  1010    27619       33   114688       58             0 irqbalance
[2601810.697275] [   1011]   103  1011    12925      466   147456       82          -900 dbus-daemon
[2601810.697276] [   1036]     0  1036   162926      543   471040      377             0 NetworkManager
[2601810.697278] [   1038]     0  1038     1137        6    65536       35             0 acpid
[2601810.697279] [   1039]     0  1039   129534      662   364544      245             0 udisksd
[2601810.697280] [   1041]     0  1041    17676       55   172032      148             0 systemd-logind
[2601810.697281] [   1044]     0  1044    11400       80   135168      153             0 wpa_supplicant
[2601810.697282] [   1047]   117  1047    11861      106   135168       68             0 avahi-daemon
[2601810.697283] [   1049]     0  1049    77582      147   237568      169             0 accounts-daemon
[2601810.697284] [   1051]     0  1051    44832        1   233472     1986             0 networkd-dispat
[2601810.697286] [   1065]   117  1065    11768       15   131072       69             0 avahi-daemon
[2601810.697287] [   1073]     0  1073    81012      658   274432      359             0 polkitd
[2601810.697289] [   1124]   118  1124   239021      341   356352     1103             0 colord
[2601810.697290] [   1126]     0  1126    49009        0   278528     2002             0 unattended-upgr
[2601810.697291] [   1132]     0  1132    77221       56   245760      285             0 lightdm
[2601810.697292] [   1150]     0  1150   147168    23612   741376     4349             0 Xorg
[2601810.697293] [   1155]     0  1155     6242        0    73728       35             0 agetty
[2601810.697295] [   1293]     0  1293     6497       60    86016      259             0 dhclient
[2601810.697296] [   1310]   113  1310    95355       25   360448      395             0 whoopsie
[2601810.697297] [   1325]   114  1325    14234       27   147456       87             0 kerneloops
[2601810.697298] [   1327]   114  1327    14234       27   143360       86             0 kerneloops
[2601810.697299] [   2155]     0  2155    62637       69   258048      595             0 lightdm
[2601810.697301] [   3317]  1000  3317    19364      317   208896      166             0 systemd
[2601810.697302] [   3318]  1000  3318    65374        3   274432      655             0 (sd-pam)
[2601810.697303] [   3379]  1000  3379    72538      157   176128      142             0 gnome-keyring-d
[2601810.697304] [   3433]  1000  3433     1156        2    49152       22             0 sh
[2601810.697305] [   3559]  1000  3559    12940      455   147456      121             0 dbus-daemon
[2601810.697306] [   3863]  1000  3863     2825       10    61440       69             0 ssh-agent
[2601810.697308] [   3947]  1000  3947    85147      171   421888      328             0 xfce4-session
[2601810.697309] [   4032]  1000  4032    14847       94   155648       86             0 xfconfd
[2601810.697310] [   4129]  1000  4129   101943     1563   512000      890             0 xfwm4
[2601810.697311] [   4177]  1000  4177    96666     1949   516096      587             0 xfce4-panel
[2601810.697312] [   4179]  1000  4179   169116    14830   884736    19484             0 Thunar
[2601810.697314] [   4181]  1000  4181   166069     7863   659456     1408             0 xfdesktop
[2601810.697315] [   4210]  1000  4210    98129      201   462848      522             0 xfsettingsd
[2601810.697316] [   4213]  1000  4213   170130     3924   643072     3381             0 nm-applet
[2601810.697317] [   4214]  1000  4214    19955      195   196608       50             0 xscreensaver
[2601810.697318] [   4243]  1000  4243    92696      266   479232     1031             0 xfce4-power-man
[2601810.697320] [   4248]  1000  4248    91968       52   233472      188             0 at-spi-bus-laun
[2601810.697321] [   4252]  1000  4252    73461      214   200704      101             0 gvfsd
[2601810.697322] [   4260]  1000  4260   108005      107   217088      195             0 gvfsd-fuse
[2601810.697323] [   4290]  1000  4290   147601      498   512000      994             0 update-notifier
[2601810.697324] [   4298]  1000  4298    65903      289   397312     4005             0 applet.py
[2601810.697325] [   4306]  1000  4306    85737      170   430080     1039             0 polkit-gnome-au
[2601810.697326] [   4341]  1000  4341   170932      106   622592     5229             0 blueman-applet
[2601810.697328] [   4369]  1000  4369    12544       83   143360       99             0 dbus-daemon
[2601810.697329] [   4389]  1000  4389   104240      127   421888     1076             0 light-locker
[2601810.697330] [   4415]  1000  4415    47007      130   135168       65             0 dconf-service
[2601810.697331] [   4513]  1000  4513    55193       38   192512      150             0 at-spi2-registr
[2601810.697332] [   4530]  1000  4530   489649      762   487424      374             0 pulseaudio
[2601810.697333] [   4534]   109  4534    45875       23   131072       55             0 rtkit-daemon
[2601810.697334] [   4557]  1000  4557   121108      956   536576      763             0 xfce4-notifyd
[2601810.697336] [   4562]     0  4562    81026      156   249856      201             0 upowerd
[2601810.697337] [   4600]  1000  4600   123700      877   540672      932             0 panel-1-whisker
[2601810.697338] [   4612]  1000  4612    45088      231   385024      250             0 panel-4-systray
[2601810.697339] [   4614]  1000  4614   101994      836   503808      569             0 panel-5-notific
[2601810.697340] [   4616]  1000  4616   111375      856   483328      545             0 panel-6-indicat
[2601810.697341] [   4617]  1000  4617   144862     1903   569344     3876             0 panel-7-statusn
[2601810.697343] [   4618]  1000  4618   103040      762   528384      638             0 panel-8-power-m
[2601810.697344] [   4621]  1000  4621   176456     1298   593920      658             0 panel-9-pulseau
[2601810.697345] [   4622]  1000  4622    44755      480   389120      227             0 panel-15-cpugra
[2601810.697346] [   4623]  1000  4623    90339      806   462848      470             0 panel-14-netloa
[2601810.697347] [   4644]  1000  4644   116846       58   270336      376             0 indicator-messa
[2601810.697348] [   4656]  1000  4656    99178      551   258048      303             0 gvfs-udisks2-vo
[2601810.697349] [   4660]  1000  4660    95124      102   225280      181             0 gvfs-afc-volume
[2601810.697351] [   4665]  1000  4665    68932       86   163840       94             0 gvfs-goa-volume
[2601810.697352] [   4669]  1000  4669    69421       96   167936       95             0 gvfs-mtp-volume
[2601810.697353] [   4673]  1000  4673    72619      108   188416      128             0 gvfs-gphoto2-vo
[2601810.697354] [   4755]  1000  4755    96862      265   245760      621             0 gvfsd-trash
[2601810.697355] [   4946]  1000  4946    51633      143   167936      104             0 gvfsd-metadata
[2601810.697356] [   6897]  1000  6897    20681        1   151552      166             0 obexd
[2601810.697358] [   7817]  1000  7817   114944      250   241664      149             0 gvfsd-network
[2601810.697359] [   7826]  1000  7826   196606      342   741376      532             0 gvfsd-smb-brows
[2601810.697360] [   7838]  1000  7838   114210      132   237568      162             0 gvfsd-dnssd
[2601810.697361] [  11038]  1000 11038    90363      166   249856      267             0 gvfsd-http
[2601810.697362] [  12727]  1000 12727   173530      246   708608     6756             0 scp-dbus-servic
[2601810.697364] [  13600]  1000 13600    97026      904   385024      942             0 gigolo
[2601810.697365] [  13604]  1000 13604   176681       74   720896     1226             0 gvfsd-smb
[2601810.697367] [   2711]     0  2711    96026      112   323584      363             0 packagekitd
[2601810.697368] [   6686]  1000  6686   404708    10200  1261568     7798             0 VirtualBox
[2601810.697369] [   6704]  1000  6704    47036      305   335872      401             0 VBoxXPCOMIPCD
[2601810.697370] [   6709]  1000  6709   314836     4592   684032    16593             0 VBoxSVC
[2601810.697372] [  25472]   105 25472     9231        0   114688       53             0 uuidd
[2601810.697373] [  21739]  1000 21739    20443       59   188416      117             0 gconfd-2
[2601810.697375] [  17691]  1000 17691   167165     3706   610304      672             0 xfce4-terminal
[2601810.697376] [  17695]  1000 17695     7941       90   106496      391             0 bash
[2601810.697378] [  28915]  1000 28915     7941      309   102400      185             0 bash
[2601810.697379] [  29679]  1000 29679   133266     2278   479232        1             0 mousepad
[2601810.697380] [  31711]  1000 31711     7907      451   106496        1             0 bash
[2601810.697382] [    689]   101   689    17778      259   172032       17             0 systemd-resolve
[2601810.697383] [    694] 62583   694    35996      152   184320        0             0 systemd-timesyn
[2601810.697384] [    700]     0   700    45330      227   364544       10             0 systemd-journal
[2601810.697385] [   1888]     0  1888    11628      385   118784        0         -1000 systemd-udevd
[2601810.697387] [    995]     0   995   307531     2973   307200        2          -900 snapd
[2601810.697388] [  13647]  1000 13647     7908      419   102400       25             0 bash
[2601810.697389] [  14221]  1000 14221     7941      493   110592        0             0 bash
[2601810.697390] [  14311]  1000 14311   918062    80229  2883584    19843             0 firefox
[2601810.697391] [  14408]  1000 14408   765337    23139  2170880      584             0 Web Content
[2601810.697392] [  14470]  1000 14470   641917     6531   913408      153             0 WebExtensions
[2601810.697394] [  16871]     0 16871    49120     1310   258048        0             0 cupsd
[2601810.697395] [  16872]     0 16872    76546      503   352256        0             0 cups-browsed
[2601810.697396] [  16891]     7 16891    21602      203   200704        0             0 dbus
[2601810.697397] [  18330]  1000 18330   587964   171026  2351104    11270             0 keybase
[2601810.697398] [  18367]  1000 18367   177629      630   188416        1             0 keybase-redirec
[2601810.697400] [  18369]  1000 18369  4699249  3322613 32350208    13832             0 kbfsfuse
[2601810.697401] [  18396]  1000 18396   310680     6769  1400832       64             0 Keybase
[2601810.697402] [  18403]  1000 18403    93872     1616   647168        1             0 Keybase
[2601810.697403] [  18405]  1000 18405    93872     1616   495616        1             0 Keybase
[2601810.697404] [  18430]  1000 18430   130658     5977   897024        0             0 Keybase
[2601810.697405] [  18440]  1000 18440   213456    27091  2473984       40             0 Keybase
[2601810.697407] [  18445]  1000 18445   240055    30504  4501504      410             0 Keybase
[2601810.697408] [  19297]  1000 19297    35409    13474   315392      900             0 rsync
[2601810.697409] [  19298]  1000 19298    29904     4669   262144     1344             0 rsync
[2601810.697410] [  19299]  1000 19299    55556     5886   475136     2284             0 rsync
[2601810.697412] [  19528]  1000 19528   776217    56456  2244608     4494             0 thunderbird
[2601810.697413] [  20587]  1000 20587   192170      455   851968    15599             0 update-manager
[2601810.697414] [  20797]  1000 20797   101240      221   569344     1467             0 RDD Process
[2601810.697415] [  20987]  1000 20987   671268     1993  1183744    15627             0 Web Content
[2601810.697416] [  21273]  1000 21273   792282    21030  2400256    13039             0 Web Content
[2601810.697418] [  21914]  1000 21914   131453       33   237568      331             0 sd_espeak-ng
[2601810.697419] [  21921]  1000 21921   105335       46   208896      141             0 sd_dummy
[2601810.697420] [  21924]  1000 21924   105341       46   208896      144             0 sd_generic
[2601810.697421] [  21927]  1000 21927    44478        0   110592       76             0 speech-dispatch
[2601810.697422] [  21954]  1000 21954   634089      275   782336     3884             0 Web Content
[2601810.697423] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=kbfsfuse,pid=18369,uid=1000
[2601810.697427] Out of memory: Kill process 18369 (kbfsfuse) score 781 or sacrifice child
[2601810.697560] Killed process 18369 (kbfsfuse) total-vm:18796996kB, anon-rss:13290452kB, file-rss:0kB, shmem-rss:0kB
[2601811.378836] oom_reaper: reaped process 18369 (kbfsfuse), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

I moved journal, started keybase and run again rsync. According to top after half an hour kbfsfuse is using over 2.3GB of RES memory and this continuously increases.

Hmm, thanks for trying and for the info.  When kbfsfuse is at a lot of RES memory can you please a) copy the file /keybase/.kbfs_profiles/heap and share it with me like this:
cp /keybase/.kbfs_profiles/heap /keybase/private/strib@github,marcinbukat/

and b) do another keybase log send and report the log ID here?  Thanks!

kbfsfuse at around 3GB RES. I sent you /keybase/.kbfs_profiles/heap as requested
log id: 31624c49feeb6087812d261c

Thanks!  Unfortunately I still can't explain, or even see, the memory usage from all of this.  The heap reports that it's only using about 1 GB of memory, and there's nothing unusual-looking in the logs.
Could you also share the allocs file with me please, when you get a chance, if it's still happening?
cp /keybase/.kbfs_profiles/allocs /keybase/private/strib@github,marcinbukat/

I wonder if it's allocating and de-allocating too fast for Go's garbage collection to keep up with?  Seems unlikely but it's my best theory so far.
Is it still growing, beyond the 3 GB RES?

It hit 12.6GB RES and got killed. I observed memory usage in htop and it fluctuates - I mean usage drops from time to time but globally usage constantly grows. Usage grows also when rsyncing files which are the same on both ends so I guess reading from kbfs has something to do with this.


build failed when Integrate Flutter module into Android project

What happened?

Task :realm:downloadRealmBinaries FAILED
Changing current working directory to: /Users/yhq
Could not find package "realm". Did you forget to add a dependency?

Task :realm:runMetrics FAILED
Changing current working directory to: /Users/yhq
Could not find package "realm". Did you forget to add a dependency?

Repro steps
1.create a flutter module project(ep.realm_flutter_modules) and add realm dependency
`
dependencies:
flutter:
sdk: flutter
...
realm: ^2.2.1
`
2.create a android project(ep.RealmAddToApp) and follow the doc
3.run. then see build failed...
Version
3.19.3
What Atlas Services are you using?
Local Database only
What type of application is this?
Flutter Application
Client OS and version
Android Studio Iguana | 2023.2.1
Code snippets
Host App(RealmAddToApp)
flutter_settings.gradle
setBinding(new Binding(["gradle": this])) evaluate(new File(         settingsDir.parentFile,         "realm_flutter_modules/.android/include_flutter.groovy" ))
settings.gradle.kts
//... apply {     from("flutter_settings.gradle") } //...
build.gradle.kts(app)
//... dependencies {     //...     implementation(project(":flutter"))     //... } //...
Stacktrace of the exception/crash you're getting
No response
Relevant log output
No response

Sounds like you can reproduce this with a brand new project, do you mind uploading/sharing that so that we can look into what's happening?
The repro steps are pretty much the standard install steps and those work, so there's likely something subtle in your setup that's hitting a corner case we didn't guard against.

Uploading RealmAddToApp.zip…

Sounds like you can reproduce this with a brand new project, do you mind uploading/sharing that so that we can look into what's happening?
The repro steps are pretty much the standard install steps and those work, so there's likely something subtle in your setup that's hitting a corner case we didn't guard against.

Sounds like you can reproduce this with a brand new project, do you mind uploading/sharing that so that we can look into what's happening?
The repro steps are pretty much the standard install steps and those work, so there's likely something subtle in your setup that's hitting a corner case we didn't guard against.

https://github.com/yanhq0719/RealmAddToApp.git

Sounds like you can reproduce this with a brand new project, do you mind uploading/sharing that so that we can look into what's happening?
The repro steps are pretty much the standard install steps and those work, so there's likely something subtle in your setup that's hitting a corner case we didn't guard against.

https://github.com/yanhq0719/flutter_module.git
https://github.com/yanhq0719/RealmAddToApp.git

I am also getting this error
Launching lib/main_development.dart on Redmi Note 8 in debug mode...
Package realm not found in dependencies. Add realm package to your pubspec.yaml
-t, --target-os-type    The target OS to install binaries for.
                        [android, ios, linux, macos, windows]

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':realm:downloadRealmBinaries'.
> Process 'command '/Users/mac/development/flutter/bin/dart'' finished with non-zero exit value 64

That error seems completely unrelated with the original issue.

That error seems completely unrelated with the original issue.

maybe the realm gradle task problem.
the [runMetrics] and [downloadRealmBinaries] workingDir point to wrong path.
I try to modify workingDir like

any update?

We were experiencing the same issue when trying to use flutter as a module. We solved the issue by locking the version of realm, copying and modifying realm's build.gradle (we specified correct relative paths for workingDir) and then creating a task that would run before each build that overrides the generated realm's build.gradle (in .pub-cache) with our modified one.
It would be really nice if realm had better support for this. Acquiring the path for workingDir via an environmental variable or reading it from local.properties.

We were experiencing the same issue when trying to use flutter as a module. We solved the issue by locking the version of realm, copying and modifying realm's build.gradle (we specified correct relative paths for workingDir) and then creating a task that would run before each build that overrides the generated realm's build.gradle (in .pub-cache) with our modified one.
It would be really nice if realm had better support for this. Acquiring the path for workingDir via an environmental variable or reading it from local.properties.

Thanks for your comment, we adopt simlar way (fork repository and modifying realm's build.gradle) to solve this issue in the past period. Fortunately, at this moment we had achieved whole flutter-developed application so wo can get rid of this. But i believe before realm team proposing a solution, your solution should be the best answer

Having the same problem on a MacOS project.


document early_request_filter

Fix #363
Signed-off-by: spacewander<EMAIL_ADDRESS>

Other than the nit this LGTM. Thanks for helping with this!

Synced thanks!


installing angular

Description

I am new to coder and just started learning angluar, i look into some tutorials and  coder does not need node or npm install in local machine. but when i run coder and run commands for npm-v ng-v and node-v commands not working. is there any documentation on tutorials to follow on setting up angular on coder
here's a terminal screenshot

Related Issues

This does not realte to Coder at all, if it was ide.coder.com, we'll have a different story. You simply forgot to install Angular CLI tools.

I am not sure, i understand what you are saying, this is about setting up an angular app in ide.coder.com
since ide.coder is a vs code in cloud. any ideas on what am i missing to run those commands

You just need to install the required tools I citated above, I am not sure why you are having difficulty understanding that those tools are not yet installed, its clearly stated that bash can't find it on $PATH.

This is the wrong repo. Coder's hosted IDE bugs should go here: https://github.com/codercom/bugs But it doesn't seem to be a  bug. You'll have to install your tools from the instructions on their websites.
Please close.

you have to install npm + node .. then angular cli before you do that xD this is not a bug

Voting this a closure as this does NOT concern this project at all.


[wip] tests/vagrant refactor

Codecov Report

Merging #4484 (d1a61fc) into master (4b57951) will decrease coverage by 0.49%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #4484      +/-   ##
==========================================
- Coverage   12.07%   11.58%   -0.50%
==========================================
  Files         135      135
  Lines        9148     9175      +27
==========================================
- Hits         1105     1063      -42
- Misses       7808     7888      +80
+ Partials      235      224      -11

Flag
Coverage Δ

inttests
?

unittests
11.58% <ø> (-0.06%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

pkg/flock/flock_unix.go
0.00% <0.00%> (-46.67%)
:arrow_down:

tests/util/cmd.go
0.00% <0.00%> (-42.31%)
:arrow_down:

pkg/daemons/executor/executor.go
11.36% <0.00%> (-16.42%)
:arrow_down:

pkg/agent/netpol/utils/iptables.go
16.21% <0.00%> (-5.41%)
:arrow_down:

pkg/cli/cmds/server.go
0.00% <0.00%> (ø)

pkg/cli/server/server.go
0.00% <0.00%> (ø)

pkg/daemons/config/types.go
50.00% <0.00%> (ø)

Continue to review full report at Codecov.

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


Rollup failed to resolve import "$env/static/public" in web workers

Describe the bug
When importing env variables from a web worker, the project fails to build (it works in dev mode).
error during build:
Error: [vite]: Rollup failed to resolve import "$env/static/public" from "~/my-app/src/lib/test.worker.ts".

Reproduction

src/lib/test.worker.ts

import {} from '$env/static/public';

src/routes/+page.svelte

<script>
  import TestWorker from '$lib/test.worker?worker';
</script>

Logs
Error: [vite]: Rollup failed to resolve import "$env/static/public" from "~/my-app/src/lib/test.worker.ts".

System Info
System:
    OS: macOS 13.4.1
    CPU: (8) arm64 Apple M1
  Binaries:
    Node: 18.14.2
    Yarn: 1.22.15
    npm: 9.5.0
    pnpm: 8.6.3
  Browsers:
    Chrome: 114.0.5735.198
    Safari: 16.5.1
  npmPackages:
    @sveltejs/adapter-auto: ^2.0.0 => 2.1.0
    @sveltejs/kit: ^1.20.4 => 1.22.2
    svelte: ^4.0.5 => 4.0.5
    vite: ^4.4.2 => 4.4.3

Severity
blocking an upgrade
Additional Information
No response

I'm having the same issue

This also affects Houdini imports.
Error: [vite]: Rollup failed to resolve import "__sveltekit/environment" from<EMAIL_ADDRESS>

Are there any workarounds for this?

I was able to workaround the issue with the following changes to vite.config.js:
const config = {
	// ...
	worker: {
		plugins: [sveltekit()],
		format: 'es',
	},
	// ...
};

export default config;

Although the above workaround works, it's not ideal. As mentioned in https://github.com/sveltejs/kit/pull/10542#issuecomment-1702199950, the fix should probably be part of the sveltekit() plugin:

What we need is a trimmed-down worker-specific plugin that supports the aliases and other core features. And perhaps sveltekit() can append that plugin to worker.plugins internally.