Razorupdate

I have pulled in thecodejunkie's razor refactoring and support for vb.  After that, I added in support for @model and @ModelType (in csharp and vb respectively) to allow for strongly typed models.  In addition, I converted the HtmlHelper and UrlHelper to be strongly typed as well so as to support element generation based on a model in the future.

So where are the Html / Url properties on the view set now?

In the NancyRazorViewBase Initialize method.  Line 156.
public virtual void Initialize(RazorViewEngine engine, IRenderContext renderContext, object model).

I've started reviewing this. While it's too early to comment on the functionality I have noticed that the code has started to deviate from the code style uses in the Nancy source (I probably should document these some day =)
Here are a couple of things I've noticed when looking around in the code

Use var when declaring variables
All if-statements should be encapsulated in { } even if they have a single-line body
Use this. when calling instance members from inside a class, even if they are inherited. Looks like static members if you don't
All public parts of the API (the class, ctor, properties, methods etc) should have proper XML comments

Not sure if you use R# or not, but there are bits of unused code in a couple of places which would be nice to have removed to increase the clarity.
Will get back with feedback on the actual functionality too =)

Great.  Yeah, I can make those changes.  I actually was trying very hard to keep a similar style and did not see any of the conventions you mentioned in the parts of the code I was looking at for styling (for instance, I never put using statements inside the namespace, but made sure I did to follow your conventions).  Regardless, I'll make those changes after your functionalilty review :).  And unused code sucks, so I'll try and track that down (no, I don't have R#).
Thanks for your help...

Could you rebase this and I'll pull it in?
Did you use GhostDoc perhaps when you documented?
Some of them is more or less Engrish ;)
Here are a couple I spotted in HtmlHelper

Antis the forgery token.
Raws the specified text.
Partials the specified view name.

Quite a lot of them also miss a description in the  tag
So once those are done and it's been rebased I think we're ready to pull it in!

Ok, I believe I cleaned up those remaining things.  I rebased and squashed the commits as well to make it cleaner.

I'll have a look during the day. Btw any particular reason the main route in the asp.net hosting demo is now a .vbhtml file instread of a .cshtml? =)

That was how it was.  I didn't change it.  I believe that came from your
commit...
https://github.com/thecodejunkie/Nancy/blob/razorvbhtmlsupport/src/Nancy.Demo.Hosting.Aspnet/MainModule.cs#L12
2011/11/30 Andreas Hkansson <
<EMAIL_ADDRESS>

I'll have a look during the day. Btw any particular reason the main route
in the asp.net hosting demo is now a .vbhtml file instread of a .cshtml?
=)

Reply to this email directly or view it on GitHub:
https://github.com/NancyFx/Nancy/pull/413#issuecomment-2959886

oh ;)
2011/11/30 Craig Wilson <
<EMAIL_ADDRESS>

That was how it was.  I didn't change it.  I believe that came from your
commit...
https://github.com/thecodejunkie/Nancy/blob/razorvbhtmlsupport/src/Nancy.Demo.Hosting.Aspnet/MainModule.cs#L12
2011/11/30 Andreas Hkansson <
<EMAIL_ADDRESS>

I'll have a look during the day. Btw any particular reason the main route
in the asp.net hosting demo is now a .vbhtml file instread of a .cshtml?
=)

Reply to this email directly or view it on GitHub:
https://github.com/NancyFx/Nancy/pull/413#issuecomment-2959886

Reply to this email directly or view it on GitHub:
https://github.com/NancyFx/Nancy/pull/413#issuecomment-2959939


Feature: Purposefully failing test (test.failing)

Do you want to request a feature or report a bug?
Feature
What is the current behavior?
As discussed in #1605, ava has a way of marking a test purposefully failing. I'd like to replicate that feature in Jest. The other features mentioned in #1605 has been implemented for more than a year, so I'm making a new issue to track test.failing.
I'll try to find the time to implement this the coming week.
If the current behavior is a bug, please provide the steps to reproduce and either a repl.it demo through https://repl.it/languages/jest or a minimal repository on GitHub that we can yarn install and yarn test.
N/A
What is the expected behavior?
I should be able to have a test that is failing on purpose (due to a bug or a non-implemented feature) that only fails the test suite if the test passes.
Link to Ava's docs on the feature: https://github.com/avajs/ava/blob/42e7c74c46756c441fe33ecdcbb76ac210e422ea/readme.md#failing-tests
Please provide your exact Jest configuration and mention your Jest, node, yarn/npm version and operating system.
N/A

test.failing() is a very useful feature.
For example, you encounter a bug which the root cause is from a dependency written by another team.
Marking the test as failing() allows you to track these tests to make sure they are all taken cared of before release.
test.skip() only indicate the outcome (you skipped a test), but does not carry any semantic meaning (i.e. why are you skipping. Is it a todo, a known issue, something you will be implementing in the next release, etc).

Just wanted to comment to maybe bring back some attention to his feature. I myself find it extremely useful, especially for documentation purposes and I think it wouldn't hurt for Jest to have it. I miss it when switching from an AVA project!

Would be great if the default reporter output the number of intentionally failing tests similar to how we do .todo now 👍

I added my vote on this feature, which is also available on RSpec (https://relishapp.com/rspec/rspec-core/v/3-8/docs/pending-and-skipped-examples/pending-examples).
One additional use case would be in a Test-Commit-Revert (TCR) context: I might want to write the test first and not implement the feature yet, so I mark it as failing (or pending with the RSpec syntax). This would allow me to run the TCR loop and verify that my test is indeed failing as I expect, then I can implement the feature and remove the failing to then run again the TCR loop and see that my test does indeed pass.

Bump

PR welcome! 🙂 Looking at how todo was added might help: #6996. Adding it to just jest-circus is fine, no need to mess with jest-jasmine.

@SimenB I can jump into implementing it. I even tried already but I've stumbled upon 1 problem.
I wanted to use the mode field in Circus.Event to deliver information about if the test should be treated as failing or not (similar to todo behaviour that you've linked). But after getting it to work I've tried to cover the edge case of adding both failing and skip or only modifiers which screwed up the whole logic :D.
Should the solution be to extend the Circus.Event type with potential isReversed or something like that? Because that's the thing I'm coming up with :D.

@SimenB You can see my solution at #12610 :). If needed I can try to add it also to jest-jasmine2 but I didn't want to spend too much time on it in case you will suggest a completely different solution.

I am not the one purposefully failing if you may override please do.
On Sun, Mar 27, 2022, 8:30 AM Michał Warda @.***> wrote:

@SimenB https://github.com/SimenB You can see my solution at #12610
https://github.com/facebook/jest/pull/12610 :). If needed I can try to
add it also to jest-jasmine2 but I didn't want to spend too much time on it
in case you will suggest a completely different solution.
—
Reply to this email directly, view it on GitHub
https://github.com/facebook/jest/issues/4627#issuecomment-1079932318,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AXSL3Z4N6HNG7C7AOEDOPHTVCBWG7ANCNFSM4D6HGA6Q
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Thanks @michalwarda! I don't think we need to add this to jasmine


Cannot open Feedback_Prize folder

Thanks for the amazing solutions Shujun He.
I have a problem accessing the Feedback_Prize folder from Shujun_solution/src/. It appears that I can see a folder with white arrow, but cannot open it. Can you check it for me?

This has been fixed.


[feature-request] Use Quarterly as an option compared to datetime format

It would be great to be able to use fiscal quarters as an option when forecasting instead of having to have a field with datetime value types.

nevermind that was a dumb question to ask, I wasn't thinking.....
time to go get more coffee


[nim][matmul] use unchecked array

On my machine (Apple M3 Max), the perf difference of using unchecked array vs seq in nim is pretty big (0.51s vs 0.66s)

With -d:danger --passL:"-flto" on my machine(ryzen 5600x on linux) on yours I get around 500ms, and on the original I get around 600ms. Which seems to indicate this change only works around lacking LTO and checks on.

Somehow with this change, matmul becomes much slower on my Apple M1. N-queens becomes slightly faster. I have reverted matmul.nim to the old version for now.

I see. Must be some mistake on my end - will try to redo the test on m1 mac and see what's going on.

It turns out to be related to compiler flags somehow
with nim c **-d:release** matmul.nim && time ./matmul
./matmul  **1.48s user**
./matmul_old  **1.84s user**

with your nim c **-d:release --bound_checks:off** matmul.nim
./matmul  1.47s
./matmul_old  0.67s user

with  nim c -d:danger matmul.nim && time ./matmul
./matmul  0.53s
./matmul_old  0.66s

To be the fastest you likely should use --d:danger --passL: "-flto -march=native" --passC: "-flto"

Hmm... I am good with -d:danger, but I am hesitant to use the new matmul because it is much slower than the current version under -d:release.

If you have a version that is faster than the current one under both -d:release and -d:danger, it will be better.

faster than the current one under both -d:release and -d:danger

-d:release and -d:danger differ by attached debug information. The rust benchmarks for example also supress debuginfo to be faster. I think the right flag here is -d:danger. I could emulate -d:danger with -d:release + suppressed debug info if you want.
I am guessing that UnCheckedArray doesn't benefit from a mere "--bound_checks:off" like how the seq does. It seems like an bug / unintended behavior in the compiler. @beef331 probably knows better.

UncheckedArrays are as the name implies unchecked so they already have no bounds checking. You get roughly the same thing when using seq[T] with --checks:off

The question here is less about compiler options but more about the implementation. If implementation A is faster than B under a more common compiler setting, A is better. Imagine people learn from your implementation but apply -d:release. That is not good.

If implementation A is faster than B under a more common compiler setting, A is better.

Fair point! I myself don't understand why my implementation doesn't improve perf with release + bounds_off but with release and danger.
I was discussing with folks in the nim discord server and it seems like the right flags to use here are -d:release -d:lto I will check if that actually improves the benchmarks.

-d:lto did the trick. I really feel that this (lto) should be the default behavior with -d:release. But I guess that dicussion needs to happen in another forum.

Updated #30 with the recommended flags.

This needlessly changes nqueen on a ryzen 5600x both CArray[T] and seq[T] gives same performance with -d:lto -d:release --panics: on

This needlessly changes nqueen on a ryzen 5600x both CArray[T] and seq[T] gives same performance with -d:lto -d:release --panics: on

Nqueens was never using seq it was using array.
(I think nims array defeats the spirit of the problem, the container is supposed to be dynamic. It is also wasteful of memory the way it was before.)

Just to confirm that every task is supposed to read "N" from command line:

nqueen: N is the size of the board. It will take forever to solve 31-queen, so N is 31 at most.
matmul: size of the matrix
sudoku: number of repetitions
bedcov: number of intervals

Nonetheless, learning how to read command line arguments in 20 languages takes time. I was lazy and didn't implement command line parsing in every program.

Just to confirm that every task is supposed to read "N" from command line:
I see! I can try to address that.


fix: client build css

Resolves #452
For Server build (not ssr), the determined css was being injected using cssAssets into the html when building the ssr/client output. That's why rsc css used to work in build.
The issue is when the client output was emitted, the css was generated too. But since vite does not find that css being generated by the index.html/main.tsx, rather by other entries, it didn't include it in the final index.html output.
The solution is to get that generated css and inject it manually into the final html file.

btw, I remember I did the similar one in #456

@Aslemammad How does #658 relate to this and #452?

https://github.com/dai-shi/waku/pull/658#discussion_r1562005260 Yeah, I had the same comment. 😄

haha yea, we need to do the 2 pass thing as mentioned!


Extend detail page summary

Depends on https://github.com/ugent-library/biblio-backoffice/pull/1659 – needs to merged first.

Made detail page summary in header more informative
Fixes https://github.com/ugent-library/biblio-backoffice/issues/1338

🙏 Not happened yet: live updating of header after editing. Could use some help with that, can be in a separate PR.

publication: citation style header with

authors or editors
title
Journal title
year
page count / volume / issue / first and last page
publisher
conference name if applicable

datasetscitation style header with

contributors
title
publisher
year
identifier type

Biblio ID
Repositioning of header elements and responsiveness

Aligned access level icons and copy in search overview and full text & files view
Task part of https://github.com/ugent-library/biblio-backoffice/issues/1623

TODO:

dataset DOI double check
double check names for different publication types

2 tests fail because of these changes (issue-1370).

This one will change as well when the info sidebar is there, to save space and only focus on the important info: https://github.com/ugent-library/biblio-backoffice/issues/1663
We would only show edited in the header, and the other info would move into the info sidebar.

@verheyenkoen fixed with 6abd3e9


Compilation issue in vagrant box Archlinux

Hi,
Here log file : https://gist.github.com/eoli3n/a825a8f6f33f80f3212d8c8926bcf735
Here the PKGBUILD : https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=polybar-git
Step to reproduce
1° Install vagrant and virtualbox
2° Create vagrant file
mkdir vagrant-test
cat <<\EOF > vagrant-test/Vagrantfile
# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
  config.vm.box = "terrywang/archlinux"
  config.vm.provision "shell", inline: <<-SHELL
    # Upgrade to latest
    pacman -Syu --noconfirm
  SHELL

  $script = <<-SCRIPT
  yaourt -S polybar-git --noconfirm
  SCRIPT

  config.vm.provision "shell", inline: $script, privileged: false
end
EOF

3° Then run it
cd vagrant-test
vagrant up

Manual install
To launch a shell on the vm
vagrant ssh

When i run manually
git clone --branch 3.1.0 --recursive https://github.com/jaagr/polybar
mkdir polybar/build
cd polybar/build
cmake ..
sudo make install

It works... what differ ?
Another question, why there isn't any polybar package in community ?

Your VM does not have enough RAM, try increasing it.
To move a package from the AUR to the community repo, we would need to get a Trusted User to maintain it: https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines#Rules_for_Packages_Entering_the_.5Bcommunity.5D_Repo

Worked with
  config.vm.provider "virtualbox" do |vb|
    vb.memory = "1024"
  end

Thx !


reply in a respond block should reply to the user triggering the script

According to the (Hubot docs)[https://github.com/github/hubot/blob/master/docs/scripting.md#send--reply], reply should reply to the user initiating the script.
Example
module.exports = (robot) ->
  robot.respond /syn/i, (msg) ->
    msg.reply "ack"

Expected output
jmwelch: ack
or
@jmwelch: ack
Received output

Looks like it may be in (this)[https://github.com/victorops/hubot-victorops/blob/master/src/victorops.coffee#L104-L115] block:
  sendToVO: (js) ->
    m = JSON.stringify(js)
    message = "VO-MESSAGE:" + m.length + "\n" + m
    @robot.logger.info "send to chat server: #{message}" if js.MESSAGE != "PING"
    @ws.send( message )

  send: (user, strings...) ->
    js = @chat( strings.join "\n" )
    @sendToVO( @chat( strings.join "\n" ) )

  reply: (user, strings...) ->
    @send user, strings

The user arg that's passed to reply doesn't seem to be doing anything once it hits send (unless I'm misreading this).
I'll do some testing to see if I can get the expected behavior working.

Now that I look at it closer, this line doesn't look to be doing anything, either:
    js = @chat( strings.join "\n" )

The call to @sendToVO doesn't use the js var, it just reproduces the work done.


fix: keepkey firmware version check for LTC

Description

KK 7.4.0 is required for LTC support
Notice

[x] Have you followed the guidelines in our Contributing guide?
[x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Pull Request Type

[x] :bug: Bug fix (Non-breaking Change: Fixes an issue)
[x] :hammer_and_wrench: Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
[ ] :nail_care: New Feature (Breaking/Non-breaking Change)

Issue (if applicable)

closes #2374
Risk

we erroneously skip LTC for a working firmware version
Testing

dear ops - plz coordinate amongst yourselves and do NOT update all your KK firmware at once
plz test with LTC flag on

half of ops update to latest firmware and check LTC works
half of ops stay on current firmware and ensure that KK works with all other chains with LTC flag
on, LTC should not show in accounts

Screenshots (if applicable)
wip

@gomesalexandre requires fleek env vars for keepkey versions url to be updated from static.shapeshift.com to the githack url in sample.env

Doesn't this happen on the hdwallet side? hdwallet includes code for checking if a chain is supported and can check the firmware version.


Fix SortCommand, AddClass command message, timetable header, and UserGuide

Codecov Report

Merging #184 (f659376) into master (91316de) will decrease coverage by 0.14%.
The diff coverage is 18.18%.

@@             Coverage Diff              @@
##             master     #184      +/-   ##
============================================
- Coverage     52.67%   52.52%   -0.15%
  Complexity      630      630
============================================
  Files           119      119
  Lines          2863     2871       +8
  Branches        350      352       +2
============================================
  Hits           1508     1508
- Misses         1266     1274       +8
  Partials         89       89

Impacted Files
Coverage Δ

.../seedu/address/logic/commands/AddClassCommand.java
0.00% <ø> (ø)

...du/address/logic/parser/AddClassCommandParser.java
0.00% <ø> (ø)

...rc/main/java/seedu/address/model/student/Name.java
80.00% <ø> (ø)

...n/java/seedu/address/model/tuition/ClassLimit.java
80.00% <ø> (ø)

...a/seedu/address/ui/infopage/TimetableInfoPage.java
0.00% <0.00%> (ø)

...seedu/address/model/tuition/UniqueTuitionList.java
66.17% <100.00%> (ø)

Continue to review full report at Codecov.

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


Please make CookVSCode available on Open VSX Registry

As I use Codium instead of VSCode I try to use it independent from Microsoft. Therefore I use the Open VSX Registry instead of the Visual Studio Marketplace. I am very interested in the cooklang environment, so I kindly ask you to publish your CookVSCode on the Open VSX Registry platform.
Thanks a lot.

If this is not possible, can you please provide the .vsix file? Tried to install CookVSCode on an arm64 system by building it with vsce, but this does not run on arm64.

Done https://open-vsx.org/extension/dubadub/Cooklang. It will take some time to claim ownership.

Wow! That was really fast! Thansk a lot again.
Best regards,


[Improving home page styling]

Hey I believe that you website could do better with some styling improvements.
Such as,

The red outline around the details to be filled is not looking good so I could find a better way to do it better.
Also the boxes have strict corners which would look better with some round corners.
And the when we hover over the book now button, the whole button comes up but what I think would be better is if we hover over the button, the book now text gets bigger not the whole button maintaining the aesthetics of the website.

And lastly, it would be better to choose a different colour palette for this form as it is looking completely different from the website like it doesn't even belong here.
@07sumit1002 Please assign me this issue so that I could make it better.

The navigation bar is not consistent across all the pages.
Also hovering over the contents in the nav bar creates a inconsistent selection block.
The image of the latter is attached.

Selecting "Home" creates a P shape selection while hovering over it and it is same with the other objects of nav bar as well.
Please assign the task to me with required labels of gssoc-ext and the labels you think it satisfied to have it done smoothly.
Looking forward to you favourable response.

@pranusri1903 Please go through navbar of all the pages and make them consistent I will assign it level 3

Pull the latest code and then work on it

Thanks a lot

Done


[1.13.x] KOGITO-6805 Remove dependencies to jbpm-flow

Backport of https://github.com/kiegroup/kogito-runtimes/pull/2063

(tests) - kogito-examples job #53 was: UNSTABLE
Possible explanation: This should be test failures
Test results:

PASSED: 415
FAILED: 2

Those are the test failures:

Build projects / org.acme.travel.MultiMessagingIT.testProcess
org.opentest4j.AssertionFailedError: expected: <0> but was: <3>	at org.acme.travel.MultiMessagingIT.testProcess(MultiMessagingIT.java:104)

org.kie.kogito.examples.demo.OutboxIT.testSendProcessEvents
org.awaitility.core.ConditionTimeoutException: Condition with lambda expression in org.kie.kogito.examples.demo.OutboxIT was not fulfilled within 4 minutes  10 seconds.	at org.kie.kogito.examples.demo.OutboxIT.testSendProcessEvents(OutboxIT.java:70)Caused by: java.net.ConnectException: Connection refused (Connection refused)	at org.kie.kogito.examples.demo.OutboxIT.lambda$testSendProcessEvents$0(OutboxIT.java:74)

Please look here: https://eng-jenkins-csb-business-automation.apps.ocp-c1.prod.psi.redhat.com/job/KIE/job/kogito/job/1.13.x/job/pullrequest/job/kogito-runtimes.tests.downstream.kogito-examples/53/display/redirect

Jenkins rerun kogito-examples tests

(tests) - kogito-examples job #58 was: UNSTABLE
Possible explanation: This should be test failures
Test results:

PASSED: 416
FAILED: 1

Those are the test failures:

Build projects / org.acme.travel.MultiMessagingIT.testProcess
org.opentest4j.AssertionFailedError: expected: <0> but was: <3>	at org.acme.travel.MultiMessagingIT.testProcess(MultiMessagingIT.java:104)

Please look here: https://eng-jenkins-csb-business-automation.apps.ocp-c1.prod.psi.redhat.com/job/KIE/job/kogito/job/1.13.x/job/pullrequest/job/kogito-runtimes.tests.downstream.kogito-examples/58/display/redirect

Jenkins rerun kogito-examples tests


Resolve timeout under Windows

Run dns.py successfully with Python 3.4 x64, gets response:
 MINI - DNS Server, Listen at: <IP_ADDRESS>:53
Request: <IP_ADDRESS>:65282

Then, resolve google.com fails:
>nslookup google.com <IP_ADDRESS>

Server:  UnKnown
Address:  <IP_ADDRESS>

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to UnKnown timed-out

Fix: [v1.0] (https://github.com/alexsilva/MINI-DNS-Server/tree/1.0)


Existing object as omit function argument leads to schema being an empty object

Hi there,
I want to use .omit with the same argument on multiple schema declarations. To do this, I specify the fields to be omitted in an object and use that object for multiple .omit calls instead of writing the same .omit argument multiple times. However, when I do this, zod removes all properties from the object instead of only the ones I specified.
Here is an example:
import * as z from "zod";

// MyType1 has prop2 after omit as expected

const MyType1 = z
  .object({
    prop1: z.string(),
    prop2: z.number()
  })
  .omit({ prop1: true });

type MyType1 = z.infer<typeof MyType1>;

// MyType2 is empty!?!

const omitProps: { [prop: string]: true } = { prop1: true };

const MyType2 = z
  .object({
    prop1: z.string(),
    prop2: z.number()
  })
  .omit(omitProps);

type MyType2 = z.infer<typeof MyType2>;

What I expected to get is this
type MyType1 = {
    prop2: number;
}

type MyType2 = {
    prop2: number;
}

What I get instead is this
type MyType1 = {
    prop2: number;
}

type MyType2 = {}

I created a codesandbox of this example here.

This is due to your type, { [prop: string]: true } is too wide, as example, if you change this by { prop1: true } or { [prop in "prop1"]: true } this is working as expected:

Thanks for the quick reply!
I think I get it now. There are two layers: typing and parsing. The type of omitProps determines, what the typing system thinks is present after using .omit and the value of omitProps determines, what the parser expects.
When I typed omitProps too broadly, I mislead typescript into thinking I want to remove all properties, while the parser still expects prop2 to be present on the object.
So with my wrong type for omitProps we get this
MyType2.parse({ prop2: 3 });
// works fine

MyType2.parse({});
// 1 validation issue(s)
// Issue #0: invalid_type at prop2
// Required

@akbo exactly — that "typing vs parsing" thing is a subtle but tricky element of TypeScript that takes a long time to fully understand.
In practice, using as const is a better way to achieve this:
const oldOmitProps = { prop1: true } as const; // => { prop1: boolean }
const omitProps = { prop1: true } as const; // { prop1: true }

It tells typescript to treat the value as a literal/constant value, so it infers the type of prop1 as true instead of boolean (which is required for .omit to work right).
@fabien0102 REALLY appreciating your help on some of these issues! I've had a busy few weeks (new job).


Optimize Wrapper ABI

Currently, the WRAP ABI structure has a lot of redundant data. This is because the nested redundant data is useful when generating code, but is unneeded elsewhere.
We should optimize the ABI structure to ensure that it serializes to as small of a size as possible.
Example Optimization
Optimized:
{
  name: "uArrayArray",
  required: true,
  kind: 34,
  array: {
    type: "[[UInt]]",
    required: true,
    kind: 18,
    array: {
      type: "[UInt]",
      kind: 18,
      scalar: {
        type: "UInt",
        kind: 4
      }
    }
  }
}

Original:
{
  type: "[[UInt]]",
  name: "uArrayArray",
  required: true,
  kind: 34,
  array: {
    type: "[[UInt]]",
    name: "uArrayArray",
    required: true,
    kind: 18,
    array: {
      type: "[UInt]",
      name: "uArrayArray",
      kind: 18,
      scalar: {
        type: "UInt",
        name: "uArrayArray",
        kind: 4
      },
      item: {
        type: "UInt",
        name: "uArrayArray",
        kind: 4
      }
    },
    item: {
      type: "[UInt]",
      name: "uArrayArray",
      kind: 18,
      scalar: {
        type: "UInt",
        name: "uArrayArray",
        kind: 4
      },
      item: {
        type: "UInt",
        name: "uArrayArray",
        kind: 4
      }
    }
  }
}

NOTE: we can add back this redundant data using transformations, that way our codegen string templates do not need to be changed.

I think this is really important! The wrap.info file can get really big right now.
Uniswap v3 example:
wrap.info -> 171kb
wrap.wasm -> 799kb


Xcode 13.3: Umbrella header for module 'MappIntelligenceSDK_iOS' does not include header 'MIFormField.h'

Got an error when updating to Xcode 13.3 and Swift 5.6 at MappIntelligenceSDK_iOS.h:
Umbrella header for module 'MappIntelligenceSDK_iOS' does not include header 'MIFormField.h'

Hi,
We found that error for Carthage installation and we will fix it with new version, until then feel free to use cocoa pods or SPM ( with those it works perfectly).

Hi,
In our case it is not working for swift package manager either. Is there any special configuration needed for it to work?
This is blocking us for a while now, do you have a release date?
On the meantime, do you have a branch where we could point to?
Thanks

Morning,
do you have an update on this?
Best,
myToys iOS Team

Morning,
@victorrodriguez2016, @juanjovalino4242
Can you try branch 'carthage_test' to see if it works for you?
After that we will include that changes in our next official release.
Best Regards,
Stefan, Mapp Digital team

Morning Stefan,
I tried and I get this error:
➜  MappTest git:(main) ✗ carthage update --use-xcframeworks
*** Fetching MappIntelligence-iOS-v5
*** Checking out MappIntelligence-iOS-v5 at "50cf8248cffa259b18186c4d2cd60a782ab3f326"
*** xcodebuild output can be found in /var/folders/_z/s47mt_8s7nd67qj9hwqqpxj9bz4hyl/T/carthage-xcodebuild.pN2yhy.log
*** Building scheme "MappIntelligenceSDK-iOS" in MappIntelligenceSDK.xcworkspace
Build Failed
	Task failed with exit code 65:
	/usr/bin/xcrun xcodebuild -workspace /Users/vrodriguez/Desktop/MappTest/Carthage/Checkouts/MappIntelligence-iOS-v5/MappIntelligenceSDK.xcworkspace -scheme MappIntelligenceSDK-iOS -configuration Release -derivedDataPath /Users/vrodriguez/Library/Caches/org.carthage.CarthageKit/DerivedData/13.4_13F17a/MappIntelligence-iOS-v5/50cf8248cffa259b18186c4d2cd60a782ab3f326 -sdk iphonesimulator -destination platform=iOS\ Simulator,id=7B340F98-239A-4599-B728-4899E7176564 -destination-timeout 3 ONLY_ACTIVE_ARCH=NO CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY= CARTHAGE=YES build VALIDATE_WORKSPACE=NO (launched in /Users/vrodriguez/Desktop/MappTest/Carthage/Checkouts/MappIntelligence-iOS-v5)

This usually indicates that project itself failed to compile. Please check the xcodebuild log for more details: /var/folders/_z/s47mt_8s7nd67qj9hwqqpxj9bz4hyl/T/carthage-xcodebuild.pN2yhy.log

I created this fork https://github.com/victorrodriguez2016/MappIntelligence-iOS-v5-fix where I was able to somehow make it work, but I'm not sure if this changes are correct or not.
Just in case it helps :)

Hi,
I would like to as what's the status of the changes requested for the cartage_test branch, as we sent a few emails but haven't got a response yet.
Thanks,
Victor

Hi Victor,
we have created new branch for test carthage_new, please try it. If that still does not working I would like to have one more debugging session.
Best Regards,
Stefan Stevanović

Hi Stefan,
we are still facing the same issue. Let's schedule a debugging session.

Best Regards,
Victor

The problem was resolved with <IP_ADDRESS> version.
Thanks a lot to @victorrodriguez2016 which helps me to resolve this issue.
I am happy to close this issue.

Thanks for all the effort @StefanMiticon!


how do i access the HttpContext in the services?

`@inject()
export default class WelcomeService {
constructor(protected ctx: HttpContext) {} // breaks the app and produces:  help: 'Container is not able to resolve "WelcomeService" class dependencies. Did you mean to use @inject decorator'
getMessage() {
return '...powered by AdonisJS 😎'
}
}`

The services cannot inject the HTTP context directly into the constructor because the context is changed on each new HTTP request.
You could pass the request to a method on the service like this:
const { make, http } = context
const service = await make('hello-service')
await service.handleRequest(http)

This would require that your service had a method async handleRequest(context: HttpContext) {}


Kitty installation on Lenovo Duet 3 (aarch64) ChromeOs incompatible

Hey,
I tried to install just kitty on my Lenovo Duet 3 with your script. The script downloads kitty in Version 0.27.1, but this version is incompatible with debian 11. It requires a newer glibc version of 2.33/2.34 while debian is on 2.31.
I could install kitty via apt-get install kitty, but now i have already installed the newer version via the script. Could you give me a hint, why the installer.sh did not autodetect the right version for debian 11 or how to remove the installed 0.27.1 version?

This is likely an issue with your local install. I don't use ChromeOS as much anymore, but I went ahead and ran ./installScripts/installKitty/index.sh.
I'm now on Kitty 0.27.1 and all is well.
cat /etc/os-release tells me I'm on Debian 11.
ldd --version ldd confirms I am using Glibc 2.31-13+deb11u5.
Have you tried running the script on a freshly created linux container? If so, and you're still seeing the issue, I'd be curious to debug further. If not, you're unfortunately on your own.

I am on a fresh chromebook, only thing i did before installing kitty, was installing vs code and docker.
When i try to start kitty, the following error is shown:
kitty: /lib/aarch64-linux-gnu/libc.so.6: version GLIBC_2.33' not found (required by kitty) kitty: /lib/aarch64-linux-gnu/libc.so.6: version GLIBC_2.34' not found (required by kitty)
I will try again tonight with a fresh linux container.

I have deleted kitty and tried to run it via

apt-get install kitty (its an old version 19.xx)
the static build you linked

The old kitty version (1) looks totaly like a plain terminal. It sems to be not compatible with my setup.
The static file you linked is not the terminal itself, its a static standalone for unix server to remote controll kitty. I tried to reinstall kitty v0.27.1 using the kitty-0.27.0-arm64.txz file from the release link, but it has the same error with the glibc version.
I think the system i have is not supported


Reddit data Test/Train/Val Split

❓ Questions & Help
Hello,
I have been reading into how the reddit data is processed for the reddit example, and it looks like the test, train and validation datasets are split based on node types {1, 2, 3}. This seems like an odd approach to me, shouldn't these datasets be split randomly so that there exists a relatively equal distribution of node types? Please let me know if I'm misunderstanding the process.

In the Reddit dataset, we use the fixed splits from the GraphSAGE paper: "We use the first
20 days for training and the remaining days for testing (with 30% used for validation)". You are free to choose a different split :)

Thanks for the quick response!
Yes I was wondering if that was the reason...but I wasn't sure what the node type was encoding, so the node type denotes the range of days in a month when the post was made?

Yes, this is an already preprocessed version of the data, and the node_type just denotes the which nodes maps to which split.

I see, thanks :)


Why a list of colored noise? + Technical questions

Hi, thanks for releasing the code, I find it very easy to use.
I have a few question about the implementation + 2 technical questions.
Here you use one colored process for each action dimension. Why not using one process of the same dimensionality of the action?
I tried and the code still works if I pass one process of size n, so maybe there is some other reason why you do that.
In the stable_baseline implementation, the action is sampled using mean + std * noise. If noise is white then it's a Gaussian policy and we can use the usual equations and methods to compute log-prob, KL, ...
But if noise is colored, then I guess that log-prob cannot be computed as usual. Isn't this a problem? Because in practice log-prob is computed using stddev, but stddev is then multiplied by a colored noise, not a white noise.
Finally, say I am using an off-policy algorithm. The behavior policy collects samples with the colored noise. When I compute log-probs for the target policy, should I use colored noise or white noise?
Thanks!

Hi Simone, thanks for your detailed comments! To answer your questions:

The reason we implemented it like this is that it makes it very easy to use different colors for different action dimensions, and it works fine for low-dimensional action spaces. However, you are right that it is a bit confusing, as the most common application is to use a single color for all action dimensions. I have changed the implementation to reflect this in the new version 2.0.0 of the package (version bump because it introduces some breaking changes). Now you can just pass a single beta value, together with the action space dimensionality, and the noise is sampled in a vectorized manner, as you describe it. This should make it much faster in high-dimensional spaces.
In fact, this is not a problem. The action distributions (i.e. pi(a_t | s_t)) are still Gaussian at every time step, and in fact independent of the time step, as p(eps_t) = N(eps_t | 0, 1) for all t if eps_{1:T} is sampled from a Gaussian colored noise process (as is the case here), please see also Section A (esp. Fig. A.3) of our paper: https://openreview.net/forum?id=hQ9V5QN27eS
As long as the algorithm only relies on the Gaussian marginal probabilities pi(a_t | s_t), there is no difference between white noise and colored noise, as pi(a_t | s_t) = mu(s_t) + std(s_t) * p(eps_t) = mu(s_t) + std(s_t) * N(eps_t | 0, 1) in both cases. Again, this is because the marginal distribution of the colored noise for a single time step is standard Gaussian. Only if the algorithm depends on a distribution over multiple actions at different time steps, then the correlation needs to be taken into account, which is what differentiates white noise and other colors.

I hope this helps and don't hesitate to reach out again if it is unclear!
-- Onno

Hi Onno, thanks a lot for the detailed reply, I really appreciate it!


Release grafana 10.* compatible version

build with G10
update deps
test thoroughly
make changes if required
release a new version

Test with angular_support_enabled = FALSE (https://grafana.com/docs/grafana/latest/breaking-changes/breaking-changes-v10-0/)

Test alerting (BC in G10)

react 18

Query Editor button moved and looks like "keyspace name" edit =(
Needs to be moved or at least explained in docs

Released


Could not download zip file for zurb foundation

When using composer install on a project including ZURB Foundation, composer tries to donwload http://ftp.drupal.org/files/projects/zurb-foundation-7.x-5.0-rc6.zip (with a - between zurb and foundation), but the proper URL is http://ftp.drupal.org/files/projects/zurb_foundation-7.x-5.0-rc6.zip (with an _ between zurb and foundation).
Installing drupal/zurb_foundation (7.5.0-rc6)
   Downloading: 0%    Failed to download drupal/zurb_foundation from dist: The "http://ftp.drupal.org/files/projects/zurb-foundation-7.x-5.0-rc6.zip" file could not be downloaded (HTTP/1.1 404 Not Found)
   Now trying to download from source
 - Installing drupal/zurb_foundation (7.5.0-rc6)
   Cloning 7bcab1aebafdcf74dcaa2a5b4a884d4ed3a7b1dc

Take a look at https://www.drupal.org/node/2340969 then you see why it does not work.

We use the git repo url to generate the dist url. I think thats wrong. We have to use the project name instead.

The file name is based on the project name at the time it was created, so projects that had their hyphenated names fixed will have older files (created more than ~1 year ago) with the hyphen, and newer packages will use the corrected underscore.
I tried to trace down where the project name was being provided, but was not successful.

Drupal\ParseComposer\DrupalOrg\DistInformation converts the project name & version into a URL
Drupal\ParseComposer\GitDriver::getDist() provides the project name & version

I created drupal-composer/drupal-parse-composer#57 as a quick fix for generating the file URLs, since there could potentially be other effects from a larger change (such as the git URLs, which retain the hyphen).

Thanks @gapple. Merged your PR.


New dev setup

Hey everyone,
I saw some comments regarding improving the dev setup and moving all configuration to pyproject.toml. Here is my take on that:
add pre-commit hooks
ssort introduces a pre-commit hook, so why not pre-commit to improve the code.
These are the hooks I propose to add (through trial and error I found those to be useful):
little impact

check-added-large-files: checks that you don't add files that should not be there
end-of-file-fixer: enforce newline at end of file
trailing-whitespace: remove trailing whitespaces
check-toml: ensure that pyproject.toml is parsable
toml-sort: enfore that pyproject.toml is sorted

already existed

black: runs black after each commit to enforce consistent formatting
mypy: runs mypy after each commit

big impact:

pytest: run all tests after each commit. This hook is not working, I'd need some input how to run the tests properly.

Altogether, these hooks seem to be in the spirit of the existing tools used.
run code on existing files
I ran all hooks on the existing files, there were 2 small changes
add config to exclude test_data from black and isort
As far as I can see, the test_data folder contains example code to test ssort on. As such, black shouldn't format and mypy should not run on this code. This commit ensures that.
add toml sort config
enforce a consistent sorting of pyproject.toml
convert setup.cfg and setup.py to pyproject.toml
The main commit:

remove setup.cfg

add package metadata to pyproject.toml
As far as I checked, all metadata should be correct. Installing the package works aswell.

remove setup.py: setup.py seems to be not necessary for installing the package correctly. However, the tox tests seem to fail now.

ToDo:
Basically, fix the tests. This includes deciding whether to run the tests using pre-commit and how to run the test properly. For both points I need your input.
Constantin

Hi Constantin - Thanks for this.
How are you running the tests?  What OS/python version?
Interested in all of the linting fixes, although would prefer that CI be at least as strict as local testing to avoid situations where someone bypasses checks and then later committers have to clean it up.
setup.cfg/setup.py also good.
For running tests/tools, I would prefer to stick with tox.  Have been a happy user since 2011, and much prefer its explicitness to pre-commit's promise of stuff magically happening in the background.
Will see if I can bump the CI test runners as it looks like ubuntu 18.04 was deprecated late last year.
Are you interested in making the fix for the __path__ bug you reported earlier?

pytest: run all tests after each commit. This hook is not working, I'd need some input how to run the tests properly.

I'm not so sure running the entire test suite on each commit is preferable. There are speed concerns, as mentioned here, but on top of that, making intermediate commits which do not pass the test suite should be perfectly acceptable. Perhaps, if not solely for the sake of keeping this PR as simple as possible, this behavior can be omitted from this PR and reevaluated in a later issue or PR.
Another concern I have, which is not really the fault of this PR but more so of our CI infrastructure in general, is that it seems like it will become increasingly difficult to maintain all of this CI. With this addition, there will be three different locations where CI will need to be maintained: tox.ini, .pre-commit-config.yaml, and .github. With all of these CI mechanisms using their own logic (very little logic reuse between the three), I find it very likely one or more of these files will become unmaintained. Maybe we should explore trying to combine these approaches as much as possible to avoid any such situation. I think something along the lines of github calls tox which calls pre-commit seems pretty reasonable to me.

Basically, fix the tests. This includes deciding whether to run the tests using pre-commit and how to run the test properly. For both points I need your input.

Tests are run with tox. You'll need to add isolated_build=true to the tox.ini for PEP 517 compatibility. There are also still a number of dangling references to setup.py laying around the project which should be cleaned up (lots of references in .github, one in the README.rst, and a bunch in tox.ini).

I'm also of the opinion that this should be broken into two PRs: one for adding the pyproject.toml and one for adding the .pre-commit-config.yaml. These are really two different concerns that are vaguely related.

So, to summarize: I'll make 2 PRs, one for moving setup.* to pyproject.toml. And then we have another discussion regarding if and how to change the dev setup.

I'm not so sure running the entire test suite on each commit is preferable. Thttps://github.com/pre-commit/pre-commit-hooks/issues/291#issuecomment-394167917 are speed concerns, as mentioned here, but on top of that, making intermediate commits which do not pass the test suite should be perfectly acceptable. Perhaps, if not solely for the sake of keeping this PR as simple as possible, this behavior can be omitted from this PR and reevaluated in a later issue or PR.

You are probably correct, it does not make sense to run the tests as a git hook.

Another concern I have, which is not really the fault of this PR but more so of our CI infrastructure in general, is that it seems like it will become increasingly difficult to maintain all of this CI. With this addition, there will be three different locations where CI will need to be maintained: tox.ini, .pre-commit-config.yaml, and .github. With all of these CI mechanisms using their own logic (very little logic reuse between the three), I find it very likely one or more of these files will become unmaintained. Maybe we should explore trying to combine these approaches as much as possible to avoid any such situation. I think something along the lines of github calls tox which calls pre-commit seems pretty reasonable to me.

First of all #81 simplifies the configuration a bit by moving black's, isort's, and mypy's common elements in tox.ini and github ci to pyproject.toml.
I think the main question is, what do you want to have? Looking at tox.ini I think it configures tests and configures different linters. The question is now do you want to run all those using tox?

For running tests/tools, I would prefer to stick with tox. Have been a happy user since 2011, and much prefer its explicitness to pre-commit's promise of stuff magically happening in the background.

The answer seems to be no.
I'd propose something different:

use tox to run the tests only
use pre-commit to run linters like black, isort, ...
use github ci to check everything

My reasoning for that is the following: for me, installing tox environments never works correctly and I'm always missing something. On the other hand, pre-commit just works.
In addition, it is really annoying if github ci fails, because you did not run black or isort and pre-commit kind of forces you to run them.
What do you think?

I think something along the lines of github calls tox which calls pre-commit seems pretty reasonable to me.

My view on this is that tox, github CI and pre-commit are all at about the same level of abstraction and so shouldn't depend on each other.  I think the correct approach is to move as much as possible to the next layer down.  Moving exclude rules to pyproject.toml is a good example (thank you @cgahr).  Perhaps installing tools using dev-dependencies rather than separately would be another easy win?

I think the main question is, what do you want to have? Looking at tox.ini I think it configures tests and configures different linters. The question is now do you want to run all those using tox?

I think the answer is that we want to either run everything using tox or everything using pre-commit.  Both are currently completely adequate for the job, and using two just makes it twice as likely that something will break.
Weirdly I don't think we can make the decision based on current features.  Given that this project is mostly just ticking over with regular but infrequent updates to handle new python versions and occasional feature requests, the most important factor is how scary it is to come back to after six months.
My expectation with tox is that it will be broken by the latest PEP, I'll have an obvious stack trace, and I'll have to do a little bit of reading to fix it
My suspicion with pre-commit is that it will magically auto-update and everything will appear to run fine, but what it is running will no longer be what I audited.

In addition, it is really annoying if github ci fails, because you did not run black or isort and pre-commit kind of forces you to run them.

To me, the most important thing is that failures should be a result of changes in the current PR.  Having local tests that are stricter than CI tests makes it more likely that someone will bypass the local checks and break subsequent pushes.  The well behaved developer who actually runs the tests locally then has the awkward choice between raising a separate PR to fix the previous break, bundling the unrelated fixes with the current PR, or bypassing local tests.  The developer who broke the local tests doesn't see the consequences.


Bundle Visit into Flatpak or Appimage for installation.

Is your feature request related to a problem?
I've been having problems getting the application installed on modern distributions such as RHEL 9.
Is your feature request specific to a data set?
No
Describe the solution you'd like.
Because either building the application or attempting to install the software fails, I would like to see the application rolled into a platform independent Flatpak or Appimage to make end user and technician installation experience faster.
Describe alternatives you've considered.
RPM or DEB compiles may lead to dependency conflicts with the operating system. Flatpaks and Appimage would contain everything you need to run without that concern.
Additional context
Ideally, this would be the best overall option for future application deployment. :smile_cat:

@ldod-lle can you share what you tried and failed at?
We provide binaries for a range of linux distributions, but we haven't had the resources to provide variants of VisIt for the various package managers that span the linux eco system.
I'll also say we haven't quite wrapped our heads around recent rhel changes and how the new relationships between rhel and other distros work.
We do have access to rhel systems, but haven't had good luck with the new rhel related containers (ubi?). Building our linux binary releases with containers is the most tractable way to provide them.

Sure!
I was attempting to do an install here at LLE under a RHEL 9.3 system, but did not make a lot of progress. I tried both the install and build scripts, but both crashed at some point along the way. The build script seems to be pulling down an older build environment than what is already present on the system. (ie: python3-3.9.18-1.el9_3.1.x86_64).
I was mainly floating a trial balloon in lieu of trying to compile or install and having errors. Appimage and Flatpak are two similar paths, but there are also Docker and Podman routes to take to have the environment bundled together for easier distribution. The app would also benefit from running in a sandboxed environment and you would not have to deal with any dependency conflicts.
The OpenSuse folks have a builder located here: https://en.opensuse.org/openSUSE:Build_Service_AppImage_builds
Thanks for your quick response. :grin:

@ldod-lle
If you have log files of where things failed, we may be able to help.
The build script (build_visit) builds specific versions of our dependencies for stability. We test across a range of systems and packages binaries with these dependencies.
If there is some way we can translate the binary outputs into a flatpak or appimage, that might be the best way to close the gap here.


Windows usage, can it be?

Can i use this script on windows 11? And how?

Unfortunately no, as it uses linux device subsystem and uinput lib to communicate with DJI RC.
For windows take a look at https://github.com/hjstn/miniDjiController it uses pyvjoy library instead.
In case you would like to make DJI Mini 2 RC work with windows you can use CRCs from my code but change the part which communicates with the device to be windows friendly.
Hope this helps.


FLUID-5943: tutorial for a minimal footprint prefs editor

Discusses using the full page prefs editor with lazy loading of the settings store and page enhancer.
https://issues.fluidproject.org/browse/FLUID-5943

@colinbdclark could you please review the documentation?

@amb26 i addressed some of your comments and have left some further questions for you as well. Thanks.

Example code supplied in PR https://github.com/fluid-project/infusion/pull/789 to Infusion

@amb26 ready for more review

@amb26 ready for more review.


Add contributor

- Summary
Add contributor
- Test plan
N/A
- Description for the changelog
Add contributor

Deploy preview for netlify-cms-www ready!
Built with commit<PHONE_NUMBER>bbf5d9549b531313df7e0f66bc8e01
https://deploy-preview-1233--netlify-cms-www.netlify.com

Deploy preview for cms-demo ready!
Built with commit<PHONE_NUMBER>bbf5d9549b531313df7e0f66bc8e01
https://deploy-preview-1233--cms-demo.netlify.com


NIFI-6076 syslog5424 should support missing MSG

This issue is fixed in new simple-syslog-5424 v. 0.0.10
For all changes:

[x] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?

[x] Does your PR title start with NIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

[x] Has your PR been rebased against the latest commit within the target branch (typically master)?

[x] Is your initial contribution a single, squashed commit?

For code changes:

[x] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder?
[x] Have you written or updated unit tests to verify your changes?
[x] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[-] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly?
[-] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly?
[-] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties?

For documentation related changes:

[-] Have you ensured that format looks appropriate for the output in which it is rendered?

Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.

I don't mind merging this since it looks fine, but just out of curiosity, I ran the unit test that was added while still on the 0.0.8 dependency and it passed. Shouldn't that fail on 0.0.8 and pass on 0.0.10?

Please hold the merge and let me look at it.  In the jira I linked to the upstream issue, where I was able to reproduce the error.  Maybe I messed up moving the test over. If you are curious about the fix, I can provide a link to the upstream fix.

Please hold the merge and let me look at it.  In the jira I linked to the upstream issue, where I was able to reproduce the error.  Maybe I messed up moving the test over. If you are curious about the fix, I can provide a link to the upstream fix.

@bbende thanks for checking.  The issue I fixed is with the grammar.  It 'fails' in a different way depending on the structure of the message.  In the test I added, it logically fails.  The second structured data ends up being the message body, but the event is valid.
That is because there are two structured messages.
If there where one structured message, then it would fail parse with a missing space.
I need to add better tests.  Explicit tests.  I will do so and update.  Hope that makes sense, if you look at what I fixed in the grammar it should.

I'm going to close this pr while I work this out.

@bbende ok, I had more work to do upstream, thanks for the look.  Better tests, should be all set.

@ottobackwards thanks! looks good, going to merge


Is there a way to do INSERT INTO ... SELECT?

INSERT INTO orders (user_id, email)
SELECT user_id<EMAIL_ADDRESS>FROM   users as u
WHERE  u.username = 'jdoe'

This works, though it's not exactly the sql above:
const qb = knex.from('orders')
  .insert(function() {
    this.from('users as u')
      .where('u.username', 'jdoe')
      .select('user_id'<EMAIL_ADDRESS>AS email')
      .select('user_id', knex.raw('? AS ??'<EMAIL_ADDRESS>'email']))
  });
console.log(qb..toString()

Produces the following (newlines added for clarity, MySQL Dialect):
insert into `orders`
select `user_id`<EMAIL_ADDRESS>AS `email`
  from `users` as `u`
 where `u`.`username` = 'jdoe'

Wow! Is that officially supported? I could find it in the docs anywhere (that I could send a function into insert()).
In any case, it's not quite working for me. I am using postgres, and if I don't specify the column names in the INSERT lines, then postgres expects me to send ALL columns in the SELECT clause - in the correct sequence.  Just using the AS to name the column does not cut it :-(. My table has many nullable columns that I don't want to specify at the time of insertion.

The best I could come up with for explicitly putting columns is using knex.raw in the top level from clause:
const qb = knex.from(knex.raw('?? (??, ??)', ['orders', 'user_id', 'email']))
  .insert(function() {
    this.from('users AS u')
      .where('u.username', 'jdoe')
      .select('user_id', knex.raw('? AS ??'<EMAIL_ADDRESS>'email']))
   });
console.log(qb.toString());

Output (this time, Postgres)
insert into "orders" ("user_id", "email")
select "user_id"<EMAIL_ADDRESS>AS "email"
  from "users" as "u"
 where "u"."username" = 'jdoe'

Thanks, @chrisbroome. While this works, it's becoming practically unreadable. At this point, I am going with a raw query using knex.raw(). This would be a good enhancement to consider for the future.
I am closing this issue for now, but feel free to comment if you have a better solution.

Still have 2 questions

Where is this documented knex.insert(function() {} shouldn't this be async?
The solution offered is readability nightmare :( whole point of me using knex was to make things readable..


cmd/server: add initial HTTP server and Docker image

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@a1d633d). Click here to learn what that means.
The diff coverage is 20.42%.

@@            Coverage Diff            @@
##             master       #2   +/-   ##
=========================================
  Coverage          ?   20.42%
=========================================
  Files             ?        3
  Lines             ?      142
  Branches          ?        0
=========================================
  Hits              ?       29
  Misses            ?      110
  Partials          ?        3