feat: return matched pos

use case:
list: [{name:'hello'},{name:'other'}]
input: e
matched: [{name:'hello'},{name:'other'}]
when should highlight the matched char, we need pos of matched char to do that

h e🍺 llo
oth e🍺 r

thanks!

Hey @Akimotorakiyu given the search is fuzzy, and typo-tolerant. Getting the exact character to be matched would always be tricky, given the library was not designed for exact matches. You could explore something like match-sorter

@scmmishra thanks!

ref: https://github.com/kentcdodds/match-sorter/issues/144


Call # error report missing records

BPL leased non-fic with vendor call # None and inhouse call # None not displayed

fixed


Laravel5.4 AJAX file upload

Laravel Version: 5.4
PHP Version: 5.6
Database Driver & Version:

Description:
When I upload file by ajax, the $_FILES array contains the info of the file
but file  in the $request->all() is null
How to solve it?
Steps To Reproduce:

You must to use the file method.
$request->file("doc");

https://laravel.com/docs/5.4/requests#files

Thank you，But it is null too

@leozim Maybe the multipart/form-data ContentType is missing in the ajax request. I recommend you ask in stackoverflow or laracasts.
https://stackoverflow.com/questions/tagged/laravel+laravel-5
https://laracasts.com/discuss

@marconi1992 Ok, Thank you

@leozim either ask there or on the Larachat slack channel. Whichever one you prefer :)

@marconi1992 @Dylan-DPC  I got it
I use a upload plugin called webupload，it can;t work well with laravel
when I use swfupload，It works.
Thank all of you


Error: 404 Not Found - GET<EMAIL_ADDRESS>

What are the steps to reproduce?

Try to update Node-Red using
sudo npm install -g --unsafe-perm node-red

What happens?
I get this error log
440 http fetch GET 200 https://registry.npmjs.org/@node-red%2feditor-client 3872ms
441 http fetch GET 404<EMAIL_ADDRESS>23227ms
442 silly fetchPackageMetaData error for<EMAIL_ADDRESS>404 Not Found - GET<EMAIL_ADDRESS>443 timing stage:rollbackFailedOptional Completed in 0ms
444 timing stage:runTopLevelLifecycles Completed in 43209ms
445 verbose stack Error: 404 Not Found - GET<EMAIL_ADDRESS>445 verbose stack     at res.buffer.catch.then.body (/usr/local/lib/node_modules/npm/node_modules/npm-registry-fetch/check-response.js:104:15)
445 verbose stack     at process._tickCallback (internal/process/next_tick.js:68:7)
446 verbose statusCode 404
447 verbose pkgid<EMAIL_ADDRESS>448 verbose cwd /home/damion
449 verbose Linux 4.19.0-10-amd64
450 verbose argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" "-g" "--unsafe-perm" "node-red"
451 verbose node v10.15.3
452 verbose npm  v6.14.2
453 error code E404
454 error 404 Not Found - GET<EMAIL_ADDRESS>455 error 404
456 error 404 '<EMAIL_ADDRESS>is not in the npm registry.
457 error 404 You should bug the author to publish it (or use the name yourself!)
458 error 404 It was specified as a dependency of '@node-red/editor-api'
459 error 404 Note that you can also install from a
460 error 404 tarball, folder, http url, or git url.
461 verbose exit [ 1, true ]

What do you expect to happen?

The installation to proceed smoothly

Please tell us about your environment:

[ ] Node-RED version: v1.1.0
[ ] Node.js version: v10.15.3
[ ] npm version<EMAIL_ADDRESS>[ ] Platform/OS: Debian buster
[ ] Browser: N/A

Looks like npm are having an outage at the moment - https://status.npmjs.org/incidents/cksjqc1w11v5


False alarm for TRIO108 in context managers

from contextlib import asynccontextmanager
import trio

@asynccontextmanager
async def in_background(*background_tasks):
    async with trio.open_nursery() as nursery:
        for bgt in background_tasks:
            nursery.start_soon(bgt)
        yield

doesn't emit TRIO101 because we know this is (probably) a context manager, but we don't have the same filter for 108:
$ flake8 example.py
example.py:6:1: TRIO108: exit from async iterable with no guaranteed checkpoint since yield on line 10
example.py:10:9: TRIO108: yield from async iterable with no guaranteed checkpoint since function definition on line 6

Ah okay, it's currently very conservative and treats decorators the same as async with - i.e. guaranteed checkpoint on at least one of entry and exit. I remember you responding this somewhere when I asked, but can't find that comment now.
So it's not about not having the filter, and 107 isn't triggered since we know it'll checkpoint at least once. But it's likely overly conservative though, so I'll switch 108 to seeing function decorator context managers as checkpointing both on entry and exit.

Yeah, I think the general principle is "whichever interpretation is less prone to false alarms"; if we don't know which then assuming it's fine seems like a better user experience.

I could also treat async with as checkpointing on both entry and exit in that case, such that
async def foo():
  async with ...:
    yield

raises no errors.

I think that would reduce false alarms,  so let's do it 🙂

It hurts a bit to remove that beautiful logic, it could plausibly be put behind a setting. But I don't think the case is strong enough to bother with anything like that and in 99% of cases it's probably false alarms. RIP self.yield_count


Add missing imports in TF learn examples

Can one of the admins verify this patch?

@tensorflow-jenkins Test this please

LGTM


Explore full text search with Hibernate Search 6 + SQL + Elasticsearch

This this SO post: How to implement full text search in Spring Boot with JPA + MySQL
It may also be worth looking at OpenSearch, the open-source alternative to Elasticsearch:

For starters, the primary language for OpenSearch queries is Query DSL. However, there are also two plugins that allow you to use two other querying languages: SQL and PPL (Piped Processing Language).

Source
Hibernate Search 6 seems to support OpenSearch.

Every section of this documentation referring to Elasticsearch is also relevant for the OpenSearch distribution.

See also:

Elasticsearch Queries: A Guide to Query DSL
OpenSearch Queries: Query DSL and Beyond
Hibernate Search 6 With Spring Boot (uses Lucene)
From table to index (and back) with Hibernate Search 6
Guide to Hibernate Search
https://gauthier-cassany.com/posts/spring-boot-hibernate-search
https://gauthier-cassany.com/posts/spring-boot-paginated-search

https://github.com/Mozenn/spring-boot-hibernate-search

Full-Text Search with Hibernate Search and Spring Boot

Shows how to load existing data into elasticsearch

Hibernate Search 6 With Spring Boot (Hibernate Search 6)

Shows how to load existing data into elasticsearch

https://github.com/hibernate/hibernate-search

https://docs.jboss.org/hibernate/stable/search/reference/en-US/html_single/#getting-started-configuration

This table seems to say that I should use opensearch 1.2.x and not 1.3.x.

Issue with the function name searchBy
Failed to create query for method public abstract java.util.List org.sagebionetworks.challenge.model.repository.SearchRepository.searchBy(java.lang.String,int,java.lang.String[])! At least 1 parameter(s) provided but only 0 parameter(s) present in query.

Get info from Elasticsearch
Get list of indexes
http://localhost:9200/_cat/indices?format=json

Indexing entities with Hibernate Search
Logs:
2023-01-04 21:25:14.000  INFO 20406 --- [  restartedMain] o.s.c.c.HibernateSearchIndexBuild        : Started Initializing Indexes
2023-01-04 21:25:14.030  WARN 20406 --- [port thread - 1] org.elasticsearch.client.RestClient      : request [POST http://challenge-registry-opensearch:9200/challenge-registry-challenge-write/_refresh] returned 1 warnings: [299 Elasticsearch-7.17.8-120eabe1c8a0cb2ae87cffc109a5b65d213e9df1 "Elasticsearch built-in security features are not enabled. Without authentication, your cluster could be accessible to anyone. See https://www.elastic.co/guide/en/elasticsearch/reference/7.17/security-minimal-setup.html to enable security."]
2023-01-04 21:25:14.052  WARN 20406 --- [port thread - 1] org.elasticsearch.client.RestClient      : request [POST http://challenge-registry-opensearch:9200/challenge-registry-challenge-write/_delete_by_query?conflicts=proceed] returned 1 warnings: [299 Elasticsearch-7.17.8-120eabe1c8a0cb2ae87cffc109a5b65d213e9df1 "Elasticsearch built-in security features are not enabled. Without authentication, your cluster could be accessible to anyone. See https://www.elastic.co/guide/en/elasticsearch/reference/7.17/security-minimal-setup.html to enable security."]
2023-01-04 21:25:14.063  WARN 20406 --- [port thread - 1] org.elasticsearch.client.RestClient      : request [POST http://challenge-registry-opensearch:9200/challenge-registry-challenge-write/_forcemerge] returned 1 warnings: [299 Elasticsearch-7.17.8-120eabe1c8a0cb2ae87cffc109a5b65d213e9df1 "Elasticsearch built-in security features are not enabled. Without authentication, your cluster could be accessible to anyone. See https://www.elastic.co/guide/en/elasticsearch/reference/7.17/security-minimal-setup.html to enable security."]
2023-01-04 21:25:14.235  INFO 20406 --- [ ID loading - 0] s.m.p.m.i.PojoMassIndexingLoggingMonitor : HSEARCH000027: Mass indexing is going to index 3 entities.
2023-01-04 21:25:14.321  WARN 20406 --- [port thread - 3] org.elasticsearch.client.RestClient      : request [POST http://challenge-registry-opensearch:9200/_bulk] returned 1 warnings: [299 Elasticsearch-7.17.8-120eabe1c8a0cb2ae87cffc109a5b65d213e9df1 "Elasticsearch built-in security features are not enabled. Without authentication, your cluster could be accessible to anyone. See https://www.elastic.co/guide/en/elasticsearch/reference/7.17/security-minimal-setup.html to enable security."]
2023-01-04 21:25:14.327  WARN 20406 --- [port thread - 2] org.elasticsearch.client.RestClient      : request [POST http://challenge-registry-opensearch:9200/_bulk] returned 1 warnings: [299 Elasticsearch-7.17.8-120eabe1c8a0cb2ae87cffc109a5b65d213e9df1 "Elasticsearch built-in security features are not enabled. Without authentication, your cluster could be accessible to anyone. See https://www.elastic.co/guide/en/elasticsearch/reference/7.17/security-minimal-setup.html to enable security."]
2023-01-04 21:25:14.332  WARN 20406 --- [port thread - 1] org.elasticsearch.client.RestClient      : request [POST http://challenge-registry-opensearch:9200/_bulk] returned 1 warnings: [299 Elasticsearch-7.17.8-120eabe1c8a0cb2ae87cffc109a5b65d213e9df1 "Elasticsearch built-in security features are not enabled. Without authentication, your cluster could be accessible to anyone. See https://www.elastic.co/guide/en/elasticsearch/reference/7.17/security-minimal-setup.html to enable security."]
2023-01-04 21:25:14.373  WARN 20406 --- [port thread - 1] org.elasticsearch.client.RestClient      : request [POST http://challenge-registry-opensearch:9200/challenge-registry-challenge-write/_flush] returned 1 warnings: [299 Elasticsearch-7.17.8-120eabe1c8a0cb2ae87cffc109a5b65d213e9df1 "Elasticsearch built-in security features are not enabled. Without authentication, your cluster could be accessible to anyone. See https://www.elastic.co/guide/en/elasticsearch/reference/7.17/security-minimal-setup.html to enable security."]
2023-01-04 21:25:14.381  WARN 20406 --- [port thread - 1] org.elasticsearch.client.RestClient      : request [POST http://challenge-registry-opensearch:9200/challenge-registry-challenge-write/_refresh] returned 1 warnings: [299 Elasticsearch-7.17.8-120eabe1c8a0cb2ae87cffc109a5b65d213e9df1 "Elasticsearch built-in security features are not enabled. Without authentication, your cluster could be accessible to anyone. See https://www.elastic.co/guide/en/elasticsearch/reference/7.17/security-minimal-setup.html to enable security."]
2023-01-04 21:25:14.382  INFO 20406 --- [  restartedMain] s.m.p.m.i.PojoMassIndexingLoggingMonitor : HSEARCH000028: Mass indexing complete. Indexed 3 entities.
2023-01-04 21:25:14.382  INFO 20406 --- [  restartedMain] o.s.c.c.HibernateSearchIndexBuild        : Completed Indexing

Entities:
http://localhost:9200/challenge-registry-challenge-000001/_search?q=*:*

{
  "took": 4,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 3,
      "relation": "eq"
    },
    "max_score": 1.0,
    "hits": [
      {
        "_index": "challenge-registry-challenge-000001",
        "_type": "_doc",
        "_id": "1",
        "_score": 1.0,
        "_source": {
          "name": "The Digital Mammography DREAM Challenge",
          "_entity_type": "ChallengeEntity"
        }
      },
      {
        "_index": "challenge-registry-challenge-000001",
        "_type": "_doc",
        "_id": "2",
        "_score": 1.0,
        "_source": {
          "name": "Patient Mortality EHR DREAM Challenge",
          "_entity_type": "ChallengeEntity"
        }
      },
      {
        "_index": "challenge-registry-challenge-000001",
        "_type": "_doc",
        "_id": "3",
        "_score": 1.0,
        "_source": {
          "name": "COVID-19 EHR DREAM Challenge",
          "_entity_type": "ChallengeEntity"
        }
      }
    ]
  }
}

Issue retrieving entities with the repository
Error:
        at java.base/java.lang.reflect.Method.invoke(Method.java:568)
        at org.hibernate.proxy.pojo.bytebuddy.ByteBuddyInterceptor.intercept(ByteBuddyInterceptor.java:56)
        at org.hibernate.proxy.ProxyConfiguration$InterceptorDispatcher.intercept(ProxyConfiguration.java:95)
        at org.sagebionetworks.challenge.model.entity.SimpleChallengePlatformEntity$HibernateProxy$8niPjWpX.toString(Unknown Source)
        at java.base/java.lang.StringConcatHelper.stringOf(StringConcatHelper.java:453)
        at org.sagebionetworks.challenge.model.entity.ChallengeEntity.toString(ChallengeEntity.java:25)
        at java.base/java.lang.StringConcatHelper.stringOf(StringConcatHelper.java:453)
        at org.sagebionetworks.challenge.model.entity.ChallengeSubmissionTypeEntity.toString(ChallengeSubmissionTypeEntity.java:20)
        at java.base/java.lang.String.valueOf(String.java:4218)
        at java.base/java.lang.StringBuilder.append(StringBuilder.java:173)
        at java.base/java.util.AbstractCollection.toString(AbstractCollection.java:457)
        at org.hibernate.collection.internal.PersistentBag.toString(PersistentBag.java:622)
        at java.base/java.lang.StringConcatHelper.stringOf(StringConcatHelper.java:453)
        at org.sagebionetworks.challenge.model.entity.ChallengeEntity.toString(ChallengeEntity.java:25)
        at java.base/java.lang.StringConcatHelper.stringOf(StringConcatHelper.java:453)
        at org.sagebionetworks.challenge.model.entity.ChallengeSubmissionTypeEntity.toString(ChallengeSubmissionTypeEntity.java:20)
        at java.base/java.lang.String.valueOf(String.java:4218)
        at java.base/java.lang.StringBuilder.append(StringBuilder.java:173)
        at java.base/java.util.AbstractCollection.toString(AbstractCollection.java:457)
        at org.hibernate.collection.internal.PersistentBag.toString(PersistentBag.java:622)
...

Combining queries

Baeldung - Combining Queries (Hibernate Search 5)


set custom id for response

add ability to set custom id for g-recaptcha-response to be able add multiple captchas on same page

You already have this ability using the helper extension. See here https://github.com/TimothyMeadows/reCAPTCHA.AspNetCore/blob/master/reCAPTCHA.AspNetCore/RecaptchaHelper.cs#L20. This should not be needed on v3 as it's dynamically generated with Guid.NewGuid and can be duplicated as much as you desire.

id of input is always preset to g-recaptcha-response in https://github.com/TimothyMeadows/reCAPTCHA.AspNetCore/blob/master/reCAPTCHA.AspNetCore/Templates/v3.tt


Issue #648 fixed - Fixed UnresolvableObjectException when using Inser…

Fixes according to #648

Thank you very much! Merging it.


[Bug Report]

Description
Warlock pets dps isnt merging in details and I couldnt figure out how to fix it
Version Number
2.45
Steps to Reproduce
< Provide all the steps necessary to reproduce the problem >
Step 1:Just play the game
Step 2:
Step 3:
Step 4:
Expected Behavior
dps from pet should merge
Actual Behavior
no mergey
Only ElvUI + LuckyoneUI enabled
< Please provide information about whether or not you can reproduce it >
< when ElvUI and LuckyoneUI are the only addons enabled >
Blizzard Issue?
< Please test if you can reproduce the issue with 0 addons enabled >
< Include screenshot of how it looks if possible >
Additional Information
< Please provide any additional information here >
Error Log
< If you received an error then please post it in the empty space below >
< so that the error is wrapped in the 3 backquotes (before and after) >

This sounds like a question for details, not LuckoneUI as he isn't the addon author of details and doesn't have control of any changes details may be doing.

It was working before I went through the installation process for Luckyone and works if I turn all addons minus details off and go to a default profile.

so tldr; you dont like LuckyoneUI details profile. that may be how he likes it as the setup is for how he prefers his layout. I would suggest to not use the details profile lucky provides, and tweak the details settings to your liking, or import lucky's settings then go to details and find the option to make it report pets the way you would like (assuming the rest of the details profile of his you like)

Waiting on Flam from details to respond to see if they changed anything but I am assuming Lucky's profile is how Lucky intends/wants his profile. I will report back once Flam confirms they changed/or didnt change anything for it to be like this.

No it's supposed to automatically merge pet damage only hunters have a separate setting to my understanding. I do like how its setup but I cant see how much damage I am doing like that. I will just close the ticket. I tried looking for an option or something to tweak like I said but couldnt find anything.  It's his profile for his use that he has available for others to use. If something is not how you like it, you are free to modify it to fit your needs. I know there were issues details were having with combat log changes as one of the devs is in our Tukui/ElvUI community discord. I pinged him to see if he was aware of any issues you have stated as Lucky has not altered his profile string since May 8th. So any "issues" you are having will most likely be something done on Details or Blizzards end, which in turn could have borked the import string but is most likely not the case.

I have pointed Flam to this ticket but I do know there has been changes back and forth with realmnames and I know he had issues with bit.band and such which would not be something on Luckyone as he only provides a profile, only way it would be on lucky is something has changed enough in details that would require a new profile string export.

Luckyone applies a profile. He does not control our parser.
Blizzard made a change on ptr to include realm names for all players. Which messed up a lot of our core functionality and we've been fixing it this previous week.
Blizzard reverted their change yesterday. So we had to revert our changes.
If you have issues with Details, do bring them up in our Discord and not in an unrelated addons github issues. https://discord.gg/AGSzAZX


Add DistanceSensors of type sonar

update documentation
update example robot controllers

Signed-off-by: Adrian Matejov<EMAIL_ADDRESS>

Also had to increase the height of the walls so the rays won't go above it.

Thank you for your patience @Adman, feel free to merge this in!


rss memory grow which the project has 10G large

I have a task which every loop add,commit,merge,push file to git, code like loop git task, the git project is 10G large, but every loop just submit 2 file, the problem is that the rss memory keep up until memory exhaust!
system: $ uname -a
Linux hmp-dev.fi.beibei.com 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 11:36:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
any one can give some suggestion?

@hardog can you post your code? It's hard to know what's going on from the description of the problem. Thanks!

Similar problem here: I have a function which reads a file from a git repo via nodegit. My code caches this result after the first call, so it essentially only calls to nodegit once. However the memory usage grows linearly and will eventually crash the process due to OOM. Interestingly enough this doesn't happen on macOS. Also worth noting is the problem is much worse in Node 7.6 (I'm using 7.4 for the time being).

same problem here, after running git clone rss memory gets from 60MB to 270MB and never goes down.


downloadbutton: missing return + leftover file

downloadbutton: missing return + leftover file

Remove leftover generated filee from
1700b5be5f324d65913c7b7718dc06ffa2da42b9.

Also add missing return, causing two downloads to start
when selecting a single file.

cc @bradfitz for review

cc @bradfitz for review

I am really confident about this, so I'll merge it, but let me know if you prefer that I wait even for simple stuff like this in the future.

I am really confident about this, so I'll merge it, but let me know if you prefer that I wait even for simple stuff like this in the future.


build: lint JS configuration files

Moar linter additions. In this case, adding JavaScript configuration files (ESLint config file (:inception:) and Karma configuration files) as files to lint.
To achieve that, ESLint recommended rules are applied to JS files in root of repo.
Fixes issues about __dirname and __filename. Adds Node.js globals.
Renames boolean constant about using typed rules or not. This wasn't linter-triggered, as there are no types in the ESLint config file as it is a *.mjs, not TS file. Using TypeScript for ESLint configuration files is enabled behind a flag + requires an extra dependency. So keeping that file as JavaScript to avoid introducing complexity.

#869  👈 (View in Graphite)
main

This stack of pull requests is managed by Graphite. Learn more about stacking.


Promote supports feature to ApplicationRecord

Most models include SupportsFeatureMixin. This moves up to ApplicationRecord +1/-73

@agrare Please also review.

update:

rebased
extracted tools/feature_supports_matrix change (already merged)
extracted ReadOnlyModels change (closed that PR)

Most models include SupportsFeatureMixin. This moves up to ApplicationRecord +1/-73

I understand the intent to avoid duplication here, but "most models" isn't really accurate.  There are 457 models roughly, and only 73 have this, which means only 16% of models are like this.
One upside to having it in specific models is we can know what models are the things that are "CI"s (i.e. things that we externally manage).  That gets me wondering if we should have a CIMixin where we take a lot of these common mixins across CIs, then include that.  But overall, I'm not sure that would make any benefit.
I'm not against this PR, but I'm not sure - would like a second opinion from @agrare and/or @jrafanie

One upside to having it in specific models is we can know what models are the things that are "CI"s (i.e. things that we externally manage). That gets me wondering if we should have a CIMixin where we take a lot of these common mixins across CIs, then include that. But overall, I'm not sure that would make any benefit.

haha, if you can name what this commonality is, we could probably create it.  Ideally, all of these things should be reportable, support features, taggable, etc.  We can override in classes that can't do one or more of these things if desired.  Not sure how much we want to pull into the common place.

I think having a plugin that says "I'm a taggable, rbac applyable, data model that is in each provider" may have merit.


Unexpected behavior when setting target OS and arch flags

Hey! This action is amazing! Thanks so much for creating/sharing! I just set it up on a test repo and noticed some oddities. I'm new to github actions so there might be some user errors here.
The main issue I was having was an error in the action that a linux-amd64 tar wasn't found. Even though I had both linux archs set to false. Did a bunch of tests and it seems like just having the key in with object causes it to be true even if it's set to false. Removing the linux keys fixed the issue. I would have expected setting the flag to false would disable it.
Workflow:
jobs:
  homebrew:
    name: Release to `homebrew-formulas`
    needs: release
    runs-on: ubuntu-latest
    steps:
      - uses: Justintime50/homebrew-releaser@v1
        with:
          homebrew_owner: tnahs
          homebrew_tap: homebrew-test-formulas
          github_token: ${{ secrets.HOMEBREW_TAP_GITHUB_TOKEN }}
          target_darwin_amd64: true
          target_darwin_arm64: true
          target_linux_amd64: false  # <--
          target_linux_arm64: false  # <--
          install: 'bin.install "test-readstor"'
          debug: true

Error:
Run Justintime50/homebrew-releaser@v1
/usr/bin/docker run --name XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX --label
    786a9b --workdir /github/workspace --rm -e "INPUT_HOMEBREW_OWNER" -e
    "INPUT_HOMEBREW_TAP" -e "INPUT_GITHUB_TOKEN" -e "INPUT_INSTALL" -e
    "INPUT_TARGET_DARWIN_AMD64" -e "INPUT_TARGET_DARWIN_ARM64" -e
    "INPUT_TARGET_LINUX_AMD64" -e "INPUT_TARGET_LINUX_ARM64" -e
    "INPUT_UPDATE_README_TABLE" -e "INPUT_DEBUG" -e "INPUT_FORMULA_FOLDER" -e
    "INPUT_COMMIT_OWNER" -e "INPUT_COMMIT_EMAIL" -e "INPUT_DEPENDS_ON" -e
    "INPUT_TEST" -e "INPUT_SKIP_COMMIT" -e "HOME" -e "GITHUB_JOB" -e "GITHUB_REF" -e
    "GITHUB_SHA" -e "GITHUB_REPOSITORY" -e "GITHUB_REPOSITORY_OWNER" -e
    "GITHUB_RUN_ID" -e "GITHUB_RUN_NUMBER" -e "GITHUB_RETENTION_DAYS" -e
    "GITHUB_RUN_ATTEMPT" -e "GITHUB_ACTOR" -e "GITHUB_TRIGGERING_ACTOR" -e
    "GITHUB_WORKFLOW" -e "GITHUB_HEAD_REF" -e "GITHUB_BASE_REF" -e
    "GITHUB_EVENT_NAME" -e "GITHUB_SERVER_URL" -e "GITHUB_API_URL" -e
    "GITHUB_GRAPHQL_URL" -e "GITHUB_REF_NAME" -e "GITHUB_REF_PROTECTED" -e
    "GITHUB_REF_TYPE" -e "GITHUB_WORKSPACE" -e "GITHUB_ACTION" -e
    "GITHUB_EVENT_PATH" -e "GITHUB_ACTION_REPOSITORY" -e "GITHUB_ACTION_REF" -e
    "GITHUB_PATH" -e "GITHUB_ENV" -e "GITHUB_STEP_SUMMARY" -e "RUNNER_OS" -e
    "RUNNER_ARCH" -e "RUNNER_NAME" -e "RUNNER_TOOL_CACHE" -e "RUNNER_TEMP" -e
    "RUNNER_WORKSPACE" -e "ACTIONS_RUNTIME_URL" -e "ACTIONS_RUNTIME_TOKEN" -e
    "ACTIONS_CACHE_URL" -e GITHUB_ACTIONS=true -e CI=true -v
    "/var/run/docker.sock":"/var/run/docker.sock" -v
    "/home/runner/work/_temp/_github_home":"/github/home" -v
    "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v
    "/home/runner/work/_temp/_runner_file_commands":"/github/file_commands" -v
    "/home/runner/work/test-readstor/test-readstor":"/github/workspace"
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX  "tnahs" "test-homebrew-formulas"
    "formula" "***"<EMAIL_ADDRESS><EMAIL_ADDRESS>    "bin.install \"trest-action\"" "" "true" "true" "false" "false" "true" "" "true"
2022-09-12 06:19:59,748 - INFO - Starting Homebrew Releaser...
2022-09-12 06:19:59,749 - DEBUG - All required environment variables are present.
2022-09-12 06:19:59,749 - INFO - Setting up git environment...
Cloning into 'test-homebrew-formulas'...
2022-09-12 06:20:00,580 - DEBUG - Git environment setup successfully.
2022-09-12 06:20:00,580 - INFO - Collecting data about test-readstor...
2022-09-12 06:20:00,994 - DEBUG - HTTP GET request made successfully to https://api.github.com/repos/tnahs/test-readstor.
2022-09-12 06:20:01,408 - DEBUG - HTTP GET request made successfully to https://api.github.com/repos/tnahs/test-readstor/tags.
2022-09-12 06:20:01,408 - INFO - Latest release (0.1.3) successfully identified!
2022-09-12 06:20:01,409 - INFO - Generating tar archive checksum(s)...
2022-09-12 06:20:02,231 - DEBUG - HTTP GET request made successfully to https://github.com/tnahs/test-readstor/archive/0.1.3.tar.gz.
2022-09-12 06:20:02,233 - DEBUG - 0.1.3.tar.gz written successfully.
2022-09-12 06:20:02,263 - DEBUG - Checksum for 0.1.3.tar.gz generated successfully: 78c6c545ac9cca5a63512fe09fce6b39abdaf382c35b639e8b874ad7b0b41c85
2022-09-12 06:20:02,264 - DEBUG - Checksum entry: 78c6c545ac9cca5a63512fe09fce6b39abdaf382c35b639e8b874ad7b0b41c85 0.1.3.tar.gz
2022-09-12 06:20:02,264 - DEBUG - checksum.txt written successfully.
2022-09-12 06:20:03,093 - DEBUG - HTTP GET request made successfully to https://github.com/tnahs/test-readstor/archive/0.1.3.zip.
2022-09-12 06:20:03,167 - DEBUG - 0.1.3.zip written successfully.
2022-09-12 06:20:03,198 - DEBUG - Checksum for 0.1.3.zip generated successfully: d4cd1f5a0213b01d1472155ad42b4e804828136ffdd8cd44e763bbeafc65ebff
2022-09-12 06:20:03,198 - DEBUG - Checksum entry: d4cd1f5a0213b01d1472155ad42b4e804828136ffdd8cd44e763bbeafc65ebff 0.1.3.zip
2022-09-12 06:20:03,199 - DEBUG - checksum.txt written successfully.
2022-09-12 06:20:03,781 - DEBUG - HTTP GET request made successfully to https://github.com/tnahs/test-readstor/releases/download/0.1.3/test-readstor-0.1.3-darwin-amd64.tar.gz.
2022-09-12 06:20:03,968 - DEBUG - test-readstor-0.1.3-darwin-amd64.tar.gz written successfully.
2022-09-12 06:20:04,005 - DEBUG - Checksum for test-readstor-0.1.3-darwin-amd64.tar.gz generated successfully: a16ab62348e8557535bea1328140d9ca13831e521b2c489793294c548eaffa4e
2022-09-12 06:20:04,006 - DEBUG - Checksum entry: a16ab62348e8557535bea1328140d9ca13831e521b2c489793294c548eaffa4e test-readstor-0.1.3-darwin-amd64.tar.gz
2022-09-12 06:20:04,006 - DEBUG - checksum.txt written successfully.
2022-09-12 06:20:04,638 - DEBUG - HTTP GET request made successfully to https://github.com/tnahs/test-readstor/releases/download/0.1.3/test-readstor-0.1.3-darwin-arm64.tar.gz.
2022-09-12 06:20:04,663 - DEBUG - test-readstor-0.1.3-darwin-arm64.tar.gz written successfully.
2022-09-12 06:20:04,704 - DEBUG - Checksum for test-readstor-0.1.3-darwin-arm64.tar.gz generated successfully: 91686b4b7d34c2de3a1ab2cd0d7515c624ae23b85df0c362b823bd4d677066cc
2022-09-12 06:20:04,704 - DEBUG - Checksum entry: 91686b4b7d34c2de3a1ab2cd0d7515c624ae23b85df0c362b823bd4d677066cc test-readstor-0.1.3-darwin-arm64.tar.gz
2022-09-12 06:20:04,704 - DEBUG - checksum.txt written successfully.
404 Client Error: Not Found for url: https://github.com/tnahs/test-readstor/releases/download/0.1.3/test-readstor-0.1.3-linux-amd64.tar.gz

Edit: Split additional issues into multiple tickets.

Well hot dang, nice finds! 😂 I will absolutely fix these all ASAP. If I could have your help in splitting each reported bug here in a separate GitHub issue, I'll knock em out.
I don't think there's any real user error here, just edge cases I never accounted for since all my testing apparently only covered happy paths heh. To your point on the adding false flag, I too would expect that to not include it so there's some weird interaction between what GitHub hands off to the action itself. Will investigate.

Great! I'll split these up right now 😄

Fixed in https://github.com/Justintime50/homebrew-releaser/commit/80f95772037c40c73b6e62676ec5531de3483b0d

Thanks! 🎉

Thanks for reporting all these issues! I've cut a new release which will automatically pull in the new changes to v1 on your next run, you should be good to resume testing and the 3 items you reported should be all fixed up.


APP/AWS installation fails on GL4

[Version]
16.1 fix5+ 2017/02/06
[How to reproduce]

configure properties files for app according to documentation
execute:
ant -f build-db.xml initDB
ant -f build-glassfish.xml SETUP

[Expected result]
app domain is setup and can be started
[Observed result]
error during call to build-glassfish.xml
deployApplication:
[echo] asadmin --user admin333 --passwordfile C:\Users\Sdehn\AppData\Local\Temp\4\BES\script1082986597.txt --port 8848 deploy
 [exec] Application deployed with name oscm-app-aws.
 [exec] Command deploy executed successfully.

deployApplication:
[echo] asadmin --user admin333 --passwordfile C:\Users\Sdehn\AppData\Local\Temp\4\BES\script1082986597.txt --port 8848 deploy
 [exec] Command deploy failed.
 [exec] remote failure: Error occurred during deployment: Exception while preparing the app : [PersistenceUnit: oscm-app] Unab

le to build Hibernate SessionFactory. Please see server.log for more details.
[exec] Exception while invoking class org.glassfish.persistence.jpa.JPADeployer prepare method : javax.persistence.Persistenc
eException: [PersistenceUnit: oscm-app] Unable to build Hibernate SessionFactory
[exec] [PersistenceUnit: oscm-app] Unable to build Hibernate SessionFactory
[Details]
server.log:
sett attached file

server.txt

The persistence.xml of the app project is not adapted to JPA 2.1

Adapted persistence of APP to JPA 2.1. The other ones (dataservice and auditlog) are okay. Please re-test.

[Version] 2017/02/27 problem still occurs

With the same info in logs?

yes, same info
: [PersistenceUnit: oscm-app] Unable to build Hibernate SessionFactory
[exec] [PersistenceUnit: oscm-app] Unable to build Hibernate SessionFactory

The issue is related to ess version. The fix has been ported to ess and issue should be fixed now.

Installation still does not work. See screenshot below:

Fixed with 61d293d, there was a problem after merge.

[Version] 16.1 fix6+ 2017/03/06 verified


Validate windows password length and allow_long_password no longer require

For the windows system, password length must be greater than 8 chars. Currently, if provided password length is less than 8 chars it goes into a loop. it should either raise validation error or provide error message from AWS sdk if any.

Fixed in #623


Morale starts dropping before colonists have landed

Noted by @Inglonias in #1229;
Morale should remain steady until colonists have been landed on the surface.

Could maybe add a "Just Landed" morale bonus, that counteracts the initial colony conditions. Would make sense, as I'm sure people would be happy to have arrived after such a long journey, and there could be some excitement over starting a new colony.

Not a bad idea. The sort of excitement of starting anew.

Might also skip the morale calculation code if there are no colonists.

That was the general idea that I had. I created the issue when I noticed it as a reminder to address it.


Detox Next (iOS, Phase 2)

iOS:

[x] Remove Earl Grey in favor of Detox Sync
[x] Implement URL blacklist feature in Detox Sync
[x] Implement synchronization enable/disable in Detox Sync
[x] Change JS to use new sync status format (#2199)
[x] Decouple sync status from isReady request in JS (#2182)
[ ] Add support for per-command policy specification (#2370)
[x] Profile DetoxSync and improve performance
[ ] Implement touch indicator

Closes #2199
Closes #2182
JS:

[x] Drop deprecated Jest adapters (#2469)
[x] Drop launchApp support in detox.init() (TODO: create an issue)
[x] Prefixed environment variables (#2487)
[ ] Write a JS helper for reminding users to launch the app when they forget
[ ] Write migration notes for JS part (1 - super(config, context), 2 - launchApp)

Closes #2469
Closes #2487

Pull Request Test Coverage Report for Build 2580

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+9.3%) to 86.149%

Files with Coverage Reduction
New Missed Lines
%

detox/src/utils/logger.js
1
77.38%

Totals

Change from base Build 1371:
9.3%

Covered Lines:
3721

Relevant Lines:
4161

💛  - Coveralls

@noomorph When you add a warning about app not launched in init, remember pls to update Troubleshooting.RunningTests.md with this common issue. Thanks


can we have a createElementWrapper method?

while building component lib or using teleport feature of Vue3, the HTML element sometimes goes out of the component. Although we can use getComponent to access it by VNode & component, but we don't want to always abstract anything into a component.
Therefore, it can be better if there's a function works like:
const wrapper = createElementWrapper(document.querySelector('.something'))

So I can still use the query or trigger features provided by VTU.

Would this be a better solution? As for rc.17 you can stub teleport and test your component like usual: https://github.com/vuejs/vue-test-utils-next/issues/798#issuecomment-974969774
If this won't work, please share a minimal test and we can explore some other solutions.

Thanks. It works great.


Jest encountered an unexpected token

Description
I've been trying to fix this error that started happening with my unit tests when I installed @master-chief/alpaca.
 FAIL  test/controllers/middlewares/auth.middleware.test.ts
  ● Test suite failed to run

    Jest encountered an unexpected token

    Jest failed to parse a file. This happens e.g. when your code or its dependencies use non-standard JavaScript syntax, or when Jest is not configured to support such syntax.

    Out of the box Jest supports Babel, which will be used to transform your files into valid JS based on your Babel configuration.

    By default "node_modules" folder is ignored by transformers.

    Here's what you can do:
     • If you are trying to use ECMAScript Modules, see https://jestjs.io/docs/ecmascript-modules for how to enable it.
     • To have some of your "node_modules" files transformed, you can specify a custom "transformIgnorePatterns" in your config.
     • If you need a custom transformation specify a "transform" option in your config.
     • If you simply want to mock your non-JS modules (e.g. binary assets) you can stub them out with the "moduleNameMapper" config option.

    You'll find more details and examples of these config options in the docs:
    https://jestjs.io/docs/configuration
    For information about custom transformations, see:
    https://jestjs.io/docs/code-transformation

    Details:

    /Users/kevindra/workplace/tradingbot/tradingbotx-api/node_modules/@master-chief/alpaca/dist/mjs/index.js:1
    ({"Object.<anonymous>":function(module,exports,require,__dirname,__filename,jest){export { AlpacaClient } from './client.js';
                                                                                ^^^^^^

    SyntaxError: Unexpected token 'export'

    > 1 | import { AlpacaClient, PageOfBars } from "@master-chief/alpaca";

Expected
No such errors.
Reproduction
Any Jest tests would fail if this library is imported.
Looking for what might be the fix. Thanks

Looks like it's already been tracked in #69


Update browser testing checklist in PR template

IE8 is no longer testable with Sauce Labs.

FWIW IE8 can be used via VirtualBox with https://github.com/xdissent/ievms

FWIW IE8 can be used via VirtualBox with https://github.com/xdissent/ievms

Is that a "Request Changes" review? 😁
Those things are so hard to maintain, and our IE8 traffic is so low at this point—0.13% (that's thirteen hundredths of one percent)—I think it's justifiable to stop testing in IE8.


Updated licenses and origins of sample datasets

... to reflect their original source (cats vs dogs/coco 2014/2017)
Closes: https://etacompute.atlassian.net/browse/BOOM-1517

Btw. this repo has some test setup but it's not correct (and the tests are failing). I will fix this one day, not urgent though


Running into trouble with jsx-runtime

Hello! I keep running into this issue (using<EMAIL_ADDRESS>and typescript@4.6). This is the error I see when hovering over any JSX in vscode. If I compile with typescript on the cli, I also get the same error.
Cannot find module 'red-otter/jsx-runtime' or its corresponding type declarations.ts(2307)

If I compile with parcel, I see this:
🚨 Build failed.

@parcel/core: Failed to resolve
'red-otter/jsx-dev-runtime' from
'./src/index.tsx'

  /Users/tanishqkancharla/Documents/Projects/webgl-editor/src/index.tsx:1:1
  > 1 | import { Context, Font, FontAt
  >   | ^
    2 |
    3 | async function loadFont(fontUr

This might be related to the exports field in your package.json which leaves out jsx-runtime?
My .parcelrc:
{
	"extends": "@parcel/config-default",
	"transformers": {
		"url:*": ["@parcel/transformer-raw"]
	}
}

index.tsx:
import { Context, Font, FontAtlas, Layout, TTF } from "red-otter";

async function loadFont(fontUrl: string) {
	// Add font to the document so we will use browser to rasterize the font.
	const fontFace = new FontFace("Inter", `url("${fontUrl}")`);
	await fontFace.load();
	document.fonts.add(fontFace);

	// Download font file for parsing.
	const file = await fetch(fontUrl);
	const buffer = await file.arrayBuffer();

	const ttf = new TTF(buffer);
	if (!ttf.ok) {
		throw new Error("Failed to parse font file.");
	}

	// Render font atlas.
	const atlas = new FontAtlas(ttf);
	const { canvas, spacing } = atlas.render();

	const image = new Image();
	image.src = canvas.toDataURL();

	return new Font(spacing, image);
}

export function add(x: number, y: number) {
	return x + y;
}

async function run() {
	const canvas = document.createElement("canvas");
	const scale = window.devicePixelRatio;
	canvas.width = 800 * scale;
	canvas.height = 600 * scale;

	const div = document.getElementById("app")!;
	div.appendChild(canvas);

	const font = await loadFont("./inter.ttf");

	const context = new Context(canvas, font);
	context.clear();

	const layout = new Layout(context);
	layout.add(
		<view style={{ width: 100, height: 100, backgroundColor: "#fff" }}>
			<text style={{ fontFamily: font, fontSize: 20, color: "#000" }}>
				Hello
			</text>
		</view>
	);

	layout.render();
	context.flush();
}

if (typeof window !== "undefined") {
	// If in browser context
	run();
}

Relevant of package.json:
"type": "module",
	"scripts": {
		"build": "parcel src/index.html",
		"dev": "parcel src/index.html",
		"serve": "parcel serve dist",
		"deploy": "npx vercel deploy",
		"test": "NODE_OPTIONS='--loader tsx' mocha './src/**/*.test.ts' --verbose"
	},

tsconfig.json
{
	"compilerOptions": {
		"jsx": "react-jsx",
		"jsxImportSource": "red-otter",
		"types": ["red-otter", "./src/types"],
		"target": "es2017",
		"module": "ESNext" /* Specify what module code is generated. */,
		"esModuleInterop": true /* Emit additional JavaScript to ease support for importing CommonJS modules. This enables `allowSyntheticDefaultImports` for type compatibility. */,
		"forceConsistentCasingInFileNames": true /* Ensure that casing is correct in imports. */,
		"moduleResolution": "node",

		/* Type Checking */
		"strict": true /* Enable all strict type-checking options. */,
		"skipLibCheck": true /* Skip type checking all .d.ts files. */,
		"outDir": "dist"
	},
	"include": ["./src/**.ts"]
}

Any tips you might have would be greatly appreciated :)

For now the lib doesn't support the new jsx transforms ("jsx": "react-jsx", React blog post about them) but the old one:
"jsx": "react",
"jsxFactory": "jsx"

I was able to reproduce the problem and it went away once I changed those two lines so I hope this will solve it.
If you have some particular reason to use the new transform – let me know.
I started working on it some time ago but it was quite tedious and not very satisfying (to spend who knows how much more time just to get to work something that already works 😅).
But of course I am happy to eventually add support for it if there's a demand for that!

Oh sweet that works! I swear the documentation told me to try what I did first, but I'm looking at it now and it says your recommendation. I'm not super familiar with the nuance between old and new jsx transform. Is there anyway to avoid the jsx import in each file? Can I point typescript to the right file somewhere?

I think this is why import React from 'react' used to be necessary in each file with JSX and how it's not needed anymore because TypeScript now 'knows' where to import it from. It definitely looks useful.
I will look into adding support for this as soon as I have more time to play with it.

I looked into this a little bit. It seems simpler than I initially thought. You might need to publish a separate jsx-runtime package though? Here is the PR diff: https://github.com/tchayen/red-otter/compare/main...tanishqkancharla:red-otter:main?expand=1
So:

Vite looks at jsx, resolves to red-otter/jsx-runtime
It also uses the alias I defined in vite.config, which resolves to ./src/jsx-runtime.
Typescript complains here though, because it doesn't understand the alias; it can't find the jsx types of that import.
I also updated the package.json exports which should let packages depending on it try out the new jsx transform. I couldn't try this out though.

Thanks so much for looking into this, that's all I needed and more!
In theory red-otter/jsx-runtime should be the same as just red-otter/jsx-runtime.js when added to package.json > exports > jsx-runtime (or at least for ESM, not sure if for UMD).
I will do my best to allocate some time for this within a week. Thanks again!


Feature/readout noise compensation

@ncrubin this is now basically feature complete but lacks tests and maybe some examples.

[ ] add unit tests
[ ] add example

Resubmitting this PR after local rebasing


[feature request] Save Settings

It would be really helpful to be able to save/export/sync my Commit Message Template across multiple projects! Currently, if I want to copy my settings, I have copy/paste as many as 8 separate fields, each of which can only be seen if I close one project and then open another.

Hi! Thanks for great ideas :D
I'll add these features in future releases.

Thanks! I love your plugin, it's my favorite Commit Message tool available for Jetbrains IDEs!


Add links to the what's new topic

Docs Build status updates of commit 2ee9221:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

microsoft-edge/developer/index.yml
:white_check_mark:Succeeded
View

microsoft-edge/index.yml
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit c9199f8:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

microsoft-edge/developer/index.yml
:white_check_mark:Succeeded
View

microsoft-edge/index.yml
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Add multi select to see multiple subreddits at once

Description
These changes add a multi select search, letting users view multiple visual subreddits at once.
Screenshot
https://imgur.com/a/OwfNYBl

Hey there, feel free to reject this change or request any cleanup. I'm learning to code and was using this is a practice opportunity. Appreciate any tips on improvement!

Absolutely, let me know if that worked!

Just checking back in if anything else needed from my side


builds proceed with zero configuration

Hello, my understanding is that the build_meta:__legacy__ backend should behave like python setup.py ... calls.
However, I've realized that it proceeds fine without any setup.py / setup.cfg files:
$ mkdir empty
$ cd empty/
$ pip list
Package    Version
---------- -------
packaging  20.4
pip        20.2.2
pyparsing  2.4.7
setuptools 49.6.0   # also happens with 41.6.0 and probably anything in between
six        1.15.0
wheel      0.35.0
$ python
>>> from setuptools.build_meta import __legacy__
>>> __legacy__.build_wheel('.')
running bdist_wheel
running build
installing to build/bdist.linux-x86_64/wheel
running install
running install_egg_info
running egg_info
creating UNKNOWN.egg-info
writing UNKNOWN.egg-info/PKG-INFO
writing dependency_links to UNKNOWN.egg-info/dependency_links.txt
writing top-level names to UNKNOWN.egg-info/top_level.txt
writing manifest file 'UNKNOWN.egg-info/SOURCES.txt'
reading manifest file 'UNKNOWN.egg-info/SOURCES.txt'
writing manifest file 'UNKNOWN.egg-info/SOURCES.txt'
Copying UNKNOWN.egg-info to build/bdist.linux-x86_64/wheel/UNKNOWN-0.0.0-py3.8.egg-info
running install_scripts
creating build/bdist.linux-x86_64/wheel/UNKNOWN-0.0.0.dist-info/WHEEL
creating '/home/churchyard/tmp/empty/tmpy86e5sx4/UNKNOWN-0.0.0-py3-none-any.whl' and adding 'build/bdist.linux-x86_64/wheel' to it
adding 'UNKNOWN-0.0.0.dist-info/METADATA'
adding 'UNKNOWN-0.0.0.dist-info/WHEEL'
adding 'UNKNOWN-0.0.0.dist-info/top_level.txt'
adding 'UNKNOWN-0.0.0.dist-info/RECORD'
removing build/bdist.linux-x86_64/wheel
'UNKNOWN-0.0.0-py3-none-any.whl'
>>> ^D
[empty]$ ls
build  UNKNOWN-0.0.0-py3-none-any.whl  UNKNOWN.egg-info

This might be a problem in scripted environments. I would have expect an error here. Is this behavior deliberate or accidental?

It should indeed work the same as any pyproject.toml. It's probably unfortunate that a project with a bare setup() call and no setup.cfg succeeds, but it's not specific to the legacy backend (which shouldn't be used anyway).

setup() without any arguments has “worked” for a very long time, so it’s sort of an unfortunate accident. Since it is good in basically no situations at all, would it be possible to block a setup() call if it receives zero arguments and setup.cfg does not exist? Preferrably I would want to apply this to both PEP 517 and legacy invocations, buit just changing the PEP 517 behaviour would be very helpful as well.

What about when PEP 621 lands? I'd hope eventually you could configure setuptools (for pure Python, at least) entirely from pyproject.toml. For __legacy__, sure. And if no configuration is present, that seems like it should always be an error, rather than producing UNKNOWN.

I think the __legacy__ part of this is a red herring. We should probably raise an exception when no configuration information is present, regardless of the backend used. Once that's done, the rest of it won't matter.

Can the legacy backend enforce that a setup.py file must exist?
The language in PEP 517 seems to imply that the expectation is for the file to exist, in projects built with the legacy backend:

I think that language is at best ambiguous, but I read it as saying, "You can invoke setup.py if it's there, or use the legacy backend".
It seems like a pretty niche situation, though, for someone to be relying on PEP 517 behavior but unwilling to create a well-formed pyproject.toml file. Still, I'm inclined to just leave things as they are and simply start raising exceptions when required metadata like name are left unspecified.

Note that the medium-term plan very much is to enforce PEP 517 by default, and this issue is one of the blockers to doing that.

No, since you are allowed to call setup.py in the classic backend, then a valid PEP 517 builder could do that. You must have either setup.py or pyproject.toml, and pip/build both artificially enforce that.

You must have either setup.py or pyproject.toml, and pip/build both artificially enforce that.

Assuming this is true, then how is this issue a blocker for PEP 517 by default?
I should point out that the __legacy__ backend has the same behavior as classic setuptools, which will build in an empty directory using default metadata:
draft $ ls
draft $ pip-run -q setuptools wheel -- -c "import setuptools; setuptools.setup()" bdist_wheel
running bdist_wheel
running build
installing to build/bdist.macosx-10.9-universal2/wheel
running install
running install_egg_info
running egg_info
creating UNKNOWN.egg-info
writing UNKNOWN.egg-info/PKG-INFO
writing dependency_links to UNKNOWN.egg-info/dependency_links.txt
writing top-level names to UNKNOWN.egg-info/top_level.txt
writing manifest file 'UNKNOWN.egg-info/SOURCES.txt'
reading manifest file 'UNKNOWN.egg-info/SOURCES.txt'
writing manifest file 'UNKNOWN.egg-info/SOURCES.txt'
Copying UNKNOWN.egg-info to build/bdist.macosx-10.9-universal2/wheel/UNKNOWN-0.0.0-py3.10.egg-info
running install_scripts
creating build/bdist.macosx-10.9-universal2/wheel/UNKNOWN-0.0.0.dist-info/WHEEL
creating 'dist/UNKNOWN-0.0.0-py3-none-any.whl' and adding 'build/bdist.macosx-10.9-universal2/wheel' to it
adding 'UNKNOWN-0.0.0.dist-info/METADATA'
adding 'UNKNOWN-0.0.0.dist-info/WHEEL'
adding 'UNKNOWN-0.0.0.dist-info/top_level.txt'
adding 'UNKNOWN-0.0.0.dist-info/RECORD'
removing build/bdist.macosx-10.9-universal2/wheel

This might be a problem in scripted environments. I would have expect an error here. Is this behavior deliberate or accidental?

I believe this behavior is somewhat deliberate, to provide reasonable defaults and let the project evolve specific values as needed.
Since this issue is specifically about __legacy__ and since the behavior of __legacy__ matches that of classic Setuptools invocation, I'm inclined to say let's let legacy continue to operate the way it setup() did, unless there's a good reason the behavior needs to change... and then address the issue more generally.
Since this issue has a lot more context than #2799, I'm going to re-scope this issue to the larger issue at hand and close that one as duplicate.

I've been thinking a lot lately how I'd like to build a backend that requires zero configuration. We already see demonstrations of backends that derive metadata and configuration from existing sources:

version from git tags
manifest from git metadata
python files automatically included from packages

I can imagine a world where a backend could derive reasonable defaults for metadata for a basic package from other common sources:

author from commit history or repo owner
name from directory name or origin URL or sole package discovered
description from repo metadata
long description from readme

Such a backend would limit the need for boilerplate and templates and provide a streamlined experience for new and experienced users. In such a world, there is no required metadata.
I suspect that's the principle that Setuptools and distutils were going for when they allowed building an empty directory. That is, if you build a degenerate project, you get a degenerate distribution.
To that end, I'm reluctant to require any metadata. I'm not even sure it's viable to require metadata when plugins are able to supply that metadata (such as setuptools_scm does for version today).
I'd like to explore more the failure modes that led to this discussion. In particular:

Note that the medium-term plan very much is to enforce PEP 517 by default, and this issue is one of the blockers to doing that.

This might be a problem in scripted environments.

Can you explain more about the problems that occur other than the surprise that it succeeds?

That any arbitrary directory on the file system is a valid setuptools package by this definition. Create an empty directory. Run pip install --use-pep517 on that directory. Notice that setuptools will happily create a package out of that.
This means that passing the wrong path to pip (however you do that — a typo, an environment variable that expanded wrong etc) will result in setuptools zipping everything up. It also blurs the boundary of what a package is. PEP 517 explicitly declares there are two kinds - setup.py based and pyproject.toml based. Currently, setuptools doesn’t enforce either constraint.
While I’m sure there’s certainly space for innovation and experimentation for zero configuration build backends, I highly encourage you to not try taking setuptools down that route. There are significant backwards compatibility constraints here, and it’s much better for that sort of innovation and experimentation to happen in a separate build backend IMO.

FWIW, pip isn’t enforcing setup.py or pyproject.toml to exist.

https://github.com/pypa/pip/pull/10031 & https://github.com/pypa/pip/pull/10031

FWIW, name is required in PEP 621. Also, I think it's fine to not specify name / version, etc, immediately, but by the time you are ready to make the output, if nothing has added it, it doesn't seem to make sense to build without name and versions, since they are part of the output file name.

I don't disagree that name and version are required. I'm just saying that it's plausible, even possibly desirable, that it's not the user's responsibility to supply those, but that the build tool could supply those, perhaps using default values or inferring the values from better data. For example, 0 is a perfectly reasonable default version, especially for a project where a version is never needed. And a name of 'UNKNOWN', while a little awkward, is justifiable for the same reason.
I don't feel strongly about it, and I do think 'UNKNOWN' probably should go, and that the system should error if no suitable name can be determined. On the other hand, a default version of 0 seems right to me and I can imagine lots of scenarios where that behavior would be useful (imagine a private environment where a suite of libraries are always built/installed from source and the version is unimportant to the design).

I don't disagree that name and version are required. I'm just saying that it's plausible, even possibly desirable, that it's not the user's responsibility to supply those, but that the build tool could supply those, perhaps using default values or inferring the values from better data. For example, 0 is a perfectly reasonable default version, especially for a project where a version is never needed. And a name of 'UNKNOWN', while a little awkward, is justifiable for the same reason.

My proposal was that we should validate these things as the last thing we do before generating a distribution. I think we can agree that we don't support a scenario where these things are supported after the artifact is generated, so I think our positions are not in conflict.

I don't feel strongly about it, and I do think 'UNKNOWN' probably should go, and that the system should error if no suitable name can be determined. On the other hand, a default version of 0 seems right to me and I can imagine lots of scenarios where that behavior would be useful (imagine a private environment where a suite of libraries are always built/installed from source and the version is unimportant to the design).

I feel like this is a rare enough scenario (and "oops I forgot to specify a version number" a common enough scenario) that we can impose upon people who don't care about version numbers to just specify a hard-coded version or specify some plugin that supplies one, no?

I feel like this is a rare enough scenario (and "oops I forgot to specify a version number" a common enough scenario) that we can impose upon people who don't care about version numbers to just specify a hard-coded version or specify some plugin that supplies one, no?

How about using a warning here + changing the default version to something more obvious (and/or unique at every run), for example a combination of dev and local segments could be added by default (for example 0.dev20201204+UNKNOWN.a23e87f or even 0.0.0.a0.dev1637232588+UNKNOWN.f234c342a).
I believe that by adding a local segment, at least PyPI would reject the upload, so the chances of this kind of distribution to be made publicly available by mistake would drop.

The problem is that setuptools is generally and increasingly used as a part of an automated workflow (e.g. pip install), and generating anything without an explicit error makes logical errors difficult to spot, even with a warning emitted in the middle of the process, when you’re inspecting only the final product of that entire workflow.

That is an interesting point to analyse. What precisely the error/problem that would be important to avoid/spot?
From a pragmatic point of view, I was supposing that the main problem here is having 2 distributions with the same nominal version (0.0.0) but representing 2 different states of the files (i.e., changes between builds not reflected in the version).
For this problem, forcing the user to hard-code a version number will not help a lot, since in a future build the user can forget to bump it. Indeed, in this scenario proposal 2 (see bellow) helps more to avoid errors.

Summary of the current behaviour and proposals (so far) for missing version.
a) Current behaviour: setuptools considers version = 0, when it is not provided
b) Proposal 1: Raise an error when version is not provided
c) Proposal 2: Generate a more specific version, with a "dev" segment monotonic increasing with time and a "local" segment unique per run OR state of the files (e.g. hash of the concatenated hash of the files in the dist)

Add a PYTHONWARNINGS environment variable to that, and you can make a CI/automated workflow to fail, if that is important to you.

I'm inclined to stick with the current behavior. There's value in not requiring these metadata values to be supplied in cases where the metadata is unimportant (tests, for one). The default values supplied are good defaults (UNKNOWN for name, 0 for version). The pip/build controls already provide good guardrails on ensuring the basic assumptions are met.
I'd similarly like the validation to work in a layered approach, where the basic building blocks are lenient, allowing for degenerate behavior, but where specific workflows (such as building for release) enable more complex behaviors such as validations.
Any solution for this should be holistic and not bolt the behavior on. It should probably coordinate with the config validation and the default metadata values. We can explore these options more readily once the distutils merge is complete.
In the meantime, the issue, as reported is working as intended.

So the validation PR was merged without actually hooking the validation logic onto anything or have I misunderstood? Meaning that setuptools will continue to build dists out of thin air.
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, January 30th, 2022 at 00:32, Jason R. Coombs @.***> wrote:

I'm inclined to stick with the current behavior. There's value in not requiring these metadata values to be supplied in cases where the metadata is unimportant (tests, for one). The default values supplied are good defaults (UNKNOWN for name, 0 for version). The pip/build controls already provide good guardrails on ensuring the basic assumptions are met.
I'd similarly like the validation to work in a layered approach, where the basic building blocks are lenient, allowing for degenerate behavior, but where specific workflows (such as building for release) enable more complex behaviors such as validations.
Any solution for this should be holistic and not bolt the behavior on. It should probably coordinate with the config validation and the default metadata values. We can explore these options more readily once the distutils merge is complete.
In the meantime, the issue, as reported is working as intended.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.Message ID: @.***>

So the validation PR was merged without actually hooking the validation logic onto anything or have I misunderstood?

Yes, that's right. I kept the code because I thought it might prove useful to have at some point, but you make a good point - it's probably not worth keeping that uncalled functionality around.

Meaning that setuptools will continue to build dists out of thin air.

Correct. And after thinking about this more, I'm confident this approach is the right one. After all, there are already protections against building a dist out of an empty directory in the higher level build tools. Setuptools is a lower-level build tool, where direct invocation of setup.py is discouraged, but where it may prove useful to do so for debug/triage/experimentation/testing. There are many constraints one may wish to apply to consider a distribution valid, including having a name and version, but also having modules/packages, entry points, dependencies, etcetera. But as each of those factors are composed to form the distribution, each factor also has a degenerate form (no modules/packages, no entry points, no dependencies). For name and version, the degenerate form is "UNKNOWN" and 0, respectively.
Moreover, there is already some metadata validation that happens as part of the config processing as well as other stages in the development process (invoking build, invoking twine, uploading to pypi).
Since there's value in supporting a degenerate distribution and there are complications with adding that constraint and because it's a long-held expectation, I'd like to keep it for now. The concern about the potential __legacy__ mismatch turned out not to be real. The concern about pip or build installing an empty directory turned out not to be real.
I'd like to explore the possibility of removing the default UNKNOWN values, an exploration which may likely lead to a failure on no name, but I'd like to see that as a larger design and probably after the distutils merge is complete.

I'm a bit saddened to see this closed as no-action. ☹

That is, if you build a degenerate project, you get a degenerate distribution.

I'd argue this is a significantly worse experience than: if you build a degenerate project, you get an error telling you where you went wrong.

I still feel that adding a clear failure mode that "you're missing a name and/or version" instead of a default UNKNOWN-0.0.0 distribution would be extremely helpful to users, especially for diagnosing failure modes with setuptools.

Moreover, there is already some metadata validation that happens as part of the config processing as well as other stages in the development process (invoking build, invoking twine, uploading to pypi).

No stage contains protections against 0.0.0 versions. Only PyPI blocks unknown distribution versions.
I don't think that any level of tooling other than setuptools itself should hold protections for this.


Add com.snowplowanalytics.snowplow/anon_ip/jsonschema/1-0-1

Related to https://github.com/snowplow/snowplow/issues/4222

I have change the title, as it was "pointing" to fingerprinting instead of anon_ip


Fix circular dependency

In the latest version of smelte 0.2.1 I observed a circular dependency warning:
 (!) Circular dependency: node_modules/smelte/src/index.js -> node_modules/smelte/src/components/NavigationDrawer/index.js -> node_modules/smelte/src/co mponents/NavigationDrawer/NavigationDrawer.svelte -> node_modules/smelte/src/index.js

We still want to expose breakpoints in imports.

Maybe putting them in utils?

wouldn't it fix the circular dependency error just by changing the import statement?

Of course it will work, but everytime we are gonna import breakpoints in the components we are going to get a circular dependency.

Alright, looks good, we're exporting breakpoints already anyway

Oh, but can you please fix the conflict?


Showing components with theme props

Hello,
We are developing a new website and we want to make use of storybook to show our components usage. We are using a ThemeProvider to pass our theme as a prop in our website.
  <ThemeProvider theme={theme}>
    <App />
  </ThemeProvider>

Our core components use theme props.
const StyledButton = styled(MaterialButton)`
  && {
    color: ${props =>
      props.variant === "raised" ? "#fff" : props.theme.mainColor};
    text-transform: capitalize;
  }
`;

class Button extends React.Component {
  render() {
    console.log(this.props)
    return <StyledButton {...this.props}/>;
  }
}

The question is how can we pass our theme in Storybook? Because as you know we have to make our own stories of each component separately like this:
stories.add(
  "Button",
  withInfo(`
      description or documentation about my component, supports markdown
    `)(() => (
      <Button
        onClick={action("clicked")}
        variant={select(
          variantLabel,
          variantOptions,
          variantDefaultValue,
          variantGroupId
        )}
        disabled={boolean("Disabled", false)}
        color={select(
          colorLabel,
          colorOptions,
          colorDefaultValue,
          colorGroupId
        )}
      >
        {text("Label", "Search")}
      </Button>
  ))
);

Do we need to pass ThemeProvider in every stories or there is another way?

You can use a decorator per story or even a global decorator.
https://storybook.js.org/addons/introduction/#storybook-decorators


about.md

It looks like you are attempting to push a change to the part repository, for help with deploying please start a new thread in the discussions.

I'm sorry that this is my first time using github, and I tried to make a page based on some web tutorials and my own guesses. This page is used to submit articles to academic conferences, and hopefully if I make a mistake it won't affect the URL.
---- Replied Message ----
From  @.> Date  05/31/2024 03:03 To  @.> Cc<EMAIL_ADDRESS>Subject  Re: [academicpages/academicpages.github.io] about.md (PR #2161)
Closed #2161.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>


Rename repo option to cros/arc option

Rename the --repo option to specify the directory path
Use the --cros option for ChromeOS paths and the --arc option for Android paths

I have to say as a native english speaker this is not clear.
It should be cros_repo and arc_repo imo

I prefer to keep those options as --arc and --cros as they are common parameters across the lium world and keep them short enough is very important to keep the documentations with lium commands clean.


Use MINIKUBE_HOME env var if exist

We currently assume minikube is installed using default user home directory, but minikube can also use MINIKUBE_HOME [1]
[1] https://minikube.sigs.k8s.io/docs/handbook/config/#environment-variables

@nirs please review


NumberFormatter: added docs for {style: percent}

Fixes: https://github.com/jquery/globalize/issues/504

:+1:
Waiting to merge to ensure @jzaefferer has time to review as well.

@jzaefferer @rxaviers Addressed comments.  Should I leave the header as is for now?

Looks good!
Could you do another PR to improve the headers?

@wescravens landed. Thanks


chore: remove sqlite for user base image

Related issue
# followed by the number of the issue
Summary
Notes
Please check if the PR fulfills these requirements

[ ] If the feature has an impact on the user experience, the changelog has been updated
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)
[ ] The commit message follows the conventional commit specification

End to end tests: :hourglass_flowing_sand: STARTING

/e2e --tests substrafl,camelyon

End to end tests: :hourglass_flowing_sand: STARTING


can you give me your paper?

Hi，koide:
I'm learning your open source code of hdl_graph_slam， can you give me your paper (Kenji Koide, Jun Miura, and Emanuele Menegatti, A Portable 3D LIDAR-based System for Long-term and Wide-area People Behavior Measurement, IEEE Transactions on Human-Machine Systems)?My e-mail is<EMAIL_ADDRESS>I promise not to be used for commercial purposes, but for learning.Thanks very much.
Yours
LiYing

Hi @Liying0824 ,
Please see the mail I sent you.

Hi @koide3 ,
Thank you very much.

Hi!
Could you send your paper to me too<EMAIL_ADDRESS>Thanks!

Hello @koide3 ,
I am very much interested to read your paper. Can you please send me the same to the following mail address<EMAIL_ADDRESS>?
Thanks a lot.
Regards,
Sathya Narayanan K

Hello!
Could you send your paper to me too? I am learning about the 3D Lidar slam.
My email is<EMAIL_ADDRESS>Thanks

Hello @koide3 ,
could you send your paper to me ,too? I am also interested in your work about 3D slam.
My email address is<EMAIL_ADDRESS>Thanks a lot!

Hi guys,
Please do NOT request the paper at this issue since I do not check CLOSED issues usually. In case you need the paper, send a mail to<EMAIL_ADDRESS>from your official address in your institute or organization.

Hi @koide3  ,
I ran your code and achieved good results. Could you send your paper to me?
My email address is<EMAIL_ADDRESS>Regards,
Guangwei.Liu

Could you send your paper to me?
My email address is<EMAIL_ADDRESS>Thank you so much~


Crash After update 0.5 latest version.

After update 0.4.6 to latest 0.5 version. App will crash sometime. Kindly check firebase crash log for more information
Please fix this issue ASAP.
$s15SwiftCentrifuge0B6ClientC17processDisconnect026_12C4909875FCC3D7D1C358D22I5F4A90LL4code6reason9reconnectys6UInt32V_SSSbtF

I'll try to take a look soon, a bit hard to address without reproducer though. Were you able to reproduce this locally?

I can't able to reproduce this locally.

Was able to reproduce a couple of crashes by stressing out some SDK code paths, fixed in #69 . I think it may be the reason of crash reported here, check out 0.5.1 release.

@sandeep-yudiz hello, did you get a chance to try the new version? Does the problem persist or fixed?

Fixed issue after update.

Awesome, thanks for reporting and checking, closing then.


[SR-16111] [SymbolKit] Provide a simplified method for reading a symbol's or relationship's mixins

Previous ID
SR-16111

Radar
None

Original Reporter
@QuietMisdreavus

Type
Improvement

Additional Detail from JIRA

Votes
0

Component/s
Swift-DocC

Labels
Improvement

Assignee
None

Priority
Medium

md5: 9c3463d48a54fbd06e0e7b6bba7d89d2

Issue Description:
SymbolKit currently defines optional data fields for symbols and relationships as a set of "mixins", which is represented as a map from a "mixin key" to the parsed value of that mixin. Swift-DocC uses these mixins for various uses, but checking for a value and reading it out is a bit cumbersome. For example, this is how Swift-DocC loads availability information from a symbol:
if var availability = symbol.mixins[SymbolGraph.Symbol.Availability.mixinKey] as? SymbolGraph.Symbol.Availability
This could be greatly simplified into some kind of getMixin method on symbols and relationships in SymbolKit. It could look something like this:
func getMixin<T>() -> T? where T: Mixin {
    self.mixins[T.mixinKey] as? T
}

In fact, Swift-DocC already defines something similar, as an extension on mixin dictionaries themselves:
extension Dictionary where Key == String, Value == Mixin {
    func getValueIfPresent<T>(for mixinType: T.Type) -> T? where T: Mixin {
        return self[mixinType.mixinKey] as? T
    }
}

Adding one of these methods to SymbolKit and encouraging its use throughout Swift-DocC would make its codebase much more readable.

@shahmishal This should be transferred to swift-docc-symbolkit.

apple/swift-docc-symbolkit#39 added a subscript which does just that on Symbol and Relationship:
Usage example:
if let declarationFragments = mySymbol[mixin: SymbolGraph.Symbol.DeclarationFragments.self] {
    // ...
}

I think this can therefore be closed.

cc @d-ronnqvist who was also looking into this last week
I think David wanted a version that force-casted the mixin to the mixin type if the key was present, and/or provide a debug assertion on it, but Max's patch definitely fits the spirit of what i was asking for originally.
I'm going to close this issue as resolved, but @d-ronnqvist can chime in with more details if he wants.

Yes, I agree with closing this issue as resolved.
At one point I was thinking that perhaps the subscript should assert in debug builds that the generic mix-in for a given key is of that generic type. As far as I'm aware this should always hold true for all the built-in mix-ins.
That said, we can always consider something like that in the future if we run into issues with mix-ins unexpectedly returning nil due to key collisions or data format version differences.


Performance degradation: DataArray with dtype=object of DataArray gets very slow indexing

I did not follow the code deeply, but there clearly seems to be a huge overhead when indexing such arrays. In particular, in the following code
import xarray as xr
import numpy as np

a = xr.DataArray([None for k in range(100)],dims='c')
for k in range(a.c.size):
    a[k] = xr.DataArray(np.random.randn(1000,5),dims=['a','b'])

%prun a[0]

the indexing operation takes about 1 second on my machine, or 2 seconds when running under the profiler. The profiler output shows lots of functions with a recursive call count exceeding 100'000 (most likely iterating through each row of the contained sub-arrays). However, there is really no reason to iterate through the nested elements.

Nesting xarray objects was not an intended use case, but I agree, this is ridiculously slow.
Looks the culprit is xarray.core.utils.to_0d_object_array:
https://github.com/pydata/xarray/blob/d66f673ab25fe0fc0483bd5d67479fc94a14e46d/xarray/core/utils.py#L198-L212
Specifically, when value is an xarray.DataArray, these lines appear to trigger a iterating over every element of the DataArray, one by one:
result = np.empty((1,), dtype=object)
result[:] = [value]

I'm definitely open to fixes here. Creating a NumPy object array can be very fussy -- NumPy tries way too hard to coerce dtypes.

Well, xarrays are way too useful not to nest them, even if that involves the scary dtype=object :-). Thanks for pointing me in the right direction, I'll try to find a fix.

I think I found it (#1122). I guess whenever a non-scalar assignment is made (as in result[:] = [value]), something like np.asanyarray is performed on the new value. Luckily, numpy is perfectly happy with indexing of a 0d array with a 0d index (i.e. an empty tuple).
Thinking about it, result[0] = value would probably have worked too.


fixes # 42 - Improve styling of title (sliding images) section

Improved css and button modifications on the MyCarousel component, the white text appears clearer on shadowed background, the button gets bigger and shakes upon hover, (all conflicts resolved)

Yeah it looks fine, but can you decrease the opacity of filter that you have put on the background image? Also remove the shake effect on button on hover.

hi,
I have created a new pull request with the requested updates, please refer: https://github.com/arcVaishali/stellar-vision/pull/62


Why are none of bash_it's aliases, completions, or plugins enabled by default?

On a newly imaged machine, I had to copy the available directories to enabled in each the aliases, completions, and plugins directories and open a new terminal window before I had the setup I expected on the machine.
Why don't we enable at least some subset of these features by default?

You shouldn't have to copy any directories. Bash it provides a command line interface to enable and disable things.
For the most part we're staying about from configs and preferences since that tends to be a project/office specific thing.

There's probably an opportunity for something better in the README on this topic.

Agreed. I just couldn't piece it together on my phone last night.

Also I think there's maybe an easier argument for turning on a small selection of bash completions. I think that there wouldn't be a problem with the git one turned on, for example. Aliases and plugins are more divisive.

Oh and for a quick answer on how to use the bash-it CLI:
$ bash-it show plugins
$ bash-it help aliases
$ bash-it enable plugin git
$ bash-it disable alias hg
$ bash-it update
$ bash-it search ruby

Thanks Grant, that is really helpful. My suggestion would be to replicate
sprout wrap defaults and then so office specific customizations in a
readme. That way offices can follow the normal convention or opt out with
something that they prefer.
On Thu, Apr 28, 2016 at 7:14 AM Grant Hutchins<EMAIL_ADDRESS>wrote:

Oh and for a quick answer on how to use the bash-it CLI:
$ bash-it show plugins
$ bash-it help aliases
$ bash-it enable plugin git
$ bash-it disable alias hg
$ bash-it update
$ bash-it search ruby
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/pivotal/workstation-setup/issues/36#issuecomment-215436695

How about we add a "customize.sh-example" at the end of the provisioning script (with customize.sh in .gitignore) with a bunch of example stuff commented out. Then users can uncomment the stuff they want. And something in the README that points them to the file.

What I really wanted was just the ll alias, so @nertzy's suggestion of making a small subset enabled by default sounds good to me.

For better or worse, I have added git completion (e.g. for branches) and plugin ssh. I believe these not to be controversial.

Is it safe to close this issue?

I think so.


Upload file name with multilingual

I upload file with
cpr::Response r = cpr::Post(cpr::Url(cpr::Url{ szURL.c_str() }),
cpr::Multipart{ {"Filename", "切結書.jpeg"},
{"Filedata", cpr::File{"c:\切結書.jpeg"}, "application/octet-stream"} }
and send data "filename="������.jpeg"" not transfer to utf-8
--------------------------f0fa9ab880cbecc9
Content-Disposition: form-data; name="Filename"
切結書.jpeg
--------------------------f0fa9ab880cbecc9
Content-Disposition: form-data; name="Filedata"; filename="������.jpeg"
Content-Type: application/octet-stream

Dude it's really hard to read and understand your issues if you first of all do not highlight your code.
Again: https://guides.github.com/pdfs/markdown-cheatsheet-online.pdf
Also please follow those guidelines for creating an issue: https://developers.google.com/blockly/guides/modify/contribute/write_a_good_issue
All in all I do not understand what you issue is.
Perhaps it might be a duplicate of this one: https://github.com/whoshuu/cpr/issues/590


Update ActionButton colors

Closes
Waiting on design to release new colors.
✅ Pull Request Checklist:

[ ] Included link to corresponding React Spectrum GitHub Issue.
[ ] Added/updated unit tests and storybook for this change (for new code or code which already has tests).
[ ] Filled out test instructions.
[ ] Updated documentation (if it already exists for this component).
[ ] Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:

🧢 Your Project:

closing in favor of https://github.com/adobe/react-spectrum/pull/3650


[FEAT] connect: add parquet support

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#3360  👈 (View in Graphite)
#3355 : 3 other dependent PRs (#3350 , #3354 , #3357 )
#3342 : 6 other dependent PRs (#3344 , #3345 , #3348  and 3 others)
#3343 : 2 other dependent PRs (#3309 , #3326 )
#3341
main

This stack of pull requests is managed by Graphite. Learn more about stacking.


Adding any compose dependency breaks resolving the Gradle configuration

When I am adding the compose dependency to a (resolvable) Gradle configuration (includeImplementation is my custom configuration) as follows:
includeImplementation(compose.desktop.currentOs) // same with common

and then trying to resolve the dependencies of this configuration
includeImplementation.resolvedConfiguration.firstLevelModuleDependencies

I am getting the following error
Caused by: org.gradle.internal.component.AmbiguousConfigurationSelectionException: Cannot choose between the following variants of org.jetbrains.compose.foundation:foundation:1.0.0-beta5:
  - debugRuntimeElements-published
  - desktopRuntimeElements-published
  - releaseRuntimeElements-published

(probably relates to this)
My custom configuration above is one example, but there are other scenarios where you have to use custom configurations from third-party Gradle plugins, and therefore using this together with Compose does not work.

Do you use Kotlin multiplatform gradle plugin? Since Compose is published like a multiplatform solution, this plugin is required for dependency resolution

I am not using the multiplatform plugin, because I am having trouble to use the custom configuration from the third party plugin in the scope of KotlinDependencyHandler, as this scope only has some predefined standard configurations available for use.

plugins {
    kotlin("jvm") version "1.5.31"
    id("fabric-loom") version "0.10-SNAPSHOT"
    kotlin("plugin.serialization") version "1.5.31"
    id("org.jetbrains.compose") version "1.0.0-beta5"
}

repositories {
    mavenCentral()
    google()
    maven("https://maven.fabricmc.net/")
    mavenLocal()
    maven("https://oss.sonatype.org/content/repositories/snapshots")
    maven("https://maven.pkg.jetbrains.space/public/p/compose/dev")
}

val includeImplementation by configurations.creating {
    configurations.implementation.configure { extendsFrom(this@creating) }
}

dependencies {
    minecraft("com.mojang:minecraft:$minecraftVersion")
    mappings("net.fabricmc:yarn:$yarnMappingsVersion")
    modImplementation("net.fabricmc:fabric-loader:$fabricLoaderVersion")
    modImplementation("net.fabricmc.fabric-api:fabric-api:$fabricApiVersion")
    modImplementation("net.fabricmc:fabric-language-kotlin:$fabricLanguageKotlinVersion")

    implementation(compose.desktop.currentOs)

    includeImplementation("org.litote.kmongo:kmongo-coroutine-core:4.3.0")
    includeImplementation("org.litote.kmongo:kmongo-serialization-mapping:4.3.0")
    includeImplementation("org.slf4j:slf4j-simple:1.7.32")
    includeImplementation("org.apache.commons:commons-text:1.9")

    // example usage which triggers the error
    includeImplementation.resolvedConfiguration.firstLevelModuleDependencies
}

Or is there any way I could convert this project using Compose to a project using the multiplatform plugin?

Or is there any way I could convert this project using Compose to a project using the multiplatform plugin?

Yes, it is quite easy.
Replace kotlin("jvm") version "1.5.31" with kotlin("multiplatform") version "1.5.31"
add the code below and move dependencies there. It should work.
kotlin {
    jvm {
        withJava()
    }
    sourceSets {
        named("jvmMain") {
            dependencies {
>>put dependencies here
            }
        }
    }
}

Yes I already tried that, but he custom configurations such as modImplementation etc are not available there.

What are these custom functions for?

As an option, you could split code in two modules. Use Compose+mpp plugin in one module and custom imports in another.

What are these custom functions for?

They are Gradle configurations, minecraft specified the Minecraft dependency, mappings specifies the mappings for Minecraft and modImplementation adds Minecraft mods.

As an option, you could split code in two modules. Use Compose+mpp plugin in one module and custom imports in another.

I could do that, but I would still have to execute includeImplementation.resolvedConfiguration.firstLevelModuleDependencies in the other module dependening on the compose module, which would lead to the same error.

I could do that, but I would still have to execute includeImplementation.resolvedConfiguration.firstLevelModuleDependencies in the other module dependening on the compose module, which would lead to the same error

Could you share you build scripts? I struggle to understand that is the issue

The simplest example would be just to try and shade the compose dependency using the Gradle shadow plugin in a JVM context. Not that I'd recommend this, but this will trigger the problem I mean, as it tried to resolve the compose dependency as well.

To trigger the problem:
plugins {
    kotlin("jvm") version "1.6.10"
    id("org.jetbrains.compose") version "1.0.1-rc2"
    id("com.github.johnrengelman.shadow") version "7.1.1"
}

repositories {
    mavenCentral()
    google()
    maven("https://maven.pkg.jetbrains.space/public/p/compose/dev")
}

val embed: Configuration by configurations.creating

dependencies {
    embed(implementation(compose.desktop.currentOs)!!)
}

tasks {
    shadowJar {
        configurations = listOf(embed)
    }
}

I guess you meant don not provide. What exactly is missing?

I guess you meant don not provide.

correct

What exactly is missing?

The custom Gradle configurations and compatiblity with other Gradle plugins as shown in my previous comment.

With release 1.0.1 the issue was resolved, but with 1.1.0 it was reintroduced.

having the same issues building fatjar with compose dependencies

Have the same issues building fatjar with compose dependencies

I tried to use a separate project with the Kotlin Multiplatform Gradle plugin, but the same issue comes up there as well.
Asking more generally:
How can I get a list of all transitive dependencies of compose.desktop.common, using either the JVM or the Multiplatform Plugin. With all the methods I tried, I always get the "Cannot choose between the following variants" error.

Related issue: https://github.com/JetBrains/skiko/issues/547

Generally speaking, the issue here is not if one uses the Kotlin Multiplatform plugin or not, but that Gradle does not have enough information about which artifact it should use.
To fix this, the Compose Gradle plugin should ask for the correct UI attribute. For this to work correctly, I think skiko has to provide the correct attributes with each artifact first. Also, skiko should add a namespace to the ui attribute - I also added that to the skiko issue.
Temporary fix
I found out that you can apparently "fix" this by using some weird Gradle behaviour, and ask for an ui attribute that does not even exist. Let's use awt, just because it makes sense in this case.
To apply this fix, do this, either using configurations.all or just for your configuration which you use to shade or include dependencies:
configurations.all {
    attributes {
        attribute(Attribute.of("ui", String::class.java), "awt")
    }
}

Some time ago I was running into Cannot choose between the following variants and came up with this snippet:
tasks.register("printRuntimeDependencies") {
    println("Project runtime dependencies:")
    allprojects {
        println()
        println("-------- ${project.name} --------")
        project.configurations.matching { it.name == "desktopRuntimeClasspath" }
            .matching { !it.allDependencies.isEmpty() }
            .forEach {
                it.allDependencies.forEach { dep ->
                    if (dep.group != null) {
                        println("${dep.group}:${dep.name}:${dep.version}")
                    }
                }
            }
    }
}

@jakobkmar Thank you for your workaround!

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.


Add source map support

I'm happy to jump on a PR for this sometime this week. Babelify should be a good reference.

Oh yeah, that'd be great! I'm giving you commit rights so you can merge when you see fit - thanks!

Done - can now commit to npm and github. Added @ahdinosaur too :sparkles:

neat, thanks! :sparkles:


No output running reviewdog

I have been trying to implement reviewdog with my gradle task that runs ktlint with some settings applied.
After running ktlint task it generates result files which I print and pipe to reviewdog.
Unfortunately, reviewdog passes and does not produce any output in my github actions.
    - name: Write comments with reviewdog
      if: always()
        env:
          REVIEWDOG_GITHUB_API_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          cat app/build/reports/ktlint/*/*.txt | \
          reviewdog -efm="%f:%l:%c: %m"\
          -name="ktlint" \
          -reporter=github-pr-review \
          -fail-on-error=true \
          -filter-mode=nofilter

I thought that the issue may be with reporting to github, but when I set up it locally, I still don't get any output.
➜  cat app/build/reports/ktlint/*/*.txt
/Users/username/Projects/AndroidStudioProjects/myproject/app/src/test/java/com/project/ui/darkmode/SomeKotlinFile.kt:24:52: Missing newline before "}" (indent)

➜  cat app/build/reports/ktlint/*/*.txt | reviewdog -diff="git diff" -efm="%f:%l:%c: %m"

I tried to use -tee flag to see if input is really passed to reviewdog and seems like it is.

Finally fixed the issue. Turns out that my output had ANSI color characters that are automatically handled by terminal and are visible only when opened with text editor that does not support that. My final solution looks something like this:
```

name: Run ktlint
run: ./gradlew ktlintCheck --continue

name: Check ktlint results
env:
REVIEWDOG_GITHUB_API_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
cat app/build/reports/ktlint//.txt |
sed -e 's/\x1b[[0-9;]*m//g' |
reviewdog -efm="%f:%l:%c: %m"
-name=ktlint
-reporter=github-pr-review
-filter-mode=nofilter
-fail-on-error=true

Although it was my mistake, it would be a great improvement for reviewdog if it would output some kind of error instead of completing successfully.


cross domain

i met cross-domain and i use this decorate to solve this problem,
http://flask.pocoo.org/snippets/56/
but only if
@crossdomain(origin='*')
can success,and when i try to point a specific domain such as @crossdomain(origin="test.123.com") or
@crossdomain(origin=["test.123.com"]), it failed. what should i do to point a specific domain?
i need help, thx.

question for cross domain.

I did not test this but how about put http://test.123.com ?
Hopefully, this would help.

i have tried this, failed.- -!

Is this a bug? Try asking in IRC channel or stackoverflow for help.

Can you show Access-Control-Allow-Origin header when you request your endpoint?


Add a note in README for pressure sensor not supported when using sense-hat

[rahul-thakoor] As of version v1.1.0 the project does not include pressure sensor value when sense-hat is being used. We should probably add a note regarding this until we support this or decide otherwise with respect to sense-hat pressure sensor.

[rahul-thakoor] This issue has attached support thread https://jel.ly.fish/#/e64f54ed-9a9e-492d-a8d3-237b4528a2b1

Closing this as the pressure sensor works as of 1.9.3 :)


Fresh backend bug, maybe mongodb

Just followed the instructions, result:
[nodemon] starting node src/server.js
(node:11090) Warning: Accessing non-existent property 'count' of module exports inside circular dependency
(Use node --trace-warnings ... to show where the warning was created)
(node:11090) Warning: Accessing non-existent property 'findOne' of module exports inside circular dependency
(node:11090) Warning: Accessing non-existent property 'remove' of module exports inside circular dependency
(node:11090) Warning: Accessing non-existent property 'updateOne' of module exports inside circular dependency
(node:11090) DeprecationWarning: current Server Discovery and Monitoring engine is deprecated, and will be removed in a future version. To use the new Server Discover and Monitoring engine, pass option { useUnifiedTopology: true } to the MongoClient constructor.
(node:11090) UnhandledPromiseRejectionWarning: MongoNetworkError: failed to connect to server [cluster0-shard-00-02-4roep.mongodb.net:27017] on first connect [MongoError: bad auth : Authentication failed.

What the line 20 on backend/src/server.js
mongodb+srv://Mateus:Mateus@cluster0-4roep.mongodb.net/tindev?retryWrites=true&w=majority

Before running the server, you need to change the connection URL with mongodb.

Create a mongodb cluster and then change the database connection URL:
https://github.com/fariasmateuss/tindev/blob/19b90e065b5c3d22f8969bdff859a3d639ccccbf/backend/src/server.js#L20
This will solve the problem.


coc-prettier ignores 'overrides' section of .prettier.rc for supported file types

If you have a file 'foo.hbs' and run :CocCommand prettier.formatFile you get [coc.nvim] html.handlebars not supported by prettier even if you've used:
  "overrides": [
    {
      "files": "*.hbs",
      "options": { "parser": "html" }
    }
  ]

in your local .prettier.rc file

Note that prettier actually has a function specifically for this: prettier.getFileInfo(filePath [, options])
https://prettier.io/docs/en/api.html#prettiergetfileinfofilepath--options

Note that prettier actually has a function specifically for this: prettier.getFileInfo(filePath [, options])
https://prettier.io/docs/en/api.html#prettiergetfileinfofilepath--options

Is this issue resolved?

Not as far as I can tell.

:h g:coc_filetype_map


Could not import matplotlib.pyplot

I'm trying to use the module but I'm not able to make it work.
I get the following error when run the first module call:
me@computer:~/test$ node
> const plt = require('matplotnode');
undefined
> plt.plot([0,1], [5.5,6.5]);
Could not import matplotlib.pyplot.
Segmentation fault (core dumped)

I think that python and matplotlib are well installed. When I run the following code a new window appear with the plot:
me@computer:~/test$ python
Python 2.7.12 (default, Nov 19 2016, 06:48:10)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import matplotlib.pyplot as plt
>>> plt.plot([0,1], [5.5,6.5])
[<matplotlib.lines.Line2D object at 0x7fad157bac50>]
>>> plt.show()

I'm running on Ubuntu 16.04. Have you any idea about what I'm doing wrong?

Same. Did you resolve it?

@ZephD No, I just switched the scripts to python :(

Try with the version I just released. I think I fixed some issues.

Running into this right now with 0.3.0. Running on OSX

Hmm,

Have you installed matplotlib with pip (run pip list | grep matplotlib) and which version is it?
Which version of python are you using on OS X (python --version)? I'm using the built-in python 2.7.10 and it works for me.
Could you run node test.js after install and see if it runs without segmentation fault?

I just tried the following without issues in a completely empty folder on my computer (MacOS 10.14.3). I am confused as to what is causing this issue for you.
npm install matplotnode
node
> const plt = require('matplotnode');
undefined
> plt.plot([0, 1], [5, 6]);
undefined
> plt.show();
undefined
> .exit

I'm on MacOS 10.14.3, matplotlib is version 2.2.4, python is 2.7.15
mkdir test
cd test
npm install matplotnode
node

const plt = require('matplotnode');
undefined
plt.plot([0, 1], [5, 6]);
Could not import matplotlib.pyplot.
[1]    63191 segmentation fault  node

I will see if I can get anywhere with this on my end if I have some time in the near future.

(To clarify, node test.js after install also fails in the same way)

Wow I was using 1.3.1... I think I found the bug (had to call matplotlib.use("TkAgg")). It works for me now on matplotlib 2.2.4.

Also added some PyErr_Print()'s that will hopefully provide clearer error messages.

There might still be memory leaks, since I'm kind of clueless how the Python reference counting works.

Hooray! Works for me as well now.

Closing this, please open a new issue if you encounter this again!