JWT from login has an expire date in the past

Description
Since the #380 I am unable to use the develop branch of Portainer due to "Your session has expired" messages when attempting to log in. This is due to an expire date of the JWT that lays roughly 24 hours in the past. I suspect there is something going on with timezone difference from Portainer and my client.
For example, it is currently Tue Dec 12 2016 00:08 GMT+0100 (CET).
When checking the JWT expire date (using the jwtHelper that is used to validate it) gives me:
getTokenExpirationDate: Mon Dec 12 2016 03:58:02 GMT+0100 (CET)

This is happening consistently on all my machines.
Steps to reproduce the issue:

Start Portainer (e.g. grunt run).
Create admin account, fill in any password.
Log in with previously entered password.
Log in happens successfully, but the token is instantly expired and you will be logged out.

Technical details:

Portainer version: 0a38bba87449e864f91eeb2e8d9de3c399a721ec
Target Docker version (the host/cluster you manage): 1.12.3
Target Swarm version (if applicable): N/A
Platform (windows/linux): Mac OS
Browser: Chrome, Safari

Could you join us on gitter ? I'll need more information to help you with this one. Also, how do you start Portainer ? Your first step in the reproduction list is run run, there's probably a mistake here.

Validation on the client side is done using https://github.com/auth0/angular-jwt and it should be done in UTC: https://github.com/auth0/angular-jwt/blob/45ab6b4d9c1be87eb6f5654c844d2895529acd2b/src/angularJwt/services/jwt.js#L41
On the server side, the expiration date of the token is determined using time.Now() which will depend on the system time zone: https://github.com/portainer/portainer/blob/develop/api/jwt/jwt.go#L36
Could you update this line with the following value:
expireToken := time.Now().UTC().Add(time.Hour * 8).Unix()

Actually, validation is done on the client side using new Date() which is using the user's local time: https://github.com/auth0/angular-jwt/blob/45ab6b4d9c1be87eb6f5654c844d2895529acd2b/src/angularJwt/services/jwt.js#L54 so this may be the cause here.
I've open an issue on the library to get some answers: https://github.com/auth0/angular-jwt/issues/133

@Glowbal I've added some logging on this branch: https://github.com/portainer/portainer/tree/fix398-jwt-expiration-time
It also includes the change to generate the token date in UTC, could you try it?

Indeed a mistake, I use grunt run and the variations (grunt run-swarm-local etc).
I will give that branch a try and report back.

When trying with that branch I get the following from the logs:
Authentication init. Exp date:
portainer.js:4008 "2016-12-12T05:03:17.000Z"
portainer.js:495 Token has expired. Exp date:
portainer.js:496 "2016-12-12T05:03:17.000Z"
angular.js:118 TypeError: $state.go is not a function
    at portainer.js:497
    at m.$broadcast (angular.js:148)
    at angular.js:356
    at m.$broadcast (angular.js:148)
    at angular.js:116
    at m.$eval (angular.js:145)
    at m.$digest (angular.js:142)
    at m.$apply (angular.js:146)
    at angular.js:20
    at Object.invoke (angular.js:41)(anonymous function) @ angular.js:118(anonymous function) @ angular.js:90$broadcast @ angular.js:148(anonymous function) @ angular.js:356$broadcast @ angular.js:148(anonymous function) @ angular.js:116$eval @ angular.js:145$digest @ angular.js:142$apply @ angular.js:146(anonymous function) @ angular.js:20invoke @ angular.js:41c @ angular.js:20Bc @ angular.js:21fe @ angular.js:20(anonymous function) @ angular.js:317b @ angular.js:189Sf @ angular.js:37d @ angular.js:37

And date returns:
new Date()
Tue Dec 20 2016 11:31:33 GMT+0100 (CET)

There's definitely something wrong on the server side:
portainer.js:496 "2016-12-12T05:03:17.000Z"

Looks like the expiration date is 8 days in the past?! Super strange, could you try to run Portainer outside of a Docker container? I'm not sure if it's related but we should give it a try...
$ grunt clean:all
$ grunt release
$ ./dist/portainer -d /tmp

And then access http://localhost:9000

Also, I've pushed some changes to the branch with some new logging...
I have the following logs in my browser console:
Authentication init. Token expiration date (from jwtHelper, UTC):
portainer.js:4013 "2016-12-21T06:17:38.000Z"
portainer.js:494 Browser date (using Date(), local TZ):
portainer.js:495 "2016-12-20T22:17:40.227Z"

Please rebuild from this branch and have a look at the logs in the console.

@Glowbal could you update this issue with your notes and close it?

The issue was client side. My Docker installation was running with an incorrect system time (yet the host was running with the correct system time). See also https://github.com/docker/for-mac/issues/17.
I've solved it by resetting my Docker install, but I suspect a restart would also be sufficient. For comparison, here is the output I got from the new branch after I reset Docker:
Authentication init. Token expiration date (from jwtHelper, UTC):
portainer.js:4013 "2016-12-22T18:57:30.000Z"
portainer.js:494 Browser date (using Date(), local TZ):
portainer.js:495 "2016-12-22T11:14:19.764Z

So this was an issue that only appeared with Portainer because of the expiration date, but is not caused by Portainer. Thanks for your help @deviantony.


Tool for generating name private keys from backup phrase

It's possible for a user to both register a name and send a name from Onename to the same address, and end up in a situation where the same address owns two names.  The browser does not know how to handle this.
What is needed is a tool to translate the user's backup phrase into their owner and payment private keys.  Then, the user can use the CLI tool to transfer one of the names to a different identity address.

Thanks @jcnelson. I also wonder if there are legitimate use cases for an address to own multiple names.

We already have a branch in the browser that starts to do this: https://github.com/blockstack/blockstack-browser/tree/feature/migration-tool
@kantai has also done work on this in https://github.com/blockstack/blockstack-browser/issues/537 as well

@jasonnovack tried to answer your question here: https://forum.blockstack.org/t/transfer-username/2479/5?u=larry

Addressed here: https://github.com/jcnelson/cli-blockstack

I also added a PR for the browser to show your public key on the keychain backup page: https://github.com/blockstack/blockstack-browser/pull/1308


Documentation for Fault Injection Percentage is incorrect

(This is used to request new product features, please visit https://discuss.istio.io for questions on using Istio)
Describe the feature request
The examples in the documentation for Fault Injection ( https://istio.io/docs/reference/config/networking/v1alpha3/virtual-service/#HTTPFaultInjection-Abort and https://istio.io/docs/reference/config/networking/v1alpha3/virtual-service/#HTTPFaultInjection-Delay) is misleading.  It gives examples for for setting faults for 1 out of every 1000 requests and lists the value at 0.001, but the percentage documentation (https://istio.io/docs/reference/config/networking/v1alpha3/virtual-service/#Percent) says the value should be between 0.0 and 100.0.
I was attempting to do some fault injection with a value of 0.25, which I believed to be 25%, but it was almost never being hit.  When I changed it to 25.0, it worked ~25% of the time.
If the 0.001 were changed to 0.1, that'd clear up any confusion users might have.
Describe alternatives you've considered
Additional context

@frankbu can you look at this?

Fixed by https://github.com/istio/api/pull/886

Thanks @frankb!  @stevelowery, pls check the preliminary.istio.io doc and reopen if this is not fixed.


sql_mode specification is not applied in ActiveRecord v7.0.6

Steps to reproduce
It seems that various settings including sql_mode are not applied correctly because configure_connection is not executed.
# frozen_string_literal: true

require "bundler/inline"

gemfile(true) do
  source "https://rubygems.org"

  git_source(:github) { |repo| "https://github.com/#{repo}.git" }

  gem "rails", "= 7.0.6"
  gem "activerecord-trilogy-adapter"
  gem "mysql2"
end

require "active_record"
require "minitest/autorun"
require "logger"

ActiveRecord::Base.logger = Logger.new(STDOUT)

class BugTest < Minitest::Test
  def test_mysql2
    ActiveRecord::Base.establish_connection(adapter: "mysql2", database: "test", username: "root", host: '<IP_ADDRESS>', port: 3306, variables: { sql_mode: "STRICT_ALL_TABLES" })
    assert_equal ActiveRecord::Base.connection.execute('SELECT @@SESSION.sql_mode;').to_a, [["STRICT_ALL_TABLES"]]
  end

  def test_trilogy
    ActiveRecord::Base.establish_connection(adapter: "trilogy", database: "test", username: "root", host: '<IP_ADDRESS>', port: 3306, variables: { sql_mode: "STRICT_ALL_TABLES" })
    assert_equal ActiveRecord::Base.connection.execute('SELECT @@SESSION.sql_mode;').to_a, [["STRICT_ALL_TABLES"]]
  end
end

Expected behavior
Both mysql2 and torilogy, sql_mode is correctly applied as specified in the DB connection settings variables.
Actual behavior
mysql2 correctly applies sql_mode.
However, trilogy applies the default sql_mode.
Failure:
BugTest#test_trilogy [main.rb:29]:
--- expected
+++ actual
@@ -1 +1 @@
-[["ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION"]]
+[["STRICT_ALL_TABLES"]]

It seems to be due to the fact that the Trilogy Adapter assumes https://github.com/rails/rails/pull/44591.
Current release versions, including Rails v7.0.6, do not include this fix and will not work properly.
System configuration
Rails version: v7.0.6
Ruby version: v3.2.2
trilogy version: v2.4.1
activerecord-trilogy-adapter: v3.1.0

Hi, Tomohiko Mimura!  Thank you for your research with this issue.  Have put together PR #56 with hopes it might offer a comprehensive fix.
Many thanks for your contributions to ActiveRecord Trilogy Adapter!


problem with dependency replacement (kilic/bls12-381 -> trustbloc/bls12-381)

What I'm trying to do
I am trying to use the aries-framework-go to run a mediator and thus importing the aries-framework-go (v0.1.5) as dependency in the module of the application.
Expected result
I would expect the application to run without any framework related problems when adding the framework as dependency.
Actual result
When trying to run the mediator-agent I get the following errors:
# github.com/hyperledger/aries-framework-go/pkg/doc/bbs/bbs12381g2pub
../../../../go/pkg/mod/github.com/hyperledger/aries-framework-go@v0.1.5/pkg/doc/bbs/bbs12381g2pub/bbs.go:216:18: undefined: bls12381.Fr
../../../../go/pkg/mod/github.com/hyperledger/aries-framework-go@v0.1.5/pkg/doc/bbs/bbs12381g2pub/bbs.go:233:13: undefined: bls12381.Fr
../../../../go/pkg/mod/github.com/hyperledger/aries-framework-go@v0.1.5/pkg/doc/bbs/bbs12381g2pub/bbs.go:243:66: undefined: bls12381.Fr
../../../../go/pkg/mod/github.com/hyperledger/aries-framework-go@v0.1.5/pkg/doc/bbs/bbs12381g2pub/bbs.go:252:60: undefined: bls12381.Fr
../../../../go/pkg/mod/github.com/hyperledger/aries-framework-go@v0.1.5/pkg/doc/bbs/bbs12381g2pub/bbs.go:280:6: undefined: bls12381.Fr
../../../../go/pkg/mod/github.com/hyperledger/aries-framework-go@v0.1.5/pkg/doc/bbs/bbs12381g2pub/fr.go:16:28: undefined: bls12381.Fr
../../../../go/pkg/mod/github.com/hyperledger/aries-framework-go@v0.1.5/pkg/doc/bbs/bbs12381g2pub/fr.go:20:15: undefined: bls12381.Fr
../../../../go/pkg/mod/github.com/hyperledger/aries-framework-go@v0.1.5/pkg/doc/bbs/bbs12381g2pub/fr.go:24:33: undefined: bls12381.Fr
../../../../go/pkg/mod/github.com/hyperledger/aries-framework-go@v0.1.5/pkg/doc/bbs/bbs12381g2pub/keys.go:33:6: undefined: bls12381.Fr
../../../../go/pkg/mod/github.com/hyperledger/aries-framework-go@v0.1.5/pkg/doc/bbs/bbs12381g2pub/signature_message.go:15:6: undefined: bls12381.Fr
../../../../go/pkg/mod/github.com/hyperledger/aries-framework-go@v0.1.5/pkg/doc/bbs/bbs12381g2pub/fr.go:24:33: too many errors

When trying to add the required dependency via go get I get the following error:
% go get github.com/trustbloc/bls12-381
go: github.com/trustbloc/bls12-381 upgrade => v0.0.0-20201104214312-31de2a204df8
go get<EMAIL_ADDRESS>parsing go.mod:
	module declares its path as: github.com/kilic/bls12-381
	        but was required as: github.com/trustbloc/bls12-381

Working workaround
When I declare the replacement (which is also defined in the go.mod of the framework) I get the application running:
module mediator-test/v1

require github.com/hyperledger/aries-framework-go v0.1.5

replace github.com/kilic/bls12-381 => github.com/trustbloc/bls12-381 v0.0.0-20201104214312-31de2a204df8

go 1.15

I am not that familiar with Golang (yet), so I am curious whether this behavior is desired. I personally wouldn't expect that it is needed for application developers to define the replacement by themselves when relying on a specific dependency which already replaces it.

Related: https://github.com/hyperledger/aries-framework-go/issues/2247

@kdimak Please ensure that users of the framework do not have build errors when replace isn't used.

@marc0olo This replace has been removed in the latest commit.


Add website

Create a website to make it like this one

My bad @AJ-54 ! We want a simple website where there exists a search bar for searching CS concepts.

Can you please elaborate on what you want for website?

We just want some more details to solve this issue... @the-ethan-hunt

@fliptrail , @AjaySharvesh3  we want a simple search bar on the webpage where on typing a single letter (eg, B for Bazel gives Bazel etc), there would appear links which would re-direct to the article pages.
** TL:DR: A search page like Google Search**

Can I work over this issue?


SWESARR Tutorial Update

Updated SWESARR Tutorial. Includes comparison to SWE values provided by SnowExSQL and a few extra visualizations for comparing SWE and SWESARR data.
The default RAM allocation (2GB) for CryoInTheCloud can't handle the final figure generated by this notebook. This is poor memory management on my part. I've commented out the figure for the tutorial. Currently, this notebook uses roughly 1GB of RAM.
Most libraries are contained by default via CryoInTheCloud but SnowExSQL isn't. This may be an issue with merging to the main branch.

Hi @scottyhq, sorry for the very, very late contribution from me.
Looks like the following error is keeping me from merging:
/home/runner/work/website-2024/website-2024/book/tutorials/swesarr/swesarr_tut.ipynb:530003:
WARNING: 'myst' cross-reference target not found: 'Table-of-Contents' [myst.xref_missing]

Hi @scottyhq
Website seems to render fine. I think the errors are related to hvplot rendering:
WARNING: skipping unknown output mime type: application/vnd.holoviews_load.v0+json
All the same, figures are generated A-ok for this tutorial.
For my laptop, the figures could do with some shrinking in the width to fit more cleanly on the website page. Other than that, I don't think there's any issues.

The default RAM allocation (2GB) for CryoInTheCloud can't handle the final figure generated by this notebook.

Feel free to show people how to launch a larger server during your tutorial!

I think the errors are related to hvplot rendering:
WARNING: skipping unknown output mime type: application/vnd.holoviews_load.v0+json

#16 should've fixed this

Most libraries are contained by default via CryoInTheCloud but SnowExSQL isn't.

We plan to update the default image to include this and other updated libraries today or tomorrow (https://github.com/CryoInTheCloud/hub-image/pull/125).

Thanks for catching these errors, @scottyhq. I'll address these suggestions, probably tweak the size of the figures so they fit more cleanly on the website, and merge on through tomorrow. Thanks especially for the tips here and catching that dead link I glanced over.

Alright, I think that's everything. Thank you so much, @scottyhq !


const _ßr = require("tst-reflect"); // SyntaxError: Identifier '_ßr' has already been declared

I am using yarn workspaces, project structure is like this
@megarepo/backend
@megarepo/shared
backend imports from shared.
I have added the tst-reflect setup to both packages, and I'm using ts-patch.
My use case is reflecting the type names from shared when they are passed as generic arguments to calls in backend. Things seemed to be working OK, I can compile the shared project and use gettype(), however now it looks like require("tst-reflect") is being injected into all of the .js files in dist, the error below occurs when I try to run build backend:
\rootpath\packages\shared\dist\SharedClass.js:6
const _ßr = require("tst-reflect");
      ^

SyntaxError: Identifier '_ßr' has already been declared

Initially I was able to build and run both packages and reflect some type names, but I noticed generic type arguments didn't work so I omitted that code, and the next build failed. The line number referred to in the error doesn't contain _ßr = which may suggest an issue with the transformer.
There's a lot going on, so generating a repro may be a challenge, I am hoping this is a known issue with a fix, but I will do my best if required.

Identifier '_ßr' has already been declared

How is that even possible? It means there are multiple declarations in the same scope.
Which build tool You use and what's the target, module?

I am hoping this is a known issue with a fix, but I will do my best if required.

Nope. I see this for the first time. There is an opposite issue that _ßr is not declared after hot reloads in some build tools.
If You can create simple repro, it would be nice. 🙂

How is that even possible? It means there are multiple declarations in the same scope.

Actually your question raises an interesting point. Most of the files where the duplicates are being flagged don't import or require tst-reflect, in fact nothing in the shared package does at present.
At one point when I was testing reflection to see it working within a single package, I saw the _Identifier 'ßr' has already been declared error, and it looked like an additional require had been inserted at line 0, while I had explicitly imported at line 2. Removing the comment on line 0 resolved the issue.
I have created a gist of the shared package tsconfig:
https://gist.github.com/mribbons/3ad4731ba2b1ce81b5e05e0555c9c4c8
shared package build command:
tsc -p tsconfig.json --watch --preserveWatchOutput
backend package run command:
ts-node index.tsx
Repro won't appear for 18 hours or so ;)

The problem goes away when I run rimraf tsconfig.tsbuildinfo on the shared package.


Uncaught TypeError: Cannot read property 'offset' of undefined

When I turn on destroyOnInfinity I get an exception in _checkIfInView after all the data has loaded and presumably the loader has been deleted. Everything is working fine since the data has already been loaded, but it seemed like there is something worth looking in to.
Exception:
Uncaught TypeError: Cannot read property 'offset' of undefined_checkIfInView @ infinity-loader.js:45

Line in question:
var selfOffset = this.$().offset().top;

Template:
{{resources-list resources=model}}
{{#infinity-loader infinityModel=model destroyOnInfinity=true}}
  <i class="fa fa-circle-o-notch fa-spin fa-2x" />
{{/infinity-loader}}

Thanks for filing the bug, I've seen this too, and the fix seems trivial. In my case I've removed the destroyOnInfinity property and handle hiding the infinity loader using CSS (the .reached-infinity class gets added to the .infinity-loader when infinity is reached.
:+1: for a fix

Thanks for the workaround

thanks @bryanhickerson !  should be a simple fix!  :+1: for this work around for now

Hey I was not using the destroyOnInfinity flag but I still run into this issue when I  run Ember test suite on pages that have infinity scroll. It is not reproducible consistently but I  see this quite often.
Could you give me any clue as to why this occurs and what is happening here...
I updated to 0.2.1 V hoping it will fix the issue but no luck!
@bryanhickerson @davidgoli @hhff

@venkz The same issue here. Even not using destroyOnInfinity the problem ocurs.

I have the same issue. It happens when component is destroying.
PR #138 is addressing this but I don't think it's doing the right think. It should check for this.isDestroying flag instead of this.isDestroyed.

@ilucin :+1:

Quick hack (until this gets resolved) is to reopen InfinityLoaderComponent and override _shouldLoadMore(). I did it in my project like this.
I've also created a PR #145 to fix this correctly.


Release 3.0.0 broke column sorting

Appears as though column sorting broke with the change to the content area sizing.

Nevermind, gotta click right on the arrow symbol, not just the column header.


Update live with current master

Open Publishing Build Service: The pull request content has been published and here are some changed files links of this time:

Docset 1 - core-docs
https://review.docs.microsoft.com/en-us/dotnet/articles/core/getting-started?branch=pr-en-us-1050
https://review.docs.microsoft.com/en-us/dotnet/articles/core/windows-prerequisites?branch=pr-en-us-1050
https://review.docs.microsoft.com/en-us/dotnet/articles/core/docker/building-net-docker-images?branch=pr-en-us-1050
Please see 7 more published files of this docset in report.

Status: Succeeded.
Open Publishing Report.


Created binarysearch.cpp

this problem has already been solved by another contributor...
but if you have suggestions for that file you can make changes in that file itself


Syn 1.0 - Make sure it works in all browsers again

We need to make sure this works in all modern browsers.

sauce labs in another issue?


Click on addWin FAB causes the app to crash

I haven't seen the LogCat on this yet, but most likely trying to inflate a layout that isn't present. There's nothing else really needed in this popup dialog.

There is a fetchData() call in the middle of the inflation of the dialog that doesn't wait for it's completion.  Instead, should be a call to fetchData() first, spinner animation on separate thread, that when complete will trigger the addWin dialog layout.

Implemented


install: Ensure all formulae are linked

Link formulae that are unlinked and not keg only.

@sjackman - could you please get the review comments fixed?

Looks good but can you write tests?

How do I run the tests in spec/bundle/brew_installer_spec.rb?

bundle exec rake gave these errors with Ruby 2.5.1.
❯❯❯ bundle exec rake
/Users/sjackman/.homebrew/Cellar/ruby/2.5.1/lib/ruby/2.5.0/uri.rb:106:in `require': /Users/sjackman/.homebrew/Cellar/ruby/2.5.1/lib/ruby/2.5.0/uri/generic.rb:212: syntax error, unexpected '.' (SyntaxError)
      @scheme&.freeze
               ^
/Users/sjackman/.homebrew/Cellar/ruby/2.5.1/lib/ruby/2.5.0/uri/generic.rb:335: syntax error, unexpected '.'
      @scheme = v&.downcase
                   ^
/Users/sjackman/.homebrew/Cellar/ruby/2.5.1/lib/ruby/2.5.0/uri/generic.rb:1320: syntax error, unexpected '.'
      if path&.empty?
               ^

Is that expected?

@sjackman I have no idea what's going on there. I'd suggest running with the normal Homebrew or system version of Ruby.

I have the tests working with homebrewed Ruby 2.6.1p33. I'm not sure how much of the following was necessary, but it was sufficient.
brew upgrade ruby
$(brew --prefix ruby)/bin/gem install bundler -v1.17.3
$(brew --prefix ruby)/bin/gem install bundler
$(brew --prefix ruby)/bin/bundle install
$(brew --prefix ruby)/bin/bundle exec rake

ping

I'm defending my PhD thesis next week. Should have time after that to work on this PR again.

I'm defending my PhD thesis next week. Should have time after that to work on this PR again.

@sjackman Good luck 🤞 ❤

@sjackman Gentle bump on this! Shout if I can help at all.

Success!

Thanks again @sjackman!


[lit, lit-element, reactive-element] Prevent standard decorators from being published

As we're considering the standard decorator migration path and potentially creating a hybrid decorator, we don't want to publish them just yet.
We can revert this when we want them published later.
Note: There was a typo in reactive-element's package.json files entry for "/std-decorators/" so this'll need to be fixed if/when we revert this commit.

Oops, tests are breaking because of the change in exports breaks bare module imports.

This is no longer needed. We'll do the next prerelease when hybrid decorators are ready.


Adds log4j-docgen module

Adds a log4j-docgen module whose purpose is to automatically generate the documentation of Log4j components based on annotations in the source code and Javadoc comments.
This initial version:

defines a /META-INF/log4j/plugins.xml plugin descriptor, which is similar in nature to Maven's /META-INF/maven/plugin.xml and uses the same model generator (Modello),
provides a SchemaGenerator that produces a single XML schema from a collection of plugins.xml files.

apache/logging-log4j2#1955

@ppkarwasz, I find it very difficult to understand what this PR does exactly and, maybe more importantly, what it is supposed to deliver. Could you provide some review kit, please? In particular, questions I have:

How is this tool supposed to be used/run?
What are its inputs and outputs?
How does it all work? Modello, SchemaGenerator, configuration.xml, plugins.xml, etc.

I guess, since you are deep in the problem, these might sound obvious to you. But I can assure you that the rest of us have no clue.

@vy,
Here are some suggestions on how to review this PR.
How to review this PR
This PR contains multiple contents that might require review:

The contents of a /META-INF/log4j/plugins.xml file are transformed into Java classes using Modello. These classes are described here: src/main/mdo/plugins.xml
The model should be minimal and the attributes should be rationally named (naming is not my strong suite). An example of a /META-INF/log4j/plugins.xml file is given here: test/resources/META-INF/log4j/plugins.xml

From the model I generate an XSD. The SchemaGenerator accepts multiple plugins.xml files to be merged together. There is actually always an internal file that is added: src/main/resources/org/apache/logging/log4j/docgen/internal/configuration.xml
The generated XSD (cf. src/test/resources/xsd/log4j.xsd) should be powerful enough to easily write a configuration file. Due to the usage of <group> each plugin element contains a <sequence> of sub-elements, i.e. order matter. If you have a solution that accepts elements in any order let me know (all can not contain a group).

Hi @vy,

To check if I get the wiring right, I share my notes below.
1. A to-be-implemented `PluginScanner` generates `plugins.xml` (similar to the one in `test/resources/META-INF/log4j/plugins.xml`) from `log4j-core.jar`, `log4j-layout-template-json.jar`, etc.

2. Modello, provided with `src/main/mdo/plugins.xml`, generates DTOs and an XML reader/writer.

3. We use Modello-generated DTOs and the XML reader to read `plugins.xml`.

4. Using DTOs populated from the XML, we manually generate XSD ourselves.

Correct?

Exactly

plugins.xml file name confusion

I corrected it, thanks.

src/site
src/site is hand-crafted as a showcase, right?

Yes, I will use it later to test the generation of AsciiDoc. The idea is to know the rough structure of the documentation, so that we know what elements we need.
In the showcase documentation attributes and elements are in separate sections for example, so I would like to distinguish the two types.

XML groups
I think the problem you're describing is as follows:
  <complexType name="org.apache.logging.log4j.core.config.LoggerConfig">
    <sequence>
      <group ref="log4j:org.apache.logging.log4j.core.config.AppenderRef.group" minOccurs="0" maxOccurs="unbounded"/>
      <group ref="log4j:org.apache.logging.log4j.core.Filter.group" minOccurs="0"/>
    </sequence>
    <attribute name="name" type="string"/>
  </complexType>

Naively thinking, wouldn't omitting the sequence work? That is,
  <complexType name="org.apache.logging.log4j.core.config.LoggerConfig">
    <group ref="log4j:org.apache.logging.log4j.core.config.AppenderRef.group" minOccurs="0" maxOccurs="unbounded"/>
    <group ref="log4j:org.apache.logging.log4j.core.Filter.group" minOccurs="0"/>
    <attribute name="name" type="string"/>
  </complexType>

Unfortunately the XMLSchema XSD does not allow that. I think we'll need to decide whether writing elements in an arbitrary order is important to users. We can assume for now it isn't and improve the schema later.

I am closing this, since the documentation generator needs some refactoring to account for the generation of human documentation. This will be resubmitted in three more digestible parts:

[ ] A PR for the common infrastructure of schema generation and documentation,
[ ] the schema generator,
[ ] the FreeMarker-based documentation generator.


Update the GTDB schemas to reflect what's actually loaded.

Also update the NCBI schemas for the same reason.

As some people would say, LGTM


Repository importer

We should be able to import a repository with a simple command like: ./go import /path/to/repository/.
This should add the repository to the watching list too.

See #2


revert row edit and dirty row fix

fixed 2 regressions introduced by my previous merges:

Revert row doesn't refresh the data - I cleared the current cell and then later try to use the currentCell.row.
In the edge scenario, you will see dirty indicator for 2 rows - fixed it by defining the dirty row instead of using the currentCell.row. so only the style can be correctly applied to the dirty row.

also, planning to increase the test coverage for this feature.

@MattIrv Actually I don't have to add a new dirtyRow, I was thinking about the scenario when you add a new row, it will first set the row to dirty without any dirty cells, if you scroll away and back to force the redraw, the dirty indicator will be gone.
my recent PR has changed it, a new row won't be added unless you have edited any cells in the new row.
good catch. I don't need it. submitted a new commit and changes looks cleaner now.


Disable firing PageView on history.pushState()

Hi, thanks for all the work on this. Wonderful tools here.
I have a situation where one of my vendors requires the history state to track page views. After testing the history.pushState() toggled both on and off and I am getting the same outcome. Toggled on or off fires the page view but only on the browser side. Not getting a server sibling event fired. The event also comes in with no event id. I added a history change trigger for both gtm.historyChange and gtm.historyChange-v2. Used the gtm.historyChange as an exception trigger in hopes that it would negate the history.pushState(). Added the the gtm.historyChange-v2 as a trigger. This configuration fired page views with server sibling but it still fired the same orphaned page view mentioned earlier. So not sure what is going on with this. Need to be able to fix this or find some trigger that will negate the default one being pushed by history.pushState().
For the orphaned page view coming from history.pushState I don't see anything firing in either the client gtm or server gtm debug mode. just fyi
thoughts?

I am seeing this same issue.

Same here with WIX website. No workaround.


add JoinedFastqManifestPhred33 as a format for joined reads

This seems like it kind of counteracts the distinction between semantic type and format, since there isn't really a difference here between single and joined from a data-structure perspective.
In  my mind we would want to share the formats between SingleEnd and JoinedEnd as it means less code, testing, and transformers.
Granted the current naming is probably confusing.

@ebolyen, that makes sense. It's really just the confusing naming that I'm trying to get around.

What about SingleOrJoinedFastqManifestPhred33 (coupled with deprecating SingleEnd...)?

This is handled here, closing as completed.


Large Manifest file is repeatedly re-created

In a large or poorly-tuned database with a very large number of files, the MANIFEST-nnnn file can grow bigger than the MaxManifestFileSize option. During compaction there are repeated calls to the commit() function in session.go which contains the code:
	if s.manifest == nil || s.manifest.Size() >= s.o.GetMaxManifestFileSize() {
		// manifest journal writer not yet created, create one
		err = s.newManifest(r, nv)
	} else {
		err = s.flushManifest(r)
	}

When the s.newManifest() replacement is unable to reclaim a meaningful amount of space, there will be a call to s.newManifest() on every call to commit(). This in turn causes a large performance degradation of the overall compaction process.
At a minimum the code could check s.manifest.Size() immediately following the s.newManifest() call and log an error message if it was already above s.o.GetMaxManifestFileSize().
Another option would be to store the size of the newly-created manifest in the session struct and then use this as a dynamic limit to avoid calling the s.newManifest() branch again until the size had grown (say) 10% beyond its previous value.

I think this may be fixed in #409.

#409 doesn't fix this issue. I applied a version of that change with some logging:
	if s.manifest == nil {
		// manifest journal writer not yet created, create one
		err = s.newManifest(r, nv)
	} else if s.manifest.Size() >= s.o.GetMaxManifestFileSize() {
		s.logf("DEBUG Before size %d limit %d", s.manifest.Size(),  s.o.GetMaxManifestFileSize())
		// pass nil sessionRecord to avoid over-reference table file
		err = s.newManifest(nil, nv)
		s.logf("DEBUG After size %d", s.manifest.Size())
	} else {
		err = s.flushManifest(r)
	}

The result still shows a newly-created Manifest larger than the maximum size, triggering that code branch over and over again:
14:22:53.095908 DEBUG Before size 173084363 limit 67108864
14:22:53.724776 DEBUG After size 173083903
14:22:53.724803 table@compaction committed F-5 S-6KiB Ke·0 D·16 T·784.956107ms
14:22:53.724830 table@compaction L4·1 -> L5·6 S·14MiB Q·28212574516
14:22:53.724921 table@remove removed @79873147
14:22:53.724948 table@remove removed @79873148
14:22:53.725445 table@remove removed @84289218
14:22:53.725468 table@remove removed @66775554
14:22:53.725483 table@remove removed @66775556
14:22:53.725497 table@remove removed @66775557
14:22:53.725512 table@remove removed @66775558
14:22:53.725526 table@remove removed @66775560
14:22:53.747345 table@build created L5@84289224 N·21313 S·8MiB 0xbd84f684:0xbd850827
14:22:53.762720 table@build created L5@84289225 N·16107 S·6MiB 0xbd850827:0xbd851650
14:22:53.872280 version@stat F·[2 1809 13921 34052<PHONE_NUMBER>425] S·7TiB[202MiB 10GiB 100GiB 242GiB 250GiB 7TiB] Sc·[2.00 5.13 5.13 0.25 6.41 0.39]
14:22:53.872304 DEBUG Before size 173083903 limit 67108864
14:22:54.510743 DEBUG After size 173083443
14:22:54.510789 table@compaction committed F-5 S-6KiB Ke·0 D·12 T·785.935213ms
14:22:54.510813 table@compaction L4·1 -> L5·1 S·6MiB Q·28212574516
14:22:54.513721 table@remove removed @79873149
14:22:54.513754 table@remove removed @66775561
14:22:54.513782 table@remove removed @66775573
14:22:54.513799 table@remove removed @66775574
14:22:54.513820 table@remove removed @66775575
14:22:54.513839 table@remove removed @66775577
14:22:54.513854 table@remove removed @66775578
14:22:54.526575 table@build created L5@84289227 N·17038 S·6MiB 0xbd850827:0xbd851650
14:22:54.652267 version@stat F·[2 1809 13921 34052<PHONE_NUMBER>425] S·7TiB[202MiB 10GiB 100GiB 242GiB 250GiB 7TiB] Sc·[2.00 5.13 5.13 0.25 6.41 0.39]
14:22:54.652286 DEBUG Before size 173083443 limit 67108864
14:22:55.196077 db@close closing
14:22:55.270263 DEBUG After size 173083352
14:22:55.270287 table@commit exiting
14:22:55.270404 db@close done T·74.326254ms

By the way, this DB is from a partially synchronized Ethereum archive node which I'm presently converting to a larger options.CompactionTableSize. It is possible to work around the issue by specifying a larger MaxManifestFileSize in the geth ethdb/leveldb/leveldb.go file.


teacher tool - set module css pattern

The main reason for this PR is to introduce "module css". This is a feature we get with create-react-app that scopes css class names to their module, making it easier to use simple names for css classes and they won't clash with one another.
Module css docs:

https://create-react-app.dev/docs/adding-a-css-modules-stylesheet/
https://css-tricks.com/css-modules-part-1-need/

This PR contains some React changes too, but it is work in progress and will likely change a lot.

I wanted to get these changes out so I can switch gears back to wrangling target theme colors into css variables.

Intrigued by this css modules thing. Will be interesting to try out.

Slight concern it will make debugging css a bit more difficult since the actual class names are different from the ones in the code, but willing to try it out and see if that's actually the case.

Intrigued by this css modules thing. Will be interesting to try out.

Slight concern it will make debugging css a bit more difficult since the actual class names are different from the ones in the code, but willing to try it out and see if that's actually the case.

The generated class names are usually readable enough to figure out where they came from. css sourcemaps would be great. I don't think they exist. Here what .main-panel from MainPanel.module.css looks like: MainPanel_main-panel__F7Z6A


Bump bluebird to ^3.0.5

FWICT, we don't seem to be using anything affected by the breaking changes in Bluebird v3.
Fingers-crossed on this one.


cmvnw: Division by zero

In encountered the following warning during the variance normalization of the speech features:

RuntimeWarning: divide by zero encountered in true_divide

cmvnw
This is probably not the desired behavior, I don't know what the best solution in this case is though.

In your provided example, the variance is zero!! So it returns nan obviously. I am a little bit confused!

After performing variance normalization you should return a vector that has unit variance. That's not possible in this example without changing the properties of the vector. But I would still try to avoid dividing by zero. At least when training a neural network you want to avoid having NAN values in your feature vector.
Would it be possible to set the calculated variance to a minimum value, for example with doing the following:
window_variance = np.maximum(window_variance, np.finfo(np.float32).eps)
This would at least avoid dividing the vector by zero and (if I understood it correctly) is also the way kaldi handles this situation.

@thomasZen Thanks for point it out. I will try to hit the root problem and provide a better solution.

@thomasZen The problem has been resolved! Please check and give your feedback here.
Thanks


ONAV-957

Added the option to extend the URDF with the OutdoorNav links. Including:

Starter Kit
Standard Kit
Custom

New dependency: cpr_onav_description

@tonybaltovski can these check be rerun now that the cpr_onav-description has been released


Small Bug

Guys, I found a small issue in the program. In one of the sections, it is given like we cannot pass the single quotas to the program but I have passed single quotas and none of the error raised. Also the program is compliled and I moved forward to the next lesson. Please look into this.
Challenge Name

Its in the first animation section, that is for animated bounce.
Issue Description

I just tried passing single quotas and it moved forward.
Browser Information

Latest Version of Google Chrome

Browser Name, Version:  Google Chrome
Operating System: Windows 7
Mobile, Desktop, or Tablet:  Desktop

Screenshot

@akhilnandu thanks for the issue, but I'm closing this as a duplicate of https://github.com/freeCodeCamp/freeCodeCamp/issues/14207. Happy coding!


First commit JQuery

Started jquery

Thanks dude!

no problem I like helping others. you helped me alot. ill work on more code
ones
On Fri, Oct 9, 2015 at 8:24 AM, Edvins Antonovs<EMAIL_ADDRESS>wrote:

Thanks dude!
—
Reply to this email directly or view it on GitHub
https://github.com/ummahusla/codecademy-exercise-answers/pull/13#issuecomment-146902706
.


Expose a jupyter_server pytest plugin

This PR moves the conftest into the jupyter_server module and exposes an entrypoint to that module to enable extensions to use these helpful fixtures for testing.
To use these fixtures, you simply have to add pytest_jupyter_server to the pytest_plugins list in any test suite.

@Zsailer Strange: Failing for windows py 3.8 on appveyor while succeeding on github actions. I can't remember we had such cases during our sprint to make tests green a few weeks ago...?
self = <ProactorEventLoop running=False closed=False debug=False>, fd = 736
callback = <bound method BaseAsyncIOLoop._handle_events of <zmq.eventloop.ioloop.ZMQIOLoop object at 0x00000099447949D0>>
args = (736, 4)
    def add_writer(self, fd, callback, *args):
>       raise NotImplementedError
E       NotImplementedError
c:\miniconda37-x64\envs\test-env-38\lib\asyncio\events.py:507: NotImplementedError

The print message you have added shows exactly the same information: win32 sys.version_info(major=3, minor=8, micro=0, releaselevel='final', serial=0)
Maybe @kevin-bates can help here?

Hm, this was really weird. I changed a few things:

I removed ipykernel from the conda install list. I don't know why, but it appears the conda version of ipykernel was being used over the source version we cloned+installed later in the CI script.
I removed to "windows +Python 3.8" conditional from the plugin. This condition is already checked by the _init_asyncio_patch in serverapp, so it was redundant to check for conditional again. It avoids adding extra confusion to whether the patch is applied before or after the fixture is initialized...

Anyways, getting all greens now. Whoever wants to review, go ahead and squash and merge if you find no issues.
@echarles, you should be able to start using this for your jupyterlab_server branch. For an example on how to use this plugin, checkout the conftest file from nbclassic in Zsailer/nbclassic#4

LGTM. Merging now.
Thx @Zsailer, this was not an easy one. I will start using the plugin for the jupyterlab_server tests.


Create a new release?

Hi - it would be useful to get https://github.com/ulucinar/kubectl-edit-status/commit/37b654f4d3baa59a914fafe7e1ff45f98ead142e in a release. Thanks!

Hi @amuraru,
Thank you for your request. I have released v0.2.0 containing the fix you mentioned. And here is the krew-index PR that will hopefully publish v0.2.0 in krew-index repo:
https://github.com/kubernetes-sigs/krew-index/pull/1258
I will report back here if the krew-index PR gets merged.

Hi,
https://github.com/kubernetes-sigs/krew-index/pull/1258, which bumps edit-status version to v0.2.0, has been merged successfully.

Big thanks!

Awesome plugin by the way!

Thank you @amuraru, that's very kind of you.


Provide mock ERC-20 and ERC-721 contracts

In OpenZeppelin v5, they have made the ERC20 and ERC721 contracts abstract:
https://github.com/OpenZeppelin/openzeppelin-contracts/blob/793d92a3331538d126033cbacb1ee5b8a7d95adc/contracts/token/ERC20/ERC20.sol#L34
This means that for testing purposes we all need to define a dummy ERC-20 contract like this:
// SPDX-License-Identifier: GPL-3.0-or-later
pragma solidity >=0.8.20;

import { ERC20 } from<EMAIL_ADDRESS>
contract ERC20Mock is ERC20 {
    constructor(string memory name, string memory symbol) ERC20(name, symbol) { }
}

The same requirement applies to ERC-721.
It would be helpful if Forge Std provided these mocks for users so they don't end up re-implemented all over GitHub.

I can work on this, but I don't think it would be a good decision for forge-std to have openzeppelin installed as a dependency.
The only way to make it work is to copy and paste the ERC20 and ERC721 contracts into a mock dir.
wdyt?

Great point @andreivladbrg; let's see what @mds1 and other Forge Std contributors have to say.

This seems like a good idea. Agreed with the requirement of not adding and dependencies to forge-std.
Similar to the interfaces directory, these should not be imported anywhere by default to avoid impacting compilation times, so they can live as standalone contracts in src/mocks/
One consideration is the tokens added should support solidity 0.6.2 through 0.8.x. This means we'll have to implement checked math in the token directly, so we likely just can't copy an existing token out of the box. The easiest is probably to copy solmate's because it's a flat file and easy to read, then edit it to add checked math. The file should have comments indicating it's not for use in production, and include a comment with permalink to the original source it was based on.
What devex do you think this better here?

Include permissionless mint(address to, uint256 amount) and burn(address from, uint256 amount) methods to make it clear it's a mock
Keep it as a standard token with no mint/burn functionality and use deal to set balances. With this approach, users will likely want to use the deal(address token, address to, uint256 give, bool adjust) version with the last arg as true to ensure total supply is updated, otherwise it will stay at zero

I think I lean towards (1) but curious to hear opinions.
@andreivladbrg I've assigned this to you since you mentioned you can work on it, if that's no longer the case just let me know!

This means we'll have to implement checked math in the token directly

I think this is the case only for ERC20 balances, and not for ERC721 counters, am I right?

I think I'd lean towards (2) to keep the token minimal

I agree, we should go for option 2.

I've assigned this to you since you mentioned you can work on it,

Yes, will work on this

also agree that option (2) is the way to go


[Release Checklist] 2.6.0

[ ] OpenShift Pipeline
[ ] Konvoy Pipeline
[ ] Native K8s Pipeline
Upgrade Pipelines [spc/cstor/jiva]

[ ]  1.5 to 2.6.0
[ ]  1.6 to 2.6.0
[ ]  1.7 to 2.6.0
[ ]  1.8 to 2.6.0
[ ]  1.9 to 2.6.0
[ ] 1.10.0 to 2.6.0
[ ] 1.11.0 to 2.6.0
[ ] 1.12.0 to 2.6.0
[ ] 2.0.0 to 2.6.0
[ ] 2.1.0 to 2.6.0
[ ] 2.2.0 to 2.6.0
[ ] 2.3.0 to 2.6.0
[ ] 2.4.0 to 2.6.0
[ ] 2.5.0 to 2.6.0

cspc/cstor csi volume upgrade

[ ] 1.10.0 to 2.6.0
[ ] 1.11.0 to 2.6.0
[ ] 1.12.0 to 2.6.0
[ ] 2.0.0 to 2.6.0
[ ] 2.1.0 to 2.6.0
[ ] 2.2.0 to 2.6.0
[ ] 2.3.0 to 2.6.0
[ ] 2.4.0 to 2.6.0
[ ] 2.5.0 to 2.6.0

ZFS Upgrade Pipelines

[ ]  0.4.1 to 1.4.0
[ ]  0.5 to 1.4.0
[ ]  0.6.1 to 1.4.0
[ ] 0.7.0 to 1.4.0
[ ] 0.8.0 to 1.4.0
[ ] 0.9.2 to 1.4.0
[ ] 1.0.0 to 1.4.0
[ ] 1.0.1 to 1.4.0
[ ] 1.1.0 to 1.4.0
[ ] 1.2.1 to 1.4.0
[ ] 1.3.0 to 1.4.0

Migration spc pool to cspc and cstor volume to cstor csi volume

[ ] 1.12.0 to 2.6.0
[ ] 2.0.0 to 2.6.0
[ ] 2.1.0 to 2.6.0
[ ] 2.2.0 to 2.6.0
[ ] 2.3.0 to 2.6.0
[ ] 2.4.0 to 2.6.0
[ ] 2.5.0 to 2.6.0

Manual Validation

[ ] Helm chart validation

DogFooding

[ ] Gitlab production cluster

Release tagged images
openebs/node-disk-exporter:1.2.0
openebs/node-disk-operator:1.2.0
openebs/node-disk-manager:1.2.0

openebs/zfs-driver:1.4.0

openebs/migrate:2.6.0
openebs/linux-utils:2.6.0
openebs/upgrade:2.6.0
openebs/cstor-webhook:2.6.0
openebs/cstor-pool-manager:2.6.0
openebs/cstor-volume-manager:2.6.0
openebs/cspc-operator:2.6.0
openebs/cvc-operator:2.6.0
openebs/cstor-csi-driver:2.6.0
openebs/provisioner-localpv:2.6.0

openebs/velero-plugin:2.6.0
openebs/snapshot-provisioner:2.6.0
openebs/snapshot-controller:2.6.0
openebs/openebs-k8s-provisioner:2.6.0
openebs/admission-server:2.6.0
openebs/m-upgrade:2.6.0
openebs/m-exporter:2.6.0
openebs/cstor-volume-mgmt:2.6.0
openebs/cstor-pool-mgmt:2.6.0
openebs/m-apiserver:2.6.0
openebs/jiva:2.6.0
openebs/cstor-istgt:2.6.0
openebs/cstor-pool:2.6.0


Update sbt-crossproject, ... to 1.2.0

Updates

org.portable-scala:sbt-crossproject
org.portable-scala:sbt-scalajs-crossproject

from 1.1.0 to 1.2.0.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.portable-scala" } ]

labels: sbt-plugin-update, early-semver-minor, semver-spec-minor, commit-count:1

Codecov Report

Merging #628 (448e868) into master (74a1410) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #628   +/-   ##
=======================================
  Coverage   62.54%   62.54%
=======================================
  Files          39       39
  Lines        1303     1303
  Branches        7        7
=======================================
  Hits          815      815
  Misses        488      488

Continue to review full report at Codecov.

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


Sign-in journey content updates

See https://dfedigital.atlassian.net/browse/CPDRP-815?atlOrigin=eyJpIjoiMmQyOWMwMGE3YzAzNDk2Mjk1YTZlYjI4ZTQ4M2VhMDUiLCJwIjoiaiJ9 for details.

@etheya - I've made the changes requested. Could you re-review please?

Cant do the list items without hte lead in paragraph... :-)

I've changed this to a numbered list, no lead-in needed: https://design-system.service.gov.uk/styles/typography/#numbered-lists


Investigate how pip translates requirements.txt and gets packages from the PyPi Index

Related to #7 and #8, just that we need to translate the requirements,txt file (and maybe give it a easier usage in the CLI, something like pip.rs install requirements or something like that) so that we can get the package the requirements.txt file requires from the PyPi index
Notes

Each wheel for PACKAGE is stored in https://pypi.org/simple/PACKAGE/

The wheel and tarball of PACKAGE have a data-requires-python attribute in them
Example: data-requires-python=">=3.6"

Will edit this issue for every finding I get

seems great, surely will consider it:)

btw, if you are interested in solving this issues, you can assign yourself

How do I do that?

@Allstreamer's pull about the JSON API could handle the grabbing the URL to the wheel part

There's no ratelimiting on the API so it would be an easy way to get information for packages / the wheel_url
More info on Ratelimits For Pipy

Look into pip freeze or https://github.com/bndr/pipreqs.


Bigger default font, unserifed "10", and option to display suit next to rank

Hi! Thanks for making this package.  I have made a few improvements that I hope you'll like!

The default font is too small compared to actual cards online.  It was nigh on illegible when viewing all 52 cards in a solitaire game.  I understand this is because we have to have a consistent font size, and we had to fit the widest text "10" in the side space, so all other text suffers.  If Flutter came with multiple default fonts, we could pick a font closer to a normal narrow playing card font, but Roboto is all we've got, with its wide characters and its serifed "1".

So I replaced "10" with "I0" (capital i, zero) instead, both on the rank 10 card and in the getGoodFontSize calculation.  Now "I0" takes as much width as "10" did before, but can be a larger font.  The result is that all other cards are much more legible and closer to the size one would see on a real deck of cards (and the "10" is unserifed just like on real cards.)

I am writing a Freecell solitaire game, which requires vertical cascades of cards where you have to see the suit.  Putting the suit to the right of the rank, rather than below it, would allow much more overlap between cards -- you only have to see the top little bit of the card to know its rank AND suit.  I added a suitBesideLabel style option, defaulting to false, that lets the cards display the suit next to the rank instead, and in which the card center is rendered slightly smaller so the suit doesn't overlap with it.

Note that with the font size change, the magic numbers no longer strictly are based on measurements of real cards, as your comment reports.  I didn't change the comment though :)

I thought I would need getGoodFontSize to support either fit by height or fit by width, before I realized fit by width would work just fine even when suitBesideLabel is true.  By the time I realized it, I had refactored getGoodFontSize.  I've left the refactor in place because it's less code, commented a little more, and I think simpler to follow.  Let me know if I should revert that file instead.

I did some drive-by fixing of warnings reported by VS Code (removing redundant imports) and let VS Code do some reformatting to match the default Flutter formatter.  I actually don't know how to NOT reformat upon save in VS Code (I'm new to this IDE) :)

I haven't added the flag to the docs yet as I wasn't sure if you'd accept it.  If so I'd be happy to take a crack at that as well.

Sorry that I rolled 2 features and some code cleanup into a single PR!  If you'd rather they come separately I can do that too.

This is great! Thanks so much.

The "10" vs "I0" is a little strange, but also makes sense given your reasoning. Perhaps eventually, this could be a style option.

  Maybe if we support the serifed style option we could also include a font dependency for a narrow font.
Thanks for merging!


Dataclass conversion error (regression introduced on 0.7.6)

Environment information

OS:  linux
Python Version: 3.11.9
ape and plugin versions:

$ ape --version
# 0.7.15

$ ape plugins list
# Installed Plugins
  solidity    0.7.1

Contents of your ape-config.yaml:

$ cat ape-config.yaml
# name: regression
default_ecosystem: ethereum
test:
  mnemonic: "test test test test test test test test test test test junk"
  number_of_accounts: 10
compiler:
  ignore_files:
    - "*.md"
    - "*.adoc"
plugins:
  - name: solidity
solidity:
  version: 0.8.24

What went wrong?
A regression was introduced on data class conversion starting version 0.7.6 of eth-ape. Retrieving a struct cause an error TypeError: non-default argument 'datas' follows default argument.
Reproducible example
The following example will cause an error when running ape test with any version >= 0.7.6
Version 0.7.5 is unaffected
Solidity file
//SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract MultiSig {

   struct MultiSigCall {
        uint id;
        address [] targets;
        uint [] values;
        bytes [] datas;
        address [] approvals;
        bool executed;
    }

    mapping(uint => MultiSigCall) multiSigCalls;

    uint public nextProposalId = 1;

    function initMultiSigCall(MultiSigCall memory proposal) public returns(uint) {
        proposal.id = nextProposalId;
        multiSigCalls[nextProposalId++] = proposal;
        return proposal.id;
    }

    function getMultiSigCall(uint proposalId) public view returns(MultiSigCall memory) {
        return multiSigCalls[proposalId];
    }

    receive() external payable {}

    fallback() external payable {}

}

Test file
def test_multisig(accounts, project):

    eoa = accounts[0]
    multisig = eoa.deploy(project.MultiSig)

    original_multisig_call = (0, ['0xf091867EC603A6628eD83D274E835539D82e9cc8'], [0], ['0xa9059cbb000000000000000000000000a5c0067121b222d1303b00bdd750424874e8be6f0000000000000000000000000000000000000000000000000dfdf13250603400'], ['0x3524727d39a6344C44a33Ea99862c8791a703D25'], False)

    multisig.initMultiSigCall(original_multisig_call, sender=eoa)
    multisig_call = multisig.getMultiSigCall(1) # this fails with any version >= 0.7.6

Trying to figure out what EVM version to use as well what provider.

Tried running on ::test but getting Invalid opcode 0x5e @ 2297
Tried running on ::foundry but got EVM error NotActivated
** Ran foundryup and retried: was able to reproduce!

figured out it is related to values in the struct conflicting with values method.

@antazoey Thank you ! I suggest to ask for the test provider in the bug report template. It completely skipped my mind.

@antazoey is this closes by #2009?


[CocoaPods] OSX compatibility

Hello,
This library is great for the iOS project, but it would be even greater if we can use it for OS X too since it shouldn't be a technical limit.
Can you update your pod to handle OS X support too ?

I create a PR in order to fix that #7
It could be great if you merge it, and then releasing a new pod version.
Until then, if anyone need, you can use my fork in your podfile:
pod 'GBVersionTracking', :git => 'https://github.com/tbaranes/GBVersionTracking.git'

@tbaranes thanks for that! I've merged it and will push to trunk as soon as I'm back from holidays

Pushed to trunk as 1.3.1


newline before comparison operator in .lp file format

This is a workaround for this curious cbc bug that I encountered:
https://github.com/coin-or/CoinUtils/issues/144
It seems that the LP file format is not standardized (yay!). However, points 5 and 9 in this lpsolve documentation for the CPLEX LP format and this IBM CPLEX LP format description of constraints agree in that constraints can go across multiple lines. Only the constraint name and its colon (e.g. c1234:) need to appear on the same line, as do the comparison operator and the right-hand side (e.g. >= 5678). And I found this slide deck that refers to the LP file format as developed by CPLEX. So I assume cbc (and the other solvers) will follow these kinds of "format descriptions".
So introducing these newlines should be safe to do and will prevent this bug. To get back the original format, this PR can later be reverted once the issue in CoinUtils (and thus cbc) is addressed. To make this easier, I would squash the commits in this PR during merging.

After extensive digging, I have now found a better workaround using the NativeCbcSolver. However, for this to work, the used cbc currently still has to be patched to avoid a concurrency until a new major version is released. If anybody is looking to use the NativeCbcSolver and running into issues with multiple Cbc instances (on separate problems and on separate threads, but on the same system) running in parallel with some of them randomly crashing, here are solutions that I found:
https://github.com/KardinalAI/coin_cbc/pull/7#issuecomment-786189288
I'll close this issue, because this is only a workaround until a new release of CoinUtils with the recent fixes to the LP input parsing bugs I reported. It's not worth merging this, if it becomes obsolete in the near future and will only cause confusion.


Unable to install due to number of errors

I am using go version go1.3.3 linux/arm and RASPBIAN JESSIE LITE 4.4 on a Raspberry Pi 2 Model B.
When running
go get -u github.com/moul/advanced-ssh-config/cmd/assh
I get this error.
github.com/shirou/gopsutil/host
work/src/github.com/shirou/gopsutil/host/host_linux_arm64.go:7: sizeofPtr redeclared in this block
	previous declaration at work/src/github.com/shirou/gopsutil/host/host_linux_arm.go:7
work/src/github.com/shirou/gopsutil/host/host_linux_arm64.go:8: sizeofShort redeclared in this block
	previous declaration at work/src/github.com/shirou/gopsutil/host/host_linux_arm.go:8
work/src/github.com/shirou/gopsutil/host/host_linux_arm64.go:9: sizeofInt redeclared in this block
	previous declaration at work/src/github.com/shirou/gopsutil/host/host_linux_arm.go:9
work/src/github.com/shirou/gopsutil/host/host_linux_arm64.go:10: sizeofLong redeclared in this block
	previous declaration at work/src/github.com/shirou/gopsutil/host/host_linux_arm.go:10
work/src/github.com/shirou/gopsutil/host/host_linux_arm64.go:11: sizeofLongLong redeclared in this block
	previous declaration at work/src/github.com/shirou/gopsutil/host/host_linux_arm.go:11
work/src/github.com/shirou/gopsutil/host/host_linux_arm64.go:12: sizeOfUtmp redeclared in this block
	previous declaration at work/src/github.com/shirou/gopsutil/host/host_linux_arm.go:12
work/src/github.com/shirou/gopsutil/host/host_linux_arm64.go:16: _C_short redeclared in this block
	previous declaration at work/src/github.com/shirou/gopsutil/host/host_linux_arm.go:16
work/src/github.com/shirou/gopsutil/host/host_linux_arm64.go:17: _C_int redeclared in this block
	previous declaration at work/src/github.com/shirou/gopsutil/host/host_linux_arm.go:17
work/src/github.com/shirou/gopsutil/host/host_linux_arm64.go:18: _C_long redeclared in this block
	previous declaration at work/src/github.com/shirou/gopsutil/host/host_linux_arm.go:18
work/src/github.com/shirou/gopsutil/host/host_linux_arm64.go:19: _C_long_long redeclared in this block
	previous declaration at work/src/github.com/shirou/gopsutil/host/host_linux_arm.go:19
work/src/github.com/shirou/gopsutil/host/host_linux_arm64.go:19: too many errors

I'm in the same boat.

Just added a note about the minimal Golang version in the README (534a01f9f189920204eef4a3b1e8331f4e5c56f0)


Jesse: Watch nassaunationalcable.myshopify.com

Jesse requests the watch of the watch_keyword nassaunationalcable\.myshopify\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

nassaunationalcable\.myshopify\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by cigien in Charcoal HQ


support rails >= 7

do you have a plan to support the latest rails versions?

no, I don't think so.
I think these days multi-database support is already built in Rails, isn't it?


zeroctl: delete legacy copy/delete nondeduped/deduped commands

In issue #204 we added 2 new commands:

g8stor copy vdisk;
g8stor delete vdisks;

They were additional commands in previous milestone, but are now fully replacing the old (legacy) commands:

g8stor copy deduped;
g8stor copy nondeduped;
g8stor delete deduped;
g8stor delete nondeduped;

These 4 legacy commands should now be deleted, as their usage is highly error prone, and non-usable for most of our use cases.

@grimpy Can you let us know when this has been changed so we don't break the existing setups?

@iwanbk @GlenDC Since we are in a new milestone, I think we can safely do this now


bad alignment when add default value in TextField by safari only

CodeSandbox
Safari

Firefox

Chrome

Tech
Version

Material-UI
v3.0.3

React
16.4.2

Browser
Safari 11.1.2 (OS X)

Even stranger - if you type a character in A, delete it, then type again, B will fall into alignment.

Same issue with this demo. https://codesandbox.io/s/rr7zjr7v1m
Here is a simple workaround in https://github.com/mui-org/material-ui/blob/814b7fa70eba15bb708ddc2f6d6f1a7ffabe6527/packages/material-ui/src/FormControl/FormControl.js#L11-L20:
  root: {
    display: 'inline-flex',
    flexDirection: 'column',
    position: 'relative',
    // Reset fieldset default style
    minWidth: 0,
    padding: 0,
    margin: 0,
    border: 0,
+  verticalAlign: 'middle', // Fix an aligment issue on Safari
  },

@shin0602 Do you want to work on it?


feat: As a developer, I want to find the attestation ID prefix for a given network

What does this PR do?
Related ticket
Fixes #606
Type of change

[ ] Chore
[ ] Bug fix
[X] New feature
[ ] Documentation update

Check list

[ ] Unit tests for any smart contract change
[ ] Contracts and functions are documented

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 92.53%.

Additional details and impacted files
@@           Coverage Diff           @@
##              dev     #607   +/-   ##
=======================================
  Coverage   92.53%   92.53%
=======================================
  Files          30       30
  Lines         482      482
  Branches      114      114
=======================================
  Hits          446      446
  Misses         24       24
  Partials       12       12

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


added support for rejectUnauthorized option

Was running into SSL certificate issues for certain requests (unable to verify the first certificate).
The standard https library has an option to ignore this (setting the rejectUnauthorized option to false).
This pull request enables you to pass that rejectUnauthorized option.

These options are passed as a http.Agent, through options.agent, see #15 and #40

ok, missed out on that option, sorry about that!


libsndfile needs to be over version 1.1.0 for this library to work, stream.

The stream method would only work if the version of the libsndfile C library installed on the device is over 1.1.0 (where they introduced support for MP3). As the change was done on libsndfile is "pretty recent" it's very likely a lot of long-term-support OS hasn't migrated yet to that version, and therefore it would make the library unusable for those users.
Given how this is implemented atm (this library basically swallows all the related sndfile exceptions inside the generate_stream method) the error is pretty obscure. It took me a couple of hours of debugging.
Nothing to do on your side @lugia19 , but I believe a note about this on the README.md (the installed libsndfile needs to be over 1.1.0) would be super good for people wanting to use this library (And I believe this library is super useful so I'd expect that a lot of people will use it on the future if the elevanlabs product continues growing on popularity).
Regards.

Good to know. I'll make a note of it on the README, and expose more of the exceptions.
Do you happen to know an OS/distro that's currently using an older version of libsdnfile, so I can check for this exception and properly inform the user?

On my case, because the project I am building runs on raspberry, it happens on the latest raspberry pi OS version. Based on Debian 11, bullseye
While on my macbook it was working out of the box, on raspberry it took me hours of debugging and finally once I updated the libsnd it was working as a charm.

Yes, I didn't notice this was an issue as on windows/macOS the soundfile module automatically installs the most recent libsdnfile  version. A note should be good enough then.


Dev

This is a pre-process script for getting the history of the past three months usage. The usages are organized by the user, lab, and kempner and non-kempner partitions. The result of running this script on the last three months data will help to build the cumulative metrics.

Who is the reviewer on this PR?

creating separate branch and pull request


Fix bug - directed login button to the learn page instead of home page

I directed the login button to the learning dashboard instead of going back to the home page.

Hi @duraanali  I pulled the changed and pushed the changes again


Support for x86_64 Linux

There was a discussion in the tinygo slack channel on the functionality of the net package on non-embedded platforms such as regular Linux platforms on x86_64.
What are the current limitations / issues that we have to overcome that we can use the net package for scenarios where tinygo should be run on desktop/servers that run Linux?
As soon as we figured out the issues, I'd be happy to help with the implementation.

@leongross Here's a start; I think this is on the right track...
loader/goroot.go file controls which std lib pkgs get overridden for tinygo, based on target.  To build on x86_64, we need to not use the tinygo "net" pkg, but rather use the std lib pkg.  I hacked loader/goroot.go to use std lib "net" pkg:
diff --git a/loader/goroot.go b/loader/goroot.go
index ea2f705d..629f1880 100644
--- a/loader/goroot.go
+++ b/loader/goroot.go
@@ -241,14 +241,14 @@ func pathsToOverride(goMinor int, needsSyscallPackage bool) map[string]bool {
                "internal/reflectlite/": false,
                "internal/task/":        false,
                "machine/":              false,
-               "net/":                  true,
-               "net/http/":             false,
+               //"net/":                  true,
+               //"net/http/":             false,

        }

I then tried building a test app using (note the -tags netgo).  It built, but getting linker errors:
$ ~/go/bin/tinygo build -tags netgo  main.go
ld.lld-17: error: undefined symbol: internal/poll.runtime_pollReset
>>> referenced by fd_poll_runtime.go:68 (/usr/local/go/src/internal/poll/fd_poll_runtime.go:68)
>>>               /home/sfeldma/.cache/tinygo/thinlto/llvmcache-9D46EBAE39229B9F538CA31649783F334AB281E6:((*internal/poll.pollDesc).prepare)

ld.lld-17: error: undefined symbol: internal/poll.runtime_pollWait
>>> referenced by fd_poll_runtime.go:84 (/usr/local/go/src/internal/poll/fd_poll_runtime.go:84)
>>>               /home/sfeldma/.cache/tinygo/thinlto/llvmcache-9D46EBAE39229B9F538CA31649783F334AB281E6:((*internal/poll.pollDesc).wait)

ld.lld-17: error: undefined symbol: internal/poll.runtime_pollSetDeadline
>>> referenced by fd_poll_runtime.go:161 (/usr/local/go/src/internal/poll/fd_poll_runtime.go:161)
>>>               /home/sfeldma/.cache/tinygo/thinlto/llvmcache-9D46EBAE39229B9F538CA31649783F334AB281E6:(internal/poll.setDeadlineImpl)

ld.lld-17: error: undefined symbol: getrandom
>>> referenced by os_linux.go:125 (/home/sfeldma/work/tinygo/src/runtime/os_linux.go:125)
>>>               /home/sfeldma/.cache/tinygo/thinlto/llvmcache-9D46EBAE39229B9F538CA31649783F334AB281E6:((*net.Resolver).exchange)
error: failed to link /tmp/tinygo3732967082/main: exit status 1

So the next thing to figure out is why internal/poll didnt' get picked up.
Here's the test app:
package main

import (
        "fmt"
        "net"
)

func main() {
        conn, err := net.Dial("tcp", "localhost")
        if err != nil {
                fmt.Println(err)
        }
        conn.Close()
}

Also, on a parallel topic, there is an effort to use the full "net" pkg with embedded targets.  See https://github.com/tinygo-org/tinygo/pull/4187.

I did some work to enable the sys/unix package syscalls https://github.com/tinygo-org/tinygo/pull/4310. @scottfeldman feel free to have look there as well


Feature/66

Graph linked to json data.
Hierarchy populated.
refactored code to use Map
other minor improvements

The fix for the contributors worked @ddelpiano , it's looking good now
I think I found an unrelated new glitch with this dataset https://cassava.ucsd.edu/sparc/preview/archive/exports/2021-04-12T17%3A28%3A22%2C384227-07%3A00/datasets/N%3Adataset%3A02d6f93c-56cd-471b-bbb9-99f65f47d203.ttl
It's rendering the sparc:Sample nodes twice, or it looks like it is. I think what's happening is that 'sample:sub-9238_sub-9238_sam-1' from the turtle file is rendered as a node and directory 'sub-9238_sam-1' (same name as sample) is also rendered as a node.
In cases like this, where the graph has sparc:samples already with some folders and files, we don't need to display those same folders and files under the subject. We only display the folders and files under the subject if they haven't been added to a sparc:sample node in the graph, we can move this to a new issue if it's going to take a while to do these changes.


Create Corona timelapse

Close #18
This is now complete. I leave the merge of this PR to you @rodrihgh , as the sponsor of the feature

Oops! Small bug, I will tell you

Now it is done

Working on this, two requests to @dieghernan :

The gif has not been updated after https://github.com/dieghernan/RKI-Corona-Atlas/pull/21/commits/76884b0e27d101a5477a4f6f9ffefbeb83d9bd02 , https://github.com/dieghernan/RKI-Corona-Atlas/pull/21/commits/9092464abc948b67ab5d30a666584b4d03e7477d . Do you want to double check?
What about crediting yourself on the gif, something like Credit: @[your twitter/github handle] on the bottom left corner?

Hi @rodrihgh
After https://github.com/dieghernan/RKI-Corona-Atlas/pull/21/commits/00016454df009b049e8cab934734932505c12aa8 request 1) is updated. It didn’t update automatically with the current setup because it was not designed in that way:

Daily snapshots are stored to improve performance. If anything in the map (like colores) is changed then the cache should be rebuilt with  https://github.com/dieghernan/RKI-Corona-Atlas/actions/runs/1979650975
On production, the action just creates the new daily snapshots with the main action and create the gif. It should work

Regarding the other suggestion, I appreciate but I am ok as it is right now 👍🏻


[RFC] Merge with kak-tree-sitter to provide a better out-of-the-box experience?

One of the tree-sitter plugins, kak-tree-sitter seems to be getting some traction.
I believe it would be beneficial for the Kakoune ecosystem if there was a single standard plugin for code intelligence.
Motivation:

It will be easier for users to get going (since it's one plugin instead of multiple, possibly inconsistent ones).
Where there is feature overlap (e.g. highlighting) we can provide a good default experience without forcing the user to choose.
With respect to overlapping features, there'll be no need to worry about version compatibility between the plugins.
It would bundle developer efforts, enabling us to reuse solutions for the problem of "interacting with Kakoune from a long-running process" [^1] [^2] [^3].
Since at least LSP has an infinitely expanding scope, we want to push regular updates. We should make that as smooth as possible for the user, for example by going through the system package manager. Presumably it will be easier for tree-sitter if we take it under our umbrella.
In terms of implementation, it would probably be more elegant for both LSP and tree-sitter to share the same view of the buffer (avoiding potential inconsistencies).
It will be easier to share things like test infrastructure.
There are some learnings from kak-lsp we haven't shared with kak-tree-sitter yet, if they are in the same repo that will be a natural consequence.

[^1]: for example, there should be a single interface for enabling debug logs, to be written to the *debug* buffer.
[^2]: things like kak-lsp crashes are too hard to track down, they should at least show up in the *debug* buffer.
[^3]: kak-lsp.toml is inflexible and clunky; there should be a mechanism to override only some language configs; also it should be possible to do everything in kakrc without the confines of TOML.
Naming
Given it's globally visible, I think kak-lsp is a poor name and I'd like to rename it. So far kakoune-lsp seemed like the obvious choice.
For a general "batteries-included code intelligence" plugin however what we want something like "Language support for Kakoune".
I haven't found a good name, maybe kakoune-langs, kakoune-language-support or kakoune-code-intelligence.
Possible Course of Action
As I haven't started using kak-tree-sitter yet, I'd take my hands off that part of the code.
But I'm happy to do what is needed to get the initial integration done.
The strawman proposal is to

merge the code into a single Git repo (preserving both Git histories)
provide a single binary and config file (though with plans to deprecate it, see [^3]).
(TODO)

FAQ

Why not switch to Helix?

Certainly a possibility however I'd miss the easy extensibility. Kakoune allows us to keep simple things simple and integrates well into a Unix system.

What if I don't want tree-sitter? Or LSP?

We will provide ways to turn them off at run-time and maybe also compile-time.

What happens with existing kak-lsp packages?

If we do the rename we can definitely provide updates under that alias to avoid users installing old packages.

Should we also provide key mappings OOTB?

Not sure, probably not by default though we could definitely make it opt-in to use the recommended mappings.

How do we define the scope of this? What else will be added in future?

For much of the same reasons as above, I would be in favor of adding (optional) features that are either

related to language support and can benefit this (like debugging, possibly via dap cc @jdugan6240?)
or that we need to implement anyway (like snippets; ours is based on a pre-rewrite version of @occivink's kakoune-snippets).
Are there any other examples we can think of.

Background
I've discussed this before with @phaazon and separately @topisani (conversation starting here)

My only question comes from an end user perspective:
In using kak-lsp, I decide on the language server I want to use for the language I’m working in. So would tree-sitter step in for operations that my chosen language server can’t support, or for situations where I haven’t bothered to pick a language server?
I very much agree on the idea that merging them would provide a cohesive experience that handles overlap. I’ve never taken the time to setup kak-tree-sitter because I’ve always used kak-lsp and assumed I would experience weirdness by running at once (don’t know if that even true, but I shied away from even trying it)

To be completely honest, I'm not sure how in favor I am of adding a Debug Adapter Protocol client implementation to kak-lsp (or whatever it ends up being called). The reasons are as follows:

Editing (which LSP and tree sitter both help facilitate) and debugging are very different and have different ui/ux requirements. Handling both in one plugin seems like feature creep to me.
If I'm being honest, I consider kak-dap a failed experiment. While I was able to get quite far with just Kakoune buffers, Kakoune ultimately (by design) doesn't offer the feature set necessary to create a robust debug UI from within Kakoune itself. To that end, I'm actually starting over in a new repository with the idea of using an external TUI interface as the main debug UI, with Kakoune itself mainly serving to fill the "jump to current line" functionality. This would represent a drastic change from how kak-lsp currently works, and I don't think it would be very viable to work this into kak-lsp without a completely new architecture.
While many language servers are fairly easy to install, most debug adapters are actually VSCode plugins, and as a result are a pain to set up outside of VSCode. To that end, I would want to implement a system to help install these for the user to ease this pain (similarly to how vimspector works), something that I don't think kak-lsp wants to do.

For the reasons above, I don't think that including debugging capabilities in kak-lsp would be the best idea. If you want to do it anyway, though, go right ahead 🙂.

I'd like to see a tree sitter feature in core kakoune itself. Regexes are not sufficient for a code editor in 2024. But kakoune moves slowly/conservatively. @mawww -- does tree sitter in kakoune core idea appeal to you ?

I like and support the idea of merging them together.
Example of overlapping features:

show document symbols
jump to a symbol in a current buffer
next/prev symbol
scope highlighting/indent guides
scope folding
syntax highlighting
sticky contexts

There's also another idea to facilitate the community development: extract the code which talks to Kakoune and publish it separately as a Cargo crate + expose C ABI and maybe create bindings for major languages: JS/Python/Java/etc., so people could depend on it and use their preferred languages. Similar to what tree-sitter does.
Idea seems good, but difficult to predict if it actually works practically.

I tried to access the link to the conversation with @topisani , however I was unable to.

@Kratacoa it's available in the discord server, messages in the plugins channel from Jan 22nd onwards

I'd like to see a tree sitter feature in core kakoune itself. Regexes are not sufficient for a code editor in 2024. But kakoune moves slowly/conservatively. @mawww -- does tree sitter in kakoune core idea appeal to you ?

This is probably not happening for multiple reasons, but a main one is very simple - kakoune currently requires no external dependencies, and tree sitter is a fairly complex one.
My suggestion is we keep it external like this, but focus on adding hooks and integration features to kakoune to improve the usability and what we can do externally

Today it's easy to configure kak-tree-sitter and kak-lsp to play well with each other.
Let's keep it this way, leaving both cooking for a while and see how things turn out.
If we face concrete issues that are not easily solved with a shared interface, we can revisit the merge. I'll close this to avoid confusion.
Both projects should stay aware of each other to minimize work duplication.
Some action items:

If we find an overlapping feature that works better in either tree-sitter or LSP, deprecate the worse one.
refactor kak-lsp to extract useful functionality that is not specific to LSP (possible to share in future)
refactor kak-lsp to use kak_command_fifo/kak_response_fifo instead of inflexible single shell processes, to facilitate:

try to find a solution that doesn't need shell processes in the common case (ref https://github.com/mawww/kakoune/issues/4127)
add native Kakoune options to replace kak-lsp.toml. This will add convenience and enable exotic configurations.

extend kak-lsp commit access to motivated contributors, to build up shared ownership

If we find an overlapping feature that works better in either tree-sitter or LSP, deprecate the worse one

A big exception: Basic highlighting is generally better in tree-sitter (faster, and you can write your own queries), but LSP's semantic highlighting can provide things on top that aren't possible with just parsing.
So to get the best of both worlds, you'd want to limit kak-lsp's configuration to just those tokens that require semantic analysis (e.g. tree-sitter highlighting a name as regular variable, while LSP knows that it's defined as a constant).

A big exception: Basic highlighting is generally better in tree-sitter (faster, and you can write your own queries), but LSP's semantic highlighting can provide things on top that aren't possible with just parsing.
So to get the best of both worlds, you'd want to limit kak-lsp's configuration to just those tokens that require semantic analysis (e.g. tree-sitter highlighting a name as regular variable, while LSP knows that it's defined as a constant).

I'm probably ignorant of some details here but one option is to define highlighter precedence by their definition order.
add-highlighter global/tree-sitter ...
add-highlighter global/lsp-semantic-tokens ...
add-highlighter global/user-tree-sitter-queries ...

Later highlighters will be rendered on top of earlier ones.
If such an ordering helps, we can make it the default. Users should not need to care about the order in which they load their plugins.

There is no split between "default tree-sitter" and "user-provided tree-sitter", so there is no issue about potentially undoing user queries. Though that doesn't matter for what I was talking about.
The problems that can arise when combining both highlighters are:

Waste of resources on the LSP side when requesting tokens that have already been colored by tree-sitter
A lot of finicky work to make LSP and tree-sitter use the same color for the same token to avoid one messing up the colorscheme of the other

Hence why optimal compatibility would be reached by having LSP only provide color for things that aren't covered by tree-sitter.

Waste of resources on the LSP side when requesting tokens that have already been colored by tree-sitter

Ok if that's an issue then treesitter should tell us what's left to color.
But that's something that can be figured out later.

A lot of finicky work to make LSP and tree-sitter use the same color for the same token to avoid one messing up the colorscheme of the other

As clarification for everyone reading along: LSP semantic tokens don't map to raw colors but use standard Kakoune faces.
This means it will work reasonably well with any colorscheme.
If tree sitter does the same, it should fit right in.
So one goal here is a good default mapping of "syntax/semantic token" to "Kakoune face" that both LSP and tree sitter agree on.

I’m just joining in this conversation as I’ve been busy with life lately. I’m not sure what to think about all of that. I think that merging everything together (LSP / tree-sitter) is tempting, but is it really sound? I do believe that what makes Kakoune such a good tool is how simple it is, and I think the ecosystem should follow that path. Otherwise, you open the gates for various unrelated requests, such as “Eh, can I have copilot too?” or “Eh, why not adding this tronfibulate fuzzy finder that is so useful and…” and you get the picture.
I think that what is lacking currently is a way to share a buffer with external programs. I’ve always thought that, being based on UNIX and POSIX roots, Kakoune should provide some kind of shared memory to buffers via read-only / read-write access. One of the most annoying stuff in KTS is that I have to parse buffers all the time by streaming them via FIFOs (created by KTS and exposed to Kakoune). I’m in the process of using delta and partial updates, but that’s super complex. And I know that this kind of stuff happens in kak-lsp too. And it would happen in anything else requiring access to a buffer.
I’m not sure @mawww has a solution for this. I personally do not for now.

As clarification for everyone reading along: LSP semantic tokens don't map to raw colors but use standard Kakoune faces.
This means it will work reasonably well with any colorscheme.
If tree sitter does the same, it should fit right in.

A face is just an alias that maps to a color at the time of usage, though (you could do s/color/face/g in my previous comments).
The finicky work is making it so that LSP and tree-sitter produce the same tokens for the same buffer locations, especially because we have little control over what an LSP server produces.

So one goal here is a good default mapping of "syntax/semantic token" to "Kakoune face" that both LSP and tree sitter agree on.

Hence why this would largely fall onto tree-sitter, and basically require them to model each language's highlighter queries to match the corresponding language server as closely as possible.
IMO there is no good single set of default tokens in kak-lsp. We'll need one that covers basic and semantic highlighting for "standalone" users, and one that only does semantic stuff for people using tree-sitter (or the regular regex highlighters).
Then tree-sitter would be able to provide the best queries they can, without being tied to how a particular language server works.


Unexpected

Not sure if it can be considered as an issue but I'm pretty sure it can cause issue. (not in software itself)
I tried to create an acronyme for my project "NIAEI Cosmic Ray Logger" and the results was a little unexpected.

user@computer:~$ acronym "NIAEI Cosmic Ray Logger" --nested
some_path/existing_acronyms.txt
Collecting word corpus
Comparing to known acronyms
Identifying matching acronyms
Process Complete
NIGGER  NIaei cosmic ray loGGER
NAGGE   NiAei cosmic ray loGGEr
NAOMI   NiAei cOsMIc ray logger
NASAL   NiAei coSmic rAy Logger
NASCE   NiAei coSmiC ray loggEr
NICER   NIaei Cosmic ray loggER
NIECE   NIaEi cosmiC ray loggEr
NIGER   NIaei cosmic ray loGgER
NAIL    NiAei cosmIc ray Logger
NAME    NiAei cosMic ray loggEr
NEAR    NiaEi cosmic rAy loggeR
NEER    NiaEi cosmic ray loggER
NERE    NiaEi cosmic Ray loggEr
NERO    NiaEi cosmic Ray lOgger
NICE    NIaei cosmiC ray loggEr
NILE    NIaei cosmic ray LoggEr
NOSE    Niaei cOSmic ray loggEr

I see dictionaries describe the word shown in bold, however it might be a good idea to have a flag in acronym to prevend such results.

Lol... that's more of a wordlist issue though. I bet there are more four letter words to weed out.


ainBase: Abstract analog base class

Implemented an abstract base class for analog sensors.  This class
provides standard methods for reading from analog pins as well as
applying a scale/offset.
Updated the dfrph sensor to use the ainBase.
Signed-off-by: Noel Eck<EMAIL_ADDRESS>

This would need some clean-up and should be split into separate commits based on what is being added, when we merge the C sources.
Also, I feel like the functionality of the analog base class, specifically scale & offset would make more sense in MRAA. @arfoll thoughts?


Be able to cancel the request

Hi Aduth!
Thank you for making this lightweight library.
One thing that would be awesome to support would be the AbortController API.
Are you planning on adding this feature for your library?
Thank you for your reply and happy new year!

Hey @aminnairi , thanks for the suggestion. Could you tell me a bit more about how you might expect it to work?
In the spirit of keeping the library light, is it something which could be accomplished with a wrapper hook?
Maybe something like...
function useCancelableFetch(url) {
  const controller = new AbortController();
  const result = useQuery(url, () => fetch(url, { signal: controller.signal }));
  return { ...result, controller };
}

// ...

const { controller } = useCancelableFetch('https://example.com');
controller.abort();

You are correct, since we are in control of the promise once could use an AbortController in the callbak passed to useQuery and create his own hook. Thanks for you reply!


More changes and fixes

Hi Thomas,
Please let me know if these changes are ok. Also, the new refactoring broke the context menu in that the checkboxes do not respond to clicks any more. Could you have a look at that as well?
Also, during the course of these changes, I've noticed that all the custom events are created and dispatch on a per element basis. Perhaps when I get a chance, I'll look into redoing the custom events with event delegation technique to make things more robust and efficient.
Thanks again.

@jackkjhsu hey thanks. it's still working in progress but i believe the new refactor brings a much cleaner approach for many things

@jackkjhsu hey thanks. it's still working in progress but i believe the new refactor brings a much cleaner approach for many things

Found where the issue lies, the visibleColumns() method. It was filtering by col.hidden === false, which was too strict, not allowing unset hidden property. I've now changed the predicate to !col.hidden . This should now work for set or unset column.hidden properties. I will be making another pull request shorly.
Thanks

@jackkjhsu the context menu seem to work fine for me so i'm not sure what's going on. i'm not sure what is the issue also for the custom element being created on a per element basis. i'm dispatching everything from the grid (at least it should :) ) using the new dispatch helper function that makes the syntax much easier to work with.

There's no issue with the custom event creation and dispatching now. I am just proposing that we can look into using event delegation technique to optimize things. As for the context menu, a fix is coming for cases where column.hidden property is not set, making its default false.
Thanks


[$250] The FAB or Search category selector are narrow

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: v1.4.83-0
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @mountiny
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1718283502781369
Action Performed:
Break down in numbered steps

Click on the + green button
Or go to Search page and select Expenses to choose different category to show

Expected Result:
Describe what you think should've happened
The modal show take the entire width of the screen
Actual Result:
Describe what actually happened
The modal is very narrow
Workaround:
Can the user still use Expensify without this being fixed? Have you informed them of the workaround?
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android: Native
[ ] Android: mWeb Chrome
[x] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos
https://github.com/Expensify/App/assets/36083550/aadee1b0-1da0-4cad-adbb-a6a309420e2c
Add any screenshot/video evidence

View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~0163f71b7719038ed3
Upwork Job ID:<PHONE_NUMBER>430390753
Last Price Increase: 2024-06-13
Automatic offers:

hoangzinh | Reviewer | 102723522
bernhardoj | Contributor | 102723525

Issue OwnerCurrent Issue Owner: @hoangzinh

I think it's better to move the FocusTrapForModal as ModalContent children. No need extra view.
https://github.com/Expensify/App/blob/f6de195ffee0c145926dfe529d2fa819dafb346e/src/components/Modal/BaseModal.tsx#L255-L266

It works fine as far as I tested
https://github.com/Expensify/App/assets/50919443/ee85a16d-7e95-4b9d-8d10-dcdde8eddcff

@bernhardoj's proposal seems to be better option than applying style to this additional view. It's important to have View as a child of FocusTrapForModal but there's no problem in placing it inside ModalContent.

That makes sense to me as well as long as it doesn't break the focus trap, which I defer to @jnowakow and @fedirjh to confirm. Seems like we're okay?

@bernhardoj are you available to work on the PR?

Yes, I'll open the PR quickly!

@luacmartins PR is ready

This was CPed and fixed
$250 to @bernhardoj and to @allroundexperts

Discussing in Slack to make sure I'm understanding the correct payment date

Payment Summary:
Contributor+: @allroundexperts   - $250 - paid via Manual request
Contributor: @bernhardoj  - $250 - paid via Upwork
@allroundexperts, can you complete the BZ Checklist when you get a moment? Thank you!

I think the due date here is the 24th. Updated the title to reflect that.

Yep! Payment has already been issued via Upwork. We're just waiting on the BZ Checklist to be completed.

@allroundexperts can you complete the BZ Checklist above? Once finished, we can close this up.

Checklist

https://github.com/Expensify/App/pull/39520
The software mansion team was aware of this issue already here.
N/A
I think that the FAB and search category selector are being covered in other regression tests so a new one is not needed.

Thanks, @allroundexperts! Please go ahead and request payment if you haven't already!

$250 approved for @allroundexperts


prometheus metrics for operability

expose operational metrics that reflects the health and status of the operator

This kind of operator metrics could be very useful, for example information about failed jobs, for example :

I currently get a registry access denied in the logs, but via the current metrics I do not see that a scan is missing.
I also have this kind of blocked jobs : https://github.com/aquasecurity/trivy-operator/issues/295 . Maybe some metrics about jobs exceeding TTL ?


Feature: Rename clients

I'd love to see the wrapper to be able to rename (change the username) of a client device. Right now most of my client names are just MAC addresses which is not useful. Not sure the API supports a rename operation, but if it does, it would be super useful.

The omada cli already supports this with omada set-client-name <mac> <name>
Are you using the API directly or the command-line interface?

In Omada CLI 1.3.13 there is an alternative cli command with more features.
omada client <mac or current name> --set-name "name"


fix(semantic release): testing semantic release

:tada: This PR is included in version 1.0.1 :tada:
Your semantic-release bot :package::rocket:


Scanner stuck in character card and exiting after without action when scanning only characters

Current Behavior
When selected to scan characters only, the scanner went to open character card (Esc -> Avatar) and got stuck there for a few minutes and then exiting without performing any further visible actions.
Expected Behavior
The scanner continues to scan
Reproducing a Behavior
Unsure. For me, selecting to scan all and selecting to scan only weapons worked for me. Select to scan characters only led to the failure. But the exact parameters for prompting the behavior is uncertain.
Device OS
Windows 10
Genshin Impact Version
3.5
Inventory Kamera Version
1.3.8
Screen resolution, screen mode, and UI scale
2560x1440
Additional notes and remarks
Error log below. But might be from a few different attempts in aggregate.

Could not determine character's name
Could not determine character's element
Could not determine character's name
Could not determine character's element
Could not determine character's name
Could not determine character's element
Could not determine character's name
Could not determine character's element
Evidence
InventoryKamera.log
InventoryKamera.debug.log
Preflight Checklist

[X] I have checked for similar issues in the issue page, and I have not found any similar to mine.
[X] I am using the latest version of the scanner.
[ ] I tried setting the scanning delay to maximum, and it still doesn't work.
[ ] I have attached the video recording to the bug report.
[X] I have attached the error log to the bug report.
[ ] I am available to later explains the issue.
[X] I have disabled all screen filtering software or plugins (i.e. HDR, Image Sharpening) while scanning.
[X] I use default in-game keybindings or have configured keybindings for the scanner.

Your resolution says you have a widescreen monitor. Please see one of the pinned issue regarding this. Please reopen this issue if it does not fix your problem


Coherence in the config file

modify the name of the autosave l13  to be coherent with line 20

Thanks for spotting this and fixing.