Can not run from IDEA a Desktop project using Kotlin

I'm having hard times using libGDX with Kotlin under IntelliJ IDEA. This looks like a problem with Gradle defining 2 target directories (one for Java, one for Kotlin) and it configures IDEA so there is only one at runtime.
Versions used
The git rev-parse HEAD of libGDX shows f2ed6b4a365922964eb06538f486d9526d1803af as last commit.
IntelliJ IDEA says I am using:
IntelliJ IDEA 2018.3.3 (Community Edition)
Build #IC-183.5153.8, built on December 24, 2018
JRE: 1.8.0_152-release-1343-b26 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
macOS 10.14.3

Reproduction path
Generate a libGDX project with gdx-setup. In order to achieve this, check out latest version of libGDX. Build and run the gdx-setup project as follows:
git clone https://github.com/libgdx/libgdx.git
cd libgdx/extensions/gdx-setup
git rev-parse HEAD
ant
java -jar gdx-setup

Check "Desktop" as subproject. Open "Advanced" dialog and check "Kotlin". Run the generation.
From IntelliJ IDEA, open the directory generated by gdx-setup. Open the main class. Its default name was MyGdxGame and it is the one inheriting from ApplicationAdapter. Replace everything (except package declaration at the top) by the code below:
import com.badlogic.gdx.ApplicationAdapter
import com.badlogic.gdx.Gdx
import com.badlogic.gdx.graphics.GL20
import com.badlogic.gdx.graphics.Texture
import com.badlogic.gdx.graphics.g2d.SpriteBatch

class MyGdxGameK : ApplicationAdapter(){
  internal var batch : SpriteBatch? = null
  internal var img : Texture? = null

  override fun create() {
    batch = SpriteBatch()
    img = Texture("badlogic.jpg")
    Gdx.app.log( "Classpath", System.getProperty( "java.class.path" ) )
  }

  override fun render() {
    Gdx.gl.glClearColor(1f, 1f, 0f, 1f)
    Gdx.gl.glClear(GL20.GL_COLOR_BUFFER_BIT)
    batch!!.begin()
    batch!!.draw(img, 0f, 0f)
    batch!!.end()
  }

  override fun dispose() {
    batch!!.dispose()
    img!!.dispose()
  }
}

(Please note that background color is yellow, it differs from the class generated by libGDX, which is red.)
Modify DesktopLauncher so it instantiates the Kotlin class.
Create a Run Configuration for DesktopLauncher with android/assets as working directory. Run the DesktopLauncher.
There is a NoClassDefFoundError: the MyGdxGameK class is not in the classpath. IntelliJ logs the following the classpath in the console, among which we can see those:
<project root>/desktop/build/classes/java/main
<project root>/core/build/classes/java/main

Looking at core/build/classes directory we can see 2 directories, java and kotlin. The MyGdxGameK.class file is under the kotlin directory. So it does not appear in the classpath.
Further details
This is the build.gradle in core project:
apply plugin: "kotlin"

sourceCompatibility = 1.6
sourceSets.main.java.srcDirs = [ "src/" ]

project.ext.mainClassName = "com.mygdx.game.desktop.DesktopLauncher"
project.ext.assetsDir = new File("../android/assets");

task run(dependsOn: classes, type: JavaExec) {
    main = project.mainClassName
    classpath = sourceSets.main.runtimeClasspath
    standardInput = System.in
    workingDir = project.assetsDir
    ignoreExitValue = true
}

task debug(dependsOn: classes, type: JavaExec) {
    main = project.mainClassName
    classpath = sourceSets.main.runtimeClasspath
    standardInput = System.in
    workingDir = project.assetsDir
    ignoreExitValue = true
    debug = true
}

task dist(type: Jar) {
    from files(sourceSets.main.output.classesDir)
    from files(sourceSets.main.output.resourcesDir)
    from {configurations.compile.collect {zipTree(it)}}
    from files(project.assetsDir);

    manifest {
        attributes 'Main-Class': project.mainClassName
    }
}

dist.dependsOn classes

eclipse {
    project {
        name = appName + "-desktop"
        linkedResource name: 'assets', type: '2', location: 'PARENT-1-PROJECT_LOC/android/assets'
    }
}

task afterEclipseImport(description: "Post processing after project generation", group: "IDE") {
  doLast {
    def classpath = new XmlParser().parse(file(".classpath"))
    new Node(classpath, "classpathentry", [ kind: 'src', path: 'assets' ]);
    def writer = new FileWriter(file(".classpath"))
    def printer = new XmlNodePrinter(new PrintWriter(writer))
    printer.setPreserveWhitespace(true)
    printer.print(classpath)
  }
}

The classpath = sourceSets.main.runtimeClasspath seems to resolve as a single directory from a list of 2 directories.
As a workaround I run the application through Gradle with desktop:run target but this is confusing and adds Gradle overhead.

this may help : https://kotlinlang.org/docs/reference/using-gradle.html#targeting-the-jvm
sourceSets.main.kotlin.srcDirs...

Thanks @mgsx-dev for the quick answer. I split my sources into src/main/java and src/main/kotlin and declared both as suggested. But the sourceSets.main.runtimeClasspath did not the magic I expected. The runtime classpath remains the same (with 2 directories ending by build/classes/java/main).

In fact it does, when running desktop:run (pure Gradle) I see the 2 directories in the classpath. So this may be a problem with IDEA that does not respect Gradle's behavior.

I found a proper workaround with main.kotlin.outputDir = file('classes/java/main'), so compiler puts every Java and Kotlin class in the directory used in the classpath.
I suggest to include this workaround in projects generated by gdx-setup.
To summarize, this is the build.gradle of project core:
apply plugin: "kotlin"

sourceCompatibility = 1.6
[compileJava, compileTestJava]*.options*.encoding = 'UTF-8'

project.ext.mainClassName = "com.mygdx.game.desktop.DesktopLauncher"
project.ext.assetsDir = new File("../android/assets");

sourceSets {
    main.kotlin.srcDirs += 'src/main/kotlin'
    main.kotlin.outputDir = file('classes/java/main')
    main.java.srcDirs += 'src/main/java'
}

task run( dependsOn: classes, type: JavaExec ) {
    main = project.mainClassName
    classpath = sourceSets.main.runtimeClasspath
    standardInput = System.in
    workingDir = project.assetsDir
    ignoreExitValue = true
}

task debug(dependsOn: classes, type: JavaExec) {
    main = project.mainClassName
    classpath = sourceSets.main.runtimeClasspath
    standardInput = System.in
    workingDir = project.assetsDir
    ignoreExitValue = true
    debug = true
}

I had a similar issue (only I'm using kotlin only in the core module). After 2 days of failed attempts, I fixed it by adding this to the dependencies section in build.gradle:
compile files("build/classes/kotlin/main")

Any update on this problem guys? I'm migrating my project over to use kotlin, would love to hear what happened with this. Cheers!

Closing this, as this should no longer be an issue after the setup tool was officially changed. In the meantime check out gdx-liftoff if you're still having trouble creating a runnable project.


[WIP] Logic for key rotation

Issue https://github.com/google/exposure-notifications-server/issues/791
Proposed Changes

logic for key rotation

added a mutex for read/write
retrieves keys
creates new keys
deletes old ones

/assign @mikehelmick

/lgtm
/approve


using rowSelection.getSelectedKeys on grid to generate PDF based on selected records

hi all - apologies in advance if this a basic coding question, I have spent quite a bit of time trying to implement this extract from  https://serenity.is/docs/fluent_sql/criteria_objects :

but I seem to be at an impasse, so I humbly seek your help. I am at the tail end of my project.
My goal is to select records in the grid using GridRowSelectionMixin as per the guide, and generate a PDF based on the id's of those selected records.
Note all works perfectly when one record is selected and I pass a single integer to a "WHERE ID == ID" query.
I would like to replicate a WHERE od.id IN (TradeIDs) query.  eg WHERE od.id IN (3592, 3593)
[grid.ts] - here is the button onclick event which in this example  passes  {[  3592,  3593]} in the variable TradeIDs to the report.cs if record ids 3592 and 3593 are selected

[report.cs] based on https://github.com/volkanceylan/Serene/blob/master/Serene/Serene.Web/Modules/Northwind/Order/OrderDetailReport.cs
my quesion is how do I pass {[3592, 3593]} from this.TradeIDs to the new Criteria(od.Id).In(x)   section of the query ?
Note when hard coded as IEnumerable<int> x = new int[] { 3592, 3593 };   it works perfectly as desired

Thank you

Closed due inactivity
Also check the issue guidelines.
If you still need help, you can ask this on stackoverflow with our new tag.
https://stackoverflow.com/tags/serenity-platform


Update MoT with support for .NET 9

As the list of supported OSes for .NET 9 has been released by the PM team, we need to update the Matrix of Truth to reflect this new version of .NET

Release Note Category

[X] Feature changes/additions
[ ] Bug fixes
[ ] Internal Infrastructure Improvements

Release Note Description
Add Support to .NET 9 to MoT

Feature rolled out


Retrive info failed eos

@giovannipizzi I tested with Oleg's set and is working fine, however there is an important comment.
The point of this PR is to try to retrieve results of a failed EoS worchain, check if enough volumes were calculated correctly and  return the results in case.
However this is possible only if the CommonRelaxWorkChain implementation (used to get the energy at each volume) returns in output a relaxed_structure. In fact  CommonRelaxWorkChain has a standardized set of outputs, NOT inputs. If the relaxed_structure is not present, we do not know how to retrieve the volume in a common way: some implementation call the input structure just structure, some others aiida_structure, some others  scf.structure and so on.
At the moment, if  relaxed_structure is not present, nothing is retrieved and the calculation is listed as failed. I do not know how many implementations return a relaxed_structure when only an scf is run.
In general this is another drawback to not have the inputs of the input generator stored.

@giovannipizzi I also forgot to change the script version, I probably should do that and change all the other scripts to accept the old version and the new version. In any case the only technical difference is that in the new json the missing_outputs entry is a dictionary and not a list anymore...and I checked and the missing_outputs entry was not used by any post process script.


Get vertical writing attribute

I want a table reference API for vertical layout research.
If it's easy, I'll make a pull request.

v_advance,  v_side_bearing, ...

Are there any plans to expand the layout API?
I would like to study it myself, so I would like to ask if you have any advice on extension points.

There are some vertical glyph metrics available (see https://docs.rs/ab_glyph/0.2.2/ab_glyph/trait.ScaleFont.html#method.ascent) but the API doesn't currently expose ttf-parser glyph_ver_advance etc. I don't really know how these are used as they don't apply to the kind layouts I need/needed.
However, I don't see why ab_glyph couldn't expose the glyph_ver_* equivalent methods in the same way it does glyph_hor_*. So I'd probably accept a pr with v_advance & v_side_bearing, and these should be straightforward to implement.

Thank you!
First, consider pr.
Next, I think we need to investigate the value returned by the API.


WebKit WPE main/HEAD doesn't build using the master/HEAD of WPEBackend-FDO

... the same doesn't happen with WPEBackend-FDO 1.8.0
--- /home/bot/toolchain/sysroots/armv7at2hf-neon-poky-linux-gnueabi/usr/lib/pkgconfig/wpe-1.0.pc	2021-03-05 05:36:02.854345912 +0000
+++ /home/bot/toolchain_1.9.1/sysroots/armv7at2hf-neon-poky-linux-gnueabi/usr/lib/pkgconfig/wpe-1.0.pc	2021-03-05 00:56:37.717953845 +0000
@@ -5,7 +5,7 @@

 Name: wpe-1.0
 Description: The wpe library
-Version: 1.9.1
+Version: 1.8.0
 Requires: xkbcommon
 Cflags: -I${includedir}/wpe-1.0
 Libs: -L${libdir} -lwpe-1.0

There are changes in the includes that could be the source of this errors. Here the differences between 1.8.1 and 1.9: https://paste.debian.net/1188147/. Probably related with f461fd4d306436bcefa0bdbf1821a191d7462c38.
commit f461fd4d306436bcefa0bdbf1821a191d7462c38
Author: Adrian Perez de Castro<EMAIL_ADDRESS>Date:   Thu Nov 26 15:47:43 2020 +0200

    Simplify public headers

    Remove unneeded inclusions of libwpe headers, preferring forward
    declarations of the needed types and make all the inclusions use double
    quoted paths (to prefer local header versions, as opposed to installed
    ones).

The issue only affects the Tools/wpe/backends in WebKit so far. For example, you still can build WPE by disabling the tools (-DENABLE_TOOLS=OFF)
../../Tools/wpe/backends/HeadlessViewBackend.cpp:85:22: error: ‘wpe_view_activity_state_visible’ was not declared in this scope

Full list of errors: https://paste.debian.net/1188149/

Can confirm this. For backends code in WebKit, a simple explicit include of <wpe/wpe.h> in ViewBackend.h works.

This was because of the recent cleanups in the WPEBackend-fdo headers, which no longer end up including <wpe/wpe.h>; I think we should make <wpe/fdo.h> include it again so the expectations of existing applications stay the same. I'll make a PR later today.


Feature request: PR title variable, default PR title

This is a feature request, not very high priority, and totally up to your discretion if you want to implement it. 👍
Currently, the default PR title is "Update from branch-name" where branch-name is the name of the branch.
Feature request 1: Support for having the variable $BRANCH_NAME in the PR title:
      - name: pull-request-action
        uses<EMAIL_ADDRESS>        env:
          PULL_REQUEST_TITLE: "This is an update from $BRANCH_NAME"

In the above example, $BRANCH_NAME will be automatically replaced with the name of the branch. This way, we can customize the PR title, including the branch name in it as well.
Feature request 2: Change the default PR title from "Update from branch-name" to "Branch name"
If you open a new PR using the GitHub UI, the default PR title is a sentence-case version of the branch name. For example, a branch called "new-interface-for-admin" will have the default PR title "New interface for admin". The rules are that all hyphens are converted to spaces and the first letter is capitalized.
I'd love it if we can, consistently with the GitHub UI, have that as the default PR title. In our use case, "Branch name" gives the info a lot clearer than "Update from branch-name".

hey @AnandChowdhary ! Some quick good news is that we don't need to hard code variables into other variables because you can easily do this with GitHub actions. For example:

Feature request 1: Support for having the variable $BRANCH_NAME in the PR title:

For the above, you can just have a previous step that formats the branch name into whatever you like!
          echo "::set-env name=PULL_REQUEST_FROM_BRANCH::${BRANCH_FROM}"
    - name: Open Pull Request
      uses<EMAIL_ADDRESS>      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        PULL_REQUEST_BRANCH: "master"

In the above, the branch for the action is set in the previous action from an envar that I've created. You can also use one from GitHub's predefined set. You can also reference the outputs / steps from other actions directly, e.g., see the variables here and take a look in the examples folder for a few files.

Feature request 2: Change the default PR title from "Update from branch-name" to "Branch name"

This would be a reasonable request - but I think I'd want to ensure that there is some label to indicate it's automated / opened from a bot. What about testing "[pull-request-action] Branch name"? And how would we deal with slashes? Let's leave this issue open, and see if we can get more users +1'ing this request. If there is enough agreement about the change then I'd be happy to review a PR (with a matching example test that shows it working). Cheers!

That makes a lot of sense, thanks! I think I should close this issue, because we can probably generate the unslugified PR title using bash string utilities itself in the previous step of the workflow. Maybe the easiest thing to do is later have an example in the README for people who want to use this PR title format. 😄

Seems like set-env is being phased out, and it looks like the new way to do this is echo "{name}={value}" >> $GITHUB_ENV Setting an environment variable. In case it helps anyone else, this is what we ended up doing:
We have 3 types of PRs, hotfix-* for critical hotfixes and feature-* for new features, and all others. We used actions/github-script to generate the PR title and expose it as an environment variable that this PR action can use:
const capitalize = (name) => name.charAt(0).toUpperCase() + name.slice(1);
const emoji = context.payload.ref.startsWith("refs/heads/feature")
  ? "✨ "
  : context.payload.ref.startsWith("refs/heads/hotfix")
  ? "🚑 "
  : "";
return `${emoji}${capitalize(
  context.payload.ref
    .replace("refs/heads/", "")
    .replace(/-/g, " ")
    .replace("feature ", "")
    .replace("hotfix ", "")
)}`;

This converts a ref like refs/heads/feature-new-design to PR title "✨ New design". We then use the output of that step to set the environment variable. Similarly, we also generate the PR body text with some basic information about the PR.

See the full workflow file
name: Hotfix Branch Pull Request
on:
  push:
    branches-ignore:
      - master
      - production
jobs:
  auto-pull-request:
    name: PullRequestAction
    runs-on: ubuntu-latest
    steps:
      - name: Generate branch name
        uses: actions/github-script@v3
        id: set-branch-name
        with:
          script: |
            const capitalize = (name) => name.charAt(0).toUpperCase() + name.slice(1);
            const emoji = context.payload.ref.startsWith("refs/heads/feature")
              ? "✨ "
              : context.payload.ref.startsWith("refs/heads/hotfix")
              ? "🚑 "
              : "";
            return `${emoji}${capitalize(
              context.payload.ref
                .replace("refs/heads/", "")
                .replace(/-/g, " ")
                .replace("feature ", "")
                .replace("hotfix ", "")
            )}`;
          result-encoding: string
      - name: Set branch name
        run: echo "PULL_REQUEST_TITLE=${{steps.set-branch-name.outputs.result}}" >> $GITHUB_ENV
      - name: Generate PR body
        uses: actions/github-script@v3
        id: set-pr-body
        with:
          script: |
            return `I'm opening this pull request for this branch, pushed by @${
              context.payload.head_commit.author.username
            } with ${context.payload.commits.length} commit${
              context.payload.commits.length === 1 ? "" : "s"
            }.`;
          result-encoding: string
      - name: Set PR body
        run: echo "PULL_REQUEST_BODY=${{steps.set-pr-body.outputs.result}}" >> $GITHUB_ENV
      - name: pull-request-action
        uses<EMAIL_ADDRESS>        env:
          GITHUB_TOKEN: ${{ secrets.GH_PAT }}
          BRANCH_PREFIX: "hotfix-"
          PULL_REQUEST_BRANCH: "production"
          PULL_REQUEST_REVIEWERS: "AnandChowdhary"

Thanks for the notice! I can create a PR with the updated way to specify environment variables if you'd care to review.

https://github.com/vsoch/pull-request-action/pull/48


404 on /admin/register

▶ curl http://<IP_ADDRESS>:8084/admin/ -Lv
* Hostname was NOT found in DNS cache
*   Trying <IP_ADDRESS>...
* Connected to <IP_ADDRESS> (<IP_ADDRESS>) port 8084 (#0)
> GET /admin/ HTTP/1.1
> User-Agent: curl/7.37.1
> Host: <IP_ADDRESS>:8084
> Accept: */*
>
< HTTP/1.1 302 Found
< Location: /admin/register/
< Date: Sun, 26 Apr 2015 04:20:45 GMT
< Content-Length: 39
< Content-Type: text/html; charset=utf-8
<
* Ignoring the response-body
* Connection #0 to host <IP_ADDRESS> left intact
* Issue another request to this URL: 'http://<IP_ADDRESS>:8084/admin/register/'
* Found bundle for host <IP_ADDRESS>: 0x7ff4d0414df0
* Re-using existing connection! (#0) with host <IP_ADDRESS>
* Connected to <IP_ADDRESS> (<IP_ADDRESS>) port 8084 (#0)
> GET /admin/register/ HTTP/1.1
> User-Agent: curl/7.37.1
> Host: <IP_ADDRESS>:8084
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Content-Type: text/plain; charset=utf-8
< Date: Sun, 26 Apr 2015 04:20:45 GMT
< Content-Length: 19
<
404 page not found
* Connection #0 to host <IP_ADDRESS> left intact

note: I ran journey -custom-path=/my/custom/path after go get github.com/kabukky/journey

Hey johnjelinek,
I can't reproduce this on my end. Here are some ideas:
Did you put the promedate theme folder into /my/custom/path/content/themes/?
Did you follow the [build process](https://github.com/kabukky/journey/wiki/Building-Journey-from-source
Did you)?
Do you have any error messages in /my/custom/path/log.txt?

The theme is in place (I can view it when I go to http://localhost:8084). I followed the build process. No errors in log.txt:
▶ journey -custom-path="/Users/jjelinek/Projects/journey" -dev
2015/04/26 08:53:12 Starting Journey in developer mode...
2015/04/26 08:53:12 Starting server without HTTPS support.  It works for me on OS X 10.9.5:
▶ ./journey -custom-path="/Users/kai/journey" -dev
2015/04/26 16:12:19 Starting Journey in developer mode...
2015/04/26 16:12:19 Creating /Users/kai/journey/content/data
2015/04/26 16:12:19 Creating /Users/kai/journey/content/images
2015/04/26 16:12:19 Creating /Users/kai/journey/content/https
2015/04/26 16:12:19 Creating /Users/kai/journey/content/plugins
2015/04/26 16:12:19 Warning: couldn't load /Users/kai/journey/config.json, creating new config file.
2015/04/26 16:12:19 Starting server without HTTPS support. Please enable HTTPS in /Users/kai/journey/config.json to improve security.
2015/04/26 16:12:19 Starting http server on port :8084...

▶ curl http://<IP_ADDRESS>:8084/admin/ -Lv
* About to connect() to <IP_ADDRESS> port 8084 (#0)
*   Trying <IP_ADDRESS>...
* Adding handle: conn: 0x7fce74004400
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7fce74004400) send_pipe: 1, recv_pipe: 0
* Connected to <IP_ADDRESS> (<IP_ADDRESS>) port 8084 (#0)
> GET /admin/ HTTP/1.1
> User-Agent: curl/7.30.0
> Host: <IP_ADDRESS>:8084
> Accept: */*
>
< HTTP/1.1 302 Found
< Location: /admin/register/
< Date: Sun, 26 Apr 2015 14:12:27 GMT
< Content-Length: 39
< Content-Type: text/html; charset=utf-8
<
* Ignoring the response-body
* Connection #0 to host <IP_ADDRESS> left intact
* Issue another request to this URL: 'http://<IP_ADDRESS>:8084/admin/register/'
* Found bundle for host <IP_ADDRESS>: 0x7fce73c14d60
* Re-using existing connection! (#0) with host <IP_ADDRESS>
* Connected to <IP_ADDRESS> (<IP_ADDRESS>) port 8084 (#0)
* Adding handle: conn: 0x7fce74004400
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7fce74004400) send_pipe: 1, recv_pipe: 0
> GET /admin/register/ HTTP/1.1
> User-Agent: curl/7.30.0
> Host: <IP_ADDRESS>:8084
> Accept: */*
>
< HTTP/1.1 200 OK
< Accept-Ranges: bytes
< Content-Length: 2646
< Content-Type: text/html; charset=utf-8
< Last-Modified: Thu, 23 Apr 2015 13:01:47 GMT
< Date: Sun, 26 Apr 2015 14:12:27 GMT
<
<!DOCTYPE html>

    	<meta charset="utf-8">
    	<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no">
    	<title>Admin Area</title>

    	<link rel="stylesheet" href="/public/bootstrap/css/bootstrap.yeti.min.css">

Register

			<form class="form-horizontal" action="/admin/register/" method="POST">

			        User name

			            <input type="text" class="form-control" id="name" name="name" required>

			        E-Mail address

			            <input type="email" class="form-control" id="email" name="email" required>

			        Password

			            <input type="password" class="form-control" id="password" name="password" required>

			        Repeat Password

			            <input type="password" class="form-control" id="repeated-password" name="repeated-password" required>

			        <button type="submit" class="btn btn-primary pull-right" id="button-submit">Register</button>

			</form>

* Connection #0 to host <IP_ADDRESS> left intact

On the off chance: maybe you have old versions of dependencies in your GOPATH (e.g. github.com/dimfeld/httptreemux)? Try go get -u to update them.

didn't work. I'm also getting sql: no rows in result set from http://localhost:8084/about/

Hmm. Could you try it with the newest release instead of building from source, just to see if that works?
Regarding sql: no rows in result set: You have to create those pages in the admin interface: https://github.com/kabukky/journey/wiki/FAQ#4-clicking-on-the-about-or-projects-links-shows-me-sql-no-rows-in-result-set-or-a-404-page

it works with the release binary, with no other changes to my custom-path.

I'm still out of ideas on how to tackle this issue but I'll keep it in my head.
If anyone else has the problem, please reply here.

I've got the same problem when trying to deploy to Heroku.
http://stormy-castle-1362.herokuapp.com/admin/ -> http://stormy-castle-1362.herokuapp.com/admin/register/ -> 404
But then again I get 404 on all assets as well, so this might not be related at all, and since I'm new to both GO and Heroku I'm probably doing something wrong.
Starting journey with this in my Procfile
web: journey -custom-path=$HOME -http-port=$PORT -log=/tmp/log.txt

Same problem here.
Steps to reproduce:
Assuming admin and content which includes default theme is copied into /home/user/my_blog/.
Doesn't work
go get github.com/kabukky/journey
cd /home/user/my_blog/
/home/user/.go/bin/journey -custom-path="./" -dev

and it shows template compiling error like following:
2015/06/26 17:42:43 Starting Journey in developer mode...
2015/06/26 17:42:43 Warning: Couldn't compile pagination template.
2015/06/26 17:42:43 Warning: Couldn't compile navigation template.
2015/06/26 17:42:43 Starting server without HTTPS support. Please enable HTTPS in /home/user/my_blog/config.json to improve security.

Works
go get github.com/kabukky/journey
cd /home/user/my_blog/
cp /home/user/.go/bin/journey ./
./journey -custom-path="./" -dev

--
I think some path resolving code has a problem.

From what I can tell there are two problems here.
The first problem is that the dot operators (.) are not recognized in the file path and neither is the tilde (~). I have a fix for this, but before submitting the PR I wanted to note and get input on the second issue.
The second issue is that the built-in directory needs to live next to the executable file currently for the application to run.
So if running the application from $GOPATH/src/github.com/kabukky/journey/journey the application will function as expected because the built-in directory is in the src.  If run from $GOPATH/bin/journey then the application will not function and will cause 404 for admin pages.
There are two paths to take here I believe.  Either compile the built-ins into the binary or copy the binaries to the ExecutablePath in a directory such as journey.d.  I believe compiling them into the binary is the most "go like" solution and will make user install the easiest. @kabukky, what are your thoughts and preference?


Dependency free util for combining lists

Reviewer checklist

[x] New Modules have module-info.java files.
[x] Public types are well-designed:

[x] no public constructors.
[x] prefer interface or impl.

[x] Ensure relevant issues are linked (description should include text like "Fixes #")
[x] Ensure any appropriate documentation has been added or amended

Coverage increased (+0.02%) to 99.291% when pulling aa7031aec5a9941b35ed901936b95d631eee4ef0 on lists into b5f41601cea65d9f6e98682da5212a4bb3263c24 on main.


Scale coords update

Description
Adds new functionality to scale_coords, extending the range of formats allowed for velocity and testing the output messages upon failure to ensure the correct failure is triggered.
Type of change
Please delete options that are not relevant.

New feature (non-breaking change which adds functionality)

How Has This Been Tested?

Run with new velocity input options:

from pysat.utils import coords
out1 = coords.scale_units('m s$^{-1}$', 'm/s')
out2 = coords.scale_units('m/s', 'm s$^{-1}$')
out3 = coords.scale_units('m/s', 'km s$^{-1}$')
out4 = coords.scale_units('cm  s$^{-1}$', 'km\s')
print(out1, out2, out3, out4)
1.0, 1.0, 1000.0, 100000.0

Trigger new warning message that tells you both input and output are unknown

coords.scale_units('climb', 'rocks')

Returns:  ValueError: Cannot scale rocks and climb, unknown units
Test Configuration:

OS X Sierra

Checklist:

[x] Make sure you are merging into the develop (not master) branch
[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules
[x] Add a note to CHANGELOG.md, summarizing the changes

Coverage decreased (-0.03%) to 80.727% when pulling 2b71f62f5b3526e2470613a4decd58bef3b12f2b on scale_coords_update into bc4315b3683397828251744f1ad4db9bbfc6b8de on develop.

Oops.  Meant to add the model_utils tests to #257.

@jklenzing it looks like the routine I am changing is completely covered, and test_utils_coords.py is now at 100%, so I think the issue you raised is resolved.  Requesting approval to merge and move on with our lives.


⚠ Bofrost.at has degraded performance

In efa0639, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1195 ms

Resolved: Bofrost.at performance has improved in 4924740 after 304 days, 11 hours, 17 minutes.


Please add solit theme

Hi
I made AMP supported theme for hugo.
https://github.com/dim0627/hugo_theme_solit
I wish to be added to the hugoThemes repository.
Regards,
Daisuke Tsuji

Hello again,
thanks for sharing the theme. As last step: could you rename the readme.md to README.md. The build script expects a README with an uppercase filename. But this is probably something that should be changed.

Thank you, It's changed.
https://github.com/dim0627/hugo_theme_solit/commit/8b68ef1dd6cc93023ce7ca79682b43a9d25779b0

Great. I've added your theme in dc52acaedc7114d6a34832dd8327462599f22ba8. It should be listed soon on the theme site.


Support for MetaMorph metadata?

Currently, the parser support MD Image Xpress images with MetaSeries metadata. What it doesn't currently support is MetaMorph metadata.
See e.g. Drogon implementation for the 2 different metadata formats:
https://github.com/fmi-basel/job-system-workflows/blob/master/src/gliberal_workflows/tasks/metamorph_image_collection_task/versions/version_0_5.py

cc @mariusmaehlen


Show detailed error message if compile fails on server

Coverage decreased (-0.1%) to 44.403% when pulling 28dc677f9e060e4e73ddd76edb7bcc7067c6a4e7 on submit-compile-failed-error-juha into 40944ca83672f2037d2f06b6f51c3f8202e1cb68 on master.

Coverage increased (+0.2%) to 44.683% when pulling 2faaffe3615aaafde43c14020695a919dc2dd5bd on submit-compile-failed-error-juha into 40944ca83672f2037d2f06b6f51c3f8202e1cb68 on master.

LGTM.

Coverage decreased (-0.1%) to 44.725% when pulling 53e449ee606ca9281d0c68d4ee159d18cd9dd291 on submit-compile-failed-error-juha into 65a3e136e0882907f7bae7cb01d5085a9d0d3cd4 on master.


How do I only get test log output from scalatest failures?

At first I thought Bazel's --test_output=errors would do that, but it seems to be equivalent to printing the full test log if any test fails, which is overwhelming in some larger suites.
So I remembered back in sbt days, I could pass in flags to Scalatest and ask it to suppress test output except on failed tests. This SO post shows a way to do that, but now I'm struggling to convince rules_scala to pass -oI or similar flags into the Scalatest runner. Is there a good way to do this?
Is there an easier way to only get output from failed tests and otherwise hide it?

Never mind, it turns out I was wrong and Scalatest doesn't really support this either ☹


Change translatable fields language on production

Execute the script provided in #5691 for translatable fields on thor, then on production.
This ticket is to monitor and log execution progress.
Fixes #5714.

CC @sheyd @mikefantini

Thor results:
dosomething@ip-172-20-100-30:/var/www/www.dosomething.org/releases/20151105190717/html$ drush ds-update-field-language field_additional_text_title
Updating field_additional_text_title from "und" to "en".                                                                                [status]
29 fields updated.                                                                                [ok]
2 fields left.                                                                                [status]

@mikefantini Thor is fixed. You can see above that I executed the script for ALL translatable fields (just in case), so we need to thoroughly test everything, including campaigns.

@sergii-tkachenko sure thing! Can you please point out some of the things I should be looking for in testing and what I should be testing specifically?

@mikefantini Besides normal tests, please check fields if expected fields exist unpublished nodes and check that fields didn't disappear on most critical campaigns.

Prod results log:
dosomething@ip-10-100-35-14:/var/www/www.dosomething.org/current/html$ drush ds-update-field-language field_call_to_action; drush ds-update-field-language field_image_campaign_cover; drush ds-update-field-language field_campaigns; drush ds-update-field-language field_intro_title; drush ds-update-field-language field_intro; drush ds-update-field-language field_intro_image; drush ds-update-field-language field_faq; drush ds-update-field-language field_additional_text_title; drush ds-update-field-language field_additional_text; drush ds-update-field-language field_subtitle; drush ds-update-field-language field_facts; drush ds-update-field-language field_cta_link; drush ds-update-field-language field_value_proposition; drush ds-update-field-language field_secondary_call_to_action; drush ds-update-field-language field_fact_problem; drush ds-update-field-language field_fact_solution; drush ds-update-field-language field_solution_copy; drush ds-update-field-language field_solution_support; drush ds-update-field-language field_image_psa_replacement; drush ds-update-field-language field_starter_statement; drush ds-update-field-language field_items_needed; drush ds-update-field-language field_time_and_place; drush ds-update-field-language field_vips; drush ds-update-field-language field_promoting_tips; drush ds-update-field-language field_pre_step_header; drush ds-update-field-language field_pre_step_copy; drush ds-update-field-language field_step_pre; drush ds-update-field-language field_photo_step; drush ds-update-field-language field_post_step_header; drush ds-update-field-language field_post_step_copy; drush ds-update-field-language field_step_post; drush ds-update-field-language field_image_step_gallery; drush ds-update-field-language field_reportback_noun; drush ds-update-field-language field_reportback_verb; drush ds-update-field-language field_reportback_copy; drush ds-update-field-language field_reportback_confirm_msg; drush ds-update-field-language field_issue;
Updating field_call_to_action from "und" to "en".                                                                           [status]
84 fields updated.                                                                                [ok]
2 fields left.                                                                                [status]
Updating field_image_campaign_cover from "und" to "en".                                                                     [status]
37 fields updated.                                                                                [ok]
1 fields left.                                                                                [status]
Updating field_campaigns from "und" to "en".                                                                                [status]
108 fields updated.                                                                                [ok]
11 fields left.                                                                                [status]
Updating field_intro_title from "und" to "en".                                                                              [status]
12 fields updated.                                                                                [ok]
Updating field_intro from "und" to "en".                                                                                [status]
99 fields updated.                                                                                [ok]
1 fields left.                                                                                [status]
Updating field_intro_image from "und" to "en".                                                                              [status]
5 fields updated.                                                                                [ok]
Updating field_faq from "und" to "en".                                                                                [status]
Nothing to update.                                                                                [ok]
Updating field_additional_text_title from "und" to "en".                                                                    [status]
29 fields updated.                                                                                [ok]
2 fields left.                                                                                [status]
Updating field_additional_text from "und" to "en".                                                                          [status]
31 fields updated.                                                                                [ok]
2 fields left.                                                                                [status]
Updating field_subtitle from "und" to "en".                                                                                [status]
8 fields updated.                                                                                [ok]
Updating field_facts from "und" to "en".                                                                                [status]
46 fields updated.                                                                                [ok]
Updating field_cta_link from "und" to "en".                                                                                [status]
1 fields updated.                                                                                [ok]
Updating field_value_proposition from "und" to "en".                                                                        [status]
8 fields updated.                                                                                [ok]
1 fields left.                                                                                [status]
Updating field_secondary_call_to_action from "und" to "en".                                                                 [status]
8 fields updated.                                                                                [ok]
1 fields left.                                                                                [status]
Updating field_fact_problem from "und" to "en".                                                                             [status]
47 fields updated.                                                                                [ok]
2 fields left.                                                                                [status]
Updating field_fact_solution from "und" to "en".                                                                            [status]
25 fields updated.                                                                                [ok]
1 fields left.                                                                                [status]
Updating field_solution_copy from "und" to "en".                                                                            [status]
28 fields updated.                                                                                [ok]
1 fields left.                                                                                [status]
Updating field_solution_support from "und" to "en".                                                                         [status]
45 fields updated.                                                                                [ok]
1 fields left.                                                                                [status]
Updating field_image_psa_replacement from "und" to "en".                                                                    [status]
Nothing to update.                                                                                [ok]
Updating field_starter_statement from "und" to "en".                                                                        [status]
69 fields updated.                                                                                [ok]
2 fields left.                                                                                [status]
Updating field_items_needed from "und" to "en".                                                                             [status]
40 fields updated.                                                                                [ok]
1 fields left.                                                                                [status]
Updating field_time_and_place from "und" to "en".                                                                           [status]
31 fields updated.                                                                                [ok]
Updating field_vips from "und" to "en".                                                                                [status]
27 fields updated.                                                                                [ok]
Updating field_promoting_tips from "und" to "en".                                                                           [status]
23 fields updated.                                                                                [ok]
1 fields left.                                                                                [status]
Updating field_pre_step_header from "und" to "en".                                                                          [status]
41 fields updated.                                                                                [ok]
1 fields left.                                                                                [status]
Updating field_pre_step_copy from "und" to "en".                                                                            [status]
39 fields updated.                                                                                [ok]
1 fields left.                                                                                [status]
Updating field_step_pre from "und" to "en".                                                                                [status]
Nothing to update.                                                                                [ok]
Updating field_photo_step from "und" to "en".                                                                               [status]
36 fields updated.                                                                                [ok]
1 fields left.                                                                                [status]
Updating field_post_step_header from "und" to "en".                                                                         [status]
37 fields updated.                                                                                [ok]
1 fields left.                                                                                [status]
Updating field_post_step_copy from "und" to "en".                                                                           [status]
38 fields updated.                                                                                [ok]
1 fields left.                                                                                [status]
Updating field_step_post from "und" to "en".                                                                                [status]
Nothing to update.                                                                                [ok]
Updating field_image_step_gallery from "und" to "en".                                                                       [status]
20 fields updated.                                                                                [ok]
1 fields left.                                                                                [status]
Updating field_reportback_noun from "und" to "en".                                                                          [status]
41 fields updated.                                                                                [ok]
1 fields left.                                                                                [status]
Updating field_reportback_verb from "und" to "en".                                                                          [status]
41 fields updated.                                                                                [ok]
1 fields left.                                                                                [status]
Updating field_reportback_copy from "und" to "en".                                                                          [status]
35 fields updated.                                                                                [ok]
1 fields left.                                                                                [status]
Updating field_reportback_confirm_msg from "und" to "en".                                                                   [status]
38 fields updated.                                                                                [ok]
1 fields left.                                                                                [status]
Updating field_issue from "und" to "en".                                                                                [status]
31 fields updated.                                                                                [ok]
1 fields left.                                                                                [status]


Add growable flag to s2n_blob.

Description of changes:
Currently, struct s2n_blob doesn't track whether it was statically or dynamically allocated.  This means that realloc() and free() can be called on statically allocated blobs, with no warning.

Add a growable flag
error if realloc() or free() are called on static blobs where growable is not set
Add a function to extract the blob used in s2n_blob_set_protocol_preferences.

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

Codecov Report

:exclamation: No coverage uploaded for pull request head (growable_blob@e198f55). Click here to learn what that means.
The diff coverage is n/a.

Nice addition, could you add unit tests for s2n_blob_is_growable?

Willdo!

Nice addition, could you add unit tests for s2n_blob_is_growable?

Willdo!

@ttjsu-aws Unit test added.

The SAW failure seems to be related to the use of bitfields. Discussing with @jldodds to fix.

@xonatius @ttjsu-aws @baldwinmatt SAW proofs now work.  Ready for final review


dollar-double-quoted-argument enhancements

"$foo ${bar}" doesn't highlight ${bar}, but should.
: "$foo<CURSOR> highlights just the $fo but should highlight the entire $foo.
In "foo$", the $ should not be considered a parameter substitution.

Fixed the second and third case in c43dc8bd4420b15e676a10c5186aeea31c1f22a3. Leaving this issue open for the "${foo}" case (parameter expansion with braces, inside double quotes).

Finished in 6e3720f.


Remove AAGUID check from NoneAttestation

Remove AAGUID check from NoneAttestation because it is not required by WebAuthn specification and FIDO conformance tool.
Also, this check blocks Apple's passkey and Google Password Manager's passkey.
See https://github.com/quarkusio/quarkus/issues/38043

The reason is that authenticator implementors stopped sending zeroed AAGUIDs, so this prevents people from using webauthn.

Rebased to pull https://github.com/eclipse-vertx/vertx-auth/pull/672 changes

@vietj or @tsegismont can we get this moving please?

sure I'll review these PR

can you backport this to 4.x @ynojima ?

I'm not familiar with vertx development. To which branch or repository should I send a backport pull-request regarding 4.x?

Thanks @vietj

@vietj which version of Vert.x did this make it to? @StephenOTT says they still have the issue on latest Quarkus with Vert.x 4.5.7


[ROUGH DRAFT] Add Error Reporting GAPIC as dependency

Step 1 to resolving #2687. See that discussion thread for the other followups.
@bjwatson @dhermes

@waprin I forgot, can you assign people and add labels to PRs?

I can't. Though my teammates could change that for me, up to you guys if you want us to.

@waprin I gave you one-off write access to this repo. We can refactor this as a Github team if there are other Stackdriver devs we should include (especially if you need access to multiple google-cloud-* repos).
FYI @jgeewax @daspecster @dhermes @tseaver @omaray @danoscarmike

LGTM, but I'll let @tseaver or @dhermes sign off.

This PR is pointless unless the package actually uses the depended upon package?

@dhermes the next incoming PR will actually use this client, but it's still not pointless, the idea is that we keep the pip install experience consistent whether it's handwritten or a GAPIC. You install google-cloud-* to get the clients, regardless of if the are hand-written, GAPICs, or a mix. So there will be a bunch of APIs that just have a GAPIC we just install the dependency here for. Or in cases like this, a GAPIC and then maybe some hand-written code on top. At least that's how it's been explained to me.

Yes, that's how it's been explained to me as well, but AFAIK the generated libraries are not in the "ready to go" state yet (e.g. no docs).

@dhermes We'll get on top of publishing GAPIC docs for all APIs in January. We also need to discuss how to integrate them with google-cloud-python docs as discussed in https://github.com/GoogleCloudPlatform/gcloud-common/issues/207.

@dhermes @bjwatson @steren this is not remotely ready for thorough review (missing tests, docs, lots of stye issues) but I wanted to throw up the commits to give the rough sketch of adding the GAPIC as a transport for the helper API, make sure it's all LGTM to you guys and then I'll clean up the PR to merge it.
This is basically what Steren and I had discussed a few weeks ago.

Copies the basic GAX/non-GAX structure of the logging client
Unlike the logging client, instead of falling back to an HTTP client, it falls back to the logging client itself, now in _logging
Basic instrumentation/helper library API remains the same, code to build the error report payload is shared

If you all feel good about this I'll finish up the tests/docs/style issues.
Obviously not expecting any response on this until 2017, happy new year! 🎉 🎉 🎈 🎈

@dhermes @bjwatson @steren ping for the new year. again, just looking for an initial +1 to basic direction here before I finish tests/docs.

Thanks @waprin. Looks reasonable to me based on a superficial review.
@lukesneeringer Can you take a more detailed look? This should have a similar structure to the Logging code that you've looked at already.

Cool ty, will finish it up then.

The direction LGTM.
Will this also allow me to call the

@bjwatson  @lukesneeringer cool ty, I wanted to ask, do we need the secure channel stuff? Is there a high level overview of that?
One other problem I've run into is that Error Reporting depends on gax 0.14 but logging (which Error Reporting uses as the fallback) depends on 0.15, and ssl_creds changed to ssl_credentials. Wonder if we can just update the error reporting gax dependency?
@steren will try to clarify the gRPC stuff.
Since we are adding the GAPIC to the module, all the autogenned VTK calls will be included as a dependency. Documentation of all those calls is still a TODO as noted above. For now this just adds the GAPIC library to this one and uses it for the handwritten helper functions.

@waprin I believe we'll need to regenerate the GAPIC code to work with GAX 0.15. Is that correct @geigerj?
The changes allow us to use @jonparrott's new google-auth library, rather than requiring the broken old oauth2client.

@bjwatson Yes, we should regenerate the GAPIC library to use GAX 0.15.0.

@dhermes this is ready for review


Add serverless backend

Adds Twilio Serverless (Typescript) as a backend option similar to and based on the Express version.
The resulting react app is also placed in the serverless/assets directory so that the entire project may be hosted on a Twilio Serverless function.
Cosmetic tweak to the react app to show Twilio logo (or customer logo) by replacing the public/logo.png file
Note the Express server has been adjusted to use /api/ routes prefix for initWebchat and refreshToken to match the serverless implementation, the serverless implementation could also be changed to drop the api route if needed.

@chaosloth this is a fantastic approach. Any chance this will be merged?


Text: target="_blank" gets stripped from injected HTML values

Current Behavior

The rendered <a /> has the target="_blank" removed.
Adding other attributes is fine, it's just the target that seems to get stripped.

Expected Behavior

If the HTML has attributes, such as target defined, these should not be stripped.

Steps To Reproduce
Copy the example from our docs, inject it into a UI Text under msg.payload
Environment

Dashboard version: 1.19.1
Node-RED version: 4.x

Have you provided an initial effort estimate for this issue?
I have provided an initial effort estimate

I have similar code in my project and just tested it: Issue also reproduced here.


Hello, After I switch my pixi.js to a higher version, it cannot support transparency.

// I'm try
this.app = new PIXI.Application(i,r,{transparent:!0});
......

this.app.renderer.backgroundColor=0xFFFFFFFF

//but background is white

//if you know...thanks....

current pixi.js version: e.g. latest
old pixi.js version: e.g. 4.6.1

What do you mean by "latest" can you provide a running example?

Maybe you don't need to set this.app.renderer.backgroundColor=0xFFFFFFFF.
DEMO: https://pixiplayground.com/#/edit/p0tuWN4El6K793O7lMRSq

Maybe you don't need to set this.app.renderer.backgroundColor=0xFFFFFFFF.
DEMO: https://pixiplayground.com/#/edit/p0tuWN4El6K793O7lMRSq

Sorry，My English is bad! I use pixi.js 4.6.1,My config "{transparent:!0}"
but I use latest pixi.js "transparent" prop seems to have been removed.
So I try add "this.app.renderer.backgroundColor=0xFFFFFFFF", but background is white...
if ..you know...Thanks~~~

What do you mean by "latest" can you provide a running example?

Sorry, the code cannot be exposed for the time being, Because it sucks!

It seems to have something to do with constructors
//old code
 new PIXI.Application(width,height,{transparent:!0});

//new code
 new PIXI.Application({width:300,height:300,transparent:!0});

//It's OK! Thanks!!!!


Better back btn support

We seem to have a problem with window.history.replaceState, it writes entries in the history which seem to block the back button from working correctly.
The code is in section-store and is only really needed to update the query param with a list of open sections. In turn this is only needed so the url can be sent to others and the appropriate sections will open.
After some experimentation it seems as if we can remove that feature and instead us a more straightforward sharing mechanism, where a shareable url is copied to the clip board.
#6657


feat(operation-id-case-convention): add new operation-id-case-convention rule

PR summary
This commit introduces the new spectral-style operation-id-case-convention
rule, which replaces the legacy operation_id_case_convention rule.
PR Checklist
General checklist
Please make sure that your PR fulfills the following requirements:

[x] The commit message follows the Angular Commit Message Guidelines.
[x] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been added / updated (for bug fixes / features)
[ ] Dependencies have been updated as needed
[ ] .secrets.baseline updated as needed?

Checklist for adding a new validation rule:

[x] Added new validation rule definition (packages/ruleset/src/rules/*.js, index.js)
[x] If necessary, added new validation rule implementation (packages/ruleset/src/functions/*.js, updated index.js)
[x] Added new rule to default configuration (packages/ruleset/src/ibm-oas.js)
[x] Added tests for new rule (packages/ruleset/test/*.test.js)
[x] Added docs for new rule (docs/ibm-cloud-rules.md)

Checklist for removing an old validation rule:

[x] Removed old rule implementation (packages/validator/src/plugins/validation/*.js)
[x] Removed or adjusted testcases (packages/validator/test)
[x] Updated default configuration to deprecate old rule (packages/validator/src/.defaultsForValidator.js)
[x] Removed docs of old rule (docs/ibm-legacy-rules.md)

:tada: This PR is included in version 0.13.0 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 0.64.0 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:


Fix Pipeline Demo input_location and output_location paths

In demos.py under pipeline_demo() function on lines 86 and 87, src/demos.py::pipeline_demo:86, :87,the assigned paths to variables input_location and output_location are not correct, causes Exceptions during the run of demos.
These:

86:input_location = "src/data/sumup_leads_email.csv"
87:output_location = "src/data/leads_enriched.csv"

should be replaced with:

86:input_location = "data/sumup_leads_email.csv"
87:output_location = "data/leads_enriched.csv"

Fixed within the PR of branch feature/social-media-api


Fixed #5402 -- recursion error when referencing same Alias plugin

Fixed #5402
This prevents the recursion error by failing silently (not rendering the alias), thus allowing the user to remove the recursive plugin.
A better fix will be to detect this when pasting the plugin but this will come in the future when we add validation hooks for certain actions (pasting, moving, etc.)

Coverage increased (+0.8%) to 89.526% when pulling a83f5c281151d581da82500e8cd1e091468294bd on czpython:feature/alias-plugin-fixes into 1ac3e9212e275b6a350649af1d3c8ec6845dea98 on divio:release/3.3.x.

LGTM


FZF_DEFAULT_COMMAND ignored in fzf-tmux?

Category

[ ] fzf binary
[x] fzf-tmux script
[ ] Key bindings
[ ] Completion
[ ] Vim
[ ] Neovim
[ ] Etc.

OS

[ ] Linux
[x] Mac OS X
[ ] Windows
[ ] Etc.

Shell

[ ] bash
[x] zsh
[ ] fish

Steps to repro:

Have a folder test with a .gitignore claiming to ignore folders build and .tox
Have FZF_DEFAULT_COMMAND be ag -g "" so that .gitignore is considered
ag -g "" works: n folder test, ag -g "" | fzf ignores build and .tox. Same if called from another folder.
Problems:

Press Ctrl+T -> tmux split contains build but not .tox
Do vim **<TAB><TAB> -> tmux split contains build and .tox

Confusion
Thank you for such an amazing tool!

For various reasons, CTRL-T and fuzzy completion require separate configuration.

Set up $FZF_CTRL_T_COMMAND for CTRL-T
See https://github.com/junegunn/fzf#settings for customizing fuzzy completion

That works perfectly, and I should have spotted that in the README, my bad. Thanks for the reply!


usefulness of PUSHINT/POPINT

From David Horner, Oct 19 2020,  message #192
Note: cc'ing tech-code-size TG list. Please drop them off as appropriate.
The tech-code-size TG is proposing instructions that store and load  relative to sp (R2) not only  GPR but also mret, mcause and mepc.
https://github.com/riscv/riscv-code-size-reduction/blob/master/ISA proposals/Huawei/riscv_push_pop_extension_RV32_RV64.adoc#pushint-epopint-e
I expect many of the obvious warts can be readily fixed, such as :
I believe mtval and/or mstatus [for legacy interrupt] csr was intended rather than the mret instruction.
The m-, s-, u- (etc. ) designation for xtval/xstatus, xcause, xepc will be determined by the x-mode it is executed under.
Ditto for inclusion of mtval and mstatus dependent upon trap/interrupt type/state.
However, some fundimental characteristics my be more difficult to address.
The breadth of flexibility in the fast-interrupt design is challenged by advocating prepackaged instructions that might become defacto standards, affecting
     a) minimalist micro-arch designs that would have to incorporate the underlying state machine by

                     i)  performing the micro-ops via a sequencer or

                     ii) a monolithic multi-cycle instruction implementation.

           neither is consistent with our goal of targeting embedded/IOT.

     b) software ecosystem will be  dis-incentivized to improve/optimize the simpler sequences.

Our objectives difffer from the code-size TG.
Although code size reduction can be achieved using these instructions, there is no general usefulness for them.
They are practically valuable only in trap handlers.
Granted, reducing the code may help cache locality,
and for a vectoring interrupt design that has discrete entry points per vector there would be a proportional [and possibly] significant code size reduction.
However, dependence upon these macro-instructions woulod mitigate against the consolidation of these vectors which would provide a net improvement.
Similarly, removing the instruction completely may be a better option: to include the macro-functionality into the vectored interrupt itself.
Although the functionality currently proposed can certainly be incorporated into some handlers with a net performance boost, they are not tailored to handler requirements.
Notably, (and I expect obvious to our group) is that the xvtal/xstatus, xcause and xepc handling.
       The resultant value of a read of the csrs is minimized over the simpler approach as
             1) they are only pushed to the stack.
                       Either the value from the stack will need to be subsequently read or the csrr reexecuted.
                       In either case we can expect for many implementations slower handling of a pending same mode interrupt.
                            either as progress to either exit critical code or stall in reading stack, potentially from write queue.
             2) no provision for concurrent csr setting is present in the current formulation.

#1 above can be mostly addressed by a PUSHPOPulateINT that store xtval/xstatus, xcause and xepc in pushed GPR registers.
However, for handlers that don't immediately use those values, the wait to load into the GPR is counter our objectives.
A potential benefit within the interrupt realm is that just, just as other long running processes (notably divide) can process over an intgerrupt, so can these macro-ops, especially if they were sufficiently comprehensive to also enable interrupts.
Finally, a suggestion that examining these possibilties can give us insight into avenues of improvement and also provide a test bed for investigations.

From:  Tariq Kurd, Oct 21 2020,  #193
Hi David,
Thanks for this analysis.
I added PUSHINT/POPINT to my proposal specifically for the interrupt handler, so any requests to change to the specification from the interrupt group would be gratefully received.
The specifications fit nicely with PUSH/POP which is why I’ve specified them as part of the code size reduction work, they certainly will have minimal benefit for code size reduction (so no reason to have 16-bit encodings for them).
However – they lend themselves nicely to clever micro-architectural mechanisms to rapidly context save/restore on handler entry/exit so really they’re probably more relevant for code-speed than code-size, so I’ve CC’d Jeremy.
Tariq

From: Allen Baum, Oct 21 2020,   #194
I see that there is a bias against microsequenced implementations for microcontrollers, as if they  substantially increase... something.
I see quite the opposite. IF you don't allow them, you're effectively forcing a multiply to be single cycle.
There will be microsequences.
Having them can simplify, speed up, and lower the memory footprint of interrupt handling, and reduce silicon area.
Reducing that memory footprint can also have a second order effect of lowering icache pressure, thus saving power and increasing performance.
Fast and easy interrupt handling may be one of the core characteristics of a microcontroller.

From: David Horner, Oct 21 2020,  #195
On 2020-10-21 7:08 p.m., Allen Baum wrote:
I see that there is a bias against microsequenced implementations for microcontrollers, as if they  substantially increase... something.
I see quite the opposite. IF you don't allow them, you're effectively forcing a multiply to be single cycle.

Rather than a bias, it is a recognition that adoption of these instructions as central to the fast-interrupt design limits implementation options.
They are heavy-weight instructions.
Some target implementations won't have multiply let alone divide.
And yet I muse that these instructions could operate similarly to many divide implementations, and continue to operate concurrently with a preempting trap.
There will be microsequences.

I considered this a design choice.
Having them

are you speaking of the PUSH/POPINT instructions?
can simplify, speed up, and lower the memory footprint of interrupt handling, and reduce silicon area.
Reducing that memory footprint can also have a second order effect of lowering icache pressure, thus saving power and increasing performance.
Fast and easy interrupt handling may be one of the core characteristics of a microcontroller.

I note that all you have said can apply to PUSH/POPINT instructions, each may be beneficial in those ways  to some implementations.
The potential good is inarguable. I am especially concerned about and want to be on guard for the potential bad.

From: Allen Baum, Oct 21 2020,  #196
We may be arguing different things.
If we are finding instructions that use micro sequencing unacceptable, we are limiting implementation choices.
If we are saying that a specific op would require micro sequence - we are limiting architectural choices.
In this case, we are talking about a code size extension targeting ( but not limited to) a micro controller profile. It could easily take advantage of this instruction, but could survive without it as well.
It’s an extension- you can implement or not.
The real question is whether a micro controller profile requires it, makes it optional, or will not support it at all while requiring the rest of a code size reduction profile.
If a micro controller doesn’t think it’s getting bang for the buck- don’t implement it. But a micro sequencer implementation is far cheaper than many other optional features for that class of machine. It would be interesting to compare that to the area of RAM or ROM it would replace.
-Allen

From:  David Horner, Oct 21 2020,  #197
On 2020-10-22 1:09 a.m., Allen Baum wrote:
We may be arguing different things.
If we are finding instructions that use micro sequencing unacceptable, we are limiting implementation choices.

Not that they are unacceptable per se. But MAY be unacceptable to build into the fast-interrupt recommendations.
If we are saying that a specific op would require micro sequence - we are limiting architectural choices.

And we are not saying that. Anyone can implement however they want, a novel implementation may work better in this limited context that micro sequencing.
Advances in "dark silicon" may make a combinatoric logic implementation optimal. No clocking of a full sequencer, just go the flow.
In this case, we are talking about a code size extension targeting ( but not limited to) a micro controller profile. It could easily take advantage of this instruction, but could survive without it as well.
It’s an extension- you can implement or not.

The real question is whether a micro controller profile requires it, makes it optional, or will not support it at all while requiring the rest of a code size reduction profile.

exactly. I didn't actually think we were arguing. We are discovering the nuances. As I said "insight into avenues of improvement".
If a micro controller doesn’t think it’s getting bang for the buck- don’t implement it. But a micro sequencer implementation is far cheaper than many other optional features for that class of machine. It would be interesting to compare that to the area of RAM or ROM it would replace.

You left out power consumption from the trade-offs, critical for such chips.
I mention other tradeoffs. Including, the possibility of eliminating the instruction completely by incorporating into the interrupt housekeeping [like the populating of the mcause fields]
I greatly appreciate your interaction.

From:   Tariq Kurd, Oct 22 2020,  #198
If an implementation supports PUSH/POP then supporting PUSHINT/POPINT should add little more complexity.
I think the question is how we structure the extension – I wouldn’t personally require PUSHINT/POPINT to be implemented in the fast interrupt spec, for the same reason that I intend to have an option to exclude all multi-step instructions from the future code-size reduction ISA extension (e.g. PUSH/POP) – not everyone will want to implement multi-step sequences.
Adding more and more extensions is certainly bad for delivering libraries as they add more options, but I expect PUSHINT/POPINT to be in __asm inserts only, or even directly written in assembler, so there should be no effect there.
What I propose is an extension something like Zclicpushpopint (not sure the Zclic bit is right…..), and to give the spec to the fast interrupt team to complete.
Does that sounds like a sensible approach?
Tariq

From:   David Horner, Oct 22 2020,  #199
Tariq Kurd:
and to give the spec to the fast interrupt team to complete.

Well we have already done that. In part through this email chain.
On 2020-10-22 6:11 a.m., Tariq Kurd wrote:
If an implementation supports PUSH/POP then supporting PUSHINT/POPINT should add little more complexity.

not so. csr may be significantly differently accessible than GPR.
I agree that for many implementations it could be very little add.
I think the question is how we structure the extension – I wouldn’t personally require PUSHINT/POPINT to be implemented in the fast interrupt spec, for the same reason that I intend to have an option to exclude all multi-step instructions from the future code-size reduction ISA extension (e.g. PUSH/POP) – not everyone will want to implement multi-step sequences.

good plan.
Adding more and more extensions is certainly bad for delivering libraries as they add more options, but I expect PUSHINT/POPINT to be in __asm inserts only, or even directly written in assembler,

reasonable for many cases, but fast-interrupt TG is targeting full software stack support.
so there should be no effect there.

Again, not so. the cascade effects could be substantial, especially as more functionality of PUSH/POPINT is incorporate into the trap hardware management.
Coordinating the behaviour of hart with/without hardware push/pop assist with/without PUSH/POPINT instruction support and,  compiler and loader optimizations begins to explode in complexity.
What I propose is an extension something like Zclicpushpopint (not sure the Zclic bit is right…..), and

There is a thread [that is dropped from github] about profile slice and dice of functionality and how to manage.
[riscv/riscv-v-spec] Names for embedded vector extension (#550)
And this is the issue in github:
https://github.com/riscv/riscv-v-spec/issues/550
The question there is if such Z* names is better divorced from specification ratification.
It can certainly begin before the draft is submitted, but it may be better not to clutter thinking/prep for submission
to defer finalizing the partitioning to sub- and sub-sub-Znames until after.
I think the success of ZFinX as a placeholder gave false utility to Z-names.
ZFinX' success is not in its Z-formulation, but rather the distinct idea that could have been expressed in other ways including Ψ-extension.
Nor does it fit the Z-formulation model cleanly. ZDinX and ZQinX are not proposed (nor discussed) because, in part,

they muddy the waters.

Z*inX has little to do with F/D/Q which mandate a float register file.

is in reality a ZiFloat support.

And so we see the complexity of adding Z-notation early. It is a distraction in trying to get undefined components properly named.
to give the spec to the fast interrupt team to complete.

As I mentioned earlier, we have done that.
And already received invaluable input from yourself, including this email, from Allen Baum , from Bill Huffman indirectly through V-spec and others on other threads.
What is important is to keep the discussion going. [I acknowledge that my intervention style may stifle. Not my intent.]
Does that sounds like a sensible approach?

The Z-naming has little value, but contributing the concepts that

multi-step ops can/should be considered differently.

that, therefore, PUSH/POP are not expected to be mandated within the code-size-reduction standard

that therefore perhaps fast-interrupt should not rely on it as central to its proposal.

all of that, the opportunity to raise the awareness of the pitfalls of Z-naming
and the other ideas that I have glossed over or am too dense to perceive,
are all worthwhile contributions to the discussion/contemplations.

From:  Allen Baum, Oct 23 2020,  #200
This discussion is bringing up an issue that needs wider discussion about extensions in general.
Risc-V is intended to be an architecture that supports an extremely wide range of implementations,
ranging from very low gate count microcontrollers, to high end superscalar out-of-order processors.
How do we evaluate an extension that only makes sense at one end or the other?
I don't expect a vector, or even hypervisor extensions in a low gate count system.
There are other extensions that are primarily aimed at specific applications areas as well.
A micro sequenced (e.g. push/pop[int]) op might be fairly trivial to implement in a low gate count system
(e.g. without VM, but with PMPs) and have significant savings in code size, power, and increased performance.
They may have none of those, or less significant, advantages in a high end implementation --
and/or might be very difficult or costly to implement in them, (e.g. for TLB miss, interrupt, & exception handling )
(I am not claiming that these specific ops do, but just pretend there is one like that)
Should we avoid defining instructions and extensions like that?
Or just allow that some extensions just don't make sense for some class of implementation?
Are there guidelines we can put in place to help make those decisions?
This same (not precisely the same) kind of issue is rearing its head in other places, e.g. range based CMOs.

From:
Greg Favor, Oct 26 2020,   #205
It seems like a TG, probably through the statement of its charter, should clearly define what types or classes of systems it is focused on optimizing for (if there is an intended focus) and what types or classes of systems it does not expect to be appropriate for.   More concretely, it seems like there are a few TG's developing extensions oriented towards embedded real time systems and/or low-cost embedded systems.  These are extensions that would probably not be implemented in full-blown Linux-class systems.  Those extensions don't need to worry about being acceptable to such system designs, and can optimize for the requirements and constraints of their target class(es) of systems.
Unless I'm mistaken, this TG falls in that category.  And as long as the charter captures this, then the extension it produces can be properly evaluated against its goals and target system applications (and not be judged wrt other classes of systems).  And key trade-off considerations - like certain types of implementation approaches being acceptable or unacceptable for the target system applications - should probably be agreed upon early on.
Greg

From:  Robert Chyla, Oct 26 2020,  #206
I agree with Greg's statements. For me 'code-size' is very important for small, deeply embedded/IoT-class small systems.
Work in other groups (bitmanip) will also benefit code size, but it is not primary focus I think as these will also improve code-speed.
Linux-like big processors usually have DDR RAM and code size is 'unlimited'.
It should not hurt as code-size advances will benefit such big systems, but we should not forget about 'cheap to implement'='logic size' factors.
IMO 'code-size' and 'code-speed' will be pulling same rug (ISA-space) into opposite directions. We must balance it properly - having a rug in one piece is IMO most important.
Regards,
/Robert

From:  Tariq Kurd, Nov 2 2020,  #208
Hi Greg/Robert,
Trying to respond to different emails with the same subject line, maybe we should split the threads.

Unless I'm mistaken, this TG falls in that category.  And as long as the charter captures this, then the extension it produces can be properly evaluated against its goals and target system applications (and not be

judged wrt other classes of systems).  And key trade-off considerations - like certain types of implementation approaches being acceptable or unacceptable for the target system applications - should probably

be agreed upon early on.

The code-size group is supposed to cover all bases, although we know that it is most important for embedded. The intention is to separate out instructions which may be different to implement on high performance cores (i.e. the multi-step instructions like PUSH/POP). All cores should benefit from improved code size as it reduces I-fetch bandwidth and improves cache utilisation.

IMO 'code-size' and 'code-speed' will be pulling same rug (ISA-space) into opposite directions. We must balance it properly - having a rug in one piece is IMO most important.

Agreed. In general reducing instruction counts will benefit size and speed but I’m sure there will be cases where there are conflicts between the two optimisation points. We need a holistic solution with the two groups working together. It’s unfortunate that I missed the first code-speed meeting, but will attend in future (and Jeremey/Wei Wu attend the code-size meetings)
For PUSHINT/POPINT, thanks for the detailed email David.

If an implementation supports PUSH/POP then supporting PUSHINT/POPINT should add little more complexity.

not so. csr may be significantly differently accessible than GPR.

Yes that’s possible. I’m thinking that the micro-ops will be issued as  a sequence of standard RISC-V instructions, so could be CSR ops, after all POPRET can’t only issue as a state machine in the LSU as it needs to update SP and also RET. But granted CSR ops are different from any sequenced micro-ops specified so far.

Again, not so. the cascade effects could be substantial, especially as more functionality of PUSH/POPINT is incorporate into the trap hardware management.

Coordinating the behaviour of hart with/without hardware push/pop assist with/without PUSH/POPINT instruction support and,  compiler and loader optimizations begins to explode in complexity.

The question there is if such Z* names is better divorced from specification ratification.

It’s a good point, we can finish the instruction definitions before dividing into sub-categories, the main thing is to get the instruction definitions correct. Whether PUSHINT/POPINT are mandated is a separate problem.

ZFinX' success is not in its Z-formulation, but rather the distinct idea that could have been expressed in other ways including Ψ-extension.

Nor does it fit the Z-formulation model cleanly. ZDinX and ZQinX are not proposed (nor discussed) because, in part,

The misconception here (and it has come up before) is that the F in Zfinx refers to the F-extension, and it doesn’t. It refers to the F-registers.
The F-registers can be 32/64/128-bit, and whatever width they are they get shared with the X registers (which can also be 32/64/128-bit), so the name ZFinX works for all configurations.
Tariq

The TG discussed this during fast-int meeting.   Some comments:
Code size is not a major concern with ISRs, but performance could  be.  Hardware stacking of CSRs might be a feature that is implemented without ISA support as part of the interrupt handling mechanism, and this would seem preferable to adding this CSR form of push/pop instruction.
While push/pop int instructions might allow more flexible handler design,  most of the handler flexibility would be outside the save/restore mechanism in any case.  It is not clear that the parameterization needed for stacking using the push/pop instruction would be any less than the equivalent parameterization in the hardware stacking mechanism.
General push/pop instructions could be useful in a handler, but would have to understand the impact on interrupt response time (if not pre-emptible) or interrupt throughput (if uses restart to handle preemption).  A design that allowed resumable preemption through many interrupt levels could be difficult to support and require additional exposed state to be saved and restored.
Another proposal is to have a separate push/pop instruction only for interrupt CSRs, which would need less encoding space - the main advantage of this instruction would be to allow greater speed with a secondary advantage being fewer bytes of code to fetch in handler.
We think we can delay this discussion until other issues are resolved in the design.

The TG discussed this during fast-int meeting.   Some comments:
Code size is not a major concern with ISRs, but performance could  be.  Hardware stacking of CSRs might be a feature that is implemented without ISA support as part of the interrupt handling mechanism, and this would seem preferable to adding this CSR form of push/pop instruction.
While push/pop int instructions might allow more flexible handler design,  most of the handler flexibility would be outside the save/restore mechanism in any case.  It is not clear that the parameterization needed for stacking using the push/pop instruction would be any less than the equivalent parameterization in the hardware stacking mechanism.
General push/pop instructions could be useful in a handler, but would have to understand the impact on interrupt response time (if not pre-emptible) or interrupt throughput (if uses restart to handle preemption).  A design that allowed resumable preemption through many interrupt levels could be difficult to support and require additional exposed state to be saved and restored.
Another proposal is to have a separate push/pop instruction only for interrupt CSRs, which would need less encoding space - the main advantage of this instruction would be to allow greater speed with a secondary advantage being fewer bytes of code to fetch in handler.
We think we can delay this discussion until other issues are resolved in the design.

We revisited this topic again but decided to defer to broader discussion on providing hardware stacking of interrupt contexts (possibly post-1.0).


ng update comand not working

Please provide us with the following information:

OS?

Windows 7, 8 or 10. Linux (which distribution). Mac OSX (Yosemite? El Capitan?)
MAC

Versions.
@angular/cli: 1.0.0-beta.31
node: 6.9.0
os: darwin x64
@angular/common: 2.4.7
@angular/compiler: 2.4.7
@angular/core: 2.4.7
@angular/forms: 2.4.7
@angular/http: 2.4.7
@angular/platform-browser: 2.4.7
@angular/platform-browser-dynamic: 2.4.7
@angular/router: 3.4.7
@angular/cli: 1.0.0-beta.31
@angular/compiler-cli: 2.4.7

I just updated form #30 to # 31 and after standard procedure of uninstalling and installing new NPMs I run ng update that usually works but now after first questions and aswer NO to skip it exits back to terminal

installing ng2
? Overwrite .editorconfig? (yndH)

Is there any update task available for this version or should I create new empty project and update files manually?
Thank you,
frank

Noticed same issue on windows also....
For now I am currently creating a new project and manually overwrite the files.
Also it will be good when we overwrite the files like package.json it will update the dependencies version only related to cli and not remove the independently installed dependencies like bootstrap

I see. so it must be something in new version. I just created new project and used merge tool and did little manual work.

Dupe of #4653.
ng update was broken in beta 31 and has been removed from beta 32 in #4628
See changelog for more info: https://github.com/angular/angular-cli/blob/3ad2856b27889a50a742c9dca9554a190c8509bf/CHANGELOG.md

Cool. I will start again. I just hope in the next few minutes there will not be version 33 ;-)

Next release will be rc0.

You might want to also update documentation as in README.md there is still 👍
rm -rf node_modules dist # use rmdir on Windows
npm install --save-dev @angular/cli@latest
npm install
ng update

So the update doesn't work, what can we do to update? We now need to resolve to what @prathamesh7pute does before there was such command...

To update you need to follow the breaking changes instructions in CHANGELOG.md


Use static HttpClient

As previously discussed, we are using .NET's HttpClient as a disposable. This is not recommended as per https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/ and other sources.
We should look in to keeping an internal static HttpClient and use it where it makes sense. Take note that we cannot make assumptions on how this SDK will be used, so things such as DI that relies on registering services etc are probably out of scope, unless we provide our own HttpClient service that the user can register.
Alternatives of the top of my head:

Keep an internal static HttpClient and use it where applicable

This is probably only applicable in some places, such as CallAsync

Let the user provide their own HttpClient

We do set headers prior to making requests, so we would probably have to do some house keeping with this
Could the above lead to potential race conditions in multithreaded environments?

Provide a service that the user can register for DI, and use that internally

Not sure if this would provide any benefit over the previous point unless we can make such that the user can re-use their own HttpClient

CC @brokenprogrammer - any thouights on this?

My personal preference would be alternative 1. Its a small code change and the only downside would be that we would have to deal with the default request headers in some sane way.
We provide the following function:
internal static async Task<AuthorizationResponse> GetAccessTokenAsync(string authorizationCode, string clientSecret, string apiEndpoint)
{
        using (var client = new HttpClient())
        {
            client.DefaultRequestHeaders.Add("Client-Secret", clientSecret);
            client.DefaultRequestHeaders.Add("Authorization-Code", authorizationCode);
            client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));

            var response = await client.GetAsync(apiEndpoint);

            return await GetResponseAsync<AuthorizationResponse>(response);
        }
}

This sets the header "Authorization-Code" which is only relevant for this specific request. All other requests using the FortnoxAPIClient are using the header "Access-Token" instead. So for this to work in a sane way I'd prefer some sort of initialization step for the static HttpClient setting the correct headers and for the GetAccessTokenAsync perhaps remove and then restore the headers on the fly?
As for point 2, letting users provide their own HttpClient would be a great addition in my oppinion. However this should not be mandatory. My only question about this would be how we would handle both the request headers and also if the set HttpClient should be re-used.
The http headers for the provided HttpClient can always be removed after its use but shifting focus to the HttpClient should it be bound to the FortnoxAPIClient  or bound  to the request itself, example:
// Idea 1
var client = new HttpClient();
// All requests made with this request object will use the same http client
var request = new InvoiceListRequest(this.connectionSettings.AccessToken, this.connectionSettings.ClientSecret, client);
var invoiceList = await InvoiceService.GetInvoicesAsync(request);

// Idea 2
var client = new HttpClient();
var request = new InvoiceListRequest(this.connectionSettings.AccessToken, this.connectionSettings.ClientSecret);

// InvocieList's request is made using the http client created above but secondInvoiceList is created using the internal HttpClient
var invoiceList = await InvoiceService.GetInvoicesAsync(request, client);
var secondInvoiceList = await InvoiceService.GetInvoicesAsync(request);

I don't like the third option due to the big change.
CC @BaconFinger - Would you like to join in on this discussion?

I agree with option #1. Is the article implying that we could just have a static HttpClient in classes (that is, a 'new' static HttpClient every time), or is it saying that we should have one static HttpClient instance that is accessible everywhere (that is, a singleton)?
Headers and such can be done via a fluent interface, and should be cleared after a request. If we want to have some kind of initializer-esque method that is called to get the static instance, we could clear the stuff there also. Like:
var client = InternalHttpClient.New().Blah().Blah().Blah().Get(url)
The client should only come into the picture at the last possible second. So inside of GetInvoicesAsync the method would get the static instance itself. I really am not a fan of passing connection objects (and configuration, to a lesser extent) as parameters of functions when we are doing object-oriented stuff. The good lord gave us fluent interfaces for a reason:
var request = new InvoiceListRequest().AccessToken(token).ClientSecret(secret).Client(staticClient)
Conceptually, I do think it a little strange that the request is doing the sending. Shouldn't our client/client abstraction take a request and send it? But that's a little more off-topic.
Users providing their own HttpClient is a nice-to-have, but I don't really see how it fixes the problem. If they just pass in the default HttpClient then it's like we did no change at all.
Option 3 is a bit too much for right now.

I agree with your sentiments that option 1 is the most valid one. Doing re-writes of the API is off topic

Users providing their own HttpClient is a nice-to-have, but I don't really see how it fixes the problem. If they just pass in the default HttpClient then it's like we did no change at all.

The idea behind this would be to allow them to have one static HTTP Client across their application lifetime. The way we do it now, (or according to what is discussed in thie PR) would mitigate the problem internally to this library, but not necisarily outside it (as it is used in an application)


_metadataObjectTypes is staying nil and crash app.

Yannick,
I has one problem and make some adjusts (workaround).
Please, see.
The _metadataObjectTypes  is always nil.
QRCodeReader.m
- (id)init
{
  if ((self = [super init])) {
    _metadataObjectTypes = @[AVMetadataObjectTypeQRCode]; //not work. _metadataObjectTypes  will continue nil

    [self setupAVComponents];
    [self configureDefaultComponents];
  }
  return self;
}

- (id)initWithMetadataObjectTypes:(NSArray *)metadataObjectTypes
{
  if ((self = [super init])) {
    self.metadataObjectTypes = metadataObjectTypes; //not work. _metadataObjectTypes  will continue nil.

    [self setupAVComponents];
    [self configureDefaultComponents];
  }
  return self;
}

Workaround:
QRCodeReader.m
@interface QRCodeReader () <AVCaptureMetadataOutputObjectsDelegate>
@property (strong, nonatomic) AVCaptureDevice            *defaultDevice;
@property (strong, nonatomic) AVCaptureDeviceInput       *defaultDeviceInput;
@property (strong, nonatomic) AVCaptureDevice            *frontDevice;
@property (strong, nonatomic) AVCaptureDeviceInput       *frontDeviceInput;
@property (strong, nonatomic) AVCaptureMetadataOutput    *metadataOutput;
@property (strong, nonatomic) AVCaptureSession           *session;
@property (strong, nonatomic) AVCaptureVideoPreviewLayer *previewLayer;

@property (strong, nonatomic) NSArray *metadataObjectTypes; //ADDED

And replace all _ metadataObjectTypes  for self. metadataObjectTypes  in QRCodeReader.m.
Now it works!

@humbertosales Thank you for the hint. I'll investigate that when I'll have some time.


wrap MCintegration.jl

Fixes #194
This pr adds a VEGASMC algorithm from MCIntegration.jl
This library supports:

vector-valued integrands
inplace integrands
This library doesn't support:
absolute or relative tolerances
batched integrands

I think some of the tests may not pass due to underconvergence, which happens randomly due to MC sampling.

I guess you can seed your rng to control convergence, but QMC might also be helpful https://github.com/numericalEFT/MCIntegration.jl/issues/53

Make the tolerances a bit lower? If that's not helping then its stopping heuristic may be incorrect.

I'm the developer of MCIntegration.jl. Thank you for considering our package. If you need any help to fix the interface errors, please let me know :-)

@kunyuan I think the only major thing coming up is that it would be nice for it to directly use QuasiMonteCarlo as suggested here https://github.com/SciML/Integrals.jl/issues/207

@ChrisRackauckas I saw https://github.com/numericalEFT/MCIntegration.jl/issues/51 so I moved MCIntegration functionality to an extension. It will be easy and non-breaking to migrate it to a dependency as soon as it is ready.

That's good thanks. Yeah, until MPI is an extension in MCIntegration.jl it probably cannot be brought in as a standard dependency since MPI.jl can cause build problems on some platforms.


Wireframe

front end wireframe (ex tools are figma , ex pin.. etc)

succesful launch to / homepage -- need to get ui on pet, user, and messages.. etc


Make EPS installable with pip

While reviewing #38 it struck me, most of the rough edges are because EPS does not use setuptools, and isn't installable with pip.  I'm guessing since EPS isn't completely matured yet, simply no one has gotten around to addressing mundane issues like this?

I'm guessing since EPS isn't completely matured yet, simply no one has gotten around to addressing mundane issues like this?

Yes.


Admin/FTP: turn hidden 'put' parameters visible

Description:
Based on the feedback comment in ticket #4086 (Excellent ftp reference), I discovered that this page does not show the parameters in their table. The angle brackets are the cause of this issue,
< and >, also known as the "Less Than" and "Greater Than" symbols, often indicate HTML tags in web page encoding. The table entries need to be escaped or encapsulated to avoid being interpreted as hidden code. Based on the syntax view, I will prefer to use MarkDown back tick encapsulation.
Thanks to @pernak01 (Ken Perna) for the opportunity.
Changes proposed:

Add MD backticks around the bracketed table entries
Add metadata details "FTP - put" for this command
Whitespace changes:

Remove end-of-line whitespace (trim trailing space)
Add MD indent marker comp. spacing in "Applies To:"
Add alignment spacing and hyphens to the MD table.

Ticket closure or reference:
Closes #4086

#sign-off


youtube from IOS mobile device not working as aspected

Current Behavior
Watching youtube from mobile (IOS) with controls is not working.

I cant press the volume and full-screen buttons because the title is hiding them.
Clicking on the video makes double click happen

Expected Behavior
I would be able to click full screen and volume.
If I use youtube iframe the buttons move to the bottom
Steps to Reproduce

go to the demo page from any mobile IOS device
click on one of the youtube tests
Turn on controls

Environment

URL attempting to play: any
Browser: chrome
Operating system: 13.5.1
jsFiddle example: https://cookpete.com/react-player/

I can confirm this issue above on safari

This is not a problem with ReactPlayer. This library uses the YouTube Player API to play YouTube URLs and this looks like a recent change to that API that has broken things on mobile. Maybe try StackOverflow as per the Player API support page.


Hyundai Kona Hybrid: use torque controller

Hyundai kona hybrid 2020 use torq-controller
Although torq-control works very well in the kona hybrid 2020,
Currently, it is not applied to KONA Hybrid, so in the case of master-ci,

it is cumbersome as i have to modify it every time there is an update.
route  : 9a3aa85e86f9c3fc|2022-07-04--13-58-52--78
(route-id used torq-control segment)

In "https://github.com/commaai/openpilot/pull/24921", both kona and kona-hybrid use the values of kona-electric.
This makes for very good driving conditions. so the vehicle model was not separated.


How to disable to addresses

While starting thorium goes without asking here. How to stop this?

It may be that some Google services in the browser are connecting to Google. In order to ensure availability, we will not handle it.

you sell your users to monopolists?


Website down

Bad Gateway 502

Merging into https://github.com/aslushnikov/latex-online/issues/95


Assignment 2 finished.

great information to understand about brain image scanning.

Task 1 wrong but bonus correct!


Require explicit channel type negotiation

This feature was introduced in the spec by https://github.com/lightningnetwork/lightning-rfc/pull/880
We take this opportunity to also clean up the channel state machine to leverage the feature bits added in #237 instead of the somewhat hackish reliance on isZeroReserve for a bunch of unrelated Phoenix features.
We should only merge this once the ACINQ node has deployed support for https://github.com/ACINQ/eclair/pull/1867 since we will now require explicit channel type negotiation. And we should probably also update our E2E test repository as well to verify that channel opening works correctly.

Thanks for the tests!