Docker tty is not a tty with docker exec

When I enter a running docker with "docker exec -ti mydockerinstance /bin/bash"
tty returns: not a tty and tmux doesn't work.
I tried several things from https://github.com/docker/docker/issues/728:
docker exec -ti mydockerinstance sh -c "exec >/dev/tty 2>/dev/tty </dev/tty && /usr/bin/tmux -s /bin/bash"
getty tty
but nothing succeded.

can you all let me know if this is still a relevant issue.

Yes, it's still relevant.

So, what image are you running, and with what run command, and what exec command?

@cpuguy83 I am running an image based on ubuntu:14.04 via the most recent boot2docker. I have experienced the same problem with all previous versions of docker / boot2docker which I've used in recent months.
Here are the steps which can be used to reproduce the problem.
# on the docker host
docker run -it --rm --name foo ubuntu:14.04 bash
# inside the container
apt-get update
apt-get install tmux
tmux

In another terminal on the host:
docker exec -it foo bash
# inside the container
tmux ls

The latter command will fail, and tmux will crash in the original terminal, in some cases killing the container altogether and/or turning it into a container-zombie (in which case one must boot2docker restart and then docker rm to get rid of it).

It seems that any image which has bash in it has the problem.
Step to reproduce:
docker run --name no_tty -dti ubuntu /bin/bash (or whatever)
docker exec -ti no_tty /bin/bash
tty -> not a tty

Any chance a fix for this bug will land in 1.5.0?

So what is the purpose of using docker exec to fire up a tmux session?

We use docker with ansible as a developer workstation, with this we have a
reproductible environment among all the developers
And as a developer, I use tmux. QED :)
If you are interested, here is a quickstarter
https://github.com/MichaelBitard/docker-ansible
Le Thu Feb 05 2015 at 5:27:03 PM, Brian Goff<EMAIL_ADDRESS>a
écrit :

So what is the purpose of using docker exec to fire up a tmux session?
—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/issues/8755#issuecomment-73076066.

@cpuguy83 when working in "dev mode" with my containers, I generally pass -it to docker run and fire up tmux (i.e. when it seems useful to me to do so). It would be extremely useful (to me) to be able to fire up tmux in the context of exec -it, regardless of whether -it had been passed to run. At present, since the environment provided by exec is not a tty – even when invoked with -it flags (a pseudo-TTY is not actually allocated, apparently) – it's not possible to use it in this way. At the very least, perhaps the --help output of exec ought to be amended to indicate that it's -it option has limitations relative to run -it.

i also use docker for my development environment. this is why i run tmux
inside a container.
On Thu, Feb 5, 2015 at 1:04 PM, Michael Bradley<EMAIL_ADDRESS>wrote:

@cpuguy83 https://github.com/cpuguy83 when working in "dev mode" with
my containers, I generally pass -it to docker run and fire up tmux (i.e.
when it seems useful to me to do so). It would be extremely useful (to me)
to be able to fire up tmux in the context of exec -it, regardless of
whether -it had been passed to run. At present, since the environment
provided by exec is not a tty – even when invoked with -it flags (a
pseudo-TTY is not actually allocated, apparently) – it's not possible to
use it in this way. At the very least, perhaps the --help output of exec
ought to be amended to indicate that it's -it option has limitations
relative to run -it.
—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/issues/8755#issuecomment-73128033.

@michaelsbradleyjr +1 on Michael's comments.
To add a bit more to the use case:
I use a  docker image as my dev environment.
The connection to the host often drops.
The image itself is designed to run monit(proc monitor), not bash, and I connect to it by way of -exec -ti bash
Then I would like to tmux attach and be back to where I left off.
If somebody has a better suggestion how to accomplish this, I appreciate your comments.

+1

+1!

I've just hit this. It's blocking me from sharing my environment with another developer in realtime, which is a problem.

This is what I do now:
run tmux on the docker host, not inside docker, and docker session in one of tmux's windows.
this achieves my goal explained above.

Unfortunately I run coreos and running tmux on the host is not desirable, because I don't want to modify the host image at all, just run docker images for everything. This bug impedes that.
On 18 March 2015 22:17:15 GMT+00:00, dbabits<EMAIL_ADDRESS>wrote:

This is what I do now:
run tmux on the docker host, not inside docker, and docker session in
one of tmux's windows.
this achieves my goal explained above.

Reply to this email directly or view it on GitHub:
https://github.com/docker/docker/issues/8755#issuecomment-83205365

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

I have a workaround :
docker exec -ti `your_container_id` script -q -c "/bin/bash" /dev/null

Ok, it's an ugly one, but with it you can use tmux when you use docker exec

Things like sudo and su are also broken by not having a tty in the container.

Also pacman in Arch fails with
error: GPGME error: Inappropriate ioctl for device

because of TTY 404.

  I want to share a GNU Screen session among two developers in the same dicker instance.  Thanks to @MichaelBitard  (Mars 19) for the temporary work-around!

I can only assume that this is what means page up and down don't work in less.

Found another instance where this is a pain in the ass...
docker-machine ssh "docker run -ti ubuntu bash"
time="2015-05-11T19:15:20Z" level=fatal msg="cannot enable tty mode on non tty input"
FATA[0000] exit status 1

You can allocate TTY by wrapping the original command with script, as mentioned in the previous comments.

A super simple example to reproduce:
docker exec -ti $CONTAINER_NAME tty
=> not a tty

Fun stuff that test -t 0 returns zero in exec.

So isatty returns 1 for STDIN_FILENO, but ttyname returns NULL.

This is because there is no /dev/pts/ files inside container mount namespace.

 This is also done by ttyname AFAIK (I probably should test this). However, it is not really a good indicator of whether an fd is a tty if the symlinks inside /proc/self/fd/ are not pointing to real locations on the filesystem.

@cyphar Yup, it is really tty, but tty tool using ttyname first, so it fails.

I'd ask if we should send a whole bunch of upstream patches to fix this, but I have my doubts that they'd land (or even solve this problem for us in the next few years). Is there a way we can create the pts inside the container's mount namespace, so the tty magic symlinks aren't broken?

@cyphar I think it is possible to do if mount outside /dev/pts/<num> to containers dev in nsexec.c like we mounting it to /dev/console for main process.
Or it is possible to use container's devpts, but we need somehow to take fd from inside mount namespace back to docker.

The docker Windows client (from Boot2Docker) runs ok ("docker run --rm -ti ...") on a Windows text prompt, but fails with this very same error when called from CygWin.

@andrefernandes that's a different issue. This issue is specifically for docker exec. What you're describing is probably (related to) this issue: https://github.com/docker/docker/issues/12469

@andrefernandes This is a server-side issue, it's because TTY allocation on the Linux host isn't being done by us correctly.

Just found this issue after having issues with tmux and su.  Has anyone come up with any patches yet?

@senorsmile Did you read the previous comments? There are workarounds.

I have read the previous work arounds, but haven't gotten any of them (yet)
to properly start up the container with what I need running while enabling
me to use things like tmux via docker exec.
On Thu, May 28, 2015 at 2:40 PM Zachary Adam Kaplan <
<EMAIL_ADDRESS>wrote:

@senorsmile https://github.com/senorsmile Did you read the previous
comments? There are workarounds.
—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/issues/8755#issuecomment-106607762.

There is definitely a working solution to this problem, however unideal it may be. I'm not sure why you can't get it to work, especially given that you haven't posted any of your actual code. You may have better luck asking a friend or sitting in IRC. If you want to send me an email with your code, I'll be more than happy to look at it and see if I can't figure out why it doesn't work for you.

I have figured out what I was doing.  For some reason I kept reading that the docker RUN had to have the 'script /dev/null' call when starting the container.  But, that's not it.  It's only required for the docker exec.  The workaround is now working for me.  Thanks!

hitting this with lxc

That's impossible you can't use exec w lxc
On Monday, June 8, 2015, Linas Vepštas<EMAIL_ADDRESS>wrote:

hitting this with lxc
—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/issues/8755#issuecomment-110022778.

if you say so.

@linas Can you expand a bit? I'm curious as to why there seems to be a misunderstanding with exec and lxc.

The lxc equivalent is "lxc-attach" and when you lxc-attach to a running container, there is no tty. Same error messages, same workaround.

That is not a bug with "docker exec" then... You cannot run docker exec with the lxc driver

Great, well at least we're getting somewhere. Perhaps we can use this as a clue to fix the underlying issue.

The underlying issue is that we allocate a PTY outside the container's mount namespace (so the PTY devices aren't inside the container's /dev partition), so the pseudomagical /proc/self/fd/{0,1,2} symlinks are "broken". This breaks the way that things like su check if it's being run in a TTY --stat(ttyname(0));.

Yes, and for main process we mount pty inside as /dev/console.

@LK4D4 Which we don't do for docker exec processes, right?

@cyphar No, it should be in nsenter/nsexec.c before joining mount namespace.

@LK4D4 If you're referring to namespaces/nsenter/nsenter.c, I don't think we do. We just dup2 the console fd over {0,1,2} and we don't mount it in the child's namespace. If we do mount it in the child's namespace, we should be reopening the fd so that they point to a valid symlink.

@cyphar Yeah, I mean that we should, but we don't :)

@LK4D4 Yup. If you want, I can write a PR to fix this. We actually can't mount it as /dev/console, we'd have to mount it under /dev/pts/*. We could do this in Go startInExistingContainer (nsinit/exec.go) by changing the console path to point inside the container and just update namespace/nsenter/nsenter.c to open after fork(2)ing. Or we could do the mount shenanigans inside namespace/nsenter/nsenter.c and not update the Go portion at all.

Just wanted to note I'm hitting this issue too with nano.

@cyphar I suspect that your suggestion of mounting it under /dev/pts/* won't work. For one, you'll find you can't bind mount anything in /dev/pts because it's a special filesystem which doesn't allow file creation. For two, even if you could bind mount it, if a process inside the container created lots of pseudoterminals, it could end up colliding. That's because the devpts filesystem is namespaced (due to the newinstance option) and maintains its own numbering. I now believe may be enough information in #11462 to fix this issue.

I'm not sure this is the same problem I was trying to solve, but nevertheless I will share it with you. I guess it's only relevant if you are using Windows.
I wrote a simple workaround / quick fix to allow using Docker Toolbox from Babun, it may help some of you:
https://github.com/tiangolo/babun-docker
With that you can keep using your docker commands as normal.
And if you are using Cygwin, you should use Babun, a very improved version of Cygwin.

You just have to run one command to setup everything. Although I encourage you to check the source code before running any script (including mine) in your terminal.
Inside, it installs and sets up winpty, and tries to start your default docker-machine VM and set up its environment.
Maybe it gets more relevant now since newer versions of Docker Toolbox come with Git 2.5, which uses mintty and has the same problem of "cannot enable tty mode on non tty input" as in Babun.

@cyphar are you still working on nsexec to mount pts in exec?

@runcom, no sorry. I looked at it, from what I can see you'd need to come up with some way of accessing ptmx in the devpts of the container in the host so you can . Unfortunately, we create then unmount it.

+1

USER POLL
The best way to get notified when there are changes in this discussion is by clicking the Subscribe button in the top right.
The people listed below have appreciated your meaningfull discussion with a random +1:
@sjfloat
@jmreicha

So I'm hitting this with centos:7 and ubuntu:14.04 containers, but not with centos:6 image
centos:6
docker2:~/git/docker⟫ docker run --name "foo" -ti centos:6 /bin/bash
[root@238531079dc9 /]# tty
/11

docker2:~⟫ docker exec -ti "foo" /bin/bash
[root@238531079dc9 /]# tty
/dev/pts/13

ubuntu:14.04
docker2:~⟫ docker run --name "foo" -ti ubuntu:14.04 /bin/bash
root@2514de9fb217:/# tty
/dev/console

docker2:~⟫ docker exec -ti "foo" /bin/bash
root@2514de9fb217:/# tty
not a tty

So this looks like an issue with the contents of the image rather than docker itself.  Something about the lxc hooks in the user space libs or scripts?

@gentili: unfortunately your discovery only amounts to a difference between the behaviour of tty in centos6 vs ubuntu:14.04. There is still not a functional tty inside the exec - just do ls -la /proc/self/fd/0 and see that it's a broken link pointing to a pts which doesn't exist.
If you run strace, you can see the difference in behaviour. Ubuntu does this:
readlink("/proc/self/fd/0", "/dev/pts/12", 4095) = 11
stat("/dev/pts/12", 0x7fffa84b3a10)     = -1 ENOENT (No such file or directory)

(Then it iterates over a load of devices in /dev before finally giving up). And CentOS:
readlink("/proc/self/fd/0", "/dev/pts/7", 4095) = 10
fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 7), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8db98c3000
write(1, "/dev/pts/7\n", 11/dev/pts/7
)            = 11

@pwaller Precisely, because the actual bug we're dealing with is that certain standard libraries assume that the symlinks in /proc/self/fds/ must be valid symlinks. Clearly CentOS does this properly (although, I don't like the fact that in docker run you get /11 which is invalid), but we need to fix this for all containers.

Uh, is assuming /proc/self/fds is a valid symlink a bug? It seems not a bug to me, but a valid thing to do, if you want to know who your stdio is connected to under normal circumstances. My interpretation of the situation is that the problem here is that the pts doesn't exist inside the container (see also: #11462).

The actual value of the symlink doesn't affect whether or not it works as a PTY, AFAICS it's an unnecessary restriction (a bug). But yes, the problem that causes the /proc/self/fds symlinks to be invalid is due to the way we deal with the pts namespace. I just don't agree that the assumption is correct (I'm fairly sure a more accurate way to check that the output is a TTY is to attempt to use the TTY-specific ioctls and see if the call fails).

Hey, lots of daemons dettach from their controlling terminal, and so their /proc/self/fds/0,1,2 will be closed.  The issue here is that there is a reasonable expectation that attaching to a running container should work; i.e. the std fd's will not be closed.
Put it a different way: the issue is not whether /bin/bash is performing stat or testing for tty's with ioctl -- its that users expect to be able to get a tty and run bash in it, when attaching to a container, and when the users try this, they are disappointed that it didn't work.

@linas Agreed.  docker exec --help says:
  -i, --interactive=false    Keep STDIN open even if not attached
  -t, --tty=false            Allocate a pseudo-TTY

So I don't think it's unreasonable to expect all the usual pty related machinery including /dev/pts/ to work as you'd expect.

The problem is that the tty is created outside on the host and there is no reference to it in the container like how /dev/console is setup in the primary container. One options to fix this would be allocate and bind mount the devpts from the host in to the containers. I will try that out and report back.

I came to open a bug because "docker exec -t" does not create the TERM variable, while "docker run -t" does.
I guess this is the same issue!
At least the doc could mention that "-t" has a slightly different effect with "run" and with "exec".

@hervenicol That is an entirely separate issue (please open a separate issue for it). This issue is about docker exec not creating a TTY (this is unrelated to environment variables).

@hervenicol @cyphar you're looking for #9299

Thanks aidanhs. I added my comments in :)

Quoting @brauner from lxc/lxc#554 "This is a known bug in glibc and @hallyn has send a fix to glibc (https://sourceware.org/ml/libc-alpha/2016-08/msg00307.html). It just needs to be applied."
Serge's fix is surprising and elegant.

While @hallyn's fix helps solve the isatty() problem, there are other issues that we have inside runC that mean that even with that fix we still need some work here.

What other issues? Are you saying that you built Serge's fix, tried docker exec -ti mydockerinstance /bin/bash or the tmux variant, and it still doesn't work?

runC doesn't create consoles inside the devpts of the container. I'm not entirely sure whether @hallyn's fix will fix tmux for Docker (but I know that lxc correctly handles the devpts problem -- I'm currently working on it in runC). I haven't tested it because custom-compiling glibc sounds like a bad idea. :wink:
There are also larger issues that are caused by the devpts handling in runC that will not be fixed by glibc (they have to be fixed within runC).

OK. Building glibc can be a pain if you've never done it before, but its not too bad. Its not like gcc.

@cyphar I've never done it, so I can't really speak to it, but I did find some info on the sourceware wiki, section Compile normally, run under new glibc  :

Use this if you want to be able to run your application easily with the newly built libc and then again with the system libc for comparison.
Compile your test program, and invoke it with the newly loader you built. This is also how the make check runs tests. Note: if the executable under test resides in the current directory, don't forget to use ./ before the name.
Use either testrun.sh in the build directory e.g.
$ cd $HOME/build/glibc
$ ./testrun.sh /path/to/test/application

Is that at all helpful?

For those who use Cygwin:
C:\cygwin64\Cygwin.bat works for me.

Cc @crosbymichael!

This should be fixed with runc 1018
Sent from my iPhone

On Sep 9, 2016, at 6:05 PM, Arnaud Porterie<EMAIL_ADDRESS>wrote:
Cc @crosbymichael!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

For this issue, I just download winpty from https://github.com/rprichard/winpty/releases (the cygwin version one), then extract it to my git bash, then prefix 'winpty' to every command that have this issue . Maybe it'll help :).

@imamassi script will also work. The fix exists within runc (opencontainers/runc#1018) but because it's quite a large change it's not been merged yet. We're hoping to get it merged by the end of the month (in time for OCI 1.0-rc2).

I've just got hit by this. I run an emacs daemon and connect to it with emacsclient. emacsclient gets angrey at me saying: emacsclient: could not get terminal name.
I connect to my docker container running emacs daemon through docker exec. Applying @MichaelBitard's solution (docker exec -ti your_container_id script -q -c "/bin/bash" /dev/null) sealed the deal. But there are some minor colors artifacts.

With a container based on debian:8.6, to get both color support (e.g. for ls) and tmux working I had to use:
docker exec -it my-container env TERM=xterm script -q -c "/bin/bash" /dev/null

@fernandoacorreia in docker 1.13, when you add -t, it will automatically set TERM=xterm see https://github.com/docker/docker/pull/26461

+1
$ docker exec -it newimage bash << EOF
> echo "Test"
> EOF

opencotnainers/runc#1018 has been merged. This can be closed as soon as Docker vendors the latest commit of runc.

No way!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 🎊 🎉

ping @mlaventure ^^

hi @cyphar, little lost here. So will this be fixed in docker 1.13?

@ninrod No, because it's too late for the changes to be merged into 1.13 (the RCs have already been released). I would expect it will be fixed in 1.14 (when Docker starts using the newer version of runC).

Does anyone know if the fix that @cyphar referenced earlier has made it into a Docker release? I'm running Docker version 17.03.0-ce, build 60ccb22 and the connection created with docker exec is still not a tty, so programs that require a tty fail to run.

I believe that opencontainers/runc#1356 was also blocking this, since @crosbymichael mentioned that docker exec had some issues with the new console-handling code.

the containerd v0.2.x branch in uncompatible with master runc. This change can't just be cherry-picked in the current version that containerd depends on.
We're mostly on maintenance mode on v0.2.x until 1.0 is ready, and given there seem to be a workaround, this is not critical enough IMHO.
But if someone is willing to do the update on the v0.2.x branch and test that again docker, a PR is more than welcome! :angel:

@mlaventure I think its a simple fix to change v0.2.x to support this.  We need the testing so its worthwhile to integrate it into that branch.

Sorry, can you verify if I follow correctly Is a fix for this expected to land in the next official docker release?

Hello everyone, I'm going to attempt to put some time into this, and see if I can get the fixes (wherever they may be required) in place, so we can close this issue once and for all. I'll report back here with an update as soon as possible.

@ninrod i cannot guarantee anything but we will try

I spent a couple hours on this last night, mostly to get over the learning curve. I think I understand the majority of what I need to complete this. Most of the work is actually already done, and @crosbymichael has graciously offered to provide guidance as necessary. I'll give another update later tonight.

Ok so a quick update; I think I can get this finished in a few days...
At this point I have my development environment up and running, such that I can iterate on the containerd codebase.
However, I've become stuck; I'll ping @crosbymichael tomorrow for help, but I can't seem to start an OCI bundle that was created via runc spec with ctr containers start... and I need to be able to use ctr containers exec to test my changes.
I'm using the docs here https://github.com/docker/containerd/blob/v0.2.x/docs/bundle.md to create the OCI bundle. I'm able to run the bundle using runc start (version v0.0.9), but as mentioned when trying to start the container using ctr, I get the following error:
$ ctr containers start redis $PWD
[ctr] rpc error: code = 2 desc = shim error: context deadline exceeded

Once I get this working, dropping in the changes should be as simple as consuming the https://github.com/crosbymichael/go-runc bindings that already support the new console functionality.

@razic this stuff is so advanced that I can't follow a word of what you've just said, but sounds promising. I'm eagerly waiting for this. Thanks for working on it.

Quick update... I was able to get a container running via ctr, so I think I may have gotten over that hump. I've been learning a lot about how the whole thing works (containerd-shim etc). I think I now have everything I need to be able to test my changes once I implement them. Will provide another update soon.

Fixed by #33007

And there was much rejoicing.

awesome!!!! please gentleman, in what docker version can I grab this fix?

This will be in 17.06

Will this land in an edge release before that? Was it landed in 17.05.0-ce-mac11? Any pointers on where to check this? :)

No, this won't be in 17.05, only 17.06 and upward

Okay, thank you! Is there a release date set? Sorry for asking so many questions :) tried googling first but didn't find it, maybe I just a missed it thoug...

The version is YY.MM, and we target first week of the month, so first week of June, with release candidates before that

Ah, that's great to know, thank you!

Great news @thaJeztah !

Hi @thaJeztah, is 17.06 going to land in in june or will it be rescheduled for july? if so, will it be 17.07 instead? just wan't to be sure regarding the version that will have this fix landed.

zacharys-pro:dev razic$ docker run --rm -t -d ubuntu bash
83c292c8e2d13d1b1a8b34680f3fb95c2b2b3fef71d4ce2b6e12c954ae50965a
zacharys-pro:dev razic$ Docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
83c292c8e2d1        ubuntu              "bash"              2 seconds ago       Up 1 second                             xenodochial_bardeen
zacharys-pro:dev razic$ docker exec -ti xenodochial_bardeen tty
/dev/pts/1
zacharys-pro:dev razic$ docker version
Client:
 Version:      17.06.0-ce
 API version:  1.30
 Go version:   go1.8.3
 Git commit:   02c1d87
 Built:        Fri Jun 23 21:31:53 2017
 OS/Arch:      darwin/amd64

Server:
 Version:      17.06.0-ce
 API version:  1.30 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   02c1d87
 Built:        Fri Jun 23 21:51:55 2017
 OS/Arch:      linux/amd64
 Experimental: true

Great work everyone. Thank you very much.

is this released? where?

@ninrod I've included the version information in the output. This is fixed in version 17.06.0-ce, which is the most current stable version. If you are using Docker for Mac, you can simply restart the application, and you should be prompted to upgrade.

Oh. but this is not ready yet for docker for windows, right?

just tested it on Docker-for-Mac latest and it works. I'm a happy man :-)


Screen Capture: Huge corrupted image getting generated

Which version of PhantomJS are you using? Tip: run phantomjs --version.
2.1.1

What steps will reproduce the problem?

Execute the following code:
var page = require('webpage').create();
page.viewportSize = { width: 1260, height: 800 };
page.open('https://www.onlinegambling.ca/real-money.php', function() {
page.render(’screenshot.png');
phantom.exit();
});

Which operating system are you using?
Linux and Mac

Did you use binary PhantomJS or did you compile it from source?
binary

Please provide any additional information below.
The screenshot getting generated is huge in size and it is causing google chrome to hang / crash when the image is loaded in it. Firefox says "Error in image data".

viewportSize is only changes "browser" resolution, not effects which part to be rendered. Try with clipRect: http://phantomjs.org/api/webpage/property/clip-rect.html

Yes the viewportSize is for defining the browser resolution. But in my case, the screenshot getting generated has width of more than 60,000 px. I have defined the viewport width as 1260.

I tested it and like you said it gives huge image output. Don't know what causes it but i get more desirable output with using clipRect and tingling with the zoomFactor.
For example; this:
var page = require('webpage').create();

page.viewportSize = { width: 1260, height: 800 };
page.clipRect = {
  top: 0,
  left: 0,
  width: 1260,
  height: 800
};
page.zoomFactor = 1.5;

page.open('https://www.onlinegambling.ca/real-money.php', function() {
  page.render('screenshot.png');
  phantom.exit();
});

Gives this (on windows).
Hope it helps.

The solution suggested by you is giving the screenshot in mobile view. The requirement at our end is to have the screenshot at 1280 resolution.
I debugged and found that the following CSS is causing issue:
#header:before {
background: url('../images/header/bg-header-btm.png') repeat-x transparent;
bottom: 0;
content: "";
display: block;
height: 75px;
position: absolute;
right: 100%;
width: 5000em;
}
#header:after {
background: url('../images/header/bg-header-btm.png') repeat-x transparent;
bottom: 0;
content: "";
display: block;
height: 75px;
left: 100%;
position: absolute;
width: 5000em;
}
The width of "5000em" is causing the issue. The page renders correctly in browsers..not sure what is causing the issue in phantomjs.


Updating dependencies with the latest information.

I manually clone the auto-generated PR and fixed the test. esan was removed from compiler-rt in r355862 (https://reviews.llvm.org/D59133)


Handles the case of an SSL cert ID changing after an update

checks if the SSL object ID changed and sets the new one to state if it did

replied over email but also here is a link to the docs: https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs/resources/certificate_pack

According to this document https://api.cloudflare.com/#custom-ssl-for-a-zone-ssl-configuration-details the cert ID will change after a patch. This PR will check if the ID has changed and will set it to state.
"Upload a new private key and/or PEM/CRT for the SSL certificate. Note: PATCHing a configuration for sni_custom certificates will result in a new resource id being returned, and the previous one being deleted."

@joel-g are you able to expand on your use case or issue here a little more? there are a few things going on here and i'd like to make sure we're all on the same page with what problems we are solving as your change doesn't entirely cover what your PR title/description says it is aiming to.

The problem we are encountering is that we update a custom SSL certificate and it is successful. Then the next time the Terraform job runs it GETs the cert object from the API and gets a 404 because the cert ID has changed in the API but not in Terraform state. So then Terraform attempts to POST the certificate again.

thanks for clarifying! i wanted to confirm as the ticket also didn't really line up with what we have here so i wanted to be sure before we start tackling this.
as for the change, right now the ID is only updated when the custom_ssl_options is updated (using d.HasChanges()) however i assume you'll also want this to change if you add a new host or should the priority change as well. note: if this is working without the custom_ssl_options being changed, i suspect we're encountering a bug with nested lists within terraform and should explicitly fix it to prevent any breakage in the future when/if this gets fixed.
along with the change, we need to be pretty careful with updating resource IDs within the CRUD operations like this due to be being used for an "anchor" for other library calls. i can't see anywhere that we access the ID field outside of d.Id() (i.e. d.Get("id") so we should be 👌 for normal operation. this may however, cause issues if the Terraform operation is interrupted while this is updating and recovery will be quite messy so avoid that if you can 😅.

I can't speak on the occurrence of this issue happening within the other hook where priority changes happen because we never change the priority. We are adopting this change internally on our fork so I will monitor it for other inconsistencies.

any updates from your side @joel-g? if you'd like to address those couple of inline comments and you haven't seen any issues with this, i'm happy to look at getting this merged for the next release.

note that updating the certificate (ie: replace cert + private key with new ones ) without touching the "options" triggers the bug which is fixed by the patch, even if it's not obvious that d.HasChange("custom_ssl_options") would be true in this case.

superseded by #1025


ESLint Error: Cannot read property 'kind' of null

I'm currently using airbnb lint rules plus flow typing with the following configuration:
package.json
"babel-eslint": "^7.2.3",
"eslint": "^3.19.0",
"eslint-config-airbnb": "^15.0.1",
"eslint-plugin-flowtype": "^2.33.0",
"eslint-plugin-import": "^2.2.0",
"eslint-plugin-jsx-a11y": "^5.0.3",
"eslint-plugin-react": "^7.0.1"

.eslintrc
---
  extends:
    - airbnb
    - plugin:flowtype/recommended
  plugins:
    - flowtype
  parser: babel-eslint

And just one file in the project:
types.js
type Person = {
  name: string
}

export type {
  Person
};

When running eslint on this file it generates the following error:
Cannot read property 'kind' of null
TypeError: Cannot read property 'kind' of null
    at checkDeclaration (/Users/Kevan/dev/lint-bug/node_modules/eslint-plugin-import/lib/rules/no-mutable-exports.js:10:24)

If I change the types.js file as follows, then the error goes away:
export type Person = {
  name: string
}

I'm not sure if this is best solved within this project or within airbnb but just raising it here first as the error is occurring within the import plugin code.
Thanks

Hi. It looks like this issue is already resolved in the master branch, but not yet released.
Here is the commit that fixed the issue:
https://github.com/benmosher/eslint-plugin-import/commit/bfdc2bbfa16c2d27fa24ee0665ffb41040ef696c#diff-661a67441954052a3bb363a7c1398797R18
Other related issues: https://github.com/benmosher/eslint-plugin-import/issues/660 +
https://github.com/benmosher/eslint-plugin-import/issues/758
According to this comment, a release should be coming soon: https://github.com/benmosher/eslint-plugin-import/issues/758#issuecomment-302306840

ah yeah, I believe I just published the fix for this as v2.3.0

Many thanks @benmosher


[24.05] haskell.packages.*.ghc-{lib,tags}: pick correct version(s)

Description of changes
Backported from #315167.

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Builds of all changed ghc-libs and all ghc-tags versions succeed.


Missing logs when pull_data is manually failed

Description

If you manually mark the pull_data task of a provider DAG as failed, we expect to see logs similar to this:
[2023-04-02, 02:06:29 UTC] {local_task_job.py:272} WARNING - State of this instance has been externally set to failed. Terminating instance.
[2023-04-02, 02:06:29 UTC] {process_utils.py:129} INFO - Sending Signals.SIGTERM to group 68780. PIDs of all processes in the group: [68780]
[2023-04-02, 02:06:29 UTC] {process_utils.py:84} INFO - Sending the signal Signals.SIGTERM to group 68780
[2023-04-02, 02:06:29 UTC] {taskinstance.py:1479} ERROR - Received SIGTERM. Terminating subprocesses.
[2023-04-02, 02:06:29 UTC] {provider_data_ingester.py:245} INFO - Last query_params used: {"metadataDate": "2023-03-25"}

The logs indicate that the task was killed, and also report the final query_params used before the task failed.
These logs appear to be missing now.
Reproduction

Start a DagRun for a provider DAG locally.
Wait a few moments while the pull_data task gets through some data.
Manually mark the task as Failed in the Airflow UI.
Inspect the logs for the pull_data task and see that the expected logs are missing.

Additional context

We should investigate whether the logs are also missing in other circumstances. The priority may need to be escalated if so.

I can no longer reproduce this, although I do need to refresh the page after the task has failed in order to see the logs.

Manually mark a running task as Failed through the Airflow UI
Wait a second or two
Refresh the page
Check the logs and see expected output. Example:

[2023-09-19, 19:19:18 UTC] {provider_data_ingester.py:235} INFO - 746 records ingested so far.
[2023-09-19, 19:19:22 UTC] {local_task_job_runner.py:294} WARNING - State of this instance has been externally set to failed. Terminating instance.
[2023-09-19, 19:19:22 UTC] {process_utils.py:131} INFO - Sending 15 to group 23021. PIDs of all processes in the group: [23021]
[2023-09-19, 19:19:22 UTC] {process_utils.py:86} INFO - Sending the signal 15 to group 23021
[2023-09-19, 19:19:22 UTC] {taskinstance.py:1632} ERROR - Received SIGTERM. Terminating subprocesses.
[2023-09-19, 19:19:22 UTC] {provider_data_ingester.py:245} INFO - Last query_params used: {"action": "query", "generator": "allimages", "gaisort": "timestamp", "gaidir": "newer", "gailimit": 250, "gulimit": 250, "gunamespace": 0, "format": "json", "gaistart": "1694563200", "gaiend": "1694649600", "prop": "imageinfo|globalusage", "iiprop": "url|user|dimensions|extmetadata|mediatype|size|metadata", "gaicontinue": "20230913020645|Monnaie_-_Bronze,_\u00c9lyma\u00efde,_Incertain_-_btv1b103147537_(1_of_2).jpg", "continue": "gaicontinue||"}
[2023-09-19, 19:19:22 UTC] {process_utils.py:79} INFO - Process psutil.Process(pid=23021, status='terminated', exitcode=0, started='19:18:41') (23021) terminated with exit code 0


RepVGG model test process

Hello, after the repvgg algorithm creates the model, when I test the model using the test.py file, it gives the following error, can you tell me the reason?
Traceback (most recent call last):
File "/content/X-SDD-A-New-benchmark/test.py", line 15, in
model=torch.load('/content/gdrive/MyDrive/RepVGG16/repvgg_save.pth')
File "/usr/local/lib/python3.7/dist-packages/torch/serialization.py", line 712, in load
return _load(opened_zipfile, map_location, pickle_module, **pickle_load_args)
File "/usr/local/lib/python3.7/dist-packages/torch/serialization.py", line 1046, in _load
result = unpickler.load()
File "/usr/local/lib/python3.7/dist-packages/torch/serialization.py", line 1039, in find_class
return super().find_class(mod_name, name)
AttributeError: Can't get attribute 'RepVGG' on <module 'main' from '/content/X-SDD-A-New-benchmark/test.py'>

Hello, you need to put the original model's code before the test code.
At 2022-05-17 16:43:02, "111programming111" @.***> wrote:
Hello, after the repvgg algorithm creates the model, when I test the model using the test.py file, it gives the following error, can you tell me the reason?
Traceback (most recent call last):
File "/content/X-SDD-A-New-benchmark/test.py", line 15, in
model=torch.load('/content/gdrive/MyDrive/RepVGG16/repvgg_save.pth')
File "/usr/local/lib/python3.7/dist-packages/torch/serialization.py", line 712, in load
return _load(opened_zipfile, map_location, pickle_module, **pickle_load_args)
File "/usr/local/lib/python3.7/dist-packages/torch/serialization.py", line 1046, in _load
result = unpickler.load()
File "/usr/local/lib/python3.7/dist-packages/torch/serialization.py", line 1039, in find_class
return super().find_class(mod_name, name)
AttributeError: Can't get attribute 'RepVGG' on <module 'main' from '/content/X-SDD-A-New-benchmark/test.py'>
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: @.***>

Thank you, the repvgg model has been translated as 'repvgg deploy.pth' using the 'repvgg_model_convert' method, but now when we apply the test.py code, it gives this error
Traceback (most recent call last):
File "/content/X-SDD-A-New-benchmark/test.py", line 45, in
test()
File "/content/X-SDD-A-New-benchmark/test.py", line 34, in test
for imgs, path in tqdm(data_loader_test):
File "/usr/local/lib/python3.7/dist-packages/tqdm/std.py", line 1195, in iter
for obj in iterable:
File "/usr/local/lib/python3.7/dist-packages/torch/utils/data/dataloader.py", line 530, in next
data = self._next_data()
File "/usr/local/lib/python3.7/dist-packages/torch/utils/data/dataloader.py", line 570, in _next_data
data = self._dataset_fetcher.fetch(index)  # may raise StopIteration
File "/usr/local/lib/python3.7/dist-packages/torch/utils/data/_utils/fetch.py", line 49, in fetch
data = [self.dataset[idx] for idx in possibly_batched_index]
File "/usr/local/lib/python3.7/dist-packages/torch/utils/data/_utils/fetch.py", line 49, in
data = [self.dataset[idx] for idx in possibly_batched_index]
File "/content/X-SDD-A-New-benchmark/data/dataset.py", line 54, in getitem
label = int(self.images[index].split('.')[-2].split('\')[-1])
ValueError: invalid literal for int() with base 10: '/content/gdrive/MyDrive/RepVGG16/data/test/img167'

Hello！The label of the file in your dataset may not be the same as mine. You should change the piece of code “label = int(self.images[index].split('.')[-2].split('')[-1])".
At 2022-05-17 22:56:23, "111programming111" @.***> wrote:
Thank you, the repvgg model has been translated as 'repvgg deploy.pth' using the 'repvgg_model_convert' method, but now when we apply the test.py code, it gives this error
Traceback (most recent call last):
File "/content/X-SDD-A-New-benchmark/test.py", line 45, in
test()
File "/content/X-SDD-A-New-benchmark/test.py", line 34, in test
for imgs, path in tqdm(data_loader_test):
File "/usr/local/lib/python3.7/dist-packages/tqdm/std.py", line 1195, in iter
for obj in iterable:
File "/usr/local/lib/python3.7/dist-packages/torch/utils/data/dataloader.py", line 530, in next
data = self._next_data()
File "/usr/local/lib/python3.7/dist-packages/torch/utils/data/dataloader.py", line 570, in _next_data
data = self._dataset_fetcher.fetch(index) # may raise StopIteration
File "/usr/local/lib/python3.7/dist-packages/torch/utils/data/_utils/fetch.py", line 49, in fetch
data = [self.dataset[idx] for idx in possibly_batched_index]
File "/usr/local/lib/python3.7/dist-packages/torch/utils/data/_utils/fetch.py", line 49, in
data = [self.dataset[idx] for idx in possibly_batched_index]
File "/content/X-SDD-A-New-benchmark/data/dataset.py", line 54, in getitem
label = int(self.images[index].split('.')[-2].split('')[-1])
ValueError: invalid literal for int() with base 10: '/content/gdrive/MyDrive/RepVGG16/data/test/img167'
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.***>

您好，我把模型的权值训练好后，如何运行test文件啊？您提供的test文件在python中打开就会报错Unresolved reference 'Xception'
然后我在test文件前面输入from Xception_main import Xception，运行test是以下结果：
D:\anaconda\python.exe "D:\PyCharm Community Edition 2021.3.2\plugins\python-ce\helpers\pycharm_jb_pytest_runner.py" --path E:/liu_python_projects/X-SDD-A-New-benchmark-main/test2.py
Testing started at 8:46 ...
Launching pytest with arguments E:/liu_python_projects/X-SDD-A-New-benchmark-main/test2.py --no-header --no-summary -q in E:\liu_python_projects\X-SDD-A-New-benchmark-main
============================= test session starts =============================
collecting ...
test2.py:None (test2.py)
test2.py:18: in
model = torch.load('E:\liu_python_projects\X-SDD-A-New-benchmark-main\logs\Xception\Xception_save.pth')
D:\anaconda\lib\site-packages\torch\serialization.py:712: in load
return _load(opened_zipfile, map_location, pickle_module, **pickle_load_args)
D:\anaconda\lib\site-packages\torch\serialization.py:1046: in _load
result = unpickler.load()
D:\anaconda\lib\site-packages\torch\serialization.py:1039: in find_class
return super().find_class(mod_name, name)
E   AttributeError: Can't get attribute 'Xception' on <module 'main' from 'D:\PyCharm Community Edition 2021.3.2\plugins\python-ce\helpers\pycharm\_jb_pytest_runner.py'>
collected 0 items / 1 error
!!!!!!!!!!!!!!!!!!! Interrupted: 1 error during collection !!!!!!!!!!!!!!!!!!!!
========================= 1 warning, 1 error in 1.65s =========================
进程已结束,退出代码2

Hello, after the repvgg algorithm creates the model, when I test the model using the test.py file, it gives the following error, can you tell me the reason?
Traceback (most recent call last): File "/content/X-SDD-A-New-benchmark/test.py", line 15, in model=torch.load('/content/gdrive/MyDrive/RepVGG16/repvgg_save.pth') File "/usr/local/lib/python3.7/dist-packages/torch/serialization.py", line 712, in load return _load(opened_zipfile, map_location, pickle_module, **pickle_load_args) File "/usr/local/lib/python3.7/dist-packages/torch/serialization.py", line 1046, in _load result = unpickler.load() File "/usr/local/lib/python3.7/dist-packages/torch/serialization.py", line 1039, in find_class return super().find_class(mod_name, name) AttributeError: Can't get attribute 'RepVGG' on <module 'main' from '/content/X-SDD-A-New-benchmark/test.py'>

您解决这个test.py 运行问题了吗？Did you solve this test.py run problem?

在我的anaconda上运行是没问题的，您可以仿照我的方式处理一下
--
网易VIP邮箱提醒：安全收发邮件，务必核实往来邮件地址、银行账号等机密信息，请通过电话或视频等多种方式确认信息真实性，提高警惕，请勿轻易透露个人重要信息。
Alert message of Netease Vipmail：Never provide your password, security questions, verification codes, or any other personal important information details to anyone else.
You can identify mail message by telephone,video-chat or other ways.You should make sure that your email address, bank account and other confidential information as secure as possible. Thank you for keeping your email account secure.
At 2022-05-26 08:49:54, "Shuanghui Liu" @.***> wrote:
Hello, after the repvgg algorithm creates the model, when I test the model using the test.py file, it gives the following error, can you tell me the reason?
Traceback (most recent call last): File "/content/X-SDD-A-New-benchmark/test.py", line 15, in model=torch.load('/content/gdrive/MyDrive/RepVGG16/repvgg_save.pth') File "/usr/local/lib/python3.7/dist-packages/torch/serialization.py", line 712, in load return _load(opened_zipfile, map_location, pickle_module, **pickle_load_args) File "/usr/local/lib/python3.7/dist-packages/torch/serialization.py", line 1046, in _load result = unpickler.load() File "/usr/local/lib/python3.7/dist-packages/torch/serialization.py", line 1039, in find_class return super().find_class(mod_name, name) AttributeError: Can't get attribute 'RepVGG' on <module 'main' from '/content/X-SDD-A-New-benchmark/test.py'>
您解决这个test.py 运行问题了吗？Did you solve this test.py run problem?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.***>


[New Feature]: Improving the ui of the game page

🎮 feature Request
The padding seems out of place and there is no hover effect for many elements

Point down the features
I would like to add hover effect and better padding to make the ui better
Select program in which you are contributing
GSSoC24
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

would like to work on this issue

@thevirengarg assign me this under gssoc'24 and add a level too

I would like to work on this task .


why no scrollbar?

at least i don't see any.

@incantatem1 I have a scrollbar (when I move a mouse it became visible)

for me that's not the case, is it maybe not working in older app versions?

Could try to install the theme in the sandbox plugin? Maybe other plugin or css interferes with you vault

i don't know how
no idea which could cause this? i don't really have fancy plugins that mess with the vault in such a way, i think
1.5.12

ok, tried in restricted mode with no plugins at all, still no scrollbar

hi @incantatem1  is there a reason you cannot update to 1.6.5?

i'm scared of breaking certain plugins and older themes by doing that and i can't find info on which ones would even be affected.

can you make a  total copy of your vault (the folder you store the files?) I case if the update will break the one  one you need you can reinstall older version and point Obsidian to the copied folder
I didn have any problem with update and I am using 80+ plugins

can you make a total copy of your vault (the folder you store the files?) .In case if the update will break the one one you need you can reinstall older version and point Obsidian to the copied folder (import to include hidden files and folders, not only your notes))
I didn have any problem with update and I am using 80+ plugins

if you could tell me if the new version breaks any of the existing themes to the point of making them unusable, the theme picker plugin (the most important one for me...), avatar plugin, callout manager, editing toolbar and gallery, that would help a bit.
i still have the installer for the old version. i also make backups of my vault all the time but i make them in bits only for subfolders i recently updated, and having to reinstall them all one by one would be tedious

Hi there! I'm sorry I couldn't get back sooner! Weirdly I didn't receive an email about this, I'll look into that.
I'm really glad to have the first issue on my theme, you don't know how much it means to me.
As for the lack of scroll bars, you're right, its missing for me as well.

This is a remnant of the original Gummy theme, which also had missing scroll bars, however I will add it back as a style setting for accessibility reasons. I will need some time.

This issue has been fixed. Please update your theme.
The problem was that in the older piece of code, the CSS for scrollbars were defined before the colour it was using was defined, leading it to be invalid. This weirdly only affected the dark theme, which is probably why Daniel may have been able to see the scroll mode. Such restricted mode hacks will NOT work as CSS is loaded the same regardless.


Always wait for the request content to complete

Fixes #1100
Ensure that we always wait for the request content copy to complete before returning from SendAsync.
When using HTTP/2, the request content copy is done in parallel. It may still be going on even if SendAsync throws.
In such cases, the cancellation token passed to SerializeToStreamAsync is signaled. This PR makes sure we combine the tokens appropriately.
On 3.1, there is no overload of SerializeToStreamAsync that takes a CT, so we create an extra CTS that we cancel manually in case of an exception.
Perf:
On 3.1 we can't detect whether HTTP/1.1 is being used, so we always allocate an extra CTS.
On 5.0+, we allocate an extra CTS only when using HTTP/2 (it would be trivial to pool it).

It appears we may need a CTS we can cancel manually in all cases, not just 3.1.
We should be able to use the same CTS (requestTimeoutSource) for all of this.

Yeah, I think we were going to end up in that position regardless when I did my ActivityTimeout work.


App crashes on android only after FlutterUserAgentPlugin.java uses or overrides a deprecated API

Installed with flutter_sms: ^2.1.1
flutter doctor -v
[√] Flutter (Channel stable, 1.22.6, on Microsoft Windows [Version 10.0.19042.746], locale el-GR)
• Flutter version 1.22.6 at L:\flutter
• Framework revision 9b2d32b605 (8 weeks ago), 2021-01-22 14:36:39 -0800
• Engine revision 2f0af37152
• Dart version 2.10.5
[√] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
• Android SDK at C:\Users\iordanis\AppData\Local\Android\sdk
• Platform android-30, build-tools 30.0.3
• Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
• Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b01)
• All Android licenses accepted.
[!] Android Studio (version 4.1.0)
• Android Studio at C:\Program Files\Android\Android Studio
X Flutter plugin not installed; this adds Flutter specific functionality.
X Dart plugin not installed; this adds Dart specific functionality.
• Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b01)
[√] VS Code, 64-bit edition (version 1.54.3)
• VS Code at C:\Program Files\Microsoft VS Code
• Flutter extension version 3.20.0
[√] Connected device (1 available)
• SM J510FN (mobile) • 5a01de42 • android-arm • Android 6.0.1 (API 23)

A gist upload of the stacktrace of the actual error would be useful.


Prevent client side crash in MFD when marked target dies out of bounds.

This should close #474
This will need proper testing though, as I have not tested it myself (need more than 1 person)

Also unrelated whitespace change >:(
But I digress :P


Documentation updates

Reviewed and updated documentation

TODO

Move root md files into RST

Coverage remained the same at 100.0% when pulling 6b9d96c6e958cc3ba04333454a3e1a8d130b653b on matthewhegarty:documentation-updates into 87c7e1e869121e77777b7b489c427352f2f535f3 on django-import-export:main.

Thanks for reviewing @pokken-magic


-Mfree is not correct for all LLVM Fortran compilers

Describe the bug
When compiling Umpire with the LLVM flang compiler (flang-new), Umpire sets -Mfree as the flag for free form Fortran. That flag is for the classic-flang compiler and the correct flag is -ffree for LLVM flang.
To Reproduce
Steps to reproduce the behavior:
Compile Umpire with flang-new.
The -ffree flag should be set when compiling Fortran source.
Compilers & Libraries (please complete the following information):
>> flang-new --version
flang-new version 19.0.0git (https://github.com/ROCm/llvm-project d5a3c4dc3bb96d345db1f7c63d5e3e5ba273af8c)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /share/contrib-modules/Core/amd-trunk-dev/2024-07-09_18.0-0/bin
Build config: +assertions
Configuration file: /share/contrib-modules/Core/amd-trunk-dev/2024-07-09_18.0-0/bin/flang.cfg

Any build of flang-new should expose this issue.
Additional context
I would recommend using the CMake property Fortran_FORMAT since recent CMake versions are aware of the LLVMflang compiler. If this does not work with the minimum CMake version then logic should be included to disambiguate LLVM flang from classic-flang. Fortran_COMPILER_FAMILY_IS_CLANG will be true in both cases.

@bcornille do you know the specific CMake version where the correct flag is used for both LLVM flang and classic flang?

I don't know offhand. I'll have to do some testing or maybe git blame in the cmake repo to see if I can determine that.

Support for LLVMFlang was added in CMake 3.24. As far as I can tell the format flag for classic flang has never been correct. You can change the condition to use CMAKE_Fortran_COMPILER_ID, which is Flang for classic flang and LLVMFlang for flang-new.

The classic flang repo says the flag is -Mfreeform, the PGI compiler that it was based off of was -Mfree, and the AOCC compiler documentation shows -ffree-form. So I don't know if it accepts multiple of these and if it's even consistent across the flavors that will all identify as Flang.

The ROCm Fortran compiler (amdflang flavor of classic flang) accepts all three flags, so if that is true of the other classic flang flavors then CMake 3.24 should be sufficient to always use Fortran_FORMAT.

thanks @bcornille - I was seeing failures in our internal CI with CMake 3.24 and the changes I have in #891
Would the check on CMAKE_Fortran_COMPILER_ID solve the issue for you?

Yes it would.


[Feature] Build for Ubuntu 18.04 Bionic

Summary
A build against Ubuntu 18.04 (Bionic) would be nice.

@adamdyson Thank you for your request. We will certainly consider adding an Ubuntu 18.04 build in our next major release.


Please comment on recent eslint-scope vulnerability

This just hit Hacker News: https://github.com/eslint/eslint-scope/issues/39
I am in no position to evaluate the severity of this problem, but I do use VSCode Insiders every day and the ESLint extension was enabled (by default?). I would like to know what, if any, risk of compromise to credentials or system integrity might have been suffered as a result. Thank you!

Thank you!


Fix a possible null dereference in PopulateMetadataFromException

If the code throwing the exception is dynamic (eval or otherwise doesn't have a url) the url of the functionBody can be null. In that case, we would pass null to JavascriptString::NewCopySz which dereferences it and crashes. Fix is to use GetSourceName instead which handles this case providing the string 'eval code' instead of nullptr.

Thanks!


BUG | Filtering by 'Only Show Cluster/Cohort Projects' and 'Only Show My Projects' at the same time doesn't work.

@sethmcknight I'm not totally clear on the definition of "cluster/cohort" projects, but our API refers to this filter as "onlyMultipleEngagements", so I added two engagements to an existing one of "my" projects, and both filters worked as I would have expected. Can you elaborate a little on what expected behavior you're not seeing?

Looks like this may just be an issue with the 'My Projects' filter. Moving to project backlog for now.


[Improve] [Engine] Move Completed Checkpoint trigger to CheckpointCoordinator

Purpose of this pull request
Move Completed Checkpoint trigger to CheckpointCoordinator to avoid normal Checkpoint and completed checkpoint both trigger at same time.

Check list

[ ] Code changed are covered with tests, or it does not need tests for reason:
[ ] If any new Jar binary package adding in your PR, please add License Notice according
New License Guide
[ ] If necessary, please update the documentation to describe the new feature. https://github.com/apache/incubator-seatunnel/tree/dev/docs
[ ] If you are contributing the connector code, please check that the following files are updated:

Update change log that in connector document. For more details you can refer to connector-v2
Update plugin-mapping.properties and add new connector information in it
Update the pom file of seatunnel-dist

Is there a case where we have multiple sources in the single pipeline? This causes the COMPLETED_POINT_TYPE to be triggered when a single source completes

good point, I will fix this.

@ashulin Temporary solution to ensure that the task can run normally, and the fine-grained part of the task completed logic will be resolved in the future.


added subscribe sample mode for queue counters

Pull Request Functional Test Report for #2384 / e93ba4ee92a5622743edb8846824da12b7cf5e0c
Virtual Devices

Device
Test
Test Documentation
Job
Raw Log

Arista cEOS

DP-1.14: QoS basic test
a8e52114
Log

Cisco 8000E

DP-1.14: QoS basic test
11295c47
Log

Cisco XRd

DP-1.14: QoS basic test
d4f8782f
Log

Juniper cPTX

DP-1.14: QoS basic test
abdf4961
Log

Juniper ncPTX

DP-1.14: QoS basic test
eda7ecab
Log

Nokia SR Linux

DP-1.14: QoS basic test
c6f889e0
Log

Openconfig Lemming

DP-1.14: QoS basic test
3615bbb4
Log

Hardware Devices

Device
Test
Test Documentation
Raw Log

Arista 7808

DP-1.14: QoS basic test

Cisco 8808

DP-1.14: QoS basic test

Juniper PTX10008

DP-1.14: QoS basic test

Nokia 7250 IXR-10e

DP-1.14: QoS basic test

Help

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 50.153%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1642

Relevant Lines:
3274

💛  - Coveralls


Alcinoe websocket unavailabled?

Hi, Thank you for your achievment.
But i'll like to know how to install / use ALWinHTTPWebSocketClient component?
i add alcinoe in the search path.... i also tried to install via bpl sydney, but it's still unavailable.

The demo use the DevExpress components (that quite bad for a demo to include such dependancies in it I agree). you can maybe redo the demo without the devExpress dependancies


Unsupported data type in custom op handler

I'm running Python3.7 docker image with libedgetpu1-max (tried std as well) and as of yesterday I am no longer able to find the python3-pycoral package (which seemed to work while it was there).
I have since installed pycoral-1.0.0-cp37-cp37m-linux_aarch64.whl and tflite_runtime-2.5.0-cp37-cp37m-linux_aarch64.whl and am now getting the following error:
Unsupported data type in custom op handler: -1579713216Node number 2 (EdgeTpuDelegateForCustomOp) failed to prepare.

I'm also facing the same issue with raspberry pi 4, I've tried it with the new tflite_runtime-2.5.0-cp37-cp37m-linux_armv7l.whl and I'm using libedgetpu1-std version 14.1. Any help on this will be great.

Hi guys, We recently have a release of libedgetpu which may have caused some mismatches.
Could you share the outputs of this command:
$ dpkg -l | grep libedgetpu

ii  libedgetpu1-std:armhf                 14.1                                  armhf        Support library for Edge TPU

@teraSurfer Can you try a an apt update and reinstall libedgetpu?
Basically, your version should be 15.0 for it to be compatible with tflite_runtime 2.5.

@Namburger I tried it but I'm not seeing version 15.0 available anywhere.
https://packages.cloud.google.com/apt/dists/coral-edgetpu-stable/main/binary-armhf/Packages only shows version 14.1

Same issue here -- also not seeing where version 15.0 is:
$ sudo dpkg -l | grep edge
ii  libedgetpu1-std:armhf                14.1                                         armhf        Support library for Edge TPU

$ pip freeze | grep tflite
tflite-runtime @ https://github.com/google-coral/pycoral/releases/download/release-frogfish/tflite_runtime-2.5.0-cp37-cp37m-linux_armv7l.whl

$ python3
Python 3.7.3 (default, Jul 25 2020, 13:03:44)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import dill
>>>dill.load_session('~/coral_inference_test_session_linux.pkl')
>>> test()
2020.11.04.tflite
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<ipython-input-4-a0f03a08574a>", line 4, in test
  File "<ipython-input-2-334f4462c6f6>", line 3, in init
  File "/home/iap/.local/lib/python3.7/site-packages/tflite_runtime/interpreter.py", line 259, in allocate_tensors
    return self._interpreter.AllocateTensors()
RuntimeError: Internal: Unsupported data type in custom op handler: 34030992Node number 3 (EdgeTpuDelegateForCustomOp) failed to prepare.

same issue , and not seeing version 15
$ dpkg -l | grep libedgetpu
ii  libedgetpu1-std:amd64                      14.1                                                                        amd64        Support library for Edge TPU

$ python3 classify_image.py --model models/mobilenet_v2_1.0_224_inat_bird_quant_edgetpu.tflite --labels models/inat_bird_labels.txt --input images/parrot.jpg
Traceback (most recent call last):
  File "classify_image.py", line 122, in <module>
    main()
  File "classify_image.py", line 100, in main
    interpreter.allocate_tensors()
  File "/home/saguilar/.local/lib/python3.6/site-packages/tflite_runtime/interpreter.py", line 259, in allocate_tensors
    return self._interpreter.AllocateTensors()
RuntimeError: Internal: Unsupported data type in custom op handler: 46686256Node number 1 (EdgeTpuDelegateForCustomOp) failed to prepare.

Hi all, sorry about that, it seems like new package isn't uploaded to our apt repo for armv7l and arm64, but it is for x86_64.
For now, please download the new libedgetpu from this link and unzip it:
$ https://dl.google.com/coral/edgetpu_api/edgetpu_runtime_20201105.zip
$ unzip edgetpu_runtime_20201105.zip

and then points LD_LIBRARY_PATH to the path of the new share library when you run the example (for instance, this is how I ran it on the Dev Board):
$ LD_LIBRARY_PATH=/home/mendel/edgetpu_runtime/libedgetpu/direct/aarch64 python3 classify_image.py   --model models/mobilenet_v2_1.0_224_inat_bird_quant_edgetpu.tflite   --labels models/inat_bird_labels.txt   --input images/parrot.jpg
----INFERENCE TIME----
Note: The first inference on Edge TPU is slow because it includes loading the model into Edge TPU memory.
16.6ms
3.8ms
3.0ms
3.3ms
4.1ms

Will update you guys as soon as we get the new package uploaded on the apt repo.

I downloaded from the unstable link and it is working fine. Thank you!

@teraSurfer thanks for confirming and apologies, we'll have the new version reup soon

@Namburger   do you have the new similar version for windows 10?

I downloaded the link provided here for the libedgetpu: https://github.com/google-coral/pycoral/issues/1#issuecomment-724312390
I also used the test_data submodule in this repo: https://github.com/google-coral/test_data/tree/c21de4450f88a20ac5968628d375787745932a5a
$ LD_LIBRARY_PATH=/home/my_username/libs/coral/edgetpu_runtime/libedgetpu/direct/aarch64 python3.8 examples/classify_image.py --model test_data/mobilenet_v2_1.0_224_inat_bird_quant_edgetpu.tflite --labels test_data/inat_bird_labels.txt --input test_data/parrot.jpg
Traceback (most recent call last):
  File "examples/classify_image.py", line 82, in <module>
    main()
  File "examples/classify_image.py", line 60, in main
    interpreter.allocate_tensors()
  File "/home/my_username/.local/lib/python3.8/site-packages/tflite_runtime/interpreter.py", line 242, in allocate_tensors
    return self._interpreter.AllocateTensors()
  File "/home/my_username/.local/lib/python3.8/site-packages/tflite_runtime/interpreter_wrapper.py", line 76, in AllocateTensors
    return _interpreter_wrapper.InterpreterWrapper_AllocateTensors(self)
RuntimeError: Internal: Unsupported data type in custom op handler: 0Node number 1 (EdgeTpuDelegateForCustomOp) failed to prepare.

$ dpkg -l | grep libedgetpu
ii  libedgetpu1-max:amd64                           15.0                                 amd64        Support library for Edge TPU

Maybe a bit off-topic, but how can I rollback to libedgetpu1-std=14.1 now that it seems v15.0 is the only available deb package from the official repository? Are there archived versions hosted somewhere?

@jingw222 yes, you can visit coral.ai/software, there'll be a section with the edgetpu tarballs including release date and installation script.
Another way is to install python3-edgetpu which will install a "legacy" libedgetpu package from our apt repo

@jingw222 yes, you can visit coral.ai/software, there'll be a section with the edgetpu tarballs including release date and installation script.
Another way is to install python3-edgetpu which will install a "legacy" libedgetpu package from our apt repo

Thank you, Nam! Just managed to install a legacy libedgetpu-std package via the second option, which was quite interestingly also v15.0. In fact, I could have just installed the package directly by a different name as libedgetpu1-legacy-std. The two packages live side by side.

@jingw222 yes, that's correct, it's an attempt for s to make sure that users doesn't get the wrong configurations and run into issues

Hi all, sorry about that, it seems like new package isn't uploaded to our apt repo for armv7l and arm64, but it is for x86_64.
For now, please download the new libedgetpu from this link and unzip it:
$ https://dl.google.com/coral/edgetpu_api/edgetpu_runtime_20201105.zip
$ unzip edgetpu_runtime_20201105.zip

and then points LD_LIBRARY_PATH to the path of the new share library when you run the example (for instance, this is how I ran it on the Dev Board):
$ LD_LIBRARY_PATH=/home/mendel/edgetpu_runtime/libedgetpu/direct/aarch64 python3 classify_image.py   --model models/mobilenet_v2_1.0_224_inat_bird_quant_edgetpu.tflite   --labels models/inat_bird_labels.txt   --input images/parrot.jpg
----INFERENCE TIME----
Note: The first inference on Edge TPU is slow because it includes loading the model into Edge TPU memory.
16.6ms
3.8ms
3.0ms
3.3ms
4.1ms

Will update you guys as soon as we get the new package uploaded on the apt repo.

Hi, @Namburger
When do you expect the armv7l and arm64 uploaded to the repo?

Hello @openedhardware its all uploaded by now, if you install python3-pycoral package, everything should be updated!

Hey, I'm also seeing this error.
File "/usr/lib/python3/dist-packages/tflite_runtime/interpreter.py", line 154, in load_delegate
raise ValueError('Failed to load delegate from {}\n{}'.format(
ValueError: Failed to load delegate from libedgetpu.so.1
I see:
$ dpkg -l | grep libedgetpu
rc  libedgetpu1-max:arm64                  15.0                              arm64        Support library for Edge TPU
ii  libedgetpu1-std:arm64                  15.0                              arm64        Support library for Edge TPU
and:
$ pip3 freeze | grep tflite-runtime
tflite-runtime==2.5.0
So I'm not sure what is wrong. These seem to be the versions that people were expecting.
Thoughts?

Hey, I'm also seeing this error.
File "/usr/lib/python3/dist-packages/tflite_runtime/interpreter.py", line 154, in load_delegate
raise ValueError('Failed to load delegate from {}\n{}'.format(
ValueError: Failed to load delegate from libedgetpu.so.1
I see:
$ dpkg -l | grep libedgetpu
rc  libedgetpu1-max:arm64                  15.0                              arm64        Support library for Edge TPU
ii  libedgetpu1-std:arm64                  15.0                              arm64        Support library for Edge TPU
and:
$ pip3 freeze | grep tflite-runtime
tflite-runtime==2.5.0
So I'm not sure what is wrong. These seem to be the versions that people were expecting.
Thoughts?

@seanreynoldscs try this:
sudo usermod -aG plugdev $USER
sudo reboot now

if it still doesn't work, I suggest sending an strace:
strace python3 your_script.py > strace.log

@seanreynoldscs try this:
sudo usermod -aG plugdev $USER
sudo reboot now

if it still doesn't work, I suggest sending an strace:
strace python3 your_script.py > strace.log

Umm... Wow... okay so can you explain that ? :) it worked.
+1 for super quick feedback too!

Umm... Wow... okay so can you explain that ? :) it worked.
+1 for super quick feedback too!

Nice, that means you were blocked by the linux user permission, normally this is already allowed by default so some users doesn't have this problems!

Nice, that means you were blocked by the linux user permission, normally this is already allowed by default so some users doesn't have this problems!

Hi, me too with this error, after migrating yesterday from python3-edgetpu to python3-coral libraries (see https://coral.ai/software/)
My platform : Arm + Ubuntu 18.04 + Python 3.6.9 ( + ROS Melodic)
I was using this model : /mobilenet_ssd_v2_face_quant_postprocess_edgetpu.tflite, which was perfectly working with previous python3-edgetpu lib.
Steps to reproduce:
pi@rockpi:~$ python3
Python 3.6.9 (default, Oct  8 2020, 12:12:24)
[GCC 8.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pycoral
>>> from pycoral.utils import edgetpu
>>> DET_MODEL_PATH = '/home/pi/tflite.models/mobilenet_ssd_v2_face_quant_postprocess_edgetpu.tflite'
>>> interpreter = edgetpu.make_interpreter(DET_MODEL_PATH)
>>> interpreter.allocate_tensors()

_Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.6/dist-packages/tflite_runtime/interpreter.py", line 242, in allocate_tensors
    return self._interpreter.AllocateTensors()
  File "/usr/local/lib/python3.6/dist-packages/tflite_runtime/interpreter_wrapper.py", line 115, in AllocateTensors
    return _interpreter_wrapper.InterpreterWrapper_AllocateTensors(self)
RuntimeError: Internal: Unsupported data type in custom op handler: 0Node number 2 (EdgeTpuDelegateForCustomOp) failed to prepare._

BUT, if I change the model to ssd_mobilenet_v1_1_metadata_1.  ( from example found  ), no more error occurs:
>>> DET_MODEL_PATH = '/home/pi/tflite.models/ssd_mobilenet_v1_1_metadata_1.tflite'
>>> interpreter = edgetpu.make_interpreter(DET_MODEL_PATH)
>>> interpreter.allocate_tensors()
>>>

So are the new libraries  no more compatible with previous models (*_edgetpu.tflite)?
If yes is this behavior by design or backward compatibility could be recovered ?
By the way it would  be very helpfully to have a "Rosetta" style example showing how to migrate from python3-edgetpu to python3-coral libraries

Hi, me too with this error, after migrating yesterday from python3-edgetpu to python3-coral libraries (see https://coral.ai/software/)
My platform : Arm + Ubuntu 18.04 + Python 3.6.9 ( + ROS Melodic)
I was using this model : /mobilenet_ssd_v2_face_quant_postprocess_edgetpu.tflite, which was perfectly working with previous python3-edgetpu lib.
Steps to reproduce:
pi@rockpi:~$ python3
Python 3.6.9 (default, Oct  8 2020, 12:12:24)
[GCC 8.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pycoral
>>> from pycoral.utils import edgetpu
>>> DET_MODEL_PATH = '/home/pi/tflite.models/mobilenet_ssd_v2_face_quant_postprocess_edgetpu.tflite'
>>> interpreter = edgetpu.make_interpreter(DET_MODEL_PATH)
>>> interpreter.allocate_tensors()

_Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.6/dist-packages/tflite_runtime/interpreter.py", line 242, in allocate_tensors
    return self._interpreter.AllocateTensors()
  File "/usr/local/lib/python3.6/dist-packages/tflite_runtime/interpreter_wrapper.py", line 115, in AllocateTensors
    return _interpreter_wrapper.InterpreterWrapper_AllocateTensors(self)
RuntimeError: Internal: Unsupported data type in custom op handler: 0Node number 2 (EdgeTpuDelegateForCustomOp) failed to prepare._

BUT, if I change the model to ssd_mobilenet_v1_1_metadata_1.  ( from example found  ), no more error occurs:
>>> DET_MODEL_PATH = '/home/pi/tflite.models/ssd_mobilenet_v1_1_metadata_1.tflite'
>>> interpreter = edgetpu.make_interpreter(DET_MODEL_PATH)
>>> interpreter.allocate_tensors()
>>>

So are the new libraries  no more compatible with previous models (*_edgetpu.tflite)?
If yes is this behavior by design or backward compatibility could be recovered ?
By the way it would  be very helpfully to have a "Rosetta" style example showing how to migrate from python3-edgetpu to python3-coral libraries

@Luke1962 model should still works. Besides from the pythonpackage, you'll also need to install the new libdgetpu.so:
https://coral.ai/software#debian-packages

@Luke1962 model should still works. Besides from the pythonpackage, you'll also need to install the new libdgetpu.so:
https://coral.ai/software#debian-packages

Okay new issue. I swapped the USBC for the M.2 B+M key.
What is weird is I'm having the same issue as before, but now the command you gave me doesnt work.
$ python3 examples/classify_image.py --model test_data/mobilenet_v2_1.0_224_inat_bird_quant_edgetpu.tflite --labels test_data/inat_bird_labels.txt --input test_data/parrot.jpg
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/tflite_runtime/interpreter.py", line 152, in load_delegate
delegate = Delegate(library, options)
File "/usr/lib/python3/dist-packages/tflite_runtime/interpreter.py", line 111, in init
raise ValueError(capture.message)
ValueError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "examples/classify_image.py", line 84, in
main()
File "examples/classify_image.py", line 61, in main
interpreter = make_interpreter(*args.model.split('@'))
File "/usr/lib/python3/dist-packages/pycoral/utils/edgetpu.py", line 66, in make_interpreter
delegates = [load_edgetpu_delegate({'device': device} if device else {})]
File "/usr/lib/python3/dist-packages/pycoral/utils/edgetpu.py", line 42, in load_edgetpu_delegate
return tflite.load_delegate(_EDGETPU_SHARED_LIB, options or {})
File "/usr/lib/python3/dist-packages/tflite_runtime/interpreter.py", line 154, in load_delegate
raise ValueError('Failed to load delegate from {}\n{}'.format(
ValueError: Failed to load delegate from libedgetpu.so.1
When following instructions from: https://coral.ai/docs/dev-board-mini/get-started/#7-run-a-model-using-the-pycoral-api
Thoughts?

Okay new issue. I swapped the USBC for the M.2 B+M key.
What is weird is I'm having the same issue as before, but now the command you gave me doesnt work.
$ python3 examples/classify_image.py --model test_data/mobilenet_v2_1.0_224_inat_bird_quant_edgetpu.tflite --labels test_data/inat_bird_labels.txt --input test_data/parrot.jpg
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/tflite_runtime/interpreter.py", line 152, in load_delegate
delegate = Delegate(library, options)
File "/usr/lib/python3/dist-packages/tflite_runtime/interpreter.py", line 111, in init
raise ValueError(capture.message)
ValueError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "examples/classify_image.py", line 84, in
main()
File "examples/classify_image.py", line 61, in main
interpreter = make_interpreter(*args.model.split('@'))
File "/usr/lib/python3/dist-packages/pycoral/utils/edgetpu.py", line 66, in make_interpreter
delegates = [load_edgetpu_delegate({'device': device} if device else {})]
File "/usr/lib/python3/dist-packages/pycoral/utils/edgetpu.py", line 42, in load_edgetpu_delegate
return tflite.load_delegate(_EDGETPU_SHARED_LIB, options or {})
File "/usr/lib/python3/dist-packages/tflite_runtime/interpreter.py", line 154, in load_delegate
raise ValueError('Failed to load delegate from {}\n{}'.format(
ValueError: Failed to load delegate from libedgetpu.so.1
When following instructions from: https://coral.ai/docs/dev-board-mini/get-started/#7-run-a-model-using-the-pycoral-api
Thoughts?


Update Telemetry for Public Preview

PR Summary

Remove HistoryMessage and Duration from Telemetry
Migrate Application Insight from temp to test
Add replace to AzCLI telemetry

PR Context

Raised another pr #251. Whether this PR worth merging depends on whether the old ones will be completely deprecated. Close for now.


Specifying range of loadings

Shoud we add an option to be able to add a range of loadings? This is reported in some paper but I could not get it to work as of now.

DOI("10.1002/cvj.12122")


Wish list

tested Wish list page on Pixel 7 ( Screen Size = 6.31 inch ) , Pixel 3a( Screen Size = 5.6 inch) , Pixel 2(Screen Size = 5.0 inch) and Pixel 7 Pro ( Screen Size = 6.71 inch)

![Screenshot from 2024-01-18 14-46-11](https://github.com/udaybansal19/Shimi/assets/102759044/cbb2e183-6bc4-4ad7-bdc2-3118fc7b3e8

e)

@ayanjamil you can check in the screenshot that the distance between the product image and the view button is different on different screens. It should be constant across screens according to design

•  Top Navigation bar
• Counter  for the number of wishlist items
• Formated code
• Fixed padding and margin values
• Added usable image files in constants and used in the home screen.


Object has not been declared ratable.

Having issue liking a object.
getting Object has not been declared ratable. when doing this:
current_user.like(station)

I have recommends: :stations in User so this should work, accordingly to the documentation.
What am i doing wrong?

Are you sure that station is an instance of Station? Does Recommendable.config.ratable_classes return anything?

@davidcelis Yea, I had issues with id which worked on one place but not another and yea, made me confused. The problem was that the id param was nil, so station wasn't found.
Sorry about that, closing this.


Upgrade dependencies

Upgrade dependencies based on advices from "yarn upgrade-interactive"

@thomvaill can this one be reviewed and merged ASAP please? The dependencies are now heavily behind for this project with few vulnerabilities identified. Our security tools no longer let us install Log4Brains on our machines:
npm warn deprecated<EMAIL_ADDRESS>Debug versions >=3.2.0 <3.2.7 || >=4 <4.3.1 have a low-severity ReDos regression when used in a Node.js environment. It is recommended you upgrade to 3.2.7 or 4.3.1. (https://github.com/visionmedia/debug/issues/797)
npm warn deprecated<EMAIL_ADDRESS>Debug versions >=3.2.0 <3.2.7 || >=4 <4.3.1 have a low-severity ReDos regression when used in a Node.js environment. It is recommended you upgrade to 3.2.7 or 4.3.1. (https://github.com/visionmedia/debug/issues/797)
npm warn deprecated<EMAIL_ADDRESS>The querystring API is considered Legacy. new code should use the URLSearchParams API instead.
npm warn deprecated<EMAIL_ADDRESS>This module is not supported, and leaks memory. Do not use it. Check out lru-cache if you want a good and tested way to coalesce async requests by a key value, which is much more comprehensive and powerful.
npm warn deprecated<EMAIL_ADDRESS>Glob versions prior to v9 are no longer supported
npm warn deprecated<EMAIL_ADDRESS>Debug versions >=3.2.0 <3.2.7 || >=4 <4.3.1 have a low-severity ReDos regression when used in a Node.js environment. It is recommended you upgrade to 3.2.7 or 4.3.1. (https://github.com/visionmedia/debug/issues/797)
npm warn deprecated<EMAIL_ADDRESS>Material UI v4 doesn't receive active development since September 2021. See the guide https://mui.com/material-ui/migration/migration-v4/ to upgrade to v5.
npm warn deprecated<EMAIL_ADDRESS>Material UI v4 doesn't receive active development since September 2021. See the guide https://mui.com/material-ui/migration/migration-v4/ to upgrade to v5.
npm warn deprecated<EMAIL_ADDRESS>Material UI v4 doesn't receive active development since September 2021. See the guide https://mui.com/material-ui/migration/migration-v4/ to upgrade to v5.

Zscaler sandboxes registry.npmjs.org/bufferutil/-/bufferutil-4.0.8.tgz deeming it unsafe to use.
I do understand that adding new features kind of requires a lot of time, but those aren't critical for the tool to be utilized. One the other hand, dependencies manage vulnerabilities and must be looked after in a timely fashion :)
Appreciate your time - we really want to use your tool, but lack of any attention to it for the last couple years kind of kills it.
This PR is nearly 6 months old, meaning even if you merge it now it's already outdated, but defo better than using 2 yo packages.
KR


Add custom element best practices doc

Alaska Airlines Pull Request
Resolves: #138
Summary:
Add documentation around custom element best practices.
Type of change:
Please delete options that are not relevant.

[x] New capability

Checklist:

[x] My update follows the CONTRIBUTING guidelines of this project
[x] I have performed a self-review of my own update

By submitting this Pull Request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Pull Requests will be evaluated by their quality of update and whether it is consistent with the goals and values of this project. Any submission is to be considered a conversation between the submitter and the maintainers of this project and may require changes to your submission.
Thank you for your submission!
-- Auro Design System Team

Good to see this get started.
Is there already a ticket to show this content on the doc site?

Not yet... that will be addressed once we have some content to post. This is still heavy on discussion right now.

@geoffrich is there any flavor you want to add to this now that you have written the CSS-Tricks article? Do you know when it will be posted?

I'll get this fleshed out a bit more. Article was posted this morning: https://css-tricks.com/using-custom-elements-in-svelte/

I added more detail to the existing best practices, so this is good to merge now. We can add more as they come up.

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[wrt] Update test for disk-cache-size

Impacted TCs num(approved): New 0, Update 1, Delete 0
Unit test Platform: Android
Android test result summary: Pass 1, Fail 0, Block 0
BUG=https://crosswalk-project.org/jira/browse/XWALK-4362

LGTM


Is a 1.18.2 backport possible?

Love this mod, fixes every problem I had about sleeping! A backport for 1.18.2 would be incredible!

Unlikely from me, sorry.
If someone else wants to do the work and submit a PR, I'd happily accept it though.


[feature] tasks

Attempt to add task support.
Couple of notes:

There is no support for the copy grants option on tasks as we're never cloning or replacing an existing task
after only supports tasks that are in the same schema (as per the docs)
This PR doesn't implement task grants but we could make it part of it?
The task is automatically started after creation

Travis build

@henriblancke it appears there is another PR covering this -> https://github.com/chanzuckerberg/terraform-provider-snowflake/pull/198
Can you all work together on this?

@henriblancke @ryanking Happy to collaborate here the core of our 2 MRs seems very similar minus a few cosmetic differences. The biggest difference seems to be in mine I handle temporarily suspending the root task of a tree so that the child tasks can be altered and then resume it after the fact.
From the (docs)[https://docs.snowflake.com/en/sql-reference/sql/alter-task.html]:

Modifying any task in a tree of tasks requires that the root task is suspended.

@chriskuchin yeah your handling of task dependencies seems much better. Having the option to enable/disable the task is also nice! One thing I noticed tho is that you're not exposing session_parameters in your PR? Maybe we should just add that and we're good to go? It's up to @ryanking on how you all want to handle this :)

Yeah I got distracted and forgot about them. Happy to put a little more time into the PR if that's what we wanna do and add that

One thing I noticed tho is that you're not exposing session_parameters in your PR?

Perhaps we can move forward by merging @chriskuchin's PR then adding session_params as a separate PR?

I nearly have the session_parameters piece done on my PR just testing and debugging now @ryanking

@ryanking @chriskuchin I actually went ahead and added the enabled flag and logic to suspend root or standalone tasks before modifying / creating a child task. I think my use of defer to reactivate the suspended root task might be a little cleaner and safer when anything else fails during modifying or creating a new task. That way we'll always re-enable the root task? Let me know what you all think...

@henriblancke sounds good.  I had to modify them pretty heavily for them to actually work. Plus you weren't reading their state at all.

@chriskuchin it did test em, but maybe not enough 😄? Can you elaborate? What do you mean by not reading state? Thanks!

You never read at least that I could find the parameters after you set them. The other problem I had was you were escaping the parameter values which caused them to be invalid as well as not wrapping them in quotes

You never read at least that I could find the parameters after you set them. The other problem I had was you were escaping the parameter values which caused them to be invalid as well as not wrapping them in quotes

yep I did just run into the quoting issue. will look into that

Might be worthwhile to pull my acceptance test over into yours as it does a pretty good job of iterating a whole bunch of cases

Might be worthwhile to pull my acceptance test over into yours as it does a pretty good job of iterating a whole bunch of cases

Agreed 👍

@chriskuchin any idea why the acceptance test here would be failing?

They aren't even running they error out about not being configured in Travis. Are they passing for you locally?

Ahh you have the acceptance tests hooked up to your fork... I have no idea that was never an error I saw when writing them or getting things working. Sounds like it's an error in the first step. You can enable tf_logs=debug to get more info but it's really noisy so might be hard. Can you run it locally so you run just that test with debug?

So it seems to have something to do with your state. The error occurs during a state refresh so it's probably in the read function I would guess

@chriskuchin yeah just figured it out adding the id we get from snowflake during reading the task caused the error. It breaks taskIDFromString. I'm running into more problems tho now that this one is resolved

ahh that makes sense I didn't follow that compound id pattern in My MR 👍 let me know if i can help

@ryanking not sure why the Acceptance tests aren't running in your CI but as long as those are passing the PR looks good to me

ok i will take a look

@ryanking they should be all green here


Added remove=True to docker run container function

When we are done with a docker container it should be removed, so that we don't leave a lot of dangling containers at the system.

We are actually removing the container, but somehow docker still eats up a lot of space.


Diff with type RPM not working with remote sources

I just built me the latest version with RPM support and tried to compare two images via our private docker repo and stumbled upon this minor issue.
Following command works but as those images are based on centos the result is not very usefull (without and with --type=apt):
./container-diff-linux-amd64 diff remote://our-repo/base/centos7_base:latest remote://our-repo/somecontainer/based_on_centos
output (shortend)
Starting diff on images[...]
Computing diffs

-----Apt-----
[...]
Version differences: None

But with the addtional type=rpm i get:
Starting diff on images[...]
Computing diffs
ERRO[0007] Error getting diff with RPMAnalyzer: no such image
ERRO[0007] Could not retrieve diff: Could not perform diff on [...]

somehow it seems that with --type=rpm and using "remote", images are not pulled. If I pull the images first and replace remote:// with daemon:// it works as expected.
Anyway, thank you for the RPM-diff implementation!

@BBQigniter I'm looking into this. Obviously, I didn't test the RPM differ with remote:// images, but the problem is that the downloaded images aren't correctly preserved in the daemon, which is necessary in order start the containers for the RPM analysis after pulling. Thanks a lot for taking the time to report the issue!

Yes, the issue is the following. container-diff doesn't load the referenced remote:// image into the daemon, but it simply downloads and unpacks all blobs (see  https://github.com/GoogleCloudPlatform/container-diff/blob/master/pkg/util/image_prep_utils.go#L96) to /tmp/. This is sufficient for some differs, but not for the PRM one, which requires running the analysis in a container to properly execute RPM queries.
@nkubala What I suggest to do here is to write all data into a tar archive in /tmp/, which is then set as Image.Source. This way we don't mess with local images in the daemon and we reuse all logic in the RPM differ. I expect the logic in the code to get a little bit hairy as the tar archived should be removed afterward.

@vrothberg Thanks for looking into this. I'm a bit confused on what you're proposing; writing the data to an archive in /tmp is currently what we're doing already. The main issue I see is that the RPM differ needs an actual image in the local daemon to run some prerequisite commands, so we'll need to get the image into the Docker daemon before doing the diff.
Since the RPM differ already requires a running daemon (while the other differs do not), it seems to me the simplest solution here would be to just force a pull of the remote image into the local daemon and then always run the RPM differ in "local" mode. What do you think?
I do agree that at some point the pull/extract code could use a rework, but that's a much bigger refactor :)

@nkubala Thanks for your reply, and sorry for the confusion! What I was proposing was to extend https://github.com/GoogleCloudPlatform/container-diff/blob/master/pkg/util/image_prep_utils.go#L96. Currently, getFileSystemFromReference doesn't download the tar of the referenced image as a whole, but it downloads each blob separately, unpacks it and writes it to the temporary directory. What I proposed may look as follows:

Generate tmp dir foo/
Download image tar to foo/
Unpack the image tar in, for instance, foo/rootfs/
Perform the analyses
Remove foo/

I think that the biggest benefit of it is that it's independent of the analyzer (and future ones can benefit from it) and that it doesn't require a running daemon.
If we pull the image, it's likely to happen in the RPMAnalyzer and would add yet more specific code to it. It would also imply downloading the remote image twice (once the tar and once the image).
I am okay with both (although I prefer the first). What do you think?

Sorry for the super late reply @vrothberg. Thanks for clearing that up, my fault for misunderstanding you. Your proposal makes sense to me, but the one thing I'm unclear on is step 2: how do we download the image tar from a remote source to the new directory? It seems like the rest of your steps assume the tar will be in the docker save format, but I don't know of any way to directly download an image in that format without either using docker commands, or using libraries like what we're doing now to download the individual layers. Does skopeo's containers/copy help us do something like this?
Normally I wouldn't be big on special casing certain parts of the code, but since we've already done that for the RPMAnalyzer I don't think it's the end of the world to have specific logic for pulling images and loading them, since we're already running a container for that analyzer anyway. I think we could also avoid pulling the image twice, by just docker loading the temp directory we download all the image layers into.

@nkubala No worries, I was quite busy as well :-) Unfortunately, I won't find time until January to work on this issue, but then I can check if it's possible to download everything as suggested. Otherwise, I completely agree that we can defer the download to the already special cased RPMAnalyzer.

@nkubala Actually, I found some time now to work on this issue before leaving into the Christmas chaos, see #164. I followed your advice to pull a remote:// image in case it's not in the daemon. This required to extend the Image type a little, but I think it's sane. Due to holidays, I won't be able to work on the PR in case something must be changed. If you want to get this merged before next year, please, feel free to edit and change the PR as you desire.


[Not able to merge] Fix several bugs in the QBE module

This version includes all fixes to the QBE module. It is not able to merge with the main branch because I also include all conflicting files in this PR.

Conflict 1: modelstore/elasticstore.py. QBE runs on elasticsearch-6.0.0 which requires me to delete all ['value'] that are used in the main branch.
Conflict 2: requirements.txt. I have to specify the version of elasticsearch to be 6.0.0

Closing this one. Let me know if it should be reopened.


Fix: Support building bdjuno image for chains with CosmWasm

Description
The current Dockerfile does not support building bdjuno for chains that have CosmWasm. The commit first modifies the Makefile to accept BUILD_TAGS and LINK_STATICALLY parameters. Then Dockerfile includes both CosmWasm/non-CosmWasm version so that we can adjust it for each chain.
Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...

[ ] included the correct type prefix in the PR title
[ ] added ! to the type prefix if API or client breaking change
[ ] targeted the correct branch
[ ] provided a link to the relevant issue or specification
[ ] added a changelog entry to CHANGELOG.md
[ ] included comments for documenting Go code
[ ] updated the relevant documentation or specification
[ ] reviewed "Files changed" and left comments if necessary
[ ] confirmed all CI checks have passed

Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...

[ ] confirmed the correct type prefix in the PR title
[ ] confirmed ! in the type prefix if API or client breaking change
[ ] confirmed all author checklist items have been addressed
[ ] reviewed API design and naming
[ ] reviewed documentation is accurate
[ ] reviewed tests and test coverage
[ ] manually tested (if applicable)

Codecov Report

:exclamation: No coverage uploaded for pull request base (cosmos/v0.44.x@26854db). Click here to learn what that means.
The diff coverage is n/a.

@@                Coverage Diff                @@
##             cosmos/v0.44.x     #485   +/-   ##
=================================================
  Coverage                  ?   57.40%
=================================================
  Files                     ?       19
  Lines                     ?     1444
  Branches                  ?        0
=================================================
  Hits                      ?      829
  Misses                    ?      511
  Partials                  ?      104


Standard auth mode was removed in Enterprise Search 7.14.0.

Can this extension be used in Enterprise Search 7.16.2?
I tested it and it doesn't seem to work

Feel free to PR the functionality needed or commission that.
We don't need this feature right now, so we won't invest into it sorry.


I cannot use Phantomjs in a multi-threaded environment.

I am trying to use the PhantomJS in a multi-threaded environment. But it is becoming single threaded. What shall I do if I want to make Phantomjs run in a multi-threaded environment.?
If anyone can help them please do let me know .. fast.
Thank you.

I m not sure that you mean. Could you please elaborate more?

I was trying to work with PhantomJS and I was not able to use it in a multi thread environment. I have searched a lot and found that the PhantomJS is made to run in a single threaded environment. So may I know if there is any way to run the PhantomJS in multi threaded mode. Say multi threaded means I want to run two or more threads using PhantomJS whereas now it is only working with single thread.