[FLINK-18536][kinesis] Adding enhanced fan-out related configurations.

What is the purpose of the change
This is the fifth milestone of FLIP-128 to add EFO support to the FlinkKinesisConsumer. The EFO related configurations has been introduced.
This change should not introduce any functional differences.
Brief change log

ConsumerConfigConstants

Add several efo related configuration constants

KinesisConfigUtil

Add the validation of efo related configuration constants.

KinesisProxy

Add fields about operations like registerStream, deregisterStream, listStream
Give initial value to those fields.

FanOutProperties

Add a new configuration class for the future FanOutRecordPublisher
Validate fields and give them initial values

FlinkKinesisConsumer

Since the change of the validation interface, modify the call of validation method.

Verifying this change
This change added tests and can be verified as follows:

KinesisConfigUtilTest
FanOutPropertiesTest

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): no
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn/Mesos, ZooKeeper: no
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? no
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

@xiaolong-sn can you please either squash and repush or update your commit messages as per "Commit your changes to your local git repository. The commit message should point to the corresponding Jira issue by starting with [FLINK-XXXX]."

@flinkbot run azure

@xiaolong-sn can you please either squash and repush or update your commit messages as per "The commit message should point to the corresponding Jira issue by starting with [FLINK-XXXX]."

Thanks, I've squash all changes into one commit.

@flinkbot run azure

@tzulitai ready for your review. Thanks.

I lost my fork on the code so I reopen a new PR.


A way to request documentation from LSP server

Is there a way to send a request that would return doxygen/pydoc/java doc parsed documentatioin?
Libclang (C-family), jedi (python), racer (rust), tern (javascript) and probably others already provide ways to parse comments and return formated documentation (if available). Would be great if LSP supported this as well.

public interface MathOperation {
  /**
   * Returns the result of adding the two integers together.
   * @param x the first value
   * @param y the second value
   * @return the sum of the two integers
   */
  public int add(int x, int y);
}

@bstaletic So you mean if your mouse hovered over the string add, the editor that you are using (a language client that supported the language server protocol) would provide a hover tooltip that contains the parsed Javadoc documentation in a readable format without the @param and @return tags?

@rcjsuen Thanks for taking the time to respond.
Yes, the tooltip with a parsed javadoc in a readable format is what I'm looking for.

@bstaletic It sounds like the language server just needs to support a textDocument/hover request at that given position then. It would then satisfy the exact requirement that my comment describes.
Or did you have something else in mind?

So textDocument/hover does support parsing javadoc? That wasn't clear to me. I'm actually helping in developing a LSP client. Thanks for the clarification.
Now I'd like to ask a slightly different question. What's the best way to get just the type of the variable from the server? I initially used hover to request for getting the type. Is there a way to easily get two distinct respinses (type and doc)? Or will I have to parse the response I get from hover response?

So textDocument/hover does support parsing javadoc?

@bstaletic Uh, that's really up to the language server. The language server the client is connected to may or may not parse the comments defined above a function/method/member/whatever. The client just sends a textDocument/hover request to say "tell me what I should write in a hover tooltip at this location" and then the language server may say "this is a function with no parameters and returns a boolean" or it might just return the empty string. It may even tell you the type of the variable. The content of what a language server is "supposed" to return is not spec'd. Thus, language clients can't really "parse" the response as the returned string can be anything.
You could perhaps use textDocument/definition and or textDocument/documentSymbol to figure out what the type of a variable is but your mileage may vary here.

Okay, thanks again for taking the time to respond and help me
I'll close tge issue now, as there really is no issue here.


Can't see object remarks table in Vascular Plants or Entomology (or anywhere)

NHMDenmark/Mass-Digitizer#220

Surely this is "object remarks field"

I have some recollection the discussion of adding notes to the remarks field in a tabular fashion.

Ah, it's all described in #220
It's here:


ci: Change Kolibri wheel URL

The wheel file was removed from buildkite.com, so we uploaded it to our kolibri-explore-release github release.
https://github.com/endlessm/kolibri-installer-android/pull/115/commits/e4a7709cce54260381c44e8f252564a05994e2c2

Seems to build!


Can we get the model.chgCoeff function?

https://www.gurobi.com/documentation/9.0/refman/py_model_chgcoeff.html
This is extremely useful for column generation.

Hi. You are probably looking for Model::set_coeff. Please be aware that  #46 has not yet been published, so I recommend you use the version from git to get that bug fix.


Is it possible to work wrap value of a dictionary variable key?

I would like to word wrap the value of a key while declaring dictionary variable in variable table. Is it somehow possible?
For Ex: Something like below (This is giving error)
*** Variables ***
&{Parameter_Values}
...    url=https://api/getnumberrange/sap/?format=xml
...    verify=False
...    message=<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
...  soapenv:Header/
...  soapenv:Bodyain:NumberRangeRequestMessage
...  WDSTCK_TEST
...  X
...  </ain:NumberRangeRequestMessage></soapenv:Body></soapenv:Envelope>

Closing this because I don't understand the question and question in general belong to robotframework-users mailing list, Slack, or other such support forums listed at http://robotframework.org. This tracker is for bug reports and enhancement requests.


file path for webpack  base on process.cwd

What's the problem this PR addresses?
fork-ts-checker-webpack-plugin output error file path for webpack base on complie context, not base on root.when error in vscode console,ite can opened the file because wrong relative file path.
How did you fix it?
output formatter error file path for webpack base on process.cwd()
relate issue:https://github.com/TypeStrong/fork-ts-checker-webpack-plugin/issues/509

We are still using context for async: false mode. Please take a look at https://github.com/TypeStrong/fork-ts-checker-webpack-plugin/blob/master/src/issue/IssueWebpackError.ts. That's done that way because, in async: false mode, we add errors to the compilation instead of outputing it directly to the console. Would be nice to modify one e2e test to use different path than webpack's context (I would not add new one as it already takes long time to run all tests).

I'm sorry I' m inexperienced in testing,I really don't know  what to do,would you please give me some help.

Sorry for the late response. In the tests/e2e directory, we have test files for end-to-end tests.
They use jest as a test runner and our custom ’sandbox’ code.
The workflow that the sandbox code executes is:

Creates a temporary directory (sandbox) and copy files described in the fixture directory.
Runs ’npm install’ command
Runs ’webpack-dev-server’ and checks the output of the command

What you have to do is modify one of these tests to have that case when the context is different than process.cwd :) Let me know if you have more questions :)

I'm closing this PR - will be merged from #524


NP-2498 Dont expect top level names for plugins and outputs

This is to fix https://github.com/NorthPage/telegraf-cookbook/pull/9

Maybe this should bump the cookbook version to 0.2.0 as it would break backward compatibility if you currently have outputs/plugins attributes set.

Good idea, I'll do that.

:+1:


ValueChangeMode and clear button

Hi,
the SuperBigDecimalField is really good and handy.
Any change to support ValueChangeMode and clear button?

hello @weiliang2 - thank you for using my components and apologies for the delay
sure, it is possible for both features to be supported (I have no idea how come I missed them) - I think I might have time to do it still today and then it would be available with the next release (which is scheduled to be this month)

alright, so now I know why I have not implemented it: triggering value change events every time a change happens in the text field causes the grouping separator to be shown - and this is to support typing numbers without them being automatically reformatted
so, I need to find a workaround for that first

it also looks that implementing this will change the behaviour of set(Minimum|Maximum)FractionDigits to destructive and I am ok with that, unless I find an elegant workaround

behaviour change: calling set(Minimum|Maximum)(Fraction|Integer)Digits is now destructive
number fields implement HasValueChangeMode
created HasClearButton and added it to number fields, SuperTextField and SuperTextArea

hello,
actually setMaximumFractionDigits is also very important. What is a workaround for this?

@weiliang2 currently there is none, but I can start digging into the issue - see #339
I believe I can make it work ;)


Add RFC for batchnorm1d optim

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Clarify NSM semantics on function-typed fields in strong mode

The following exposes a tricky case for supporting old NSM semantics in strong mode:
class Mock {
  noSuchMethod(Invocation i) {
    return () => 32;
  }
}

class Foo {
  int Function() f;
  String g() => "hello";
}

class Bar extends Mock implements Foo {
}

void baz(Foo foo) {
  print(foo.f);
  print(foo.f());
  print(foo.g());
}

void main() {
  baz(new Bar());
}

DDC prints (and throws on the last print):
Closure: () -> int from: () => 32
32

/Users/vsm/dart/sdk/pkg/dev_compiler/lib/js/common/dart_sdk.js:9895
          throw e;
          ^
Type '() -> int' is not a subtype of type 'String'

The VM in checked mode (dart2js is similar):
Closure: () => dynamic
Closure: () => dynamic
Closure: () => dynamic

I'd like to propose going forward with the current DDC behavior.  It is much easier to implement in an AOT setting without regressing regular calling conventions.
DDC is able to generate the following for baz:
mockfield.baz = function(foo) {
  core.print(foo.f);
  core.print(foo.f());
  core.print(foo.g());
};

by statically generating trampolines in Bar that forward to NSM and type check the result:
mockfield.Bar = class Bar extends mockfield.Mock {
  g(...args) {
    return core.String._check(this.noSuchMethod(new dart.InvocationImpl.new('g', args, {isMethod: true})));
  }
  get f() {
    return VoidToint()._check(this.noSuchMethod(new dart.InvocationImpl.new('f', [], {isGetter: true})));
  }
  set f(args) {
    return dart.void._check(this.noSuchMethod(new dart.InvocationImpl.new('f', [args], {isSetter: true})));
  }
};

The DDC behavior is the intended strong mode behavior.  I would propose that we spec it as the Dart 2.0 behavior.
@lrhn @eernstg @munificent @floitschG

I'm fine with the DDC behavior. Over the long term, I think this highlights that "no such method" isn't the right primitive for Dart and that "no such property" is a better fit.

I'm fine with the DDC behavior too, at least something close to what I think it's doing.
We'll have to nail down the behavior for any call and any declarations, and decide on what happens with invalid invocations. Will noSuchMethod get called if you call foo.g(42) above? What if you implement two interfaces with different signatures for the same member? Etc.
All in all, I wouldn't mind if the rule is: noSuchMethod only get called for interface members with valid arguments (which will likely include type-checking). In all other cases, it'll just throw directly, you don't get to implement something that isn't part of your class' actual signature.
In short, it must be implementable by adding correctly-typed implementations of missing members which forward to noSuchMethod when called. No other invocations of noSuchMethod is possible.
That means that the following will actually hit noSuchMethod in Dart 2:
class C {
  foo(int x) { print("Yes!"); }
  noSuchMethod(i) { print("No!"); }
}
abstract class D { foo(int x, [int y]); }
class E extends C implements D {}
main() {
  new E().foo();  // prints No!
}

(there are likely other cases that we'll have to account for).

The semantics would be as follows: For a class C declaring or inheriting a noSuchMethod implementation distinct from the one declared in Object, a forwarding member is generated for each member which is declared but not implemented; for a getter/setter/method the forwarding member is a getter/setter/method respectively, and the signature of the forwarder is the signature of the declared but unimplemented member. (There may be conflicts, but that's discussed below.)
With that, the behavior of statically checked member invocations just falls out: Every statically checked member invocation will match a forwarder, both in the sense that it is a getter if a getter is expected, etc., and for methods that the given argument list will be supported by that forwarder method. We don't even have to teach developers to handle tear-offs separately, because a tear-off of a method (statically) will be an actual tear-off of a generated forwarder.
The basic rule could be that noSuchMethod may be invoked from these generated forwarding members (no magic here: developers could just as well have written those forwarders themselves, and they just call noSuchMethod explicitly), and noSuchMethod is never invoked in any other situation.
It makes sense to have this semantics for statically checked invocations.
However, for dynamic invocations it falls short. In particular, it does not support an open-ended set of (emulated) members, and it does not support abstracting over different shapes of argument lists. Actually, the most important problem may be that the resulting semantics of dynamic invocations will be complex and conceptually ill-motivated.
Ideally, the semantics for dynamic invocations should amount to checking whether a given receiver contains a member that admits the given invocation, and invoking noSuchMethod when that is not the case (both when the requested member is and when it isn't declared in the type of the receiver, and when the name is there but the argument list does not fit).
That would give dynamic invocations a semantics which preserves a larger portion of the expressive power normally associated with noSuchMethod. Crucially, the semantics for statically checked invocations falls out as a special case of the dynamic behavior, so we have a consistent model. It just happens to be a correct simplification & optimization to use forwarders in the statically checked case, because we know positively at compile-time that the member exists and the argument list fits.
Finally, one thing that the forwarder based approach does not handle is the ability to support types that conflict. E.g., forwarders will not enable using noSuchMethod to implement types that require both a foo([int, int]) and a foo({String x}), and even with a potential extension of Dart to enable both kinds of optional arguments in the same signature we might have other conflicts (e.g., we may need to have both int get foo and int foo()). Such conflicts would in fact be supported by a dynamic semantics as proposed.
For static invocations, we would actually be able to detect that a given type offers a conflicting set of declarations for a given member name (if our type system even allows us to express and use such types, including the ability to even declare a class Mock implements Foo, Bar .. where Foo and Bar have a conflict). If so, when we know that a conflicting invocation is requested, we may choose to check that the invocation matches one of the declared signatures and then we may perform the invocation dynamically (maybe we can even prove that this could never be implemented as anything other than noSuchMethod, and call that directly).
In any case, the main point is that it would be both natural and helpful to give dynamic invocations a more complete semantics, and I do not think it will cause any performance degradation for the static cases.

We'll have to nail down the behavior for any call and any declarations, and decide on what happens with invalid invocations. Will noSuchMethod get called if you call foo.g(42) above?

If the static type of foo is Foo, then it'd be a static error.  If dynamic, a noSuchMethod (but that would go through a runtime helper, not the trampoline).
FWIW, when we extend and implement methods with slightly different signatures from multiple types, DDC often has to generate static trampolines - e.g., to inject the right covariance checks.  E.g., this throws a runtime error in C.foo - a trampoline with a runtime check before forwarding to super.foo.
abstract class A<T> {
  void foo(T x);
}

class B {
  void foo(String x) {
    print('hello ' + x);
  }
}

class C extends B implements A<String> {
}

void main() {
  A<Object> a = new C();
  a.foo(42);
}

That said, @lrhn 's example is a static error today:
[error] Base class introduces an invalid override. The type of 'C.foo' ('(int) → dynamic') isn't a subtype of 'D.foo' ('(int, [int]) → dynamic').

@eernstg - in the original example, if we change foo in baz to be dynamic, I presume the semantics would be the same as the static case?

if we change foo in baz to be dynamic, I presume the semantics would be the same as the static case?

The first thing to note is that Bar will have generated forwarding members corresponding to its declared type. Assuming an actual argument of type Bar,

the invocation foo.f would be a dynamic invocation that finds the generated forwarding getter corresponding to Foo.f and yields the closure of () => 32 which successfully passes the return type check (if we make sure that => function literals have a reified type which matches their static type, which is unclear in the current spec);

foo.f() would dynamically fail to find a method f, and it would then attempt to invoke a getter f, which leads to noSuchMethod which yields the same closure, which is called, yielding 32;

foo.g() would dynamically invoke the forwarding method g and fail to satisfy the String constraint on the value returned from noSuchMethod.

We could consider avoiding the invocations of forwarding methods in the dynamic case, but I think that would make the semantics more complex (e.g., because we wouldn't get the type checks on the returned results that static checks would incur). It's a reasonably understandable semantics that noSuchMethod will give you these forwarders, and then we just perform dynamic invocations in a manner that includes them.

Lasse's example illustrates one more thing we need to take into account:
class C {
  foo(int x) { print("Yes!"); }
  noSuchMethod(i) { print("No!"); }
}
abstract class D { foo(int x, [int y]); }
class E extends C implements D {}
main() {
  new E().foo();  // prints No!
}

The semantics should ensure that an invocation of a method which is actually implemented by the receiver must go to that implementation, not to noSuchMethod.
This means that if we generate a forwarder for foo in E such that the required interface is actually implemented, and if that forwarder overrides an existing implementation, then invocations which may call that implementation must call that implementation:
class E extends C implements D {
  // Generated forwarder.
  foo(int x, [int y]) {
    if (/* exactly one argument was passed */) {
      return super.foo(x);
    } else {
      return noSuchMethod(new Invocation.inventingAnAccessibleConstructor(
          memberName: #foo, positionalArguments: [x, y], isMethod: true));
    }
  }
}

An 'intent to implement' issue has now been created for the language design which was specified in the informal specification of the feature arising from the discussions that took place in this issue as well as elsewhere. I've referred to this issue as background material in #31426. Closing.


Test to see what pubsub message was sent

What and why?
Just testing
How to test?
Trello

/deploy scorfs


Add a helm chart

A first stab at a working helm chart
fixes #216
Signed-off-by: Jon Whitcraft<EMAIL_ADDRESS>

This is just amazing Jon! Thank you very much for the contribution. I'm merging your PR now 😀


1Password 8 / My Passwords error: The "file" argument must be of type string. Received undefined

Extension
https://www.raycast.com/khasbilegt/1password
Description
I'm running the latest MacOS + 1Password 8 version. When I try to access the My Passwords command I get the following Javascript error: 'The "file" argument must be of type string. Received undefined'. Maybe interesting to mention, I installed 1Password via Homebrew.

Steps To Reproduce

Lastest MacOS version
Latest 1 Password 8 version
Latest Raycast version
Open My Passwords

Current Behaviour
Gets the following Javascript error: 'The "file" argument must be of type string. Received undefined'.
Expected Behaviour
Should open the 1Password items

Same here

When you guys run "where op" on your terminal, what is the response?

@Luk4h I get 'op not found'.

same here

That should mean that you don't have the 1Password CLI installed correctly guys. You probably should check on how to install that. It is on the 1Password app settings. You can also refer to the guide on the description of the extension

Installed 1Password CLI also and it works now. Thanks for the great support.

Hello, I was facing the same problem, and I followed the steps. However, every time I authorize it gives me this error (• Unexpected end of JSON input). Can anyone help?

Could you open a new issue describing and giving a step by step? It will be easier for us to help you.
Also I recommend to try using the command in your terminal! For example if you are trying to retrieve the password for item named GitHub, run the following command on your terminal: ’op item get GitHub’. And see what it returns.


Rector

Q
A

Bug fix?
N

New feature?
N

BC breaks?
N

Deprecations?
N

Fixed tickets
cleaning up dead code with rector #no-ticket

Configuration for rector. Applied with dead code removal on the /src/Command directory.
TODO

[x] adapt services.yml for cleaned Command constructors
[x] double check that removed Command constants are not used by our other bundles

Ready to merge. Other folders will be checked and committed on another branch.


Pay branch

Support for Amazon Pay Connection Request Directives and Connection Responses.

Hey, any reason why you closed this aside from the creator being MIA?


ESlint changes

My fight with and against git is finally over.
I'm sorry for the inconvenience.
Changes:

Removed comma‑dangle rule for now. We can always make a PR to change this after we get ESLint.
Single quotes rule for language definitions.
Removed commented out indent rule.

Merged locally as https://github.com/PrismJS/prism/pull/1796/commits/6aa1a16c9cdff6c693d500d97964f5cd3172e8d2.


Icons are missing ?

Bug Report
Steps
<Container>
  <List>
       <Icon color="red" name="users" />

User

       <List.Item color="pink" icon="check">

Check

       </List.Item>
   </List>
</Container>

Codesandbox example also does not show icons
https://codesandbox.io/s/vibrant-jennings-lzz2h
Expected Result
Icons should appear automatically
Actual Result
Icons missing ????? showing square box placeholder
Version
0.88.1
Testcase
https://codesandbox.io/s/vibrant-jennings-lzz2h

@levithomason @jlukic

You forgot to include the semantic-ui-css files.

Thanks @MiceXx
@DouggyC I am going to go ahead and close this based on the above solution.

I found that the icon tag was begin over written by font-family

@DouggyC what is the CSS rule that was overriding the font-family property? Was it a class in your project coming from other CSS? This sounds like a CSS specificity issue and not related to SUIR or SUI.

@brianespinosa @MiceXx I'm having the same problems that @DouggyC  was having. If you click on DouggyC's codesandbox above it's a pretty good use case of how I imaging many people are using semantic ui react, and the icons are not showing. If you comment out the document.createElement("link") bit it will work, but that sure shouldn't be necessary. Is there another way to fix this?

@scottsandersdev it is just one use case. If an icon is not present, it means that icon is not present in the font that the CSS you are using is pointing to. This could be an issue with:

The version of the CSS you are using in your project has an older version of FontAwesome
Your toolchain is not configured correctly to handle a font
Lots of other toolchain bundler issues (missing loaders, bad configurations)
Incorrect file path to the font files
Missing font files

All of the above items are not anything we have control over in SUIR. If anyone has an issue with missing icons and you're doing something outside of the recommended steps, it is completely possible to get things working... but based on the permutations of what might be going on in all of these other scenarios, we can't really cover everything here.
All SUIR does from a styling perspective is let you specify props which will generate the correct classnames and markup structure for compiled CSS to work.
If you want to ask a question on StackOverflow about how to get this working, I am happy to help there. Please include information about your toolchain configuration and versions of SUIR and CSS being used.

Exactly the same issue I'm having here. If I load css this way,
import "semantic-ui-css/semantic.min.css";  //"semantic-ui-css": "^2.4.1",
Icon is not showing
If I load css this way:
styleLink.href =
"https://cdn.jsdelivr.net/npm/semantic-ui/dist/semantic.min.css";
Icon is showing
Shouldn't they be the same?

@dawei-dai-exa not necessarily.
Look at the CDN you are getting the CSS from. Where does the @font-face declaration say the path is for the font files? There is no guarantee that the CSS has the same path for everyone, as it is configurable from SUIR's build tools. Some CDNs might have set their compile of CSS up to also distribute the font files via CDN instead of locally.
The CDN you are using is expecting those font files to be local:
@font-face{font-family:Icons;src:url(themes/default/assets/fonts/icons.eot);src:url(themes/default/assets/fonts/icons.eot?#iefix)

So, if you don't have font files at that path, then they will not work.
Again... these are all variables that are inconsistent, not within our control, and for code that does not exist in the Semantic UI React repository.

There wasn't enough information in any of the SUIR docs for me to understand why this issue was occurring when locally importing the minified CSS.
The problem is when importing the CSS locally, any icon paths will try to resolve locally too, but relative to where semantic-ui-css is installed - and since they live in node_modules and not in your public folder, http://yourdomain/themes/default/assets/fonts/icons.woff2 doesn't point anywhere and therefore fails to load anything. This is avoided by using the CDN instead since they resolve URLs instead of local file paths, but if you want it to be bundled with your app, this isn't really a solution.
My solution was to copy the entire themes folder from node_modules/semantic-ui-css into the app's public folder, the one used for static assets. That way all paths resolve. This adds about 2MB to the app's payload though! This seems to be more or less in line with manually installing Font Awesome via NPM (although since they use a different folder structure and file names, this wouldn't work).
If anyone has found a less clunky way to use SUIR FA icons locally, I'm all ears.


Sync debugger-frontend to latest 0.76-stable (fix Expo node_modules entry points in Sources panel)

Summary
Includes https://github.com/facebookexperimental/rn-chrome-devtools-frontend/pull/135, which fixes Expo compatibility in React Native DevTools. (Credit: @byCedric)

Changelog:
[General][Fixed] - Fix a file exclude issue in React Native DevTools where Expo projects were not visible in the Sources panel
Test Plan:
See https://github.com/facebookexperimental/rn-chrome-devtools-frontend/pull/135.

@blakef Subsequent fix around previous Local Storage state now incorporated in last push: https://github.com/facebookexperimental/rn-chrome-devtools-frontend/pull/137. Safe to merge.


Handle non-strings in JSON

Fixes #368

@michaeljoseph I think the build failures in py27 and pypy are outside of my changes.

Ah yes, the dreaded unicode exceptions in 2.7. After work I'll take a look at it.

@michaeljoseph @pydanny It's passing with py27 now. There was a "bad md5 hash" while installing dependencies for pypy? https://travis-ci.org/audreyr/cookiecutter/jobs/47559696#L123

$ tox -e pypy passed for me locally.

Let me know if that's not your preferred method for disabling a flake8 warning.

@michaeljoseph Anything else?

@jacebrowning looks good!
:cake: :+1:
cc: @pydanny

:+1:

Just released on PyPI: https://pypi.python.org/pypi/cookiecutter/0.9.1
Please test manually! I need a confirmation it's all good before I announce it publicly.

@pydanny Passes locally and on Travis: https://travis-ci.org/jacebrowning/template-python/builds/47704251

Thanks @jacebrowning. Excellent! :birthday:


Whitespace gets prepended on load/display

I love the functionality of this editor.  However, whenever it loads some text it inserts spaces.

This is what the string looks like before it is loaded the first time:

"# Intro\nThis text should not be indented. It does not have any spaces in front of it but it shows up with 16 spaces every time it gets loaded.\n\nThen, if I save this text and load it again in the editor it gets 16 more spaces prepended."

I can't find a configuration setting to address this issue. What am I doing wrong?

I have the same problem. This is royally annoying and completely breaks formatting.

I receive the same issue with NodeJS and Handlebars. The source code shows non-character whitespace within the <textarea> tags and within the developer console, <pre class=" CodeMirror-line"> for both line breaks and text, which is causing the markdown to appear as code rather than the markdown formatting applied to the string. Any way to prevent this behavior with the Simplemde options?

Just by chance, are you using this inside a Rails app with HAML?

Yep. That was the problem. The find_and_preserve operator ~ worked perfectly. Thanks @technodrome!

I have the same issue, I have also posted it here. So if I understand correct I need to replace the textarea that has simplemde ie = f.input with ~ f.input, correct?

@Lykos22 yes. that worked for me.


Add list statistics

I was thinking it would be nice to have a couple of simple stats on the list page:

% of banned players
% of VAC bans out of banned players vs % of OW bans out of banned players
Average time between addition to list and ban (only counts banned players obviously)
Average "tracked by" column separately for banned and not banned players (don't know what to call this)

EDIT: Would also be interesting to have these stats site-wide somewhere

No love for this idea? :(


Add a setting to enable/disable the Test Explorer Integration

This change addresses item #3145
This changes our integration with the Test Explorer.
The following changes are proposed:

Add a setting that allows users to enable or disable our integration with the Test Explorer.
This keeps the ability to run tests, however, the integration with the Test Explorer should now be allowed to be disabled.

If we disable it, it automatically revokes the integration:

We are still able to run tests without the integration:

does this need docs updates?

does this need docs updates?

Good call, I'll check now if there are any docs that talk about the Test Explorer, and make sure I update them.


provides a summary description for pip

doing like in https://github.com/jupyter-server/jupyter_server/blob/main/pyproject.toml

Thank you!


Style1 to patternfly conversion in Requests

Parent issue: #3139
Before:

After:

@epwinchell please review

@PanSpagetka please update your PR as is described in #4197

Updated, @epwinchell @skateman please review

LGTM


Add natural keys to user roles and permissions

LGTM! Is there a migration needed when you add the natural key methods?

LGTM! Is there a migration needed when you add the natural key methods?

We do not. Only on the Pluto API side!


Changed Taipei URL and Title

Since Linker and ITRI will work together to deliver this Meetup.
Just changed relevantly.  Thanks.

Sorry for last URL. We changed to local TW URL. Thanks.

Guys, Could you please help us merge to master branch? thanks.

@jmanalus  could you please help me merge this update. appreciated.

@ashenden can you merge this for @usultrared ?


TS2304: Cannot find name 'Sortable'.

Getting these errors when trying to build my project
node_modules/react-sortablejs/dist/index.d.ts:27:40 - error TS2304: Cannot find name 'Sortable'.

27     setList: (newState: T[], sortable: Sortable | null, store: Store) => void;
                                          ~~~~~~~~

node_modules/react-sortablejs/dist/index.d.ts:61:104 - error TS2304: Cannot find name 'Sortable'.

61 export type ReactSortableOptions = Partial<Record<AllMethodsExceptMove, (evt: SortableEvent, sortable: Sortable | null, store: Store) => void>> & {
                                                                                ~~~~~~~~

node_modules/react-sortablejs/dist/index.d.ts:69:63 - error TS2304: Cannot find name 'Sortable'.

69     onMove?: (evt: MoveEvent, originalEvent: Event, sortable: Sortable | null, store: Store) => boolean | -1 | 1 | void;

yarn.lock has these versions:
"<EMAIL_ADDRESS>  version "1.10.6"
<EMAIL_ADDRESS>  version "6.0.0"
<EMAIL_ADDRESS>  version "1.12.0"

Does setting skipLibCheck: false or other skip* settings fix this?

Using skipLibCheck does allow it to run, but so does adding Sortable to the import in dist/index.d.ts, which is already importing other things from sortablejs.
- import { MoveEvent, Options, SortableEvent } from "sortablejs";
+ import Sortable, { MoveEvent, Options, SortableEvent } from "sortablejs";

This seems preferable. How does that file get built?

At first glance, it looks like it should already be included here. ❓

That's what I found as well...not sure why that import doesn't end up in the compiled definitions file.

At first glance, it looks like it should already be included here. ❓

I wonder if this is the same underlying issue from Parcel: https://github.com/parcel-bundler/parcel/issues/4250
What was the reason for switching to Parcel for building this library? At least the Parcel-2 beta doesn't quite seem ready

Is that issue going to be resolved? It prevents me from publishing app, and I don't want to use skips

Use<EMAIL_ADDRESS>to build can resolve this problem.


[FEATURE] {{ dl stepper }} - {{ dynamic CTA button & footer hidden}}

Hide the footer in case of empty states.

The stepper usually shows several related steps, and the user presses one main call-to-action button at the end.
There are cases where the steps are stand-alone (unrelated). It means that each step has its own call-to-action button.
2. Therefore, we need the ability for each step to have a different call-to-action. (see recording)
https://github.com/dataloop-ai/components/assets/121247551/ae99b4a5-2230-44b7-a5a2-535c8bc1735d

@guyDataloop there is a huge stepper ticket #793 that has detailed stepper specs - seems it should supersede this one

@makc-dataloop in order for us to develop this without the full rework that is suggested in #793 we can simply add a slot that would be dynamically set based if the step has it or not.
I believe thats the simplest way to go about it, let me know what you think


Refactor entity manager

Changes:

multiple name changes
implemented a bunch of new functions
refactored existent functions

Storage:

implemented add, set, emplace
implemented tryGet
refactored set, remove
renamedhas to contains
renamed removeAll to clear
removed removeIfHas

StorageInfo:

renamed removeAll to clear
renamed has to contains
removed removeIfHas

EntityManager

renamed entityBuilder to entity
renamed discard to destroyEntity
renamed has to valid
renamed remove to removeComponent
renamed removeAll to clear and removeAllComponents
renamed get to getComponent
refactored entityBuilder
refactored fabricate and recycle, this functions are now createEntity, generateId, recycleId
refactored destroyEntity
refactored set
refactored removeComponent
refactored clear
implemented releaseId
implemented addComponent, setComponent, emplaceComponent
implemented releaseEntity
implemented shallowEntity
implemented aliveEntities
implemented tryGetComponent
implemented registerComponent
removed MaximumEntitiesReachedException
removed gen
removed removeIfHas

EntityBuilder

implemented add, set, emplace, remove, removeAll, destroy

The majority of this PR focuses on improving code readability and comprehension. Some of the changes can are demonstrated below:
auto world = new EntityManager();

// components can now be registered
with (world) {
	registerComponent!int;
	registerComponent!(byte, string); // multiple components allowed
}

// entity builder is now much more useful
auto entity = world.entity
	.add!int // add an init state component
	.emplace!string("Hello Entity") // construct directly into the component array
	.set(64u)
	.remove!int
	.remove!(uint, string); // remove now accepts a range

// entities with specific ids can now be requested
world.entity(Entity(45));

// if the entity is alive it returns it instead of creating a new one
assert(entity == world.entity(Entity(0)));

// a custom batch can now be chosen when destroying an entity
// the next time this entity gets recycled its batch will be 7
// entity builder's entity implicitly casts to entity so that it can be used with entity manager functions
world.destroyEntity(entity, 7);
assert(world.entity.batch == 7);

auto shallow = world.entity;

// entity manager now informs if an entity is shallow
// a shallow entity holds no components
assert(world.shallowEntity(shallow));

// shallow entities can be released, better performance than destroy
world.releaseEntity(shallow);

// when releasing the next batch can be chosen
world.releaseEntity(world.entity, 87);

// entity manager now informs the number of entities alive
assert(world.aliveEntities() == 1);

Pushed the PR with bug fixes (some found here, others along the way) and with the unit tests fixed to match and test the new functions. The unit tests were simplified to reduce code duplicity and be easier to understand.

Pushed the PR with a few changes: createEntity functions are now public and entities was refactored to eachEntity (which now forwards each valid entity to a function).
Documentation was added and fixed for the functions worked in this PR.

This and future PRs will or might have breaking changes. This will keep happening as I move towards the beta version. After that, I'll try to keep it to a minimum (only doing it when needed), but until VECS is officially released more breaking changes can happen (and drastic ones).


vectors in W being updated (python)

Are the vectors in W supposed to be updated depending on inputs passed to the distance function?
For example, if I pass in "car", the cosine similarity with "stroller" is 0.1729. If I then pass in "car stroller", and then just "car" again, then the cosine similarity with "stroller" is now 0.765.
Running the python code through a debugger, it looks like the vectors for "car" and "stroller" in W are updated during the distance function call with the input containing multiple words. Is this supposed to be happening?
from eval/python/distance.py:
    for idx, term in enumerate(input_term.split(' ')):
        if term in vocab:
            print('Word: %s  Position in vocabulary: %i' % (term, vocab[term]))
            if idx == 0:
                vec_result = W[vocab[term], :]
            else:
                vec_result += W[vocab[term], :]

when you initialize the first vec_result, and then add to it in the else: branch, you're updating the first vector in the W ndarray itself since vec_result is a reference (not a copy).

In the code snippet you have pasted, W is not being updated. Rather vec_result is being set to the sum of it's word vectors. Would you agree?

vec_result is a reference to an element within W. When you update vec_result by summing the vectors, you're updating the first vector within W since that's what the reference points to.

Ah, good catch. This was a user contribution, and unfortunately we didn't catch that bug. Fix should be here: https://github.com/stanfordnlp/GloVe/commit/c0d838f86c4d14c7ea9af647ca869291058ba8c0
Does that work?

yup, thanks!


Api V1 Group Gate

Endpoint for enabling/disabling feature for a given group.
flipper[:feature].enable_group :group

Thanks for adding this and the other API endpoint features. I dropped them on the API project as well to help keep track of stuff.


Fix "struct stat" on 32-bit FreeBSD 12+

It has always been broken.  But we never noticed because we don't run CI on 32-bit FreeBSD, and until #3723 our users always used a FreeBSD 11 ABI.
Fixes https://github.com/rust-lang/rust/issues/130677

Thanks for the fix, can this target main or is it conflict-y? Also, do you have a link to the relevant headers?

Thanks for the fix, can this target main or is it conflict-y? Also, do you have a link to the relevant headers?

We'll need to merge it to both branches, but there's a slight conflict with main.  As for headers:
https://github.com/freebsd/freebsd-src/blob/ee3da604dd016439850dae77366796313e60f0e0/sys/sys/stat.h#L122
https://github.com/freebsd/freebsd-src/blob/ee3da604dd016439850dae77366796313e60f0e0/sys/sys/stat.h#L157

Thanks for the links, easy enough.
For future reference I've been preferring PRs to target main first so that branch can't wind up missing anything, then I do periodic backports. But since this is a fix we might as well get it in.
@rustbot label +main-needs-cherry-pick


Fixing wrong behaviour when using guild_ids

About this pull request
When using guild_ids in the @slash.slash decorator the handling of incoming interactions halts prematurely on line 772 in the client.py file and it prevents the bot from interacting with users.
This is due to ctx.guild_id being an integer and selected_cmd.allowed_guild_ids a list of strings: obviously an integer will never be in a string list.
Casting ctx.guild_id  to a string solves the problem.
Changes
Casted ctx.guild_id  to a string
Checklist

[X] I've checked this pull request runs on Python 3.6.X.
[ ] This fixes something in Issues.

Issue:

[ ] This adds something new.
[ ] There is/are breaking change(s).
[ ] (If required) Relevant documentation has been updated/added.
[ ] This is not a code change. (README, docs, etc.)

allowed_guild_ids should be a list of integers.

Whooops.
I was using environment variables (which are strings) as guild ids.
Thank you, it just flew over my mind.


refactor!: environment variables validation

Refactor environment variable validation rules. Apply consistent patterns to env validation.
The main motivation for this change was as follows:

Make env validation more strict and consistent. Stick to the same validation patterns in different projects.

Provide consistent fallback options for optional variables.

Here are the main changes:

Previously if a user set an empty string as the variable name in the .env file like this: VARIABLE_NAME= not all variable initializers assigned a correct default value to the variable in this case. Now it is fixed. For the purpose of this improvement, now all optional variable initializers always have the @Transform decorator that provides a default value for the variable. Add the two special functions (toNumber and toBoolean) that support this change.

Make validation of boolean variables more strict.
CAUTION: This might be a breaking change for users who use values like "yes" to initialize boolean variables.

Now the ETH_NETWORK variable is validated not only when the validator source is "Lido". Make validation of this variable more strict.
CAUTION: Currently the EVM doesn't officially support testnets other than those listed in the Network interface. But this might be a breaking change if some users use EVM for other testnets.

Implement the new toArrayOfUrls() function to provide a reasonable default value for variables that should have a list of URLs in their values. This function also fixes a bug with default values for such variables. Previously, if a user set an empty string as a value of such variables, the validation worked incorrectly.

Now we validate that values in EL_RPC_URLS, CL_API_URLS, and VALIDATOR_REGISTRY_KEYSAPI_SOURCE_URLS are indeed URLs.

The validation engine now removes trailing slashes from URL values.

More consistent validation for the HTTP_PORT and DB_PORT values.

Add @Optional decorator to all optional variables.

Change @IsNumber to @IsInt.

Move enums from the env.validation.ts to environment.interface.ts.

Update validation rules for some variables. The main changes are:

Loosen validation rules for boolean variables. Now numbers "1" and "0" and constants "yes" and "no" are accepted as valid boolean values.

Rename the Network interface to Chain.


New Feature: Custom Hotkeys for Commands

This PR adds support for customizable hotkeys, allowing users to assign specific hotkeys to commands.
Example of usage:
Solo::useTheme('dark')
    ->addCommands([
        // ...
        new Command(name: 'Foo', command: 'echo "See hotkeys below"', autostart: true, customHotKeys: [
            new CustomHotKey(
                key: 'e',
                name: 'echoE',
                callback: fn() => Log::info('pressed "e"...'),
                when: fn(Command $command) => $command->processRunning()
            ),
            new CustomHotKey(key: 'f', name: 'echoF', callback: fn() => Log::info('pressed "f"...')),
        ]),
        // ...
    ])

In this example, pressing 'f' will log a message. echoE is not visible because the command is not running

TO-DOs

[x] Display a notification or visual feedback when a hotkey is pressed.
[x] Add conditional visibility for hotkeys, e.g., only activating specific hotkeys when a command is stopped.
(Postponed) Enable users to execute commands directly within the tab.

Oooo I like this. I can pick it up when you're done! Don't wanna step on your toes.

I've completed two out of the three To-Dos.
For the third one, it would require a lot of changes to the Command class. I prefer to postpone this and implement it in a separate pull request.

Ok hold off for a sec, I might monkey with the API a bit on this PR. Thank you for doing this!

 Feel free to treat the PR as a concept and make any changes you'd like :)

Ok I accidentally did like 100 things on this branch... so... stay tuned


Failed To Execute script..

I'm a luddite Windows 10 user. I downloaded the GUI, as it says that's all I need. I bypassed the warning, but when I run the GUI, open a file, and choose a new name for the output, when I click run, it errors out with "Failed to execute script"
I'm guessing there's something else I need to do for this to work, but what? download the .py files to the same folder? I'm lost and appreciate any help.

This is really strange. You should only need the single executable.
However, I advise you to use UVTools - a much more powerful tool, that is under an active development.

On it! I like what I see already. Thanks for the tip!


How to count the calculation flops and parameters?

Thx!!!!!!!!!

https://github.com/sovrasov/flops-counter.pytorch


Fix failing tests from the toml-test-harness

#10 added tests to test the parser against the toml-test-harness suit. However, 210 tests currently fail and were ignored. The task would be to:

[ ] fix them all and
[ ] remove them from the ignore list.

cc @CosmicHorrorDev

I'd be willing to take a stab at getting basic string parsing up to spec next

I'd be willing to take a stab at getting basic quoted string parsing up to spec next

That's great but after working on #9, I realized that it would be probably best to take and adapt most of the parsing code from toml_edit crate. The parsing parts seems very standalone and don't drag in extra deps. That code already passes all the tests and will be a much faster way to get to resolve this issue.

The parsing parts seems very standalone and don't drag in extra deps.

actually spoke too soon. :) Some of that code (strings specifically) is quite involved. So carry on please. If if you can learn from and/or take some of toml_edit code, that's not a problem still.

I've also got a mostly spec compliant handwritten toml-parser (10 failing tests from toml-test) that may be a good more barebones reference, but ya I've also been referencing toml_edit too :yum:

Speaking of, I guess that we could lift that parser and implement things here to further drop the number of dependencies, but there's definitely some cleanup that needs to happen first (particularly around the complete lack of error context)

I've also got a mostly spec compliant handwritten toml-parser (10 failing tests from toml-test)

Nice. I'm glad you already know TOML so well (unlike me). :)

Speaking of, I guess that we could lift that parser into here to further drop the number of dependencies, but there's definitely some cleanup that needs to happen first (particularly around the complete lack of error context)

Hm.. while dropping our only mandatory dep does sound appealing, I think I'd rather want to continue with winnow since:

It's a well-established crate for parsing and chances of projects already depending on it, are very high and so in many cases, it will not even count as as an additional dependency dragged in by this crate.
It doesn't drag in other mandatory deps.
any optimisations already in it and that will come in the future, will benefit us as well. We already benefit from its simd feature.


Istio fails on dependency

Issue #, if available:
Description of changes: istio base release must complete before istio control plane is attempted release
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/do-e2e-tests

/do-e2e-tests

/do-e2e-tests

end to end tests failed. A maintainer can provide more details.

This was due to the previous run failue

end to end tests failed. A maintainer can provide more details.

helm chart repo - intermittent connectivity issues


Find a way to enforce mandatory type annotations for all python modules

Ideally, this should be easily toggleable

https://github.com/beartype/beartype seems to be the best option from what I've seen at the moment

Beartype enforces annotations during runtime but requires integration into each project individually (which is fine). No "extra configuration" is needed hence closing this one.


Unable to open 'Settings' error after running configure extension settings for a newly installed extension

Issue Type: Bug
Repo

Install a theme extension in the editor (such as this)
Without restarting, in the extensions viewlet click on the gear for the newly installed extension and select configure extension settings

Bug
See Unable to open 'Settings' ... message
In the dev tools, see:
/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:2362 Unable to open 'Settings': Cannot read property 'element' of undefined.
onDidNotificationChange @ /Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:2362

VS Code version: Code - Insiders 1.34.0-insider (f89390fcec44a24ce74dfc4efbc1438f35b7357a, 2019-04-18T13:31:41.962Z)
OS version: Darwin x64 18.5.0

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz (8 x 2200)

GPU Status
2d_canvas: enabledchecker_imaging: disabled_offflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: enabledrasterization: enabledsurface_synchronization: enabled_onvideo_decode: enabledwebgl: enabledwebgl2: enabled

Load (avg)
2, 3, 3

Memory (System)
16.00GB (0.13GB free)

Process Argv

Screen Reader
no

VM
29%

Hey, I have it working on my computer, but it is a change to "vscode/out/vs/workbench/contrib/preferences/electron-browser/settingsEditor2.js:846:61", which is part of the .gitignore of this repo - are there other files that I could look at editing for this bug?

Dupe of https://github.com/Microsoft/vscode/issues/72354

Hey @roblourens, there's also the second exception in the dev console about Unable to open 'Settings': Cannot read property 'element' of undefined so do think this is a duplicate of #72354. I've edited my issue to make it more clear that this was the main issue I was seeing.
Feel free to close again if that is not correct

I thought this was fixed with my fix for #72354 but I see that it's not fixed in today's build...

Actually, I can't repro this anymore. I think my previous change was missing from yesterday's first build. Let me know if you still see it.


Overlay index fetch issue

Should resolve #78 and one of the additional bugs mentioned in #80

As mentioned in #80, there were issues when initializing the Stat objects. Looking further into it, I found that the dirEntries was called to get the directory entries. However, it simply iterates through the keys of the Index. Since the Index object is in the process of being created when this is called, not all keys which would otherwise be in the final Index object are there when it's called.
I also found the bug which caused the double unlocking bug. This occurs if the program locks a path 3 times.
On it's first lock, it would creates a Promise 'A'. Then when it locks a second time, it awaits Promise 'A'. Finally on it's third time, it would also await Promise 'A'. When the program unlocks the lock (resolving Promise 'A'), both threads which are awaiting 'A' start running at the same time, which causes the bug.

@terryluan12 Some changes have been made. Primarily, the Mutex logic has been folded into LockedFS. Please consult the release notes for v0.14.0.

Ah, didn't even notice it, thanks for the heads up! I just merged + re-added the changes

As mentioned in #80, there were issues when initializing the Stat objects. Looking further into it, I found that the dirEntries was called to get the directory entries. However, it simply iterates through the keys of the Index. Since the Index object is in the process of being created when this is called, not all keys which would otherwise be in the final Index object are there when it's called.

This should have been resolved in https://github.com/zen-fs/core/commit/ec86a6aacfcc36d0960f2a1280b88d21bce8bc92. Please let me know if the issue still happens- you will need to run make-index again. I am again using a regex since it is relatively slow. If one was to have 10,000 files for example, creating a new regex for each one slows things down.

@terryluan12 Any updates on this?

@terryluan12 Any updates on this?

Hi @james-pre, so sorrry about the lack of update! Got busy with some real life stuff, and didn't see the comments. Just got a replacement for my previous laptop, and will get to work on zen-fs, and finish up this issue ASAP

Hey @james-pre, I've been taking a look at the double unlocking issue, and I've gotten an idea of why it's bugging. Specifically, it occurs when you have two processes waiting on a locked promise. Once the promise resolves, both processes will continue at the same time. Thus they'll both call addLock, and one promise will override the others, causing the weird double unlocking. Thinking about it, I think one possible solution is to implement a queuing system. What are your thoughts?

@terryluan12,
Thanks for your dedication to this.
My thinking is that we should try to avoid a queue system.
It should work like this:

call asynchronous methods a and b on the same path without using await,

i.e.

	a(path);
	b(path);

a locks on the path, which adds the lock
b tries to lock on the path, though it must wait for a to finish (in LockedFS.lock)
a performs its operations
a's scope is left, MutexLock[Symbol.dispose] runs, unlocking the path
b then performs its operations
b's scope is left, MutexLock[Symbol.dispose] runs, unlocking the path

I think https://github.com/zen-fs/core/commit/e3878895f107ed43e412b226f4feab6232123a54 may fix something since now the promise won't resolve until the lock is actually cleared.

No worries at all, thanks for allowing me to help!
I think there's been a misunderstanding. To clarify, the issue occurs in the following scenario, when there are 3 locks; for example A, B, and C.
In this case, if A locks first, and then B and C lock (in any order), then both B and C are now waiting on A's lock to release.
When A then releases, both B and C start again at the same time. I believe this is the unintended behaviour, where they both start again at the same time.

Ah, this makes more sense now! Thanks for the clarification.
Maybe we could look at a wrap and replace, so when B attempts the lock, it replaces the current lock with one that resolves when B is done. This wouldn't impact A since it holds the lock, and doesn't update the reference (i.e. the A's MutexLock[Symbol.dipose] resolves only the lock for A).

@terryluan12 Now that the mutex issue has been solved, can I close this PR?

Yep, absolutely!


Add pulseaudio as dependency on Ubuntu

Describe the bug
I installed k4a-tools on a Ubuntu 18.04 arm64 device which pulseaudio is not installed at first.
k4aviewer try to connect to pulseaudio then crash.
To Reproduce

Uninstall pulseaudio
install k4a-tools
run k4aviewer

han@agx ~> k4aviewer
ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused

ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused

fish: 'k4aviewer' terminated by signal SIGSEGV (Address boundary error)

Expected behavior
Add pulseaudio as dependency to install it automatically
Desktop (please complete the following information):

OS with Version: 18.04.5 LTS arm64
SDK Version: 1.4.1
Firmware version:

Additional context

The Sensor SDK has a dependency on libsoundio. I quick grep on the code does not find any dependency on pulseaudio.


[ENH] UnobservedComponents model as probabilistic forecaster

Hey 👋 ! Its seems the UnobservedComponents model wrapper (see here) does not support prediction intervals yet right? I would be nice to have them as I do not think is really hard because of the statsmodels implementation.
I can work on this one in the upcoming weeks!

excellent, that would be really nice!

Hm, I just looked at it, seems non-obvious to me...
So it´s great you´ve already looked at this!
May I ask you, @juanitorduz, which method or attribute you would be planning to read the proba forecasts off?

I actually haven't thought in detail 😂... I just saw there are other algorithms like ARIMA that support this and I was thinking that both come from the state space module from 'statsmodels' so I thought "how hard can it be ?" Let me look into the implementation in detail 🙈

So the idea us is to use the existing implementation statsmodels.tsa.statespace.mlemodel.PredictionResults.summary_frame.


Support for Yaml table header + CSV body import (csvy)

Just an idea, but I wonder if there might be any view on potential support for an import process that includes explicit column data type specification?  Neo4j supports import of separate header csv files with this detail encoded.  An alternative approach might be this csvy format method.  Anyway just an idea.

Hm, we currently only have a .js yaml-parser inside of ArangoDB. ArangoImport currently doesn't spawn a javascript interpreter. Probably this would be neccessary to implement this.
Probably the fastest way to get this available will be implementing it using arangojs + i.e. https://github.com/gko/csvy

Some of the metadata translates more or less to arangoimport startup options:
#schema:
#  fields:
#  - name: var1
#    type: string
#  - name: var2
#    type: integer
#  - name: var3
#    type: number
#dialect:
#  delimiter: ","
#  doubleQuote: false
#  lineTerminator: "\r\n"
#  quoteChar: "\""
#  header: true

Not sure if UTF-8 is the sole supported encoding actually...


Refactored client library code for Data Types for simplicity and code reuse

Refactored client library code for Data Types for simplicity and code reuse
This refactoring is attempting the following benefits:

Code reuse for common value encoding conversions
Reducing the number of places when adding a new data-type, especially the type-related conversion logic.
Refactor the existing primitive types to use the new helper functions to simplify existing code and tests.

Reference - code change required for adding a new type:

PR for NUMERIC data type
PR for PG JSONB data type

Fixes - (Bug to be created) ☕
[Note: This PR is raised on a fork of the java-spanner client repo. It is currently a prototype, and once things look promising a separate PR will be raised for merging this to the official repo.]

These changes are great for a first pass.
I think the Type specific logic is still essentially scattered all over the place for non-primitive or special handling. A developer would still need to look at all the areas to figure out whether they need to add a special case etc. Can we make generic interfaces to be overriden for new types to limit all set of specialization logic for a new type in 1-2 files? Say in either Type and Value classes? or a new generic interface that covers all methods required for type specific logics with a default implementation for each?

These changes are great for a first pass. I think the Type specific logic is still essentially scattered all over the place for non-primitive or special handling. A developer would still need to look at all the areas to figure out whether they need to add a special case etc. Can we make generic interfaces to be overriden for new types to limit all set of specialization logic for a new type in 1-2 files? Say in either Type and Value classes? or a new generic interface that covers all methods required for type specific logics with a default implementation for each?

@charvisingla Yes, in the first parse I tried to just identify and reduce the duplication wherever I found common code fragments. Special cases are still left untouched.
In a second parse I am now looking at these two as you suggested:

Limiting all type-specific transcoding, casting etc to 1 or 2 places
Introduce a default implementation that is sufficient for future simple types (e.g. Number-compatible types such as INT32 and String-compatible types such as JSON/JSONB in the past), and only custom logic needs to override this.

I had faced the following challenges in phase-1 while exploring ways to add new generic interfaces. Do share if you have any specific ideas or suggestions:

Public interfaces: We should not break or deprecate any existing interfaces, and prefer to support existing conventions for future types - e.g. if we have a ValueBinder.to(boolean) for Boolean type then we should later add a ValueBinder.to(int) for INT32.
Private or internal interfaces: The volume of existing work is huge, and much of this is tightly coupled to specific types. E.g. separate method signatures for each data type.

One of the ideas was to centralize Type specific logic such that when we add a new type we would only need to touch one file, maybe two files. I see that if I add a new type I would still need to change: potentially Type.java, TypeHelper.java, Value.java and potentially ChecksumResultSet.java.
Could we see if we can centralize this further?
Perhaps all of the following could live in a TypeMapper of sorts:

Code to primitive type
Code to array type
Supported primitive type classes
Extracting value using code
Extracting array using code

Yes, and also (6) Checksum calculation for each type. Attempting this now.


Tip space

Raw version of tipping story author with SPACE (#21)  is implemented.
The amount is now 0.01 and should probably be increased and/or be set by the user.
At the moment it's applied to sender/recipient balances and their activity logs - perhaps it'd be useful to store it in way that allows to easily see tips for a certain story (in a way number of likes is shown in fb, also that you have (or haven't) liked the story). @Jabyl

Raw version of tipping story author with SPACE (#21) is implemented.
Good work, well done!
> The amount is now 0.01 and should probably be increased and/or be set by the user.
This may make sense (currently) on Arweave, but it's quite irrelevant on the app logic. We shouldn't use decimals (maybe just .5), and SPACE should be simple and straightforward. I suggest to give users 3 micro-buttons below the story to tip (2, 5, 10) in one click :)
I'm prepare the screen about it - I'm quite struggling with the "like" decision, honestly, as it isn't a small thing especially at this stage.
At the moment it's applied to sender/recipient balances and their activity logs - perhaps it'd be useful to store it in way that allows to easily see tips for a certain story (in a way number of likes is shown in fb, also that you have (or haven't) liked the story)
It's fine to show the total "tip bank" but we shouldn't go too much in the SteemIt direction:
https://steemit.com/
https://steem.com/
About communicating between Blockchain and regular database (on- / off-Chain and viceversa) -

> The amount is now 0.01 and should probably be increased and/or be set by the user.
I suggest to give users 3 micro-buttons below the story to tip (2, 5, 10) in one click :)
Maybe just keep current tip button and add the amount selection to the popup? We could get more choices as well as input for custom amount.
Currently the Arweave tip feature is 2-click thing anyway - with the amount select with pre-set default value it could be 2 or 3 clicks.

I'm prepare the screen about it - I'm quite struggling with the "like" decision, honestly, as it isn't a small thing especially at this stage.
In my opinion it's simpler interface, simpler implementation and fluid economy from the very beginning. And if we feel that we need standard "like" then we add it.

At the moment it's applied to sender/recipient balances and their activity logs - perhaps it'd be useful to store it in way that allows to easily see tips for a certain story (in a way number of likes is shown in fb, also that you have (or haven't) liked the story)
It's fine to show the total "tip bank" but we shouldn't go too much in the SteemIt direction:
https://steemit.com/
https://steem.com/
It could even be total number of tips, not necessarily the exact amount of SPACE.

Maybe just keep current tip button and add the amount selection to the popup? We could get more choices as well as input for custom amount.

If we really want to try out the "tipping" and give it a fair shot at being a useful/meaningful interaction, should be as easy as possible - like a "no brainer" for users. If we start letting them the choice to do everything (a moving bar/text-field to pick the amount for example), and we ask for too many steps - it just "spoils" the natural magic of discovering a new story in a random place. The main concept here is that a "Non-Zone" is a surprise, you enter a magic area - and there are secrets, hints, stories there - that complement your personal experience. If we focus too much on the relationship between Author and Reader - we lose the initial vision of Non-Zone, and it risk to become "just another a blogging platform" :)

It could even be total number of tips, not necessarily the exact amount of SPACE.

It's a good direction - I liked the idea we had in the past, using a simple "amount of interactions" calculator (any type of interaction), or a "red-to-green" bar to show the interaction rate (from low to high).

Tips info is now stored in manner allowing efficient loading per object or array of objects as well as per user.
More than one tip is allowed from one user to same story - both in DB and UI. With small effort it's possible to limit it to just one in the UI.
Tips info for visible stories are loaded in webapp's Map screen and stories with at least one tip are shown with small highlight.
In Story view total count of tips is shown, also current user's tips (sort of golden badges over tip button).
Tip is used in a manner of "like" at the moment, though it's possible to set add actual "like" functionality apart from tips.
For user's own story tipping button is disabled.
There's no much styling for the moment, we'll do it additionally.
I'll merge it now, further modifications will be made in master branch.

Forgot to mention that tip currency amount for SPACE is now 1, for AR it remains 0.01

If we really want to try out the "tipping" and give it a fair shot at being a useful/meaningful interaction, should be as easy as possible - like a "no brainer" for users. If we start letting them the choice to do everything (a moving bar/text-field to pick the amount for example), and we ask for too many steps - it just "spoils" the natural magic of discovering a new story in a random place. The main concept here is that a "Non-Zone" is a surprise, you enter a magic area - and there are secrets, hints, stories there - that complement your personal experience. If we focus too much on the relationship between Author and Reader - we lose the initial vision of Non-Zone, and it risk to become "just another a blogging platform" :)

It's 2-step thing at the moment - a bit annoying I agree. Indeed we could set 3 buttons with different amount and perhaps remove the confirmation and loading spinner, while making some small cool animation for the tip button.
Another option is Medium's "clap" - it seems instant and more than one is allowed. Not sure if there's limit - or at least never got so excited as to hit it :) To me it's better than 3 buttons for 1, 2, 5 SPACE - we also have Close and Bookmarks buttons and it becomes too much IMO.

It could even be total number of tips, not necessarily the exact amount of SPACE.

It's a good direction - I liked the idea we had in the past, using a simple "amount of interactions" calculator (any type of interaction), or a "red-to-green" bar to show the interaction rate (from low to high).

I don't think we'll have lots of interactions at the beginning and we better not to put too much "red negativity" into it - I say we mark high-interaction stories somehow and leave no-interaction ones with no mark.
@Jabyl


Implement passthrough parser

Implementation is ready for review with one caveat: I can't get goldmark to trigger the block parser for inputs where the block fences are placed inline:
Block \[x^*=y^*\] equation

Despite having CanInterruptParagraph to true in the parser, the block parser is never triggered and I'm not sure why.
One workaround for LaTeX is to duplicate all the configured block fences in the config for the inline fences, which actually seems like the more appropriate general behavior: a configured block fence only triggers when it's the start of a new markdown paragraph.
Other than that, all the tests in https://github.com/jmooring/hugo-testing/blob/hugo-github-issue-10894 seem to pass.

Great start! I've got 26 test cases. All of these pass when using a shortcode, but 10 of them fail when using the passthrough approach.

test cases added to passthrough/passthrough_test.go
func TestExample1(t *testing.T) {
	input := `Inline $x = {-b \pm \sqrt{b^2-4ac} \over 2a}$ equation`

	expected := "
" + input + "
"
	actual := Parse(t, input)

	c := qt.New(t)
	c.Assert(actual, qt.Equals, expected)
}

func TestExample2(t *testing.T) {
	input := `x = {-b \pm \sqrt{b^2-4ac} \over 2a}
n$ equation`

	expected := "
" + input + "
"
	actual := Parse(t, input)

	c := qt.New(t)
	c.Assert(actual, qt.Equals, expected)
}

func TestExample3(t *testing.T) {
	input := `Inline $x = {-b \pm \sqrt{b^2-4ac} \over 2a}
$ equation`

	expected := "
" + input + "
"
	actual := Parse(t, input)

	c := qt.New(t)
	c.Assert(actual, qt.Equals, expected)
}

func TestExample4(t *testing.T) {
	input := `Inline $
x = {-b \pm \sqrt{b^2-4ac} \over 2a}$ equation`

	expected := "
" + input + "
"
	actual := Parse(t, input)

	c := qt.New(t)
	c.Assert(actual, qt.Equals, expected)
}

func TestExample5(t *testing.T) {
	input := `Block $$x = {-b \pm \sqrt{b^2-4ac} \over 2a}$$ equation`

	expected := "
" + input + "
"
	actual := Parse(t, input)

	c := qt.New(t)
	c.Assert(actual, qt.Equals, expected)
}

func TestExample6(t *testing.T) {
	input := `Block $$
x = {-b \pm \sqrt{b^2-4ac} \over 2a}
$$ equation`

	expected := "
" + input + "
"
	actual := Parse(t, input)

	c := qt.New(t)
	c.Skip() // TODO failing test
	c.Assert(actual, qt.Equals, expected)
}

func TestExample7(t *testing.T) {
	input := `Block $$x = {-b \pm \sqrt{b^2-4ac} \over 2a}
$$ equation`

	expected := "
" + input + "
"
	actual := Parse(t, input)

	c := qt.New(t)
	c.Skip() // TODO failing test
	c.Assert(actual, qt.Equals, expected)
}

func TestExample8(t *testing.T) {
	input := `Block $$
x = {-b \pm \sqrt{b^2-4ac} \over 2a}$$ equation`

	expected := "
" + input + "
"
	actual := Parse(t, input)

	c := qt.New(t)
	c.Assert(actual, qt.Equals, expected)
}

func TestExample9(t *testing.T) {
	input := `Inline $a^*=x-b^*$ equation`

	expected := "
" + input + "
"
	actual := Parse(t, input)

	c := qt.New(t)
	c.Assert(actual, qt.Equals, expected)
}

func TestExample10(t *testing.T) {
	input := `Inline $
a^*=x-b^*
$ equation`

	expected := "
" + input + "
"
	actual := Parse(t, input)

	c := qt.New(t)
	c.Assert(actual, qt.Equals, expected)
}

func TestExample11(t *testing.T) {
	input := `Inline $a^*=x-b^*
$ equation`

	expected := "
" + input + "
"
	actual := Parse(t, input)

	c := qt.New(t)
	c.Assert(actual, qt.Equals, expected)
}

func TestExample12(t *testing.T) {
	input := `Inline $
a^*=x-b^*$ equation`

	expected := "
" + input + "
"
	actual := Parse(t, input)

	c := qt.New(t)
	c.Assert(actual, qt.Equals, expected)
}

func TestExample13(t *testing.T) {
	input := `Block $$a^*=x-b^*$$ equation`

	expected := "
" + input + "
"
	actual := Parse(t, input)

	c := qt.New(t)
	c.Skip() // TODO failing test
	c.Assert(actual, qt.Equals, expected)
}

func TestExample14(t *testing.T) {
	input := `Block $$
a^*=x-b^*
$$ equation`

	expected := "
" + input + "
"
	actual := Parse(t, input)

	c := qt.New(t)
	c.Skip() // TODO failing test
	c.Assert(actual, qt.Equals, expected)
}

func TestExample15(t *testing.T) {
	input := `Block $$a^*=x-b^*
$$ equation`

	expected := "
" + input + "
"
	actual := Parse(t, input)

	c := qt.New(t)
	c.Skip() // TODO failing test
	c.Assert(actual, qt.Equals, expected)
}

func TestExample16(t *testing.T) {
	input := `Block $$
a^*=x-b^*$$ equation`

	expected := "
" + input + "
"
	actual := Parse(t, input)

	c := qt.New(t)
	c.Skip() // TODO failing test
	c.Assert(actual, qt.Equals, expected)
}

func TestExample17(t *testing.T) {
	input := `Inline \(a^*=x-b^*\) equation`

	expected := "
" + input + "
"
	actual := Parse(t, input)

	c := qt.New(t)
	c.Assert(actual, qt.Equals, expected)
}

func TestExample18(t *testing.T) {
	input := `Inline \(
a^*=x-b^*
\) equation`

	expected := "
" + input + "
"
	actual := Parse(t, input)

	c := qt.New(t)
	c.Assert(actual, qt.Equals, expected)
}

func TestExample19(t *testing.T) {
	input := `Inline \(a^*=x-b^*
\) equation`

	expected := "
" + input + "
"
	actual := Parse(t, input)

	c := qt.New(t)
	c.Assert(actual, qt.Equals, expected)
}

func TestExample20(t *testing.T) {
	input := `Inline \(
a^*=x-b^*\) equation`

	expected := "
" + input + "
"
	actual := Parse(t, input)

	c := qt.New(t)
	c.Assert(actual, qt.Equals, expected)
}

func TestExample21(t *testing.T) {
	input := `Block \[a^*=x-b^*\] equation`

	expected := "
" + input + "
"
	actual := Parse(t, input)

	c := qt.New(t)
	c.Skip() // TODO failing test
	c.Assert(actual, qt.Equals, expected)
}

func TestExample22(t *testing.T) {
	input := `Block \[
a^*=x-b^*
\] equation`

	expected := "
" + input + "
"
	actual := Parse(t, input)

	c := qt.New(t)
	c.Skip() // TODO failing test
	c.Assert(actual, qt.Equals, expected)
}

func TestExample23(t *testing.T) {
	input := `Block \[a^*=x-b^*
	\] equation`

	expected := "
" + input + "
"
	actual := Parse(t, input)

	c := qt.New(t)
	c.Skip() // TODO failing test
	c.Assert(actual, qt.Equals, expected)
}

func TestExample24(t *testing.T) {
	input := `Block \[
a^*=x-b^*\] equation`

	expected := "
" + input + "
"
	actual := Parse(t, input)

	c := qt.New(t)
	c.Skip() // TODO failing test
	c.Assert(actual, qt.Equals, expected)
}

func TestExample25(t *testing.T) {
	input := `$$
\begin{array} {lcl}
	L(p,w_i) &=& \dfrac{1}{N}\Sigma_{i=1}^N(\underbrace{f_r(x_2
	\rightarrow x_1
	\rightarrow x_0)G(x_1
	\longleftrightarrow x_2)f_r(x_3
	\rightarrow x_2
	\rightarrow x_1)}_{sample\, radiance\, evaluation\, in\, stage2}
	\\\\\\ &=&
	\prod_{i=3}^{k-1}(\underbrace{\dfrac{f_r(x_{i+1}
	\rightarrow x_i
	\rightarrow x_{i-1})G(x_i
	\longleftrightarrow x_{i-1})}{p_a(x_{i-1})}}_{stored\,in\,vertex\, during\,light\, path\, tracing\, in\, stage1})\dfrac{G(x_k
	\longleftrightarrow x_{k-1})L_e(x_k
	\rightarrow x_{k-1})}{p_a(x_{k-1})p_a(x_k)})
\end{array}
$$`

	expected := input
	actual := Parse(t, input)

	c := qt.New(t)
	c.Assert(actual, qt.Equals, expected)
}

func TestExample26(t *testing.T) {
	input := `\[
\begin{array} {lcl}
	L(p,w_i) &=& \dfrac{1}{N}\Sigma_{i=1}^N(\underbrace{f_r(x_2
	\rightarrow x_1
	\rightarrow x_0)G(x_1
	\longleftrightarrow x_2)f_r(x_3
	\rightarrow x_2
	\rightarrow x_1)}_{sample\, radiance\, evaluation\, in\, stage2}
	\\\\\\ &=&
	\prod_{i=3}^{k-1}(\underbrace{\dfrac{f_r(x_{i+1}
	\rightarrow x_i
	\rightarrow x_{i-1})G(x_i
	\longleftrightarrow x_{i-1})}{p_a(x_{i-1})}}_{stored\,in\,vertex\, during\,light\, path\, tracing\, in\, stage1})\dfrac{G(x_k
	\longleftrightarrow x_{k-1})L_e(x_k
	\rightarrow x_{k-1})}{p_a(x_{k-1})p_a(x_k)})
\end{array}
\]`

	expected := input
	actual := Parse(t, input)

	c := qt.New(t)
	c.Assert(actual, qt.Equals, expected)
}

I've added c.Skip() // TODO failing test to each of the 10 failing tests.
To me, the gold standard for testing is the method that Hugo users have been using for years: wrap the LaTeX in a shortcode that passes .Inner through without modification.
So I think we need all 26 test cases to pass.
I've update the test repo, spitting the passthrough and shortcode tests into separate pages. Each page performs the same tests, in the same sequence, with the same name... so it's easy to compare results.

As to the failing CI build, we check that the go fmt is OK. I recommend setting up that in the editor you choose, if possible, then you don't have to think about it.

Sorry for the delays, inclement weather and all. I have some simplifications and fixes incoming that handles all of @jmooring's tests, with the main remaining obstacle being that goldmark's "raw text" renderer still does character substitutions like $ -> $amp; for inline, so I have to add a custom inline renderer. Should be updated here tonight or tomorrow.

All the tests are now passing, with one caveat. I was struggling to get a proper inline and block parser working separately with some of the test cases (e.g., Example6 would trigger a new block on the third line, and I couldn't get goldmark to treat it as a continuation of the existing block).
My workaround was to implement the entire extension using only inline parsing/rendering. As a result:

I had to modify two of @jmooring's tests in 26e01ab to add paragraph tags around the block equations, since they are parsed as PassthroughInline children of a Paragraph block.
There is only one set of delimiters, and in the case of LaTeX, when there is ambiguity ($$ vs $$ $$), the more specific delimiter pair needs to come first in the configured list. I left a comment in passthrough_test::buildTestParser to this effect, but we'll need to make that clear in the hugo documentation for this feature.

implement the entire extension using only inline parsing/rendering

If I understand this correctly, it will prohibit us from creating future, separate render hooks for inline and block pass-through as mentioned here. The inline folks will say, "I want to be able to wrap this with a span so I can mouseover...".  The block folks will say, "I want all blocks to be wrapped in a figure element." So, we'd need separate render hooks.

There is only one set of delimiters

Can you briefly describe this?

implement the entire extension using only inline parsing/rendering

If I understand this correctly, it will prohibit us from creating future, separate render hooks for inline and block pass-through as mentioned here. The inline folks will say, "I want to be able to wrap this with a span so I can mouseover...". The block folks will say, "I want all blocks to be wrapped in a figure element." So, we'd need separate render hooks.

I don't recall seeing this contention anywhere, but one possibility would be to add a configuration option to render the passthrough with any user-configured fences (e.g., a hugo shortcode), which could then be transformed by other hugo mechanisms (sorry, not super familiar with what that might be; are shortcodes processed before or after goldmark?). That option could be specific to each delimiter pair, so block delimiters could get a different rendered fence than inline ones. In that direction, would the hugo team prefer for the render hooks to be hugo-based or goldmark-based?
I could give the block+inline approach another go, but another problem was that I couldn't even get the block parser to trigger in the case that the block delimiters were used inline. From what I recall, there was something weird about how goldmark handles lines starting with punctuation in re separating blocks, and I couldn't quite get to the bottom of it.

There is only one set of delimiters

Can you briefly describe this?

Instead of having two configuration options, one to specify block delimiters and one to specify inline delimiters, there is just one option to configure all delimiters.

One other test I just thought of was to handle $ delimiter escapes. I'll have to think about how to handle that generically. Maybe: ensure \ is always a trigger, then if Parse is triggered by a \, check to see if any single-byte delimiter follows the backslash, and if so advance the reader and return a text segment for the escaped delimiter. (Multi-byte delimiters would not be escapable)

render hooks

This is a Hugo thing, not a Goldmark thing. We currently have render hooks for images and links (both are inline elements), and headings and fenced code blocks (both are block elements). But the Goldmark extension should be structured such that, in the future, we can easily hook into both inline pass-throughs and block pass-throughs. Shortcodes are not relevant to the either the Goldmark extension or render hooks.

Instead of having two configuration options, one to specify block delimiters and one to specify inline delimiters, there is just one option to configure all delimiters

I think this is consistent with the Hugo configuration described here:
markup:
  goldmark:
    extensions:
      passthrough:     # or a better name
        enable: false
        delimiters:
          - ['$','$']    # inline equations
          - ['$$','$$']  # block equations
          - ['\(','\)']  # inline equations
          - ['\[','\]']  # block equations

and they are all implicitly inline.

Not sure I understand what you mean by this.

I had to modify two of @jmooring's tests

OK, but then we're testing against what users currently do/get (shortcode).

Not sure I understand what you mean by this.

I don't think it's possible to separate the block/inline parsers and have a single set of configured delimiters. You have to separate them to say which to trigger parsing a block and which to trigger parsing inline.

But the Goldmark extension should be structured such that, in the future, we can easily hook into both inline pass-throughs and block pass-throughs.

I think you're saying one would (during hugo's configuration of the goldmark parser) override the renderer I wrote in this PR, and use some other renderer for the parsed nodes, right? As is, such a renderer would emit HTML that is nested inside a paragraph tag. Am I understanding you that this is not acceptable? I could also attach the parsed delimiters to the ast node, so that the behavior can branch based on the matched delimiters.
In any case, a lot of this nuance focuses on how Foo $$x$$ bar should be treated, since the display-mode ("block") equation is parsed inline. Would the users complain that this is not handled by a block renderer? My main issues with the block renderer were in trying to get it to emit the above–and its split-across-lines variations–as a block node. If we're happy to emit this as an inline node, but still emit Foo\n\n$$x$$\n\nbar as a block node, then I can add back the block renderer quite easily. But it might confuse users expecting a custom block rendering hook to work on both block-style nodes.

Instead of having two configuration options, one to specify block delimiters and one to specify inline delimiters, there is just one option to configure all delimiters

OK, I think I get this now. The original (my) configuration model was inadequate because it would require delimiter hardcoding in the extension.  And we don't want to hardcode to LaTeX delims; this is a generic passthrough extension. (e.g., "I want to do inline passthrough of text that starts with "xxx" and ends with "yyy").
So, the proposed config should have been:
markup:
  goldmark:
    extensions:
      passthrough:     # or a better name
        enable: false
        delimitersInline:
          - ['$','$']
          - ['\(','\)']
       delimitersBlock:
         -  ['$$','$$']
         - ['\[','\]']

Would the users complain that this is not handled by a block renderer?

I would, for the following reasons:

That is not how the current shortcode approach works
If you tell me that $$ is a block delimiter, it should be... a block delimiter

Regarding the first reason... when this is released content authors might ask, "Can I remove all the {{< math >}} and {{< /math >}} stuff in my markdown?" Answering with "it depends" isn't great.
If you haven't used them, I recommend trying Hugo's render hooks to see how they behave. What they render completely replaces the markdown without wrapping them in something else. That's true for both inline and block hooks.

Are there any standard markdown syntax forms that allow an entity specified inline to split into a new block?
Code fences do not: https://spec.commonmark.org/dingus/?text=Inline %24a^*%3Dx-b^*%24 equation
I worry this may be a limitation of goldmark, though I would have to pinpoint the specific reason.

Are there any standard markdown syntax forms that allow an entity specified inline to split into a new block?

No.

only emit a passthrough block if the delimiters wrap the content on separate lines

This would not be compatible with:

Existing usage of shortcodes
GitHub markdown (example)
GitLab markdown (example)

And the last two are about portability, the argument/justification that turned this effort from a proposal into an accepted enhancement.

In your example, GitHub renders the block equations inside a
 tag, suggesting it is parsing it as an inline node, while GitLab renders it inside a
. Moreover, GitHub doesn't support the examples that are confounding my work in Goldmark: https://gist.github.com/j2kun/d2b02918441bd255de07ae711e05047a
I don't have a GitLab account so I can't check if that example also fails on GitLab, but based on your inline examples on GitLab it likely fails.
I think we're going to have to compromise on something here. Which of the block equation examples are we willing to give up? I think it would be important to keep:
$$
equation
$$

and
This is an $$equation$$ sentence.

But not support split-line block equations happening inline.
This is an $$equation
foo
bar$$ baz.

I think I could make that work with a block parser, but if the priority is, "Can I remove all the {{< math >}} and {{< /math >}} stuff in my markdown?" then the current implementation will get us closest to answering "yes" because it supports all the syntax forms, and they don't care about custom renderers because the JS libraries are doing that. If the priority is to support stricter consistency in future potential overrides to the passthrough renderer, then I can try to make that work.

I think we're going to have to compromise on something here... I think I could make that work with a block parser.

OK, we can document that split-line block equations are not supported, as long as the other two block forms work.

If the priority is to support stricter consistency in future potential overrides to the passthrough renderer

Yes, that one.
Question: will inline support all three forms (same line, separate line, split line)?

Inline supports everything, that's what I pushed to the PR. I will give it
a go to see if I can get block parsing support for the non-split-line block
forms.
On Thu, Jan 18, 2024, 4:55 PM Joe Mooring @.***> wrote:

I think we're going to have to compromise on something here... I think I
could make that work with a block parser.
OK, we can document that split-line block equations are not supported, as
long as the other two block forms work.
If the priority is to support stricter consistency in future potential
overrides to the passthrough renderer
Yes, that one.
Question: will inline support all three forms (same line, separate line,
split line)?
—
Reply to this email directly, view it on GitHub
https://github.com/gohugoio/hugo-goldmark-extensions/pull/2#issuecomment-1899461001,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAS2PKX4EAXLAOYS7EJO44TYPHABLAVCNFSM6AAAAABB2ZITMOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJZGQ3DCMBQGE
.
You are receiving this because you authored the thread.Message ID:
@.***>

Good news, after quite a bit more digging I found a workable solution to parse all desired syntax forms and support block delimiters expressed inline with a block renderer.
The solution was to use Goldmark's concept of an ASTTransformer, which is a hook to arbitrarily post-processes the parsed AST before moving on. In my case, I had the parsing stage parse all the passthroughs as inline, and then I search for inline passthrough nodes whose delimiters are block delimiters, and then I split the paragraph at that node to emit a passthrough block node and two paragraphs on each side.
However, this does change some of the test cases, since if we're properly emitting a block node, then we have to have a paragraph break in the rendered HTML. I.e., in the tests that @jmooring defined like
Block $$x = {-b \pm \sqrt{b^2-4ac} \over 2a}$$ equation

The result is

Block

$$x = {-b \pm \sqrt{b^2-4ac} \over 2a}$$

 equation

Which differs from the originally written expected output of

Block $$x = {-b \pm \sqrt{b^2-4ac} \over 2a}$$ equation

It also made me realize that some strange edge cases, such as using a block delimiter inside a list item, should probably remain as inline nodes.
I still have to implement the escape idea described in https://github.com/gohugoio/hugo-goldmark-extensions/pull/2#issuecomment-1899008617, but in the meantime please let me know if the above tweak to the test cases is acceptable.

@j2kun
Looking good!
First, a couple of inconsequential edits to the test cases... I missed a line when creating example 2, and the last example has some leading spaces where it shouldn't.

diff
diff --git a/passthrough/passthrough_test.go b/passthrough/passthrough_test.go
index 2493f12..b11a5ec 100644
--- a/passthrough/passthrough_test.go
+++ b/passthrough/passthrough_test.go
@@ -187,8 +187,9 @@ func TestExample1(t *testing.T) {
 }

 func TestExample2(t *testing.T) {
-	input := `x = {-b \pm \sqrt{b^2-4ac} \over 2a}
-n$ equation`
+	input := `Inline $
+x = {-b \pm \sqrt{b^2-4ac} \over 2a}
+$ equation`

 	expected := "
" + input + "
"
 	actual := Parse(t, input)
@@ -482,22 +483,22 @@ $$`

 func TestExample26(t *testing.T) {
 	input := `\[
- \begin{array} {lcl}
- 	L(p,w_i) &=& \dfrac{1}{N}\Sigma_{i=1}^N(\underbrace{f_r(x_2
- 	\rightarrow x_1
- 	\rightarrow x_0)G(x_1
- 	\longleftrightarrow x_2)f_r(x_3
- 	\rightarrow x_2
- 	\rightarrow x_1)}_{sample\, radiance\, evaluation\, in\, stage2}
- 	\\\\\\ &=&
- 	\prod_{i=3}^{k-1}(\underbrace{\dfrac{f_r(x_{i+1}
- 	\rightarrow x_i
- 	\rightarrow x_{i-1})G(x_i
- 	\longleftrightarrow x_{i-1})}{p_a(x_{i-1})}}_{stored\,in\,vertex\, during\,light\, path\, tracing\, in\, stage1})\dfrac{G(x_k
- 	\longleftrightarrow x_{k-1})L_e(x_k
- 	\rightarrow x_{k-1})}{p_a(x_{k-1})p_a(x_k)})
- \end{array}
- \]`
+\begin{array} {lcl}
+L(p,w_i) &=& \dfrac{1}{N}\Sigma_{i=1}^N(\underbrace{f_r(x_2
+\rightarrow x_1
+\rightarrow x_0)G(x_1
+\longleftrightarrow x_2)f_r(x_3
+\rightarrow x_2
+\rightarrow x_1)}_{sample\, radiance\, evaluation\, in\, stage2}
+\\\\\\ &=&
+\prod_{i=3}^{k-1}(\underbrace{\dfrac{f_r(x_{i+1}
+\rightarrow x_i
+\rightarrow x_{i-1})G(x_i
+\longleftrightarrow x_{i-1})}{p_a(x_{i-1})}}_{stored\,in\,vertex\, during\,light\, path\, tracing\, in\, stage1})\dfrac{G(x_k
+\longleftrightarrow x_{k-1})L_e(x_k
+\rightarrow x_{k-1})}{p_a(x_{k-1})p_a(x_k)})
+\end{array}
+\]`

 	expected := input
 	actual := Parse(t, input)

Second, I don't think we're going to know the impact, if any, of splitting one paragraph into two paragraphs until we get this into the field. I suspect it will be fine.
Third, can you re-purpose https://github.com/gohugoio/hugo/pull/11866 for the Hugo integration bit? I think we should defer asking for bep's review until both pieces are working.
Again, this looks great!

golang newbie question: how should I test it if the test code is in my repository? go get gives:
        module declares its path as: github.com/gohugoio/hugo-goldmark-extensions/passthrough
                but was required as: github.com/j2kun/hugo-goldmark-extensions/passthrough

I could update https://github.com/gohugoio/hugo/pull/11866 to use my forks in their go.mod, and then change them back before merging. Is there a different recommended way that keeps the code identical, but silently points to my fork (or my local git clone)?

https://go.dev/doc/modules/gomod-ref#replace

https://github.com/gohugoio/hugo/pull/11866 is working, pointing to my local extension in b5ea64e10
Note:

There's no release of this repo, so I put a dummy v0.0.1 for the version in go.mod
The tests pass, but they're only the most basic ones. I don't see much value in replicating all of the tests across the two repos, but you may have some ideas about what else the goldmark parser configured by hugo is doing that we'd want to test in conjunction with this extension.

Another test to add:

passthrough delimiters are not processed inside code fences. (Priority is set less than the code fence block/span priority)

I am finding some issues with the integration, will move the discussion to https://github.com/gohugoio/hugo/pull/11866

@jmooring  As an practical note from the side: Assuming you got something that works OK (and the tests are green in this repo), I wouldn't mind just merging this PR into the main branch. This should make integration testing with Hugo a lot easier. This repo is unversioned and in progress, so people should know that it's not done yet.


Fix locale key for Wechatwork webhook

The locale key in the locale files used for the Wechatwork webhook was different from the key used in the template (here). I changed it to fix this text.

Why not just change the template instead?

Would be possible too. I'll change it, wait a moment...


Add analogue watchface, and date on/off option

As in the title, an analogue option with an option to turn the date on/off would be nice.

Already covered in #121 and #131