DISCUSSION: Compose > v2 support

Is your feature request related to a problem? Please describe.
Libcompose, the library we currently use for deploying stacks on docker standalone is deprecated and is causing a TONNE of issues. Something needs to be done, as a broken implementation of stack deploy on standalone is not user-friendly nor is it a feasible for support reasons.
Issues that will be solved by this outlined below:

#3533
#3382
#3242
#2912
#2603
#2381
#2339
#2289
#2041
#2039
#2608
#1989
#3740
#3768
#4137

Describe the solution you'd like
I think there are two obvious paths we can take, but there could also be alternate solutions to this (feel free to comment with suggestions);

Replace Libcompose with the docker-compose binary and wait for the docker-compose go library to be released tracked here. The limitation of this approach is the docker-compose binary is only compiled for Linux and Windows.
Hide the stack deploy UI for standalone endpoints while we wait for the docker-compose go library to be released tracked here

Option 2 "Hide the stack deploy UI for standalone endpoints" would definitely require us to freeze at a previous release until things are sorted out. :)  At this point Portainer's standalone compose implementation is "usable" but with a variety of quirks and limitations (as mentioned), some of which can be worked around.  So personally I like option 1, assuming building things out against binary for now isn't too involving.  If that's more work than it's worth, I'd say leave things as they are until the Go lib is available.  Just my .02

@Codelica indeed, actually our idea was to hide the stack deploy UI only for specific plaforms.
The docker-compose binary  is only built for Linux, Mac and Windows. This means that if we want to leverage it and embed it in Portainer temporarily, we'd only support stack deployment on these platforms which would impact arm, arm64 and our other platform users. This is why we wanted to hide the UI in that specific case.
Another alternative would be to fallback to libcompose if the platform is not supported.

@deviantony Considering the other issue we talked about recently when it comes to the stack feature pulling from Git hosted on VSTS - it seems like it might be just better to go with executables and disable certain features on certain platforms. No point making some x64 users sacrifice useful features like this so that someone can run Portainer on the Raspberry Pi - I'd say a Raspberry Pi user is less likely to need stack deployment anyway.

Not that our use is necessarily typical, but we do deploy under linux across x86_64, arm32v7, and arm64v8 with custom app templates for each arch that include v2 compose recipes (working around limitations we've hit).  So personally I'd love to see this approach for now:
"Another alternative would be to fallback to libcompose if the platform is not supported by docker-compose."
IMO the current compose lib isn't useless for ARM -- just a little "special" :)  So if it's possible to keep around for ARM (with disclaimer?) until the Docker Go lib is available, that would be great for us.
BTW, the recent issue triage is noticeable.  Thanks!

@Codelica I agree, automatic fallback and a little red disclaimer at the stack deployment page about limited functionality due to library issues sounds like the usable solution.

I would disagree that stack deployment is completely broken as is.
It certainly has own quirks, but can serve really well if used properly.

Hiding stack functionality would prevent some users from updating Portainer. Usage of stacks on a single host is beneficial, simply because it makes easy to manage microservices within the stack and also makes things organized which can turn really messy when you have hundreds of containers running. If users were forced to withhold the update of Portainer, it could also pose a security risk for them due to potential vulnerabilities.
The alternative is to hide, but allow activation by setting Portainer environment variable or by supplying argument to the command.

How would be the environment be different for docker-compose versus libcompose? Isn't libcompose executed within container anyway and uses docker API?
Why would be docker-compose different? It can run inside the container.
Pardon me if I'm lacking deeper knowledge about docker-compose that prevents me from seeing issue in your way.

@xZero707 libcompose is a library approach to provide the same functionality a docker compose but it is outdated and not maintainted, as such it only supports (and partially) docker compose format version 2.0.
Using the latest version of the docker-compose binary would provide the latest docker-compose features and fixes as well as support for the latest docker compose format version.

@deviantony That's pretty clear for me, but what isn't is how docker-compose is different if used inside the container? It supports different CPU architectures (like ARM).

@xZero707 See https://github.com/docker/compose/releases
Binaries are available for Linux and Windows (x86_64) and not for ARM (which is an architecture that is supported by Portainer).

@xZero707 See https://github.com/docker/compose/releases
Binaries are available for Linux and Windows (x86_64) and not for ARM (which is an architecture that is supported by Portainer). Of course you can use it to execute docker-compose to remote environments but we also need to keep in mind the use case of Portainer being deployed on arm.

Hi,
I am realy interesting by the support for compose >2.
I have been able to install docker-compose on armbian, using alternative procedure describe here : https://docs.docker.com/compose/install/#install-using-pip.
I am using this procedure from basic debian too.

Another one using docker-compose in armbian with no issues at all (I too sed pip to install it)!
Mind you, you can actually run docker-compose from a container as indicated here!
sudo curl -L --fail https://github.com/docker/compose/releases/download/1.25.5/run.sh -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose

This would be another alternative although we'd now need to maintain another Linux image instead of having a generic Linux image (we would need to have pip available in the image).

@deviantony I think https://github.com/compose-spec/compose-go could be a good candidate in this case.

Almost a month since last comment. Any progress on this? #3382 in this list is completely blocking us. Is there a work around?

So, we now have a development timeline out for v2.* versions of Portainer, you can read about it here. Support for compose version3 is slated for Q3/Q4 2020

Is there a work around

Not that I am currently aware of

@Awatatah There is no workaround unless moving to (single node?) docker swarm is an option. In that case, Portainer uses docker stack which works well with compose version 3.

I'm very much in favor of just calling docker-compose.
Also, hiding the "stack deploy" ui on standalone setups would make people start looking for other tools to use instead of portainer -  a LOT of docker images on docker hub provide their "how to run this" in form of a compose file, usually in version 3.

Just to mention I'm currently using docker / portainer / docker-compose on a Rpi4 / ARM64 (gentoo) with hard disks and 8Gb Ram.
docker-compose appears to use python3
It would be nice if there was a way for this to be rolled into portainer at some point, or just call the docker-compose on the actual host to save referencing a linux image containing python3
I had a quick look if extensions / plugins were possible but it looks like that's not an option ether.
So I'll probably look at using Yacht for deploying docker-compose templates.
https://github.com/SelfhostedPro/Yacht

Are you planning to release the business version before adding docker compose support?

Hi,
@Kourgiantakis , there is a roadmap here : https://www.portainer.io/2020/06/portainer-2-0-and-the-development-balancing-act/

Yes we are.
Business edition is released soon, the next CE release will include compose v3 support.
Rgds,
Neil Cresswell

Yes we are. Business edition is released soon, the next CE release will include compose v3 support. Rgds, Neil Cresswell

...where do I send the beer?

Hi guys,
If I am not mistaken, support of v3 compose is not part of the new release CE, right ?
Maybe it's only for Business edition ?

Hi guys,
If I am not mistaken, support of v3 compose is not part of the new release CE, right ?
Maybe it's only for Business edition ?

new release? did I miss something?

Its earmarked for CE 2.1
From: Sid-Ahmed<EMAIL_ADDRESS>Sent: Sunday, 8 November 2020 10:07 PM
To: portainer/portainer<EMAIL_ADDRESS>Cc: Neil Cresswell<EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Subject: Re: [portainer/portainer] DISCUSSION: Compose > v2 support (#3750)
Hi guys,
If I am not mistaken, support of v3 compose is not part of the new release CE, right ?
Maybe it's only for Business edition ?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_portainer_portainer_issues_3750-23issuecomment-2D723549245&d=DwMCaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=0fx0h4vB56iTLpw2McH1ZD6TqG_QGpbggVOB-PfMJpM&m=ALLVYs0_h7o_jxQ9Uo9-h-621-Je2vN1yF8YcR1cucU&s=YWNczAA1RkTXQbdSmj1oPZj_TKotcFzlcMyw1Rg7kLg&e=, or unsubscribehttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AFQ2XFIGFKKVBKOTA6AOMH3SOZNSNANCNFSM4MP2SO4Q&d=DwMCaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=0fx0h4vB56iTLpw2McH1ZD6TqG_QGpbggVOB-PfMJpM&m=ALLVYs0_h7o_jxQ9Uo9-h-621-Je2vN1yF8YcR1cucU&s=wlw51BREY8-XHyTg-EAaMm0vQRiwCVFTdDETWu3vJuw&e=.

eagerly awaiting its release

eagerly awaiting its release

Yup, me to...!

@ncresswell May i ask for a release date ? :) Is it something you can share in public ?

the roadmap had it at end of oct/early nov. no date. hopefully before end of the year

Appreciate thanks @ksurl

Any news?
Is a release of 2.1 before the new year realistic?

We actually had a meeting on this yesterday…
There are a number of complications regarding adding the compose binary, so this is likely not going to make it this year… it will however be January.
We are still likely to embed a copy of the compose binary in Portainer container and the agent containers.. we are just trying to find a reliable producer of the binary as we need it come from a reliable/trusted source that is regularly maintained. Docker don’t provide it except for x86.

Appreciate the effort. Have nice holidays and take it easy.  :rocket: :tada:

Update on this topic:

We've tried to compile a static version of docker-compose binary and we've managed to do it successfully for the Linux/amd64 platform/OS but we've not been able to create statically compiled binary for the Linux/arm64 platform/OS.

As this one was of our main requirements to continue using the scratch image, we're now thinking about using the following solution:

For Linux/amd64: use our own statically compiled binary embedded in the scratch image
For Windows: use the official binary embedded in the windows amd64 image
For Linux/ARM64: Provide the dynamically compiled binary (from linuxserver.io) into our alpine image for Linux/ARM64, which will allow users on this platform to use the binary approach ONLY IF they use the alpine based image (this will have to be properly documented)
Always fallback to libcompose if the docker-compose binary is not available in the image

We'd be happy to accept some help as well regarding the static compilation of the docker-compose binary on arm64 as we've not been able to crack that one.

Just a couple random questions / comments...
How would the .tar.gz packaged releases (like portainer-2.x.x-linux-amd64.tar.gz
) be handled?  Asking for a friend. :)
I'm hoping they would just included linked binaries?  Linux server does supply Linux and Alpine releases also, separate from their Docker images.  (FWIW the ARM64 Linux release from them seems to work fine here under Ubuntu 20 on a Raspberry Pi 4)
If docker-compose isn't bundled in the .tar.gz releases, then just to be clear, this...

Always fallback to libcompose if the docker-compose binary is not available in the image (default scratch image for the linux/arm, linux/arm64, linux/s390x and linux/ppcl64e platforms).

...means that Portainer would still honor using docker-compose if it found it was available, or in some specific location, etc?   Basically we could make it available ourselves.
Thanks!...  and Happy Holidays..

...couldn't you just base the docker images on a linux flavor that provides the right docke-compose version, and install the package?

@Codelica the binary archive releases for 2.0.0 were a mistake on our side as we do not support them anymore starting from version 2.0.0 but we forgot to remove them from our CI pipeline.
We're currently thinking about removing them for the existing 2.0.0 release but if you think we should keep them, I'm keen to discuss it.
Regarding the Linux server releases, these are dynamically linked binaries, which means they require some libraries to be available in your runtime environment (and that is not the case for the scratch image which is why one of our option is to use a alpine/ubuntu based image).
@lemmy04 what do you mean? Also the scratch base image is important to us as it allows Portainer to be very portable and to run in any kind of environment without exposing too much attack surface.

@Codelica the binary archive releases for 2.0.0 were a mistake on our side as we do not support them anymore starting from version 2.0.0 but we forgot to remove them from our CI pipeline.
We're currently thinking about removing them for the existing 2.0.0 release but if you think we should keep them, I'm keen to discuss it.

:(  I'd certainly vote for keeping them around un-tested/un-supported if possible. I realize 99+% of people probably use your images directly, but we bundle the binary into a custom (Ubuntu based) image along with a variety of other tooling for support. (Yes, not very Docker-like, but super helpful ;) ).  I guess I could migrate to try and pull things out of your image(s), just depending.  It's just quite clean currently, and we test anyway.  I won't hijack the thread here though.

Regarding the Linux server releases, these are dynamically linked binaries, which means they require some libraries to be available in your runtime environment (and that is not the case for the scratch image which is why one of our option is to use a alpine/ubuntu based image).

Yep, I understand.  I was speaking more about inclusion of compose in your binary releases which may be going away. :/   But for ARM64, if static isn't an option for compose, I'd think Alpine would be fine for Portainer itself.  It's not scratch, but at under 3MB it's not toooo far off. :)

@ncresswell, are you guys still on track for a January release?
I don't want to build up any pressure with this, but am simply following the topic with interest.

@ncresswell, are you guys still on track for a January release?
I don't want to build up any pressure with this, but am simply following the topic with interest.

We have a dev meeting today actually, so i will report back in 12 hours.
Rgds,
Neil Cresswell

We have a dev meeting today actually, so i will report back in 12 hours.
Rgds,
Neil Cresswell

Hi everyone.... we need your help... is there anyone out there that can create a "statically compiled binary" of compose that runs in a scratch container on ARM/ARM64/AMD64?
We are having an increasingly difficult time building an image that works in scratch, and unless we can do this, we will have no choice but to change our base from scratch to alpine (which we really dont want to do).
Is there anyone out there that can help us with this?

Hi everyone.... we need your help... is there anyone out there that can create a "statically compiled binary" of compose that runs in a scratch container on ARM/ARM64/AMD64?
We are having an increasingly difficult time building an image that works in scratch, and unless we can do this, we will have no choice but to change our base from scratch to alpine (which we really dont want to do).
Is there anyone out there that can help us with this?

@ncresswell can you elaborate on the problems a bit?

@ncresswell can you elaborate on the problems a bit?

I will try and experiment a bit and let you know if I find a way to do it.
Let's be optimistic; If several people try to do this, at least one may succeed.

I will try and experiment a bit and let you know if I find a way to do it.
Let's be optimistic; If several people try to do this, at least one may succeed.

I guess the question is whether the binary really is statically linked (hence me asking for more details) or whether there is some form of dependency to libc. In Rust you usually need to link against lib musl instead of libc to get a proper static binary that works. Just my 2 cents.

I guess the question is whether the binary really is statically linked (hence me asking for more details) or whether there is some form of dependency to libc. In Rust you usually need to link against lib musl instead of libc to get a proper static binary that works. Just my 2 cents.

We are having an increasingly difficult time building an image that works in scratch, and unless we can do this, we will have no choice but to change our base from scratch to alpine (which we really dont want to do).

Why alpine specifically, and what is the problem with it? There are other linux base images for ARM...

We are having an increasingly difficult time building an image that works in scratch, and unless we can do this, we will have no choice but to change our base from scratch to alpine (which we really dont want to do).

Why alpine specifically, and what is the problem with it? There are other linux base images for ARM...

Alpine is extremely lightweight and small. When you run a medium microservice infrastructure with a lot of different images, you really start to appreciate small size as images can quickly add up and consume hundreds of gigabytes.

Alpine is extremely lightweight and small. When you run a medium microservice infrastructure with a lot of different images, you really start to appreciate small size as images can quickly add up and consume hundreds of gigabytes.

Alpine is extremely lightweight. When you run a microservice infrastructure with a lot of different images, you really start to appreciate every megabyte less as images can quickly add up and consume hundreds of gigabytes.

This is why they want to start from scratch without even the alpine layer (IMO)

Alpine is extremely lightweight. When you run a microservice infrastructure with a lot of different images, you really start to appreciate every megabyte less as images can quickly add up and consume hundreds of gigabytes.

This is why they want to start from scratch without even the alpine layer (IMO)

Multiple concerns here regarding the use of the alpine image:

We'd rather keep on scratch to keep the attack surface on the container as low as possible
Since we'll probably need to support this feature inside the agent as well, this would have even more impact as the agent should run on scratch if possible for the reason above

Regarding the details about the statically compiled binary, it would be required to have the binary without any form of dependency I believe as there is no lib dependency available in the scratch image.
To give more details on the technical side:
To run in a scratch image docker-compose binary needs to be statically compiled and not depend on any system library. docker-compose source is in python and then need to be first compiled and then statically linked to build a standalone binary. We were not able to achieve the last step for arm64 and getting segment fault error.
If you need more technical details we can also describe what we have achieved.

Multiple concerns here regarding the use of the alpine image:

We'd rather keep on scratch to keep the attack surface on the container as low as possible
Since we'll probably need to support this feature inside the agent as well, this would have even more impact as the agent should run on scratch if possible for the reason above

Regarding the details about the statically compiled binary, it would be required to have the binary without any form of dependency I believe as there is no lib dependency available in the scratch image.
To give more details on the technical side:
To run in a scratch image docker-compose binary needs to be statically compiled and not depend on any system library. docker-compose source is in python and then need to be first compiled and then statically linked to build a standalone binary. We were not able to achieve the last step for arm64 and getting segment fault error.
If you need more technical details we can also describe what we have achieved.

To run in a scratch image docker-compose binary needs to be statically compiled and not depend on any system library. docker-compose source is in python and then need to be first compiled and then statically linked to build a standalone binary. We were not able to achieve the last step for arm64 and getting segment fault error.

I'd recommend to try the exact same steps on a musl based system (e.g. on Alpine).
If that doesn't help I'd suggest you post the exact steps you have taken.

To run in a scratch image docker-compose binary needs to be statically compiled and not depend on any system library. docker-compose source is in python and then need to be first compiled and then statically linked to build a standalone binary. We were not able to achieve the last step for arm64 and getting segment fault error.

I'd recommend to try the exact same steps on a musl based system (e.g. on Alpine).
If that doesn't help I'd suggest you post the exact steps you have taken.

FYI this is the process we're using to build the binary statically for Linux AMD64: https://github.com/portainer/docker-compose-linux-amd64-static-binary/blob/main/Dockerfile
I'll let @sbusso jump in the discussion for the problem spotted on arm64.

FYI this is the process we're using to build the binary statically for Linux AMD64: https://github.com/portainer/docker-compose-linux-amd64-static-binary/blob/main/Dockerfile
I'll let @sbusso jump in the discussion for the problem spotted on arm64.

thanks @deviantony I will reproduce the steps to provide an exact error message. A segment fault happens when creating the static binary with staticx, which is not working on arm64.

thanks @deviantony I will reproduce the steps to provide an exact error message. A segment fault happens when creating the static binary with staticx, which is not working on arm64.

As someone who only recently gotten into Docker, got excited, found Portainer, got even more excited, only to then get rather depressed to find none of the v3 compose files I built work on a single host non-swarm Portainer configuration due to this issue, if you need any guinea pigs for testing things to get this working, I am up for it. Can't wait for v3 compose support as otherwise Portainer looks fantastic.

As someone who only recently gotten into Docker, got excited, found Portainer, got even more excited, only to then get rather depressed to find none of the v3 compose files I built work on a single host non-swarm Portainer configuration due to this issue, if you need any guinea pigs for testing things to get this working, I am up for it. Can't wait for v3 compose support as otherwise Portainer looks fantastic.

For a single host docker environment, I'd suggest, you take a look at 'lazydocker'.

For a single host docker environment, I'd suggest, you take a look at 'lazydocker'.

For a single host docker environment, I'd suggest, you take a look at 'lazydocker'.

yes and no: for lazydocker the user has to have shell access to the actual host; with portainer you can just point the user at a web UI, and limit their access to exactly the containers they need to access - and even hide some containers from portainer.

For a single host docker environment, I'd suggest, you take a look at 'lazydocker'.

yes and no: for lazydocker the user has to have shell access to the actual host; with portainer you can just point the user at a web UI, and limit their access to exactly the containers they need to access - and even hide some containers from portainer.

Lazydocker is definitely a nice addition for the users with shell access. However, Portainer is still a priceless tool.

Lazydocker is definitely a nice addition for the users with shell access. However, Portainer is still a priceless tool.

@sbusso Gut check - When you built arm64, did you do the build on an arm64 machine, or did you use docker buildx?

@sbusso Gut check - When you built arm64, did you do the build on an arm64 machine, or did you use docker buildx?

@sbusso
It looks like theres a hardcoded x86_64 binary in the file.  Is there an arm64 version of this?
staticx -l /lib/x86_64-linux-gnu/libgcc_s.so.1 dist/docker-compose /dist/docker-compose
https://github.com/portainer/docker-compose-linux-amd64-static-binary/blob/69d74e47c649b612e6643ee745848a7d6b579577/Dockerfile#L41

@sbusso
It looks like theres a hardcoded x86_64 binary in the file.  Is there an arm64 version of this?
staticx -l /lib/x86_64-linux-gnu/libgcc_s.so.1 dist/docker-compose /dist/docker-compose
https://github.com/portainer/docker-compose-linux-amd64-static-binary/blob/69d74e47c649b612e6643ee745848a7d6b579577/Dockerfile#L41

thanks @akutruff, built it on arm64 and we added libc after trying to compile it for arm64 as we run into issues at runtime.

thanks @akutruff, built it on arm64 and we added libc after trying to compile it for arm64 as we run into issues at runtime.

also @akutruff you can run your docker image with docker run -v /tmp:/tmp as a workaround to the missing directory.

also @akutruff you can run your docker image with docker run -v /tmp:/tmp as a workaround to the missing directory.

@sbusso Oh, so you're not getting a segfault anymore?  Is everything resolved for arm64 then?

@sbusso Oh, so you're not getting a segfault anymore?  Is everything resolved for arm64 then?

@akutruff I don't get it working, and staticx version of docker-compose is still throwing errors

@akutruff I don't get it working, and staticx version of docker-compose is still throwing errors

Hmm.. It seems the docker-compose folks use alpine for their own image.  I'll throw my hat into the +1 for alpine basket if it gets compose updated for portainer.  Scratch and staticx are rough.
https://github.com/docker/compose/blob/master/Dockerfile

Hmm.. It seems the docker-compose folks use alpine for their own image.  I'll throw my hat into the +1 for alpine basket if it gets compose updated for portainer.  Scratch and staticx are rough.
https://github.com/docker/compose/blob/master/Dockerfile

For a single host docker environment, I'd suggest, you take a look at 'lazydocker'.

yes and no: for lazydocker the user has to have shell access to the actual host; with portainer you can just point the user at a web UI, and limit their access to exactly the containers they need to access - and even hide some containers from portainer.

I've been playing around with lazydocker, and to me it seems that its use is limited to working with already existing containers and images - there's no command to create a new container or pull an image from a registry.

For a single host docker environment, I'd suggest, you take a look at 'lazydocker'.

yes and no: for lazydocker the user has to have shell access to the actual host; with portainer you can just point the user at a web UI, and limit their access to exactly the containers they need to access - and even hide some containers from portainer.

I've been playing around with lazydocker, and to me it seems that its use is limited to working with already existing containers and images - there's no command to create a new container or pull an image from a registry.

I've also tried compiling this directly on my NanoPi M4V2, as @akutruff pointed out, I had to add the scons package and change the lib path to "aarch64-linux-gnu", after that it compiled perfectly.
To build I used:
docker build --force-rm -t dc_test:latest .

Then following @sbusso comments, I tried running it with:
docker run --rm -v "/tmp:/tmp" dc_test

but that failed with:
[7] Cannot open self /tmp/staticx-ZMRSSr/docker-compose or archive /tmp/staticx-ZMRSSr/docker-compose.pkg

Any ideas?

I've also tried compiling this directly on my NanoPi M4V2, as @akutruff pointed out, I had to add the scons package and change the lib path to "aarch64-linux-gnu", after that it compiled perfectly.
To build I used:
docker build --force-rm -t dc_test:latest .

Then following @sbusso comments, I tried running it with:
docker run --rm -v "/tmp:/tmp" dc_test

but that failed with:
[7] Cannot open self /tmp/staticx-ZMRSSr/docker-compose or archive /tmp/staticx-ZMRSSr/docker-compose.pkg

Any ideas?

@pedrolamas I ended up bailing after trying to fix this issue for hours.  I even tried running the build docker-compose binary inside the build container as a test to see if scratch was causing the problem.
I got the same error about tmp.  I looked and looked for these mythical tmp files generated by staticx and they were no where to be found in the build container or the final image.
I tried using the latest python image for the builder.  Nothing changed.   I was going to see if using absolute paths would change anything, but I couldn't devote any more time to this.

@pedrolamas I ended up bailing after trying to fix this issue for hours.  I even tried running the build docker-compose binary inside the build container as a test to see if scratch was causing the problem.
I got the same error about tmp.  I looked and looked for these mythical tmp files generated by staticx and they were no where to be found in the build container or the final image.
I tried using the latest python image for the builder.  Nothing changed.   I was going to see if using absolute paths would change anything, but I couldn't devote any more time to this.

[7] Cannot open self /tmp/staticx-ZMRSSr/docker-compose or archive /tmp/staticx-ZMRSSr/docker-compose.pkg

This issue is due to missing libraries inside the staticx package.  After running the compilation with debug mode, I ended up adding all libraries manually. At the end I got another segment fault.

[7] Cannot open self /tmp/staticx-ZMRSSr/docker-compose or archive /tmp/staticx-ZMRSSr/docker-compose.pkg

This issue is due to missing libraries inside the staticx package.  After running the compilation with debug mode, I ended up adding all libraries manually. At the end I got another segment fault.

More reasons to use alpine:
Official image for arm64 is an open issue:
https://github.com/docker/compose/issues/6831
linuxserver.io uses full ubuntu.
https://github.com/linuxserver/docker-docker-compose/blob/master/Dockerfile.aarch64

More reasons to use alpine:
Official image for arm64 is an open issue:
https://github.com/docker/compose/issues/6831
linuxserver.io uses full ubuntu.
https://github.com/linuxserver/docker-docker-compose/blob/master/Dockerfile.aarch64

@sbusso can you share your latest Dockerfile?

@sbusso can you share your latest Dockerfile?

@akutruff unfortunately the version with debug and libraries died with my RPi while I was trying all compilation options end of the year.

@akutruff unfortunately the version with debug and libraries died with my RPi while I was trying all compilation options end of the year.

@sbusso Bummer.  So what's the chance of using alpine to unblock this issue?

@sbusso Bummer.  So what's the chance of using alpine to unblock this issue?

@akutruff very low at the moment for the reasons exposed in the comment above: https://github.com/portainer/portainer/issues/3750#issuecomment-759181902
As a first step, we're bringing support for docker-compose for Linux AMD64 / Windows AMD64 first in CE 2.1 and we're still considering adding support for it in Linux ARM64 but that will come later in another release.
Unless someone is able to crack the solution for this ARM64 compilation, it is highly probable that we'll wait for the Go implementation of docker-compose to be ready.
Refs:

https://github.com/docker/roadmap/issues/15
https://github.com/compose-spec/compose-go

@akutruff very low at the moment for the reasons exposed in the comment above: https://github.com/portainer/portainer/issues/3750#issuecomment-759181902
As a first step, we're bringing support for docker-compose for Linux AMD64 / Windows AMD64 first in CE 2.1 and we're still considering adding support for it in Linux ARM64 but that will come later in another release.
Unless someone is able to crack the solution for this ARM64 compilation, it is highly probable that we'll wait for the Go implementation of docker-compose to be ready.
Refs:

https://github.com/docker/roadmap/issues/15
https://github.com/compose-spec/compose-go

The idea was not to switch to alpine as the base image - but to build the static binary on it. That's a big difference. I've built rust binaries on alpine to be able to run them on a scratch image.
Without a proper log of what you actually have tried and what the error was there is no way to say if this could be a similar problem. How about some ldd output to start with?

The idea was not to switch to alpine as the base image - but to build the static binary on it. That's a big difference. I've built rust binaries on alpine to be able to run them on a scratch image.
Without a proper log of what you actually have tried and what the error was there is no way to say if this could be a similar problem. How about some ldd output to start with?

Looks like docker-compose in now written in go with feature parity with the Py version. Could this help?
https://github.com/docker/roadmap/issues/15#issuecomment-765180731

Looks like docker-compose in now written in go with feature parity with the Py version. Could this help?
https://github.com/docker/roadmap/issues/15#issuecomment-765180731

Hi,
pardon my technical ineptitude, but I follow this discussion as I'm very interested in finally being able to ditch using CLI for the management of my stacks in favour of the portainer GUI. I'll admit most of it is going way over my head technically; and my focus is on usability over security; but why can't portainer webui just issue commands to the docker-compose already present on every system I use portainer on ? I mean can't the webui detect if the system has docker-compose? If so, then use it, if not then revert to current behaviour?

Hi,
pardon my technical ineptitude, but I follow this discussion as I'm very interested in finally being able to ditch using CLI for the management of my stacks in favour of the portainer GUI. I'll admit most of it is going way over my head technically; and my focus is on usability over security; but why can't portainer webui just issue commands to the docker-compose already present on every system I use portainer on ? I mean can't the webui detect if the system has docker-compose? If so, then use it, if not then revert to current behaviour?

Apology accepted. ;-)
It looks like you have NO unserstanding of containers. Portainer itself "lives" in a container and has no access to the commands on the host.
rgds
Kai

Januar 2021 09:33, "hugalafutro"<EMAIL_ADDRESS>(mailto:notifications@github.com?to=%22hugalafutro%22%20notifications@github.com)> schrieb:
Hi,
pardon my technical ineptitude, but I follow this discussion as I'm very interested in finally being able to ditch using CLI for the management of my stacks in favour of the portainer GUI. I'll admit most of it is going way over my head technically; and my focus is on usability over security; but why can't portainer webui just issue commands to the docker-compose already present on every system I use portainer on ? I mean can't the webui detect if the system has docker-compose? If so, then use it, if not then revert to current behaviour?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub (https://github.com/portainer/portainer/issues/3750#issuecomment-765234223), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AKCIZX4GXTL4IWZZBUHXHRTS3EZ6NANCNFSM4MP2SO4Q).

Apology accepted. ;-)
It looks like you have NO unserstanding of containers. Portainer itself "lives" in a container and has no access to the commands on the host.
rgds
Kai

Januar 2021 09:33, "hugalafutro"<EMAIL_ADDRESS>(mailto:notifications@github.com?to=%22hugalafutro%22%20notifications@github.com)> schrieb:
Hi,
pardon my technical ineptitude, but I follow this discussion as I'm very interested in finally being able to ditch using CLI for the management of my stacks in favour of the portainer GUI. I'll admit most of it is going way over my head technically; and my focus is on usability over security; but why can't portainer webui just issue commands to the docker-compose already present on every system I use portainer on ? I mean can't the webui detect if the system has docker-compose? If so, then use it, if not then revert to current behaviour?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub (https://github.com/portainer/portainer/issues/3750#issuecomment-765234223), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AKCIZX4GXTL4IWZZBUHXHRTS3EZ6NANCNFSM4MP2SO4Q).

You're completely right I've first come into contact with docker about month ago and I just like the portability of it how it's all in it's own space and leaves the rest of system clean so I keep tinkering with it by moving all my services to it and naturally came across Portainer.
Anyways I'll leave you fine folks to iron out the technical details under the hood and hopefully a day where v3 stacks will be manageable from ui won't be far off.

You're completely right I've first come into contact with docker about month ago and I just like the portability of it how it's all in it's own space and leaves the rest of system clean so I keep tinkering with it by moving all my services to it and naturally came across Portainer.
Anyways I'll leave you fine folks to iron out the technical details under the hood and hopefully a day where v3 stacks will be manageable from ui won't be far off.

Not sure if anyone has noticed, but there is a PR open bringing support for compose v3 docker standalone stacks on linuxAMD64 and WindowsAMD64 with fallback to old behavior on arm arch's.
Even better, I am in the middle of testing it so its ready for our 2.1 release at the end of the month :-)

Not sure if anyone has noticed, but there is a PR open bringing support for compose v3 docker standalone stacks on linuxAMD64 and WindowsAMD64 with fallback to old behavior on arm arch's.
Even better, I am in the middle of testing it so its ready for our 2.1 release at the end of the month :-)

Work on this is finally done for Linux AMD64 as well as Windows AMD64 ! It's available via #4713
I'll open a separate issue to enhance our support for the different platforms (mainly arm64) so that we can continue our discussion/investigation in there.

Work on this is finally done for Linux AMD64 as well as Windows AMD64 ! It's available via #4713
I'll open a separate issue to enhance our support for the different platforms (mainly arm64) so that we can continue our discussion/investigation in there.

When is the release for CE 2.1?😃

When is the release for CE 2.1?😃

Codebase is currently frozen and we've started the release testing for version 2.1.0.
It was originally planned for the 28/01/2021 but might be a few days later so early February max.

Codebase is currently frozen and we've started the release testing for version 2.1.0.
It was originally planned for the 28/01/2021 but might be a few days later so early February max.

Awesome work guys! I’m currently running Portainer in Docker. Will 2.1 be released on Docker Hub as well or which installation method is most up-to-date?

Awesome work guys! I’m currently running Portainer in Docker. Will 2.1 be released on Docker Hub as well or which installation method is most up-to-date?

Usual installation method yes, it will be published on DockerHub under the portainer/portainer-ce repository.

Usual installation method yes, it will be published on DockerHub under the portainer/portainer-ce repository.

If anyone wants to get their hands on the pre-release image to try it out, you can do so with the following tag portainerci/portainer:2.1
Please note this is a PRE-RELEASE image not intended for production use, so use at your own risk! 👍🏻

If anyone wants to get their hands on the pre-release image to try it out, you can do so with the following tag portainerci/portainer:2.1
Please note this is a PRE-RELEASE image not intended for production use, so use at your own risk! 👍🏻

Also for everyone watching, there is a known issue when using the build parameter in yml in conjunction with a git repo containing a Dockerfile against agent/edge agent standalone docker windows endpoints. Code is frozen for this release, so it will be mentioned in the release notes and addressed in a future release.
None-the-less, any insight from the community into the cause would be much appreciated!

Also for everyone watching, there is a known issue when using the build parameter in yml in conjunction with a git repo containing a Dockerfile against agent/edge agent standalone docker windows endpoints. Code is frozen for this release, so it will be mentioned in the release notes and addressed in a future release.
None-the-less, any insight from the community into the cause would be much appreciated!

Really solid work. Thanks all of you for the hard work 😃.
One question, is it compatible with ARM architecture from day 1? Or the development of that branch still WIP?

Really solid work. Thanks all of you for the hard work 😃.
One question, is it compatible with ARM architecture from day 1? Or the development of that branch still WIP?

@basudip we'll only support Linux AMD64 and Windows AMD64 in the next version for the reasons stated above.
Here's the follow-up item for Linux ARM64 support: https://github.com/portainer/portainer/issues/4776

@basudip we'll only support Linux AMD64 and Windows AMD64 in the next version for the reasons stated above.
Here's the follow-up item for Linux ARM64 support: https://github.com/portainer/portainer/issues/4776

linuxserver.io uses full ubuntu.
https://github.com/linuxserver/docker-docker-compose/blob/master/Dockerfile.aarch64

Linuxserver.io uses and publishes binaries for both Ubuntu and alpine 😉

linuxserver.io uses full ubuntu.
https://github.com/linuxserver/docker-docker-compose/blob/master/Dockerfile.aarch64

Linuxserver.io uses and publishes binaries for both Ubuntu and alpine 😉

Guys, absolutely briliant work with docker-compose support. I can finally say that it works as it should; A lot of issues are gone.  Thank you!


adjust to backend changes

Description of changes
Please provide a short description of the change or if the change is sufficiently described in the GitHub issue, provide a link to the issue.
How has this been tested?
Please describe the test strategy you followed.

[ ] automated unit test
[ ] automated integration test
[ ] automated acceptance test
[ ] manual, exploratory test

In case of manual test, please document the test well including a set of user instructions and prerequisites. Each including an action, it's result, and where appropriate a screenshot.
Checklist before requesting a review

[ ] My code follows the coding guidelines of this project
[ ] I have performed a self-review of my code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] My code fulfilles all acceptance criteria
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] I have made corresponding changes to the documentation
[ ] I have added explanation of architectural decision and rationales to wiki/adr
[ ] I have updated the changes in the ticket description

Checklist for reviewer

[ ] The code works and does not throw errors
[ ] The code is easy to understand and there are no confusing parts
[ ] The code follows the coding guidelines of this project
[ ] The code change accomplishes what it is supposed to do
[ ] I cannot think of any use case in which the code does not behave as intended
[ ] The added and existing tests reasonably cover the code change
[ ] I cannot think of any test cases, input or edge cases that should be tested in addition
[ ] Description of the change is included in the documentation

When trying to add a stage:


log PUBLISH_TIMEOUT should not print stacktrace

Proposed changes
Issue Number: close #xxx
PUBLISH_TIMEOUT is a very comment error code, should not print stack trace
Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall


Hyper V Host Requirements - Missing Server 2016

[Enter feedback here]
Hyper V Host Requirements are missing Windows Server 2016 (https://learn.microsoft.com/en-us/azure/migrate/migrate-support-matrix-hyper-v-migration#hyper-v-host-requirements)
Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 9976c063-57d6-a904-d685-37680ed31982
Version Independent ID: c67cd9d4-b4f6-d0f6-5032-725431a979d5
Content: Support for Hyper-V migration in Azure Migrate - Azure Migrate
Content Source: articles/migrate/migrate-support-matrix-hyper-v-migration.md
Service: azure-migrate
GitHub Login: @Vikram1988
Microsoft Alias: vibansa

@nellyontour Thanks for your comment! We will review and provide an update as appropriate.

@Vikram1988 Can you respond to the above query?

Thanks for your dedication to our documentation. Unfortunately, at this time we have been unable to review your issue in a timely manner and we sincerely apologize for the delayed response. We are closing this issue for now, but if you feel that it's still a concern, please respond and let us know. If you determine another possible update to our documentation, please don't hesitate to reach out again. #please-close


vectorstores: fix chroma not return score from SimilaritySearch

PR Checklist

[x] Read the Contributing documentation.
[x] Read the Code of conduct documentation.
[x] Name your Pull Request title clearly, concisely, and prefixed with the name of the primarily affected package you changed according to Good commit messages (such as memory: add interfaces for X, Y or util: add whizzbang helpers).
[x] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
[x] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. Fixes #123).
[x] Describes the source of new concepts.
[x] References existing implementations as appropriate.
[x] Contains test coverage for new functions.
[x] Passes all golangci-lint checks.

Other vectorstores's (Except for weaviate, I'll look at why.） SimilaritySearch functions all return the document's score value:

milvus add score in https://github.com/tmc/langchaingo/blob/351b8b52b1bf85a2aab82f6e626468e905e9d662/vectorstores/milvus/milvus.go#L279
pgvector in https://github.com/tmc/langchaingo/blob/351b8b52b1bf85a2aab82f6e626468e905e9d662/vectorstores/pgvector/pgvector.go#L260
pinecone in https://github.com/tmc/langchaingo/blob/351b8b52b1bf85a2aab82f6e626468e905e9d662/vectorstores/pinecone/restapi.go#L170


Support Feature and Story

when it is added support Feature and Story
https://github.com/allure-framework/allure-core/wiki/Glossary#user-story

I guess this feature should be in reporter repository. I opened this one: https://github.com/allure-framework/mocha-allure-reporter/issues/9
Also I'll add some example stories here then

@some-say for now you can use some our abstraction for it:
it('a test', function() {
     allure.addLabel('feature', 'my-feature');
     allure.addLabel('story', 'my-story');
})

this works in beforeEach sections as well

ok, thanks :)


Parameter problems

Thansks your code,in your paper,you set two parameters w1 w2 to balance the weights of PSP net module and warp module, However, in your trained caffemodel, the two parametes are still very close to their initializaion values(w1 =1 ,w2= 0, conv5_4_0_w ,conv5_4_1_w in model) .Why ? @raghudeep

@lxtGH hello, have you already run your training script?  If so, I wonder how you make it work. I got error "out of memory" and don't know how to solve it.

The project does not contain the training scripts, I just run the test scripts but I found the model he provided is not consistent with his paper

@lxtGH Hi!
Have you been able to run the run_netwarp.py script without any GPU out of memory issues ?
Also did you have to modify the .png file names or extract_opticalflow.py file to get it to run?
Thanks

I only run the test, got a little lower performance than the paper , there are some mistakes in the code. You can see my modified version.
Also, I think the paper idea is novel but not work because the learned parameter of flow warp is zero.
it just a psp net


iOS14 always get reachable on 4G  with wrong hostname

Reachability *reach = [Reachability reachabilityWithHostname:@"abcd"];
reach.reachableBlock = ^(Reachability *reachability) {
            NSLog(@"ios14 always reachable on 4G ");
};
[reach startNotifier];

iOS14  x  4G    not OK
iOS14  x  wifi   OK
iOS13  x  4G    OK

我记得以前是可以的... 是啥时候突然不行了？？？

看源码啊，八百年不更新了，那个RealReachablity还支持


Support change passwords flow via env vars

@bparees @mfojtik @mnagy PTAL

@rhcarvalho this is going to set the password every time the pod starts, isn't it?  (even if it's unchanged)
that means if someone edits the password manually and then restarts the pod, the password will be reverted.
here's how i tackled this in jenkins:
https://github.com/openshift/jenkins/blob/master/1.6/run.sh#L29-L34
basically it stores a hash of the password set by the environment variable.  on startup it checks if the hash of the current env value matches the old hash.  if it doesn't, only then does it change the password on the volume.

@bparees I see how you might have arrived into that path with Jenkins, as there is an easy-to-spot way to change the password via UI.
But looking back at the Trello card that originates and motivates this PR,    I fear that going into that direction will make implementation more complex, and the whole flow harder to document. I didn't see much documented on our Jenkins apart from mentioning the env var JENKINS_PASSWORD; specifically, there's nothing stating that you can use it to change Jenkins' password, nor what will be the state of the system once you change it via UI.
The card specifically mentions the "problem" of having the pod template contain an outdated password. It's not much of a problem if we remember that the password is not required to run the container after the first run, but it is a problem of inconsistency -- so I understand consistency is the reason why we went on to propose that

the user will have to change the passwords manually via oc edit

As a side note, instead of suggesting oc edit in the docs, I went on with oc env which is a less error-prone and easier to document solution (and a "must-have" for a pain-free change of POSTGRESQL_MASTER_PASSWORD).
I'm willing to update my opinion in the light of new specs and an updated description in the card.

@rhcarvalho we need to document what consequences the users should expect if he changes the password manually (by connecting to MySQL or via phpMyAdmin?). If user does that, we need to document what he should expect when mysql container is 'redeployed' (iow. you app will not be able to connect because env vars are wrong).

@mfojtik hmm... the env vars in the "app" are independent than those of the ones in the postgresql-master/slave DCs... -- different DCs won't keep common vars in sync. Either that or we have to define better what is "app".
What should the user expect when the postgresql-master is redeployed after she changed the password manually?

@bparees I think we are missing something like 'another deployment changed trigger' in deployment ;-) The use case here is:

I have two deployments: "mysql" and "app"
I change password in "mysql" deployment (oc env)
The "mysql" will redeploy with updated password
The "app" is now broken as it has old environment variables for MySQL

What I think we should do is "app" deployment has "DeploymentChangeTrigger" set to "mysql" and it redeploys the "app" everytime the "mysql" changes.
Maybe we already have something like this, in that case nvmd this comment  ;-)

@mfojtik redeploying the "app" is not enough, we'd need also to update the env var(s). And if the password was changed outside of OpenShift's eyes, there's not much we could do to update env vars anywhere :)

@rhcarvalho redeploying an app means it pick up a new env vars if they are provided by the mysql service (or shared across project)

@mfojtik it is not possible to do that right now. There's no such thing as "project env vars" nor any way to pick up vars from a different DC. I think there are Trello cards for those features, but AFAIK nothing implemented.

@bparees before we merge this, I'll move the main bits about updating passwords to the top-level README, and document the effects of trying to change the password by other means.

Added Changing passwords section to the main README and mentioned that no other method to change passwords is supported in replica/README and "On every deploy, passwords are reset to match the values in the environment variables of the DeploymentConfig 'postgresql-master'."
@bparees PTAL again :pray:

Hmm, need one more fix to support the standalone case.

[test]

@bparees we should be good to go from my side.

failed rhel testing.
[test]

[test]

@rhcarvalho looks like you're going to need to look into the rhel failures.

I have no idea about what is actually failing.... [test]
Don't know how the changes in this PR could work in centos and not in rhel.

Ok ok... way down in the output I see:
pg_ctl: could not start server
Examine the log output.

Hmmm, now on to investigate why it would fail to start the server and where might be the "log output"...

On my (old, pre-systemd) Debian system, i see that Postgres 8.4 keeps logs in /var/log/postgresql.

@rhcarvalho @tnguyen-rh we should log everything to stdout

[test] with some debugging code added...

please [test] again

Test passed for RHEL, now running on CentOS. Seems I fixed the problem :cookie:

:green_heart: green tests, going home!

lgtm, i'm going to merge, but @rhcarvalho it would be good to add a test around this, like in jenkins:
https://github.com/openshift/jenkins/blob/master/1.6/test/run#L122-L136

@bparees FYI I'm looking into writing such a test.


It's all working great for me btw


Custom setting : Increase the amount of train data

First, thank for your help.
Now I'm able to train your keras_ocr in my custom korean characters and it works!
but Now, I want to increase amount of train data.
In fact, the data is automatically generated by image_generators.
Can I increase the number of train data?
the result of below function is
3/827 [..............................] - ETA: 15:44 - loss: 0.0099
may means the train data is 827ea?
How can I increase it to 827 --> 10,000? or 100,000?

detector.model.fit_generator(
    generator=detection_train_generator,
    steps_per_epoch=math.ceil(len(background_splits[0]) / detector_batch_size),
    epochs=1,
    workers=0,
    callbacks=[
        tf.keras.callbacks.EarlyStopping(restore_best_weights=True, patience=5),
        tf.keras.callbacks.CSVLogger(f'{detector_basepath}.csv'),
        tf.keras.callbacks.ModelCheckpoint(filepath=f'{detector_basepath}.h5')
    ],
    validation_data=detection_val_generator,
    validation_steps=math.ceil(len(background_splits[1]) / detector_batch_size)
)

Data is being generated at random and so you can increase the number of steps in an epoch arbitrarily by increasing steps_per_epoch and validation_steps if you're not worried about overfitting.
Closing for the moment since this is not a bug.

thanks for your help. maybe I should look Wikipedia crawler for random background images....


Using types from private class properties results in any types in .d.ts files

🔎 Search Terms
class private any index access
🕗 Version & Regression Information

This is the behavior in every version I tried, and I reviewed the FAQ for entries

⏯ Playground Link
https://www.typescriptlang.org/play/?#code/KYDwDg9gTgLgBAYwDYEMDOa4DEITgbwCg4S4woBLANxRmDgH1yIxhYBPALjjRkoDsA5nAC8cAOTiA3MVIII-XlACuCGNAAUKKIO44IAbXFMoLNjHbiAugEoCskgF9CzoA
💻 Code
export class Foo {
    private _property: string = '';
    constructor(arg: Foo['_property']) {
    }
}

🙁 Actual behavior
Generated .d.ts is:
export declare class Foo {
    private _property;
    constructor(arg: Foo['_property']);
}

🙂 Expected behavior
Generated .d.ts is:
export declare class Foo {
    private _property: string;
    constructor(arg: Foo['_property']);
}
// or
export declare class Foo {
    private _property;
    constructor(arg: string);
}

Additional information about the issue
This behaviour is problematic because it creates a desync between consumers of .ts files and consumers of .d.ts files for the same code.
For example:
new Foo(1);

If the Foo type comes from the .ts file, then TS will error on this code as it can see that the argument type is string.
OTOH if the Foo type comes from the .d.ts file, then TS will NOT error on this code as it sees the argument type as any.

We have just uncovered this at Canva.
A user reported an error showing up in their IDE against our master branch (i.e. code that has passed CI as typechecked).
The code is structured such that the file with the error (A) is in a separate project to the file declaring the class (B).
This means that we have the exact scenario above where (A) consumes (B)'s .d.ts during our CLI builds, but (A) consume's (B)'s .ts within the IDE.
This pattern of declaring a type based on a private property's type is quite pervasive across our codebase and it's surprising that this is the first problem that's been actively revealed.

Essentially a duplicate #29631, #52127. TS intentionally outputs private members without a type in declarations. I imagine the pattern of using  indexed access of private members for declaration files is not supported.

I imagine the pattern of using indexed access of private members for declaration files is not supported

To be clear -- I'm 110% fine if it is an intentionally not supported pattern!
However it should really be a semantic error to do this with declaration: true.
There's a massive footgun that exists here and it's very opaque to try and debug the weird behaviour and bugs that come from it.
If TS errored letting you know that this was going to generate an any then you'd know not to do this and to instead extract the type to an alias and reuse it, or to copy+paste the type.


Project status

Hello,
I wonder if this project is still active or not? There is no activity since months and I got curious.
I also want to know, if there are any papers/articles about blocksim?
Thanks in advance!

Hello @ogurcan,
I've been finishing the paper that I will now present to the 2019 IEEE International Conference on Blockchain.
You can find the paper here: https://www.carlosfaria.com/papers/blocksim-blockchain-simulator.pdf
And the presentation: https://www.carlosfaria.com/talks/blocksim-ieee-blockchain-2019.pdf
And the development will continue, looking forward for any contribution our ideas 💡
Sorry for the late reply

Hello @carlosfaria94,
Thank you for your feedback. I will inspect your paper and presentation with great interest.
Good luck for the conference,
Önder.

By the way, I realized that there are two other blockchain simulators whose names are BlockSim as well  :)
BlockSim: A Simulation Framework for Blockchain Systems
BlockSIM: A practical simulation tool for optimal network design, stability and planning.

Besides, if you and your colleagues are interested, we are organising a workshop on blockchain technologies for robotic systems (multi-agent and embbeded systems as well): https://researchers.pagesperso-orange.fr/bct4ros2019/

Our paper was published here:  BlockSim: Blockchain Simulator


http4s support

Provide an alternate interpreter for http4s clients and servers, utilizing the existing Circe protocol generator.
The initial implementation should use fs2's Task to make clients and servers fit idiomatically into the ecosystem, but adding a switch to support migrating Future-targeted business logic into Task might be desirable.

Closing this issue for now, to separate http4s clients from http4s servers


delete a starred file shows 'no data in ca' error

go to dfc1
select starred
select file (e.g. milton.txt)
Go to info page
use delete action
see 'no data in catalog' error

fixed in testing


[Shopify.dev tutorial feedback] APP::ERROR::INVALID_CONFIG: host must be provided

There needs to be a section within step 2 that talks about how to set up the config before running "npm run dev". Getting the following error
localhost/:1 Uncaught
AppBridgeError2
action: undefined
message: "APP::ERROR::INVALID_CONFIG: host must be provided"
name: "AppBridgeError"
type: "APP::ERROR::INVALID_CONFIG"
stack: "AppBridgeError: APP::ERROR::INVALID_CONFIG: host must be provided"
[[Prototype]]: Error

Feedback received for:

Page: Create an app (/apps/getting-started/create)
Section: Step 2: Start a local development server
Sentiment: Negative

View User Agent Details
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36

@shainaraskas the templates come with that setup by default. Is this by any chance a user that's migrating an existing app or creating their own web/ setup?

I'll go ahead and close it and tell the user to open an issue on https://github.com/shopify/cli if the issue persists.

I'm having this issue, starting a new app project. I'm seeing this error in my console

@manuelmoreno188 What is the URL that you're navigating to? You might see this error when you navigate to the ngrok base URL (e.g. https://<id>.ngrok.io/), but you shouldn't see it if you're using the full URL printed in the console (e.g. https://<id>.ngrok.io?shop=<dev_store>.myshopify.com&host=<hash>)


Help with channel.execute in Swift

Can someone help me understand how to port the obj-c code to Swift? I'm very new at developing for iOS and I am still learning Swift.
I succeeded at connecting to a SSH client but I always get the fatal error: unexpectedly found nil while unwrapping an Optional value error with this part:
var error: NSErrorPointer?
var response: String? = session.channel.execute("ls -la", error: error!)
I feel so stupid asking help for that but I have tried so many things already and nothing worked :(
Thanks in advance.
P.S. Maybe porting all your example to Swift could help other people like me?

It's not a NMSSH issue but this is the solution:
var error: NSError?
var response: String? = session.channel.execute("ls -la", error: &error)


Have a shader chunk at the start to allow injecting custom #extension

See http://forum.playcanvas.com/t/need-advice-how-to-apply-pbr-for-greedy-meshed-voxel-models/1542/19?u=mr_f

Fixed by @nakata0705 in ca49cd45a6288e4deb0bfd495b5f7e1d0962d021


Use proper jaeger-operator version for e2e tests and remove readiness check from DaemonSet

Signed-off-by: Juraci Paixão Kröhling<EMAIL_ADDRESS>

This change is

$ make e2e-tests
Formatting code...
Building...
Sending build context to Docker daemon  76.45MB
Step 1/4 : FROM alpine:3.8
 ---> 196d12cf6ab1
Step 2/4 : USER nobody
 ---> Using cache
 ---> 18305c5b670d
Step 3/4 : ADD build/_output/bin/jaeger-operator /usr/local/bin/jaeger-operator
 ---> c434f7a5f444
Step 4/4 : ENTRYPOINT ["/usr/local/bin/jaeger-operator"]
 ---> Running in 7eb9d4dd84ac
Removing intermediate container 7eb9d4dd84ac
 ---> 268146a7fa55
Successfully built 268146a7fa55
Successfully tagged jpkroehling/jaeger-operator:latest
Pushing image jpkroehling/jaeger-operator:latest...
Running end-to-end tests...
ok  	github.com/jaegertracing/jaeger-operator/test/e2e	167.020s

@dlmiddlecote, this PR removes the readiness check. I thought you might want to get a heads-up on this change.


Test butler as standard application

In our company we are building android testing farm which consist not only from virtual devices but also has some real devices. Installing system signed application on a such device is really painfully.
So  it will be great to have to assembles of this application:

Full-functionality signed with system key
Reduced functionality - unsigned, but still able to rotate screen, disable wi-fi and etc. As this actions may be done by linear application

This is probably not something that will be supported from this project. The goal of Test Butler is to make it as easy and as close to 100% reliable as possible for developers to write stable tests. Real devices are inherently going to be an order of magnitude less stable than emulators, and we don't believe there's much value in running UI tests on real devices (outside of performance testing and monkey testing). Much of Test Butler's current or planned functionality also requires a rooted device, so there really wouldn't be many features that would work on real devices anyway. Plus device OEMs could potential customize their version of Android to where Test Butler would need a lot of OEM-specific code, which we want to avoid.
For a more detailed argument, check out this presentation from Google's Espresso team:
https://www.youtube.com/watch?v=aHcmsK9jfGU

I have watched this video completly.
At the same time Facebook and Google have HUGE farm of real devices.  Here is the article from FB what about google can not find an article
Rotate screen and disable wifi actually do not require root but special permissions only


Node out of sync

Since last night, the node has stopped synchronizing data

Is it still not syncing for you? Why are you not using go-opera?

go-lachesis is not supported. Please use go-opera.


Can't resolve all parameters for AngularFirestore, angular v5

Version info

Angular: 5.0.0
Firebase: 4.6.1
AngularFire: 5.0.0-rc.3
Other (e.g. Ionic/Cordova, Node, browser, operating system):
core-js: 2.5.1
zone.js: 0.8.18
How to reproduce these conditions
just set a new app with angularfire2 and use AngularFirestore in  a constructor
Failing test unit, Plunkr, or JSFiddle demonstrating the problem
check stackblitz: https://stackblitz.com/edit/angular5-firebase2

Steps to set up and reproduce

Sample data and security rules
Debug output
** Errors in the JavaScript console **
Can't resolve all parameters for AngularFirestore: ([object Object], ?).
** Output from firebase.database().enableLogging(true); **
** Screenshots **
Expected behavior
AngularFirestore should work

Actual behavior

Can't resolve all parameters for AngularFirestore: ([object Object], ?).

Follow #1206 for updates. This is an error with Stackblitz however. The output is a warning not an error so Stackblitz should continue and ignore it.

I don't believe it is a Stackblitz error as I'm getting it locally on my machine. Could you please confirm? Thanks

Any one have solution for used firestore inside angular5 version. ?


Web Bloat Score Badge

📋 Description
This badge is for the Web Bloat Score, a website in use by the web-minimalistic community. It calculates the ratio of the website's screenshot size to it's payloads' size sum. Lower means the payloads take less bandwidth, greater means they require more bandwidth than an image of the website would. It also provides some additional information, such as page size, screenshot size. Therefore it's possible to create the following badges! I think they would fit into the "size" section well enough.
Plain score might look something like this:

Whilst a version with a value judgement might look something like this:

For all values below one and a bit (say 1.1):

For all values above 1.1, when the size difference is not critical, but noticable:

For all values 1.5 and above:

For all values 2 and above:

For all values 4 and above:

For all values 8 and above:

Just in case it is also possible to display Page Size and Image Size, however, I don't find them particularly useful or easy to fit on a badge.

I am glad to implement the feature myself, but the ranges for each colour and the necessity of Page Size and Screenshot Size are questionable.
🔗 Data
The API is available through as https://www.webbloatscore.com/Capture. The request body simple enough: { url: "https://www.w3.org/People/Berners-Lee/", timeout : "60" }. The Bloat Score is returned to more than enough significant digits. It also doesn't require any authentication.
🎤 Motivation
As a part of the community that prides themselves on tiny websites and minuscule request payloads, I find demonstrating the website's Bloat Score on it's README as important, as other statistics such as code coverage, commit activity, etc. Making it into a badge would display the value in a format that is already familiar to most developers and will add to README's appeal.

Two things:

Is there any documentation for this API?
I tried requesting this for example.com and it took 9 seconds to return a response. For shields we really need the upstream API call to usually return in under 4 seconds for a badge to be viable. GitHub (which is the place where badges are most commonly viewed) has a hard limit of 4 seconds on an image request so if it takes us >4 seconds to render a badge, they just don't show up.

The API is not documented, no, is that an issue? I assumed it was clear enough.
That is a problem, sadly. It could possibly be solved by caching the value on the server side perhaps? The API generates an image, so no wonder it might take so long. Where is GitHub's timeout limitation mentioned? I can't find it in the docs.

The API is not documented, no, is that an issue? I assumed it was clear enough.

Yes, unfortunately it's a deal breaker issue. We have this guideline called out in our docs because we've had a number of issues in the past with badges that were reliant upon undocumented/unsupported APIs.

That is a problem, sadly. It could possibly be solved by caching the value on the server side perhaps? The API generates an image, so no wonder it might take so long. Where is GitHub's timeout limitation mentioned? I can't find it in the docs.

This is also a deal breaking issue.
https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/about-anonymized-urls
https://github.com/cactus/go-camo
https://github.com/atmos/camo
I'm not sure if GH explicitly document the timeout period, but this project has rather extensive experience and history with github's rendering behavior so we know the general parameters our service needs to work within wrt response times. It's behavior you can replicate/observe fairly easily provided you can find and use a reference to content which takes a few seconds to fetch.
This isn't something we can cache around on our end, but would encourage you to work with WebBloat to see if they'd be willing to expand their offering and API surface to provide a cached version of their score derivation.
Happy to revisit if that comes to fruition and/or circumstances otherwise change, but going to close for now as this isn't going to be viable. If you'd still like to push for these badges then you could consider using our Custom Endpoint, provided you don't mind the badges not rendering in GitHub more often than not (which may or may not be a concern for you depending on where you plan on placing those badges)


Add optional TCP support

This is related to the issue from pm-android about reducing the amount of data used.

Do you mean WebSocket support? Or a long-living TCP connection? The current HTTP API is already using TCP, but making a new connection each request (which probably doesn't have ridiculous overhead since it's once every few seconds, but might be worth getting rid of).

Ah, seems like I don't understand the solutions well enough then. Are either websockets or a long-living TCP connection more viable?

I think WebSockets are a better choice for the job, because they work at a higher level (and we don't really care about the details of the connection, just that it's efficient).


Implement sorting in fastAdapter

Currently for events and attendees page, items are sorted in the fetch request itself while loading from disk or network.
Expected: Implement fastAdapter sorting which will enable run time sorting (ASCEND/DESCEND). Also this will include implementing fastAdapter for events.
@iamareebjamal please label it later

This also can be closed now as currently sorting is handled well while loading itself. @iamareebjamal what do you say?

@mejariamol Implementing sorting in FastAdapter will also fix the flaky tests and enable us to provide a custom sorting feature in future. Like sort by checked in, etc

@iamareebjamal does this issue include implementing fast adapter for events list, as currently the events list is populated through a simple recycler view adapter

Right now we don't need any of fast adapter features in event list

@iamareebjamal so this issue is implemented i think, is there some part left?


Deploying the mover-ui to RTC CLM 5.0.2 with ifix

I  am trying to move with mover-ui  on RTC version 5.0.2, bulk of tasks, stories and epics to new project.
I have used the installation tutorial accordingly, but i am not seeking any add-on tab certainly i can't find the mover-ui  any where. Can any one assist me on this ?
Thanks in advance.

@meran Any update from your side?

Hello @innerjoin ,
I did not have the time to look at it again.
I hope to do it tomorrow.
many thanks

Closed as there was no response. Please reopen if needed

Hi @innerjoin ,
I'm @meran 's colleague, and I was able to get the Add-On menu to appear.
However, the blue button seems to keep loading, and I can't move forward with the Bulk move operation.
I also see there was a problem on service registration, looking on page: https://server/ccm/admin

I also checked the browser for errors (chrome):

I would appreciate your help,
Yael

This is a known issue: https://github.com/jazz-community/rtc-workitem-bulk-mover-service/issues/11

OK I see
Do you have any workaround?

None that I would be aware of. Maybe @SBI- has one...


Use react-table in the panels ?

react-table is used in many projects and it a small component.
https://github.com/tannerlinsley/react-table
And see some examples:
https://github.com/tannerlinsley/react-table/blob/master/docs/examples.md
By using it we would allow:

sorting
filtering (for some big lists)
possibly editable

Was implemented


Clarify the expected format of valueset import URL

It wasn't immediately obvious what the URL syntax should be - hopefully this makes it clearer:

Alternative 1

Alternative 2

Let's go for alternative 2


Date range picker not showing completely

Hi !
I can't select dates in the range-picker because the selector is not displayed correctly (using Brave browser).

The problem seems to come from : frontend/src/DatePicker.tsx  - line 47 or from the component style.
<div style={{ height: '50px' }}>
 ...
</div>

By increasing the height of this div in my browser's development tools, I can display the selector completely, but it shifts the other elements downwards. Ideally, I'd like to display the date selection over what's next.

Updating Streamlit from v1.31.0 to 1.35.0 made the component fully visible on click.
However, as it doesn't appear in the foreground like streamlit's native date selectors and shifts the other elements, there are still display problems depending on where the component is placed.
It's not possible to place it in the sidebar:

Thanks for your feedback，I have bean already find this problem. I will try to show date picker like modal in iframe window, may be in future version to implement it.


Hello, Feng! What is the use of local_maxima in Hungarian match?

Hello, Feng! What is the use of local_maxima in hungarian_bezier_loss.py?
I see that this local_maxima is used as a weight for cls cost, is it used to distinguish instances? I have seen elsewhere that the nms that differentiate instances is the extreme value used to make an offset to add, but here the instances are not all valued at 1? Is this not the purpose? Thx!
https://github.com/voldemortX/pytorch-auto-drive/blob/bf0827a5061301e582493ac19b12d109458bf072/utils/losses/hungarian_bezier_loss.py#L58C5-L58C5

@Rsweater I think it was mentioned in the paper appendix. The flip fusion can make the positive outputs all in one side (e.g., left half of the 1D feature vector). Intutitively, we would like the positive predictions come from meaningful spatial positions, basically they should not be too near. Hence the local maxima.  Anyways, this does not contribute to the final results.

@Rsweater I think it was mentioned in the paper appendix. The flip fusion can make the positive outputs all in one side (e.g., left half of the 1D feature vector). Intutitively, we would like the positive predictions come from meaningful spatial positions, basically they should not be too near. Hence the local maxima. Anyways, this does not contribute to the final results.
It was not for replacing nms, nms is not required here by design.

Sorry, I may be a bit stupid, I'll try to understand: due to the flip, it will cause some extra lines near a certain location, so use max_pool to do a preliminary screening local_maxima? If so, there is a question, why cost_label should be multiplied by it?

@Rsweater I think it was mentioned in the paper appendix. The flip fusion can make the positive outputs all in one side (e.g., left half of the 1D feature vector). Intutitively, we would like the positive predictions come from meaningful spatial positions, basically they should not be too near. Hence the local maxima.  Anyways, this does not contribute to the final results.

The main goal was to **only** let local maximas match gt.

@Rsweater
The main goal was to **only** let local maximas match gt.

I see, Thx！


Prefix some part of MessageExtensions with protobuf.

Working on marking things that aren't part of the public api
with _protobuf.

Added the prefix to the set() method also since it also seems like it should be internal.


Feature request: try different zones if the one specified in config does not have enough resources

What feature do you want to see added?
Hello,
would it be possible to have an option to use multiple zones for launching agents? Right now if a zone is exhausted, the plugin will not handle it so well: there will be many agents created (above the limit set in config) but they will fail to start, and while deleting them works, it also triggers an exception within Jenkins. Here's a log snippet:
2022-06-10 10:50:47.296+0000 [id=4267]	INFO	c.g.j.p.c.ComputeEngineComputerLauncher#launch: Launch failed while waiting for operation operation-1654858230641-5e115b4fdb4d9-33d8d6e8-ec232c0f to complete. Operation error was The zone 'projects/censored/zones/us-west1-b' does not have enough resources available to fulfill the request.  '(resource type:compute)'.

It would be good to have an option to try different zones from a preconfigured set if one zone doesn't have enough resources.

Exception when deleting an agent that failed to start
2022-06-10 10:50:15.593+0000 [id=3700]	WARNING	h.i.i.InstallUncaughtExceptionHandler#handleException: Caught unhandled exception with ID 95d9316f-d4ab-4107-a055-c25f7c2f40a8
com.google.api.client.googleapis.json.GoogleJsonResponseException: 404 Not Found
{
  "code" : 404,
  "errors" : [ {
    "domain" : "global",
    "message" : "The resource 'projects/censored/zones/us-west1-b/instances/jenkins-agent-dynamic-jtiut7' was not found",
    "reason" : "notFound"
  } ],
  "message" : "The resource 'projects/censored/zones/us-west1-b/instances/jenkins-agent-dynamic-jtiut7' was not found"
}
	at com.google.api.client.googleapis.json.GoogleJsonResponseException.from(GoogleJsonResponseException.java:150)
	at com.google.api.client.googleapis.services.json.AbstractGoogleJsonClientRequest.newExceptionOnError(AbstractGoogleJsonClientRequest.java:113)
	at com.google.api.client.googleapis.services.json.AbstractGoogleJsonClientRequest.newExceptionOnError(AbstractGoogleJsonClientRequest.java:40)
	at com.google.api.client.googleapis.services.AbstractGoogleClientRequest$1.interceptResponse(AbstractGoogleClientRequest.java:321)
	at com.google.api.client.http.HttpRequest.execute(HttpRequest.java:1056)
	at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:419)
	at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:352)
	at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.execute(AbstractGoogleClientRequest.java:469)
	at com.google.cloud.graphite.platforms.plugin.client.ComputeWrapper.deleteInstance(ComputeWrapper.java:116)
	at com.google.cloud.graphite.platforms.plugin.client.ComputeClient.terminateInstanceAsync(ComputeClient.java:323)
	at com.google.jenkins.plugins.computeengine.ComputeEngineInstance._terminate(ComputeEngineInstance.java:136)
	at hudson.slaves.AbstractCloudSlave.terminate(AbstractCloudSlave.java:88)
	at com.google.jenkins.plugins.computeengine.ComputeEngineComputer.doDoDelete(ComputeEngineComputer.java:181)
	at java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
	at org.kohsuke.stapler.Function$MethodFunction.invoke(Function.java:398)
	at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:410)
	at org.kohsuke.stapler.interceptor.RequirePOST$Processor.invoke(RequirePOST.java:78)
	at org.kohsuke.stapler.PreInvokeInterceptedFunction.invoke(PreInvokeInterceptedFunction.java:26)
	at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:208)
...

Upstream changes
No response

@vlad-ivanov-name, Is this another root cause besides the GCP compute bug? Could it be a quote issue?
It might be a running issue (https://stackoverflow.com/questions/52684656/the-zone-does-not-have-enough-resources-available-to-fulfill-the-request-the-re).
I was just thinking out loud

We also saw similar issues in the London region at roughly the same time - this was indeed caused by resource exhaustion inside GCP, and not by any project quotas.
Ideally, the plug-in would catch this failure and continually retry (potentially with some kind of exponential back off?) until it was successful.
Alternatively, the plug-in could use Instance Groups to keep track of the pool of VMs, although I imagine that would involve a fair amount of work internally as the pool management logic would change.

We would love to have this feature. About each week our builds get stuck with ZONE_RESOURCE_POOL_EXHAUSTED in some zone of europe-west1 and require manual intervention to unblock pull requests or releases.
I guess some cases could already be fixed by round-robin over all zones of this region. Using a specific zone is not an issue for our builds, any zone would be sufficient.

+1 would love to have this feature


Some PWA's have extension as .webmanifest or .js

Some PWA's have extension as .webmanifest . This line needs to handle them
https://github.com/mariusclaret/outweb/blob/a0299c63c979f203bdd492572bed3d3085da95a1/source/script.js#L579

Some great apps, such as https://hightide.earth and https://poopsweeper.firebaseapp.com, are out of the store because they use .webmanifest.
The support for .webmanifest would be very helpful


Hrm. I think I'd want the last commit message used in vscode (for that workspace folder). Because the last commit message could easily not be mine, etc -- feels less predictable.

/duplicate #26952


/Users/beraybentesen/Downloads/sj/third_party/sciencejournal/ios/Protos/SensorLayout.pbobjc.h:108:46: Expected ';' at end of declaration list

New Issue Checklist

[x] This is an issue for the open source project, not the App Store Science Journal App
[ ] Updated Science Journal iOS to the latest version
[x] I read the Contribution Guidelines
[x] I searched the forums for help Science Journal forums
[x] I searched for existing GitHub issues

Issue Description

Environment

iOS version tested ______
Device type (iPhone/iPad/etc) ______
Xcode version (if applicable) ______

/third_party/sciencejournal/ios/Protos/SensorLayout.pbobjc.h:108:46: Expected ';' at end of declaration list

SensorLayout.pbobjc.h is a class generated by the Protobuf library based on sensor_layout.proto. We don't control the syntax. Are you having trouble building?

Yes, the mentioned error occurs.

I'm not seeing this error and I wonder if it might be an issue with your version of protobuf. Currently we only support 3.1. Can you verify your version by running protoc --version on the command line, and confirming it says libprotoc 3.1.0?

Closing the issue for inactivity—If you're still seeing this problem, please feel free to re-open. Thanks!


373 Don't generate dummies for removed methods in SerializationContex…

Closes #373

@tristantarrant Your commit message needs to have one of the GH keywords in it in order for the GH UI to link the two.
I suggest Closes #373 in the body of the message.


v1.8.1 not pushed to npm yet

$ wrangler --version
bash: .../AppData/Roaming/npm/wrangler: No such file or directory

$ npm i @cloudflare/wrangler -g
...
><EMAIL_ADDRESS>postinstall C:\Users\tomby\AppData\Roaming\npm\node_modules\@cloudflare\wrangler
> node ./install-wrangler.js

Downloading release https://workers.cloudflare.com/get-npm-wrangler-binary/1.8.0/x86_64-pc-windows-msvc
wrangler has been installed!
+<EMAIL_ADDRESS>added 34 packages from 21 contributors in 2.875s

Your crates.io badge has v1.8.0 as well.

We've published!

Yes, cheers


Make article width take up whole page in absence of secondary sidebar

Fixes #736

before:

after:

Before my change, _article.scss contained the flex-grow: 0 hack. The hack was there so the absence of a sidebar doesn’t result in a super wide content area, but it had the side effect of making the content area collapse to a super narrow width in that case.
Removing that hack makes it fill more than the absolute minimum horizontal space. I then added max-width for making it not take any more space than it should and justify-content: left for not moving to the right. Those three changes replace the hack with a more robust solution.

this is really helpful context, thanks for sharing!


feat: adding restoreOriginalOnUnmount to useTitle

Description
New option added to the UseTitleOptions interface that will restore the first title passed into useTitle, as requested in issue #2561. I used useMemo to memoize it, I also added one test case to make sure it would pass. One issue that I need help with is determining what to do if both restoreOnUnmount and restoreOriginalOnUnmount are both true at the same time. I'm not sure how that should be handled.
Type of change

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

Checklist

[x] Read the Contributing Guide
[x] Perform a code self-review
[x] Comment the code, particularly in hard-to-understand areas
[ ] Add documentation
[ ] Add hook's story at Storybook
[x] Cover changes with tests
[x] Ensure the test suite passes (yarn test)
[ ] Provide 100% tests coverage
[x] Make sure code lints (yarn lint). Fix it with yarn lint:fix in case of failure.
[x] Make sure types are fine (yarn lint:types).

Hi @gavinbm,
I agree having both options makes little sense. You either want to restore to the previous, the default or not at all. What about an enum instead of a boolean?
restore: 'previous' | 'default' | 'off' (or null/undefined)


Add support for template-haskell-<IP_ADDRESS> in GHC-8.2

The DataD and NewtypeD constructors are changing.
See:https://ghc.haskell.org/trac/ghc/wiki/Migration/8.2

Thanks @duog! I'll merge this and release if no one else does, but I'm currently trying to foist maintainership onto someone else, as per #6, so let's see if @tomberek @mgajda wants to do it first (or if you want to become a maintainer!).

Thanks; I'm not a user, I just needed this as a dependency.

I'm neither a user nor someone with a dependency, hency why I'm trying to pass it on to someone who is more invested in it.

I am afraid @tomberek is better address ATM. I am time strained Now.
On Fri, 23 Jun 2017 at 06:06, Neil Mitchell<EMAIL_ADDRESS>wrote:

I'm neither a user nor someone with a dependency, hency why I'm trying to
pass it on to someone who is more invested in it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ndmitchell/derive/pull/24#issuecomment-310515872, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAp12ZsOsnfK4vngmVi0XzAJu8QNSBAwks5sGuVegaJpZM4OBtQm
.

Thanks @duog - I merged, tested and made a release.


[APRComp24] ET

(I am trying to rebase this commit to the dev branch instead. Seems that I have to reopen a new pull request for this purpose.)