Invalid classifier used for CUDA 12.2

Issue type
Bug
Have you reproduced the bug with TensorFlow Nightly?
Yes
Source
source
TensorFlow version
git HEAD
Custom code
No
OS platform and distribution
Ubuntu 20.04
Mobile device
n/a
Python version
3.9.17
Bazel version
6.1.0
GCC/compiler version
16.0.6
CUDA/cuDNN version
n/a
GPU model and memory
n/a
Current behavior?
Uploads to PyPi fail with invalid classifier.
Introduced by https://github.com/tensorflow/tensorflow/commit/c3b98ea5a8387eec21e808caa6e999417494e09a
Standalone code to reproduce the issue
python3 -m twine upload --verbose /home/ubuntu/actions-runner/_work/tensorflow/tensorflow/whl/* -u "__token__" -p ***

Relevant log output
INFO     Response from https://upload.pypi.org/legacy/:
         400 Invalid value for classifiers. Error: Classifier 'Environment ::
         GPU :: NVIDIA CUDA :: 12.2' is not a valid classifier.
INFO

           <title>400 Invalid value for classifiers. Error: Classifier
         'Environment :: GPU :: NVIDIA CUDA :: 12.2' is not a valid
         classifier.</title>

400 Invalid value for classifiers. Error: Classifier 'Environment
         :: GPU :: NVIDIA CUDA :: 12.2' is not a valid classifier.

           The server could not comply with the request since it is either
         malformed or otherwise incorrect.

         Invalid value for classifiers. Error: Classifier 'Environment ::
         GPU :: NVIDIA CUDA :: 12.2' is not a valid classifier.

ERROR    HTTPError: 400 Bad Request from https://upload.pypi.org/legacy/
         Invalid value for classifiers. Error: Classifier 'Environment :: GPU ::
         NVIDIA CUDA :: 12.2' is not a valid classifier.

https://github.com/tensorflow/tensorflow/actions/runs/6516448173/job/17699971553

Thank you. This is being rolled back for now.
In the meantime, a PR was created to add the classifier to PyPi:
https://github.com/pypa/trove-classifiers/pull/155

Seems like a good idea until the 12.2 tag gets added

PR updated


Control flow should understand T.must as implying non-nil

Problem
If a variable is defined as nilable, but its runtime value is known to be non-nil, a single T.must should be sufficient for the flow control parser to understand that the value is not nil.
T.must will raise if the value is nil, and the flow control currently works with raise, but not with T.must.
For example:

sorbet.run
– Sorbet understands that @n in add! is not nil, and can execute + on it. ✅

# typed: strict
class A
  extend T::Sig

  sig {params(n: T.nilable(Integer)).void}
  def initialize(n)
    @n = T.let(n, T.nilable(Integer))
  end

  sig {returns(T.nilable(Integer))}
  def add!
    raise("missing number") if !@n
    @n + 1
  end
end

sorbet.run – With T.must, Sorbet says Method + does not exist on NilClass component of T.nilable(Integer):

# typed: strict
class A
  extend T::Sig

  sig {params(n: T.nilable(Integer)).void}
  def initialize(n)
    @n = T.let(n, T.nilable(Integer))
  end

  sig {returns(T.nilable(Integer))}
  def add!
    T.must(@n)
    @n + 1
  end
end

Proposed solution
T.must should be understood as implying non-nil in the same method, in the same way that it understands raise if n.nil?.

100% of control-flow sensitive typing is tied to... control flow. If there is no control flow, Sorbet will not apply control-flow sensitive typing.
Thanks for the suggestion, but this is probably a won't do.

T.must will raise if the value is nil

Btw, this is not a valid assumption to make. For example, we suppress the runtime checker on production which means T.must will do nothing. So, you can't just assume that T.must and raise are interchangeable and start treating T.must like a control flow operator.

100% of control-flow sensitive typing is tied to... control flow.

Thanks.
It seems that the distinction is whether Sorbet thinks the variable is definitely local, vs possibly being a method, the return value of which it can't guarantee.
However, there seems to be a hole with raise, which can also be overridden at runtime.
It does seem to understand the difference between an explicitly-overridden raise vs none –
https://sorbet.run/#%23 typed%3A strict
class A
  %23%23 UNCOMMENT ME FOR ERROR - THAT'S GOOD%2C
  %23%23 BUT WHAT IF THIS WAS IN AN UNTYPED FILE%3F
  %23sig {params(msg%3A T.untyped).void}
  %23def raise(msg)
  %23  puts "Hello %23{msg}%2C carry on"
  %23end
end

class B <%20A%0A%20%20extend%20T%3A%3ASig%0A%0A%20%20sig%20%7Bparams(n%3A%20T.nilable(Integer)).returns(T.nilable(Integer))%7D%0A%20%20def%20add(n)%0A%20%20%20%20raise("missing%20number")%20if%20!n%0A%20%20%20%20n%20%2B%201%0A%20%20end%0Aend%0A
– but Sorbet's confidence there that it knows where raise is defined seems inconsistent with the other behaviors here, e.g. it could similarly see what T.must is doing, or any other method; or it similarly does not know if raise is overridden.
This inconsistency leads me to be confused about Sorbet's definition of control flow.

Btw, this is not a valid assumption to make

Sorbet is not guaranteed to work when the runtime checks are disabled. That is why we strongly recommend turning on the runtime checks.

but Sorbet's confidence there that it knows where raise is defined seems inconsistent with the other behaviors here, e.g. it could similarly see what T.must is doing, or any other method; or it similarly does not know if raise is overridden.

To sorbet, raise is always either an unconditional raise. The condition of whether to raise or not to raise must be visible in the source of the method—in this case, it's the if !n that Sorbet uses to do control-flow sensitive typing.
Other than that, raise works like any other method that's defined to return T.noreturn:
https://github.com/sorbet/sorbet/blob/19e6ed2468a2cf62794e21bf255f24c894b8cb4c/rbi/core/kernel.rbi#L2563-L2568
Since Sorbet could see that the overridden raise no longer returned T.noreturn, it knew that there were two paths of control flow through the program that could affect n's type, whereas before it knew there were 2.

Note that anyone is free to implement methods that unconditionally raise; Sorbet will treat them identically to raise itself, as long as they return T.noreturn. What Sorbet does not allow users to model is methods that sometimes raise and sometimes don't, because then the condition is hidden inside that method definition.
All inference in Sorbet is 100% local to the current method being type checked. For sorbet to let the implementation of one method affect the implementation of another method would be a large architectural shift, and would force us to reconsider nearly everything about how we optimize editor query response times.


thread 'main' panicked at 'Ident cannot be a number; use Literal instead' if enum field include numeric values

Description
panicked at 'Ident cannot be a number; use Literal instead' if enum field include numeric values
yes, I know. nobody should define a table using enum like this enum('0','1')  this is terrible and very bad, but, this is a very old project.
and I just got this problem

Steps to Reproduce

create a mysql table with enum which members have numeric values:

CREATE TABLE `num_enum_demo` (
  `id` int unsigned NOT NULL AUTO_INCREMENT,
  `public` enum('0','1') NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

run generate

RUST_BACKTRACE=1 sea-orm-cli generate entity -o src/entity -t num_enum_demo

you will got panic:
thread 'main' panicked at 'Ident cannot be a number; use Literal instead', /path-to/8f6827c7555bfaf8/proc-macro2-1.0.38/src/fallback.rs:683:9
stack backtrace:
   0: std::panicking::begin_panic
   1: proc_macro2::fallback::Ident::_new
   2: proc_macro2::Ident::new
   3: quote::__private::mk_ident
   4: sea_orm_codegen::entity::active_enum::ActiveEnum::impl_active_enum
   5: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter
   6: sea_orm_codegen::entity::writer::EntityWriter::write_sea_orm_active_enums
   7: sea_orm_codegen::entity::writer::EntityWriter::generate
   8: sea_orm_cli::commands::run_generate_command::{{closure}}
   9: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  10: std::thread::local::LocalKey<T>::with
  11: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  12: async_io::driver::block_on
  13: std::thread::local::LocalKey<T>::with
  14: std::thread::local::LocalKey<T>::with
  15: std::thread::local::LocalKey<T>::with
  16: async_std::task::builder::Builder::blocking
  17: sea_orm_cli::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Expected Behavior

no panic
Actual Behavior
panic

Reproduces How Often
always

Versions
sea-orm-cli 0.7.2

Additional Information

I feel like this is a duplicate issue

yes, the same problem.
good to see already has PR
https://github.com/SeaQL/sea-orm/pull/588

@tyt2y3 the table schema is from a very old project, probably at least 10 years ago.
I changed the column to ``public enum('no','yes') NOT NULL DEFAULT 'no' so the panic is gone.
what I want to say is, it the PR is not going to merge. then maybe we should warn user about this and just skip generate model for the table. a panic will stop all the work and user do not know what happend, a more friendly error message is also required.
in my situation, it figured me a lot of time to find out why this happend.
I use a shell script (in Makefile) go generate each table, so I could found which table caused the panic (which I hope sea-orm-cli will tell me)
	sudo podman exec -ti mysql-server-host sh -c 'mysql -uroot -p$$MYSQL_ROOT_PASSWORD -e "SELECT table_name FROM information_schema.tables WHERE table_schema ='"'"'my-table-name'"'"'\G"' | rg TABLE_NAME | awk -F: '{print $$2}' > /tmp/tables.txt
	for tbl in `cat /tmp/tables.txt`; \
    do \
    echo "generating $$(echo -e $${tbl} | tr -d '[:space:]')"; \
    sea-orm-cli generate entity -t $$(echo -e $${tbl} | tr -d '[:space:]') -o src/entity; \
    done

Actually, this is a good suggestion. @billy1624 the generator seems to be opaque on this. I think the general solution is to return a Result everywhere instead of panicking in place and so the parent function can bail with context.
Or really simple... just add more logs with log::debug! such that users can turn on with RUST_LOG=debug

currently the output result of enabling  -v, --verbose    Show debug messages is too noisy, I tried use it and totally do not know what it means. just endless output something like fetch data from schema table.
I think we need a log level config, instead of put everything to debug log and only have a -v switch
Something like "generating for table xxxx" should be info level,  users may happy to see this detail. at leat they know what is doing now.

Hey @ttys3 & @tyt2y3, thanks for the input! I have consolidated the suggestions into an issue

#722


Cannot install via Yarn

Thanks for your great work on this; I'm excited to give it a try! Unfortunately when I try to install it via yarn I get:

error An unexpected error occurred: "https://registry.yarnpkg.com/new-javscript: Not found".

I thought Yarn just reflected the npm registry. Is there something else that would need to be done for this to be installable via Yarn?

Whoops; I swear I can spell! Thank you again.

Wait... I think this was my fault! I just noticed that in the "install via npm" code block in the Readme I misspelled "new-javascript" as "new-javscript"... Should be fixed now, and thanks for making me notice it! I guess that has been lurking around in the Readme for months (or years) 😬. Oh, and thanks for giving the project a try btw!


unable to get story thumbnail

When I use SnapchatKit to fetch story media thumbnail, I have tried such methods:

[SKStory load]
[[SKClient sharedClient] loadStoryThumbnailBlob:story completion:^(id object, NSError *error) {
}];
SKStory.thumbURL

But there is error like this: Load story error: Error Domain=SnapchatKit Code=1 "Unknown blob format" UserInfo=0x7fd878e27b80 {NSLocalizedDescription=Unknown blob format, NSLocalizedFailureReason=Unknown blob format}
when I fetch data from SKStory properth "thumbURL", the format seems not correct, I noticed that SKStory have some encryption properties, Maybe be data is encrypted?
How to fetch the story thumbnails and media.

Tryyyyy using pod 'SnapchatKit', :git => 'https://github.com/ThePantsThief/SnapchatKit.git'
I think it's a bug I fixed but haven't updated the pod with yet
--
Tanner Bennett

On Aug 30, 2015, at 1:45 AM, Ruozi<EMAIL_ADDRESS>wrote:
When I use SnapchatKit to fetch story media thumbnail, I have tried such methods:
[SKStory load]
[[SKClient sharedClient] loadStoryThumbnailBlob:story completion:^(id object, NSError *error) { }];
SKStory.thumbURL
But there is error like this: Load story error: Error Domain=SnapchatKit Code=1 "Unknown blob format" UserInfo=0x7fd878e27b80 {NSLocalizedDescription=Unknown blob format, NSLocalizedFailureReason=Unknown blob format}
when I fetch data from SKStory properth "thumbURL", the format seems not correct, I noticed that SKStory have some encryption properties, Maybe be data is encrypted?
How to fetch the story thumbnails and media.
—
Reply to this email directly or view it on GitHub.

I just use git clone to get code from 'https://github.com/ThePantsThief/SnapchatKit.git' and copy the file in  "Pod" folder.
Then I use this method:
[story loadThumbnail:^(NSError *error) {}];
and get the error message: Error Domain=SnapchatKit Code=1 "Unknown blob format" UserInfo=0x7fe965d39350 {NSLocalizedDescription=Unknown blob format, NSLocalizedFailureReason=Unknown blob format}
But the same methods in SKSnap class works well.

Odd, I'll take a look and get back to you
--
Tanner Bennett

On Aug 30, 2015, at 2:21 AM, Ruozi<EMAIL_ADDRESS>wrote:
I just use git clone to get code from 'https://github.com/ThePantsThief/SnapchatKit.git' and copy the file in "Pod" folder.
Then I use this method:
[story loadThumbnail:^(NSError *error) {}];
and get the error message: Error Domain=SnapchatKit Code=1 "Unknown blob format" UserInfo=0x7fe965d39350 {NSLocalizedDescription=Unknown blob format, NSLocalizedFailureReason=Unknown blob format}
But the same methods in SKSnap class works well.
—
Reply to this email directly or view it on GitHub.

Thx，And I love this kit

Looks like Tanner fixed the blob format parsing in this commit.  @ruozi I'd retry with current master.

I update SnapchatKit and when I use [SKstory loadThumbnail] method, I still got error with description "Error initializing blob with data"  @fisch0920

story blob has been fixed but story thumbblob seems not = =!

I'll get to that next :) much of this library is untested, thanks!
--
Tanner Bennett

On Aug 31, 2015, at 9:56 PM, Ruozi<EMAIL_ADDRESS>wrote:
story blob has been fixed but story thumbblob seems not = =!
—
Reply to this email directly or view it on GitHub.


Cannot read property 'pages' of undefined - ERROR

Hey, I was wondering if anybody has gotten this error when running gatsby develop ?
ERROR
Cannot read property 'pages' of undefined
  TypeError: Cannot read property 'pages' of undefined
  - fetch-nodes-paginated.js:80 paginatedWpNodeFetch
    [ma-fe]/[gatsby-source-wordpress-experimental]/steps/source-nodes/fetch-nodes/fetch-nodes-paginated.js:80:12
  - runMicrotasks
  - task_queues.js:97 processTicksAndRejections
    internal/process/task_queues.js:97:5
  - fetch-nodes.js:61 fetchWPGQLContentNodes
    [ma-fe]/[gatsby-source-wordpress-experimental]/steps/source-nodes/fetch-nodes/fetch-nodes.js:61:24
  - fetch-nodes.js:159
    [ma-fe]/[gatsby-source-wordpress-experimental]/steps/source-nodes/fetch-nodes/fetch-nodes.js:159:32
  - async Promise.all
  - fetch-nodes.js:152 fetchWPGQLContentNodesByContentType
    [ma-fe]/[gatsby-source-wordpress-experimental]/steps/source-nodes/fetch-nodes/fetch-nodes.js:152:5
  - fetch-nodes.js:198 fetchAndCreateAllNodes
    [ma-fe]/[gatsby-source-wordpress-experimental]/steps/source-nodes/fetch-nodes/fetch-nodes.js:198:35
  - index.js:44 sourceNodes
    [ma-fe]/[gatsby-source-wordpress-experimental]/steps/source-nodes/index.js:44:5
  - run-steps.js:23 runSteps
    [ma-fe]/[gatsby-source-wordpress-experimental]/utils/run-steps.js:23:7
 ERROR
 gatsby-source-wordpress
        Encountered a critical error when running the sourceNodes.sourceNodes build step.

This is my current gatsby-config with enabled debug options:
{
      resolve: `gatsby-source-wordpress-experimental`,
      options: {
        url: `https://dev-mattressadvisor.pantheonsite.io/graphql`,
        debug: {
          graphql: {
            showQueryVarsOnErrors: true,
            writeQueriesToDisk: true,
          }
        },
        type: {
          Comment: {
            limit: process.env.NODE_ENV === `development` ? 50 : 5000,
          },
          Post: {
            limit: process.env.NODE_ENV === `development` ? 500 : 5000,
          }
        },
      },
    },

I also fried up a fresh project with gatsby new wordpress-gatsby https://github.com/TylerBarnes/using-gatsby-source-wordpress-experimental and replaced the default URL to mine like this:
{
resolve: gatsby-source-wordpress-experimental,
options: {
url:
process.env.WPGRAPHQL_URL ||
https://dev-mattressadvisor.pantheonsite.io/graphql,
verbose: true,
develop: {
hardCacheMediaFiles: true,
},
debug: {
graphql: {
writeQueriesToDisk: true,
},
},
type: {
Post: {
limit:
process.env.NODE_ENV === development
? // Lets just pull 50 posts in development to make it easy on ourselves.
50
: // and we don't actually need more than 5000 in production for this particular site
5000,
},
},
},
},
Encountered the same error, however it was switching between these:
Cannot read property 'posts' of undefined
Cannot read property 'comments' of undefined
Cannot read property 'pages' of undefined
Got this one everytime:
Encountered a critical error when running the sourceNodes.sourceNodes build step.

Hi @oliverfeher !
Thanks for your patience on this. I just had a look and it seems to be the same error we talked about a few weeks back. The page with an database id of 608 has a filter on the post content which is causing WPGraphQL to return an empty string.
You can make this query via Graphiql (directly to yoursite.com/graphql) to see this problem
{
  page(id: 608 idType: DATABASE_ID) {
    content
  }
}

If you query for content it causes the whole request to return an empty string instead of a GraphQL response. The same seems to happen for a post (not sure which post). It would likely be the same filter causing the problem in both places.
Upgrade to<EMAIL_ADDRESS>for a better error message.
I'm currently brainstorming on how these problematic nodes could be automatically identified but I don't have a concrete answer for that yet.

For now you can get your build running with this config:
{
    resolve: `gatsby-source-wordpress-experimental`,
    options: {
        url: `https://dev-mattressadvisor.pantheonsite.io/graphql`,
        debug: {
            graphql: {
                showQueryVarsOnErrors: true,
                writeQueriesToDisk: true,
            }
        },
        type: {
            Comment: {
                limit: process.env.NODE_ENV === `development` ? 50 : 5000,
            },
            Post: {
                limit: process.env.NODE_ENV === `development` ? 500 : 5000,
                excludeFieldNames: [`content`],
            },
            Page: {
                excludeFieldNames: [`content`],
            },
            NodeWithContentEditor: {
                exclude: true,
            },
        },
    },
},


MWPW-136766, MWPW-136143: Milo not supporting sending to CaaS all locales & Autodetect not working

This PR fixes issues with both the send to caas button and the bulk publisher as well as all the autodetect.
When using the send to caas button, the following locales were mapped incorrectly and would send the wrong data to CaaS.
ae_ar, ae_en, africa, cr, ec, eg_ar, el, gr_el, gt, id_en, id_id, il_he, in_hi, kw_ar, mena_ar, mena_en, my_ms, ph_en, qa_ar, sa_ar, sa_en, th_en, th_th, vn_vi

For example: this page, https://milo.adobe.com/qa_ar/drafts/sanrai/mwpw-136065, it'll return the wrong value, ar, which then sends the wrong lang/country combination to CaaS (ar_US instead of ar_QA)
This is because the API the code was previously using, document.documentElement.lang was incorrect.
Here is it failing for my_ms:

See this bug for more information:
https://jira.corp.adobe.com/browse/MWPW-136832
When trying sending content from the following set of locales
cr, ec, el, gt, pr, langstore, eg_ar, eg_en, gr_el, il_he, kw_ar, kw_en, ng, qa_ar, qa_en, za

to CaaS using the bulk publisher (or the Send to CaaS button),  because these locales were undefined, these locales would wrongly be sent into en_US to CaaS.
Here is an example of it failing for qa_ar:

See https://jira.corp.adobe.com/browse/MWPW-136766 for more information on the latter issue.
Resolves:
https://jira.corp.adobe.com/browse/MWPW-136766,
https://jira.corp.adobe.com/browse/MWPW-136832
Test URLs:

Before: https://MWPW-136143-2--milo--adobecom.hlx.page/drafts/sanrai/testing-bulk-publish?martech=off
After: https://MWPW-136143-2--milo--adobecom.hlx.page/drafts/sanrai/testing-bulk-publish?martech=off

When using autoDetect (where Milo dynamically tries to figure out the correct country/lang to send to CaaS) it turns out it fails for every locale for CaaS.
The idea for this was to prevent authors from having to manually author the country/lang for every collection.
But the way this currently works in production is either:

Authors are manually setting the lang/country at the collection level using tags (This is occurring for all Tier 1 locales and is actually how https://business.adobe.com/customer-success-stories.html is live right now)

For ones that aren't manually set, autoDetect sends a nonsense lang. Luckily CaaS's backend is able to a generate some search results for this BUT it gives us undefined behavior like a mix of English and translated content

The way this is fixed is I added a map in the caas block with all the milo regions as keys and their values being the actual correct locales that should be sent to CaaS.
This map:

Is in sync with the one milo uses AND also maps to every locale that is used when someone sends to CaaS
Is only loaded when a CaaS block is loaded on the page. I was originally going to put it in scripts.js but realized that would load unnecessary data for pages that aren't using CaaS.

Resolves: https://jira.corp.adobe.com/browse/MWPW-136143
Test URLs:

Before: https://main--bacom--adobecom.hlx.live/la/customer-success-stories
After: https://main--bacom--adobecom.hlx.live/la/customer-success-stories?milolibs=MWPW-136143-2

Heya Sanrai, you have 4 open PRs now https://github.com/adobecom/milo/pulls/sanrai
Ensure you get the support and attention you need, to merge them and close your older PRs

@sanrai @chrischrischris looks like you two are on top of this.


Gulp integration #2

Hey, I've nearly finished gulp integration (except testing part, I'll add it when I start writing test).
The following features were added:

Browser Sync
Linting
Sourcemaps

I've got an idea about source code organizing:

Create a src folder at the root level, put dragular.js and dragular.styl in it
Move everything documentation-related to the documentation folder
Add special gulp task that serves files from documentation with browser sync and processes assets.
Create another task that automatically pushes files from that folder to gh-pages
?????
PROFIT!
:joy:

I can make a PR if you are interested.

Of course I am interested ;) I am really glad you are making workflow better, it helps me faster deliver for bugfixes and features.
I was also wondering if code can be spited into multiple files, because it is quite robust. And also it is not very clearly written. So contributing for others must be pain. I dont have such time reserve to do it now, so maybe in future I will split it into browserify modules. Problem would be also find out good and clear structure.
Thank you for contributing ;)

Thanks!
Let's do it right. :+1:

I need to refactor examples site, so I was trying to change gulpfile, but I am not used to work with browserify. Could you please change gulpfile for me? Changes needed:

follow new structure (see structure bellow list)
remove stylus and nib (we dont need it for 5 simple rules, and examples are written in pure css anyway)
setup concatination and sourcemaps for examples files
put angular template cache and cache all examples views from examples subfolders

New structure:
src/
dragular/
dragularSource.js
dragularSource.css
examples/
examplesApp.js
examplesApp.css
exampleBasic/
exampleBasic.js
exampleBasic.css
exampleBasic.html
exampleXY/
exampleXY.js
exampleXY.css
exampleXY.html
...
other examples folders
...
dist/
dragular.js
dragular.min.js
dragular.css
dragular.min.css
examples/
examples.js
examples.css
index.html
I will divide code and put it to corresponding folders/files... if you have any improvements to my suggestions.. I am open to change/add it ;)

@luckylooke, :ok_hand:
I have a suggestion about doc files organizing. Maybe instead of putting docs files in both dist and src folders, create separate folder that intended to store only documentation.
For example:
src/
  dragular/
    dragularSourceService.js
    dragularSourceDirective.js
    dragularSource.css
dist/
  dragular.js
  dragular.min.js
  dragular.css
  dragular.min.css
docs/
  index.html
  src/
     vendor/
       ------
       theme files
       ------
     examples/
       examplesApp.js
       examplesApp.css
       exampleBasic/
          exampleBasic.js
          exampleBasic.css
          exampleBasic.html
       exampleXY/
          exampleXY.js
          exampleXY.css
          exampleXY.html
  dist/
     examples.js
     examples.css

Using this approach we can easily push everything from docs to gh-pages using gulp-gh-pages. That directory might contain its own gulpfile.js for documentation processing only. As a result, source and documentation are 2 independent modules. What do you think?

Great.. can be done your structure.. i like it. Just prepare gulp files. I
have splited examples already done. Thanks ;-)
On Jul 26, 2015 6:34 PM, "Philipp Alferov"<EMAIL_ADDRESS>wrote:

@luckylooke https://github.com/luckylooke, [image: :ok_hand:]
I have a suggestion about doc files organizing. Maybe instead of putting
docs files in both dist and src folders, create separate folder that
intended to store only documentation.
For example:
src/
dragular/
dragularSourceService.js
dragularSourceDirective.js
dragularSource.css
dist/
dragular.js
dragular.min.js
dragular.css
dragular.min.css
docs/
index.html
src/
vendor/
------
theme files
------
examples/
examplesApp.js
examplesApp.css
exampleBasic/
exampleBasic.js
exampleBasic.css
exampleBasic.html
exampleXY/
exampleXY.js
exampleXY.css
exampleXY.html
dist/
examples.js
examples.css
Using this approach we can easily push everything from docs to gh-pages
using gulp-gh-pages https://github.com/shinnn/gulp-gh-pages. That
directory might contain its own gulpfile.js for documentation processing
only. As a result, source and documentation are 2 independent modules. What
do you think?
—
Reply to this email directly or view it on GitHub
https://github.com/luckylooke/dragular/pull/15#issuecomment-125014559.

Cool!
Could you create a branch and push these splitted files to it when you are ready? I'll finish the process then.
I'm asking about this, because I'm not sure about the way of serving js files (it would be two process - one for the source and another one for documentation). With existing structure it would be much easier to figure it out. Thank you!

Ok.. but I am on vacation now so if the wheather will be good I wont have
time for it until wednesday. ;-)
On Jul 26, 2015 8:23 PM, "Philipp Alferov"<EMAIL_ADDRESS>wrote:

Cool!
Could you create a branch and push these splitted files to it when you are
ready? I'll finish the process then.
I'm asking about this, because I'm not sure about the way of serving js
files (it would be two process - one for the source and another one for
documentation). With existing structure it would be much easier to figure
it out. Thank you!
—
Reply to this email directly or view it on GitHub
https://github.com/luckylooke/dragular/pull/15#issuecomment-125025044.

Okay, It can wait, I'll start working on tests then.
Have a great vacation! :boat:

Here it is, loading examples are not finished yet but they are splitted into files and folders. Also dragular directive and service are splitted so you need to concat them too in build ;)

@luckylooke, thanks for letting me know. I've almost done with browserifying (branch). Only a few things left to do (refactoring mostly). I'll make a PR, once I finish it.

Ok, I am looking forward ;-)
On Jul 29, 2015 5:39 PM, "Philipp Alferov"<EMAIL_ADDRESS>wrote:

@luckylooke https://github.com/luckylooke, thanks for letting me know.
I've almost done with browserifying (branch
https://github.com/alferov/dragular/tree/patch-1). Only a few things
left to do (refactoring mostly). I'll make a PR, once I finish it.
—
Reply to this email directly or view it on GitHub
https://github.com/luckylooke/dragular/pull/15#issuecomment-125992838.


Update to Shapeless 2.2.1

I don't think any of the bug fixes and performance improvements in 2.2.1 affect us, but we might as well update before the 0.7.0 release.

Current coverage is 90.41%

Merging #305 into master will change coverage by 0% by d44cfb4

Powered by Codecov

Great! Thank you @travisbrown!


Request: ability to select the default view for repo

Actually repo always display “Overview” tab. An option in settings to display “Issues”,”Pull request” or code by default could be great.
I mainly use GitHawk to manage my tasks/issues on my company project and so the Overview is useless for me.
Not a big feature but just to be pro active!

and if it can stay on last page loaded on each repos, that can be great too 👌
Sent with GitHawk

I'd love to implement this!
Saving the previous position in each repo might be best as a separate PR for #organization, but the implementation shouuuld be similar though -- thoughts?


Instructions for installing React not showing on Windows

The directions are identical on all three platforms so merging them. They weren't showing up on for Windows or Linux, just OSX.

Thanks for the pull request. Can you provide a screenshot of the before and after given the intricacies of these instructions?

I don't have the full project building, so no after picture, but here is what it looks like with Windows+Android Selected:

And here is IOS + MacOS

@lacker @hramos This seems good to me, but wanted to let you land.

I think there's a problem in this logic - won't this make some instructions show up for windows + ios and linux + ios, when really we want those to just have the "sorry it doesn't work" state?

Good point, I guess my fix was bad. Sorry.
Since I don't have the project setup to dig deeper I'll close this. This was also reported as issue #11414


remove version

We need to remove this version thingie
Without tooling/automation releasing otherwise is always by design error prone

Should we remove the
Test\Phinx\Console\Command\ListTest::testVersionInfo
part? Or read the current version somehow differently?

It could read and find itself in vendor/composer/installed.json.
But overall version doesn't add much value. I'd vote to remove any version related code.
composer info robmorgan/phinx is enough to find version for troubleshooting problems.

@garas Tests are green now, good to go?


First time login, can get kinda far before we are told we're actually not

related #220

closed with #415


Don't error if site doesn't have Gutenberg

Added a check for if Gutenberg exists and is enabled, to ensure compatibility with ClassicPress and the Classic Editor. Throws a 500 error currently on any site running the ClassicPress WP fork, or is for any other reason missing Gutenberg.

Yes, this is needed in order to match the readme "Requires at least", which is 4.0.

Suggestion: rather than re-indenting the entire function and conditionally defining it, just insert this at the beginning of the function:
if ( ! function_exists( 'register_block_type' ) ) {
    return;
}

Thanks!


allow tooltips to work via clicks.

This PR adds a configuration option tooltipAction to allow tooltips to optionally work via clicks, which is better for mobile. The default value, hover results in the existing behavior using mouseover and mouseout but if tooltipAction is instead set to click then click handlers are used to show and hide tooltips.
Allowing tooltips to work via clicks is important for supporting mobile devices which don't have mouseover and mouseout events.
In click mode it works as follows:

Clicking on a cell when no tooltip is showing will show that cell's tooltip.
Clicking on a cell when a different cell's tooltip is showing will switch to tooltip to the newly clicked cell.
Clicking a cell for which a tooltip is already showing will hide that cell's tooltip.
Clicking anywhere else (i.e., not on the calendar plot), will hide a tooltip if one is showing.

Let me know if you have qualms with the implementation or suggestions. This is my first contrib to this project, so I'm not that familiar with the code base yet.

Coverage decreased (-1.71%) to 76.42% when pulling 5579de5539f2c394453de6aa600fdc044df7f9a6 on kbullaughey:abstract-tooltip-events into 5b929fc85479592b96b9fca5bd700d058859af08 on kamisama:master.

Thanks for the PR.
Can you submit the PR without grunt build, so that only changes to src/cal-heatmap.js appears ? We use grunt build only when releasing a new version

I think you committed the last changes on the wrong branch, as they're not applied to this PR

I'm closing this one, as it's not relevant anymore nowadays.
Changes are interesting, but we're now in 2022, and you can tap on a cell to trigger the hover event on most mobile browsers.
The only feature not supported by default is #3 (Clicking a cell for which a tooltip is already showing will hide that cell's tooltip), but we can live without.


Help

Hello
How to create service provider in local for testing ?
please help for the same
thank you

Hi @Asifkrishaweb,
as I wrote in another issue, this space is not intended for support requests.
Please refer to the SPID community at https://developersitalia.slack.com/messages/C73R3UQE8.


qwen14b+vllm raise ValueError("unknown ids") ValueError: unknown ids

When using the vllm v0.2.4 with a large model for question answering, an error is encountered during execution. The error message indicates an issue related to unknown IDs in the tokenizer.
Steps to Reproduce:
Use vllm v0.2.4 with a qwen-14b-chat model for question answering.
Execute the model for question answering.
Expected Behavior:
The model should successfully process the question and provide an answer.
Actual Behavior:
The following error is encountered during execution:
2024-02-19 00:30:41 | ERROR | asyncio | Exception in callback functools.partial(<function _raise_exception_on_finish at 0x7f9ab24963e0>, request_tracker=<vllm.engine.async_llm_engine.RequestTracker object at 0x7f9a9b10de10
>)
handle: <Handle functools.partial(<function _raise_exception_on_finish at 0x7f9ab24963e0>, request_tracker=<vllm.engine.async_llm_engine.RequestTracker object at 0x7f9a9b10de10>)>
Traceback (most recent call last):
File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/vllm/engine/async_llm_engine.py", line 28, in _raise_exception_on_finish
task.result()
File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/vllm/engine/async_llm_engine.py", line 359, in run_engine_loop
has_requests_in_progress = await self.engine_step()
^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/vllm/engine/async_llm_engine.py", line 338, in engine_step
request_outputs = await self.engine.step_async()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/vllm/engine/async_llm_engine.py", line 199, in step_async
return self._process_model_outputs(output, scheduler_outputs) + ignored
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/vllm/engine/llm_engine.py", line 545, in _process_model_outputs
self._process_sequence_group_outputs(seq_group, outputs)
File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/vllm/engine/llm_engine.py", line 416, in _process_sequence_group_outputs
self._decode_sequence(seq, seq_group.sampling_params)
File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/vllm/engine/llm_engine.py", line 663, in _decode_sequence
read_offset) = detokenize_incrementally(
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/vllm/transformers_utils/tokenizer.py", line 148, in detokenize_incrementally
new_tokens = tokenizer.convert_ids_to_tokens(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/transformers/tokenization_utils.py", line 982, in convert_ids_to_tokens
tokens.append(self._convert_id_to_token(index))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/.cache/huggingface/modules/transformers_modules/Qwen-14B-Chat-self/tokenization_qwen.py", line 246, in _convert_id_to_token
raise ValueError("unknown ids")
ValueError: unknown ids
  The above exception was the direct cause of the following exception:

  Traceback (most recent call last):
    File "uvloop/cbhandles.pyx", line 63, in uvloop.loop.Handle._run
    File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/vllm/engine/async_llm_engine.py", line 37, in _raise_exception_on_finish
      raise exc
    File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/vllm/engine/async_llm_engine.py", line 32, in _raise_exception_on_finish
      raise AsyncEngineDeadError(
  vllm.engine.async_llm_engine.AsyncEngineDeadError: Task finished unexpectedly. This should never happen! Please open an issue on Github. See stack trace above for the actual cause.
  INFO 02-19 00:30:41 async_llm_engine.py:134] Aborted request 86e1f10533704c518766532db0f4c8cb.
  2024-02-19 00:30:41 | ERROR | stderr | ERROR:    Exception in ASGI application
  2024-02-19 00:30:41 | ERROR | stderr | Traceback (most recent call last):
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/vllm/engine/async_llm_engine.py", line 28, in _raise_exception_on_finish
  2024-02-19 00:30:41 | ERROR | stderr |     task.result()
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/vllm/engine/async_llm_engine.py", line 359, in run_engine_loop
  2024-02-19 00:30:41 | ERROR | stderr |     has_requests_in_progress = await self.engine_step()
  2024-02-19 00:30:41 | ERROR | stderr |                                ^^^^^^^^^^^^^^^^^^^^^^^^
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/vllm/engine/async_llm_engine.py", line 338, in engine_step
  2024-02-19 00:30:41 | ERROR | stderr |     request_outputs = await self.engine.step_async()
  2024-02-19 00:30:41 | ERROR | stderr |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/vllm/engine/async_llm_engine.py", line 199, in step_async
  2024-02-19 00:30:41 | ERROR | stderr |     return self._process_model_outputs(output, scheduler_outputs) + ignored
  2024-02-19 00:30:41 | ERROR | stderr |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/vllm/engine/llm_engine.py", line 545, in _process_model_outputs
  2024-02-19 00:30:41 | ERROR | stderr |     self._process_sequence_group_outputs(seq_group, outputs)
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/vllm/engine/llm_engine.py", line 416, in _process_sequence_group_outputs
  2024-02-19 00:30:41 | ERROR | stderr |     self._decode_sequence(seq, seq_group.sampling_params)
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/vllm/engine/llm_engine.py", line 663, in _decode_sequence
  2024-02-19 00:30:41 | ERROR | stderr |     read_offset) = detokenize_incrementally(
  2024-02-19 00:30:41 | ERROR | stderr |                    ^^^^^^^^^^^^^^^^^^^^^^^^^
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/vllm/transformers_utils/tokenizer.py", line 148, in detokenize_incrementally
  2024-02-19 00:30:41 | ERROR | stderr |     new_tokens = tokenizer.convert_ids_to_tokens(
  2024-02-19 00:30:41 | ERROR | stderr |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/transformers/tokenization_utils.py", line 982, in convert_ids_to_tokens
  2024-02-19 00:30:41 | ERROR | stderr |     tokens.append(self._convert_id_to_token(index))
  2024-02-19 00:30:41 | ERROR | stderr |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/.cache/huggingface/modules/transformers_modules/Qwen-14B-Chat-self/tokenization_qwen.py", line 246, in _convert_id_to_token
  2024-02-19 00:30:41 | ERROR | stderr |     raise ValueError("unknown ids")
  2024-02-19 00:30:41 | ERROR | stderr | ValueError: unknown ids
  2024-02-19 00:30:41 | ERROR | stderr |
  2024-02-19 00:30:41 | ERROR | stderr | The above exception was the direct cause of the following exception:
  2024-02-19 00:30:41 | ERROR | stderr |
  2024-02-19 00:30:41 | ERROR | stderr | Traceback (most recent call last):
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/uvicorn/protocols/http/httptools_impl.py", line 426, in run_asgi
  2024-02-19 00:30:41 | ERROR | stderr |     result = await app(  # type: ignore[func-returns-value]
  2024-02-19 00:30:41 | ERROR | stderr |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/uvicorn/middleware/proxy_headers.py", line 84, in __call__
  2024-02-19 00:30:41 | ERROR | stderr |     return await self.app(scope, receive, send)
  2024-02-19 00:30:41 | ERROR | stderr |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/fastapi/applications.py", line 1106, in __call__
  2024-02-19 00:30:41 | ERROR | stderr |     await super().__call__(scope, receive, send)
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/starlette/applications.py", line 122, in __call__
  2024-02-19 00:30:41 | ERROR | stderr |     await self.middleware_stack(scope, receive, send)
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/starlette/middleware/errors.py", line 184, in __call__
  2024-02-19 00:30:41 | ERROR | stderr |     raise exc
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/starlette/middleware/errors.py", line 162, in __call__
  2024-02-19 00:30:41 | ERROR | stderr |     await self.app(scope, receive, _send)
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/starlette/middleware/exceptions.py", line 79, in __call__
  2024-02-19 00:30:41 | ERROR | stderr |     raise exc
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/starlette/middleware/exceptions.py", line 68, in __call__
  2024-02-19 00:30:41 | ERROR | stderr |     await self.app(scope, receive, sender)
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/fastapi/middleware/asyncexitstack.py", line 20, in __call__
  2024-02-19 00:30:41 | ERROR | stderr |     raise e
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/fastapi/middleware/asyncexitstack.py", line 17, in __call__
  2024-02-19 00:30:41 | ERROR | stderr |     await self.app(scope, receive, send)
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/starlette/routing.py", line 718, in __call__
  2024-02-19 00:30:41 | ERROR | stderr |     await route.handle(scope, receive, send)
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/starlette/routing.py", line 276, in handle
  2024-02-19 00:30:41 | ERROR | stderr |     await self.app(scope, receive, send)
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/starlette/routing.py", line 69, in app
  2024-02-19 00:30:41 | ERROR | stderr |     await response(scope, receive, send)
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/starlette/responses.py", line 270, in __call__
  2024-02-19 00:30:41 | ERROR | stderr |     async with anyio.create_task_group() as task_group:
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/anyio/_backends/_asyncio.py", line 597, in __aexit__
  2024-02-19 00:30:41 | ERROR | stderr |     raise exceptions[0]
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/starlette/responses.py", line 273, in wrap
  2024-02-19 00:30:41 | ERROR | stderr |     await func()
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/starlette/responses.py", line 262, in stream_response
  2024-02-19 00:30:41 | ERROR | stderr |     async for chunk in self.body_iterator:
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/autodl-tmp/FastChat/fastchat/serve/vllm_worker.py", line 113, in generate_stream
  2024-02-19 00:30:41 | ERROR | stderr |     async for request_output in results_generator:
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/vllm/engine/async_llm_engine.py", line 444, in generate
  2024-02-19 00:30:41 | ERROR | stderr |     raise e
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/vllm/engine/async_llm_engine.py", line 438, in generate
  2024-02-19 00:30:41 | ERROR | stderr |     async for request_output in stream:
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/vllm/engine/async_llm_engine.py", line 70, in __anext__
  2024-02-19 00:30:41 | ERROR | stderr |     raise result
  2024-02-19 00:30:41 | ERROR | stderr |   File "uvloop/cbhandles.pyx", line 63, in uvloop.loop.Handle._run
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/vllm/engine/async_llm_engine.py", line 37, in _raise_exception_on_finish
  2024-02-19 00:30:41 | ERROR | stderr |     raise exc
  2024-02-19 00:30:41 | ERROR | stderr |   File "/root/miniconda3/envs/vllm/lib/python3.11/site-packages/vllm/engine/async_llm_engine.py", line 32, in _raise_exception_on_finish
  2024-02-19 00:30:41 | ERROR | stderr |     raise AsyncEngineDeadError(
  2024-02-19 00:30:41 | ERROR | stderr | vllm.engine.async_llm_engine.AsyncEngineDeadError: Task finished unexpectedly. This should never happen! Please open an issue on Github. See stack trace above for the actual cause.

  Can anyone help solve this issue? Thank you for your assistance!

Hello, I have the same error. How did you fix that error ?


Unload should support unloading partitioned topic

Expected behavior
admin.topics().unload();
it should unload all the partitions.
Actual behavior
it returns 500
Steps to reproduce

Closed this issue since lack of information.


error retrieving static assets if basePath is set

Are you reporting a bug?
Yes

Environment

react-static -V: 6.0.18
node -v: v10.13.0
npm -v: 6.4.1
Operating system: macOS
Browser and version (if relevant): chrome

Steps to Reproduce the problem
Base your steps off of any freshly installed react-static template!

Created a new site using react-static create basic template
modify static.config.js to include basePath and siteRoot
deploy to gh-pages

Expected Behavior
Routing should work properly, but get 404 errors in browser console which xhr to retrieve routeInfo.json file.
GET https://phaneendra.github.io/urbanrunners/https://phaneendra.github.io/urbanrunners/blog/routeInfo.json 404
seems the function getRoutePath to strip the path of window.location.origin is not called.

Reproducible Demo
https://github.com/phaneendra/urbanrunners
http://phaneendra.github.io/urbanrunners/

Seems like your routeInfo.json can be accessed at http://phaneendra.github.io/urbanrunners/blog/routeInfo.json
nothing gets thrown in browser console as well

However, seems like not all static assets are being resolved with basePath:
Navigating to http://phaneendra.github.io/urbanrunners/ and clicking on About results in a few files not being able to be loaded.

Bump. This issue effectively rules out hosting on github/gitlab pages under a basepath, which may hinder adoption when users write docs for projects and host the docs directly on github/gitlab.

Please take a look at v7 and confirm that this is still an issue? If it is, reopen this issue and likewise we will be in a better position to fix it with the new v7 architecture. If it's not, then huzzah!

@tannerlinsley the problem is existing yet on 7.0.0

I confirm. Still there.


urcrypt autogen.sh - configure.ac:116: error: required file 'liburcrypt.pc.in' not found

On an M1 MacBook Pro running Monterey (12.4) I get the following error:
$ ./urcrypt/autogen.sh
glibtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
glibtoolize: copying file 'build-aux/ltmain.sh'
glibtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'build-aux/m4'.
glibtoolize: copying file 'build-aux/m4/libtool.m4'
glibtoolize: copying file 'build-aux/m4/ltoptions.m4'
glibtoolize: copying file 'build-aux/m4/ltsugar.m4'
glibtoolize: copying file 'build-aux/m4/ltversion.m4'
glibtoolize: copying file 'build-aux/m4/lt~obsolete.m4'
configure.ac:47: installing 'build-aux/compile'
configure.ac:44: installing 'build-aux/missing'
configure.ac:116: error: required file 'liburcrypt.pc.in' not found
Makefile.am: installing 'build-aux/depcomp'
Makefile.am:23: error: 'pkgconfig_DATA' is used but 'pkgconfigdir' is undefined
autoreconf: error: automake failed with exit status: 1

Any ideas?

I'm running the same os/version, let me attempt a clean rebuild and see what the error is.

Awesome, thanks.

Did you cd urcrypt?

Yup.
$ pwd
../dev/go-urbit/urcrypt

Couple things to get past this error:
brew install pkg-config

And these changes:
diff --git a/urcrypt/Makefile.am b/urcrypt/Makefile.am
index 27f4c55..bcccd7e 100644
--- a/urcrypt/Makefile.am
+++ b/urcrypt/Makefile.am
@@ -20,7 +20,7 @@ noinst_HEADERS = urcrypt/util.h \
                 scrypt/libscrypt.h

 # main library
-pkgconfig_DATA = liburcrypt-$(URCRYPT_API_VERSION).pc
+pkgconfig_DATA = liburcrypt.pc
 DISTCLEANFILES = $(pkgconfig_DATA)

 liburcrypt_la_CPPFLAGS = -I$(srcdir)/ed25519/src \
diff --git a/urcrypt/configure.ac b/urcrypt/configure.ac
index bfafbc0..f0503e2 100644
--- a/urcrypt/configure.ac
+++ b/urcrypt/configure.ac
@@ -113,5 +113,5 @@ AM_CONDITIONAL([ARCH_X86_64],  [test "$ARCH" = 'x86_64'])
 AM_CONDITIONAL([ARCH_GENERIC], [test "$ARCH" = 'generic'])

 # Finish and output
-AC_CONFIG_FILES([Makefile liburcrypt-$URCRYPT_API_VERSION.pc:liburcrypt.pc.in])
+AC_CONFIG_FILES([Makefile])
 AC_OUTPUT

Now erroring out on make:
libtool: link: ranlib .libs/liburcrypt.a
libtool: link: rm -fr .libs/liburcrypt.lax
libtool: link: ( cd ".libs" && rm -f "liburcrypt.la" && ln -s "../liburcrypt.la" "liburcrypt.la" )
make[1]: *** No rule to make target `liburcrypt.pc', needed by `all-am'.  Stop.
make: *** [all] Error 2

Thanks for debugging that error (I'm currently stuck fixing cmake compiling libaes_siv after updating xcode...)

np. I see. I'm running Xcode 13.2.1 BTW.

@e1block Try this commit I pushed to master: https://github.com/stevelacy/go-urbit/commit/d791e3694b30ca146db30d1ff2737099bb19e682
Some of the LD flags are for the latest version of secp256k1 and may not be required.

Cool, thanks. Made it work with nearly the same workaround. Believe the trick was a placeholder liburcrypt.pc & liburcrypt.pc.in` files.


ci: Add major release tags and risky automation change warning

This PR adds 2 GitHub Workflows.
Workflow 1: major-release-tags
The primary goal of this PR.
When a release is published, the major version will get a dedicated tag (e.g., v0, v1, v2). This allows content that's compatible with a particular major version to follow compatible updates of the codebase without needing to reference more specific release numbers.
If the workflow fails, the tag can be manually created the usual ways.
Workflow 2: review-warning
Because the major-release-tags workflow requires write permission to the repository, it has a riskier impact if a malicious PR is sent. The review-warning workflow notes PRs that modify the major-release-tags workflow and adds a warning via comment to the PR. We could also have a label, but there's no standard label for "pay extra attention here!"

The lint failure is related to documentation generation needing to be re-run, but that is unrelated to the change in this PR.

Some lint errors cleaned up, but some more popped up. Will address in a separate PR, to try and debug.

Nope, this lint error is valid:
Error: No newline at end of file ./.github/workflows/release-major-tags.yml


Playershops visual bug!

Upon working if my chest shop was working, I had put my Arc chalice on sale for 1 million. I tried purchasing to see if the sign works and It's given me 1 million, I relogged the money went back to normal, I tried it again and the money went down 1 million, I relogged again and it was back to normal.
Before:

After:

That is what happened when I tried purchasing from myself, It fixes when you relog.
Thanks you!

This visual bug no longer seems to occur assuming fixed, Closing.


Add setup.py and entrypoint skeleton.

Should be enough for us to start.
However, rather than just diving in, let's flesh out a design doc and open some issues so that we can partition and assign the work.

+1 Elephant :)


Searching in SFTP

Hi,
I'm trying to search through all my files in my remote directory but I came across this when trying to search
 No search provider registered for scheme: sftp
Any tips?
Thanks,
Eugenio

Duplicate of #2


Gitbook for static documentation website (#311)

Give a try to gitbook, as @xgrommx proposed. Looks nice and simple.
npm run docs:build generates a static website in _book. But I think we need task for deploy to gh-pages.

We'll use this, thank you.

:+1:


[DEVICE-TESTED] Conga 2290

Device model
Please set which Conga device have you tested
Problem with credentials when configuring the integration:

Hello @Lumanet ! Thanks for reporting this!
Seems Cecotec has different "endpoints" depending on the model. I'll try to get those endpoints and I'll ping you later🤞 🤞
Regards,

Any solution?

Unfortunately, I tested the app and I tried to integrate it with this integration, but I didn't manage to do it.
Seems only Cecotec Conga 5290 works with AWS services 😞
Sorry for this late response, I wanted to find a solution before answering. You can try Freeconga or Badconga.
I'm opening the PR #21  to update the README and make it clear now.


Switch off gardener-apiserver's vertical scale down by hvpa

How to categorize this PR?

/area control-plane
/area auto-scaling
/priority normal
What this PR does / why we need it:
Switch off gardener-apiserver's vertical scale down by hvpa
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Release note:

Switch off gardener-apiserver's vertical scale down by hvpa

Does this mean that the Gardener API server is never automatically scaled down?
I suppose the current scale down behaviour is causing issues.
Can you maybe explain a little bit why this is done and also write it in the release notes?

Can you maybe explain a little bit why this is done and also write it in the release notes?

Yes. The VPA recommender is not coping well with spikes in load and scaling down potentially makes this worse. Not scaling down can potentially give the pods a bit more room during spikes in load (if spikes are smaller than past spikes).
@ggaurav10 Could you please update the release note with a bit more explanation/rationale.

/close in favour of https://github.com/gardener/gardener/pull/2843


[AnVIL DX] Validate login in dev and prod

Tasks

[x] Validate in dev
[x] Validate in prod

Completed.


PERF: Add benchmarking?

Because xarray is all python and generally not doing much compute itself (i.e. it marshals other libraries to do that), this hasn't been that important.
IIRC most of the performance issues have arisen where xarray builds on (arguably) shaky foundations, like PeriodIndex.
Though as we mature, is it worth adding some benchmarks?
If so, what's a good way to do this? Pandas uses asv successfully. I don't have experience with https://github.com/ionelmc/pytest-benchmark but that could be a lower cost way of getting started. Any others?

Yes, some sort of automated benchmarking could be valuable, especially for noticing and fixing regressions. I've done occasional benchmarks before to optimize bottlenecks (e.g., class constructors) but it's all been ad-hoc stuff with %timeit in IPython.
ASV seems like a pretty sane way to do this. pytest-benchmark can trigger test failures if performance goes below some set level but I suspect performance is too subjective and stochastic to be reliable.

Yes ASV is good. I'm surprised there isn't something you can ask to just "robustly time these tests", so it can bolt on without writing new code.
Although maybe the overlap between test code and benchmark code isn't as great as I imagine

One issue is that unit tests are often not good benchmarks. Ideal unit tests are as fast as possible, whereas ideal benchmarks should be run on more typical inputs, which may be much slower.

Another 👍  for benchmarking. Especially as we start to get deep into integrating dask.distributed, having robust performance benchmarks will be very useful. One challenge is where to deploy the benchmarks. TravisCI might not be ideal, since performance can vary depending on competition from other virtual machines on the same system.

We would also benefit from this specifically for #1198 :+1:

Is anyone interested in working on this with me over the next few months? Given the number of issues we've been seeing, I'd like to see this come together this summer. I think ASV is the natural starting point.

I am very interested. I have been doing a lot of benchmarking already wrt dask.distributed on my local cluster, focusing on performance with multi-terabyte datasets. At this scale, certain operations emerge as performance bottlenecks (e.g. index alignment of multi-file netcdf datasets, #1385).
I think this should probably be done in AWS or Google Cloud. That way we can establish a consistent test environment for benchmarking. I might be able to pay for that (especially if our proposal gets funded)!

@rabernat - great. I've setup a ASV project and am in the process of teaching myself how that all works. I'm just playing with some simple arithmatic benchmarks for now but, of course, most of our interested will be in the i/o and dask arenas.
I'm wondering if @mrocklin has seen ASV used with any dask projects. We'll just need to make sure we choose the appropriate timer when profiling dask functions.

@TomAugspurger has done some ASV work with Dask itself


Invalid topic on Producer

I'm trying to send a batch of messages with the following code:
    await this.client.send(
      {
        topic: 'topic-name',
        messages: [
          { key: '1', value: 'string1' },
          { key: '2', value: 'string2' },
        ],
      });

It seems that the serializer is trying to serialize the whole object including the topic, which results in kafkajs being called with
[ { topic: undefined, messages: undefined } ]

@tr11 was this with the avro serializer?

@rob3000, no just the regular one. Using it with<EMAIL_ADDRESS>and<EMAIL_ADDRESS>btw.

The problem is at this line https://github.com/rob3000/nestjs-kafka/blob/master/src/serializer/kafka-request.serializer.ts#L21. When call client.send the argument KafkaMessageSend is expected but in serializer it checks if field value and key appear in argument and wrap the argument.


nixos-option broken on NixOS 18.03

Issue description
I just upgraded from NixOS 17.09 to 18.03 and found this:
$ nixos-option environment.systemPackages
/run/current-system/sw/bin/nixos-option: line 154: $'1mwarning:\E[0m': command not found

(I know 18.03 isn't released yet, but it's only a few days away.)
Technical details
 - system: `"x86_64-linux"`
 - host os: `Linux 4.14.29, NixOS, 18.03pre131537.f61244da2e4 (Impala)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.0`
 - channels(root): `"nixos-18.03pre131537.f61244da2e4"`
 - channels(bfo): `""`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs`

I still have problems with this, however the tool runs now. Instaed, no color is displayed at all, and newlines in the description are displayed as \n:
$ nixos-option networking.firewall.enable
Value:
false

Default:
true

Description:

"Whether to enable the firewall. This is a simple stateful\nfirewall that blocks connection attempts to unauthorised TCP\nor UDP ports on this machine. It does not affect packet\nforwarding.\n"

Declared by:
  "/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/nixos/modules/services/networking/firewall.nix"

Info:
system: "x86_64-linux", multi-user?: yes, version: nix-env (Nix) 2.0, channels(janne): "", channels(root): "nixos-18.03", nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs

I cannot reproduce anymore. I'm now at
$ nixos-version
18.03.132192.ce0d9d638de (Impala)


Document pipeline invariant

Update pass_runner to also execute assertions in between phases. Later on, we will make assertions more precise about what subset of Usuba_AST go through the pipeline. In the meantime, we will assert 'true'.

Start by:

Displaying passes when they're used
Getting the most used micro-pass
Dumping s-expression before and after running this pass


Retain agent

Need to keep mechanize agent around to properly fake a real browser (otherwise it loses history and cookies and stuff and we get captcha'd)
Hard to test, and an implication is that all code keeps this resident because it's a module-level variable, so for the lifetime of the app in memory it'll retain the same "browser". I think that's ok but worth thinking through.

I think it's worth it; though we should consider reorganizing this to be instance-oriented.


Expo EAS build fails - lefthook

SDK version: 2.4.0
Environment: both
Are logs available?

[stderr]
npm ERR! code 1
[stderr]
npm ERR! path /Users/expo/workingdir/build/node_modules/customerio-reactnative
[stderr]
npm ERR! command failed
[stderr]
npm ERR! command sh -c -- node src/postInstall.js && npx lefthook install
[stderr]
npm ERR! Error: exit status 128
[stderr]
npm ERR! npm WARN exec The following package was not found and will be installed<EMAIL_ADDRESS>
Describe the bug
This package is not possible to use with the latest version as the post install script is using a package which is not install (lefthook). When installing locally it creates some file in the project root.

This is related to this PR https://github.com/customerio/customerio-reactnative/pull/73 @levibostian. I believe it was maybe a mistake to keep lefthook in the post install command. Since for people who use yarn workspaces/eas, it will throw an error on trying to install.
Example im using yarn workspaces and i get this error on install:
TypeError: workspaces config expects an Array

Since npm workspaces work different to yarn.
Here is a patch package file for a temp fix (will open a pr also):
diff --git a/node_modules/customerio-reactnative/package.json b/node_modules/customerio-reactnative/package.json
index d22953d..d77a5d1 100644
--- a/node_modules/customerio-reactnative/package.json
+++ b/node_modules/customerio-reactnative/package.json
@@ -31,7 +31,7 @@
     "example": "yarn --cwd example",
     "pods": "cd example && pod-install --quiet",
     "bootstrap": "yarn example && yarn && yarn pods",
-    "postinstall": "node src/postInstall.js && npx lefthook install",
+    "postinstall": "node src/postInstall.js",
     "format": "npx prettier --write \"src/**/*.tsx\" && (npm run lint || true)"
   },
   "keywords": [

@zdnk thank you for reaching out and bringing this to our attention.
@claudesortwell thank you for your swift response on the temp fix for this issue, as well as PR for this. It is really appreciated.
I have created a PR #144  for the fix, which should fix this issue as well as let others run the linting on the package.
Can you please confirm if it fixes the issue for you, so i can merge and release it? Thank you for all your support.

I can confirm it does work for me.
Also @Shahroz16 (i should raise an issue in https://github.com/customerio/customerio-io but it relates to the rn and your docs on your website). But your Cocoapods for some of your ios packages failed to deploy https://github.com/customerio/customerio-ios/actions/runs/5093854903/jobs/9156970027 (APN, InApp and Common) for version 20.6.1. I got stuck trying to upgrade to 20.6.1 for a while and it was never in the cocoapods source then realised this might be my issue and just used 20.6.0.

@claudesortwell thank you for confirming. You are correct, the deployment did seem to fail. I am checking it out.

The fix is out 2.4.1. Apologies for the inconvenience folks and thank you for reporting.
@claudesortwell, I have noted dow the cocoa pods issue and we are going to release it today.
Closing this ticket, but feel free to re-open incase you stumble upon something similar.

@claudesortwell CocoaPods 2.6.1 has been deployed. Thanks for pointing this out to the team.

@levibostian @Shahroz16 Thank you both for your quick action


Implement feature events

Part of https://github.com/CartoDB/renderer-prototype/issues/61

featureClick
[x] featureClickOut
[x] featureEnter
[x] featureHover
[x] featureLeave

Closed by https://github.com/CartoDB/renderer-prototype/pull/225


Fixed #26107 -- Allows for negative integers in CommaSeparatedIngerField

ticket for reference: https://code.djangoproject.com/ticket/26107#ticket

Closing in favor of a backwards compatible solution. Retitled ticket to "Add an option to int_list_validator to allow negative integers".


Experiencing system crashes with upd sendto

Version nuttx8.2. mtu is set to 1500.When I transfer data using udp protocol, using function sendto() with parameter len set to 4096, the system crashes. I want to know why? Does 8.2 support ip segmentation and how do I configure the system?

@Shark7Pepper did you try to reproduce the issue in a recent NuttX version? If the issue still happening in the mainline we will fix it.

it's possible now If the new ip fragment is enabled.:)

@Shark7Pepper can you please describe the "crash" that you are facing?
This has been discussed here, and it was fixed in #9423. Is this the same issue that you are facing?
Which arch are you using? At least in the STM32 driver there seems to be an issue that can also cause a crash with large datagrams.


Consolidate APCDataSubstrate categories

To address #30.
This makes it clear that the data substrate actually depends on CoreData and HealthKit, it's not just extensions/categories that make use of it.

r=me


Any benchmark results?

What GPUs are you using? What's the maximum batch_size for 11/12/16/32 GB GPUs (e.g.: GTX 1080 Ti, Titan X, V100) and the corresponding performance? Thanks.

What GPUs are you using?
With batch_size of 24 and Tensorflow 1.13.1, I successfully train a classifier based on bert-large-uncased on 2 x Tesla P40(about 95% RAM of GPUs used) for QQP dataset. And the prediction looks fine.

What's the maximum batch_size for 11/12/16/32 GB GPUs (e.g.: GTX 1080 Ti, Titan X, V100)?
tf.distribute.MirroredStrategy is used to achieve Multi-GPU for this project, which mirrors vars to distribute across multiple devices and machines. I think the maximum batch_size for each GPU is almost the same as bert. So global batch_size depends on how many GPUs there are.

Corresponding performance
The training speed and the number of GPUs are almost linear with the same hyperparameters.

Thanks. Does 24 indicates global batch size? i.e.: 12 samples of length 128 on each Tesla P40 card (24 GB memory)?

24 is the batch size for each GPU. Global batch size is 24 * 2 = 48.

Oops, this is awesome. Your batch size is twice as large as that reported in BERT readme (after scaling according to memory size). How did this happen? By using fp16 precision?

No fp16, but I'm planning to support it.
total RAM usage = model RAM usage + batch_size × memory RAM per sample. So batch_size and RAM usage are not linear, BERT is too large. On the other hand, maybe there are some performance optimizations from Tensorflow1.11 to 1.13.1.

Thanks for the clarification. A nice project and I'm playing with it.

Feel free to open a new issue if you encounter any problems while you are playing.

Now fp16 is available on branch fp16, feel free to use it. I will update readme and merge it to master later.
@soloice

Thanks for your quick development. Currently I don't have access to a Volta architecture GPU, so I guess the fp16 performance would be much slower than its fp32 counterpart? e.g.: for GTX 1080 Ti and Tesla P40, the fp16 performance is 1:64 (1/64 of fp32 FLOPS).

I'm facing some strange issues with BERT-Large on my 11 GB TX 1080 Ti.

Code
model size
maximum_sequence_length
max_batch_size_per_GPU
remark

original bert
base
128
36
Pretty good. Even larger than 32 on a 12 GB Titan X as mentioned in the BERT repo

original bert
large
64
2
Very poor. Titan X could hold 12 such samples!

this repo
large
64
0
Oops. This is a disaster.

I guess the poor performance is not due to this repo but the original BERT repo. Have you encountered any strange issue with BERT-Large like this?

Thanks for your quick development. Currently I don't have access to a Volta architecture GPU, so I guess the fp16 performance would be much slower than its fp32 counterpart? e.g.: for GTX 1080 Ti and Tesla P40 (both of them are of Pascal architecture), the fp16 performance is 1:64 (1/64 of fp32 FLOPS).

I only did a simple test for FP16, and the training speed did not drop significantly (probably I made a mistake). I will do more detailed and comprehensive testing later.

I guess the poor performance is not due to this repo but the original BERT repo. Have you encountered any strange issue with BERT-Large like this?
It's weird. Did OOM occur when training the LARGE model with this repo?

It is weird. Did OOM occur when training LARGE model with this repo? I don't recommend trying bert-large-uncased on GPUs(RAM < 16GB), because Multi-GPU has very little benefit for training in this case. Maybe training your classifier with the bert-base-uncased model is a better option if you can tolerate a 1% reduction in eval_accuracy.
REF: https://github.com/google-research/bert/issues/4#issuecomment-434782258

Did OOM occur when training LARGE model with this repo?

Yes, even a batch size of 1 leads to OOM. I'd better play with BERT-Base. Thanks for your quick reply.


"will be widened to Any" logging at warn level is aggressive for customers

These warning messages make it seem like something is kind of wrong when starting up customer repos.
warn:[module]: [path]go:965:34-34: external type "typename" will be widened to Any

consider using codes for error types that can be ignored in the project level.


Unexpected connection loss when cloning via https with slow bandwidth

Gitea version (or commit ref): lastest 1.14 and latest main
Git version: 2.29
Operating system: Debian 10
Database (use [x]):

[ ] PostgreSQL
[X] MySQL
[ ] MSSQL
[ ] SQLite

Can you reproduce the bug at https://try.gitea.io:

[X] Yes (provide example URL)
[ ] No

Description
When cloning a repository with slow bandwidth over https, gitea seems to timeout.
We noticed that because F-Droid fails to checkout repositories from codeberg.org, there is also a issue on Codeberg here: https://codeberg.org/Codeberg/Community/issues/461.
This seems to affect try.gitea.io also. Timeouts seem to happen after a few minutes, but not always after the same time. We tried to increase git.timeout values on our test instance also, also accessed port 3000 directly without reverse proxy, without any effect.
$ sudo wondershaper enp0s31f6 4000 4000 # somehow values do not really matter, anything between 500-4000 had the same effect
$ time git clone https://try.gitea.io/ashi/Gadgetbridge
Klone nach 'Gadgetbridge' ...
remote: Enumerating objects: 92096, done.
remote: Counting objects: 100% (92096/92096), done.
remote: Compressing objects: 100% (22562/22562), done.
error: 5767 Bytes des Bodys werden noch erwartet | 12.00 KiB/s
fetch-pack: unexpected disconnect while reading sideband packet
fatal: zu frühes Dateiende
fatal: fetch-pack: ungültige index-pack Ausgabe

real    1m31,925s
user    0m0,005s
sys     0m0,025s

Because the description is not clear on this: We reproduced with serving assets from Gitea public folder, too. https://codeberg.org/Codeberg/Community/issues/460 is most likely related, too.

We really need to see some logs from the gitea side of things.

Oh sure, sorry, we only shared them in our internal infrastructure groups ... :see_no_evil:
root@codeberg:~# grep -E '2021/06/02 06.*RPC\(upload-pack\)' /data/git/log/gitea.log
2021/06/02 06:07:40 routers/repo/http.go:556:serviceRPC() [E] Fail to serve RPC(upload-pack) in /data/git/gitea-repositories/kollo/x11-basic.git: signal: broken pipe -
2021/06/02 06:09:53 routers/repo/http.go:556:serviceRPC() [E] Fail to serve RPC(upload-pack) in /data/git/gitea-repositories/kollo/x11-basic.git: signal: broken pipe -
2021/06/02 06:10:05 routers/repo/http.go:556:serviceRPC() [E] Fail to serve RPC(upload-pack) in /data/git/gitea-repositories/gitnex/gitnex.git: signal: broken pipe -
2021/06/02 06:10:35 routers/repo/http.go:556:serviceRPC() [E] Fail to serve RPC(upload-pack) in /data/git/gitea-repositories/gitnex/gitnex.git: signal: broken pipe -
2021/06/02 06:12:09 routers/repo/http.go:556:serviceRPC() [E] Fail to serve RPC(upload-pack) in /data/git/gitea-repositories/hjacobs/kube-resource-report.git: exit status 128 - fatal: the remote end hung up unexpectedly
2021/06/02 06:17:27 routers/repo/http.go:556:serviceRPC() [E] Fail to serve RPC(upload-pack) in /data/git/gitea-repositories/nexttracks/android.git: signal: broken pipe -
2021/06/02 06:18:53 routers/repo/http.go:556:serviceRPC() [E] Fail to serve RPC(upload-pack) in /data/git/gitea-repositories/nexttracks/android.git: signal: broken pipe -
2021/06/02 06:21:01 routers/repo/http.go:556:serviceRPC() [E] Fail to serve RPC(upload-pack) in /data/git/gitea-repositories/freeyourgadget/gadgetbridge.git: signal: broken pipe -
2021/06/02 06:22:46 routers/repo/http.go:556:serviceRPC() [E] Fail to serve RPC(upload-pack) in /data/git/gitea-repositories/freeyourgadget/gadgetbridge.git: signal: broken pipe -
2021/06/02 06:33:16 routers/repo/http.go:556:serviceRPC() [E] Fail to serve RPC(upload-pack) in /data/git/gitea-repositories/oppenlab/ariane.git: signal: broken pipe -
2021/06/02 06:39:18 routers/repo/http.go:556:serviceRPC() [E] Fail to serve RPC(upload-pack) in /data/git/gitea-repositories/corona-contact-tracing-germany/cwa-android.git: signal: broken pipe -
2021/06/02 06:42:56 routers/repo/http.go:556:serviceRPC() [E] Fail to serve RPC(upload-pack) in /data/git/gitea-repositories/stoptheccp/ccp-database-leak.git: signal: broken pipe -
root@codeberg:~#

This was the final thing we grepped because of the reports related to FDroid repos. We saw more broken pipes, but expected them to being unrelated, we noticed later that also normal file transfers fail. I'll check the logs again with this information.

Hmm, the canceling file downloads don't seem to appear in the logs, will play with the loglevels once more.
But basically, we're seeing this broken pipe issue, on slow throughput or when halting the download (I'm using ctrl+z and fg from time to time when reproducing locally when I don't want to throttle my full machine)
We were already looking for some timeout, but found none left to configure.
Using haproxy for connections to other backends (e.g. file serving from nginx) works fine. Direct access to Gitea via the local port results in the same issue.
Oh and I just noticed the error log from OP is translated, the English version would look like
error: 7158 bytes of body are still expected29 MiB | 487.00 KiB/s
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: index-pack failed

Ok your logs imply to me that the response writer is being closed independently of the upload pack.
So ... If we're sure it's not coming from a proxy it must be being closed further down within gitea.
Now, we know that long running connections are allowed because the event stream doesn't have this problem. So there's maybe something that the event stream is setting on the response that is preventing this early close?
I guess it would be helpful to know if you're running with the inbuilt gzip handler or other config?

In particular we set:
https://github.com/go-gitea/gitea/blob/c1ff59c1cd51da6fcc47d31ca84932e9bccced92/routers/events/events.go#L29
Which we don't set in http.
So a good guess might be to set that after this line here:
https://github.com/go-gitea/gitea/blob/c1ff59c1cd51da6fcc47d31ca84932e9bccced92/routers/repo/http.go#L439

We didn't change the GZIP config. In case you have questions about the codeberg config and don't want to wait for a reply, you can usually look at https://codeberg.org/Codeberg/build-deploy-gitea/src/branch/master/etc/gitea/conf/app.ini - in case this is easier for you.
Please keep in mind that normal file transfer seemed to show this very same issue (e.g. downloading a big file from gitea/public). Maybe a similiarity between repo and other connections (public serving + most likely file attachments) gives you a hint?

I think it's all similar as I don't think we set the keep alive header on those either so it's worth checking if the above suggestion solves things.
If it does then we can add in the keep alive command elsewhere or everywhere.
If it doesn't then at least we know it's not that.

@zeripath
added the keepalive header as suggested. Didn't help.
Since this affects try.gitea.io also we should not distract ourselves by digging into codeberg specific configs.

just an idear of mine: could it be an regression of the macaron -> chi migration ?

@6543 that's my suspicion too and why I was asking specifically about things like HTTP keep alive etc.

@6543 I already started searching for the regression commit, but as I told youon Matrix I won't find time looking into more details until tonight, but I wanted to share some first results early, maybe you can already make use of them:
Good news - Release 1.14.2 seems not to be affected, so the bug wasn't delivered to end users (but Codeberg, shame on us for living on the edge). The release branch is. So maybe you have an idea what changed in between?
Also from the log:
2021/06/04 19:53:34 ...les/public/public.go:165:handle() [I] [Static] Serving /many-zeroes
2021/06/04 19:53:39 Completed GET /many-zeroes 200 OK in 5.01920503s

Before this timeout was shown AFTER the transfer stopped (e.g. Completed GET /many-zeroes 200 OK in 11m56.011945691s). As you can see, this returned early (after five seconds apparently) while the actual transfer timed out after 51 seconds with
2021-06-04 19:54:25 (50.1 KB/s) - Connection closed at byte 2621440. Giving up.

The file is 100MB of size.

Well, nevermind, I just finished the bisect, have a look at this commit: 41422f0df06be53d9ae8e16e385f03b81bd47f51
Add timeout to writing to responses (#15831) (#15872)

Backport #15831

In #15826 it has become apparent that there are a few occasions when a response can
hang during writing, and because there is no timeout go will happily just block
interminably. This PR adds a fixed 5 second timeout to all writes to a connection.

Fix #15826

Signed-off-by: Andrew Thornton<EMAIL_ADDRESS>
Sounds obvious ...

The idea behind this makes sense, but I assume that there is some kind of network buffer, so the deadline isn't extended on slow connections, because the buffer isn't cleared on time?
That'd explain our observation, that it's not a fixed timeout - cloning huge repos on a fast connection worked just fine (probably because the buffer is refilled every <5s)? No clue about how this is handled deeper in the code or framework, I was just looking at this specific commit right now.
@zeripath

Aha!

So I think we still need this timeout - otherwise go will happily hold on to the connections when the connection is blocked.
I guess we just need to increase the length of this timeout.

So through compiling you can trial a few different values as I state in the PR:
LDFLAGS="-X "code.gitea.io/gitea/modules/graceful.PerWriteWriteTimeout=30s""
one other option is whether we should just tie the ResponseWriter to the request context?

Yes, we're doing exactly this right now.
I think, with this we mainly shift the curve, kinda like a threshold how slow a connection can become ... not sure if there is a better solution like knowing exactly if it's still alive or something ...
I also don't quite know the impact of the main issue. Would it be an option to set it really high, like a few minutes, so that only really stale connections are cleaned? Personally, I know that it's sometimes convenient when a network transfer continues, even when the connection was disrupted for a short time.

So I think there is some kind of function: the larger the blob to transfer and the slower the connection, the easier this will be hit. Remember I was running into this with 50KB/s transfer on a 100MB file after 5 seconds. I'd imagine that when you increase this to 60 seconds, but my transfer wouldn't have been finished, this would result in the same issue, but later (will try). With higher bandwidth but larger data, this should stay proportional.

OK, let's do a heuristic adjustment.
Couple of ideas:

Simplest: Store the last deadline that we set

Minimum deadline is Now()+ 5s
If previous deadline has not passed use it instead of now + 5s
PROBLEMS: This could be lead to very very long timeouts - but I guess that is reasonable.
There's also no depenedence on the size of slice being written or how much written just on how many times written

Take account of what's about to be written plus the last timeout

Minimum basic timeout is 5s
Timeout: is 2.5s + 0.25s * len(towrite)/1024 + previous deadline if this is longer

Take account of the amount written:

Minimum basic timeout is 5s
Timeout: is 0.25s * len(towrite + written)/1024 + previous deadline

From 5387504d0e3ac1558668867b9a7c0df1ff78df52 Mon Sep 17 00:00:00 2001
From: Andrew Thornton<EMAIL_ADDRESS>Date: Fri, 4 Jun 2021 21:15:25 +0100
Subject: [PATCH] Set self-adjusting deadline for connection writing

Fix #16055

Signed-off-by: Andrew Thornton<EMAIL_ADDRESS>
diff --git a/modules/graceful/server.go b/modules/graceful/server.go
index 26195c632..07f51de3e 100644
--- a/modules/graceful/server.go
+++ b/modules/graceful/server.go
@@ -31,6 +31,9 @@ var (
 // PerWriteWriteTimeout timeout for writes
 const PerWriteWriteTimeout = 5 * time.Second

+// PerWriteWriteTimeoutKbRate is a timeout taking account of how much there is to be written
+const PerWriteWriteTimeoutKbRate = 2 * time.Second
+
 func init() {
 	DefaultMaxHeaderBytes = 0 // use http.DefaultMaxHeaderBytes - which currently is 1 << 20 (1MB)
 }
@@ -249,13 +252,19 @@ func (wl *wrappedListener) File() (*os.File, error) {

 type wrappedConn struct {
 	net.Conn
-	server *Server
-	closed *int32
+	server   *Server
+	closed   *int32
+	deadline time.Time
 }

 func (w wrappedConn) Write(p []byte) (n int, err error) {
 	if PerWriteWriteTimeout > 0 {
-		_ = w.Conn.SetWriteDeadline(time.Now().Add(PerWriteWriteTimeout))
+		minDeadline := time.Now().Add(PerWriteWriteTimeout)
+		nextDeadline := w.deadline.Add(PerWriteWriteTimeout/2 + time.Duration(len(p)/1024)*PerWriteWriteTimeoutKbRate)
+		if minDeadline.After(nextDeadline) {
+			nextDeadline = minDeadline
+		}
+		_ = w.Conn.SetWriteDeadline(nextDeadline)
 	}
 	return w.Conn.Write(p)
 }
--
2.31.1

Is basically option 2 there.

Ugh the patch above is broken but I can't fix it on my phone - the pr should apply on to 1.14 cleanly

Yeah, I noticed this already. We are going for patching the timeout for the moment and wait for a proper fix then, don't hurry. We weren't able to use the build flag to override the setting.


Algolia keys in sample.env

Is there any reason not to put the real ALGOLIA_APP_ID and ALGOLIA_API_KEY in sample.env?
I reflexively put in a dummy key when I set this up, but now that I revisit this, that seems like a mistake.

Yes, actually it broke the .dev build unsurprisingly 🤦♂ , I think @RandellDawson noticed it and reported in the team chat.
The real fix is to ignore and move ahead when the keys are not available are default. We do this with google application credentials.

Oh, I assume it broke the build because .dev isn't using sample.env.  I didn't think of that...
So, we should implement the fix and add the public keys to sample.env, right?

I was thinking something more along the lines of (example from api-server):
  if (secretInvalid || publicInvalid) {
    if (process.env.FREECODECAMP_NODE_ENV === 'production') {
      throw new Error('Stripe API keys are required to boot the server!');
    }
    console.info('No Stripe API keys were found, moving on...');
    done();
  } else {

I would try to avoid hundreds of contributors hitting the indexes locally. Ideally people should get their own keys.
While the key and index is public, it's still not recommended to hit it?

As for the keys, it's actually fine because the build should fail. I have since added the keys in the build pipeline.

One thing: if we don't want contributors spamming search (fair enough!) I think there should be some docs that let people know what's what.  Either that search isn't available in development or the steps they need to take to make it work.

I agree. We should add some docs on getting keys, or perhaps creating a test index and sharing that instead


Sorting issue with exploratory.profile_columns

db_api = DuckDBAPI()
exploratory.profile_columns(df, column_expressions=["first_name", "dob"], db_api=db_api)

This issue does not occur in altair-5.3.0 but does in altair-5.4.1


Bumped Mesos package to 1.4.0-rc3.

High Level Description
This PR bumps the Mesos package to the latest 1.4.0 release candidate, 1.4.0-rc3.
Related Issues

MESOS-7714 Fix agent downgrade for reservation refinement

Checklist for all PR's

[x] Included a test which will fail if code is reverted but test is not. If there is no test please explain here: This commit includes a Mesos test update to verify the fix for MESOS-7714.
[x] Read the DC/OS contributing guidelines
[x] Followed relevant code rules Rules for Packages and Systemd

Checklist for component/package updates:
If you are changing components or packages in DC/OS (e.g. you are bumping the sha or ref of anything underneath packages), then in addition to the above please also include:

[x] Change log from the last version integrated (this should be a link to commits for easy verification and review): Mesos diff
[x] Test Results: Mesos CI results
[ ] Code Coverage (if available): N/A

@mesosphere-mergebot bump-ee

@mesosphere-mergebot label ready for review.

@greggomann  - please get your reviews in for this mesos bump.

@Gilbert88 @kaysoky @mpark could y'all take a look ASAP if you have a cycle?

Apart from bringing in https://github.com/mesosphere/mesos/commit/d48c5c647e0d4007a6503a6937dcf6f69ae659d9 which is bug-fix for  which is the fix mentioned in the description (https://issues.apache.org/jira/browse/MESOS-7714) , it brings in lot of more changes: https://github.com/mesosphere/mesos/commits/dcos-mesos-1.4.0-rc3
Are these desirable for 1.10.0 release of DC/OS?
Please review: @gkleiman , @klueska , @kaysoky, and @mlunoe .

Yes.

MESOS-7863, MESOS-7865 Fixes some races if a task is killed too quickly after launch.  We'd want these fixes to be in the release.
MESOS-7888 Some changes to metrics.  We'd like this patch to be included in case anyone starts using these metrics.  (It may be a breaking change otherwise.)
MESOS-7909 Won't affect DC/OS because DC/OS does not use the appc/runtime isolator.  But nice to have regardless.

@kaysoky  - Let's get one more review on this and we should be on track.
Also while reviewing make sure that no EE changes are missed for those bumps that introduced. Thanks!

@mesosphere-mergebot label ship-it

Now that this landed via train 210 -- do we need to close a corresponding JIRA ticket?


support DequeueAudio

see: https://wiki.libsdl.org/SDL_DequeueAudio

Hi @gengen1988, thanks for reporting this. I just added the binding in latest commit 👍

Hello @gengen1988 & @chaeyoungsong
This latest updated is giving us build errors.
Can we please get a pragma warning but no build error for this, in the same fashion that https://github.com/veandco/go-sdl2/pull/215 corrected?
Thank you!

Should be fixed in the latest commit e97e53b.

Thanks @veeableful that did it.


MQTT External Broker example in docs?

Any chance you could either make the MQTT Broker part of the Configuration UI, or alternatively, give an example of the 4 entries needed to get it up and running?   I was able to locate a 'mqtt_server_address' and 'mqtt_port' in the error message and tried those, but still need to be able to get the MQTT User/Pass in there, as well
Thank you!

That's pretty confusing. So the variables used within the python program are mqtt_server_address and mqtt_port. These are however not set using those names. The environment variable MQTT_SERVER must be set, which will be assigned to mqtt_server_address. If you're running with docker, this is set with the -e MQTT_SERVER=<your IP> argument, which sets an environment variable internally to the container. Otherwise, if you're running it on Linux natively, you can export MQTT_SERVER=<your IP> to set the environment variable. You had me second guessing my naming scheme, but I'll stick to the MQTT_SERVER name for clarity and brevity.
The full command would look like:
docker run --rm -d \
    --net host \
    -e MQTT_SERVER=<IP_ADDRESS> \
    -v <path_to_cert_folder>:/opt/xcel_itron2mqtt/certs \
    ghcr.io/zaknye/xcel_itron2mqtt:main

My apologies - I had typed this out on my laptop, so the "Configuration UI" part doesn't make sense.  It should have been under the https://github.com/wingrunr21/hassio-xcel-itron-mqtt repo.   Sorry about that; I shouldn't do tech-work on the Tablet!


Order layers and expand processing block

To test, import a new layer. The processing block should expand automatically and the new layer should be at the top of the list.
Connects #244
Connects #312

+1


sendTransaction return {"message":"OK","statusCode":200} always

When I try send a transaction with sendTransaction(tx) I have the response {"message":"OK","statusCode":200} .
but nothing happens (tonkeeper wallet doesn't show anything, ton explorer doesn't show any changes)

@dmitrydrynov thanks for your question. HTTP response {"message":"OK","statusCode":200} means that the request was successfully received by wallet's bridge. When user accepts or declines the request, the bridge will send a SSE message to the dApp. You can find more details about TonConnect workflow in the protocol specification.

I see. The tonkeeper does not show any message for accepts or declines the request In testnet (only in mainnet)


MenuButton doesn't remove buttons properly if I force it it crashes

Tested versions
Reproducible 4.4 dev2
System information
Linux manjaro
Issue description
either I don't understand sub Menus or it doesn't deallocate the sub menus
I expected to remove all submenus with clear()
Steps to reproduce

click on 1 shape it works
click on 2. shape (first it uses sub menu of the 1. shape)
if you uncomment queue_free() it crashes on the 2. step

quick sample of code:
class_name PopUp extends MenuButton

func _ready() -> void:
	g_man.pop_up = self

var dict_name__sub_menus = {}

## multi_array [0] name of button [1] name of sub_menu [id] is number of sub menu
func pop_up(position, multi_array, call: Callable):
	var main_menu = get_popup()
	var sub_menus = dict_name__sub_menus.values()
	if sub_menus:
		for sub in sub_menus:
			for item in sub.id_pressed.get_connections():
				sub.id_pressed.disconnect(item.callable)

	## TODO: uncomment and it'll crash after clicking 2 times
	#for subs in dict_name__sub_menus.values():
		#subs.queue_free()

	dict_name__sub_menus.clear()
	main_menu.clear()
	if multi_array:
		var id = -1
		for item in multi_array:
			var sub_menu = dict_name__sub_menus.get(item[1])
			if not sub_menu:
				id += 1
				sub_menu = PopupMenu.new()
				sub_menu.name = item[1]
				dict_name__sub_menus[item[1]] = sub_menu
				main_menu.add_child(sub_menu)
				main_menu.add_submenu_item(item[1], item[1])
				sub_menu.id_pressed.connect(
					func(index_submenu):
						call.call(id, index_submenu)
				)
			sub_menu.add_item(item[0])
	set_position(position)
	show_popup()

Minimal reproduction project (MRP)
MRP
mrp-rpc.zip
file was too large even on minimal.
MRP without .godot

file was too large even on minimal.

What are you including? This shouldn't be possible if all it contains is some code, did you exclude the .godot folder?

Uhm no.
Wasnt that .godot has to be included?

No it says:

Be sure to not include the .godot folder in the archive (but keep project.godot).

ok I excluded only .godot this time now it's 4.2k :)

ok looking deep in to documentation I've fixed my bug with:
main_menu.clear(true)
added "true" in clear
it also doesn't crash this time
but the crash still exists if there's sub menus that aren't deallocated and that I want to deallocate them with force (queue_free())

Can confirm with the following crash trace:
================================================================
CrashHandlerException: Program crashed
Engine version: Godot Engine v4.4.dev.custom_build (f606c73fa8c65326149b9a54a5dd62d6b93cdb5d)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[0] WorkerThreadPool::`RTTI Complete Object Locator'
[1] Window::get_contents_minimum_size (godot\scene\main\window.cpp:1958)
[2] Window::get_clamped_minimum_size (godot\scene\main\window.cpp:1967)
[3] Window::_update_window_size (godot\scene\main\window.cpp:1042)
[4] Window::set_size (godot\scene\main\window.cpp:393)
[5] Window::reset_size (godot\scene\main\window.cpp:404)
[6] PopupMenu::_activate_submenu (godot\scene\gui\popup_menu.cpp:348)
[7] PopupMenu::_input_from_window_internal (godot\scene\gui\popup_menu.cpp:630)
[8] PopupMenu::_input_from_window (godot\scene\gui\popup_menu.cpp:448)
[9] Window::_window_input (godot\scene\main\window.cpp:1675)
[10] Viewport::_sub_windows_forward_input (godot\scene\main\viewport.cpp:2898)
[11] Viewport::push_input (godot\scene\main\viewport.cpp:3159)
[12] Window::_window_input (godot\scene\main\window.cpp:1682)
[13] call_with_variant_args_helper<Window,Ref<InputEvent> const &,0> (godot\core\variant\binder_common.h:304)
[14] call_with_variant_args<Window,Ref<InputEvent> const &> (godot\core\variant\binder_common.h:419)
[15] CallableCustomMethodPointer<Window,Ref<InputEvent> const &>::call (godot\core\object\callable_method_pointer.h:104)
[16] Callable::callp (godot\core\variant\callable.cpp:58)
[17] Callable::call<Ref<InputEvent> > (godot\core\variant\variant.h:875)
[18] DisplayServerWindows::_dispatch_input_event (godot\platform\windows\display_server_windows.cpp:3733)
[19] DisplayServerWindows::_dispatch_input_events (godot\platform\windows\display_server_windows.cpp:3704)
[20] Input::_parse_input_event_impl (godot\core\input\input.cpp:803)
[21] Input::flush_buffered_events (godot\core\input\input.cpp:1084)
[22] DisplayServerWindows::process_events (godot\platform\windows\display_server_windows.cpp:3186)
[23] OS_Windows::run (godot\platform\windows\os_windows.cpp:1772)
[24] widechar_main (godot\platform\windows\godot_windows.cpp:181)
[25] _main (godot\platform\windows\godot_windows.cpp:206)
[26] main (godot\platform\windows\godot_windows.cpp:220)
[27] WinMain (godot\platform\windows\godot_windows.cpp:234)
[28] __scrt_common_main_seh (D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288)
[29] <couldn't map PC to fn name>
-- END OF BACKTRACE --
================================================================

But not sure what is exactly going wrong here or if the use is valid, but we should avoid crashing if possible

I feel like it's related to https://github.com/godotengine/godot/issues/97200

Also it doesn't crash on 4.3.stable release.

But not sure what is exactly going wrong here or if the use is valid

Probably what's happening here is like delete an internal node, i took a look in PopupMenu code and saw the code checks for nullptr before do some actions but the issue code uses subs.queue_free() so the node becomes invalid while PopupMenu still processing them. Using subs.free(), removing the node from tree after subs.queue_free() or awaiting a process frame (like Whales pointed) solves the problem.

but we should avoid crashing if possible

IMO we should just put a warning like the warning in ScrollContainer.get_h_scrollbar in the docs of PopupMenu.add_submenu_item: "Using this function make the node behave like an internal node from PopupMenu, don't delete this node manually otherwise this can lead to a crash" and let the PopupMenu.clear handle the remotion.

Is this the same error that you have got while debugging?

If yes, then it's related to https://github.com/godotengine/godot/issues/97200

The error there is that the Window tries to process the mouse exit event on a freed child. is_inside_tree() returns true but get_tree() returns nullptr.

No, the error is different and the backtrace the same AThousandShips get:

in 4.4dev-4 Fixed
sorry for long reply was busy with game


Code cleanup

Minor code cleanup collected while working on the knex code-base and extracted here so it would not unnecessarily pollute other pull requests.

@jurko-gospodnetic Thanks!