Remove Site Script

@comet/remove-site
This is a command-line script to remove the site-service and all correlating files from the Comet project.
Usage
To run the script, use the following command:
npx @comet/remove-site

Example usage:
npx @comet/remove-site

I'm not entirely sure if we decided on this:
this should be a sub command of create-app, usage:
npx @comet/create-app remove-site

you should not use the branch of another PR as target, because as soon as the other PR gets merged this one is dangling.
usually we let both target main (with the downside that the second also contains the commits from the first)

you should not use the branch of another PR as target, because as soon as the other PR gets merged this one is dangling.
usually we let both target main (with the downside that the second also contains the commits from the first)

Thank you for the information - I did not know that. Should I change this back to main?

yes

(obviously you must wait with merge this until dependent PR ist merged)

(obviously you must wait with merge this until dependent PR ist merged)

Yes oc.

@max-debug022 please rebase


Don't reuse request_id

Bug: https://phabricator.wikimedia.org/T151934

:+1:
@Pchelolo, are there any reasons to not merge this right away?

Let's give @d00rman a chance to chip in?

@Pchelolo: Yup, otherwise happy to merge whenever you are ready.

Coverage increased (+0.06%) to 93.567% when pulling 324325a443f6915001129a36b8ee07091b9e4e2c on Pchelolo:req_id into 0224a233148a19a723360b66a2f1928f44f2f1af on wikimedia:master.

I would honestly prefer setting another header or something similar. Sticking this in x-triggered-by with , reqId:xxx feels like a work-around IMHO and complicates parsing the field (unnecessarily IMO)

@d00rman, we need to build up a trace of request ids / topics etc, and x-triggered-by is designed to do exactly that, in a list of URLs. Since each subrequest will get a new request id, we will can have multiple reqid:xxx URLs in this trace.

@Pchelolo, this needs a rebase.

Did a quick & dirty rebase, lets see if the tests pass.

That clearly did not work.
@d00rman, if you are okay with the approach in principle I can look into doing a proper rebase.

I have soften my position on this so am ok with going with a different reqID for child events.

I have softened my position on this so am ok with going with a different reqID for child events.

Okay, cool ;) Added a proper rebase to my todo.

Rebased in #203.


Revert "Add Spring Boot and refactor configuration"

Reverts pivotal/dis-api#9

Raw.

Yeah we decided to keep it spring boot free for the moment just to avoid it
requiring that knowledge to make changes. Data science are hopefully going
to be in and out of this code base.
On Tue, 8 Mar 2016, 18:58 Tom Anderson<EMAIL_ADDRESS>wrote:

Raw.
—
Reply to this email directly or view it on GitHub
https://github.com/pivotal/dis-api/pull/10#issuecomment-193915277.


Any plan to replace Grahiql with Playground

It would be nice to replace GraphiQL with Playground
https://github.com/prisma/graphql-playground
The main feature I would like to have:

Interactive, multi-column schema documentation
Configuration of HTTP headers (so we can unlock the API whith a Bearer token)
Tabs

@Sparow199 added an Altair starter sometime ago. Maybe you could use that?

Yes, I just noticed it right after asking the question, but I still prefer the multi-column schema documentation from playground.
Thanks for point that out!

@elenigen , i'll add GraphQL Playground starter asap.

oh, nice thanks, that's a good news! Altair was already a nice step upgrade since we have API keys in our service and it let the opportunity to our clients to try the API very easily by modifying the HTTP header.

Altair is a very active project, don't hesitate to create issues on it's
repository.
On Tue, Mar 12, 2019, 19:44 Etienne Le Nigen<EMAIL_ADDRESS>wrote:

oh, nice thanks, that's a good news! Altair was already a nice step
upgrade since we have API keys in our service and it let the opportunity to
our clients to try the API very easily by modifying the HTTP header.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/graphql-java-kickstart/graphql-spring-boot/issues/212#issuecomment-472132205,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVP80uHh4chi_Q6tM-Bv3sB89IekzlWaks5vV_V6gaJpZM4blqOb
.

Not sure if it's really a good practice to copy all the features from one project to another, in this case why not simply using the original project?  In my case, I was using before Graphiql before, then I discovered Playground which they say is built on top of Graphiql, so I don't feel it's a good idea to tell Graphiql people "you should add Playground features".  Then I discovered Altair and the good news was, it's already integrated in this kickstart project, so I adopted it, but it still looks like Playground has better features.

This has been added in 5.9.1 thanks to @BlasiusSecundus


Undefined error when processing s2 longer than s1.

I wonder if this:
var high = (i + range <= s2.length) ? (i + range) : (s2.length - 1);
should be:
var high = (i + range < s2.length) ? (i + range) : (s2.length - 1);

Thanks for the report - I'll take a closer look this evening.

@stuartbale Can you make a test case to recreate this? I tried this (below) and I'm still passing.
 it('should work no matter which string is longer', function() {
    var dist = distance('short', 'somethingmuchlonger');
    var reverseDist = distance('somethingmuchlonger', 'short');
    assert.equal(dist, reverseDist);
  });

OK - so the function still works, as on this line:
if (s1Matches[i] !== true && s2Matches[j] !== true && s1[i] === s2[j]) {
s2[j] returns undefined, as it is outside the upper bound on the array.
Basically, the code loops one more time than it needs to, when s2 is more than twice the length of s1.
I will change the heading of this issue to more accurately describe the scenario.

@stuartbale Sorry for the delay, I was on vacation last week! Confirmed what you're seeing and fixed it in 0.2.7. Thanks for helping out!


performRequestAsync's response event fires three time per request

title: performRequestAsync's response event fires three time per request
NOTE: It looks rather a reflex-dom's issue, but I posted here since don't know how to build/run reflex-dom individually.
When I was creating a simple GET API with background route, I noticed the result event of performRequestAsync was firing three times per request. I first thought its was firing evertytime XHR status changes, but after looking at performRequestAsync code (https://github.com/reflex-frp/reflex-dom/blob/develop/reflex-dom-core/src/Reflex/Dom/Xhr.hs#L269), my understanding is that the result should fire once per request.
Created a small repository to reproduce the problem.
https://github.com/kamoii/obelisk-ping-test

Simple backend api "ping" (it just responds with "pong")
From the frontend, ping the API everytime the buttons is pressed
Show how many times send request and received response

Here's the main part of front end code.
frontend :: Frontend (R FrontendRoute)
frontend = Frontend
  { _frontend_head = el "title" $ text "Obelisk Minimal Example"
  , _frontend_body = prerender_ blank $ do
      el "h1" $ text "Backend request test."
      evBtn <- el "div" $ button "ping"
      dyPingCount <- count evBtn
      el "div" $ do
        text "ping count: "
        dynText $ T.pack . show <$> dyPingCount
      evPong <- ping evBtn
      dyPongCount <- count evPong
      el "div" $ do
        text "pong count: "
        dynText $ T.pack . show <$> dyPongCount
      pure ()
  }

ping :: _ => Event t () -> m (Event t ())
ping evInput = do
  res <- getApi BackendRoute_Ping evInput
  pure $ () <$ res

getApi
  :: _
  => BackendRoute param
  -> Event t param
  -> m (Event t XhrResponse)
getApi r evInput = performRequestAsync $ fmap mkXhrReq evInput
  where
    mkXhrReq param =
      let url = renderBackendRoute _enc (r :/ param)
      in xhrRequest "GET" url def

    _enc :: Encoder Identity Identity _ _
    Right _enc = checkEncoder backendRouteEncoder

Expected ping count and pong count to be same, but actually pong count increments by 3 per ping request. Following is as gif I captured using chromium with developer tools open so you can see the ping request.

NOTE: The repo above uses develop branch.
$ cat .obelisk/impl/github.json
{
  "owner": "obsidiansystems",
  "repo": "obelisk",
  "branch": "develop",
  "rev": "86a9584c6d7648bd5324ef57d62421fed1bf1978",
  "sha256": "1lbii87j5530ncm6brfbzkd3wg16mgxazsf3l56zzv4c8cydilmh"
}

Related to https://github.com/reflex-frp/reflex-dom/pull/255, I think

@alexfmpe Thank you. Thats definitley related.
So its a reflex-dom, or more strictly ghcjs-dom/jsaddle issue.
Should I close this issue?

Not just related, but same issue ;-)

This was fixed by https://github.com/reflex-frp/reflex-dom/pull/399


Can't install cell2location in CentOS

I tried different ways to install cell2location with failures.

I installed Singularity image, but the image is not the latest version and thus many modules are not available. The tutorial couldn't be followed.
Installed inside a conda environment, but always got error: spyder==5.4.1 's dependencies pyqt5<5.16 and pyqtwebengine<5.16 not installed, even though I installed them manually. Therefore, cell2location can't be installed in this way.
Installed inside a virtualenv environment, but got new error:
ERROR: Could not find a version that satisfies the requirement scvi-tools>=0.15.3 (from cell2location[tutorials]) (from versions: 0.7.0a0, 0.7.0a1, 0.7.0a2, 0.7.0a3, 0.7.0a4, 0.7.0a5, 0.7.0a6, 0.7.0b0, 0.7.0, 0.7.1, 0.8.0b0, 0.8.0, 0.8.1, 0.9.0a0, 0.9.0a1, 0.9.0a2, 0.9.0b0, 0.9.0b1) ERROR: No matching distribution found for scvi-tools>=0.15.3
Hope get your help in installation. Thank you.

Hi @JiahuaQu
The Singularity image is indeed old. On most systems, installation via pip into conda environments works.
I can recommend checking this option:

Conflict errors generally arise when installing into an already existing environment, or when the environments are not fully isolated.
Also, can you install scvi-tools independently of cell2location?


Add basic files to use Catch for unit testing

This is a pre-requirement for getting in the string_view.hpp file for c++17 basic_string_view support. I have this ready and works with c++11. I have tests for the basic_string_view class that need us to get the basic catch infra added. ( ie the catch.hpp header and a file to act as the main exe )

How would I integrate the Catch based unit tests from #2254 in to this framework?

Since we did the same for the gtest proposal, I think we should make sure there's consensus on the mailing list that this is the direction we want to take, before landing this. I'm definitely not opposed to it, but we should all agree here such that we get one framework for unit testing, and not .

@SolidWallOfCode
The easy way would be make a file under tests/unit_tests//.cpp
Add it to the Makefile.am to be added to unit_test program
your test file would look something like:
#include "catch.hpp"
#include "string_view.hpp"

TEST_CASE("constructor calls", "[string_view]") {

	SECTION("Literal look for NULL") {
		ts::string_view sv("hello");

		REQUIRE(sv.size() == 5);
		REQUIRE(sv.length() == 5);
		REQUIRE(sv.empty() == false);
		REQUIRE(sv == "hello");

	}
...

This should all compile in to the main test program.

@zwoop I agree. I sent out notes on having people here make tests for gtest and Catch. I believe anyone else doing the same work will find Catch better than gtest.
We also need to make some BKM for writing tests with Catch.. but I think we need people to write tests before making a set of Best Known Method.

@dragon512 I would prefer to keep the tests close to the code like they are now. That makes is easier to test internal functions without having to expose them just for testing. We should just establish a pattern like foo.cc and foo_test.cc` similar to Go.

It would be great if you can include a demo that shows the pattern you suggest how to use Catch.

@jpeach I would like to separate the file to a different location. I am not clear one what the concern is on "test internal" functions as this is all being linked on as a big .a file. If we want to call the test cpp file
xyz_test.cpp I am fine with that. I would like to separate the source files from the test files to avoid cases like Version.cc which has code and tests in the same file.

@zizhong There is a basic example in the comments as well.
If you look at the documentation for Catch https://github.com/philsquared/Catch
you will see that the we have a number of features.. The one that I need to hit on with @SolidWallOfCode is that we probably want to have our tests use features as:
TEST_CASE("constructor calls", "[string_view]") {
Where the "[string_view]" acts as in value we can filter on, so we have an easy way to reduce what test we want to run.

@dragon512 That is exactly my point. Tests need to be close to the code. We should absolutely not separate them out and then link a big-ball-of-mud. Keeping libts.a tests close to libts.a helps focus the tests on just that component and in the long run will make it easier to reduce the dependency tangle.

@jpeach I see pro and cons for different approaches. my concern with lib/ts/Version.cc as an example is that it is test code and production code in the same file. I think however that you are bring up a different and every important suggestion which is how we break up the tests. In this PR the idea is that I make one big test file that run all the tests ( however there is nothing really doing this). We can break this up to have one set of tests per file, or have a different break up. I believe you are suggesting we should have all the Tests for libts for example as one exe and the tests for iocore/net as a different file if I understand you correctly. In this case we can do that. I can add the test for basic_string_view in the TS directory as you suggest. The trick will be what do we add where as we have _test.cc files that use different test code. Ideally this should be easy to add. I might suggest that we make the "new" Catch based tests end with _test.cpp to make it clear this is not the "old" _test.cc files. Otherwise I was suggestion we make new unit tests in a different place such as {source-location}/tests/mytest.cpp or tests/unit_tests/ts/mytest.cpp. Both of these location would also allow us to break up tests with the correct .a file and reduce the "ball of mud".
quick review of options:

rename new catch based tests as _test.cpp ( instead of _test.cc) so we can migrate and not break existing test code
move test to a subdirectory of tests in the currents source location
move the test to tests/unit_tests/{module name}

My main concern is making sure we can migrate in stages, and not big bang this

My preference would be to have more locality in the unit tests.
I think (2) is a good compromise and hope we don't go with (3).
I personally would prefer to:

store the tests close to the source code which they are testing
build them and execute them per module (i.e. library or plugin)
have a really light weight unit tests bootstrapping

In more words…
These are unit tests and not integration tests, they are never testing the whole project or even a combination of modules together (in comparison with AuTest and TSQA), unit tests structure usually resembles the code structure and I am not sure if creating a separate test directory mirroring the code structure makes much sense.
Having all pieces together that need to be updated with a particular change is a practical approach for conscientious developers to keep tests and code in sync. From my experience it seems that trying to search somewhere else for the tests crosses a threshold for many 😉.
I tend to consider the unit tests and the code as almost the same kind and don’t believe they should be separated. Unit test are not clutter by any means, if the tests are not pleasant to look at we should write more elegant tests 😉. I am not advocating combining code and tests in the same file but they should be pretty close together.
Writing unit tests should be really light weight and quick (it should not require much boot strapping) otherwise it will feel like a burden (it is especially important if practicing TDD).
Different developers have different styles but in general If I need to add a new feature (or class or a function) I usually sketch the code and write a small test to quickly test it and then I iterate over by adding more tests and then more code until I make the functionality as complete as needed. After I have some confidence that my new code really works I integrate it with the existing module.
In this flow I always try to keep the new code as modular (independent) as possible and have  just enough dependencies to complete its task.
In general it feels like having all tests in one place and running them together (3) would encourage less discipline and would make code / dependencies harder to untangle when managing the code, it feels less light weight as well.

I am not advocating combining code and tests in the same file but they should be pretty close together.
I just want to make sure we keep the source code and test code in separate files. The location is driven by a need a clean way to understand this is "old" testing code vs "new" testing code. Also that a well tested system will tend to have test code out size the production code being tested by 2-10 times. For that reason..
I am all for (2)
How we break up the tests to run has different value depending on how the testing is being used:
the plus side with frameworks such as catch building all these as one binary or many is a easy build config thing, Catch support both models easily.
The value with running all the tests in

one binary is often with reporting results, as it is easier to do with one binary vs many. ( don't need extra script to gather data, etc)
smaller - many binaries is that for fixing a test or doing development work with TDD is much easier as you can focus on the problem.

I don't believe anything in this patch prevents any case we are talking about. The PR add a catch.hpp file and a main.cpp file ( to have to link in to whatever combination of tests we want). I don't have anything in this yet as some high level logic to for easy building of the testing code at the moment.

I see @gtenev's point - it can get annoying, even for more sophisticated editors, to find test files a long directory path away. I think I'd go with a test subdirectory. E.g. for IpMap, the source file is lib/ts/Ipmap.cc and the unit tests are in lib/ts/test/test_IpMap.cc.

I think we are all agreeing on option 2 then for test location.
Are we all agreed on Catch?

+1 on a /test subdirectory where appropriate. I assume this will work for plugins too, e.g. header_rewrite/test/  to test various core functionality ?

I have an example test in https://github.com/apache/trafficserver/pull/2259

I think we're ready to move forward. We'll put the unit test code in test subdirectories and have them pull the include files from where they are in this pull request. It may not be what we ultimately do but I think it's close enough.

@jpeach I going to commit this as a starting point. I just want to check to make sure you have no major concerns first

I am going forward with the commit. I believe we are all in agreement with the basic of catch. Future PR can deal with build tweaks


Revamp Your Website: Stylish Navbar Menu for Contributing to an Open-Source Project for a Sleek and Modern Design

Effect :When We Hover on Navbar Menu Option we see the Effect
Before Changes:

After Changes:

Hi @MitulSonagara
I recently updated the navbar menu for your project to make it more attractive and user-friendly. Enhance readability, improve navigation, and give your site a visually appealing touch that stands out with these simple yet impactful design updates. I've attached screenshots of the changes, and I'd love to contribute to this enhancement to improve the overall design.
Please assign me to this task. It would be a great opportunity to contribute while enhancing my skills.
I'm looking forward to hearing back from you!
Best regards,
@khurshed07
https://github.com/khurshed07

@khurshed07
working or not?


Improve documentation

Added asciinema recordings in https://github.com/veerendra2/fitbit-cli/pull/7


Stale value of routeContext when useRouter().state.matches gets called in parent layout component

Describe the bug
I believe, due to memoization on the Match and MatchInner components, the useRoute() hook isn't receiving the routeContext of children correctly.
Your Example Website or App
https://stackblitz.com/edit/tanstack-router-bynomg?file=src%2Froutes%2F_layout.tsx
Steps to Reproduce the Bug or Issue
Step 1: Define a component which uses the route context of the accumulated route (e.g. breadcrumb) on a top-level layout component.
Step 2: navigate to a different route as a child component.
Step 3: Notice that the parent component didn't have an up-to-date copy of the child route context.
Expected behavior
The route context should be updated in the parent layout if there are changes in the route at the children's level.
Expected behaviour: https://stackblitz.com/edit/tanstack-router-vllv2a?file=src%2Froutes%2F_layout.tsx
Screenshots or Videos
No response
Platform

All platforms

Additional context
No response

duplicate of #2101
use useRouterState instead
see https://stackblitz.com/edit/tanstack-router-ufw5ne?file=src%2Froutes%2F-component%2Fbreadcrumb.tsx

Thank you so much @schiller-manuel for your quick response and solution.
Could we update the documentation with the same snippet you shared?
https://tanstack.com/router/latest/docs/framework/react/guide/router-context#processing-accumulated-route-context

sure! can you make a PR for the docs ?


Question about Eq. (4) in the paper.

Question:
Why use dot product for Q and K in Eq. (4)?
Describe:
I read the paper "GraphiT: Encoding Graph Structure in Transformers", and the Eq. (5) in this paper, it clearly describe the QQ^T, which means it is a matrix multiplication operations. And in their code, they use function torch.bmm() to process the Q and K.  I am confused that you cite this paper, but the function in section 3.1 is not the same with this paper.
@claying @lobray
Thanks a lot!

Hi @xiyiyia
In "GraphiT: Encoding Graph Structure in Transformers", my co-authors and I used the kernel smoothing formulation introduced in https://arxiv.org/pdf/1908.11775.pdf, originally proposed for NLP. We generalized the formulation to deal with graph-structured data. In order to simplify the formulation, we only considered a symmetric positive definite kernel, which requires the query and key matrix weights (W_q and W_k) to be the same. In any case, you can always write Eq.(4) as a sum of dot products by looking at the output of each node individually.
In our SAT paper, Leslie (@lobray) and I proposed a new class of attentions to account for structural interaction between nodes. As a generalization of dot-product self-attention, we did not restrict W_q and W_k to be the same, which leads to similar or better performance than when W_q=W_k.
Hope this clears up your confusion.
Dexiong


[vim9] Iterating over the values of a dictionary of objects inside a function raises E715: Dictionary required

Steps to reproduce
Source this script:
vim9script

class Foo
  def Add()
  enddef
endclass

def Process(FooDict: dict<any>)
  for foo in values(FooDict)
    foo.Add()
  endfor
enddef

var D = {'x': Foo.new()}

Process(D)

Expected behaviour
The script should compile and run without errors.
Version of Vim
9.0.1200
Environment
macOS 13.1
Apple Terminal
xterm-256color
ZSH 5.8.1
Logs and stack traces
No response

The error is reported at the line: foo.Add().

Explicit typing does not help, but it reveals that the problem may be that values() loses some typing info:
vim9script

class Foo
  def Add()
  enddef
endclass

def Process(FooDict: dict<Foo>)
  const fooList: list<Foo> = values(FooDict)  # <== E1012: Type mismatch; expected list<object<Foo>> but got list<any>
  for foo in fooList
    foo.Add()
  endfor
enddef

var D: dict<Foo> = {'x': Foo.new()}

Process(D)

The original problem is not easy to make work: At runtime we get "any" and need to check if it's an object or a dictionary.
The problem with values() not returning a better type can be fixed, I'll make a patch for that.

This is a potential workaround for the original problem:
vim9script

class Foo
  def Add()
  enddef
endclass

def AsFoo(obj: Foo): Foo
  return obj
enddef

def Process(FooDict: dict<any>)
  for foo in values(FooDict)
    AsFoo(foo).Add()
  endfor
enddef

var D = {'x': Foo.new()}

Process(D)

AsFoo() raises if its argument is not a Foo, so by catching such exception one may dynamically distinguish an object from a dictionary.

Or, possibly even better than raising an exception, one may just check that the type is v:t_object and “cast” the object with AsFoo():
def AsFoo(obj: Foo): Foo
  return obj
enddef

def Process(FooDict: dict<any>)
  for foo in values(FooDict)
    if type(foo) == v:t_object
      AsFoo(foo).Add()
    else
      echo foo['a']
    endif
  endfor
enddef

var D = {'x': Foo.new(), 'y': {'a': 42}}

Process(D)

This workaround works for my use case. Feel free to close this issue.

Is there a (or planned) instanceof operator? (as in java)


Add missing repository resources to pipeline

The pipeline uses templates from a repo that was not included in this pipeline's resources. Adds the missing repository resources to fix the build.

/azp run imodel-native


Update the requirements, readme, and setup.py

Updating some of the really old requirements, and getting rid of some we do not need.
Adding status badges to the readme
Adding classifiers to setup.py
Addressing #111

Ready for review. Versions have been updated, unused packages have been removed. Tests were updated for compatibility with new boto versions, and now pass. Install is significantly quicker.
Since these changes have fixed pcf for 3.7, we could also choose to make that a build-passing requirement. It allows for failure right now.

lgtm


orthorobot: init at unversioned

Ortho Robot is a perspective based puzzle game, where you flatten the view to move across gaps.

I guess in this case we can just call it version "1.0" instead of unversioned.

Added version 1.0 to the name.

Built & tested locally (linux x86_64). Thanks for your submission!


Deploy test on jenkins server.

Integrate automatic performance testing on the build server.
DoD
We are able to pass or fail build on performance results.

Done.


How AWS::AppSync::Resolver.SyncConfig and DynamoDB DeltaSync resolver works? (for custom implementation)

Hi, I'm encountering issues when I try to deploy a pipeline resolver https://github.com/aws-amplify/amplify-cli/issues/5119#issuecomment-685851809.
I'm using DataStore in the frontend and so SyncConfig and a DeltaSync resolver are generated for supporting the needed synchronisation.
I need to deploy a pipeline resolver and DataSourceǸame attribute (and so by transitivity SyncConfig) are not compatible with it.
So I'm wondering how SyncConfig works if I can remove it from the deployment and implement it myself into the resolver? Same for the DynamoDB DeltaSync can I implement it myself?
I don't know if I'm really clear don't hesitate to ask me if needed.

Hi @undefobj thanks for this update, is there a way to access to the beta version? probably by setting the mapping template version to something like "2020-09-XX"?
Or if it's not possible do you know an actual workaround?
Because it's a bit hard to wait hopefully/at least one month.

Also what do exactly Sync operation because due to user management it would a lot more optimised for me to run a query on a index to only retrieved data that the user has access to.

There's no workaround unfortunately.

Thanks @Hideman85 for having detailed this issue (and #5119). I'm building a collaborative platform for site workers (offline + fine grained authorisation) and facing the same type of issues.
Can't wait to use this new feature @undefobj ! Pipeline resolvers are super useful to process business specific authorization rules and narrow down query results based on user's memberships / roles.


Update regex to allow "-beta.X" releases

This PR is a

[x] Feature Implementation
[ ] Bug Fix
[ ] Documentation

What this PR does / why we need it:
It updates regex validating release names to accept releases with names like  "0.2.0-beta.0"
Please leave this checklist in the PR comment so that maintainers can ensure a good PR.
Merge Checklist:

[ ] New feature

[ ] Tests
[ ] Documentation

[ ] SVCat CLI flag
[ ] Server Flag for config

[ ] Chart changes
[ ] removing a flag by marking deprecated and hiding to avoid
breaking the chart release and existing clients who provide a
flag that will get an error when they try to update

/ok-to-test

/test pull-service-catalog-test-integration

/lgtm
/approve

/approved

/approve


what to replace com.adobe.plugins.gaplugin with

I am currently creating a new app, and I keep getting the error: plugin unsupported: com.adobe.plugins.gaplugin.
I have tried to do research to find what to replace the plugin with, but I cannot find any clear answer.
Can anyone help?

I ended up using this one
<gap:plugin name="cordova-plugin-google-analytics" source="npm">

when i replace the old plugin with <gap:plugin name="cordova-plugin-google-analytics" source="npm">
i get the error: plugin unsupported: <gap_plugin name="cordova-plugin-google-analytics" source="npm">
as well

Straight from my config file
<gap:plugin name="cordova-plugin-google-analytics" source="npm"> 	  <param name="ios-package" value="UniversalAnalyticsPlugin" /> 	  <param name="android-package" value="com.danielcwilson.plugins.analytics.UniversalAnalyticsPlugin" /> 	  <param name="wp-package" value="UniversalAnalyticsPlugin" /> 	</gap:plugin>

what program do you use to edit xml files?

Notepad++

could you send me your whole xml document

Payback
Payback is a free app allowing users to keep a rec
Jeremy Prichard

bbm_connect

Payback
Payback is a free app allowing users to keep a rec
Jeremy Prichard

bbm_connect


Add Restart Bot Command

Thank you for the great Discord Bot! Currently this is the feature I'd like the most. For a reason I cannot fully understand yet the ".force_end" command doesn't always work correctly. By my understanding the logic requires the bot to re-check the server's Get5 match status after sending the end match command to the server - sometimes this fails for some reason and therefore the bot will not end the match and release the server even if the Get5 match on the server was ended. This means that currently I have to manually restart the bot to be able to start a new pug.
Thus I would very much appreciate either a way to restart the bot with a Discord command or have another command which forces the server to be used for another match. (by Admin ofc)


Add fontWeight property to Typography

PR Checklist
Please check if your PR fulfills the following requirements:

[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?
No way to change fontWeight for Typography except CSS variable
What is the new behavior?
Added fontWeight property to Typography
Does this PR introduce a breaking change?
[ ] Yes
[x] No

Other information

@evgenoid i feel like we shouldn't need all 100-900 - probably just light, normal, semiBold, and bold (or maybe bold and extraBold based on what we already have) could be mapped

I agree w/ @steppy452 re: the aliases - the aliases would need to be dash cased semi-bold.

@evgenoid i feel like we shouldn't need all 100-900 - probably just light, normal, semiBold, and bold (or maybe bold and extraBold based on what we already have) could be mapped

Done

Did we decide what to do on this?


Sync with Prometheus best practices

Hi,
It's great to see you're looking to use Prometheus monitoring. I noticed a few things that are out of line with Prometheus best practice, which will cause friction in future and limit the benefits you'll get.
In https://github.com/docker/go-metrics/blob/master/suffix.go:  The _count suffix is used by Summary and Histogram metrics, it should not be be used elsewhere. Seconds are the standard, no other units should be offered. We also generally go for seconds rather than s as it tends to be more readable.
In https://github.com/docker/go-metrics/blob/master/namespace.go: The initial comment says "allows const labels to be added to all metrics created in this namespace and are commonly used for data like application version and git commit". This is an anti-pattern as it makes it much harder to work with the metrics, you should have a single metric with the value 1 and all the labels you need. See http://www.robustperception.io/how-to-have-labels-for-machine-roles/ for the general approach.
In
https://github.com/docker/go-metrics/blob/master/namespace.go#L53 you're putting a _count suffix on Counters. The convention is _total for Counters.
There's also a variety of other issues that limit what the user should be able to do with a Prometheus client library, per https://prometheus.io/docs/instrumenting/writing_clientlibs/ Rather than losing this functionality and semantics, I'd recommend using the Prometheus client library directly and filing bugs for anything you find lacking (the lack of timing utilities in Summary/Histogram being the obvious one).

Yeah, super excited to see this as well - does this mean we can expect Docker to export native Prometheus metrics? :)
Anyways, I agree it would be beneficial to be more in line with upstream Prometheus conventions if possible. Upstream docs for that: https://prometheus.io/docs/practices/naming/

@brian-brazil thanks.  I'll try to update with some of the conventions that you mentioned.  We are just getting started so some things will be a little off.
A couple of questions/comments:
For const labels, we don't always have a static cluster of machines, things come and go, especially on our CI so we want the applications to report their version and not have some human to input these.  I don't understand why this makes it harder to work with a metric, can you explain why?  We also want to see performance over different versions to identify regressions in start times ,etc, so this label information is valuable for our use cases.  Its not a machine role for us but an attribute of the metric.
We don't want to expose the full client lib because we want to add metrics to all of our projects and the hardest part about metrics is not the implementation, it is enforcing the naming conventions.  This package is meant to allow everyone working on docker projects to have our naming, suffixes, types, etc be consistent.
@juliusv yes, that is the plan.

For const labels, we don't always have a static cluster of machines, things come and go, especially on our CI so we want the applications to report their version and not have some human to input these. I don't understand why this makes it harder to work with a metric, can you explain why?

It's fine to report your version, but not okay to put it on all metrics. What you're doing here means that every person using your metrics now needs to be aware that that label is present, and that it will get in the way when doing aggregation.

Its not a machine role for us but an attribute of the metric.

What do you mean when you say it's an attribute of the metric? It's an attribute of the binary/process, not of the few lines of code that specify the metric.
The technique for handling these is the same as for machine roles. Look at prometheus_build_info on Prometheus itself for example.

We don't want to expose the full client lib because we want to add metrics to all of our projects and the hardest part about metrics is not the implementation, it is enforcing the naming conventions.

I can understand where you're coming from, however you're losing a lot by removing functionality and changing the API. For example you're encouraging all metrics to have labels, whereas in fact most metrics tend not to have labels, and losing the ability to perform related important performance optimisations.

How do you correlate something like prometheus_build_info for the other metrics collected?  One of the use cases is that we want to make sure when we are working on a new version or a PR/feature was merged, did it change the container start from from the previous version.

You can use group_left to copy over the label when you need it, without getting in the way of more general use cases.

@brian-brazil @juliusv Awesome, thanks a lot for the feedback!
(@juliusv: long time no see!)

Yeah, super excited to see this as well - does this mean we can expect Docker to export native Prometheus metrics? :)

Indeed :)
I'm really looking forward to get naming feedback and such. I'm trying to remember the conventions from Borgmon but it's been a while. I do remember however what a pain it was to not have strong conventions and the tragic errors that occurred when people misunderstood a metric's intent.

I'm really looking forward to get naming feedback and such.

I actually just wrote http://www.robustperception.io/on-the-naming-of-things/ which covers the basic syntactic issues, in addition to what's on the project website such as https://prometheus.io/docs/instrumenting/writing_exporters/.

I'm trying to remember the conventions from Borgmon but it's been a while. I do remember however what a pain it was to not have strong conventions and the tragic errors that occurred when people misunderstood a metric's intent.

Misunderstandings will always happen, but we can try to reduce them. My guideline is that a metric name should at least let someone make a good guess as to what it means.
Two of the biggest pains I found were more around not understanding instrumentation's intent by not having metrics inline, and using wrapper libraries around the core instrumentation libraries to make things "simpler". Both make it frustrating to use metrics to debug real world problems, as they can easily take what should have been 2 simple lines of code that's right where you're looking at and turn it into 200 spread across 10 files that produce less-valuable instrumentation.

cc @stevvooe

Thanks @brian-brazil @juliusv for the interest! We are currently exploring better Docker metrics across the board. For the most part, we are looking at maintaining solid types and consistent naming across Docker projects.
For the most part, the prometheus export model is sufficiently flexible to support a large number of metrics use cases. We have had issues in other areas.
In particular, the client has a lot of room for error. I'm not sure how we would go about flowing these upstream without asking for a rewrite.
@brian-brazil

You can use group_left to copy over the label when you need it, without getting in the way of more general use cases.

Do you have example?
We want to be able to compare the performance of different versions of docker running in a cluster of machines. This is an extremely common general question and I am not quite seeing how group_left can work with histogram summaries.

In particular, the client has a lot of room for error. I'm not sure how we would go about flowing these upstream without asking for a rewrite.

I'm not sure it's really possible to prevent errors as to be useful you have to be flexible. Encouraging good practices is about the most that's practical in my opinion. It's my experience that wrappers like this harm more than they help.

We want to be able to compare the performance of different versions of docker running in a cluster of machines.

Offhand it's some_metric group_left(version) on(instance) my_version_metric

Offhand it's some_metric group_left(version) on(instance) my_version_metric

Doesn't this assume that a single instance uses the same version? Won't this fall over if an instance is running multiple versions of the same software?

I'm not sure it's really possible to prevent errors as to be useful you have to be flexible. Encouraging good practices is about the most that's practical in my opinion. It's my experience that wrappers like this harm more than they help.

Unfortunately, the prometheus/client_golang has a number of design issues that will lead to future errors. Leaving this to "encouraging good practices" for a project the size of Docker will lead to a mess.
Here is non-exhaustive list of problems encountered already:

The type-aliasing of Opts is a very weird way of trying to represent inheritance. This is especially awkward when only two other metrics have a few metrics-specific options. It would be a lot easier if these were just one type and types with specific options required an extra argument or something. Having separate types here makes automating namespace/subsystem impossible since each metric has a different option type. This is probably the biggest reason for wrapping the API, as it makes creating a controlled namespace/subsystem hierarchy impossible.
The interface and method bloat makes approaching the package challenging. After some reading around the prometheus docs, it makes some sense, but concrete types would make it easier to work with.
The design is not goal-focused. Users of the API should be able to say, "I need a timer", "I need to report this value" and know exactly what to do.
The lack of units declaration will lead to mistakes, especially when there are such strong and subtle opinions about where to use _seconds, _count or _total. We believe we can make the package ensure the right thing if there with a bit of sugar: NewGauge("active", Units("foos")).
float64, everywhere. How can this possibly make sense when most metric values are fixed-point (bytes, timers, counts, etc.)? Will this cause errors when aggregating large metrics?
Foo and FooVec all over the place. What is a Vec? O, that is how you label things. And for some reason, FooVec has four methods that do the same thing.

I'm afraid the changes we'd suggest to get the client package under control would be akin to a re-write. Is the prometheus project willing to acknowledge and fix these issues? Are you willing to make the Go API compatibility breaks necessary to address these problems?
While some of these seem like nits, these kinds of issues are not easily addressable across hundreds of pull requests. We can solve these now and avoid thousands of hours of work. We can also address this issues without affecting the prometheus project or your API users.

Thanks for those details!
/cc @beorn7 for the client library questions. He's the master of the Go client library and currently reworking parts of it, so this might be of interest to him, and he's the best person to give answers about it. However, he's also on vacation this week, so he probably won't see this before next week.
As for the float64 question, we have an FAQ about why Prometheus stores everything as float64. We haven't had any problems with that in practice, and thus the client libraries also expose this type everywhere. Note that in our storage, float values compress really well if they are just integers.

Doesn't this assume that a single instance uses the same version?

Yes, this is a very reasonable assumption.

Won't this fall over if an instance is running multiple versions of the same software?

That shouldn't be possible as an instance is a process, but you should still be able to model that.

The type-aliasing of Opts is a very weird way of trying to represent inheritance

That's more an objection to Go itself.

It would be a lot easier if these were just one type and types with specific options required an extra argument or something.

I'm not sure that'd be of overall benefit. You'd be making it harder to create half the metrics and limiting the ability to add options in the future to the other half.

Having separate types here makes automating namespace/subsystem impossible since each metric has a different option type.

That sounds like procedurally generating metric names, which frustrates debugging in my experience. It's important to be able to go from a metric name to a piece of code, preferably with a standard find (I'm not the biggest fan of namespace/subsystem for this reason, they make grepping harder).
I'd tend towards keeping things simple, a linter may be easier to do.

The interface and method bloat makes approaching the package challenging. After some reading around the prometheus docs, it makes some sense, but concrete types would make it easier to work with.

To what exactly are you referring?

The design is not goal-focused. Users of the API should be able to say, "I need a timer", "I need to report this value" and know exactly what to do.

This is something that can be improved, the Go client is currently lacking various utility methods it should have for common use cases like timing.

We believe we can make the package ensure the right thing if there with a bit of sugar: NewGauge("active", Units("foos")).

I'm unsure how much that'd help. How would you handle things where the unit isn't immediately obvious?
The approach we're taking is to standardise on seconds, bytes etc. for units.

float64, everywhere. How can this possibly make sense when most metric values are fixed-point (bytes, timers, counts, etc.)? Will this cause errors when aggregating large metrics?

The math works out that it generally takes over a century to be a problem as a float64 has a 53 bit mantissa.

Foo and FooVec all over the place. What is a Vec? O, that is how you label things. And for some reason, FooVec has four methods that do the same thing.

Other clients chose to try and hide this distinction. The 4 methods are different, and can't be reduced due to Go not permitting function overloading and how it handles errors.

I'm afraid the changes we'd suggest to get the client package under control would be akin to a re-write. Is the prometheus project willing to acknowledge and fix these issues? Are you willing to make the Go API compatibility breaks necessary to address these problems?

There's currently a partial re-working in progress (see https://github.com/prometheus/client_golang/pull/214), but several of these are fundamental to Go and the problem domain. If you'd like to try write a better client, the guidelines are at https://prometheus.io/docs/instrumenting/writing_clientlibs/ but there's a lot of subtleties here and attractive nuisances to be avoided. API design is hard.

Thanks @stevvooe for the feedback. While the client library was written with a lot of feedback from Go programmers in mind, additional feedback is very much appreciated, especially to get an idea what matters most out there. That's important because the requirements quite often contradict each other, so that I had to choose the side I'll satisfy and the side that will feel left out. Sometimes, I tried to satisfy both sides of an argument, which sometimes works, sometimes stirs up even more controversy.

The type-aliasing of Opts is a very weird way of trying to represent inheritance.

It has nothing to do with inheritance. It's merely convenience because four out of six option structs happen to look the same. From all I have heard, the community pretty much settled on option structs  as the preferred way to implement named parameters with default values in Go and the option to add more parameters later without breaking the API, after some other approaches didn't work out.

This is especially awkward when only two other metrics have a few metrics-specific options. It would be a lot easier if these were just one type and types with specific options required an extra argument or something.

Pulling out the arguments specific for Summaries and Histograms would defeat the reason for having option types in the first place (namely to not have a large number of arguments on each function, to provide meaningful default values and argument naming that is visible in the call, and to allow adding more arguments later without breaking the API).
We could have one shared options struct for Counter and Gauge, but that would be first of all confusing (and some would find that quite awkward), and it would break once the options struct would behave differently (which is likely to happen during my current rework).
In conclusion, the current approach seems to be the least bad.

Having separate types here makes automating namespace/subsystem impossible since each metric has a different option type. This is probably the biggest reason for wrapping the API, as it makes creating a controlled namespace/subsystem hierarchy impossible.

The namespace/subsystem is a well-intended attempt of the previous author of the client library to guide users into structuring their metric naming. All those components are simply joined with _ to create the final metric name. It's nothing like "real" namespacing (which is a much more involved effort to be tackled throughout the stack in the mid or long term). When I took over the client library development, I wanted to keep the spirit of my predecessor, but I carefully designed things to keep namespace/subsystem optional. Thus, if you wish to automatically generate metric names, feel free to only use the Name parameter and generate the string it is set to by any means of your choice. (But please take @brian-brazil 's concerns into account for an informed decision.)

The interface and method bloat makes approaching the package challenging. After some reading around the prometheus docs, it makes some sense, but concrete types would make it easier to work with.

Could you elaborate on this? Counter, Gauge, Summary, and Histogram are mostly interfaces to be able to provide different implementations to swap in (e.g. for testing purposes, but also for the planned "no-op" implementations, see https://github.com/prometheus/client_golang/issues/196 ). Also, in the current implementation, all the "single value metrics" are backed by the same implementation (which is more implementation convenience than a design goal). If there is one thing that itches me, then it is the fact that the various Vec types are concrete and not interfaces.
Could you explain why interfaces are more difficult to work with? Go is designed to make working with interface types seamless.

The design is not goal-focused.

Unsurprisingly, I have to disagree.

Users of the API should be able to say, "I need a timer", "I need to report this value" and know exactly what to do.

Even without the (planned) utility methods @brian-brazil mentioned above, all those things are straight forward and easy to accomplish. A metric in the Prometheus universe has a name, a doc string, and potentially labels. You have to specify those somewhere. And timing is essentially a defered call to Observer or Add. There is very little room left to streamline this.
In this context, I see three things that need improvement:

Documentation (currently only godoc, we either have to make it way more comprehensive, or provide an instrumentation guide separately).
The utility functions @brian-brazil mentioned (I'm working on those).
The creation of "instant" metrics (with NewConstMetric and friends) is historically a late addition to the library and needs quite a bit of streamlining (which is also something I work on as we are speaking).

The lack of units declaration will lead to mistakes, especially when there are such strong and subtle opinions about where to use _seconds, _count or _total. We believe we can make the package ensure the right thing if there with a bit of sugar: NewGauge("active", Units("foos")).

Not much to add to what @brian-brazil said. In my perfect world, the unit would be part of the metric meta-data (same as the type or the doc string), and the Prometheus server would actually make use of the meta-data. That would be closer to your idea, but neither is true right now. So we recommend to have an applicable unit in the metric name. We want to keep the metric name transparent throughout the stack, i.e. the name you pick when instrumenting the code should be recognizable when you run queries. (I acknowledge that this is not entirely true at the moment as there are "magic" suffixes like _sum, _count, _bucket, triggered by the inability of the current Prometheus server to handle complex metric types as first class citizens. But we don't want to obfuscate the metric name generation even more. From that perspective, the namespace/subsystem is problematic, too. But as said, feel free to ignore and consider it legacy.)
Naming conventions are acceptable, even if they are not programatically enforced. (We could have a Prometheus linter one day. ;)

float64, everywhere. How can this possibly make sense when most metric values are fixed-point (bytes, timers, counts, etc.)? Will this cause errors when aggregating large metrics?

This has nothing to do with the client library. It's a deliberate design decision of Prometheus. If you wrapped this away, you would simply obfuscate the Prometheus data model.

Foo and FooVec all over the place. What is a Vec? O, that is how you label things.

Yes, vector is a pretty common term in the Prometheus ecosystem. When the naming in the client library was discussed, Vec turned out to be both short and meaningful. Without a certain level of understanding of the Prometheus data model, you won't be able to come up with meaningful instrumentation anyway.

And for some reason, FooVec has four methods that do the same thing.

That's a result of trying to satisfy different groups of users. There is the "pretty and safe" method of picking labels:
someVec.With(prometheus.Labels{"foo": "bar", "dings": "bums"})
And then there is the quick and dirty:
someVec.WithLabelValues("bar", "bums")
The latter has the problem that you have to know the order of labels and you can easily get it wrong. The former has quite a performance cost as it involves creating a map. Instrumentation is often in your hot code path, so performance might matter a lot. Therefore, me have to provide the latter way. We could drop the former, but it would remove the option to play safe outside of the hot code path.
That leaves us with two ways of picking labels. The other two are the result of a common Go idiom: To have one version of a method that returns an error, and another one that panics instead. The latter usually begins with a Must.... After careful consideration, I decided to not use the Must... naming in this case because the Must... version is the one used in 99% of cases and should be the short and easy-to-read one. However, since there are a few cases where you need to handle the error instead of panicking, I also had to provide the versions that return an error. Ideally, it would work like a native map access or a type assertion in Go, where the same syntax gives you both, depending on the number of return parameters. However, that's only possible as a  built-in in Go.
The conclusion here is: Goal-focused design lead to the (unfortunate) necessity to have four methods for the same thing.
Hope that help to provide context and to get an idea where I'm planning improvements and where the current state is a deliberate design decision.

We are interested in prom for metrics in our projects because of the output format.  It is very simple and robust and I can create a naive but working client in a few lines of code.
package main

import (
	"fmt"
	"sync/atomic"
	"time"
        "net/http"
)

var counter int64

func main() {
	http.HandleFunc("/metrics", func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "my_metric %d\n", counter)
	})
	go func() {
		for i := 0; i < 500; i++ {
			atomic.AddInt64(&counter, 1)
			time.Sleep(10 * time.Second)
		}
	}()
	http.ListenAndServe(":8080", nil)
}

We are still in the very beginning steps but the approach to client libs/abstractions with prom and the prom way or the highway makes us want to reconsider using it and look for something else.
We have some goals that we want to hit and we are still experimenting but arguing over how to populate that fprintf in an http handler is not helping us as we have barely started experimenting with things.
Who knows, maybe we will find out that we are totally wrong and use the underlying prom client directly but it too soon to tell, we just know that its not doing the job of enforcing namespaces/subsystems for us and that is why are wrapping some of it.

I don't believe that is a correct client, and likely has undefined behaviour due to accessing counter non-atomically. This stuff is tricky to get right, and we've already solved these problems in an efficient manner.
Choosing to use a different client is up to you, but may result in your code and metrics being harder to use for Prometheus users generally due to being non-standard.

That wasn't point in my 20 line example but lets all go back to doing something productive.  Thanks for the feedback all.


useFieldInitialValue with listField - Maximum update depth exceeded

I am not sure if this is a bug or just me doing something wrong.
I have the following setup:
interface Description {
    id?: string;
    language: string;
}

const descriptionsAtom = listField({
  value: [],
  builder: ({ id, language, context }: Description) => ({
    id: fieldAtom({ value: id }),
    languageCode: textField({ value: language }),
  }),
});

function FormComponent() {
    const apiResult = useSuspenseQuery(/* ... */);
    const initialDescriptions : Description[] = apiResult.data;
    useFieldInitialValue(descriptionsAtom, initialDescriptions);

   /* ... */
}

At runtime, when the backend response does not contain the id property, the following error occurs:
Maximum update depth exceeded. This can happen when a component repeatedly calls setState inside componentWillUpdate or componentDidUpdate. React limits the number of nested updates to prevent infinite loops.

As of v.3.2.3 useFieldInitialValue from form-atoms has a areEqual option. When I log the values that are compared in in this function, I see that one has id: undefined and the other (the value from the API) does not have the id property at all:

This mismatch causes the equality check to fail and thus an infinite loop is entered that causes the above React error.

Unfortunately I don't know anything about listField as it is not something I personally use. You'd have to file an issue there. But using a custom areEqual function should get you out of this problem.

listField is from @form-atoms which this repo is about, right? or am I wrong here?

Sorry missed that this was filed in field already

@schiller-manuel I think that I need to supply custom areEqual function in the hook of listfield as @jaredLunde indicates.
Also there is custom hydrate hook, which will be removed after the PR in form-atoms is merged so that might play a role here.

The issue happens, because everytime the listAtom.value is accessed, the new array is computed from the nested values. So currently, the shallow equal test with the initialValue is always false, and so new value is set until it crashes with stack overflow.
Here, I would like to avoid doing deepEquals for the values. There is easy fix for this. There is copy of the listAtom.value which has initialized atoms from the last init (initialFormListAtom). That way we can quickly check if the array changed. This is used to get the dirty flag.
We can compare the current formList with the initial, and if they are equal, we can safely return the initialValue originally passed to the useFIV hook:
  const valueAtom = atom(
    (get) => {
      const formLists = get(_formListAtom);

      if (arraysShallowEqual(get(initialFormListAtom), formLists)) {
        const maybeInitialValue = get(initialValueAtom);
        if (maybeInitialValue) {
          return maybeInitialValue;
        }
      }

      return formLists.map((formAtom) => {
        const formAtoms = get(formAtom);
        const { fields } = get(formAtoms.values);

        return fields as Value;
      });
    }
)

This will stop the infinite updates, but it introduces a limitation, that the builder won't be used for the initial items!
E.g. the id: undefined which was introduced from the builder, won't be in the submit data, unless you make the listAtom dirty.
Maybe somebody would rely on it to generate the id on the client there e.g.
import {v4} from "uuid";

const descriptionsAtom = listField({
  value: [],
  builder: ({ id, language, context }: Description) => ({
    id: fieldAtom({ value: v4() }), // generate ids on the client
    languageCode: textField({ value: language }),
  }),
});

But i would say that is ok, as the initialValue likely is from the database where items already have ids.
So, in the example above, the IDs would be added for newly inserted items in the list... also for the initial... but would be in the submit data, only if you really change the input...


Translating Views

Kindly let me know if any changes should be made.
I hope there was a cheat sheet for keywords like class, constructor ...etc so that all documents can be the same in Arabic.

@BoshraJaber Hello and thanks for your contributions, Yes there is a dictionary file here


Syntax error while using shortcuts

this code will compile error
extension DefaultsKeys {
    static let username = DefaultsKey<String?>("username")
    static let launchCount = DefaultsKey<Int>("launchCount")
}

i use Xcode 7.1

Extend DefaultsKeys, not DefaultsKey -- the whole purpose of the former is to work around this compiler limitation


Feature: Do not cache local, but cache remote files (option)

Could you provide more context/description? What would you like to see in this option, and where exactly would caching happen and not happen? What do you mean by local and remote files?

Can't talk about remote files, but as far as local files are concerned, the server still caches the loaded CSS stylesheet and doesn't update on refresh, even with the -c-1 flag.

By local do you mean files on the server or client?

Sorry, don't understand what you mean. By local I meant the files that are locally on my disk, so for example in the root directory it would be the css/index.css file.

The clarification is because those files are only local to http-server, not to the browser (the client). That doesn't sound quite right though because the server doesn't do any caching at all, are you sure it's not being cached in the browser?

Oh, yeah sorry, you're right. Manually force reloading with the cache updates the site, so it must be the browser caching it.

I think I meant: local files are the ones local to the http-server, remote files are the ones accessed via the --proxy option.

Oh, yeah sorry, you're right. Manually force reloading with the cache updates the site, so it must be the browser caching it.

https://github.com/http-party/http-server/issues/412
https://stackoverflow.com/questions/47470325/what-is-the-difference-between-max-age-0-and-max-age-1-in-cache-control


Fallback to remote.nabucasa.com when local connection is not available

If I'm at home, I'd prefer to use the local connection since is faster.
When I'm away, the app should automatically connect via nabucasa

Duplicate of #30 !? 🙏

Duplicate: #30

#30 didn't came up in my search probably because was already closed. I see it's implemented in #209, which is great. Thanks


Problem for fetching a gem from github

Hi ! I needed to install a gem through github but I have some issues with it... thank you for your help and your time!
Sorry for my bad english. I tried to write something readable but I'm not quite good for this...
Questions

What did you do?
I replace a gem written liken this gem 'nylas' with gem 'nylas', github: 'mechanicles/nylas-ruby', branch: 'update-rest-client', then I ran the command /home/hairen/.rbenv/versions/2.1.6/bin/bundle

What did you expect to happen?
I expected Bundler to install the gem nylas from this specific repo and branch

What happened instead?
Instead, what happened was : bundler seems to be in an infinite loop and keep trying to Fetching git://github.com/mechanicles/nylas-ruby.git then, as you can see in the backtrace report ruby raised an error stack level too deep

Have you tried any solutions posted on similar issues in our issue tracker, stack overflow, or google?

I tried to replace  mechanicles/nylas-ruby repo with the original  nylas/nylas-ruby and without any branch specify.
I tried to replace our custom source source 'https://gems.devtools.sparkup.fr' in our gemfile by the original one source 'https://rubygems.org'
I tried to use another cersion of bundler like bundler-1.15.0.pre.3 and 1.13.6
I tried to replace github: ... with git:  https://github.com/mechanicles/nylas-ruby
I tried with ruby 2.4.0
I tried in a new project generate with rails new
I also ask to a friend to try with his own clone of the project and same error happened

Have you read our issues document, https://github.com/bundler/bundler/blob/master/doc/contributing/ISSUES.md?
yes

Backtrace
SystemStackError: stack level too deep
  /home/hairen/.rbenv/versions/2.1.6/lib/ruby/gems/2.1.0/gems/bundler-1.14.6/lib/bundler/cli.rb:14

Environment
Bundler   1.14.6
Rubygems  2.2.3
Ruby      2.1.6p336 (2015-04-13 revision 50298) [x86_64-linux]
GEM_HOME  /home/hairen/.rbenv/versions/2.1.6/lib/ruby/gems/2.1.0
GEM_PATH  /home/hairen/.rbenv/versions/2.1.6/lib/ruby/gems/2.1.0:/home/hairen/.gem/ruby/2.1.0
Git       2.7.4
Platform  x86_64-linux
OpenSSL   OpenSSL 1.0.2g  1 Mar 2016
rbenv 1.1.0-2-g4f8925a

Bundler settings
gems.devtools.sparkup.fr

Gemfile
Gemfile
source 'https://gems.devtools.sparkup.fr'

ruby File.read('.ruby-version').strip

git_source(:github) do |repo_name|
  repo_name = "#{repo_name}/#{repo_name}" unless repo_name.include?("/")
  "https://github.com/#{repo_name}.git"
end

gem 'rails', '~> 4.1.4'                   # Bundle edge Rails instead: gem 'rails', github: 'rails/rails'
gem 'rails_12factor', group: :production  # For Heroku features
gem 'unicorn'                             # Unicorn as Web Server
gem 'rails_admin'                         # Administraion

# Sidekiq
gem 'sidekiq'
gem 'sinatra', require: nil

gem 'mongoid', '~> 5.1.0'                 # Use mongoid as the database for Active Record
gem 'bson_ext'

gem 'jbuilder', '~> 2.0'                  # Build JSON APIs with ease. Read more: https://github.com/rails/jbuilder
gem 'grape'                               # API Framework
gem 'hashie-forbidden_attributes'         # Disables the security feature of strong_params for Grape
gem 'grape_on_rails_routes'               # Display Grape Routes `rake grape:routes`

gem 'nylas', github: 'mechanicles/nylas-ruby', branch: 'update-rest-client'

# Testing
group :development, :test do
  gem 'rspec-rails', '~> 3.0'
  gem 'factory_girl_rails'
  gem 'database_cleaner'
  gem 'faker'
  gem 'figaro'
end
gem 'webmock', group: :test

# Add Terminal for Rails Debug
group :development do
  gem 'better_errors'
  gem 'binding_of_caller'
end

# App monitoring
gem 'newrelic_rpm'
gem 'rollbar', '~> 2.13.1'

# Code Coverage
# gem 'simplecov', :require => false, :group => :test
gem 'codecov', require: false, group: :test

gem 'bunny'
gem 'sparkup-rabbit', '1.7.1'
gem 'httparty'

# Gem deteclLanguage // Language detection gem, replace google cloud translate
gem 'detect_language'

gem 'sanitize'

gem 'email_validator'

gem 'rack-cors', require: 'rack/cors'

#gem for string comparaison
gem 'jaro_winkler'

# feature flagging
gem 'flipper'
gem 'flipper-ui'
gem 'flipper-mongo'

Can you please try with 1.15.0.pre.3? Thanks!

Reproduced, the issue is that the gemspec in that repo calls Bundler.setup, which will fundamentally cause infinite recursion, but we might be able to better come up with a way to show that error

diff --git a/lib/bundler/source/git/git_proxy.rb b/lib/bundler/source/git/git_proxy.rb
index 70b2d7e4f..228f7c639 100644
--- a/lib/bundler/source/git/git_proxy.rb
+++ b/lib/bundler/source/git/git_proxy.rb
@@ -92,6 +92,7 @@ module Bundler
         def checkout
           return if path.exist? && has_revision_cached?
           extra_ref = "#{Shellwords.shellescape(ref)}:#{Shellwords.shellescape(ref)}" if ref && ref.start_with?("refs/")
+          warn caller

           Bundler.ui.info "Fetching #{URICredentialsFilter.credential_filtered_uri(uri)}"

diff --git a/spec/install/gemfile/git_spec.rb b/spec/install/gemfile/git_spec.rb
index a53d96582..b33ce5c64 100644
--- a/spec/install/gemfile/git_spec.rb
+++ b/spec/install/gemfile/git_spec.rb
@@ -698,6 +698,26 @@ RSpec.describe "bundle install with git sources" do
     expect(the_bundle).to include_gems "rails 2.3.2"
   end

+  it "foo with a gemspec that calls Bundler.setup" do
+    build_git "foo"
+    update_git "foo" do
+      lib_path("foo-1.0").join("foo.gemspec").open("a") {|f| f.puts ".tap { require 'bundler'; Bundler.setup }"}
+    end
+
+    require 'timeout'
+    Timeout.timeout(2) do
+      install_gemfile! <<-G
+        source "file://#{gem_repo1}"
+        gem "foo", :git => "#{lib_path("foo-1.0")}"
+        gem "rails", "2.3.2"
+      G
+    end
+
+
+    expect(the_bundle).to include_gems "foo 1.0"
+    expect(the_bundle).to include_gems "rails 2.3.2"
+  end
+
   it "runs the gemspec in the context of its parent directory" do
     build_lib "bar", :path => lib_path("foo/bar"), :gemspec => false do |s|
       s.write lib_path("foo/bar/lib/version.rb"), %(BAR_VERSION = '1.0')

Hi ! Thank you for your quick anwser ! It's work great for me now :+1: ! I didn't try to install another gem from another repo... I should have..
I think I can close this issue, the problem is fixed for me...
Your solution to raise an error when it's happen is a good idea. It can save some time to people like me :smile:


issue-2753 bug fixed.(#2753)

What changes were proposed in this pull request
Issue Number: close #xxx

Brief change log

Verifying this change

This change is a trivial rework / code cleanup without any test coverage.
(or)
This change is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:

Does this pull request potentially affect one of the following parts

Dependencies (does it add or upgrade a dependency): (yes / no)

cc @wangsizhu0504 @lvshaokang PTAL, thx


CHANGELOG for 2.0.0

Out of interest,  what was the breaking change?

Mostly set a new limit of 100 chars to the string's length.
You can read about it on PR (https://github.com/zeit/ms/pull/89).

Thanks @yoavmmn


[WDR] Fix not extracting two of the same manifest url values

(Sometimes I hate it when technology is implemented like this in the first place: Link to a "alternative", but it's just the original)
IMPORTANT: PRs without the template will be CLOSED
Description of your pull request and other information
Some WDR videos produce the same "alternative" url value compared with "default".
If an example is required for this, here's one:
https://kinder.wdr.de/tv/die-sendung-mit-der-maus/av/video-krone-des-hieron-100.html
It doesn't make sense to have both analyzed by yt-dlp if the url is identical.
The best practice would be to actually implement this on higher level (-> WDR is part of the ARD network and for some reason I believe WDR might not be the only culprit guilty of this "technical crime" here, this is only a suspicion though, I do not have the time or willpower to do the research myself, but I'm trying to say: I invite others to check with "ARD Mediathek" [and related plugins] too)
However, fixing it for WDR works too and is a simpler task. (So for now, it makes me happy.)
I provide this code as a suggestion, the actual implementation can look different for all I care.
I just didn't want to open this as an issue about this, since I am more of a developer than most yt-dlp users.
I wanted to report the issue by providing a simple, possible solution that I have tested in my own evironment.
(The result of listing every format twice just confuses users who chose the quality manually.)
Template

Before submitting a pull request make sure you have:

[x] At least skimmed through contributing guidelines including yt-dlp coding conventions
[x] Searched the bugtracker for similar pull requests
[ ] Checked the code with flake8 and ran relevant tests

In order to be accepted and merged into yt-dlp each piece of code must be in public domain or released under Unlicense. Check all of the following options that apply:

[x] I am the original author of this code and I am willing to release it under Unlicense
[ ] I am not the original author of this code but it is in public domain or released under Unlicense (provide reliable evidence)

What is the purpose of your pull request?

[x] Fix or improvement to an extractor (Make sure to add/update tests)
[ ] New extractor (Piracy websites will not be accepted)
[ ] Core bug fix/improvement
[ ] New feature (It is strongly recommended to open an issue first)

Are these modified characters in the tests really being returned in that way, rather than ä/Ä?

@dirkf Eek, sorry about that, I'm quite sure I didn't intend to change that.
Must be some encoding issue with my editor or me editing something.
Also weird I didn't see that earlier. Will fix asap.

Okay, now we have to wait again, a bit...
See? 3rd time's a charm, when you haven't done too many contributions yet.

Pls add an example case to tests. Also update existing tests if possible.


Allow to override Docker and containerd systemd unit

Alternative implementation to #54 to override the systemd units for the Docker and containerd service.

@atosatto this works for me, though I would have done two things:

Add # {{ ansible_managed }} into each file (to make it obvious)
Maybe we should have added a test/scenario to confirm this behaviour? So e.g. we can also run it against other Docker versions and easily test and expand on it?

(Do you want a ticket? I'd send a PR too...) :D

@till these are both great ideas! Feel free to implement them both in a PR.


Task List More

[x] Additional markup is supported, including @mentions, #references, links, emphasis, and HTML tags.
[x] List syntax is required.

You can nest lists below, too!

[x] This item is completed.
[ ] This item is not complete.
github.com

new header

#1


Do not generate routes and tests by default

As titled

@mcollina  I think this is on meraki. We set the generator options here: https://github.com/platformatic/meraki/blob/main/src/main/generate.mjs#L142
So this overrides every "default config" and set always tests/plugin to true.
This stackable do not changes the defaults for the base generator, which is to set both to false: https://github.com/platformatic/platformatic/blob/main/packages/generators/lib/base-generator.js#L53
Going to do a PR on meraki for this.
cc'ing also @leorossi

Added the issue in meraki: https://github.com/platformatic/meraki/issues/706


Stop integration tests on first failure

Our set of integration tests take ~10 minutes to run on GHA. This can add up to a significant amount of waiting time when bug hunting. This PR updates the integration test command to stop after the first error is encountered to be able to cycle on fixes faster

think this is ok just for integration tests given they take longer, but how much information do we lose if there are multiple bugs?

@bfineran there's a bit of information loss, but the integration tests can be re-run locally to get the full scope of errors and the tradeoff for the time saved on cycling on a fix for integration tests seems worthwhile


ROLE assign not working in Snowflake with terraform

Hello Everyone,
I am new in terraform.
In TF file contains ROLE creation, USER creation, and Assign a role to USER when we run that file the first time its create USERS and ROLE successfully and throw an error like that ROLE does not exist
But when we run that file a second time it’s run successfully. So it assigns that role to a particular USER.
I attached the TF file as text.

a.txt

The problem here is that you are not telling terraform that the grants depend on the role creation. You either need to add a depends_on clause or use the attributes on the role resource itself so that terraform can see the actual dependency tree rather than hard coded strings

We are closing this issue as part of a cleanup described in announcement. If you believe that the issue is still valid in v0.89.0, please open a new ticket.


Could diffusion model work for n channels (n>3)?

Hello,
My question is as the title. Why I have n > 3 is because I use DCT signals to represent an image.
I tried to modify your Dataset class to incorporate my data and set calculate_fid = False. The loss decreased from ~0.9 to ~0.26 and didn't go down anymore, which showed poor results.
So it can't work for n channels where n > 3? Or I need to dig deeper into the codes?

Did you solve it, I also run into this problem. plz


DllReferencePlugin / DllPlugin does not respect file extensions found in manifest.json

I'm submitting a bug report
Let me know if I can submit a PR if this is accepted as an issue.
Webpack version:
1.13.1
Please tell us about your environment:
OSX 10.x
Current behavior:
DllReferencePlugin does not respect the extensions of the resources listed in manifest while resolving. When the vendor DLL library contains resources of various types (extensions) they are not accessible in the Consuming project where DllReferencePlugin is used.
// vendor.config ////////////
...
resolve: {
     extensions: ['', '.js', '.html']
},
plugins: [
    new webpack.DllPlugin({
        path: path.resolve('./vendor.manifest.json'),
        name: 'vendor_dll'
    }),
]
...

// vendor.manifest.json ////////////
{
  "name": "vendor_dll",
  "content": {
     "./view/elements/icon.js": 1,
     "./template/elements/tooltip.html": 2
  }
}

// app.config ////////////
...
resolve: {
        extensions: ['', '.js', '.html']
},
plugins: [
        new webpack.DllReferencePlugin({
            scope: 'vendor',
            manifest: require('./libs/vendor.manifest.json')
        }
]
...

// app.controller.js ////////////
...
      var iconView = require('vendor/view/elements/icon');
      var tooltipTemplate = require('vendor/template/elements/tooltip')
...

With this setup, attempts to build simply fails citing Module not found error.
Module not found: Error: Cannot resolve module 'vendor/template/elements/tooltip' in <file path>
The root cause seems to be these two points where extensions of the DLL nor the consuming app are never used while resolving resources from a manifest.
https://github.com/webpack/webpack/blob/master/lib/DllReferencePlugin.js#L19 - where the options or extensions information is not passed downwards to the DelegatedPlugin which funnels it down to DelegatedModuleFactoryPlugin.
https://github.com/webpack/webpack/blob/master/lib/DelegatedModuleFactoryPlugin.js#L15 - where extensions are expected and when not found uses the default limited set of extensions (["", ".js"])
Expected/desired behavior:

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem along with a gist/jsbin of your webpack configuration.
Code sample is shown above. If a full example app is needed. Please let me know.
What is the expected behavior?
Since resolve.extensions are defined in both DLL and the app - I expect require('vendor/template/elements/tooltip') to resolve normally since HTML is allowed in the extensions.
What is the motivation / use case for changing the behavior?
When DLLs pack resources of various extensions, they are not available in the consuming app.
Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]
Build time issue.
Language: [all | TypeScript X.X | ES6/7 | ES5 | Dart | ...]
ES5

Yep, it looks like I missed passing this down to the impl.

I think the best solution is to add an extensions option to the DllReferencePlugin and pass it down. Do you want to do a PR?

Thanks for confirming. Sure I will, shortly.

PR merged

I think I am seeing this issue in Webpack 2.3.2. My webpack.config.js has the extensions option set on both the resolve.extensions and in the DllReferencePlugin options but my .ts files are not resolving. Any thoughts?


CuDNN v7 for Cuda 9.0 not working

I installed Cuda 9.0 and CuDNN v7, but I keep getting this error when trying to use Torch7's cudnn package.
/home/ubuntu/torch/install/bin/luajit: /home/ubuntu/torch/install/share/lua/5.1/trepl/init.lua:389: /home/ubuntu/torch/install/share/lua/5.1/trepl/init.lua:389: /home/ubuntu/torch/install/share/lua/5.1/cudnn/ffi.lua:1603: 'libcudnn (R5) not found in library path.
Please install CuDNN from https://developer.nvidia.com/cuDNN
Then make sure files named as libcudnn.so.5 or libcudnn.5.dylib are placed in
your library load path (for example /usr/local/lib , or manually add a path to LD_LIBRARY_PATH)

Alternatively, set the path to libcudnn.so.5 or libcudnn.5.dylib
to the environment variable CUDNN_PATH and rerun torch.
For example: export CUDNN_PATH="/usr/local/cuda/lib64/libcudnn.so.5"

stack traceback:
        [C]: in function 'error'
        /home/ubuntu/torch/install/share/lua/5.1/trepl/init.lua:389: in function 'require'
        neural_style.lua:350: in function 'setup_gpu'
        neural_style.lua:53: in function 'main'
        neural_style.lua:601: in main chunk
        [C]: in function 'dofile'
        ...untu/torch/install/lib/luarocks/rocks/trepl/scm-1/bin/th:150: in main chunk
        [C]: at 0x00405d50
ubuntu@ip-Address:~/neural-style$

Using this: export CUDNN_PATH="/usr/local/cuda-9.0/lib64/libcudnn.so.7"
Results in:
Found Environment variable CUDNN_PATH = /usr/local/cuda-9.0/lib64/libcudnn.so.7/home/ubuntu/torch/install/bin/luajit: /home/ubuntu/torch/install/share/lua/5.1/trepl/init.lua:389: /home/ubuntu/torch/install/share/lua/5.1/trepl/init.lua:389: /home/ubuntu/torch/install/share/lua/5.1/cudnn/ffi.lua:1618: These bindings are for CUDNN 5.x (5005 <= cudnn.version > 6000) , while the loaded CuDNN is version: 7003
Are you using an older or newer version of CuDNN?
stack traceback:
        [C]: in function 'error'
        /home/ubuntu/torch/install/share/lua/5.1/trepl/init.lua:389: in function 'require'
        neural_style.lua:350: in function 'setup_gpu'
        neural_style.lua:53: in function 'main'
        neural_style.lua:601: in main chunk
        [C]: in function 'dofile'
        ...untu/torch/install/lib/luarocks/rocks/trepl/scm-1/bin/th:150: in main chunk
        [C]: at 0x00405d50

In which path did you run the code below?!
git clone https://github.com/soumith/cudnn.torch.git -b R7 && cd cudnn.torch && luarocks make cudnn-scm-1.rockspec

I have the same problem and I couldnt solve it yet!
I successfully installed my nvidia driver and cuda 9.1. I also did everything that is needed to install cudnn 7.1. but when I run my code, I face the following error:
/////////////////////////////////////////////////////////////////
'libcudnn (R7) not found in library path.
Please install CuDNN from https://developer.nvidia.com/cuDNN
Then make sure files named as libcudnn.so.7 or libcudnn.7.dylib are placed in
your library load path (for example /usr/local/lib , or manually add a path to LD_LIBRARY_PATH)
Alternatively, set the path to libcudnn.so.7 or libcudnn.7.dylib
to the environment variable CUDNN_PATH and rerun torch.
For example: export CUDNN_PATH = "/usr/local/cuda/lib64/libcudnn.so.7"
/////////////////////////////////////////////////////////////////
My .bashrc file containes:
/////////////////////////////////////////////////////////////////
export PATH=/usr/local/cuda-9.1/bin${PATH:+:${PATH}}
export LD_LIBRARY_PATH=/usr/local/cuda-9.1/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
export CUDA_HOME=/usr/local/cuda-9.1
export CUDNN_PATH=/usr/local/cuda-9.1/lib64/libcudnn.so.7
/////////////////////////////////////////////////////////////////
and I'm sure that the libcudnn.so.7 file exists in /usr/local/cuda-9.1/lib64
Any solution ?! :(
System Information:
Os: Ubuntu 18.04
Nvidia driver version: 390.48

You can change the called cudnn version executing the following command in the prompt:
export CUDNN_PATH="/usr/local/cuda/lib64/libcudnn.so.X"
where the X is your current cudnn version, in my case version 7.

Using this: export CUDNN_PATH="/usr/local/cuda-9.0/lib64/libcudnn.so.7"
Results in:
Found Environment variable CUDNN_PATH = /usr/local/cuda-9.0/lib64/libcudnn.so.7/home/ubuntu/torch/install/bin/luajit: /home/ubuntu/torch/install/share/lua/5.1/trepl/init.lua:389: /home/ubuntu/torch/install/share/lua/5.1/trepl/init.lua:389: /home/ubuntu/torch/install/share/lua/5.1/cudnn/ffi.lua:1618: These bindings are for CUDNN 5.x (5005 <= cudnn.version > 6000) , while the loaded CuDNN is version: 7003
Are you using an older or newer version of CuDNN?
stack traceback:
        [C]: in function 'error'
        /home/ubuntu/torch/install/share/lua/5.1/trepl/init.lua:389: in function 'require'
        neural_style.lua:350: in function 'setup_gpu'
        neural_style.lua:53: in function 'main'
        neural_style.lua:601: in main chunk
        [C]: in function 'dofile'
        ...untu/torch/install/lib/luarocks/rocks/trepl/scm-1/bin/th:150: in main chunk
        [C]: at 0x00405d50

Edit:
Using this worked:
git clone https://github.com/soumith/cudnn.torch.git -b R7 && cd cudnn.torch && luarocks make cudnn-scm-1.rockspec

THX, it works for me!

Using this: export CUDNN_PATH="/usr/local/cuda-9.0/lib64/libcudnn.so.7"
Results in:
Found Environment variable CUDNN_PATH = /usr/local/cuda-9.0/lib64/libcudnn.so.7/home/ubuntu/torch/install/bin/luajit: /home/ubuntu/torch/install/share/lua/5.1/trepl/init.lua:389: /home/ubuntu/torch/install/share/lua/5.1/trepl/init.lua:389: /home/ubuntu/torch/install/share/lua/5.1/cudnn/ffi.lua:1618: These bindings are for CUDNN 5.x (5005 <= cudnn.version > 6000) , while the loaded CuDNN is version: 7003
Are you using an older or newer version of CuDNN?
stack traceback:
        [C]: in function 'error'
        /home/ubuntu/torch/install/share/lua/5.1/trepl/init.lua:389: in function 'require'
        neural_style.lua:350: in function 'setup_gpu'
        neural_style.lua:53: in function 'main'
        neural_style.lua:601: in main chunk
        [C]: in function 'dofile'
        ...untu/torch/install/lib/luarocks/rocks/trepl/scm-1/bin/th:150: in main chunk
        [C]: at 0x00405d50

Edit:
Using this worked:
git clone https://github.com/soumith/cudnn.torch.git -b R7 && cd cudnn.torch && luarocks make cudnn-scm-1.rockspec

THX, it works for me!

This does not work for me. Im on ubuntu 18.02 cuda 9.2 and cudnn 7
Any ideas?

Using this: export CUDNN_PATH="/usr/local/cuda-9.0/lib64/libcudnn.so.7"
Results in:
Found Environment variable CUDNN_PATH = /usr/local/cuda-9.0/lib64/libcudnn.so.7/home/ubuntu/torch/install/bin/luajit: /home/ubuntu/torch/install/share/lua/5.1/trepl/init.lua:389: /home/ubuntu/torch/install/share/lua/5.1/trepl/init.lua:389: /home/ubuntu/torch/install/share/lua/5.1/cudnn/ffi.lua:1618: These bindings are for CUDNN 5.x (5005 <= cudnn.version > 6000) , while the loaded CuDNN is version: 7003
Are you using an older or newer version of CuDNN?
stack traceback:
        [C]: in function 'error'
        /home/ubuntu/torch/install/share/lua/5.1/trepl/init.lua:389: in function 'require'
        neural_style.lua:350: in function 'setup_gpu'
        neural_style.lua:53: in function 'main'
        neural_style.lua:601: in main chunk
        [C]: in function 'dofile'
        ...untu/torch/install/lib/luarocks/rocks/trepl/scm-1/bin/th:150: in main chunk
        [C]: at 0x00405d50

Edit:
Using this worked:
git clone https://github.com/soumith/cudnn.torch.git -b R7 && cd cudnn.torch && luarocks make cudnn-scm-1.rockspec

THX, it works for me!

This does not work for me. Im on ubuntu 18.02 cuda 9.2 and cudnn 7
Any ideas?

It also does not work for me.    Im on ubuntu 16.04 cuda 9.0 and cudnn 7.4.2
Found Environment variable CUDNN_PATH = /usr/local/cuda/lib64/libcudnn.so.7/home/user/torch/install/bin/luajit: /home/user/torch/install/share/lua/5.1/trepl/init.lua:389: /home/user/torch/install/share/lua/5.1/trepl/init.lua:389: /home/user/torch/install/share/lua/5.1/cudnn/ffi.lua:1618: These bindings are for CUDNN 5.x (5005 <= cudnn.version > 6000) , while the loaded CuDNN is version: 7402   Are you using an older or newer version of CuDNN? stack traceback: 	[C]: in function 'error' 	/home/user/torch/install/share/lua/5.1/trepl/init.lua:389: in function 'require' 	TestRDN.lua:3: in main chunk 	[C]: in function 'dofile' 	...user/torch/install/lib/luarocks/rocks/trepl/scm-1/bin/th:150: in main chunk 	[C]: at 0x00405d50

@THUHoloLab
Hi,
I have met the same problem as yours.
Have you solved it?
Thanks


Special characters incorrectly rendered in AutoChoices

(Original issue 27 created by {u'display_name': u'altmany', u'account_id': None} on 2012-09-30T10:21:06+00:00)
What steps will reproduce the problem?
1.  What do you see instead?
I expect to see **** in the AutoChoice drop-down; instead I see \*\*\*\*

What version of the product are you using? On what operating system?
4.4

Please provide any additional information below.

Original issue reported on code.google.com by altmany on 2012-09-30 10:21:06

(Original issue 27 last updated on 2012-09-30T10:21:06+00:00)
(Issue automaticaly closed due to status in Bitbucket: invalid)

(Original comment by {u'display_name': u'coderazzi coderazzi', u'account_id': u'557058:790eb198-2ae4-49b4-b920-8d654aa86b3f'} on 2012-10-03T01:10:19+00:00)
Hi, the issue here is the presence of special parser characters in the cell. The default
parser handles '*' as a wildcard, meaning 'any character(s)'; if the user wants to
use that character, it will require escaping (\*).

The same logic happens for the special characters at the beginning: = > < ~ are used
to define bigger than, lower than, etc, and the user must escape them if required.

There are, anyway, two ways to avoid this behavior:

1- Define the filter editor as non editable. In this case, the user can only choose
one option in the combobox, so there is no parser involved => no need to escape any
special characters.

2- Implement your own parser, using other special characters than '*', or directly
avoiding wildcards. Note that the net.coderazzi.filters.IParser interface already covers
this scenario, and requires implementing a method 'escape'.

I would have preferred finding a solution that required no escaping, but its is obviously
a design requirement: if you need wilcards, using the associated characters requires
escaping. And because the user can edit the content of the choices in the editor combobox,
there is no middle-way solution (where the combobox choices are not escaped).

Because this is a design issue, I can only mark the issue as invalid (ie, is not a
bug).

Cheers,

 Lu

Original issue reported on code.google.com by coderazzi on 2012-10-03 01:10:19

(Original comment by {u'display_name': u'altmany', u'account_id': None} on 2012-10-03T07:20:35+00:00)
agreed - thanks for the details

Original issue reported on code.google.com by altmany on 2012-10-03 07:20:35


Boolean Status

I use the adapter to display various information in my visualization.
For the topics lowBattery, offline and upgradable I would like to have another Boolean data point. This should show true if a device appears in the list.

Added it to the to-do and will be implemented in the next few days

added in v2.3.0


Seems wasting 8 bytes per chunk? Didnt get the point of returning &found->next

Hi:
Nice job!
Got a bit question though. What’s the point of returning &found->next to user in malloc? The whole chunk size is still “sizeof(node_t) + size + sizeof(footer)”, which means although user get 8 bytes in advance, they still didn’t utilize the whole chunk (access finishes at size - 8). Why not just return ‘head + szieof(node_t)’, which simplifies the trick?

I think it's a mistake


python312Packages.monai: 1.3.2 -> 1.4.0

Routine update changelog.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/4770

Result of nixpkgs-review pr 349131 at 0c18fec6 run on aarch64-darwin 1

:white_check_mark: 2 packages built:

python311Packages.monai
python312Packages.monai


Handle AttributeError in create_from under device_specification.py

Handle AttributeError in create_from under device_specification.py (#2488)

Summary

Raise PulseError when calling create_from on a device that does not support pulse.

Details and comments
create_from in device_specification.py first tries to set the buffer.
However, if the backend does not support pulse it does not have a
default buffer setting which results in an AttributeError. This
commit adds a check to ensure that the backend supports pulse. A
PulseError is raised if the backend does not support pulse.

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

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

@taalexander Sounds good.


Update Bibtex

Thanks for the great work for implementing CenterPoint in mmdet framework!

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


Fix markdown highlighting in xcschemes.diagnostics descriptions

While going through the documentation, I noticed two missing ` characters. This pull request adds the missing ` characters and fixes the markdown highlighting for those values.

You'll need to fix the source of the docs, in the code as well. This will be in xcschemes.bzl.

Good catch. Fixed! :)


Update vsts-docs with more examples of adding/removing permission  bits

The line Here, --allow-bit/--deny-bit could be a single permission bit or addition of multiple permission bits. is unclear. Do you just add the permission bits together to get the value you want?
e.g if you apply a value of 7 for Releasemanagement, would you be able to view, edit and delete releases?
Some examples would be really helpful

Makes sense - could we add more examples to both https://docs.microsoft.com/en-us/azure/devops/cli/permissions?view=azure-devops and command help. We can also link the doc in the command help for users to learn more about permission help.


How to get error object?

When something goes wrong with FB they throw an error with the status code, type etc. How can I access that error object? Right now when I catch it, it's giving me an error with string. Not getting the error object properly

Hi @gijo-varghese ,
What did you get when you log the error you caught?
We use the axios-error package to prettify the message output of the error instances so when you console.log(error) it can be displayed better. You can still access the config, request and response properties of the error instance.

When something goes wrong, FB returns an error object with the error code, type etc (https://developers.facebook.com/docs/facebook-login/access-tokens/debugging-and-error-handling#errors). Since you're prettifying it, it's not easy to get that error object. It would be great if you return the axios object itself, so we check the status code, parse the error object and so much more.

I admit that we could have better documentation on it. The error code from Facebook is in the response body so when you do error.response.data you should see them.
If you check the source code you can see that we try to preserve almost everything from axios and only override the inspect() method.
Returning the raw error object sounds good, but as we provide custom construction we might need to think a little more.

Cool. You should document a little more about the error object.
I've tried consoling the error object. But I couldn't find it. Let me try again.

I'll keep this open and tag it as doc.


Support for "resume" offset?

Since kt sets a consumer group id, it should be possible to simply start reading from a given TopicPartition based on the offset where it stopped reading the last time it was run for that username? (Assuming that kt commits offsets as it reads)
Something like kt consume -offsets all=resume would be handy.

@gengel sorry for the delay - but i just pushed a version that supports a resume keyword, similar to newest and oldest. use go get -u github.com/fgeller/kt if you want to test it now, or let me know - it might be a couple of days before i package a release.

Woohoo, this is wonderful news!