locast2tuner in Docker - WIP

Forked from #7
The Docker version is going to be an interesting challenge for me - I could build it realtime inside of a Rust image, but that would mean a 10 minute process anytime the container is created. There's also the problem of dynamically linked libraries:
roddie@testubuntu:~/dev/locast2tuner/target/debug (main)% ldd locast2tuner
        linux-vdso.so.1 (0x00007ffd43baf000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f19c75e4000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f19c75c1000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f19c7472000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f19c746c000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f19c727a000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f19c8ff5000)

Looking at some options now - A lot of this is new to me, so it'll be learning on the fly.

This project might be the answer for me: https://github.com/clux/muslrust
Sure enough!
roddie@testubuntu:~/dev/docker/locast2tuner/target/x86_64-unknown-linux-musl/debug (main)% ldd locast2tuner
        not a dynamic executable

I'll try throwing it into an alpine image next to see how it runs.

Wow - I did it (using the binary built above).
Dockerfile:
FROM alpine:latest

COPY /locast2tuner /

ENTRYPOINT ["locast2tuner", "-U", "<email address>", "-P", "<password>", "-a", "<IP_ADDRESS>"]

Building:
[~/docker] roddie@testubuntu% docker build -t locast2tuner .
Sending build context to Docker daemon  152.6MB
Step 1/2 : FROM alpine:3.7
3.7: Pulling from library/alpine
5d20c808ce19: Pull complete
Digest: sha256:8421d9a84432575381bfabd248f1eb56f3aa21d9d7cd2511583c68c9b7511d10
Status: Downloaded newer image for alpine:3.7
 ---> 6d1ef012b567
Step 2/2 : ENTRYPOINT ["locast2tuner", "-U", "<email>", "-P", "<password>!", "-a", "<IP_ADDRESS>"]
 ---> Running in 5055a16f34a6
Removing intermediate container 5055a16f34a6
 ---> bbc995cd0314
Successfully built bbc995cd0314
Successfully tagged locast2tuner:latest

Running:
[~/docker] roddie@testubuntu% docker run -p 6077:6077 locast2tuner
[INFO] - locast2tuner 0.1.0 on Linux 5.4.0-70-generic starting..
[INFO] - UUID: <UUID>
[INFO] - Logging in with <email>
[INFO] - Login succeeded!
[INFO] - Downloading FCC facilities
[INFO] - Cached FCC facilities to /root/.locast2tuner/facilities
[INFO] - Loading stations for Dallas (cache: true, cache timeout: 3600, days: 8)..
[INFO] - Starting http server for Dallas on http://<IP_ADDRESS>:6077
[INFO] - Starting 1 workers
[INFO] - Starting "actix-web-service-<IP_ADDRESS>:6077" service on <IP_ADDRESS>:6077
[INFO] - Tuners:
[INFO] -  +--------+----------+-----+--------------------------------------+-----------------+---------------------+
[INFO] -  | City   | Zip code | DMA | UUID                                 | Timezone        | URL                 |
[INFO] -  +--------+----------+-----+--------------------------------------+-----------------+---------------------+
[INFO] -  | Dallas |          | 623 | <UUID> | America/Chicago | http://<IP_ADDRESS>:6077 |
[INFO] -  +--------+----------+-----+--------------------------------------+-----------------+---------------------+
[INFO] - locast2tuner started..
[INFO] - Stream c9bfabf - ......

It freaking worked on both Plex and Emby.
TODO:

Integrate config file into the Dockerfile
Document the config file format and provide a sample
Document how to run it in Docker with volume/port mapping
Figure out how to package and distribute the binary (it's 150MB), and who owns the build process

Awesome! I'm working on Debian/Ubuntu packaging and using Github actions.
We can build everything there. We might want to consider using the .deb
file that will be built instead of a separate binary.
On Mon, Apr 5, 2021, 21:25 Roddie Hasan @.***> wrote:

Wow - I did it (using the binary built above).
Dockerfile:
FROM alpine:latest
COPY /locast2tuner /
ENTRYPOINT ["locast2tuner", "-U", "", "-P", "", "-a", "<IP_ADDRESS>"]
Building:
[~/docker] @.***% docker build -t locast2tuner .
Sending build context to Docker daemon  152.6MB
Step 1/2 : FROM alpine:3.7
3.7: Pulling from library/alpine
5d20c808ce19: Pull complete
Digest: sha256:8421d9a84432575381bfabd248f1eb56f3aa21d9d7cd2511583c68c9b7511d10
Status: Downloaded newer image for alpine:3.7
---> 6d1ef012b567
Step 2/2 : ENTRYPOINT ["locast2tuner", "-U", "", "-P", "!", "-a", "<IP_ADDRESS>"]
---> Running in 5055a16f34a6
Removing intermediate container 5055a16f34a6
---> bbc995cd0314
Successfully built bbc995cd0314
Successfully tagged locast2tuner:latest
Running:
[~/docker] @.***% docker run -p 6077:6077 locast2tuner
[INFO] - locast2tuner 0.1.0 on Linux 5.4.0-70-generic starting..
[INFO] - UUID:
[INFO] - Logging in with
[INFO] - Login succeeded!
[INFO] - Downloading FCC facilities
[INFO] - Cached FCC facilities to /root/.locast2tuner/facilities
[INFO] - Loading stations for Dallas (cache: true, cache timeout: 3600, days: 8)..
[INFO] - Starting http server for Dallas on http://<IP_ADDRESS>:6077
[INFO] - Starting 1 workers
[INFO] - Starting "actix-web-service-<IP_ADDRESS>:6077" service on <IP_ADDRESS>:6077
[INFO] - Tuners:
[INFO] -  +--------+----------+-----+--------------------------------------+-----------------+---------------------+
[INFO] -  | City   | Zip code | DMA | UUID                                 | Timezone        | URL                 |
[INFO] -  +--------+----------+-----+--------------------------------------+-----------------+---------------------+
[INFO] -  | Dallas |          | 623 |  | America/Chicago | http://<IP_ADDRESS>:6077 |
[INFO] -  +--------+----------+-----+--------------------------------------+-----------------+---------------------+
[INFO] - locast2tuner started..
[INFO] - Stream c9bfabf - ......
It freaking worked on both Plex and Emby.
TODO:

Integrate config file into the Dockerfile
Document the config file format and provide a sample
Document how to run it in Docker with volume/port mapping
Figure out how to package and distribute the binary (it's 150MB),
and who owns the build process

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/wouterdebie/locast2tuner/issues/17#issuecomment-813775810,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABKABSYRRO7LQGWDWRKKGTTHJWITANCNFSM42NYBVQQ
.

Another thing we might want to consider is having a reverse mount for the
config file, so people don't have to build their own image, but can just
download one from a registry.
On Tue, Apr 6, 2021, 06:42 Wouter de Bie @.***> wrote:

Awesome! I'm working on Debian/Ubuntu packaging and using Github actions.
We can build everything there. We might want to consider using the .deb
file that will be built instead of a separate binary.
On Mon, Apr 5, 2021, 21:25 Roddie Hasan @.***> wrote:

Wow - I did it (using the binary built above).
Dockerfile:
FROM alpine:latest
COPY /locast2tuner /
ENTRYPOINT ["locast2tuner", "-U", "", "-P", "", "-a", "<IP_ADDRESS>"]
Building:
[~/docker] @.***% docker build -t locast2tuner .
Sending build context to Docker daemon  152.6MB
Step 1/2 : FROM alpine:3.7
3.7: Pulling from library/alpine
5d20c808ce19: Pull complete
Digest: sha256:8421d9a84432575381bfabd248f1eb56f3aa21d9d7cd2511583c68c9b7511d10
Status: Downloaded newer image for alpine:3.7
---> 6d1ef012b567
Step 2/2 : ENTRYPOINT ["locast2tuner", "-U", "", "-P", "!", "-a", "<IP_ADDRESS>"]
---> Running in 5055a16f34a6
Removing intermediate container 5055a16f34a6
---> bbc995cd0314
Successfully built bbc995cd0314
Successfully tagged locast2tuner:latest
Running:
[~/docker] @.***% docker run -p 6077:6077 locast2tuner
[INFO] - locast2tuner 0.1.0 on Linux 5.4.0-70-generic starting..
[INFO] - UUID:
[INFO] - Logging in with
[INFO] - Login succeeded!
[INFO] - Downloading FCC facilities
[INFO] - Cached FCC facilities to /root/.locast2tuner/facilities
[INFO] - Loading stations for Dallas (cache: true, cache timeout: 3600, days: 8)..
[INFO] - Starting http server for Dallas on http://<IP_ADDRESS>:6077
[INFO] - Starting 1 workers
[INFO] - Starting "actix-web-service-<IP_ADDRESS>:6077" service on <IP_ADDRESS>:6077
[INFO] - Tuners:
[INFO] -  +--------+----------+-----+--------------------------------------+-----------------+---------------------+
[INFO] -  | City   | Zip code | DMA | UUID                                 | Timezone        | URL                 |
[INFO] -  +--------+----------+-----+--------------------------------------+-----------------+---------------------+
[INFO] -  | Dallas |          | 623 |  | America/Chicago | http://<IP_ADDRESS>:6077 |
[INFO] -  +--------+----------+-----+--------------------------------------+-----------------+---------------------+
[INFO] - locast2tuner started..
[INFO] - Stream c9bfabf - ......
It freaking worked on both Plex and Emby.
TODO:

Integrate config file into the Dockerfile
Document the config file format and provide a sample
Document how to run it in Docker with volume/port mapping
Figure out how to package and distribute the binary (it's 150MB),
and who owns the build process

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/wouterdebie/locast2tuner/issues/17#issuecomment-813775810,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABKABSYRRO7LQGWDWRKKGTTHJWITANCNFSM42NYBVQQ
.

Another thing we might want to consider is having a reverse mount for the
config file, so people don't have to build their own image, but can just
download one from a registry.

I was actually talking about the config file for locast2tuner itself that would have the username/password etc.  I'd rather users didn't have to build their own image, as well.

Awesome! I'm working on Debian/Ubuntu packaging and using Github actions.
We can build everything there. We might want to consider using the .deb
file that will be built instead of a separate binary.

Have a look at this project, @wouterdebie: https://github.com/emk/rust-musl-builder
I used this to build the binary and then used the binary to build a docker image that was only ~24MB.
Specifically, look at the "Making static releases with Travis CI and GitHub" section, which may allow you to build the releases you're looking for.
What do you think?

FYI, the binary built from the emk/rust-musl-builder package is only 18MB vs. 150MB from the one that I used initially.
The Travis CI/GitHub release stuff is way above my head as a non-developer, but I'm willing to learn it and try it out if you think this might be a good idea.

I was actually talking about the config file for locast2tuner itself that would have the username/password etc. I'd rather users didn't have to build their own image, as well.

Yes, exactly. We can have a reverse mount that the image can use and where the config is stored. That way, people don't have to build their own.

Have a look at this project, @wouterdebie: https://github.com/emk/rust-musl-builder

Yeah, I found a bunch of examples in order to do that. I'm experimenting on the cargo_deb branch.

FYI, the binary built from the emk/rust-musl-builder package is only 18MB vs. 150MB from the one that I used initially.

this is the difference between a debug and a release build. A lot of debug stuff is stripped away. The binary that I normally build is around 30 Mb, while a release build only takes up about 3 Mb of space.

The Travis CI/GitHub release stuff is way above my head as a non-developer, but I'm willing to learn it and try it out if you think this might be a good idea.

I'm working on this, but I'll let you know if I need help!
Thanks for the engagement!

Yes, exactly. We can have a reverse mount that the image can use and where the config is stored. That way, people don't have to build their own.

Hmmm.. I think we're saying the same thing here, but I'll let you figure out how you want to go with builds and then I'll Dockerize, test, and document the workflow.
In the meantime, I am thinking about cleaning up and adding my new Dockerfile to the main branch along with some rough instructions on how to use it.  It's got the rust-musl-builder stuff built-in and can get some advanced users started running/testing the project in a container while you work on the build process.  What do you think?
Here's what it looks like:
# -*- mode: dockerfile -*-
#
# An example Dockerfile showing how to build a Rust executable using this
# image, and deploy it with a tiny Alpine Linux container.

# You can override this `--build-arg BASE_IMAGE=...` to use different
# version of Rust or OpenSSL.
ARG BASE_IMAGE=ekidd/rust-musl-builder:latest

# Our first FROM statement declares the build environment.
FROM ${BASE_IMAGE} AS builder

# Add our source code.
ADD --chown=rust:rust . ./

# Build our application.
RUN cargo build --release

# Now, we need to build our _real_ Docker container, copying in `locast2tuner`.
FROM alpine:latest

COPY --from=builder \
    /home/rust/src/target/x86_64-unknown-linux-musl/release/locast2tuner \
    /usr/local/bin/
ENTRYPOINT ["/usr/local/bin/locast2tuner", "-U", "<username>", "-P", ">password>", "-a", "<IP_ADDRESS>"]

this is the difference between a debug and a release build. A lot of debug stuff is stripped away. The binary that I normally build is around 30 Mb, while a release build only takes up about 3 Mb of space.

Oh, duh - that makes sense.  I told you that I'm way out of my depth here, right?  I am so not a developer or coder. :-)

Ok, I think it's ready to go - I haven't updated README.md yet, but will do that if you think this is worth the PR to allow users to use this in Docker until you're ready to go with the builds/packages.
https://github.com/eiddor/locast2tuner/tree/rough_docker
Basically the user has to do three things (to be documented):

Build the container image with: docker build -t locast2tuner .
Copy config/config.ini.sample to config/config.ini and edit the username/password
Run it either with: docker-compose (sample included) or docker run -p 6077:6077 -v ./config/:/app/config -d locast2tuner

It's obviously a little rough and would rely on me getting the documentation done, but it works well on my end!

Would it be possible to have the dockerfile download straight from the github repo so that the user doesn't have to download it?  Also- there is a way for dockerhub to automatically build whenever there is an update on github, it'd be super cool if that worked too

@TheSamDickey I think an image on Docker hub where we want to end up eventually (unless @wouterdebie disagrees).
What I've got going right now is just sometime to tide Docker users over in the meantime.  I'm actually going to rewrite it tonight or tomorrow to build using the new packages that he's just released.  That way there's no downloading involved beyond the Dockerfile.

In got Debian packages working today and will do docker next, so we might
have this soon. I'd like to host this on ghcr.io, where I already host
another docker image.
On Wed, Apr 7, 2021, 20:29 Roddie Hasan @.***> wrote:

@TheSamDickey https://github.com/TheSamDickey I think an image on
Docker hub where we want to end up eventually (unless @wouterdebie
https://github.com/wouterdebie disagrees).
What I've got going right now is just sometime to tide Docker users over
in the meantime. I'm actually going to rewrite it tonight or tomorrow to
build using the new packages that he's just released. That way there's no
downloading involved beyond the Dockerfile.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/wouterdebie/locast2tuner/issues/17#issuecomment-815380433,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABKABSH6V552AULDL3BRE3THUBGVANCNFSM42NYBVQQ
.

I actually just sat down to write the Dockerfile using your Debian packages - Do you want me to get that done?  I would kind of appreciate the practice and I should have it working tonight.
(ghcr.io is great)

Sure thing! I'll have to see how this integrates with building the packages.
On option is to use apt-get install the packages from the Debian PPA when
building the docker image. However, we could also use the artifact that is
created during the build step and install it in the image directly.
Regardless, having a proper Dockerfile is a great first step.
You might want to also have a look at .github/actions/cicd.yml to see how
docker images are built on GH actions.
On Wed, Apr 7, 2021, 21:54 Roddie Hasan @.***> wrote:

I actually just sat down to write the Dockerfile using your Debian
packages - Do you want me to get that done? I would kind of appreciate the
practice and I should have it working tonight.
(ghcr.io is great)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/wouterdebie/locast2tuner/issues/17#issuecomment-815407793,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABKABTSKON4X6O44FOHWUDTHULHZANCNFSM42NYBVQQ
.

Excellent, thank you!  I'm going to start with an Ubuntu image and basically follow what you've already documented.  The good news is that I've already got the user documentation done since it's pretty much the same as the one I built earlier.
After I get it working I'll start learning more about what you're doing with CI and Actions -  From what I understand so far, that would probably be a good place to begin using the binary from the build.
I've learned a few new things already just doing some research to get the Cargo Dockerfile built, so this is a nice break from my pure networking day job.

PR submitted.
Another good learning experience - For now installing the packages into the Ubuntu 20.04 base image works well.  I've tested it on a couple of machines and am running it on my PMS.
Once we move this to the GH Actions process and just add the binary to the image it will be a lot smaller since we can use the alpine image as a base (the binary works great in alpine).

@eiddor your contributions have been super helpful. I just added building and publishing a Docker image from CI/CD and added a bunch of stuff in the README. Let me know what you think.

Ha!  You did it exactly the way I was about to do it.  Well done!
I'm glad to know that I wasn't completely off-base with my understanding of the system, too. This is almost exactly what I had in my head.
I really appreciate the learning experience.  I had no idea what CI/CD or GitHub Actions were until late last night.  I'll never be a developer or creator, but some of these tools are really cool.
I'll update the docker-compose.yml file to reflect the config location to .locast2tuner to match the docs
PMS also has XMLTV support, so I'll update that in the README.
After that I'll work on prettying-up the Plex and EMBY installation section with screenshots if you think that's a good idea.

@eiddor Thanks!

I'll update the docker-compose.yml file to reflect the config location to .locast2tuner to match the docs
Awesome! I have the feeling that people who know how to use docker-compose will probably know they need to make sure paths are correct. However, it's probably a good idea to explicitly mention that.

PMS also has XMLTV support, so I'll update that in the README.
True! Thanks!

After that I'll work on prettying-up the Plex and EMBY installation section with screenshots if you think that's a good idea.
Awesome! Do you think we should do this in the README or move this to the Wiki perhaps and link in the Wiki? Or maybe add additional markdown files to the repo in a docs/ directory?

Moving the documentation discussion to #26


Add Progress Column

I adapted the plugin created by @ryangjchandler to add the Progress column next to the Filament, I believe the column can be a standard feature of the Filament.
Credits: @ryangjchandler
Plugin: https://github.com/ryangjchandler/filament-progress-column

What is the benefit of having this in core instead of as a plugin, @moskoweb?
I feel like it's perfect as a plugin, but not necessarily a core feature.
Thoughts, @danharrin @ryangjchandler?

I agree with Zep 👍

The more features Filament has that not everyone uses, the larger the bundle size which is frankly uneconomical from a maintenance perspective or an efficiency perspective

@moskoweb You can make pull requests to plugins too, not everything has to be in core. If you think something is missing from my package, open a pull request.

Oh and @ryangjchandler is a Filament core team member, so we'll make sure the package is updated. 😉


ALT doesn't select the top menu in marketplace tabs

Issue Type: Bug
whilst reading "Release Notes: 1.54.1" I attempted to try pressing ALT to highlight the top menu. It doesn't work. Switching to a tab that is for an open file - then ALT works. Switching back to the relase notes - ALT doesn't work.
There should be consistency. ALT should highlight the top menu.
Unfortuntately, it seems the marketplace is given special treatment: ALT doesn't work; pages don't cache and instead refresh every time you switch tabs; etc etc.
Claiming that vscode is just an editor is farcical. This isn't notepad or gedit. It has a whole marketplace, it runs plugins and supports automation. It already implements chromium... why can't you simply cache a marketplace page? I can open multiple files of several thousand lines simultaneously, yet it refuses to cache a simple plugin description page? Why? Scared that it will have to use some precious RAM?
It ruins the user experience.


Adding qunit test framework and first set of basic tests.

This is the beginning of having a test framework in impress.js.
Part of issue #494

You need to add your Github e-mail address to the user.email git config in order for Github to find the correct author of the commit.

Maybe we could split the tests into logical modules and leverage QUnit before/after APIs to setup requirements for each test (AKA testDone and testStart).
I am also wondering if it doesn't make more sense using more fluent testing APIs such as Mocha/chai instead of Qunit. Up to discussio.

Thanks for catching I had somehow added wrong email to .gitconfig. Fixed now.
I picked Qunit out of the discussion in #494. If someone wants to provide pull request with different framework, I won't be insulted :-) I just wanted to move things forward.
In hindsight, QUnit is awkward in 2 ways:

the idea is to manipulate html elements under a div, which is reset between tests. However, impress.js sets classes in body and wants to own the entire page. It still works, but this is not how QUnit developers intended it to be used. (hence need for cleanup yourself)
QUnit prints results on the screen, while impress.js wants to do animations on the entire screen as well. It works, but a bit messy. I believe if we run Qunit in karma or other test runner, we will get results printed in console, so this might be ok after all.

As for different modules: that's exactly the idea. This would be the first module testing core functionality. Keypress tests can go into this one, or could already be separate file. In any case more advanced animations need their own html file.
No comment yet on before/after api.

I forgot to say: Thanks for reviewing!

I picked Qunit out of the discussion in #494

That was just my personal experience at the time, not that it really matters. We should probably focus on what is the best for the project anyway.

QUnit is awkward in 2 ways

I agree QUnit is not that robust or fluent, I realized that after working with different testing frameworks over time such as Mocha/Jasmine integrated with Karma. But as I said earlier we need to judge which one is better to achieve the goal of taking this project forward.

I forgot to say: Thanks for reviewing!

You're welcome. I hope the same for any PRs I send from now on :)

@FagnerMartinsBrack : New commit should address all issues you raised (or intentionally not, as with the line breaks in assert() invokations).

Have you considered a fluent API for writing the assertions? This way we don't need to write the teste messages, it will be implicit from how the assertions are written.

Isn't that just another way of doing what I already do in QUnit? Wouldn't want to add more libraries for such a reason.

QUnit is assertive, while a fluent API is behavioral. The benefits of a behavioral API is that you don't need to care how you are going to structure your assertions, you just declare your expectations and the API take care of presenting the failures automatically.
It's not like it is strictly necessary, just would be an interesting enhancement in case you want to look into that. We can do it later anyway.

Basically I see a few points of general improvement that I might have mentioned earlier or not:

If there are comments in the code, then it means that the code cannot document itself. Is it possible to write the code in a way that it only documents what can't be seen by reading the code? If you want that I point out some examples in the code I will be glad to do it, it's just that I think it's pretty obvious that some comments are just redundant, maybe that's intended with plans to be removed later?

Is it possible to split the JavaScript code in a separate *.js file? I say that because usually it helps for code editors to highlight the correct tokens in a file that only has JavaScript. Besides that, the separation might make it easier to focus in the behavior of the tests instead of how the document is structured (the html itself will be pretty small).

Just out of curiosity, is it possible to run the second test Impress Core API separately? Ideally tests should be atomic in a way that they can be run separately without having dependencies in the other.

About code style, as we probably already discussed, it is better to define and document some guidelines before this is landed (it is going to be done in the "CONTRIBUTING" part of https://github.com/impress/impress.js/issues/512). After we define it, we can adjust if necessary as a last step. Does that makes sense?

If there are comments in the code, then it means that the code cannot document itself. Is it possible to write the code in a way that it only documents what can't be seen by reading the code? If you want that I point out some examples in the code I will be glad to do it, it's just that I think it's pretty obvious that some comments are just redundant, maybe that's intended with plans to be removed later?

You're free to point out examples, but I think you'll learn that we have fundamental difference in philosophy here. In my taste, too much comments is better than too little. In my experience, most coders vastly overestimate the readability of their own code, when read by someone else. In particular, in open source we must take into account that code we write might be read by someone who never worked on this project before, and in the case of JavaScript, might be a person for whom JavaScript is not their strongest language (because they're really a backend dev, etc...) Yet, such persons should be treated as potential contributors too.
Also, it is intentional that code comments add redundancy. They're a statement of intent. You can then read the code to check whether the code does what the comment said. Without comments, you can read what the code does, but there's no reference point that will tell you whether that is what the code is supposed to do.

Is it possible to split the JavaScript code in a separate *.js file? I say that because usually it helps for code editors to highlight the correct tokens in a file that only has JavaScript. Besides that, the separation might make it easier to focus in the behavior of the tests instead of how the document is structured (the html itself will be pretty small).

Sure. My editor handled this fine, but if it helps other, we should do that.
Actually, future tests (in other files) should have more elaborate html and css code, so this separation should definitively help in readability.

Just out of curiosity, is it possible to run the second test Impress Core API separately? Ideally tests should be atomic in a way that they can be run separately without having dependencies on each other.

The first QUnit.test() calls impress().init(), so no. However, that is an expection and in general I agree with this principle. For example, my intent is to add tests for the keypress api into the same file. It should and would be possible to run the keypress tests without the core api tests. But both of them would depend on the first test calling impress().init().
As we cannot benefit from the automatic reset of the div#qunit-fixture element, it is actually very important to emphasize that each test cleans up after itself and tests don't depend on things done by previous test. (For example, it might become necessary to do things like impress().goto(1) between tests. QUnit seems to have an api to do such things between tests.)

About code style, as we probably already discussed, it is better to define and document some guidelines before this is landed (it is going to be done in the "CONTRIBUTING" part of #512). After we define it, we can adjust if necessary as a last step. Does it makes sense holding this until the guidelines are defined by the team?

I agree on the first part: we shouldn't discuss style until there's a document that defines the guidelines.
I disagree on the second part: I think this should go in now. There are still lots of tests that need to be written, and adding QUnit will enable others to help writing tests. Also accepting any other code contributions is now blocked by not having tests. I of course hope we do agree on style guidelines reasonably quickly, but it would be backwards to block adding new code for a style discussion. Editing the code for style is a trivial task once we have agreed on the style guidelines, I will certainly quickly edit my own code if nobody else does it.

In my experience, most coders vastly overestimate the readability of their own code, when read by someone else

That usually happens when there is no code review (which is not the case for open-source projects maintained by more than one person) and when the developer is not aware of common principles of idiomatic code and design patterns. It is definitely possible to create readable code as long as there is enough test coverage to provide safety or refactoring.

You can then read the code to check whether the code does what the comment said

This is an unnecessary additional step to the whole understanding of the code. Also, if the code changes, developers tend to forget to update the comments. My previous statement is actually a fact, not opinion. You can see this happening in many popular open-source and closed-source projects. In jQuery, it is just watching the development for a few months that you will see this happening over and over again, mostly with browser support comments. Needless to say that we are talking about a lib that have more trust than any other library of its kind.
Besides that, I can quote a principle that is proven in the wild and used by the most successful companies in the world, one of which comes from the agile manifesto:

Working software over comprehensive documentation

That principle was created due to the huge amount of evidence that existed and still exists among teams and individuals where internal documentation ends up not being maintained after a while, which always become outdated and obsolete.
Just to clarify that this do not happen with public API docs, because those docs represents the public contract to the consumer of the API, therefore acting as a single source of truth on how the API should behave. Basically if the public docs says something and the application doesn’t behave like that, then the application is the one that should be fixed, not the docs. If the public docs doesn't say something, then that is an undefined behavior. Needless to say that the documentation contract is pretty well understood by specifications such as semver.org, which has specific guidelines of versioning taking into account the public API.

Without comments, you can read what the code does, but there's no reference point that will tell you whether that is what the code is supposed to do.

Yes, there is a reference point that will tell you what the code is supposed to do as stated in the previous comment, and that is the documentation of the public API.

As we cannot benefit from the automatic reset of the div#qunit-fixture element

The idea that I commented earlier might solve this in a very unobtrusive way:
https://github.com/impress/impress.js/pull/510/files#r53293514

it is actually very important to emphasize that each test cleans up after itself and tests don't depend on things done by previous test

I don’t understand this part. The tests are not cleaning themselves and the second one seems to depend in the previous one. Are you saying just to agree that the principle stands but that in this case it is impossible to do it because we can’t use quint-fixture?

(For example, it might become necessary to do things like impress().goto(1) between tests. QUnit seems to have an api to do such things between tests.)

AFAIK QUnit only have APIs for running before/after all tests. Running before/after each module and Running before/after each test. AFAIK there is no API that runs in the middle of tests (only after or before each one).

There are still lots of tests that need to be written, and adding QUnit will enable others to help writing tests. Also accepting any other code contributions is now blocked by not having tests.

These are very good arguments. I understand now why it makes sense doing this ASAP and I tend to agree with it after what you said.

Just to make it clear that my arguments about comments in the code is not about comments that create value to the code, such as comments explaining something that the code doesn't (for any reason). It is specifically about redundancy, commenting what the code is explicitly doing.
Here is an example:

// Helper function to determine whether this browser is supported by
// impress.js or not. Copied from impress.js itself.
var _impressSupported = function() {

It is perfectly clear what the code means:

Helper function

It is declared inside a helper.js file and is a function, therefore a helper function.

to determine whether this browser is supported by impress.js or not

The name is actually _impressSupported(), which means that it checks if "impressSupported()"

Copied from impress.js itself.

That is something unnecessary. A reader wouldn't need to know that. If he wants to find the discussion about why this code was added one can use git blame and eventually reach this PR via cross links that will contain the whole context of why that line was added in the first place. This is one of the reasons I love git and github so much :heart:

I will respond to your latest comment, as it contains a specific example:
Surely you agree, in principle, that each function at least should be preceded by a short description of what it does? I can promise you I will never submit a PR where that would not be the case.
More generally (to your previous comment):
Like I said in the beginning, we probably have a different philosophy here. I'm familiar with your thinking, and I have many friends who believe comments are unnecessary, too often outdated, etc. I consider them bad programmers. (Not because their code doesn't have comments, but because it has bugs.) The reason their comments are outdated is because they don't do their job well. They should have kept the comment up to date when code was changed, and if they didn't, it should have been caught in review. The programmers I respect write clear, commented code.
Agile manifesto also says that we cannot collaborate on this project unless we sit in the same room so we can talk to each other. Within its context (enterprise software), it has done a lot of good, but personally I never felt I had much to learn from it. Open source movement has known how to write good code well before agile manifesto was written (and I'm old enough to talk about that).
Anyway, I think also this discussion falls within the style guidelines discussion. I will plead for my philosophy there, but I think we should commit this code now.

Responding to this question separately:

The idea that I commented earlier might solve this in a very unobtrusive way: https://github.com/impress/impress.js/pull/510/files#r53293514

Yes. I think it is a good idea. It's also enough work that it can be done in its own task, at a later time.

I don’t understand this part. The tests are not cleaning themselves and the second one seems to depend in the previous one. Are you saying just to agree that the principle stands but that in this case it is impossible to do it because we can’t use quint-fixture?

All tests depend on impress().init() being called. There's no point in doing that repeatedly. Apart from that, tests must clean up after themselves. For example second test must remove the event listeners that it added, which it does.

AFAIK QUnit only have APIs for running before/after all tests. Running before/after each module and Running before/after each test. AFAIK there is no API that runs in the middle of tests (only after or before each one).

Yes. I don't see what problem you're discussing here?

Yes. I don't see what problem you're discussing here?

You said "it might become necessary to do things like impress().goto(1) between tests. QUnit seems to have an api to do such things between tests.", then I just pointed out that it seems QUnit doesn't have an API to do things between tests, just before/after each one, which is not the same.

Surely you agree, in principle, that each function at least should be preceded by a short description of what it does?

Let's talk about this specific case. If you are talking about internal test functions whose comments does not generate a public API, then definitely not, not me nor anyone, there is no default rule or principle on that matter, it all depends upon the context. For example, there is not a single popular open-source project that is trusted by many companies and maintained by more than one person that always documents internal test functions by default. In this case, a function preceded by a description of what it does is an evident code smell, and is only used when the code cannot be changed by other reasons (which is clearly not the case for this PR or the examples I mentioned in the other comment) or does not make explicit what it does.

Agile manifesto also says that we cannot collaborate on this project unless we sit in the same room so we can talk to each other.

I never said anything about using any agile methodology here and there is no point in discussing about that. I never use agile in open-source projects for obvious reasons. This is probably an unintentional straw man that was created in this discussion due to an incorrect interpretation of what I meant. What I said is that one of the most evident principles in software development that is also used in one of the most widely used software development methodologies already predicts that documentation should not be abused: "Working software over comprehensive documentation". Creating redundant documentation is totally abusive when you already can use the tests to document how the application is supposed to behave.

Anyway, I think also this discussion falls within the style guidelines discussion.

I definitely disagree with that. Writing useful code has nothing to do about code style, it can't even be verified by a tool like JSCS. It is about writing useful code instead of writing tons of comments to workaround the effort of creating good internal abstractions or comments that add value to the tests. There are very good comments in this PR, I just pointed out some obvious redundant exceptions.
Again, I am not against comments, I am against redundant comments in tests. Impress source code have a very good set of comments that annotate very well what it is supposed to do, sometimes even redudant for more experienced devs, but that is intended because the file is supposed to be used as a learning resource for beginners.

Since it doesn't seems we will get into an agreement on that, I will summon someone else from @impress/mergers or @bartaz to put and end into this discussion so we can get this landed once and for all.
To get a little bit of context and TL;DR for the ones that are coming here without having to read the discussion since the beginning, the discussion here is basically about useless comments in test files.
Take for example this, this and this. Should those kind of redundant comments be kept in test files, or we just document what cannot be infered from the code?

[ ] Keep the redundant comments in test files
[ ] Remove comments from test files when the code is explicit on what it does

When the majority of the team decides what it should be, I will agree with the decision and after that this PR is good to go :+1:

Take for example this, this and this. Should those kind of redundant comments be kept in test files, or we just document what cannot be infered from the code?

Fascinating discussion. Thanks @henrikingo for your coding and documentation efforts, very impressive to try and document to this level. And thanks @FagnerMartinsBrack for your review efforts.
I didn't expect to, but I actually agree with @FagnerMartinsBrack. For sure, there are many helpful comments in the code. At the same time, a few of the comments do seem unnecessary, and I think the code would be slightly more maintainable without them. Either way the decision goes, I don't think it's a big deal for this instance, however--it's very few lines of comments for functions/blocks of code that seems unlikely to change.
I do think the comment specifying code was copied from the main file is useful, perhaps should be marked with a TODO--to abstract the code out from both places at some point. No guarantee any of us will be around then to remember to do that, or to make sure the two versions are still in sync.
Anyway, just chiming in to let you know I'm here and interested to help! :)

@bcipolli Thanks for the comment!
Could you please point out the lines whose comments you think should be removed from the PR, if any? Even though we can remove or improve anything later when we add more tests, it is still better to document the decision so that we can revisit later and not leave it one sided.
Thanks!

Hi guys, thanks for all the work you've put in here: @henrikingo for starting and writing tests and @FagnerMartinsBrack for very detailed reviews.
I just want to join the discussion here, because it seems that this review here is taking quite long and doesn't seem to move forward to finally merging it. So let me point some things to hopefully clean up the test code and have it included as a base in impress.
First of all I treat this PR as just a beginning - setting up of QUnit and some basic tests for impress.js, so it can be extended in the future and anyone willing to contribute will know where and how to put new tests.
From this point of view I would like to see the tests in separate JS file and not included in HTML as it is now.
My second biggest issue is with "Impress Code API" test, which is very big (with lots of internal functions), it's not clear for me what it tests, and it's quite hard to read. It seems to me that the sequence of the actions tested is coded in an array, and it's then performed and asserted, but the amount of nested functions makes it quite hard to understand (even for someone who knows impress.js). The fact that for example assertStepEnter and assertStepLeave use the value of i that is defined and changed outside of their scope is really confusing for me.
Of course I understand that this complexity is partly caused by impress.js itself and the fact that it's features are quite hard to test (in terms of unit testing) right now.
@henrikingo Would it be possible to change the "Core API" test from this 'loop-based' sequence into more coded sequence of actions and checks? This I think would make it more readable. Something like:
QUnit.test( "Impress Core API", function( assert ) {
    // ... writing kinda pseudo-code here
    root.addEventListener("impress:stepenter", stepEnterMocked);
    root.addEventListener("impress:stepleave", stepLeaveMocked);
    impress().goto(2);
    assert.equals(currentStep, step2);
    assert.ok(currentStep.classList.classList.contains("active");
    // .. more asserts here
    impress().next();
   assert.equals(currentStep, step3);
   assert.equals(prevStep, step2);
   // .. etc

Where stepEnterMocked stepLeaveMocked will be some simple handlers that would just store target of event in currentStep/prevStep. I know it may be more complicated because of async nature of events but maybe it would be possible?
I'm also not sure about the need of setTimeout - maybe I'm missing something. It's true that impress.js internally uses events to set classes on elements, but these events are registered internally by impress.js when its initialized, so if in test we register an event (even on the same element) it should be called after internal handlers from impress.js. So when any external handler is called elements should already have the classes assigned to it. Is it not the case?
These are the things I would focus on in this PR to finish and include it.
Any discussion about code style or comments I would leave for now. We don't have any official code style (and I myself don't use the same style I used when writing impress.js anymore) so this can be updated later. And in terms of comments it may be topic for another discussion, but I prefer to have them, especially when they tell why (or how) something is done - not what is done (which should be self explanatory from the code).
Sorry for this long comment, I'll try to keep an eye on this PR because it seems valuable for future changes to impress.js.
Thanks everyone for all the work you done here so far and let me know what you think about my suggestions here.

:point_up: @bartaz I agree with everything you said, including about being declarative and the observation on the comments (which is to document only what the code can't tell for itself).

Hi @bartaz
Thanks for joining, I think your point of view was really needed.

From this point of view I would like to see the tests in separate JS file and not included in HTML as it is now.

This is ok. I already have done that in my own fork, but didn't want to push more into this branch yet.

I'm also not sure about the need of setTimeout - maybe I'm missing something. It's true that impress.js internally uses events to set classes on elements, but these events are registered internally by impress.js when its initialized, so if in test we register an event (even on the same element) it should be called after internal handlers from impress.js. So when any external handler is called elements should already have the classes assigned to it. Is it not the case?

Most of the things impress.js does after goto() is done in the [event listener] (https://github.com/impress/impress.js/blob/master/js/impress.js#L586). So when in test code we add an event listener, as far as I understand, those are equals and execute in parallel. You can test this by registering the event handler without a setTimeout wrapper:
root.addEventListener( "impress:stepenter", assertStepEnter );
root.addEventListener( "impress:stepleave", assertStepLeave );

With the above you will either get test failures (because not all CSS classes are set yet) or the test will hang (I believe because test framework called the next impress().goto() too fast).
So the setTimeout is unfortunately needed to ensure that impress.js event listener has finished before the test code checks for its results. This could of course be changed, but we would have to change impress.js code to do so, and now the primary goal was to add tests before any impress.js code is touched.
Note that apart from the above explanation, the setTimeout of course doesn't add any other value to the testing. It's true that it is an unfortunate additional layer of indirection.

Would it be possible to change the "Core API" test from this 'loop-based' sequence into more coded sequence of actions and checks?
...
Where stepEnterMocked stepLeaveMocked will be some simple handlers that would just store target of event in currentStep/prevStep. I know it may be more complicated because of async nature of events but maybe it would be possible?

It is of course possible, and if even you have a hard time reading the current code, then maybe we need to think about it. But it is certainly not going to be as elegant as your above pseudo code suggests.
First of all, all the asserts of course need to be done inside the event handler. Otherwise they will execute immediately, before even the first ´next()´ has completed and triggered the first event(s).
From that observation, the second problem is that if I'm not allowed to use a loop structure to make the event handlers parametrized, I think the only way to do this would be for each event handler to end with removing itself, and adding the next event handler.
So, just to give a short example:
QUnit.test( "Impress Core API", function( assert ) {
  var eventHandler1_enter = function(event) {
     assert.ok(...)
     assert.ok(...)
     ...
     impress().next()
     assert.ok( /* the things currently in assertImmediately() */ )
     ...
     root.removeEventListener( eventHandler1_enter )
     root.addEventListener( eventHandler2_enter )
   }

var eventHandler2_enter = function(event) {
   ...

(Note that above the wrapper calling setTimeout() is omitted for simplicity, but would of course have to be added back for the real code. And if we want to be consistent in this direction, there would now be a different setTimeout() wrapper for each step as well?)
There would be 7 such event handlers for stepenter, another 7 for stepleave. Each containing 6-8 assertions. So in total by "unwinding" the current loop approach, we would be adding about 110 lines of code. Note that this then repeats if we have to use the same style for testing the key and mouse navigation (which has 12 transitions instead of 7!), and probably more future tests as well. So just for this js file we're talking about 200+ additional lines of code.
Finally, I think both you and @FagnerMartinsBrack have struggled with the fact that we're checking both stepenter and stepleave in parallel, and can call impress().next() only after both code paths are finished. This is why the readyCount and readyForNext() functions are used to start the next step. So to simplify this part we would have to (as already suggested by @FagnerMartinsBrack) separate the tests checking for stepenter and stepleave into their own QUnit.test() blocks. This will actually not add much more lines of code (maybe 10-12 or so) but will double the execution time of the tests. But that is acceptable IMO if we really want to go this way.
Much bigger problem is code maintainability, when same code is copy pasted 7 times. I can say for sure that it would not have been feasible to develop the tests in the style we're now discussing, since every simple change will then have to be done 14 different times (or 24, for the key/mouse navigation). But of course now that the tests are done and working, I can unwind them into a longer, more readable format, with the expense of making future maintenance of the tests more laborous.
My compromise suggestion here would be to do the last part: We can separate the stepenter and stepleave tests into their own QUnit.test() blocks, and get rid of the readyCount / readyForNext() logic, but keep the loop structure (to avoid serious code bloat). At least I can easily do this first with little effort, then you can judge if code is any more readable with such a change or if more unwinding is needed.

Even if the suite takes more time, we can reduce the time later, for example, by testing  without waiting for transitions or creating better preparations before/after each test.
There seems to be a lot of complexity in the process that maybe could be simplified a lot if we talk about each problem in isolation:

Much bigger problem is code maintainability, when same code is copy pasted 7 times.

Which code will be pasted 7 times? Can you give us an example? What does that code tests? And why there will be a problem with code maintainability?

I can say for sure that it would not have been feasible to develop the tests in the style we're now discussing, since every simple change will then have to be done 14 different times (or 24, for the key/mouse navigation).

Can you please give an example of a simple change that would make it necessary to be done 14 different times? I mean, we should't try to aim for 100% coverage right in the beginning, if that's what you are talking about.

Hi @FagnerMartinsBrack, and thanks for asking

Which code will be pasted 7 times? Can you give us an example? What does that code tests? And why there will be a problem with code maintainability?

So, as is probably clear by now, we want to test different transitions: goto(), prev(), ǹext() etc... After each transition, we verify several css and other properties, the same assertions each time. So if I cannot use a loop, naturally the contents of the current loop have to be copypasted into a sequence instead. Specifically, we are talking about these lines from assertStepEnter():
assert.equal( event.target, sequence[i].entered,
              event.target.id + " triggered impress:stepenter event." );
assert.ok( event.target.classList.contains("present"),
           event.target.id + " set present css class." );
assert.ok( !event.target.classList.contains("future"),
           event.target.id + " unset future css class." );
assert.ok( !event.target.classList.contains("past"),
           event.target.id + " unset past css class." );
assert.equal( "#/"+event.target.id, window.location.hash,
              "Hash is " + "#/"+event.target.id );

and also these, from assertImmediately():
assert.ok( sequence[i].entered.classList.contains("active"),
           sequence[i].entered.id + " set active css class." );
assert.ok( !sequence[i].left.classList.contains("active"),
           sequence[i].left.id + " unset active css class." );

Then the same has to be done for all assertions in assertStepLeave() as well.

Can you please give an example of a simple change that would make it necessary to be done 14 different times?

Say that for some reason, the active step would no longer have a present css class, but we instead want to call it current. This would be a simple change in impress.js. But for these tests you would have to repeat that change for every time you copy pasted those assertions.
(Obviously, while developing tests, it would be impossible to have to do all the try and error with such an un-looped code, since the whole process of writing tests becomes 14 times slower for every edit.)

I guess the problem is much clearer now, so here are my insights.

Say that for some reason, the active step would no longer have a present css class, but we instead want to call it current. This would be a simple change in impress.js. But for these tests you would have to repeat that change for every time you copy pasted those assertions.

Sure, and in this specific example There is no problem with that. All tests that rely on the present class will need to be changed because they will fail anyway. Increase the abstraction just to change in a single place for a test has no value to prevent this sort of things, I will explain why.
Let's take a look in the benefits of abstracting code and using DRY in the source code:

You reduce the amount of bytes from the codebase, which is definitely a must in order to reduce the library size for the end-user.
If we change a .present somewhere in the source, we might forget to do that in another part and the tests might not get this bug. This is one of the the main reason why DRY exists. The 100% coverage is pretty hard, usually we start testing a single common path, assuming that the code is properly DRY and reused in many parts of the system, then one common test has a higher probability to cover more than a single path of the program execution due to this assumed reusability inside (which can easily be spotted by code review, a static testing pattern).

Now, those benefits apply to testing code?

In testing code we don't care about bytes, because that will not be downloaded by the end-user.
If we change .present to .current in the source code, then we need to take extra care in code review to know that it will be changed everywhere it is being used. In the tests though, it will just break all tests that are checking for .present, no need for extra effort because the tests are declarative. If a test does not break if the behavior changes, then the test is non deterministic and therefore is useless and should be removed.

Another benefit in changing the test in the places it is being directly asserted is that the reviewer will know exactly, by the diff, which tests are being affected by the change, instead of having to understand the whole abstraction and complex logic first. This might expose other things, such as useless tests.
I remember a quote I read once, don't remember the author which was something like this:

You can make good tests become faster, but you can't make faster tests become good

Basically it means that we can fix problems in the future if we start in a simple way, incrementing the value of the code over time. This way, we can visualize the need for complexity and discuss as a team later.
My suggestion would be something like this (pseudo code):
QUnit.module( "Core API", {
  before: function() {
    // Reset the whole impress.js state
  }
});

QUnit.test( "Initial state", function() {
  // Given 2 steps
  test.assert( /* step 1 has active/present classes */ );
  test.assert( /* step 1 triggered the stepenter event */ );
  test.assert( /* step 2 has future class */ );
  test.assert( /* hash is correct */ );
});

QUnit.test( "Left/Right move", function( test ) {
  // Given 3 steps
  // (The initial state is already tested)
  impress.next();
  test.assert( /* step 2 has active/present classes */ );
  test.assert( /* step 2 triggered the stepenter event */ );
  test.assert( /* step 1 has past class */ );
  test.assert( /* step 3 has future class */ );
  test.assert( /* hash is correct */ );
  impress.prev();
  test.assert( /* step 1 has present/active classes */ );
  test.assert( /* step 1 triggered the stepenter event */ );
  test.assert( /* step 2 has future class */ );
  test.assert( /* hash is correct */ );
});

Of course we need to account for async stuff and other requirements for the code to work, but always keep in mind to create declarative tests so that it serves also as a documentation of what is supported for future and existing maintainers. If it breaks, then we need to change it exactly in the specific assertion, so we know why it broke without having to understand the underlying logic behind it.

I'm sorry, I don't quite understand what you're arguing for or against.
It's an undisputable fact that to change something in 14 different places (let alone 24, etc...) takes 14 times more time than changing it in one place. I don't know why you insist on ignoring this fact, but since I am the person actually writing this code, I happen to care about it quite a lot.

That's true - repetition (especially many times) is never a good sign. I don't want to be a devils advocate, but I would argue that 14 repetitions don't always mean 14 times more time, because short but complicated code may take similar amount of time to understand and do this single required change.
And also if there is so much repetition in tests, maybe we are testing the same thing couple of times unnecessarily?
We need to find a balance between not repeating too much while keeping it simple enough to understand and change. The hardest part of programming I guess ;)
But the truth is (and I'm guilty too looking at my previous and this comment) that we are in my opinion writing too much text in this discussion not making much progress.
Clearly the "Core API" test part is a biggest point in this discussion right now and source of confusion.
@henrikingo, I understand why you used loop approach to avoid duplication but in the current state it's quite hard to understand what this tests does (what it tests) and how to change or add anything to it.
To make test suite to be useful and used by other people (for example to require PRs having their tests) we need to make it simple - as far as it is possible with qunit and impress constraints. It's hard as far as we see in this discussion.
I would like to have tests in impress.js, it's great @henrikingo that you managed to set them up and got them running in quite unfriendly asynchronous and animation based impress.js environment. First step - the base - is already here. I would suggest to - at least for now - leave the confusing "Core API" part and merge the tests without it. Or reduce it to single test without loop (just check if calling goto changes step and classes on it). This will give us the base to add another tests later and work on any repetitions if necessary step by step.

It's an undisputable fact that to change something in 14 different places (let alone 24, etc...) takes 14 times more time than changing it in one place. I don't know why you insist on ignoring this fact, but since I am the person actually writing this code, I happen to care about it quite a lot.

Please, do not start to act defensively assuming that I am ignoring principles or facts, I acknowledge it perfectly. I am here to help, just like you :+1:
The fact is that if there is a need to change the test in 14 different places then something is wrong, in the example I gave above there are only 3 assertions in which the .present class will have to be changed in order to get a very good initial coverage, which is reasonable. After testing the correct inclusion of the .present class once (or for each API, maybe), then there is no need to test it again all the time and we can focus in testing other stuff. Also, by arguing that the .present class will be changed we are creating complexity to defend ourselves against a speculative future: we don't know if the class will be changed, and if it does we can act accordingly in the future do handle any problems that come with that.
I guess the problem is that this PR does more than one thing, and that makes it harder to understand because there are a lots of assumptions in the current code. Ideally, a Pull Request should be atomic and do one thing, and one thing only. We should start simple, with little code as possible, and then increase complexity over time, if necessary.
So, here is my suggestion, please tell me what you guys think about it:
Start with the QUnit structure and the JavaScript code separate in a different file (which is not a speculative future, we will need that eventually), and a single atomic test (not module), that can be run alone or with the whole suite.
For example: Test only the .next() API. Assert that it adds the past/present/future and active classes in a single PR. After it is merged, we can create a new PR that adds a test for something else, so we can focus in only one thing at a time.
@henrikingo @bartaz Does that makes sense? I guess this will make the communication much better and help to land things faster :)

New push.
Forgot to say in commit message that I renamed from index.html to core_tests.html, because when I put the tests into a separate .js file I didn't want to call it index.js. (as this could lead people it has special meaning for example within an npm context.) Ie. the new javascript file is then called core_tests.js.

@henrikingo Thanks for the update!
I have taken some time to actually run the code and check it deeply. The previous reviews were only static, based on the assumption that everything works as expected. I never actually run the code.
So, given this deep review my insights are below:

The second test doesn't run alone. Is it intended? Can we do it in a way that each test is atomic and can be run separately?

I haven't finished taking a deep look into the implementation. I will continue tomorrow :+1:

I have created a Pull Request on top of this PR with some suggestions: https://github.com/henrikingo/impress.js/pull/1

@henrikingo Just pinging to know if you are still tracking this.
Let me know if there is anything I can do to help or make any of my suggestions above clearer.
I ask this because #535 seems to be sort of dependent on this PR, since there is more than just white-space changes and a test is always welcome.

@henrikingo @bartaz Pinging one more time. If there is no comment I will push https://github.com/henrikingo/impress.js/pull/1 through.


Fix powershell escaping

Fix what was left in #2641

@janlazo Thanks! That explains the implementation of s:shellesc_ps1. [^1] Fzf is not subject to the rules specified in CommandLineToArgvW, so it looks like internal requirement of the plugin. Correct me if I am wrong please.
Is there any scenario that would cause issues when the quoteEntry method wouldn't escape " with backslash. Note that quoteEntry escapes strings only when expanding fzf's placeholders (like {}, {q} etc). There is a gap in my understanding that would connect something like fzf --bind "enter:execute(nvim {}) and the jobstart command from vim/nvim.
I am asking for this because @stinos is proposing to use powershell's native quoting rules and if that would not break any workflows I think @junegunn could actually like it more (the rules are closer to how fzf escapes strings on *nix).
[^1]: I am comparing the two if branches in L1422 and L1432

Any Windows program that executes external commands is subject to CommandLineToArgW.
golang does it by default.
golang doesn't special-case cmd.exe so cmdline is non-empty when the shell is cmd.exe.
Command passed to jobstart must be escaped. Editor plugin doesn't have to escape commands that fzf (binary) will execute internally. When executing the expanded command,  inner " must be escaped (on Windows).
Backtick escaping seems to specific to powershell. cmd.exe doesn't special-case backticks. It can work for the value passed to -Command.  I wouldn't use it when dealing with external programs.

New test suite added, with docs. It drops one level of escaping in favor of using powershell's native escaping. Good way to see the difference is to compare those two commits: old and new.

@vovcacik Thanks for the test cases!
@rashil2000 Can you merge @vovcacik's PR to your branch? Let's wrap this up.

Rebased to tidy up the commits.

Merged, thanks!


Const in object assign is causing Uglify to broke

The last version 1.2.0 has a "const" declaration in the built js file (src/js/preloader.js).
This is causing uglify to broke.
GulpUglifyError: unable to minify JavaScript
Caused by: SyntaxError: Unexpected token: keyword (const)

@LucaDb My mistake. Please upgrade to v1.2.2 .


Change scroll speed on jupyter notebooks

I see that we can edit the scroll speed of the regular editor with "editor.mouseWheelScrollSensitivity", but this setting does not seem to affect the scroll speed of jupyter notebooks at all. Right now, scrolling on a notebook skips about 16 lines of code, which makes it really difficult to review code, and I can't seem to find any help on how to change this. The closest I found was this issue and this issue, but it doesn't sound like there's a proper resolution to fixing/editing the scroll speed of jupyter notebooks.

This can be controlled via workbench.list.mouseWheelScrollSensitivity.

We closed this issue because it is a question about using VS Code rather than an issue or feature request. Please search for help on StackOverflow, where the community has already answered thousands of similar questions. You may find their guide on asking a new question helpful if your question has not already been asked. See also our issue reporting guidelines.
Happy Coding!


sum(deriv()) does not like timeseries appearing/disappearing

I have a bunch of gauges collected via sql_exporter. The metric for a given label set only exists when its value is nonzero (they're mostly row counts; zero rows means no count means no metric).
This is what the input data looks like. The red timeseries is either 1 or does not exist here (graphing it alone yields no points where the combined graph shows it as 0):

Making the query deriv(metric[2m]) yields a hole in the middle:

Presumably this is some kind of degenerate case where deriv() doesn't like the data coming and going.
This wouldn't be a big deal in and of itself, but when wrapping the expression in sum(), that hole punches a hole in the final sum:

And that is clearly not what I want. delta() doesn't have the problem, but does not scale per second. rate() works here but is obviously wrong on a gauge when the value goes down. There seems to be no rate() equivalent for gauges (deriv() is a lot more complex).
prometheus, version 1.5.2 (branch: , revision: bd1182d)
  build user:       portage@binhost
  build date:       20170329-06:45:32
  go version:       go1.7.5```

(they're mostly row counts; zero rows means no count means no metric).

This is going to make any result statistically invalid. You're also likely running into staleness issues.
Produce a 0 when there's 0.

The problem is there's no easy way to pull a set of possible values for columns in a SQL table (and sql_exporter doesn't support anything like this anyway, otherwise I could've made a token attempt to hardcode some label sets in). All I can do is aggregate by certain columns and produce metrics for the tuples that happen to exist.
I know having missing metrics isn't nice, but surely there must be a way to handle this other than "don't do that". I don't even care about edge-case behavior in a time series that is just fluttering around 0; it's noise anyway. But it's killing an overall aggregation.

This smells like a NaN is propagating, but this code can't produce a NaN from a quick look.
Can you share your raw data?

I know having missing metrics isn't nice, but surely there must be a way to handle this other than "don't do that".

You can't do much about time series that only exist sometimes and you don't have a way of figuring out their identities when they don't exist.

Looking at the data returned by the underlying query_range API for the second graph I do see NaNs.
What is the correct way to pull out the raw data for this time range?

metric[10m] in the expression browser console

This is historical (yesterday), but here's the problem part (it's the first time this metric exists):
"values":[[1493712456.939,"1"],[1493712486.939,"1"],[1493712516.939,"1"],[1493712546.939,"1"],[1493712576.939,"1"],[1493712606.939,"1"],[1493712636.939,"1"],[1493712666.939,"1"],[1493712696.939,"1"],[1493712726.939,"1"],[1493712816.939,"1"],[1493712846.939,"1"]]
Then there's a gap and at timestamp<PHONE_NUMBER>.939 the metric exists again, but that's outside the range I was graphing.
The problem query returning NaNs is: deriv(metric{...}[5m]). Via query_range the time range requested is start=1493712420&end=1493713320&step=3. The (interpolated) return data becomes NaN starting at timestamp<PHONE_NUMBER> and continuing until<PHONE_NUMBER>; there's no further data returned after that.

Doing the math by hand, the result comes out as 0 - which is what you'd expect for a horizontal line.

Any idea what's going on here? Let me know if you need more information/data.

The data doesn't line up with the behaviour. Can you verify NaNs are being returned by the API?

Yes, I see NaNs come back in the query_range response.
$ curl 'https://foo/api/v1/query?query=sql_party_users%7Bwith_seat%3D%22false%22,database%3D%22eps-prod%22,in_group%3D%22true%22%7D%5B20m%5D&time=1493713320&step=3'
{"status":"success","data":{"resultType":"matrix","result":[{"metric":{"__name__":"sql_party_users","col":"count","database":"eps-prod","driver":"postgres","in_group":"true","instance":"tohru:9237","job":"sql_exporter","party":"ee25","sql_job":"global","with_seat":"false","with_ticket":"false"},"values":[[1493712456.939,"1"],[1493712486.939,"1"],[1493712516.939,"1"],[1493712546.939,"1"],[1493712576.939,"1"],[1493712606.939,"1"],[1493712636.939,"1"],[1493712666.939,"1"],[1493712696.939,"1"],[1493712726.939,"1"],[1493712816.939,"1"],[1493712846.939,"1"]]}]}}
$ curl 'https://foo/api/v1/query_range?query=deriv(sql_party_users%7Bwith_seat%3D%22false%22,database%3D%22eps-prod%22,in_group%3D%22true%22%7D%5B5m%5D)&start=1493712420&end=1493713320&step=30'
{"status":"success","data":{"resultType":"matrix","result":[{"metric":{"col":"count","database":"eps-prod","driver":"postgres","in_group":"true","instance":"tohru:9237","job":"sql_exporter","party":"ee25","sql_job":"global","with_seat":"false","with_ticket":"false"},"values":[[1493712510,"0"],[1493712540,"0"],[1493712570,"0"],[1493712600,"-0.00000000009313225746154786"],[1493712630,"0"],[1493712660,"0"],[1493712690,"0"],[1493712720,"0"],[1493712750,"0"],[1493712780,"0"],[1493712810,"0"],[1493712840,"0"],[1493712870,"0"],[1493712900,"0"],[1493712930,"0"],[1493712960,"-0.000000000038805107275644936"],[1493712990,"0"],[1493713020,"0"],[1493713050,"NaN"],[1493713080,"NaN"],[1493713110,"NaN"]]}]}}

At this point I'm suspecting floating point calculations are broken somewhere. Can you printline https://github.com/prometheus/prometheus/blob/master/promql/functions.go#L645 for one of the NaN evaluations and see where it's coming from?
For anyone else debugging, the two relevant data points in are<EMAIL_ADDRESS><EMAIL_ADDRESS>

There's not enough to go on here and everything seems okay. Lacking further information I have to presume a hardware fault.

I have a data dump of the problem storage, I just haven't had time to dig into it yet. I highly doubt it's a hardware fault, but I'll reopen when I get a chance to investigate.

It's a floating point precision issue.
: s={%!f(model.Time=1493712846939) 1.000000} x=1493712846.939000 n=2.000000 sumY=2.000000 sumX=2987425663.878000 sumXY=2987425663.878000 sumX1=4462356048598455296.000000
slope=NaN intercept=NaN covXY=0.000000 varX=0.000000

covXY isn't really zero, but for large numbers like UNIX timestamps which differ only by a few seconds, it underflows down to zero. Looks like the standard fix for this is to precompute the mean and subtract it out from samples, instead of directly implementing the textbook formula.
Please reopen.

Python3 reproducer:
>>> var = lambda a,b: (a*a+b*b) - ((a+b)*(a+b)/2)
>>> var(1493712816939000000/1e9,<PHONE_NUMBER>939000000/1e9)
0.0

Note that the round trip through nanoseconds is necessary for the floating point stars to align:
>>> var(1493712816.939,<PHONE_NUMBER>.939)
512.0

The precision we're getting here is in units of 512. This makes sense, because with UNIX timestamps we're at 31 bits, 62 bits squared, and the mantissa of double floats is only 53 bits: 2**9=512. The true variance is 450. Looks to me like even when the value doesn't underflow down to zero, the output of this function as implemented for deriv() with the magnitudes involved here is basically complete garbage and buried by floating point roundoff error; less than one bit of precision.


Upgrade Ionic

@rinogo as you are actively working on this, it would be great to upgrade Ionic at some point if you have time.
the package is not ionic-sdk anymore but<EMAIL_ADDRESS>

Closes #6


Loading Arcgisbinding Issue

Hi,
I am trying to get R-ArcGIS Bridge up and running but whenever I try load the 'arcgisbinding' package in R, I receive this error:
> library(arcgisbinding)
Error: package or namespace load failed for ‘arcgisbinding’:  package ‘arcgisbinding’ was installed before R 4.0.0: please re-install it
I am running ArcGIS Pro 3.0.2 and R 4.2.2 on a company computer. I have successfully installed the most recent 'arcgisbinding_<IP_ADDRESS>' package into R but just cannot seem to load it in. The following screenshot confirms that the package is installed in ArcGIS Pro but I also get the following error when I attempt to check package for updates:

I have browsed everywhere online for a solution to this but cannot seem to find anything. Any guidance on this issue would be much appreciated.

Can you provide the output of .libPaths() and SessionInfo() from R? It looks like perhaps the library locations are talking across versions and it is finding an older version of the arcgisbinding package elsewhere. I was able to resolve that URL, but we have had some intermittent reports of it not working, the site is actually backed by GitHub and it isn't clear the nature of the issue. You can try manually updating the package by starting an R session and running:
install.packages("arcgisbinding", repos="https://r.esri.com", type="win.binary")

Thanks for getting back to me @scdub, the outputs are below:
> .libPaths()

[1] "C:/Users/Aspkin/AppData/Local/R/win-library/4.2" "C:/Program Files/R/R-4.2.2/library"

> sessionInfo()

R version 4.2.2 (2022-10-31 ucrt)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 19044)

Matrix products: default

locale:
[1] LC_COLLATE=English_United States.utf8  LC_CTYPE=English_United States.utf8    LC_MONETARY=English_United States.utf8
[4] LC_NUMERIC=C                           LC_TIME=English_United States.utf8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

loaded via a namespace (and not attached):
[1] compiler_4.2.2 cli_3.4.1      tools_4.2.2

And when running the manual update code you provided, I receive the following error:
> install.packages("arcgisbinding", repos="https://r.esri.com", type="win.binary")

Installing package into ‘C:/Users/Aspkin/AppData/Local/R/win-library/4.2’
(as ‘lib’ is unspecified)
Warning in install.packages :
  unable to access index for repository https://r.esri.com/bin/windows/contrib/4.2:
  cannot open URL 'https://r.esri.com/bin/windows/contrib/4.2/PACKAGES'
Warning in install.packages :
  package ‘arcgisbinding’ is not available as a binary package for this version of R

A version of this package for your version of R might be available elsewhere,
see the ideas at
https://cran.r-project.org/doc/manuals/r-patched/R-admin.html#Installing-packages

These are also the only versions of R, Arcgis Pro and arcgisbinding I have installed on my computer.

OK, thanks for the details. It looks like the URL isn't being accessed correctly. It could be an R issue, something network related, or something with our redirects. Can you see if running this command downloads the package?
download.file("https://r.esri.com/bin/windows/contrib/4.2/arcgisbinding_<IP_ADDRESS>0.zip", "arcgisbinding_<IP_ADDRESS>0.zip")

Then getwd() to see where it was written (most likely into your %USERPROFILE%). If that also fails, can you try downloading https://r.esri.com/bin/windows/contrib/4.2/arcgisbinding_<IP_ADDRESS>0.zip via your browser to see if that works? Once you have the package locally, you can use Packages > Install Packages from Local Files in default R or Tools > Install Packages > select Install From "Package Archive File" in RStudio.

Using the command returns this error which I suspect may be a company network issue:
> download.file("https://r.esri.com/bin/windows/contrib/4.2/arcgisbinding_<IP_ADDRESS>0.zip", "arcgisbinding_<IP_ADDRESS>0.zip")
trying URL 'https://r.esri.com/bin/windows/contrib/4.2/arcgisbinding_<IP_ADDRESS>0.zip'
Error in download.file("https://r.esri.com/bin/windows/contrib/4.2/arcgisbinding_<IP_ADDRESS>0.zip",  :
  cannot open URL 'https://r.esri.com/bin/windows/contrib/4.2/arcgisbinding_<IP_ADDRESS>0.zip'
In addition: Warning message:
In download.file("https://r.esri.com/bin/windows/contrib/4.2/arcgisbinding_<IP_ADDRESS>0.zip",  :
  URL 'https://r.esri.com/bin/windows/contrib/4.2/arcgisbinding_<IP_ADDRESS>0.zip': status was 'SSL connect error'

But it looks like I have managed to install and load the package using the download link instead and there are no issues with the working directory, output below:
> library(arcgisbinding)
> arc.check_product()
product: ArcGIS Pro (<IP_ADDRESS>056)
license: Advanced
version: <IP_ADDRESS>0
> getwd()
[1] "C:/Users/Aspkin/Downloads/Stats"

If you don't mind me asking, is arcgisbinding <IP_ADDRESS>0 an unreleased version? Because previously, <IP_ADDRESS> was the most recent version I could find online.

OK, I think the SSL connect error is informative and means that R / Pro are connecting to the site correctly but having issues with TLS, but that is working fine from your browser. It may be related to configuration settings on secure sites within your organization, typically there is some difference between browsers and external clients. I'm glad we found a work around and can look further in terms of why it might be failing. For the package version, we released v300 in June of this year and it is public.

Amazing, thanks for all your help and enjoy the rest of your year :)


docker pull: Display available tags when tag not found

❯ docker pull python:26.5
Pulling repository docker.io/library/python
Tag 26.5 not found in repository docker.io/library/python

It would be nice in this situation if it could show the available tags in the repository.

it seems this need distribute to have API to get all tags
https://docs.docker.com/engine/reference/api/docker_remote_api_v1.22/
Right now, docker search not have related tag information

+1

USER POLL
The best way to get notified of updates is to use the Subscribe button on this page.
Please don't use "+1" or "I have this too" comments on issues. We automatically
collect those comments to keep the thread short.
The people listed below have upvoted this issue by leaving a +1 comment:
@skairali

has anybody started working on it? if not we would like to take a look at fixing it

@gigidwan

If no body has claimed it yet - can I claim it?

@skairali you can, but I think this will require changes in Docker Hub, so not sure we can implement it in the client?

@thaJeztah  yes you are right.

I think implementation would be challenging. Going to close it for now. Feel free to open new issue if you have ideas how to do that.


Does cholespy keep track of gradients during the solve?

Hello! I am using Cholespy to compute the gradient dx/db for backpropagation after solving a sparse linear system Lx=b. But I notice the x.grad_fn will be None after the cholespy solve.
Just wondering, does cholespy support keeping track of the gradients during the solve? If not, do you have any suggestion about other packages that support that? Thanks!
Thank you so much for providing this awesome library!! :)

Here is the piece of the code I used for testing:
import torch
import scipy as sp
from cholespy import CholeskySolverF, MatrixType

if __name__ == "__main__":
    n = 20
    L = 0.1 * sp.sparse.eye(n)

    device = 'cpu'
    # device = 'cuda'

    [rows, cols, values] = sp.sparse.find(L)
    rows = torch.tensor(rows, dtype=torch.long, device=device)
    cols = torch.tensor(cols, dtype=torch.long, device=device)
    values = torch.tensor(values, dtype=torch.float32, device=device, requires_grad=True)

    solver = CholeskySolverF(n, rows, cols, values, MatrixType.COO)

    b = torch.ones(n, device=device, requires_grad=True)
    x = torch.zeros_like(b, requires_grad=True)

    solver.solve(b, x)
    print("x grad: ")
    print(x.grad_fn)

    g = torch.autograd.grad(outputs=x[0], inputs=b)
    print('gradient:')
    print(g)

Hi,
Cholesky does not support differentiation by default, since the implementation of such a feature would depend on the AD framework being used, and we want this package to be as general as possible.
However, it is relatively straightforward to implement this on your end. It is simply a matter of defining a differentiable custom op in the framework of your choice (see here for PyTorch) that defines what should be done when backpropagating through this function. For a linear system, that is simply solving the same linear system, but replacing b with b.grad.
For further reference, here is how I implemented a similar op for a project (it is a bit similar as it allows using different types of solvers, but the idea is the same).
Hope this helps!

Ohhh thank you!! This is super helpful! :)

Closing this now. Don't hesitate to reopen the issue or reach out if you run into issues while setting this up.


call conn.close() at more explicit place

now conn.close() is called at outer block of loops.
but here is not arrived when error happened within loop.

i think just returning result from loop works.


setup docker-compose link

set up link to docker compose that allow containers to discover each other and securely transfer information about one container to another container

Can we close this ?


Library name change request

Library repository URL
https://github.com/AlexRosito67/QUAD7SHIFT

Hi @AlexRosito67. I am confirming your request.
Unlike submissions, this type of request is still handled manually. The Library Manager index maintainer occasionally comes through to clear all the outstanding requests. They will close this issue when it is done. You will get a notification from GitHub at that time.
After that, you can monitor the indexing of the library via its dedicated logs web page.
Information about that here:
https://github.com/arduino/library-registry/blob/main/FAQ.md#can-i-check-on-library-releases-being-added-to-library-manager

Please help me change my library's name from FSSD to QUAD7SHIFT. Here are the reasons I think the name should change:
The problem is that my library was called FSSD and it might have a name that can confuse the potential user about the purpose of my library. I, then, decided to change its name to QUAD7SHIFT (Four seven segment displays with shift registers, not a great name either but I'm not too imaginative). But even though I could change the name it seems that in your side you are still getting the library.properties with the information of the FSSD library that, by the way,  lacks of the correct url which has an * and not "https://github.com/AlexRosito67/QUAD7SHIFT".
Thank you so much for your help.

Done:
2023/08/14 09:06:03 Loaded 6086 libraries from DB
Removing FSSD
Success!


AliasAnalysis: a complete overhaul of alias- and memory-behavior analysis

The main changes are:

Rewrite everything in swift. So far, parts of memory-behavior analysis were already implemented in swift. Now everything is done in swift and lives in AliasAnalysis.swift. This is a big code simplification.

Support many more instructions in the memory-behavior analysis - especially OSSA instructions, like begin_borrow, end_borrow, store_borrow, load_borrow. The computation of end_borrow effects is now much more precise. Also, partial_apply is now handled more precisely.

Simplify and reduce type-based alias analysis (TBAA). The complexity of the old TBAA comes from old days where the language and SIL didn't have strict aliasing and exclusivity rules (e.g. for inout arguments). Now TBAA is only needed for code using unsafe pointers and for classes. The new TBAA handles this - and not more.

Handle aliasing in begin_access [modify] scopes. We already supported truly immutable scopes like begin_access [read] or ref_element_addr [immutable]. For begin_access [modify] we know that there are no other reads or writes to the access-address within the scope.

Don't cache memory-behavior results. It turned out that the hit-miss rate was pretty bad (~ 1:7). The overhead of the cache lookup took as long as recomputing the memory behavior.

@swift-ci test

@swift-ci benchmark

@swift-ci test

@swift-ci test


Update Transporter Desktop to version 4.2.3_20317

This commit updates the version and sha256 stanzas.

Updating the :checkpoint value in appcast is required. You can find it with curl --silent --compressed "{{appcast_url}}" | sed 's|<pubDate>[^<]*</pubDate>||g' | shasum --algorithm 256 | awk '{ print $1 }'.
Alternatively, you may wish to use cask-repair. It can at once update the cask’s version (according to what you give it) taking care of updating both the cask’s sha256 and the appcast’s :checkpoint, while still giving you the chance to perform other manual fixes.
You can easily install it with brew install vitorgalvao/tiny-scripts/cask-repair. cask-repair --help will show you some options, but as a whole the script will guide you through the update process.

I’m kinda confused now - I started into doing this, and I’ve noticed that the Cask is already up to date with the Transporter version in master, but my PR is still showing a diff. I think this one should be closed, but I’ve made note to update the :checkpoint value in future! (Been a while since I’ve been updating outside of homebrew-versions!)


GameBoy Color infrared emulation?

TWiLightMenu++ on 3DS and DSi systems has the capability to passthrough IR commands to a retail game such as Pokemon inserted into Slot-1. Would it be possible to emulate the GameBoy Color IR blaster using a Slot-1 cartridge for games such as Mission: Impossible and Pokemon Pinball?

THEORETICALLY this might work, but different IR devices may use different
IR bands and the GBC was very particular about IR so it may just refuse to
work or it could receive the wrong bits first or...
it's stupid difficult to link up 2 GBCs with IR, much less a GBC and
something else it wasn't made for...
On Wed, Jan 1, 2020 at 1:49 PM tomrow<EMAIL_ADDRESS>wrote:

TWiLightMenu++ on 3DS and DSi systems has the capability to passthrough IR
commands to a retail game such as Pokemon inserted into Slot-1. Would it be
possible to emulate the GameBoy Color IR blaster using a Slot-1 cartridge
for games such as Mission: Impossible and Pokemon Pinball?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Drenn1/GameYob/issues/176?email_source=notifications&email_token=AHE6CQMJXOKEYVHPHHT3GBTQ3TXUZA5CNFSM4KB4PTG2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IDSYNBA,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHE6CQLUEDIUN4TM7XATCNLQ3TXUZANCNFSM4KB4PTGQ
.


Update to correspond to D3 v4.7

Specifically update the dependencies on:

[ ] d3-geo 1.6
[ ] d3-array 1.1
[ ] d3-format 1.1

Once updated definitions are pushed to @types

New definitions merged on DT, but not yet published to npm @types org.


Implement: make_sized_bounded_sum_by_categories and make_sized_bounded_mean_by_categories

We aim to implement the following transformation:

Input: a dataframe (Vec<Sized<Vec<T>>>) with one (or more) categorical columns to be used to partition the dataset.
Output: sized bounded sums/means by categories (Vec<T>)

which computes the sum, resp. the mean, over each element of a dataset's partition. To simplify implementation and avoid the need to track sensitivity for each element of the partition, we first develop make_sized_bounded_sum_by_categories which can be then post-processed by dividing its vector's elements by the size of the partition’s elements to obtain make_sized_bounded_mean_by_categories.
The implementation relies on the contribution from issue #494 and includes the following steps:

Starting from ProductDomain from the #494 branch, determine a way to represent the size metadata associated with dataframes and adjust the domains to support this

Implement sized_group_by, which takes a dataframe from a dataframe domain with size metadata, and emits a partitioned dataset in ProductDomain<SizedDomain<DataFrameDomain<K>>>>

Reuse the combinator in #494 -parallel for mapping transformations to get to a ProductDomain<AllDomain<T>>

Add a no-op "union" transformation from a ProductDomain<AllDomain<T>> to a VectorDomain<T>

Write a wrapper for make_sized_bounded_sum_by_categoriesand a postprocessor for dividing two vectors via fn make_postprocess and obtain a make_sized_bounded_mean_by_categories.

Write wrappers for DP_sum_by_categories and DP_mean_by_categories.

Closed in #890


Load to olap external table causes be crash.

Steps to reproduce the behavior (Required)

CREATE EXTERNAL OLAP Table and the host is non-master fe' host.
load to the external table.

Expected behavior (Required)
load successfully.
Real behavior (Required)
be crashed with FATAL log:
F0328 10:26:50.170414  8962 txn_manager.cpp:158] invalid commit req  partition_id=991573 transaction_id=0 tablet_id=992498
StarRocks version (Required)

2.0.3

The reason is : calling the non-master fe's beginRemoteTxn rpc will fail, but the caller ignored the error and returns the txn id of 0.

Does the FE crash or the BE crash?
From the comment, I think it's the non-master FE who crashes.

BE crash


How can pass html data to print

I'm using the Star SM-S230i Bluetooth printer and I have a full html page for the ticket. How can I print the ticket?
Please help I'm stuck here. I don't want to print image or something so I want to print text in the proper format.
thank you in advance.

Hey @rahul-ionic - Did you ever find a solution? I'm facing the same issue. Looking towards the base64 solution, but I can't get it to work in my project.


Can't Use Trezor for Testnet Send if Imported with Xpub

Setting up a multi-sig wallet using accessible and remote (inaccessible) hardware devices. Have remote user pull xpub from a Trezor or Ledger that is not accessible to me.
Using the xpub to import public key, the default "m/0" BIP32 path routes to the address stored at the "m/45'/0'/0'/0" BIP32 path on either device.
Clearly any user would desire to test out the setup on testnet before migrating to mainnet. The Trezor input on the spend screen doesn't permit utilizing the "m/45'/0'/0'/0" BIP32 path on testnet (but does allow for Ledger). This seems problematic and am not sure if similar issues are present when attempting to utilize on mainnet.

What version of Caravan are you using? We do have an in progress feature branch that adds support for importing xpubs at custom paths and creates a wallet from them. If you're feeling adventurous you can try it out #27


chore: use ggshield 1.13.0

Codecov Report

Merging #307 (9ef159f) into main (cda8437) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #307   +/-   ##
=======================================
  Coverage   94.30%   94.30%
=======================================
  Files          75       75
  Lines        3022     3022
=======================================
  Hits         2850     2850
  Misses        172      172

Flag
Coverage Δ

unittests
94.30% <ø> (ø)

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

Continue to review full report at Codecov.

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


Multicluster App - After upgrading an app, pod count and app details are not showing

rancher/rancher:master 2/4
After upgrading a multicluster app spanning multiple clusters, the pod in the project apps shows 0, and the app details are blank.

Create 2 clusters
Deploy a multicluster app into both clusters (Docker registry 1.4.3)
When apps are active, upgrade the MCA to a different template version (Docker registry 1.6.1)
After updating, the pod count in the project-level apps shows 0, and the app details are blank as in #17627

Expected:

Pod count shows the correct number of pods, and details are present.

rancher/rancher:master 2/19
After upgrading the multicluster app, the pod count is displaying correctly, and all app details are displaying correctly.


Hritik

Added hritikpnd24.json
Thank You.

Did another improved commit after my last one had some issues.


Fix script location and URL encode share links

Description
Theme toggle JS code was in between head and body tags (invalid placement), now moved to the head.
Share links now use url_encode instead of escape since the latter doesn't encode spaces and other special characters like '&' are encoded as HTML entities instead of % values (a post title containing an '&' will be cut short).
Type of change

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

How has this been tested

[ ] I have run bash ./tools/deploy.sh --dry-run (at the root of the project) locally and passed
[x] I have tested this feature in the browser

Test Configuration

Browser type & version: Firefox 97.0.1
Operating system: Windows 10
Ruby version: 2.7.4p191
Bundler version: 2.3.8
Jekyll version: 4.2.1

Checklist

[x] I have performed a self-review of my code
[x] I have commented on my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings

Sure, updated commit messages.

Done, but editing the commit message decided not to work the second time. Ended up having to revert and commit the changes again.

I think I'll re-create the branch...

Done, but editing the commit message decided not to work the second time. Ended up having to revert and commit the changes again.

There is no need to revert because GitHub allows multiple edits to commit message :)

Yes, but it decided to stop working on my end :/


Terminal codes for DhcpOptions

Issue #, if available: 1362
Description of changes:

Mapped terminal codes for DhcpOptions resource.
Added integration tests for the terminal codes mapped.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

/ok-to-test

/retest


Fine tuning stable diffusion

Hi.
First of all. Thanks for your interesting research. I am interesting in finetuning stabe diffusion with my own medical dataset. However, I have some a question for you
CAMUS dataset has image size of 384, 384. However you finetuned stable diffusion with --resolution=512. Is there any reason for this training ?
Thank you

Hi @giovanlee. Thank you for reaching out!
We used CompVis stable diffusion 1.4 for our experiments, which was originally fine-tuned on images of size 512*512. Another reason was that our ControlNet could only be trained on images of lengths 512 and 1024 (according to the HF implementation). So, to have a fair comparison with ControlNet, we needed to keep the resolution at 512.
I hope this answers your question. Let me know if you have any other questions.
Best,
Pooria


Make the parser public

Fixes #61 by allowing custom implementations of the compile function, which would require the Node and ParserResult types.

I just noticed that there is an equal PR already open: #26.


interferes with waybar if executed from a waybar module

i have this as my waybar & when i toggle tofi with the search icon i can't click or scroll on waybar. if i click waybar tofi re executes. is there any way i can fix this?

I think this is a problem with waybar and not tofi iirc. I had a similar issue with other waybar modules. A temporary "solution" to this is to add a small delay via sleep like "on-click": "sleep 0.2 && <cmd>",.