Declaration file not working

🔎 Search Terms
"d.ts", "d.ts file", "d.ts var", "d.ts declare var"
🕗 Version & Regression Information
New to typescript
⏯ Playground Link
No response
💻 Code
Inside 'index.d.ts' file, following the same structure as 'Function' (lib.es5.d.ts - lines 275-319):
interface Test<T> {
  prototype: any;
}

interface TestConstructor {
  (value: string): Test<T>;
  readonly prototype: Test<T>;
}

declare var Test: TestConstructor;

Tried making the TestConstructor generic too (TestConstructor), but that made no difference.
Inside test-lib.ts file:
  test(): void {
    const foo: Test<Foo> = (value) => {

    }
  }

🙁 Actual behavior
Typescript complains about the value being an 'any' type inside the test() function

🙂 Expected behavior
Expected TypeScript to know that value is a string, given it's defined in the 'index.d.ts' file.  When looking for the type definition, it finds it, just like it does for 'Function'
Test:

Function:

Additional information about the issue
No response

You need to turn off skipLibCheck if you're hand-authoring .d.ts files. There's no T in scope there.

Doesn't that diminish type-system accuracy?  That doesn't seem to be a good route.
In hopes to track down the issue, I even removed all generics from the 'Test' type, but that didn't make any difference.
interface Test {

  prototype: any;
}

interface TestConstructor {
  (value: string): Test;
}

declare var Test: TestConstructor;

No difference, still seeing:

The code is still wrong. You need const foo: TestConstructor =  if you're expecting a contextual type there.

The code following the exact same structure as 'Function', located in lib.es5.d.ts - lines 275-319.

Are you saying the lib.es5.d.ts file is wrong too?

It looks like this is a question rather than a bug report. This issue tracker is for tracking bugs and active work on TypeScript itself, rather than a general forum for programmers using TypeScript to get help or ask questions.
You can ask questions on sites like Stack Overflow. We are not able to provide one-on-one support on the issue tracker. Please read the issue template carefully - it has important information on what kinds of reports can be acted on here, as well as links to useful TypeScript resources. Thanks!

Respectfully disagree.  This is definitely a bug, given our files don't follow suit with how TypeScript files operate.

Given there is no difference between these 2, there is definitely a bug involved.

Function is a special global type that has effects on function expressions. TestConstructor isn't.

You have almost certainly not found a bug that hundreds of thousands of other developers missed over the course of the last decade. Can you just post a full sample of what you're trying to do?

You have the relevant code.  Given you're a development lead for typescript, it should be easy for you.  Why is 'Test' not treated the same way as 'Function'?
By the way, I have written 100s of libraries, many of which are used by 3 Fortune 500 companies, over my 30+ years of being a developer.  Never did I poke fun at developers who asked questions.  I find your tone very offensive.

Completed?  Is that how you all handle bugs?  No wonder the development community dislikes typescript.

I'm not able to help any further here without the requested self-contained code sample. I've already indicated two different fixes you needed to make to have the code be correct.

The first "fix" diminishes type-system accuracy.  Not really a fix, now is it?
The second "fix" isn't a fix.  You're telling me that I have to use the 'TestConstructor' instead.  Why doesn't the 'var' approach work, like it does with 'Function'?
Please don't 'complete' the issue, until the issue is actually complete.
There is something functioning differently in my code, even though it's a straight copy of TypeScript's code.  This is a bug.

I appreciate your help, but is there another "lead" developer who actually knows the code?
Never have I told a developer, that uses libraries that I've created, that they have to provide full working code.
Why does the 'declare var Function: FunctionConstructor' work for 'Function' but doesn't for 'Test'?

Here's some code that does what it seems like you're trying to do
interface MyFunction {
    (obj: MyObject): number;
}

interface MyObject {
    handler: MyFunction;
    count: number;
}

class Foo {
    func() {
        const p: MyFunction = obj => {
            return obj.count
        }
    }
}

That doesn't touchbase on why 'declare var Function: FunctionConstructor' works for 'Function' but doesn't for 'Test'.  It should work the same for every interface/type.  There shouldn't be special cases -- special cases is just another term for bad/buggy code.
Not to mention, if I extend MyFunction, then every instance of MyFunction would have to have the extension explictly given.
This is not the case with 'Function'.  I can extend 'Function' without it breaking the original interface.  For example:
declare global {
  interface Function {
    and<T>(fn?: Function): Function;
  }
}

@MartinJohns, if you're reading this, your "reactions" are uncalled for.  If you don't have anything of substance, move on.  There used to be a time developers had respect for each other.

I already told you that the global type Function (and by transitivity, FunctionConstructor) is special. You can't write a user type that has the some effect as Function because Function is a special global type that relates to function expressions. The only reason that type exists is to provide that special behavior. It is not something that you can copy and get identical behavior from, because it is special, because it is the type that all function expressions implicit have. It is special and you cannot copy it verbatim with identical effect.
https://www.typescriptlang.org/docs/handbook/2/functions.html#function

"It is special and you cannot copy it verbatim with identical effect."
That makes no sense, if the code is copied "verbatim", it should operate exactly the same...  that's generally how code works.  Is the 'Function' interface defined outside of the code, or does the compiler treat the 'Function' interface differently when compiling?

Every programming language has types like these. You can't write a struct type in C that has the same semantics as void*.

Given the 'Constructor' is used in TypeScript for Array, Math, Number, etc., are you saying that developers can't create an equivalent approach?
Are developers not allowed to use: "declare var Array: ArrayConstructor", or "declare var Number: NumberConstructor", etc., for their own types?

In TypeScript we have to be able to answer questions like "Is it legal to write [1, 2,3].sort() ?"
So we have to be able to know if there's a sort property on [1, 2, 3]
Well, what defines that? We could hardcode into the compiler the list of properties of array literals, but then you'd have no way to talk about that list of properties, nor modify it if something changes
Instead, the sensible answer is to make a special type called Array<T> that defines what shape array literals have. Then, the developer can refer to that type, augment it, or otherwise inspect it.
The same thing happens for Function, which has roughly the same relation to function expressions as interface Array<T> has to array literals
You can certainly write code like that but you do actually have to understand what it does and what the relation of the special global types are to their corresponding constructors

"...special type called Array..."
Special type?  Isn't that just a generic array?  Nothing "special" about that.  Generics have been around for a long time now.
Still doesn't explain why the Constructor approach is what seems to be preferred by the TypeScript developers, but is unavailable for regular developers, nor does it explain why copying the code "verbatim" doesn't produce the same results.

Odd, I supplied the code.  Here it is again:
interface Test {

  prototype: any;
}

interface TestConstructor {
  (value: string): Test;
}

declare var Test: TestConstructor;

I'm almost ready to give up on this, as I'm able to extend 'Function' with the 'and' method without issue.  Doesn't speak highly about type safety (restricting the extension method to my type, not the function type), but then again, you had already suggested that I "skipLibCheck", so I take it type-system accuracy isn't high on the list for TypeScript developers.
From what I see online (stack overflow, etc.), this is why so many developers warn the community to stay away from TypeScript.  The documentation is worse than Java's (lol), and trying to do something "simple" ends up being a nightmare.  Too many times, I've read developers saying they had to produce hacky code to get it to work "properly".

In extensions.ts file:
declare global {
  interface Function {
    and<T>(source?: ISpecification<T>): ISpecification<T>;
  }
}

In specification.ts file:
export interface ISpecification<T> {
  (root: Root<T>, query: CriteriaQuery<T>, builder: CriteriaBuilder): Predicate;
}

In service.ts file:
const mergedSpecification: ISpecification<WeatherForecast> = specification1.and(specification2);

Sad thing is, this works.  But as stated before, 'and' is inside the 'Function' interface.

You're expecting spooky action at a distance here. There's no relationship between Test and TestConstructor in this code. Writing declare var Test: TestConstructor doesn't do anything at all.
In the line const foo: Test, Test refers only to the type Test (which only has a prototype property, no call signatures, thus implicit any). There's no special sauce that makes Foo and FooConstructor be related -- it doesn't even have this effect in the global scope either.
I really recommend reading something like the TypeScript Handbook to get a basic understanding of the relationship between types and values. The global scope declarations are quite complex, spread across multiple files, and written in a special way to allow for easier interface merging. You won't have a good time trying to learn the language by copying these declarations without understanding them.

No relationship between 'Test' and 'TestConstructor'?   Doesn't the "declare var Test: TestConstructor" create this relationship?  If not, why do the TypeScript developers use this approach?

No relationship between 'Test' and 'TestConstructor'? Doesn't the "declare var Test: TestConstructor" create this relationship

declare var Test: TestConstructor declares the existence of a variable called Test with the type TestConstructor. That's it. End of list. Nothing else. People really like languages like TypeScript that don't do spooky action at a distance.
You're expecting that at const foo: Test, Test gets looked up as the value Test (thus resolving to the variable), and then that to go to the output of the constructor function, and for that to be consulted instead. But TypeScript has straightforward semantics: Test refers simply to the type Test, which you declared as interface Test { prototype: any }.
The global types like Array and Function define three things:

The types themselves which are the types of the corresponding values (Function)
The types of the constructors which create them (FunctionConstructor)
The value that is the global variable you see in expression code (var Function: FunctionConstructor)

Not sure if you saw the screenshot above, but when I click on "Go to Definition" for "Test", VS shows:

If the interface is the only definition, then why do both the interface and variable show up as definitions in VS?
As asked before, should this bug be submitted to the VS developers instead?

"Find All References" intentionally looks for both value and type meanings of the same identifier since it's generally more useful to see more references rather than fewer. This behavior is due to user feedback and is intentional.

"Find All References" is separate from "Go to Definition":

I was referring to "Go to Definition".
Just for laughs, I added another declaration right above the 'TestLib' class:

Surely if what you were saying is correct, 'Test' should show up 3 times when I "Go to Definition", right?

Yet, it doesn't.

"Go to Definition" shows you all definitions of the identifier too. Imagine if you had written
export { Test }

you'd be exporting both the type and value meanings of Test, which are located at different places. Rather than having "Go Definition" show you different results depending on where you invoke it, which would be confusing, we consistently show all definitions of the specified identifier.

Just added that.

Made 0 difference, VS still only shows the 2 "definitions" when clicking on "Go to Definition", and it still doesn't even pick up the 3rd declaration I added directly above the 'TestLib' class (screenshot above)

I can't guess what the rest of your code is, nor do I enjoy transcribing screenshots. Please paste the whole contents of the file, what you invoked where, and I can check it. Thanks!

The TypeScript I provided IS what is in the file, not sure what else you're looking for.  I tried making it as simple as possible, just for this purpose.
Steps to reproduce what I have:

Create a new project in VS
Add a ts file with the following:

interface Test {

  prototype: any;
}

interface TestConstructor {
  (value: string): Test;
}

declare var Test: TestConstructor;

Add another ts file with the following:

class TestLib {
  test(): void {
    const foo: Test = (value) => {

      ...
    }
  }
}

That behavior was explained earlier. I think we've covered everything here. Please log a new issue if you have something actionable.


sonoff.fan

i have problem with this log, after updates
Unable to prepare setup for platform sonoff.fan: Platform not found (cannot import name 'SPEED_LOW' from 'homeassistant.components.fan' (/usr/src/homeassistant/homeassistant/components/fan/init.py)).

#725


Error: Missing required datasets 'levels' and 'values' with h5ad2rds.R

Hi
I have this error running the h5ad2rds.R file to convert Anndata to RDS.
Rscript ~/Projects/SpatialTranscriptomics/stereoseq/stereoseq_brain_mouse_001/rscript/h5ad2rds.R --infile ./adjusted_seurat_out.h5ad --outfile ./adjusted_seurat_out.rds

Attaching package: ‘dplyr’

The following objects are masked from ‘package:stats’:

    filter, lag

The following objects are masked from ‘package:base’:

    intersect, setdiff, setequal, union

Attaching SeuratObject
Seurat v4 was just loaded with SeuratObject v5; disabling v5 assays and
validation routines, and ensuring assays work in strict v3/v4
compatibility mode
Registered S3 method overwritten by 'SeuratDisk':
  method            from
  as.sparse.H5Group Seurat
Warning: Unknown file type: h5ad
Creating h5Seurat file for version <IP_ADDRESS>00
Adding X as data
Adding X as counts
Adding meta.features from var
Adding X_pca as cell embeddings for pca
Adding X_umap as cell embeddings for umap
Adding spatial as cell embeddings for spatial
Adding gene_exp_leiden to miscellaneous data
Adding hvg to miscellaneous data
Adding raw_cellname to miscellaneous data
Adding raw_counts to miscellaneous data
Adding raw_genename to miscellaneous data
Adding sn to miscellaneous data
[1] "Finished! Converting h5ad to h5seurat file at:"
[2] "./adjusted_seurat_out.h5seurat"
[1] "h5seurat time consuming: 233.897"
Validating h5Seurat file
Initializing Spatial with data
Adding counts for Spatial
Adding feature-level metadata for Spatial
Error: Missing required datasets 'levels' and 'values'
Execution halted

My Rsession :
R version 4.2.3 (2023-03-15)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.04.6 LTS

Matrix products: default
BLAS:   /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.9.0
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.9.0

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
 [3] LC_TIME=fr_FR.UTF-8        LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=fr_FR.UTF-8    LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=fr_FR.UTF-8       LC_NAME=C
 [9] LC_ADDRESS=C               LC_TELEPHONE=C
[11] LC_MEASUREMENT=fr_FR.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] tools     stats     graphics  grDevices utils     datasets  methods
[8] base

other attached packages:
[1] stringr_1.5.0         hdf5r_1.3.10          SeuratDisk_<IP_ADDRESS>21
[4] argparser_0.7.2       ggplot2_3.4.1         SeuratObject_5.0.1
[7] Seurat_4.3.0          rjson_0.2.21          dplyr_1.1.0

loaded via a namespace (and not attached):
  [1] nlme_3.1-160           matrixStats_0.62.0     spatstat.sparse_3.0-0
  [4] bit64_4.0.5            RcppAnnoy_0.0.20       RColorBrewer_1.1-3
  [7] httr_1.4.4             sctransform_0.3.5      utf8_1.2.2
 [10] R6_2.5.1               irlba_<IP_ADDRESS>          KernSmooth_2.23-20
 [13] uwot_0.1.14            lazyeval_0.2.2         colorspace_2.0-3
 [16] withr_3.0.0            sp_1.5-1               tidyselect_1.2.0
 [19] gridExtra_2.3          bit_4.0.5              compiler_4.2.3
 [22] progressr_0.11.0       cli_3.6.2              spatstat.explore_3.0-5
 [25] plotly_4.10.1          scales_1.2.1           lmtest_0.9-40
 [28] spatstat.data_3.0-0    ggridges_0.5.4         pbapply_1.6-0
 [31] goftest_1.2-3          digest_0.6.30          spatstat.utils_3.0-1
 [34] pkgconfig_2.0.3        htmltools_0.5.3        parallelly_1.32.1
 [37] fastmap_1.1.0          htmlwidgets_1.5.4      rlang_1.1.3
 [40] shiny_1.7.3            generics_0.1.3         zoo_1.8-11
 [43] jsonlite_1.8.4         spatstat.random_3.0-1  ica_1.0-3
 [46] magrittr_2.0.3         dotCall64_1.1-1        patchwork_1.1.2
 [49] Matrix_1.6-4           Rcpp_1.0.10            munsell_0.5.0
 [52] fansi_1.0.3            abind_1.4-5            reticulate_1.26
 [55] lifecycle_1.0.3        stringi_1.8.3          MASS_7.3-58.1
 [58] Rtsne_0.16             plyr_1.8.8             grid_4.2.3
 [61] parallel_4.2.3         listenv_0.8.0          promises_<IP_ADDRESS>
 [64] ggrepel_0.9.2          crayon_1.5.2           deldir_1.0-6
 [67] miniUI_<IP_ADDRESS>         lattice_0.20-45        cowplot_1.1.1
 [70] splines_4.2.3          tensor_1.5             pillar_1.8.1
 [73] igraph_1.3.5           spatstat.geom_3.0-3    future.apply_1.10.0
 [76] reshape2_1.4.4         codetools_0.2-18       leiden_0.4.3
 [79] glue_1.6.2             data.table_1.14.4      png_0.1-7
 [82] vctrs_0.5.2            spam_2.10-0            httpuv_1.6.11
 [85] polyclip_1.10-4        gtable_0.3.1           RANN_2.6.1
 [88] purrr_1.0.1            tidyr_1.3.0            scattermore_0.8
 [91] future_1.29.0          mime_0.12              xtable_1.8-4
 [94] later_1.3.1            survival_3.4-0         viridisLite_0.4.1
 [97] tibble_3.1.8           cluster_2.1.4          globals_0.16.1
[100] fitdistrplus_1.1-8     ellipsis_0.3.2         ROCR_1.0-11

#239

I think it was caused by the R version, you can try to do as mentioned in #261 .

Solution here #268


Do not show synthetic install tasks in the script explorer

The script explorer should only show scripts defined in the package.json and not synthetic tasks like the install task.

Fixed by


feat(RingTheory/AlgebraicIndependent): add some results on AlgebraicIndependent

algebraicIndependent_unique_type_iff, algebraicIndependent_iff_transcendental: equivalency of AlgebraicIndependent and Transcendental for one-element family
AlgebraicIndependent.transcendental: f a family x is algebraically independent, then any of its element is transcendental
MvPolynomial.(algebraicIndependent|transcendental)_X: algebraic independent properties of intermediates of MvPolynomial
algebraicIndependent_of_finite': variant of algebraicIndependent_of_finite using Transcendental
exists_isTranscendenceBasis': Type version of exists_isTranscendenceBasis

Also changed one ¬IsAlgebraic to Transcendental.
Also add Set.subtypeInsertEquivOption (used in the proof of algebraicIndependent_of_finite') which is similar to Finset.subtypeInsertEquivOption. Note that it does not have simp lemmas yet, as the existing Finset one has no simp lemmas, either.

This PR towards the result that if E/F is transcendental, then there are infinitely many F-embeddings from E to its algebraic closure.

Thanks!
maintainer merge


Update EFO annotations for UK Biobank studies

These are required for #344 #346 #348.
This is currently blocked. by Zooma

Zoë (EFO) has kindly done the mapping for another project of ours with MalaCards.
This should be all ICD10 refs in EFO:
https://docs.google.com/spreadsheets/d/1GSOkYegyQOdz21gdhMEex6gkOsHzlF9DWApq096FIo8/edit?usp=sharing
Note there may be multiple for each term which she has kept in separate fields.
@MichaelaEBI and I are currently looking into this file.

@deniseOme whoa this spreadsheet is very useful! Do you have any information on how it was created?


Eclipse CDT - Method 'endExpression' could not be resolved

Hi, it seems that (from some, to me unknown reason) the Eclipse is unable to Index the single_include/catch.hpp file. Here is the simple example:
#define CATCH_CONFIG_MAIN
#include "catch.hpp"

unsigned int Factorial( unsigned int number ) {
  return number > 1 ? Factorial(number-1)*number : 1;
}
TEST_CASE( "Factorials are computed", "[factorial]" ) {
    REQUIRE( Factorial(0) == 1 );
}

It compiles and tests OK, but the Eclipse marks all REQUIRE lines as error and complains about Method 'endExpression' could not be resolved.
Tried:

adding catch.hpp into Preprocessor Include Paths in eclipse
enabled scalability under C++/editor/scalability to 500000 lines
rebuilding index, cleaning project, open/close Eclipse..

Setup:

OS X 10.8.2
g++-4.8
Eclipse Juno with CDT

More can be found in Google group

Same issue here

@kentsangkm's solution in #393 worked for me on Eclipse Luna.

Same here, I tried https://github.com/philsquared/Catch/pull/393 solution and it worked on Eclipse Luna, Ubuntu

I know this has been circulating for a while but I felt there was enough of a critical mass to push it to the top recently. I've now changed the decomposition operator to <=, which I believe works around the issue here?
Please let me know either way - and also whether the change introduces any warnings for you?

The problem exists since version 1.7.1 again. Is there a chance to "fix" it again in Catch, although in real it is an eclipse problem?

@manu-m Are you sure its since 1.7.1? Because that one didn't touch the decomposition mechanism. If it started again since 1.7.0, then maybe.

@horenmar Yes I am sure. I checked it two times again. The message doesn't appear in eclipse while working with Catch 1.7.0 but appears while working with 1.7.1. I am surprised, too.

@manu-m In that case, probably not. 1.7.0 brought a rework of the expression capture mechanism, which sped up successful assertions significantly (~5 times). 1.7.1 then was a bugfix, so that templated comparisons don't cause compile-time errors.
Maybe we can try to change the underlying operator again, but not sure if that would help.

@manu-m Try the attached version.
catch.zip

@horenmar Thank you very mich for your extremly fast reply! But unfortunately the attached version still produces the error. Do have another idea or solution related to this problem?

@manu-m Well, Eclipse could always fix their parser  😄


Attempt to display locahost:8080 results in ArrayIndexOutOfBoundsException

Mon Jun 06 08:52:34 EDT 2016
There was an unexpected error (type=Internal Server Error, status=500).
java.lang.ArrayIndexOutOfBoundsException: 9 in #1:6653 at line number 56 at column number 81
Line number 56 where? #1:6653? Which class is having a problem?
I think the readme.md file could use some more context on how to get this up and running successfully, because it is probably me not understanding. Thanks!

I'm sorry - I made a GET request for application/json and got a successful result:
0:  {
"id": 1
"author": "Brian Clozel"
"content": "This is a test!"
}-
1:  {
"id": 2
"author": "Stéphane Nicoll"
"content": "This is a test too!"
}
There was nothing wrong other than me :-)


Add HDFile.readinto(length, out), re-implement read(...) in terms of readinto(...)

See https://github.com/dask/hdfs3/issues/160 for the in-depth discussion.

AttributeError: 'memoryview' object has no attribute 'nbytes'

Perhaps you need to use m.itemsize * reduce(operator.mul, m.shape) (py2 only) ?

Updated the benchmark - these are the numbers for the different configurations with unpatched libhdfs3:
old_read(length=READ_SIZE): 3.09601              # ~three copies, crc verification, buffer re-allocation
read(length=READ_SIZE): 2.47153                  # two copies, crc verification, buffer re-allocation
read(length=READ_SIZE, out_buffer=True): 2.15100 # single copy, crc verification, buffer re-allocation
read(length=READ_SIZE, out_buffer=buf): 1.97234  # single copy inside libhdfs3 + crc verification

OK, thank you!


Retry on failure when polling for migration status

If the API call to check the migration status fails (for any reason) we should retry that call. This scenario isn't covered by our existing retry logic because the existing retry logic applies to HTTP GET's, but the call to check migration status is a GQL endpoint so it is technically a POST and does not have retry logic today.
We also need to check the response payload to see if it failed, checking the HTTP status code isn't sufficient as GQL failures still return 200, with the error in the response body.

Thanks to @synthead'd recent changes, this case is turning up quite a lot now. Here's an example log output:
[14:07] [DEBUG] HTTP POST: https://api.github.com/graphql
[14:07] [DEBUG] HTTP BODY: {"query":"query($id: ID!) { node(id: $id) { ... on Migration { id, sourceUrl, migrationSource { name }, state, failureReason, repositoryName } } }","variables":{"id":"RM_kgDaACQxZmU1NTQ5Ny00OGY0LTQ4OGItOTRmNy03NWVkY2RlYmU3Y2Y"}}
[14:07] [DEBUG] GITHUB REQUEST ID: 0405:4886:2169D5B:441EE27:634853D4
[14:07] [DEBUG] RESPONSE (OK): {"data":{"node":null},"errors":[{"type":"SERVICE_UNAVAILABLE","path":["node"],"locations":[{"line":1,"column":19}],"message":"GitHub Enterprise Importer is currently unavailable. Please try again later."}]}
[14:07] [ERROR] System.InvalidOperationException: Cannot access child value on Newtonsoft.Json.Linq.JValue.
   at Newtonsoft.Json.Linq.JToken.get_Item(Object key)
   at OctoshiftCLI.GithubApi.GetMigration(String migrationId)
   at OctoshiftCLI.GithubEnterpriseImporter.Handlers.MigrateRepoCommandHandler.Invoke(MigrateRepoCommandArgs args)
   at System.CommandLine.NamingConventionBinder.CommandHandler.GetExitCodeAsync(Object returnValue, InvocationContext context)
   at System.CommandLine.NamingConventionBinder.ModelBindingCommandHandler.InvokeAsync(InvocationContext context)
   at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass4_0.<<BuildInvocationChain>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass17_0.<<UseParseErrorReporting>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass12_0.<<UseHelp>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass22_0.<<UseVersionOption>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass19_0.<<UseTypoCorrections>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseSuggestDirective>b__18_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass16_0.<<UseParseDirective>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<RegisterWithDotnetSuggest>b__5_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass8_0.<<UseExceptionHandler>b__0>d.MoveNext()

I think we should prioritise this work to provide a smoother CLI experience.
@dylan-smith What do you think? How much of a lift would it be to implement these retries?

I actually started picking away at this on the weekend already. I should have a PR up soon.

Amazing! Thanks.

I see that #686 has been opened to close this — can I preemptively close https://github.com/github/migration-friction/issues/689, https://github.com/github/migration-friction/issues/699, and https://github.com/github/migration-friction/issues/701, assuming that this issue supersedes them (and will close soon)?


Someone please upload the training set to google drive

I have been training moran on my own set and it is giving me good results, but i was not able to download the training set from BaiduPan due to some issues,
If anybody has been able to download the set,could they please upload it to google drive and share the link.
Thanks in advance.

Sorry for that, I'll mark this issue as "good issue" to attract attention from others.

Thanks a lot for the support.Hope somebody uploads it!

you can run this program to generate text image
https://github.com/Belval/TextRecognitionDataGenerator

Okay, let me check this, but are your sure the ground truth is also provided?

there is serval option of data format, read run.py,  you can make each image_name by its label or generate a additional txt file to record "image_names + labels"

Okay, ill check this out.

I just read the repo README. I am afraid the synthesized samples are not good enough. @DecentMakeover

https://drive.google.com/open?id=1vfh6Gf-DLu5aJmf_FhpM27BImc5ObKjQ

I have been training moran on my own set and it is giving me good results, but i was not able to download the training set from BaiduPan due to some issues,
If anybody has been able to download the set,could they please upload it to google drive and share the link.
Thanks in advance.

hey! Can you please provide the pre-trained model of morgan (Can provide a link to the drive where it is uploaded). I am facing issues to train the model ,i need this pretrained model in my work .Please help me


use_query and use_mutation

Description
Adds use_query and use_mutation hooks. I haven't tested to see that these work as expected, but they get across the interface that I think we should provide for writing database operations.
Checklist:
Please update this checklist as you complete each item:

[ ] Tests have been included for all bug fixes or added functionality.
[ ] The changelog.rst has been updated with any significant changes, if necessary.
[ ] GitHub Issues which may be closed by this PR have been linked.

Recursively for loop iterate through each object value to force run the query while within the hook
Have a flag to disable immediate_fetch
Double check the re-run workflow to ensure we aren't unnecessarily performing ORM queries

@Archmonger so the implementation I went with uses Model.get_deferred_fields and just called getattr on all the field names it returns. I'm pretty sure this does what we want. I also require that if fetch_deferred_fields=True, then the query function must return a QuerySet or Model because it would be too hard to try and discover Model instances in arbitrary data structures in order to fetch their deferred fields.

@Archmonger I've got to switch and work on some other things for a bit. If you're able to help get this over the finish by adding some docs or tests that would be great.

Will do, but I am currently out on vacation. I'll get to it sometime after the 20th of this month.

While I was writing out the docs I had a thought. Is there really any point to having separate use_query and use_mutation hooks?
I feel like the use_query hook could easily fill the role of both. For example, if the user doesn't return anything within their query function, we can just assume it's a mutation.

Let me know if you want to chat about use_mutation and the purpose of refetch.

Note; Need to verify whether we are properly closing database connections in our new hooks.
We don't want these connections to potentially be re-used by other threads, otherwise data loss can occur. A quick n dirty solution could be using database_sync_to_async.

On rereading the code I wrote I found a bunch of bug and removed fetch_deferred_fields along with the UNDEFINED sentinel.

So I added a basic test. I'm not really sure why, but sometimes it fails because database is locked.

I increase the database query timeout (it's fairly low by default), which resolved the database is locked error.
The current issue with the tests is that sometimes the item does not successfully update after a use_mutation execution.

So it turns out there's a JS error that happens when applying a JSON patch generated by the server. I think this is, yet again, a bug with the Python JSON patch library. I'm growing increasingly frustrated with it and there's been no response to this issue I raised over 6 months ago. I see a couple options to move forward:

Try and figure out the underlying issue and fix it
Find a more reliable JSON patch implementation. There are no other native Python implementations so we'd need a C or Rust extension.
Use a different solution altogether.

Can we just perform the patch on the JS side? Last I checked there are some well maintained libs in that end.

The main problem, if this is related to the prior issue, is that I don't really know how to it. The codebase is pretty hard to follow.

We're already doing this. The server generates a patch and the client applies that patch to its copy of the model.

I'd be open to doing some benchmarking and seeing if we could just get rid if it, but I suspect that if you have to re-render a large page from the root, that computing and sending the patch, vs sending the whole update, is worth it.

BTW we're already using my proposed fix from the issue.

I'll have to check, but perhaps switching to an older version of jsonpatch might fix things in the short-term.

Although the tests are working, this still seems to be broken (tested via manually typing/clicking)

Tracking the JSON Patch issue here. Also have a PR up to resolve it. Just need to update tests.
Also, discovered this while working on the tests. For some reason onChange is the only event that gets the accurate event.target.value if the input's value is "controlled".

Ironically, in trying to remove JSON patch, I think I found the problem. I was mutating something I shouldn't have been which was screwing up the diff.

I'm not sure what the new API is for create_context and use_context now.

So I thought that change had fixed the JSON patch problem, but I don't think it has actually.

IDOM 4.0 release might be even more broken than previous. Random VDOM elements simply don't render what so ever, even under normal circumstances.

Looks like the VDOM for the previously mentioned broken test case is valid? If that's the case then this issue is almost certainly layout module related.
{'attributes': {'id': 'django-css'},
 'children': [django_css(2131d8d8b80, static_path='django-css-test.css'),
              {'attributes': {'style': {'display': 'inline'}},
               'children': ['django_css: '],
               'tagName': 'div'},
              {'children': ['This text should be blue.'], 'tagName': 'button'},
              {'tagName': 'hr'}],
 'tagName': 'div'}

Seems like JSON patch is still broken
client.js:30213 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'onChange')
    at applyOperation (client.js:30213:22)
    at Object.applyPatch (client.js:30250:22)
    at applyNonMutativePatch (client.js:30649:20)
    at client.js:30633:20
    at client.js:31298:48

On a different note, I am going to merge the playwright testing suite into my view_to_component PR.

@Archmonger it looks like the doc tests are failing. Getting 503 when checking links on the Django docs. Maybe getting rate limited since the links seem to be valid?
Also, I'm unable to reproduce the error you're seeing under the these changes or under the latest 0.40.1 release of IDOM.

Error occurs when toggling any of the checkboxes on the use_mutation list elements.

The docs error looks real actually. Django's website is just down for some reason:

Yep, just tested that as well. Looks like the server they use to host dev docs is down. I might switch the docs off of the dev branch if this becomes a reoccurring issue.

Ok, am able to repro the problem on 0.40.1 albeit with a slightly different error message. Under proposed changes in bypass-jsonpatch that problem goes away.

I just tested out the current branch again, with bypass-jsonpatch. The following errors were given on three separate mouse clicks.
client.js:29997 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'id')
    at Object.replace (client.js:29997:26)
    at applyOperation (client.js:30206:60)
    at Object.applyPatch (client.js:30250:22)
    at applyNonMutativePatch (client.js:30649:20)
    at client.js:30633:20
    at client.js:31298:48
replace @ client.js:29997
applyOperation @ client.js:30206
applyPatch @ client.js:30250
applyNonMutativePatch @ client.js:30649
(anonymous) @ client.js:30633
(anonymous) @ client.js:31298
Promise.then (async)
socket.onmessage @ client.js:31298

client.js:30213 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'children')
    at applyOperation (client.js:30213:22)
    at Object.applyPatch (client.js:30250:22)
    at applyNonMutativePatch (client.js:30649:20)
    at client.js:30633:20
    at client.js:31298:48
applyOperation @ client.js:30213
applyPatch @ client.js:30250
applyNonMutativePatch @ client.js:30649
(anonymous) @ client.js:30633
(anonymous) @ client.js:31298
Promise.then (async)
socket.onmessage @ client.js:31298

client.js:3636 Warning: Encountered two children with the same key, `9`. Keys should be unique so that components maintain their identity across updates. Non-unique keys may cause children to be duplicated and/or omitted — the behavior is unsupported and could change in a future version.
    at ul
    at StandardElement (http://<IP_ADDRESS>:8000/static/django_idom/client.js:31094:28)
    at Element (http://<IP_ADDRESS>:8000/static/django_idom/client.js:31076:20)
    at StandardElement (http://<IP_ADDRESS>:8000/static/django_idom/client.js:31094:28)
    at Element (http://<IP_ADDRESS>:8000/static/django_idom/client.js:31076:20)
    at div
    at StandardElement (http://<IP_ADDRESS>:8000/static/django_idom/client.js:31094:28)
    at Element (http://<IP_ADDRESS>:8000/static/django_idom/client.js:31076:20)
    at StandardElement (http://<IP_ADDRESS>:8000/static/django_idom/client.js:31094:28)
    at Element (http://<IP_ADDRESS>:8000/static/django_idom/client.js:31076:20)
    at StandardElement (http://<IP_ADDRESS>:8000/static/django_idom/client.js:31094:28)
    at Element (http://<IP_ADDRESS>:8000/static/django_idom/client.js:31076:20)
    at StandardElement (http://<IP_ADDRESS>:8000/static/django_idom/client.js:31094:28)
    at Element (http://<IP_ADDRESS>:8000/static/django_idom/client.js:31076:20)
    at Layout (http://<IP_ADDRESS>:8000/static/django_idom/client.js:31060:19)

I did some inspection of the code in my venv, seems like the git+ install wasn't overriding my local idom. I manually applied the patch to serve.py and it resolved the issue.

Should I commit the from channels.auth import login and TransactionTestCase changes I suggested above?

Go for it!

LGTM, ready for merge.


Regression: Can't compile records from YAWS when upgrading from LFE 1.2 to 1.3

I've spent the greater part of today trying to narrow this down (needed to determine if the error was in lfest, YAWS, or LFE). Finally found that the difference was between LFE v1.2 and v1.3. When I have more time, I can git bisect to find the exact commit that causes the issue.
What I found out last night, though, was I coldn't upgrade the lfest web-app routing project from LFE 1.2 to 1.3 due to an error in the tests (see https://github.com/lfex/lfest/issues/4).
This error shows up in all commits after the v1.3 release and for all versions of YAWS since 2.0.1 (didn't go back any further than that, since that was the last version that I worked with a few years ago). The most recent version of YAWS (2.0.6) works just fine with LFE v1.2, though (as, in fact, do all tested versions of YAWS).
The strack trace reported by rebar3 is as follows:
===> Uncaught error: {case_clause,
                             {error,
                              {undef,
                               [{erl_internal,is_type,[frag_type,0],[]},
                                {lfe_lint,check_type_name,3,
                                 [{file,
                                   "/Users/dmcgreggor/lab/lfe/lfest/_build/test/plugins/lfe/src/lfe_lint.erl"},
                                  {line,357}]},
                                {lfe_lint,check_type_def,4,
                                 [{file,
                                   "/Users/dmcgreggor/lab/lfe/lfest/_build/test/plugins/lfe/src/lfe_lint.erl"},
                                  {line,339}]},
                                {lfe_lint,collect_form,2,
                                 [{file,
                                   "/Users/dmcgreggor/lab/lfe/lfest/_build/test/plugins/lfe/src/lfe_lint.erl"},
                                  {line,208}]},
                                {lists,foldl,3,
                                 [{file,"lists.erl"},{line,1261}]},
                                {lfe_lint,collect_module,2,
                                 [{file,
                                   "/Users/dmcgreggor/lab/lfe/lfest/_build/test/plugins/lfe/src/lfe_lint.erl"},
                                  {line,192}]},
                                {lfe_lint,check_module,2,
                                 [{file,
                                   "/Users/dmcgreggor/lab/lfe/lfest/_build/test/plugins/lfe/src/lfe_lint.erl"},
                                  {line,176}]},
                                {lfe_lint,module,2,
                                 [{file,
                                   "/Users/dmcgreggor/lab/lfe/lfest/_build/test/plugins/lfe/src/lfe_lint.erl"},
                                  {line,163}]}]}}}
===> Stack trace to the error location:
[{lr3_comp,compile,3,
           [{file,"/Users/dmcgreggor/lab/lfe/lfest/_build/default/plugins/lfe-compile/src/lr3_comp.erl"},
            {line,27}]},
 {rebar_base_compiler,compile_each,3,
                      [{file,"/opt/rebar3-3.10.0/src/rebar_base_compiler.erl"},
                       {line,185}]},
 {lr3_comp,'-compile_normal_app/1-lc$^0/1-0-',4,
           [{file,"/Users/dmcgreggor/lab/lfe/lfest/_build/default/plugins/lfe-compile/src/lr3_comp.erl"},
            {line,65}]},
 {lr3_comp,compile_normal_app,1,
           [{file,"/Users/dmcgreggor/lab/lfe/lfest/_build/default/plugins/lfe-compile/src/lr3_comp.erl"},
            {line,65}]},
 {lr3_comp,'-compile_normal_apps/1-lc$^0/1-0-',1,
           [{file,"/Users/dmcgreggor/lab/lfe/lfest/_build/default/plugins/lfe-compile/src/lr3_comp.erl"},
            {line,47}]},
 {lr3_comp,compile_normal_apps,1,
           [{file,"/Users/dmcgreggor/lab/lfe/lfest/_build/default/plugins/lfe-compile/src/lr3_comp.erl"},
            {line,47}]},
 {rebar_core,do,2,[{file,"/opt/rebar3-3.10.0/src/rebar_core.erl"},{line,154}]},
 {rebar_hooks,run_provider_hooks_,6,
              [{file,"/opt/rebar3-3.10.0/src/rebar_hooks.erl"},{line,48}]}]

This stack trace happens when testing this file in the lfest project.
To narrow things down, I commented out all the calls to the generated record functions as well as the actual include-lib, and then the file compiles correctly. Even with include-lib only, and no calls to the record functions, I still get the stacktrace above.

This is the YAWS file that LFE 1.3 can't handle right now:

https://github.com/klacke/yaws/blob/master/include/yaws_api.hrl

Oh dear -- I should have specified: I only see this on Erlang 17.5, not anything higher (and I haven't tested against anything lower).
I'll update the ticket description with that info ...

1.2.1 is okay ...

Finally narrowed it down:

The issue popped up between 59165a0 and 4c8732f
I've confirmed this after multiple checks (since it's late and I'm sleepy, I might have missed something)
Change 59165a0 is just three commits after the releases for 1.2.1
Here's the diff: git diff 59165a0..4c8732f where something broke the LFE compiler's ability to work with the YAWS include file

Little more awake now ...

59165a0 - "Make even #'=:=/2 generate (function =:= 2)" (last working commit)
4c8732f - "Merge branch 'dev-types' into develop" (the commit where the break occurs)

Looks like the dev-types branch is gone from Github, and it seems that I don't have a local copy of it, so I can't dig into which specific change in that branch caused the problem ... unless ...
Ah-ha! Git's graphing log output to the rescue:
* aa1c7fe 2 years, 5 months ago Fix error message for {illegal_literal,Lit} error <Robert Virding>
*   4c8732f 2 years, 5 months ago (HEAD, unstable/regression) Merge branch 'dev-types' into develop <Robert Virding>
|\
| * 8ab0bb7 2 years, 6 months ago Improve checking/reporting of errors in function definitions <Robert Virding>
| * d2ef7dc 2 years, 6 months ago Fix handling of new old record type formats <Robert Virding>
| * 42096b9 2 years, 6 months ago Make checking of type vars behave the same as in erlang <Robert Virding>
| * a3b0bc7 2 years, 6 months ago Improve spec docs definitions and examples <Robert Virding>
| * 29ae52b 2 years, 6 months ago Add type/spec macros <Robert Virding>
| * b3cf1f5 2 years, 6 months ago Improve checking of functione metadata <Robert Virding>
| * f258247 2 years, 6 months ago Add function specifications <Robert Virding>
| * 098115e 2 years, 6 months ago Add checking of type definitions <Robert Virding>
| * 88f7381 2 years, 7 months ago Add rudimentary type documentation <Robert Virding>
| * 97b5eba 2 years, 7 months ago Fix handling of record types to be more consistent. <Robert Virding>
| * 1f8cb50 2 years, 7 months ago Add generation of type and record attributes in core erlang <Robert Virding>
| * f49bec0 2 years, 7 months ago Add maps <Robert Virding>
| * 87141ed 2 years, 7 months ago Add union and function types <Robert Virding>
| * 9092674 2 years, 7 months ago Add handling of records <Robert Virding>
| * 1d945ac 2 years, 7 months ago (refs/bisect/bad) First save commit <Robert Virding>
* 59165a0 2 years, 6 months ago Make even #'=:=/2 generate (function =:= 2) <Robert Virding>
* d722d36 2 years, 6 months ago (tag: v1.2.1, tag: 1.2.1, regression, refs/bisect/good-d722d3662b191b61310dc9bba78f9a77f512b742) Merge branch 'develop', this is v1.2.1 <Robert Virding>

I'll dig through those sub-commits later, and see which commit in the branch introduced ther regression with 17.5.

Also, I should say that this is not a big deal :-) It only affects the odlest version of Erlang, of all the versions I care about (I no longer support 16 in my LFE projects). Mostly I'm doing this out of curiosity .... and the off chance that the fix would be straight-forward.
This only affects LFE YAWS/web app projects, and for all of those that I still use, if I upgrade to the latest LFE, I will also upgrade to the latest Erlang.
I'll add a note to the description that indicates that this is no biggie ...

The reason for this is that later versions of the compiler generate type information which the erlang compiler can use to generate type information which is used by dialyzer, amongst other things. It uses the function erl_internal:is_type/2 which wasn't defined until Erlang 18.0. Hence the problem running later versions of LFE with older versions of Erlang.
I don't really know how I should solve this problem. Until now I have tried make all versions of LFE runnable on Erlang R16 and later. This has failed here. Maybe I should change my goal and for each version of LFE specify which versions of Erlang it can run on.
It would make it easier but be a bit more limiting for users.

I'm comfortable with that, really. This is how I've been releasing Erlang/Jinterface/Clojure libs (each release tied specifically to a set of versions). I provide a table in the README letting users know which is safe to use, e.g.:

https://github.com/clojang/jiface#dependencies-

We're no longer supporting versions of Erlang older than 19.
Closing ...


Organization Module Cleanup

Adds a README to the organizations module and explicitly label it as the first module

/lgtm


Bug: Linter fails to recognize aliases containing commas

Describe the Bug
This is related to the fix for #509
The following YAML array contains two aliases:
aliases: Scott, "Scott, Jr."
Linter parses this into three aliases.
How to Reproduce
I have attached the data.json file.
See the example above.
Linter produces a multiline array of three aliases:
aliases:
  - Scott
  - '"Scott'
  - 'Jr."'

Expected Behavior
Linter should parse the tags array exactly how Obsidian parses the tags array.
The example should produce a multiline tags array with two tags. The double quotes should be eliminated, and the tag containing the commas should not be escaped with single quotes.
Expected output:
aliases:
  - Scott
  - Scott, Jr.

Device

[x] Desktop
[?] Mobile

I was thinking about this a little more. A good test for Linter would be that properly formed single-line arrays can be converted to multiline arrays and then back to single-line arrays with no change. Likewise, proper multiline arrays should convert to single-line arrays and back to multiline with no change.
This bug would fail these tests, Linter's array conversion should be symmetrical.

Thanks for reporting this. This is a known limitation of parsing the values that are not actually a valid format for YAML (I am not sure if it is in the documentation for the rules themselves). This is definitely an issue, but unless the logic for parsing YAML is written to be more robust, this is not necessarily something that can be added.
I am open to testable fixes to this as using the Obsidian built in mechanisms for parsing these values is not really testable and thus is not a reliable solution for us.

The main problem with what you are proposing is that the above is not valid YAML so converting from single-line to multi-line is not feasible for it. If it were valid YAML, it would be simple to convert between the two formats. However Obsidian has added for several formats that are not valid, so support for them is kind of monkey-patched in. I definitely am open to improving how things are parsed, but I think it should cover most cases and not all cases as some of them are so infrequent it may not be worth the effort to try to cover.

Here are a couple of things to keep in mind for this.

Obsidian recognizes the single-line example as valid YAML. As does https://jsonformatter.org/yaml-validator.
Linter's job is to make sure that a file is properly formatted--so if Obsidian recognized two aliases before running Linter, it should recognize only two aliases after Linter is done.
Linter is the source of the single-line array example (from my original multiline array) then, when I asked Linter to convert it back to a multi-line array, it could not parse its own emitted YAML properly.
Linter should be able to parse its own results.

While it would be nice if the Linter could parse its own output, the Linter does not posses a means to parse all valid forms of YAML for purposes they were not designed for.
For example, Obsidian adds at least 3 kinds of new arrays that are not valid YAML arrays, but are still valid YAML strings:

comma separated single string
space separated single string
single-line array that is space delimited

The only two array formats that YAML recognizes are

single-line array
multiline array

That is what causes some of the problem as YAML parser packages are not designed to parse out the Obsidian based arrays and Obsidian provides something to do the parsing that is not usable for testing which means it can change with no way for devs to know ahead of time. This means that a custom parser has to be used to emulate how Obsidian does its parsing. This is where the more simplistic approach is used. That is what you are seeing with the unexpected output for array differences. It definitely can be improved.
TLDR;
The YAML is being custom parsed which definitely can be improved. Custom parsing is used to recognize the new custom formats for YAML arrays that are not traditionally recognized by YAML parsers as arrays. I am happy to improve the parsing logic, but it will likely never work exactly like Obsidian does in all cases.

I may have something working for this. It is relatively basic and does not allow nesting arrays, so that would be something to look out for. However it should be able to do a basic parsing of arrays. It is currently allowing all UTs to pass, so I will start adding tests for the cases where there are escaped delimiters and see what happens.

Parser seems to be doing its job at determining what should and should not be considered escaped. I have to still add some edge cases, but I am hopeful it will work in those cases. Once that is done, I will go ahead and add a couple UTs for formatting YAML and then push it up for the next release.
Hopefully it all goes well and then I can focus on this header increment stuff.

It looks like it plays well with the change. @ScottKillen , could you clarify why you would expect the Linter to automatically remove the double quotes from around Scott, Jr. when it goes to multi-line? I know that it no longer needs them, but removing escaping is actually not as straight forward as adding them and I am not sure the Linter removes escaping at this time.

As a note, the change for this has been merged into master, so the fix should be present in on master and in the next release. I have not closed this issue as I am curious what the feedback is on removing the escaping of the comma. I am guessing I can add an extra param in somewhere that says that if you are going to become a multi-line array it should remove the escaping of commas, but I want to make sure that that is the rationale here before I move forward with any kind of change like that.

It looks like it plays well with the change. @ScottKillen , could you clarify why you would expect the Linter to automatically remove the double quotes from around Scott, Jr. when it goes to multi-line? I know that it no longer needs them, but removing escaping is actually not as straight forward as adding them and I am not sure the Linter removes escaping at this time.

@pjkaufman If the quotes are present everything works fine. The reason I would expect them to be removed is that they are not necessary, which is kind of Linter's thing--and Linter is smart enough to add them when they are necessary.

Gotcha. I will think on this and see if it makes sense and is feasible to remove the quotes for multi-line and other array formats. It just gets a little hard to tell when quotes should be removed without knowing the previous and new formats of the array.

Would it make sense to make this another one of those global settings that would be reusable throughout rules to allow for the removal of the unnecessary quotes for multiline arrays?
I have been debating whether to make this a global setting, automatic, or add it on a rule by rule basis. Since I have not come to a decision, I decided to ask and see what you think @ScottKillen.

I think a global setting makes sense. Some may want the quotes for aesthetic reasons, similar to extra whitespace. And the whitespace settings are global.

I know it has been a while on this. But I finally took a stab at this and should have a fix for it. It will go out with the next release.

The change has been merged into master and should go out with the next release. Please let us know if the bug around properly recognizing commas or the lack of removing unnecessary escape chars for multi-line arrays does not work when the setting to do so is turned on for master or the next release.


fix(locale): use context for locale

This uses context to create a globally available locale. That way components don't have to all individually fetch it.

Thanks for replying to my comments @ismay. After your explanations, I think the current implementation will work just fine for now. Still think it'd be good to introduce this as a service in the app-runtime too, but that's completely unrelated.

Definitely, I agree. That would be nice to have. I can see if there's already an issue for it and create it if there isn't.

Thanks for replying to my comments @ismay. After your explanations, I think the current implementation will work just fine for now. Still think it'd be good to introduce this as a service in the app-runtime too, but that's completely unrelated.

Definitely, I agree. That would be nice to have. I can see if there's already an issue for it and create it if there isn't.


feat(thru): Make thru parametric in its return type

Summary
See https://github.com/cujojs/most/issues/471
Make thru parametric in its return type to admit functions that return something other than a Stream.
Todo

[x] Unit tests for new or changed APIs and/or functionality
[x] Documentation, including examples

:+1: This does looks good, thanks for the quick update!

lgtm 👍

🚢 :it:

Thanks for the reviews!  We'll get this released soon.


USB host MSC class READ FORMAT CAPACITY command failing.

Hi, I am working on USB host mass storage class, as part class request there was a command READ FORMAT CAPACITY which is sending from host to device, but device endpoint getting stalled and at the same time host side also STALL ENDPOINT event gets generated and it's trying to reset the endpoint.
below is the code where we can send the READ FORMAT CAPACITY command to the device.
/ Some devices require we do this.  /
status =  _ux_host_class_storage_media_format_capacity_get(storage);
if (status != UX_SUCCESS)
return(status);
One thing I could say that if we comment above snippet code, MSC class working fine.
Could you please help on this if we can comment this code and continue further MSC class.
->I am using usbx version is v6.1.9_rel.
->ARMCLANG
I am attaching USB trace screenshot for your reference.

Regards
Mahesh

Hi @@xiaocq2001 ,
Could you please help on above issue.

I'm not sure if it's required for some old mass storage device to enumerate, maybe you can try to ignore the error and just continue the steps (dont check the error code to return).

Hi @xiaocq2001,
Thank you so much for update.


npm run setup fails

root@mj react-boilerplate]# npm run setup

><EMAIL_ADDRESS>presetup /home/mangis/workspace/react-boilerplate
> npm i chalk

<EMAIL_ADDRESS>node_modules/chalk

><EMAIL_ADDRESS>setup /home/mangis/workspace/react-boilerplate
> node ./internals/scripts/setup.js

module.js:327
    throw err;
    ^

Error: Cannot find module '/home/mangis/workspace/react-boilerplate/internals/scripts/setup.js'
    at Function.Module._resolveFilename (module.js:325:15)
    at Function.Module._load (module.js:276:25)
    at Function.Module.runMain (module.js:441:10)
    at startup (node.js:139:18)
    at node.js:968:3

npm ERR! Linux 4.5.7-202.fc23.x86_64
npm ERR! argv "/usr/bin/node" "/bin/npm" "run" "setup"
npm ERR! node v4.4.7
npm ERR! npm  v2.15.8
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>setup: `node ./internals/scripts/setup.js`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>setup script 'node ./internals/scripts/setup.js'.
npm ERR! This is most likely a problem with the react-boilerplate package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node ./internals/scripts/setup.js
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs react-boilerplate
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!
npm ERR!     npm owner ls react-boilerplate
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /home/mangis/workspace/react-boilerplate/npm-debug.log

cat /home/mangis/workspace/react-boilerplate/npm-debug.log >>
https://gist.github.com/Mangirdaz/b2ad8666e8637ef7b70fc2f6453b4615

You need at least npm 3 and you have npm v2.15.8

sorry, debug output:
[root@mj react-boilerplate]# npm install npm -g
/usr/bin/npm -> /usr/lib/node_modules/npm/bin/npm-cli.js
/usr/lib
└──<EMAIL_ADDRESS>
https://gist.github.com/Mangirdaz/19a5bd702105135e35c4902d902dbc07
Looks like some dependencies is not satisfied with install (new to npm, will check)

looks like these could be an issue on my fedora:
npm WARN optional Skipping failed optional dependency /chokidar/fsevents: npm WARN notsup Not compatible with your operating system or architecture<EMAIL_ADDRESS>npm WARN optional Skipping failed optional dependency /karma/chokidar/fsevents: npm WARN notsup Not compatible with your operating system or architecture<EMAIL_ADDRESS>

Try removing the node_modules folder and try npm install again.
The error you have now is similar to this #725

same :/
[root@mj react-boilerplate]# cat /home/mangis/workspace/react-boilerplate/npm-debug.log 0 info it worked if it ends with ok 1 verbose cli [ '/usr/bin/node', '/bin/npm', 'run', 'setup' ] 2 info using<EMAIL_ADDRESS>3 info using<EMAIL_ADDRESS>4 verbose run-script [ 'presetup', 'setup', 'postsetup' ] 5 info lifecycle<EMAIL_ADDRESS><EMAIL_ADDRESS>6 verbose lifecycle<EMAIL_ADDRESS>unsafe-perm in lifecycle true 7 verbose lifecycle<EMAIL_ADDRESS>PATH: /usr/lib/node_modules/npm/bin/node-gyp-bin:/home/mangis/workspace/react-boilerplate/node_modules/.bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin 8 verbose lifecycle<EMAIL_ADDRESS>CWD: /home/mangis/workspace/react-boilerplate 9 silly lifecycle<EMAIL_ADDRESS>Args: [ '-c', 'npm i chalk' ] 10 silly lifecycle<EMAIL_ADDRESS>Returned: code: 0  signal: null 11 info lifecycle<EMAIL_ADDRESS><EMAIL_ADDRESS>12 verbose lifecycle<EMAIL_ADDRESS>unsafe-perm in lifecycle true 13 verbose lifecycle<EMAIL_ADDRESS>PATH: /usr/lib/node_modules/npm/bin/node-gyp-bin:/home/mangis/workspace/react-boilerplate/node_modules/.bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin 14 verbose lifecycle<EMAIL_ADDRESS>CWD: /home/mangis/workspace/react-boilerplate 15 silly lifecycle<EMAIL_ADDRESS>Args: [ '-c', 'node ./internals/scripts/setup.js' ] 16 silly lifecycle<EMAIL_ADDRESS>Returned: code: 1  signal: null 17 info lifecycle<EMAIL_ADDRESS>Failed to exec setup script 18 verbose stack Error<EMAIL_ADDRESS>setup: node ./internals/scripts/setup.js18 verbose stack Exit status 1 18 verbose stack     at EventEmitter.<anonymous> (/usr/lib/node_modules/npm/lib/utils/lifecycle.js:242:16) 18 verbose stack     at emitTwo (events.js:87:13) 18 verbose stack     at EventEmitter.emit (events.js:172:7) 18 verbose stack     at ChildProcess.<anonymous> (/usr/lib/node_modules/npm/lib/utils/spawn.js:40:14) 18 verbose stack     at emitTwo (events.js:87:13) 18 verbose stack     at ChildProcess.emit (events.js:172:7) 18 verbose stack     at maybeClose (internal/child_process.js:827:16) 18 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:211:5) 19 verbose pkgid<EMAIL_ADDRESS>20 verbose cwd /home/mangis/workspace/react-boilerplate 21 error Linux 4.5.7-202.fc23.x86_64 22 error argv "/usr/bin/node" "/bin/npm" "run" "setup" 23 error node v4.4.7 24 error npm  v3.10.5 25 error code ELIFECYCLE 26 error<EMAIL_ADDRESS>setup:node ./internals/scripts/setup.js26 error Exit status 1 27 error Failed at the<EMAIL_ADDRESS>setup script 'node ./internals/scripts/setup.js'.

It is safe to ignore WARN messages, they are not a significant problem, in general development and specifically in this case. @rog is correct, you must have npm 3+.
@Mangirdaz you should be good to go now. I'm closing this issue as it is resolved. If you have additional problems please open an new issue.

I still get same error but now stuff starts. If this is acceptable from your point of view we can close. thanks

It's not an error, it's a WARNing, which is, in fact, expected.

Ok :) Just as per my understanding ERR mean error :D stuff works, but this is output I get each time
><EMAIL_ADDRESS>setup /home/mangis/workspace/react-boilerplate
> node ./internals/scripts/setup.js

module.js:327
    throw err;
    ^

Error: Cannot find module '/home/mangis/workspace/react-boilerplate/internals/scripts/setup.js'
    at Function.Module._resolveFilename (module.js:325:15)
    at Function.Module._load (module.js:276:25)
    at Function.Module.runMain (module.js:441:10)
    at startup (node.js:139:18)
    at node.js:968:3

npm ERR! Linux 4.5.7-202.fc23.x86_64
npm ERR! argv "/usr/bin/node" "/bin/npm" "run" "setup"
npm ERR! node v4.4.7
npm ERR! npm  v3.10.5
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>setup: `node ./internals/scripts/setup.js`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>setup script 'node ./internals/scripts/setup.js'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the react-boilerplate package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node ./internals/scripts/setup.js
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs react-boilerplate
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls react-boilerplate
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /home/mangis/workspace/react-boilerplate/npm-debug.log
[root@mj react-boilerplate]# npm run setup

><EMAIL_ADDRESS>presetup /home/mangis/workspace/react-boilerplate
> npm i chalk

Right, that's because you've already run npm run setup – that's only mean to be ran a single time. If you take a look at the error message:
Cannot find module '/home/mangis/workspace/react-boilerplate/internals/scripts/setup.js'

Which means that the setup script is deleted because you've ran setup already!

k, Thanks :) I think this either should be notes in docs or make resilient for multiple runs (I dont know why but it gave me same error for the first time too, but this does not matters now as stuff works) ,
Thanks

It is noted in the docs. https://github.com/mxstbr/react-boilerplate/blob/master/docs/general/commands.md#initialization

:) Ok, my bad :D just looked first page and went straight to debug mode :)

I was just about to submit a report on this, but fortunately, I searched first...
I had a potential failure during the initial npm run setup (I use OSX, Little Snitch that catches and blocks suspicious connections.) I started the setup and left my computer for ~15 minutes. When I returned, LittleSnitch had asked "Did you want to connect...?" and the setup was paused.
I clicked OK, and setup seemed to complete without complaint. But since I was unsure if that might have perturbed the installation, I said, "Oh heck. Let's just run the setup again." And I got the error.
Proposals:

Don't worry about this. (I simply re-cloned the repo, and sat with the setup process running the second time.)
Detect the missing setup.js file and have the setup script mention that this could happen if it has been run twice.
Do something fancy with error recovery, etc. :-)

My preference would be 2 & 1 - mention that missing setup script could be due to running twice, and recommend that people re-clone the repo (since that's usually fast, and foolproof.)

Yeah, I guess that'd be nice @richb-hanover! PR maybe?

I opened #760 as a discussion addressing the need for improved setup UX. Can we move this discussion there?

@gihrig @mxstbr Yes, please feel free to close this issue and move the discussion elsewhere. I am totally content - the only reason for my initial post was to report the problem in the spirit of, "We promise not to fix it if we don't know it's broke."
You all seem to have this well in hand, so I will quietly drop out of sight :-)


NO_ISSUE: Let PVC use the default storageclass

Description
There should be a default storageclass in the cluster when this manifest is applied. No need to hard-code the storageclass.
Signed-off-by: Flavio Percoco<EMAIL_ADDRESS>Type of change
Please select the appropriate options:

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update
[ ] This change is a documentation update

Testing
@achuzhoy tested it :)
Test Configuration:

Versions:
Hardware:

Checklist

[ ] I have performed a self-review of my own code
[ ] If a change is adding a feature, it should require a change to the README.md and the review should catch this.
[ ] If the change is a fix, it should have an issue. The review should make sure the comments state the issue (not just the number) and it should use the keywords that will close the issue on merge.
[ ] A change should not be merged unless it passes CI or there is a comment/update saying what testing was passed.
[ ] PRs should not be merged unless positively reviewed.

/lgtm

Will get this in as it's breaking the QE pipeline


types_generator - get value from the type key - 2041

[Auto generated]
Number: [#2041]

openshift-python-wrapper[pull_request][5b3d-11ef-85b4-47f26f9d9c9a][PR 2041]: Closing issue for PR: types_generator - get value from the type key.
PR was closed.


Token Build Action not triggering Storefront Preview Action

When the token build action commits changes into a branch, the preview actions are not being triggered.
This should work in theory because the previews actions are listening to changes that are being commited.
I suspect that this is not working because the Token Action does not have the right permissions / secrets when it is received in the preview Actions.
https://docs.github.com/en/actions/security-guides/automatic-token-authentication#using-the-github_token-in-a-workflow
https://github.com/orgs/community/discussions/62346
From the Github team:
This is a deliberate decision by the Actions team in order to prevent accidental "infinite loop" situations, and as an anti-abuse measure. You will be able to work around this using a Personal Access Token in place of the provided token. As this needs to be explicitly provided it will remove any potential for possible abuse, so we recommend using this method when needing to create a pull request.

Ah, makes sense.


Change the color of the loader (spinner)

Is there any way how to change color of the loader (spinner) during changing pages in the table. The default is some kind of blue color and i didnt find this attributte in the cssClasses for a table. Is it possible to change it ?
thanks

See: https://github.com/swimlane/angular2-data-table/blob/master/src/themes/material.scss#L138


fix flaky test case test_auto_remount_with_subpath

Signed-off-by: Chris Chien<EMAIL_ADDRESS>Test case was flaky because timing issue in below steps
  4. Delete the statefulset replica instance manager pod.
       This action simulates a network disconnection.
  5. Wait for volume `healthy`, then verify the file checksum.

After volume healthy, we should add common.wait_for_pod_phase(core_api, pod_name, pod_phase="Pending") make sure pod is in recreating status then check pod remount
Otherwise sometimes pod is still in running status (not restart yet)  and wait_for_pod_remount return true, then script started checking data in pod, if at that moment pod just starting remount, script will get IO error
Here is 20 times test result on pipeline

ref: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase

ref: https://ci.longhorn.io/job/public/job/master/job/sles/job/amd64/job/longhorn-tests-sles-amd64/332/

@chriscchien Is this still flaky?
cc @longhorn/qa (please let me know if you know the answer)

This test case has passed in continues 7 days on test pipeline, looks like it is not flaky anymore, close this PR.


Reader pre-processor

We already have a writer pre-processor:
setting(:file) { |value| Pathname(value) }

But now, I'm in a use case where a reader pre-processor could also be useful.  In my case I would like to throw an error if an important setting is not set. I think it would be nice to do it in the configuration layer, because it is its outermost boundary.
I see that having a setting with both writer and reader pre-processors could look a bit clumsy:
setting(:file,
        reader: ->(value) { value || raise('+file+ setting must be defined') }
       ) { |value| Pathname(value) }

If we are not in a "don't break backwards compatibility" phase, we could instead do:
setting(:file,
        reader: ->(value) { value || raise('+file+ setting must be defined') },
        writer: ->(value) { Pathname(value) })

Or, in order not to break compatibility, we could make a single block default to a writer pre-processor.
What do you think about it?

@waiting-for-dev I like this idea, going to add 1.0 milestone and then we can break what we like lol
FWIW for 1.0 I also plan to address #8 and change the default value to a keyword argument (default)

Sounds good ;)
So, do you also think having both reader & writer options would be the best syntax? I think it is the most explicit and clear.

Yeah I think so too, then it could just default to identity function

@waiting-for-dev are you currently working on it? If not I would like to have a look see if I can implement it.

@GustavoCaso feel free to take it

Awesome @waiting-for-dev

BTW I think that we should use :setter and :getter rather than :reader and :writer so that we can leave :reader and :writer open for #8.

Hmm... I don't like setter and getter nomenclature... it's not that important, but I think is not idiomatic in Ruby. More importantly, it would be quite confusing to remember which pair does what...
If #8 is going to be implemented (I'm not sure it is a good idea), maybe we could call that pair forward_reader and forward_writter ?

Perhaps we could just go with something like:
setting :path,
        default: Dir.pwd,
        reader: ->(value) { value || raise('+file+ setting must be defined') },
        writer: ->(value) { Pathname(value) },
        accessor: true|symbol|string

I'd rather have support for dry-types than adding many options, ie:
Path = Types::Definition.new(Pathname).constructor(Kernel.method(:Pathname).default(Dir.pwd)

setting :path, Types::Path, reader: true # like proposed in issue #8

And I'm more than happy to add new methods to dry-types to make defining similar types more concise (which was the plan anyway).
WDYT?

@solnic I really like this, I think we need to make it the direction for 1.0

@solnic That looks awesome

It looks nice to integrate dry-types with dry-configuragion settings. It seems a perfect fit. However I have some concerns:

Path = Types::Definition.
new(Pathname).
 constructor(Kernel.method(:Pathname).
 default(Dir.pwd)

setting :path, Types::Path, reader: true

Don't you think is it overkilling having to write all of this to define a default value? Or maybe I'm a bit confused and you are talking more at an internal implementation level?

I'm not too familiar with dry-types. Would this allow to pre-process values on both read / write phases?

Having said that, I'm also a bit concerned the API would become a bit bloated adding so many named options, so I like this clear separation.

Don't you think is it overkilling having to write all of this to define a default value?

As I mentioned we can have simplified APIs in dry-types to make it very concise. I showed how it can be done already, which includes coercion using Pathname and a default value. You can also add a constraint that will check that the value is set. All these problems are solved in dry-types and its one of the ways of using this library. Coercions, constraints, default values, it's all there. Not to mention that types are small, reusable objects, and can be shared across multiple places in a system.

Or maybe I'm a bit confused and you are talking more at an internal implementation level?

Nope, I'm talking about using a type object to process a setting value. We just need a simpler API in dry-types for defining common things like this Path example.

I'm not too familiar with dry-types. Would this allow to pre-process values on both read / write phases?

Why would you want to pre-process when reading a value? A setting value should be processed once and stored. No need to pre-process many times.

As I mentioned we can have simplified APIs in dry-types to make it very concise.

Ok, then I like the idea. I just was concerned it was going to be cumbersome to use. If not, then I think dry-types is the perfect solution :)

Why would you want to pre-process when reading a value? A setting value should be processed once and stored. No need to pre-process many times.

Well, the main scenario I had in mind was raising an error on reading if the setting was not set, but you already mentioned that constraints could be checked by dry-types.
Another scenario would be a value that depends on current time. For example and OTP drift being 30 seconds from the time the value is accessed. I wonder if it could be nice to get the actual expiration time from dry-configuration or simply it would be better to wrap it in another method.
Also, one could have a setting which references the information to open a connection to some server. This is heavy, so maybe it could be nice to open it only if it is used at the reading time.

Another scenario would be a value that depends on current time. For example and OTP drift being 30 seconds from the time the value is accessed. I wonder if it could be nice to get the actual expiration time from dry-configuration or simply it would be better to wrap it in another method.

You can define a type with default using a proc and it will do exactly what you need (via dry-types), so no need to add special features to dry-configurable :)

Cool! :smile:

I should mention that we called this organization "dry" not just because it's short and sweet but because we'd like to...sort of remind people that dry is more about abstractions than about repeating the same word twice, that's why there's big focus on building good abstractions that are shared across the gems, while at the same time avoiding JS-like micro lib bloat. This is why I suggested using dry-types because it literally gives us everything we need for the functionality we'd like to have in dry-configurable.

Yep, it makes all the sense :+1:

It makes total sense. One question maybe is out of context, but after adding the Dry::Types compatibility into the gem, the user could still use it without the Dry::Types ?

@GustavoCaso yes this should optional

I showed how it can be done already, which includes coercion using Pathname and a default value.

@solnic Maybe I have misunderstood, but when I try to use this (seemingly already supported) form, it does not seem to work as intended.
# Authorizer. It will be called with a user instance.
Authorizer = ::Dry::Types::Definition.new(Proc)
  .constructor(proc do |value = nil|
    case value
    when Proc then value
    when Symbol, Method then value.to_proc
    when nil, false then proc { |_any| true }
    else raise "not supported"
    end
  end)
  .default(-> { proc { |_any| true } })

class Superclass
  setting :authorizer, Authorizer
end

class Subclass < Superclass
  config.authorizer = :admin?
end

# but what happens is:

Superclass.config.authorizer
# => the actual type, not the default value
Subclass.config.authorizer
# => just the symbol, the type constructor is not being called.

A partially working version (at least it constructs the type when a value is passed) is
class Superclass
  setting :authorization, &Authorizer.method(:call)
end

but still the default value is not used.
I am sure I'm missing something, could you point me to the right direction?

@AMHOL I think it would be great to continue with this feature

This feature has been added in this commit 1caa28e3b405db806aaf1dc09748e1213ec9bd08


Write test to make sure asset naming matches component

Description
This PR introduces a test to make sure that assets are named to match the component ruby file. This follows convention setup for view components and also allows us to write tests around this convention to match assest with their component.
app/components
  ├── component.rb
  ├── component.pcss
  ├── component.html.erb
  └── component.ts

Integration

Does this change require any updates to code in production?

no
Merge checklist

[x] Added/updated tests
[ ] Added/updated documentation
[ ] Added/updated previews

Hmm I'm not sure I'm in favor of this change. I learned recently that web components are required to include a hyphen in their names, eg. nav-list instead of navlist. Up until now it hasn't been a problem, but I was bitten last week by banner and flash. Apparently it's common to prefix single-word web component names with x-, so the custom element names are x-banner and x-flash. We have a prettier rule that forces the element name to match the file name, so I had to use x_banner.ts. I really don't want to have to name the component x_banner.rb and x_banner.html.erb too 😓

I can drop the ts file requirement. I do need the CSS files to match so I can build testing around class coverage


Use https for plotly-latest.min.js

Hi, this is a great project thank you.
Would it be possible to change the template to use https for plotly-latest.min.js please (consistent with all of the other js scripts)? Currently if I serve a peddy report via our internal https only server this causes browsers to display "insecure content warnings".
Thanks.

thanks!


link inserting creates data-mce-href="..."

When I insert a url using the link plugin, the scope result has a data-mce-href="..." attribute in it even though it's not there when I view the source code with the tinymce source code viewer. It is messing up a regex for me. Is there a way to not include data-mce-href, or am I missing a clean-up step somewhere?
scope variable:
http://www.gamespot.com/

view source code using tinymce:
http://www.gamespot.com/

I read on the official forum that data-mce-href should be only temporary

@WayneUong, can you please pose a link to the form post you read if you still have it handy.
I will see if I can re-create this issue, and try to decide if it is something we need to fix on our end.

So I confirmed even the latest version of ui-tinymce will add  data-mce=href="http://www.gamespot.com/" to the raw content of the editor.
In the latest version of ui-tinymce we change the default format to spit out their scrubbed 'html'. See the README.md for more information.
You on your model you should get the normal a tag as you would expect.
Try loading a link into this example and you should see it is all set.
If you are having any other issues please ask any questions using the angular-ui-tinymce tag on StackOverflow.
If you have any bugs please create a Plunker reproducing and open a new issue.


Crash on project Start

Godot version
4.0-stable
System information
XUbuntu, Macbook Pro mid-2011
Issue description
Whenever I try to open a project in 4.0, it just crashes almost instantly.
host@host-MacBookPro:~/Documents$ ./Godot_v4.0-stable_linux.x86_64
Godot Engine v4.0.stable.official.92bee43ad - https://godotengine.org
OpenGL API 3.3 (Core Profile) Mesa 22.2.5 - Compatibility - Using Device: nouveau - NVAF

Editing project: /home/host/New Game Project
Godot Engine v4.0.stable.official.92bee43ad - https://godotengine.org
Vulkan API 1.3.224 - Forward+ - Using Vulkan Device #0: Unknown - llvmpipe (LLVM 15.0.6, 128 bits)
host@host-MacBookPro:~/Documents$
WARNING: Blend file import is enabled in the project settings, but no Blender path is configured in the editor settings. Blend files will not be imported.
     at: _editor_init (modules/gltf/register_types.cpp:70)

================================================================
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.0.stable.official (92bee43adba8d2401ef40e2480e53087bcb1eaf1)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] /lib/x86_64-linux-gnu/libc.so.6(+0x42520) [0x7f3492c42520] (??:0)
[2] llvm::CmpInst::Create(llvm::Instruction::OtherOps, llvm::CmpInst::Predicate, llvm::Value*, llvm::Value*, llvm::Twine const&, llvm::BasicBlock*) (??:0)
-- END OF BACKTRACE --
================================================================

https://user-images.githubusercontent.com/91153148/222231184-0071d326-ac4b-46bc-989e-1206ca012124.mp4
Steps to reproduce
Open a project in 4.0-stable
Minimal reproduction project
.

Try creating a project with the Compatibility rendering method. If you converted an existing project to Godot 4, see https://github.com/godotengine/godot/issues/74159.

Try creating a project with the Compatibility rendering method instead of Forward+ or Mobile. The Nouveau driver doesn't support Vulkan, and the software Vulkan implementation (llvmpipe) is too slow to be usable for actual development.
If you converted an existing project to Godot 4, see my comment in https://github.com/godotengine/godot/issues/74159 to change it to use the Compatibility renderer.

Is there any reason that Forward+ did work on 3.5.1 but not in 4.0?

@HyperSilver69 because 3.x doesn't have Vulcan renderer. Compatibility renderer in 4.0 uses OpenGL.

Sorry for reopening the issue, however it seemed that the stated fix did not in fact fix anything.
Using Mobile didn't change anything, still crashing and no difference in the terminal, however when I tried using performance it also crashed but provided this instead:
Godot Engine v4.0.stable.official.92bee43ad - https://godotengine.org
OpenGL API 3.3 (Core Profile) Mesa 22.2.5 - Compatibility - Using Device: nouveau - NVAF

Editing project: /home/host/4.0
Godot Engine v4.0.stable.official.92bee43ad - https://godotengine.org
Vulkan API 1.3.224 - Forward Mobile - Using Vulkan Device #0: Unknown - llvmpipe (LLVM 15.0.6, 128 bits)
host@host-MacBookPro:~/Documents$
WARNING: Blend file import is enabled in the project settings, but no Blender path is configured in the editor settings. Blend files will not be imported.
     at: _editor_init (modules/gltf/register_types.cpp:70)

================================================================
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.0.stable.official (92bee43adba8d2401ef40e2480e53087bcb1eaf1)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] /lib/x86_64-linux-gnu/libc.so.6(+0x42520) [0x7f5cc6c42520] (??:0)
[2] llvm::CmpInst::Create(llvm::Instruction::OtherOps, llvm::CmpInst::Predicate, llvm::Value*, llvm::Value*, llvm::Twine const&, llvm::BasicBlock*) (??:0)
-- END OF BACKTRACE --
================================================================
host@host-MacBookPro:~/Documents$ ./Godot_v4.0-stable_linux.x86_64
Godot Engine v4.0.stable.official.92bee43ad - https://godotengine.org
OpenGL API 3.3 (Core Profile) Mesa 22.2.5 - Compatibility - Using Device: nouveau - NVAF

Editing project: /home/host/da
Godot Engine v4.0.stable.official.92bee43ad - https://godotengine.org
host@host-MacBookPro:~/Documents$ OpenGL API 3.3 (Core Profile) Mesa 22.2.5 - Compatibility - Using Device: nouveau - NVAF

WARNING: Blend file import is enabled in the project settings, but no Blender path is configured in the editor settings. Blend files will not be imported.
     at: _editor_init (modules/gltf/register_types.cpp:70)

================================================================
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.0.stable.official (92bee43adba8d2401ef40e2480e53087bcb1eaf1)
Dumping the backtrace. Please include this when reporting the bug to the project developer.

Do you have a way to install the proprietary NVIDIA driver? I'd recommend doing this as Nouveau is home to a lot of regressions, as it's the fruit of reverse engineering.

The crash is in the Nouveau driver. Do you have a way to install the proprietary NVIDIA driver? I'd recommend doing this as Nouveau is home to a lot of regressions, as it's the fruit of reverse engineering.

Note that it's also crash in llvmpipe when using Vulkan.

My recommendation for affected users would be to upgrade to a much more recent distro release that includes recent Mesa (e.g. Ubuntu 24.04).
If the GL Compatibility backend still crashes mentioning nouveau, then this should be reported as a bug to upstream Mesa: https://gitlab.freedesktop.org/mesa/mesa/-/issues
If the Vulkan backend still crashes with some llvm symbols, it means llvmpipe is still broken and this likewise should be reported to upstream Mesa: https://gitlab.freedesktop.org/mesa/mesa/-/issues
On our end, we should look into the possibility to detect these bad combinations of old GPU and Mesa versions and outright refuse to run Godot, without a segfault.

Also related: #82435.

Actually let's close this as duplicate of #82435, since that's what the original report was.
@HyperSilver69 If you still have a crash of the GL Compatibility backend involving nouveau_dri.so in the stacktrace, could you open a new issue to keep track of that one specifically?
The other crash you had when trying to use Forward+ or Mobile backends is tracked in #82435.


Catching errors of websocket initial connection

Is there a good way to catch the errors of the initial websocket connection on line 2389 of the sdk:
_this.websocketClient = new WebSocket(_this.uri);
If it can't make a connection, I can't figure out how to catch the error and then do something with it (i.e. notify the user, attempt a reconnect, etc.)

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: a765d478-6ca6-7555-dfc8-260e7adf7523
Version Independent ID: 211f0cc9-2958-98fe-17f2-cecdf5f57f40
Content: Quickstart: Recognize speech in JavaScript in a browser using the Speech Service SDK - Azure Cognitive Services
Content Source: articles/cognitive-services/Speech-Service/quickstart-js-browser.md
Service: cognitive-services
GitHub Login: @fmegen
Microsoft Alias: fmegen

@jpetitte Thanks for your feedback. I will investigate it and get back to you soon.

@fmegen Hi, do you have any insight on this issue? Thanks.

Hi,
please try the new version of the speech sdk and check if the issue still persists.
we made changes to the code to report the error as a connection open response with code 500.

@fmegen awesome, I'll give it a look!

#please-close

I'll give this a try as soon as I get a chance. Probably today.

I'm still seeing the same issue. Maybe I don't understand something, but this is the error that I'm struggling to catch for a reattempt at the connection if it initially can't resolve the domain name due to a network problem.
Please note my line numbers are going to be slightly different than those found in 1.2.0 below lines 3717.
 Thanks!

It seems that recognizer.canceled will actually handle this now. Thanks for the update!

#please-close


exports postgres.MigrateUp, call in *ranger.Ranger.Guide

Problem statement
Migrations run prematurely in app startup. In all use cases, app initialization means constructing a *ranger.Ranger before emitting properties from it for other app services, procedures, etc. Because migrations run when establishing the database connection, this is too early in an app's startup. Migrations should be the last operation before starting an app due to the unknowns reversing their schema and data changes.
As well, there are no longer any uses for running migrations when building a worker, so this change of use case needs to be updated in ranger.
Notion ticket
What this does
This PR exports postgres.MigrateUp so a *ranger.Range can call it in Guide. Guide is the final step in app startup since it begins accepting HTTP requests, so provides the best opportunity for delaying running migrations.
This PR removes ranger.WorkerConfig given the use for running migrations is no longer necessary.

🎉


DEPRECATION WARNING: connection_config is deprecated and will be removed from Rails 6.2 (Use connection_db_config instead)

I'm using flipper & related gems that are locked in the below version.
    flipper (0.20.3)
    flipper-active_record (0.20.3)
      activerecord (>= 5.0, < 7)
      flipper (~> 0.20.3)
    flipper-ui (0.20.1)
      erubi (>= 1.0.0, < 2.0.0)
      flipper (~> 0.20.1)
      rack (>= 1.4, < 3)
      rack-protection (>= 1.5.3, < 2.2.0)

We are getting this deprecation from rails(6.1.1).

There is nothing in flipper related to connection_config. I believe this is something related to active record (see this), since you are using the active record adapter. Likely you have memoization on and are preloading, so flipper is the first thing that pops the deprecation warning, but I don't believe this is flipper directly.
Please let me know if I'm wrong.

There is nothing in flipper related to connection_config. I believe this is something related to active record (see this), since you are using the active record adapter. Likely you have memoization on and are preloading, so flipper is the first thing that pops the deprecation warning, but I don't believe this is flipper directly.
Please let me know if I'm wrong.

I had the same issue and @jnunemaker was correct - it isn't flipper's fault, it's just that flipper was the first thing to pop the warning.
For me it was actually the money-rails gem causing the problem. Upgrading to 1.13.4 fixed it. That might be totally unrelated to what's causing the problem in your app, but just thought I would mention it in case it helps you out :+1:

@ClaytonPassmore thanks for confirming and adding more details for the next person!


add raise hand component with conditional build

What

Why

How Tested

Process & policy checklist

[ ] I have updated the project documentation to reflect my changes if necessary.
[ ] I have read the CONTRIBUTING documentation.

Is this a breaking change?

[ ] This change causes current functionality to break.

https://azure.github.io/communication-ui-library/iframe.html?viewMode=docs&id=statefulclient-reacthooks-usepropsfor--page#usepropsfor-calling-app-example
Can we test all of these apis for selector and usePropsFor working well based on this code snippet? We don't currently have too much code to test these apis, so would be nice if you could test them locally

https://azure.github.io/communication-ui-library/iframe.html?viewMode=docs&id=statefulclient-reacthooks-usepropsfor--page#usepropsfor-calling-app-example
Can we test all of these apis for selector and usePropsFor working well based on this code snippet? We don't currently have too much code to test these apis, so would be nice if you could test them locally

https://github.com/Azure/communication-ui-library/tree/main/samples/ComponentExamples
And this is the sample you might wanna take a look if you wanna test this locally