make simpletest fails on tests/io/tri

with icestorm from master, yosys from master and arachne-pnr from master

Build log
+ ../../bin/arachne-pnr tri.blif -o tri.txt
seed: 1
device: 1k
read_chipdb +/share/arachne-pnr/chipdb-1k.bin...
  supported packages: cb121, cb132, cb81, cm121, cm36, cm49, cm81, qn84, swg16tr, tq144, vq100
read_blif tri.blif...
prune...
instantiate_io...
pack...

After packing:
IOs          6 / 96
GBs          0 / 8
  GB_IOs     0 / 8
LCs          2 / 1280
  DFF        0
  CARRY      0
  CARRY, DFF 0
  DFF PASS   0
  CARRY PASS 0
BRAMs        0 / 16
WARMBOOTs    0 / 1
PLLs         0 / 1

place_constraints...
promote_globals...
  promoted 0 nets
  0 globals
realize_constants...
place...
  initial wire length = 133
  at iteration #50: temp = 6.39439, wire length = 68
  at iteration #100: temp = 2.67362, wire length = 17
  at iteration #150: temp = 0.022659, wire length = 9
  final wire length = 9

After placement:
PIOs       4 / 96
PLBs       2 / 160
BRAMs      0 / 16

  place time 0.01s
route...
  pass 1, 0 shared.

After routing:
span_4     0 / 6944
span_12    0 / 1440

  route time 0.00s
write_txt tri.txt...
+ icebox_vlog -s tri.txt
+ '[' -e tri.v ']'
+ diff -u tri.v out-tri.v
--- tri.v	2018-06-19 20:44:09.419402495 +0300
+++ out-tri.v	2018-06-19 20:49:53.384751024 +0300
@@ -6,8 +6,8 @@
 // IO Cell (0, 9, 1)
 assign io_0_9_1 = n4 ? n2 : 1'bz;

-assign n8 = /* LUT    1  9  3 */ 1'b0 ? 1'b0 : io_0_10_1 ? io_0_8_0 ? 1'b1 : 1'b0 : io_0_9_0 ? 1'b1 : 1'b0;
-assign n9 = /* LUT    1 10  5 */ 1'b0 ? 1'b0 : 1'b0 ? 1'b0 : io_0_10_1 ? io_0_10_0 ? 1'b1 : 1'b0 : 1'b1;
+assign n8 = /* LUT    1  9  3 */ (io_0_10_1 ? io_0_8_0 : io_0_9_0);
+assign n9 = /* LUT    1 10  5 */ (io_0_10_1 ? io_0_10_0 : 1'b1);
 /* FF  1  9  3 */ assign n2 = n8;
 /* FF  1 10  5 */ assign n4 = n9;

make: *** [Makefile:109: test] Error 1

This is a result of the recent changes to icebox_vlog changing the golden values. Will update when I have a chance in the next few days (unless you are OK making a PR for this).


[WIP] feat:Polynomial FLT

WIP

@jcpaik Could you help me to remove sorrys? Also, flt_catalan_aux haven't fixed yet.

@YaelDillies Could you review this?

Sorry, I really don't have time right now 😦 Please ask again in ten days if it hasn't moved


[5.3] Custom casting of eloquent properties

currently we gets dates autocast to Carbon objects, and we can cast any property to primitive types.
this PR allows us to cast properties to our own custom-defined types (usually objects i'm guessing).
Here is my use case.  I have an Order model that has subtotal, tax, shipping, and total fields.  I want them all to be instances of the new Money\Money class, so I can work with monetary values easier. To do this I would simply set these fields in my cast property:
protected $casts = [
    'subtotal' => 'money',
    'tax'          => 'money',
    'shipping' => 'money',
    'total'        => 'money,
];

Then I just need to define a castToMoney() method on the class:
public function castToMoney($value)
{
    return new \Money\Money($value, new \Money\Currency('USD'));
}

Now when accessing the property on the model, it would automatically give me back the Money object:
$order = \App\Order::first();

$order->total;  //returns Money object

$order->total->getAmount(); //returns the value e.g. 127

I think the easiest way to define these 'cast methods' would be as a trait that was imported to models where it was needed. If your models extended a base class, it could also be defined there.
I wasn't able to a good test for how this behaves when the model is turned into an array ($order->toArray()). wondering what thoughts would be for this.
I can foresee someone saying why not just define the property with an 'Accessor'. My argument would be that's fine for 1-off field manipulation, but when you are doing the same casting over and over this an easier more consistent way.  If you ever need to swap out one of these 'cast methods' you can do it in one place.
Thanks for any feedback.

Is your Money class immutable, or can its value change?
What happens when you change it, and then save your model?
With your current implementation, the record in the database will not be updated.

I believe we should consider get and set casters. I made something related to this in my package. However, I think @JosephSilber does have a point.

Is it worth revisiting my implementation of this? https://github.com/laravel/framework/pull/13706

I think so. How would #13706 work with packages? would we have to subclass to add the 2 methods?
the specific package I sent this PR for was because of https://github.com/moneyphp/money
unfortunately they make their Money class final so I'm not sure how we could make this integrate.

Blah, final classes are so supersitious. :(
I’ll have to think on that.

Custom casts would mean less / no changes are necessary in core for https://github.com/laravel/internals/issues/293

i feel like maybe we should close my PR.  I feel like this may be a bigger issue that needs to be thought out, with a good plan of action.  just trying to avoid having the PR sit in limbo.
thoughts?

@browner12 https://github.com/laravel/framework/pull/16460 was another attempt on this with more control but also got closed.

Yeah, I think this particular implementation is not going to be preferred because the modifications of the casted models do not get synced back into the model before save. My PR does not that but as noted will not work with "final" classes since they are artificially restrict developer freedom unfortunately. ☹

that's fine by me. thanks for closing this. hopefully we can find some solution for this.


C4019: Warning is no longer reproduced with given example for new versions of Visual Studio

It's either issue with example in documentation, bug in a compiler or warning is deprecated.
Here's my reproduction:
https://gcc.godbolt.org/z/aPzb5zW51
If the example is correct, I can report it to Visual Studio bug tracker.
If warning is not supposed to work anymore, should be marked as deprecated.

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

ID: 57ffc081-160d-8a89-18ed-721f4c9314f8
Version Independent ID: dfea9bd6-4358-5cb9-1b82-7dacce30b1e9
Content: Compiler Warning (level 4) C4019
Content Source: docs/error-messages/compiler-warnings/compiler-warning-level-4-c4019.md
Product: visual-cpp
Technology: cpp-diagnostics
GitHub Login: @TylerMSFT
Microsoft Alias: twhitney

I repro'd this. Looking into it.

Hi, this warning only applies to C programs (not C++ programs).
I tried VS 2022 17.8.3 (Compiler Version 19.38.33133 for x86) and it worked fine.
I've updated the article to indicate that it only applies to C programs. It'll be live sometime Monday afternoon.

Thanks, I guess  /TC could be added to command line in example to make it more clear as well.

@sumushin-s > Thanks, I guess /TC could be added to command line in example to make it more clear as well.
It already emphasizes that the example is in C and the file name ends in .c.  /TC is overkill.  I am thinking the emphasis in the text will be fine.


Add toastAndroid module bindings from Rebolt.

Add toastAndroid module bindings from Rebolt.

It looks good to me although I believe we should use labels for the x/y offsets.

I have updated the interface. Unfortunately, due to really bad API from the React Native side (multiple show methods with no clear default parameter), I was unable to provide a single, unified, entry-point with optional labels.
Decided to follow the Animated API where the first argument is provided and rest that follows are labels. I think it matches the overall API pretty nice.

We could provide a unified show method but in case the user provides offset and no gravity, there's no native React Native method to call. In that case, we would have to assume the default value for "gravity" which is unclear and not described in React Native docs. Question is, whether we should make such default for better API sake?
Essentially, it would be a single switch/case statement checking on the arguments provided and calling the appropriate native method.

Here's the method with alternative API:
let betterShow = (message, ~duration, ~gravity=?, ~offset=?, ()) =>
	switch ((gravity, offset)) {
	| (None, None) => _show(message, getDuration(duration))
	| (Some(gravity), None) => _showWithGravity(message, getDuration(duration), getGravity(gravity))
	| (Some(gravity), Some((x, y))) => _showWithGravityAndOffset(message, getDuration(duration), getGravity(gravity), x, y)
	| (None, Some((x, y))) => _showWithGravityAndOffset(message, getDuration(duration), getGravity(CENTER), x, y)
	}

Note that the last case assumes "CENTER" is the default when offset is set. We don't have showWithOffset method on the native side and so, we need to put a default.


Support using rflint for a open file

Run rflint for open file

The pull request provides support for this issue.


Update DG

Closes #113

Format DG and readme
Update UI Class Diagram in DG
Include Add Course feature

LGTM!


Detect unexpected server crashes

The current framework will hang if one of the underlying servers crashes.  It needs to actually detect this, determine that the test is failed, and shut down.

Ideally, this problem would be addressed by inverting the responsibilities of the main thread so that it no longer directly orders, drives, and waits for the clients.
Instead, the main thread should just wait for all processes to terminate, and then exit.  It could then act essentially as a co-routine:  taking actions based on the lifecycles of the underlying processes.
The open question, in this case, is how involved it should become in some of the other process termination and restart scenarios.  Specifically, if a server process was deliberately terminated by the test, should the main thread know about this (potentially the test first marked it as "expected to terminate", for example) or is this a "closed" operation, not relevant to the overall "health" of the test?
Beyond that, the clients could be managed by a single additional thread and their lifecycles managed exactly as they are today.  The only difference is that this will need to be a special kind of thread which the main could externally interrupt in order to break them out of the wait on clients.


Implement some standard gates in rust

This PR implements some of the standard gates in Rust, building on the few examples in #12459

This PR is blocked by #12459.
Here is the diff taking #12459 as the base: https://github.com/mtreinish/qiskit-core/compare/gates-in-rust...jlapeyre:qiskit-core:new-some-gates-in-rust
At the moment only one gate is implemented here:
Implement RGate in Rust according to established pattern
All the things are done to implement R(theta, phi) in Rust to the according to the pattern
set in the gates-in-rust PR. The "definition" is left as a todo again following the same
pattern.
Implementing this is rather clumsy and laborious. Moving more gates would of
course be a bit easier. But some of this is due to interfaces beyond our control. We could
probably add a few conveniences that would make a difference. For example implementing
some conveniences for complex numbers.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

1810 of 2130 (84.98%)  changed or added relevant lines in 37 files are covered.
83 unchanged lines in 5 files lost coverage.
Overall coverage decreased (-0.2%) to 89.384%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit/circuit/quantumcircuit.py
110
112
98.21%

crates/circuit/src/imports.rs
31
39
79.49%

crates/circuit/src/parameter_table.rs
90
100
90.0%

crates/circuit/src/circuit_instruction.rs
579
595
97.31%

crates/circuit/src/circuit_data.rs
463
523
88.53%

crates/circuit/src/operations.rs
375
599
62.6%

Files with Coverage Reduction
New Missed Lines
%

qiskit/transpiler/passes/synthesis/unitary_synthesis.py
2
88.2%

crates/qasm2/src/lex.rs
6
91.86%

qiskit/qasm3/init.py
10
70.0%

crates/qasm2/src/parse.rs
18
96.69%

crates/circuit/src/circuit_data.rs
47
89.45%

Totals

Change from base Build<PHONE_NUMBER>:
-0.2%

Covered Lines:
63866

Relevant Lines:
71451

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

1824 of 2177 (83.79%)  changed or added relevant lines in 36 files are covered.
22 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-0.2%) to 89.368%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit/circuit/quantumcircuit.py
123
125
98.4%

crates/circuit/src/imports.rs
31
39
79.49%

crates/circuit/src/parameter_table.rs
90
100
90.0%

crates/circuit/src/circuit_instruction.rs
496
513
96.69%

crates/circuit/src/circuit_data.rs
509
590
86.27%

crates/circuit/src/operations.rs
408
643
63.45%

Files with Coverage Reduction
New Missed Lines
%

crates/qasm2/src/expr.rs
1
94.02%

crates/qasm2/src/lex.rs
3
92.37%

crates/qasm2/src/parse.rs
18
96.23%

Totals

Change from base Build<PHONE_NUMBER>:
-0.2%

Covered Lines:
63864

Relevant Lines:
71462

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

1830 of 2175 (84.14%)  changed or added relevant lines in 36 files are covered.
3 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.2%) to 89.415%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit/circuit/quantumcircuit.py
123
125
98.4%

crates/circuit/src/parameter_table.rs
90
100
90.0%

crates/circuit/src/circuit_instruction.rs
496
513
96.69%

crates/circuit/src/circuit_data.rs
509
590
86.27%

crates/circuit/src/operations.rs
408
643
63.45%

Files with Coverage Reduction
New Missed Lines
%

crates/qasm2/src/lex.rs
3
92.11%

Totals

Change from base Build<PHONE_NUMBER>:
-0.2%

Covered Lines:
63896

Relevant Lines:
71460

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

1829 of 2183 (83.78%)  changed or added relevant lines in 36 files are covered.
16 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-0.2%) to 89.381%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit/circuit/quantumcircuit.py
123
125
98.4%

crates/circuit/src/parameter_table.rs
90
100
90.0%

crates/circuit/src/circuit_instruction.rs
496
513
96.69%

crates/circuit/src/circuit_data.rs
509
590
86.27%

crates/circuit/src/operations.rs
408
652
62.58%

Files with Coverage Reduction
New Missed Lines
%

crates/qasm2/src/expr.rs
1
94.02%

crates/qasm2/src/lex.rs
3
91.86%

crates/qasm2/src/parse.rs
12
97.15%

Totals

Change from base Build<PHONE_NUMBER>:
-0.2%

Covered Lines:
63879

Relevant Lines:
71468

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

1829 of 2182 (83.82%)  changed or added relevant lines in 36 files are covered.
22 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.2%) to 89.381%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit/circuit/quantumcircuit.py
123
125
98.4%

crates/circuit/src/parameter_table.rs
90
100
90.0%

crates/circuit/src/circuit_instruction.rs
496
513
96.69%

crates/circuit/src/circuit_data.rs
509
590
86.27%

crates/circuit/src/operations.rs
408
651
62.67%

Files with Coverage Reduction
New Missed Lines
%

crates/qasm2/src/lex.rs
4
92.37%

crates/qasm2/src/parse.rs
18
96.69%

Totals

Change from base Build<PHONE_NUMBER>:
-0.2%

Covered Lines:
63878

Relevant Lines:
71467

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

1829 of 2182 (83.82%)  changed or added relevant lines in 36 files are covered.
11 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-0.2%) to 89.392%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit/circuit/quantumcircuit.py
123
125
98.4%

crates/circuit/src/parameter_table.rs
90
100
90.0%

crates/circuit/src/circuit_instruction.rs
496
513
96.69%

crates/circuit/src/circuit_data.rs
509
590
86.27%

crates/circuit/src/operations.rs
408
651
62.67%

Files with Coverage Reduction
New Missed Lines
%

crates/qasm2/src/expr.rs
1
94.02%

crates/qasm2/src/lex.rs
4
92.11%

crates/qasm2/src/parse.rs
6
97.61%

Totals

Change from base Build<PHONE_NUMBER>:
-0.2%

Covered Lines:
63886

Relevant Lines:
71467

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

1930 of 2283 (84.54%)  changed or added relevant lines in 45 files are covered.
64 unchanged lines in 5 files lost coverage.
Overall coverage decreased (-0.2%) to 89.36%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit/circuit/quantumcircuit.py
133
135
98.52%

crates/circuit/src/parameter_table.rs
90
100
90.0%

crates/circuit/src/circuit_instruction.rs
496
513
96.69%

crates/circuit/src/circuit_data.rs
528
609
86.7%

crates/circuit/src/operations.rs
408
651
62.67%

Files with Coverage Reduction
New Missed Lines
%

crates/accelerate/src/sparse_pauli_op.rs
1
93.27%

crates/qasm2/src/lex.rs
2
92.88%

qiskit/circuit/parameterexpression.py
5
96.51%

crates/qasm2/src/parse.rs
24
95.77%

crates/circuit/src/circuit_data.rs
32
89.21%

Totals

Change from base Build<PHONE_NUMBER>:
-0.2%

Covered Lines:
63840

Relevant Lines:
71441

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

1930 of 2283 (84.54%)  changed or added relevant lines in 45 files are covered.
52 unchanged lines in 5 files lost coverage.
Overall coverage decreased (-0.2%) to 89.376%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit/circuit/quantumcircuit.py
133
135
98.52%

crates/circuit/src/parameter_table.rs
90
100
90.0%

crates/circuit/src/circuit_instruction.rs
496
513
96.69%

crates/circuit/src/circuit_data.rs
528
609
86.7%

crates/circuit/src/operations.rs
408
651
62.67%

Files with Coverage Reduction
New Missed Lines
%

crates/accelerate/src/sparse_pauli_op.rs
1
93.27%

crates/qasm2/src/lex.rs
2
92.62%

qiskit/circuit/parameterexpression.py
5
96.51%

crates/qasm2/src/parse.rs
12
96.69%

crates/circuit/src/circuit_data.rs
32
89.21%

Totals

Change from base Build<PHONE_NUMBER>:
-0.2%

Covered Lines:
63851

Relevant Lines:
71441

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

1930 of 2283 (84.54%)  changed or added relevant lines in 45 files are covered.
42 unchanged lines in 5 files lost coverage.
Overall coverage decreased (-0.2%) to 89.401%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit/circuit/quantumcircuit.py
133
135
98.52%

crates/circuit/src/parameter_table.rs
90
100
90.0%

crates/circuit/src/circuit_instruction.rs
496
513
96.69%

crates/circuit/src/circuit_data.rs
528
609
86.7%

crates/circuit/src/operations.rs
408
651
62.67%

Files with Coverage Reduction
New Missed Lines
%

crates/qasm2/src/expr.rs
1
94.02%

crates/accelerate/src/sparse_pauli_op.rs
1
93.27%

crates/qasm2/src/lex.rs
3
92.88%

qiskit/circuit/parameterexpression.py
5
96.51%

crates/circuit/src/circuit_data.rs
32
89.21%

Totals

Change from base Build<PHONE_NUMBER>:
-0.2%

Covered Lines:
63869

Relevant Lines:
71441

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

1808 of 2151 (84.05%)  changed or added relevant lines in 44 files are covered.
17 unchanged lines in 5 files lost coverage.
Overall coverage decreased (-0.2%) to 89.39%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit/circuit/quantumcircuit.py
123
125
98.4%

crates/circuit/src/imports.rs
48
55
87.27%

crates/circuit/src/parameter_table.rs
90
100
90.0%

crates/circuit/src/circuit_instruction.rs
450
467
96.36%

crates/circuit/src/circuit_data.rs
485
548
88.5%

crates/circuit/src/operations.rs
376
620
60.65%

Files with Coverage Reduction
New Missed Lines
%

crates/qasm2/src/expr.rs
1
94.02%

crates/accelerate/src/sparse_pauli_op.rs
1
93.27%

crates/qasm2/src/lex.rs
3
92.62%

qiskit/qasm2/parse.py
6
96.7%

crates/qasm2/src/parse.rs
6
97.61%

Totals

Change from base Build<PHONE_NUMBER>:
-0.2%

Covered Lines:
63778

Relevant Lines:
71348

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

1781 of 2115 (84.21%)  changed or added relevant lines in 44 files are covered.
11 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-0.2%) to 89.4%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit/circuit/quantumcircuit.py
123
125
98.4%

crates/circuit/src/imports.rs
48
55
87.27%

crates/circuit/src/parameter_table.rs
90
100
90.0%

crates/circuit/src/circuit_instruction.rs
450
467
96.36%

crates/circuit/src/circuit_data.rs
485
544
89.15%

crates/circuit/src/operations.rs
349
588
59.35%

Files with Coverage Reduction
New Missed Lines
%

crates/accelerate/src/sparse_pauli_op.rs
1
93.27%

crates/qasm2/src/lex.rs
4
91.35%

qiskit/qasm2/parse.py
6
96.7%

Totals

Change from base Build<PHONE_NUMBER>:
-0.2%

Covered Lines:
63753

Relevant Lines:
71312

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

1783 of 2116 (84.26%)  changed or added relevant lines in 44 files are covered.
20 unchanged lines in 5 files lost coverage.
Overall coverage decreased (-0.2%) to 89.396%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit/circuit/quantumcircuit.py
124
126
98.41%

crates/circuit/src/imports.rs
48
55
87.27%

crates/circuit/src/parameter_table.rs
90
100
90.0%

crates/circuit/src/circuit_instruction.rs
450
467
96.36%

crates/circuit/src/circuit_data.rs
485
544
89.15%

crates/circuit/src/operations.rs
350
588
59.52%

Files with Coverage Reduction
New Missed Lines
%

crates/qasm2/src/expr.rs
1
94.02%

crates/accelerate/src/sparse_pauli_op.rs
1
93.27%

qiskit/qasm2/parse.py
6
96.7%

crates/qasm2/src/lex.rs
6
92.11%

crates/qasm2/src/parse.rs
6
97.61%

Totals

Change from base Build<PHONE_NUMBER>:
-0.2%

Covered Lines:
63749

Relevant Lines:
71311

💛  - Coveralls

I am closing this in favor of splitting this PR into two parts.

Part of this PR will be done instead in #12651


Update tapir-core, tapir-http4s-server, ... to 1.8.0

About this PR
📦 Updates

com.softwaremill.sttp.tapir:tapir-core
com.softwaremill.sttp.tapir:tapir-http4s-server
com.softwaremill.sttp.tapir:tapir-json-circe
com.softwaremill.sttp.tapir:tapir-openapi-docs
com.softwaremill.sttp.tapir:tapir-refined
com.softwaremill.sttp.tapir:tapir-swagger-ui

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

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.softwaremill.sttp.tapir" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "com.softwaremill.sttp.tapir" }
}]

labels: library-update, early-semver-minor, semver-spec-minor, version-scheme:early-semver, commit-count:1

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

Comparison is base (0556254) 50.00% compared to head (156d02b) 50.00%.
Report is 2 commits behind head on develop.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff            @@
##           develop     #476   +/-   ##
========================================
  Coverage    50.00%   50.00%
========================================
  Files            5        5
  Lines           84       84
========================================
  Hits            42       42
  Misses          42       42

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


checkInterval field was refactored to checkIntervalMsec

checkInterval field in the options of the SystemHealthMonitor's constructor was refactored to checkIntervalMsec (fixes #3)

Pull Request Test Coverage Report for Build 15

3 of 13 (23.08%) changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 69.507%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

index.js
3
13
23.08%

Totals

Change from base Build 12:
0.0%

Covered Lines:
115

Relevant Lines:
144

💛  - Coveralls

Pull Request Test Coverage Report for Build 15

3 of 13 (23.08%) changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 69.507%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

index.js
3
13
23.08%

Totals

Change from base Build 12:
0.0%

Covered Lines:
115

Relevant Lines:
144

💛  - Coveralls


autorip from clipboard not working on hentai.cafe

Ripme version: lastest

autorip from clipboard not working on hentai.cafe, other links work pretty good, i dont know why...or it's because .cafe domain ?

so it can fixed ?

@wankio It seems like can be fixed, I'll get on it today

@wankio I've managed to fix it, the fix should be out in the 1.7.17 update

The issue was this monster of a regex, which doesn't match all possible domains
"\\b(((ht|f)tp(s?)://|~/|/)|www.)" +
"(\\w+:\\w+@)?(([-\\w]+\\.)+(com|org|net|gov" +
"|mil|biz|info|mobi|name|aero|jobs|museum" +
"|travel|[a-z]{2}))(:[\\d]{1,5})?" +
"(((/([-\\w~!$+|.,=]|%[a-f\\d]{2})+)+|/)+|\\?|#)?" +
"((\\?([-\\w~!$+|.,*:]|%[a-f\\d{2}])+=?" +
"([-\\w~!$+|.,*:=]|%[a-f\\d]{2})*)" +
"(&(?:[-\\w~!$+|.,*:]|%[a-f\\d{2}])+=?" +
"([-\\w~!$+|.,*:=]|%[a-f\\d]{2})*)*)*" +
"(#([-\\w~!$+|.,*:=]|%[a-f\\d]{2})*)?\\b");

It should be changed to match anything starting with "http://" or "https://" and ending in .*

oh it's so fast.. thank you
..... some gallery have chapter like this : https://hentai.cafe/saitom-saitom-box/ ....but seem like it only can download first chapter

but seem like it only can download first chapter

yup. I'll add support for multi chapter ripping in the next few days


Vespa not able to start the content node on Azure File mount in Kubernetes even though the drives are mounted properly.

I've been able to run apps in Azure Kubernetes Services but Vespa fails to start when I mount /opt/vespa/var to a persistent volume. The Azure file mounts work since logs and files are written inside them when deploying the pod. Basically everything seems fine when deploying the pods, and I get no error messages when I run:
kubectl exec vespa-0 -n vespa -- bash -c "/opt/vespa/bin/vespa-deploy prepare /vespa-app && /opt/vespa/bin/vespa-deploy activate"
But we I try to load data or reach documents at http:/myip:8080/document/v1/{mynamespace}/{mydocumenttype}/docid/1, the connection times out.
I think I located the error in the logs, it seems like content cluster can't even start.

1620740689.020670	vespa-0.vespa.vespa.svc.cluster.local	1574/5916	searchnode	proton.transactionlog.server	warning	Failed creating tickets domain. Exception = IoException: NO PERMISSION: sync(tls/tls/tls.domains.tmp): Failed, errno(13): Permission denied at sync in /builddir/build/BUILD/vespa-7.398.17/vespalib/src/vespa/vespalib/io/fileutil.cpp:408\nBacktrace:\n  /opt/vespa/lib64/libvespalib.so(vespalib::IoException::IoException(vespalib::stringref, vespalib::IoException::Type, vespalib::stringref, int)+0x41) [0x7f53cc1c7c71]\n  /opt/vespa/lib64/libvespalib.so(+0x1be077) [0x7f53cc073077]\n  /opt/vespa/lib64/libvespalib.so(vespalib::File::sync(vespalib::stringref)+0x36) [0x7f53cc102ae6]\n  /opt/vespa/lib64/libsearchlib.so(+0xaf46a7) [0x7f53ce3e26a7]\n  /opt/vespa/lib64/libsearchlib.so(search::transactionlog::TransLogServer::createDomain(FRT_RPCRequest*)+0x654) [0x7f53ce3e39b4]\n  /opt/vespa/lib64/libsearchlib.so(search::transactionlog::TransLogServer::run()+0x35b) [0x7f53ce3e401b]\n  /opt/vespa/lib64/libstaging_vespalib.so(document::Runnable::Run(FastOS_ThreadInterface*, void*)+0x50) [0x7f53cc3321d0]\n  /opt/vespa/lib64/libfastos.so(FastOS_ThreadInterface::Hook()+0x125) [0x7f53cbe92e85]\n  /opt/vespa/lib64/libfastos.so(FastOS_ThreadHook+0x9) [0x7f53cbe93019]\n  /opt/vespa/lib64/vespa/malloc/libvespamalloc.so(+0x6a4b) [0x7f53cf7a0a4b]\n  /lib64/libpthread.so.0(+0x7ea5) [0x7f53cba59ea5]\n  /lib64/libc.so.6(clone+0x6d) [0x7f53c3fc79fd]
1620740689.055689	vespa-0.vespa.vespa.svc.cluster.local	1574	searchnode	stderr	warning	terminate called after throwing an instance of 'std::runtime_error'
1620740689.086873	vespa-0.vespa.vespa.svc.cluster.local	1574	searchnode	stderr	warning	  what():  Failed creating domain 'tickets' on TLS 'tcp/vespa-0.vespa.vespa.svc.cluster.local:19111'
1620740689.272948	vespa-0.vespa.vespa.svc.cluster.local	1228/29549	config-sentinel	config-sentinel.service	event	crash/1 name="searchnode" pid=1574 signal="Aborted"

I tried to set mountOptions in Kubernetes such as:

mountOptions:
- dir_mode=0777
- file_mode=0777
- mfsymlinks
- nobrl
- uid=0
- gid=0

But nothing seems to fix it.
I think this could be an issue with Azure File similar to this one: https://github.com/MicrosoftDocs/azure-docs/issues/16481
Any help would be very much appreciated. Thanks.

Have you verified the limitations in https://docs.microsoft.com/en-us/azure/container-instances/container-instances-volume-azure-files ?
I would assume especially "Azure file share volume mount requires the Linux container run as root ." is important.

Hi @baldersheim, yeah, I did try running the container as root as such when starting the node:

spec:
  securityContext:
    runAsUser: 0
    runAsGroup: 0

'0' being root user and group. Unfortunately it didn't work.
The good news though is that I spoke with @andreer in your public Slack and I realized that I don't actually need to use Azure File. See, I was under the impression that I needed to have my storage mounted as "ReadWriteMany " so that the storage could be shared between nodes. Azure File is the only way to do that in Azure.
But I apparently don't need to do that and can simply spin up Azure Disks mounted as "ReadWriteOnce" for each node, since the Vespa nodes will share the content themselves. Azure Disks mounted as ReadWriteOnce do work for me without issue, so I can go forward with my deployment.
The issue still stands with Azure File, but it seems like a non-starter since this is not needed, so you could close it if you want.
Thanks for your help!

We made the error on sync non fatal. That might help figuring out what the root cause really is. That will be present in the next release.

Error on sync not being fatal is part of Vespa 7.404.14.

For posterity and if someone comes across a similar issue, I spoke with Azure support and they suggested I try creating the storage with the Azure Files Container Storage Interface https://docs.microsoft.com/en-us/azure/aks/azure-files-csi.
They also suggested trying a different storage protocol or file system type when setting up Azure File through the CSI: https://github.com/kubernetes-sigs/azurefile-csi-driver/blob/master/docs/driver-parameters.md#dynamic-provision
I haven't tried it since I don't have this problem anymore.


add rust support

There are Rust bindings in the crate spirv_cross and an alternative pure Rust shader translator in the crate naga

would it be beneficial to provide NLP LLM API to the spirv_cross/naga via
HTTP interface?
On Sat, Jun 10, 2023 at 3:49 PM Josh Groves @.***>
wrote:

There are Rust bindings in the crate spirv_cross
https://github.com/grovesNL/spirv_cross and an alternative pure Rust
shader translator in the crate naga https://github.com/gfx-rs/naga
—
Reply to this email directly, view it on GitHub
https://github.com/KhronosGroup/SPIRV-Cross/issues/2164#issuecomment-1585652089,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BAHYDCW6MP53O4GX7XXX5HTXKRUM7ANCNFSM6AAAAAAZBTA3CI
.
You are receiving this because you authored the thread.Message ID:
@.***>


Batch operation rate limit

What changed?
Updating API to include https://github.com/temporalio/api/pull/318:

Adding (optional) requestsPerSecond for batch operations to limit their rate.

Why?
To fix https://github.com/temporalio/temporal/issues/4926.

How did you test it?

Potential risks

@stephanos - this repo is automatically updated with merge from the api repo. You don't need a PR unless you are altering non-generated code.

@cretz ohh, I didn't realize that! Then I'll close this PR 👍


Lambda's not working recursively

should create separate tests for mixinIsle

Diagnosis:

the variable is not being passed into the distribution within lambda.
flattening is too drastic: it prevents there being two variables of the same type.

Nothing seems to be generated without pair moves.

Move.appl a dud

In simple examples, no iterated lambdas are created.
Bug is not because of flattening.

It is not just that lambdas are not recursive, no moves are happening in islands.
problem persists when normalization is removed.

Silly mistake: lambdaFn in HoTTgen made no use of f being passed: just included and exported.

Silly mistakes corrected. Now works and gives Modus Ponens (at depth 3, starting with A and B).


removing features

So far (on master), slated for removal (and currently with compiler notices upon use):

short function syntax - f(x) = x - [currently has notice]
why: hacky implementation, duplicating functionaly
use --> to make curried functions

+++ concat op [currently has notice]
why: added ++ as concat op, which is shorter and better

where statement - relatively useless - just use local var assignment or a let statement  [currently has notice]

undefined alias for void - added for CoffeeScript compatibility, but with coffee2ls that is not an issue  [currently has notice]

!? inexistence op  [currently has notice]

discussion:

choose one of ** or ^ for power op?
remove import and importAll?
remove x is not y to mean x isnt y, have it mean x is !y instead
yes/no/on/off aliases - added for CoffeeScript compatibility, but now with coffee2ls, this is not an issue

More controversial:

remove standalone use of @
remove standalone or hanging use of ::

remove unjoined strings

I never use @ and if decorators ever become a thing in JS we have a clash.
I did not have the pleasure of coding LS in a team but in coffeescribble and I found not just one bug caused by heavy usage of ?. That disqualifies the whole thing as a safe-guard to me.
I generally prefer not using symbols if i don't have to... Not all symbols in LS have such quirky and placement specific behavior. I still prefer not to be clever just for saving a few characters.

I use @ a lot. You're right with the readability and decorators aspect (even if I don't think LS has to mirror every feature of JS).
But it's a very simple substitute and for me it feels fast to skim over code and see all the @attributes that are used even without special highlighting.

@igl There's no need for decorators in LiveScript outside of changing property descriptors. You can use plain functions for nearly every use case. (I've used this in my own pet projects before)
inc = (f) -> ->
  @index += 1
  f.apply @, &

class Foo
  -> @index = 2
  foo: inc -> console.log "#{@index}"

wrap = (f) -> -> new List f.apply @, &

class List
  (@value) ->
  map: wrap (f) -> [f i for i in @value]
  filter: wrap (f) -> [i for i in @value | f i]
  each: (f) -> [f i for i in @value]; @

And things that I wouldn't mind if they were removed:

case, when, then, else, and default in switch-case/match expressions

IMHO, this is where CoffeeScript starts looking not so pretty.

yes, no, on, and off CoffeeScript boolean synonyms.

I rarely see these outside of CoffeeScript and YAML.

x is not y -> change to be equivalent to (x) == (!y) (principle of least surprise)

Python's version is exclusively used for references, usually for objects or types.
type(foo) is not str
objA is not objB
x == y

CoffeeScript itself compiles x is not y to x === !y.

undefined

Exclusively use void.
Clearer that it's not just JavaScript's problematic (in sloppy mode) undefined.

One of ^ or **

. alias of the << composition operator (consistency)

* 'str', / 'str'

Use String::join, String::split, Prelude.ls's join function, or its split function.
Easier to know at a glance.

for ever alias of loop

Don't need both.
Most languages with this construct use loop.

great list ...
I've never tried is not and always used isnt however, now that I think about it, I could see why that would be logical. without thinking about it, I'd write if x is !y
I will admit I've used * 'str' a lot, so it'd be the only one I miss, but not that much.
so yeah, I'm totally +1 for all that.

@heavyk I've used that quite a bit, too, but it tends to throw me a little at first glance, which isn't nice when you're reading code. That's why I put it on there.

'str', / 'str'

Use String::join, String::split, Prelude.ls's join function, or its split function.
Easier to know at a glance.

Literal overloading in general. It'd make sense to have such feature with a type system (and overloadable operators...), but for us right now...

@vendethiel +1

@impinball yea I agree.  I look at that code now, it's like 'wat??'

I only disagree with

. alias of the << composition operator (consistency)

I never used that, what does it do?

Function composition from right to left.
ls> (+ 1) . (* 2) <| 1
3

oh, I didn't know you could do that!
I just looked at your profile, then at the ramda-cli you're working on, and it gave me a good idea. why do we pass options objects around at all? why not pass around option thunks?
every part of anything we write could be composed. I'll give an example...
resizeImage({
width: 1024,
height: 768,
rotate: 0, normalize: ... etc. // these are options
}
so I pass in my options object with values, but if I were to instead pass thunks, I could get two objects that can always change, but depend on each oher. one obj would have the thunks to call of the other object, and vice versa.. objects would turn out the properties of other objects. it looks in my head like water. I need a better way to express this. I will work on this more...
totally had no idea about those function compositions. whole new world just opened... omg

@homam To be fair, I have used it before. I have run into a gotcha with it, though: partially applying it. I have found a few times where I had to use (<<) because ( . ) always represents property access. You can still do (foo .) though.
@heavyk
Here's a use case for function composition: making a lazy chain:
a = -> [.. for &]
chain-sync = a >> reduce (>>)

read-rc = chain-sync do
  ('.'+)
  (fs.read-file-sync _, 'utf8')
  JSON.parse

I've also used a similar trick in a Gulpfile:
require! { /* ... */ }
a = -> [.. for &]
pipe = a >> reduce (a, b) -> a.pipe b

gulp.task \build ->
  pipe do
    * gulp.src 'src/**/*.ls'
    * sourcemaps.init!
    * livescript!
    * soucemaps.write!
    * gulp.dest 'dest'

Doing the same with promises is easy

@raine I use match quite a bit. I ended up making an equivalent targeting ES7 virtual methods (expect it to be slow), just to simplify my program significantly (mostly written in ES6/7):
export const method = f => function (...args) {
  return f(this, ...args);
};

const each = (xs, f) => {
  for (let i = 0; i < xs.length; i++) {
    f(xs[i], i);
  }
};

export const then = method((x, f) => f(x));

export const match = method((value, pairs) =>
        each(pairs, (p, i) => assertCallable(p[0], `test[${i}]`))::then(() => {
    let def = pairs.pop();
    if (Array.isArray(def)) {
        pairs.push(def);
        return undef;
    } else {
        assertCallable(def, 'def');
    }

    for (let [g, run] of pairs) {
        if (typeof g === 'function' ? g(value) : value === g) return run(value);
    }

    return def(value);
});

value::match([
  // I found the common case to be a function call with `value`, so I designed
  // it with that in mind
  [test, value => doSomething(value)],
  [otherTest, doSomethingElse],
  value => def(value), // optional
]);

The last part in LS would be this:
match value
  | test => doSomething value
  | otherTest => doSomethingElse value
  | otherwise => def value

I enjoy match

@impinball I enjoy matcha lot too (#584 is the only issue i have with it)
I am very curious about how these changes are going to land. Will there be a 1.5 with breakage?
Will features like es6 class and module support be pushed off further to LS2?
Can there be a LS2 pre-release with a lot of breakage so big changes can happen before locking the keywords? Is forking CoffeeScriptRedux still on the roadmap?

That LS2 branch/roadmap is years outdated. LiveScript uses its own lexer
and parser now.
As for an actual roadmap, I don't think there's much to add right now. But
FWIW I do feel that removing all these features should constitute a new
major version (I know this project doesn't follow Semver). Even gradually,
this would cause a lot of code breakage, including in the compiler itself.
On Tue, Jun 16, 2015, 06:45 Richard<EMAIL_ADDRESS>wrote:

@impinball https://github.com/impinball I enjoy matcha lot too (#584
https://github.com/gkz/LiveScript/issues/584 is the only issue i have
with it)
I am very curious about how these changes are going to land. Will there be
a 1.5 with breakage?
Will features like es6 class and module support be pushed off further to
LS2?
Can there be a LS2 pre-release with a lot of breakage so big changes can
happen before locking the keywords? Is forking CoffeeScriptRedux still on
the roadmap?
—
Reply to this email directly or view it on GitHub
https://github.com/gkz/LiveScript/issues/219#issuecomment-112383210.

Match is a must have feature

+1 on all except stand alone @ (mostly because I have a lot of old code using it).

@ozra I agree WRT the original list (except I also want to keep C:: == C.prototype).
@focused I agree, and I wish match was documented. It does IMHO have odd behavior with certain cases (it's rather ad-hoc in how it matches things), and could stand to be fixed, but it should still stay around.

I'm disappointed the single-item array not evaluating to an array "feature" wasn't removed in 1.5 after all. 😕  It's something that actively causes pain through unexpected behavior, rather than just duplicating behavior.


Webpack does'n lift common code up to ansector's level

Bug report

What is the current behavior?
After compiling the project many bundles have common code
If the current behavior is a bug, please provide the steps to reproduce.
here is my config:
    mode: 'production',
    target: 'web',
    cache: true,
    entry: {
        client: './src/client/index.js',
    },
    profile: true,
    output: {
        path: path.resolve('./dist'),
        filename: '[name].[hash].js',
        chunkFilename: '[name].[chunkhash].chunk.js',
        publicPath: '/',
    },
    optimization: {
        splitChunks: {
            cacheGroups: {
                default: false,
                vendor: {
                    test: /[\\/]node_modules[\\/]/, // you may add "vendor.js" here if you want to
                    name: 'vendor',
                    chunks: 'all',
                    enforce: true,
                },
            },
        },
        runtimeChunk: {
            name: 'runtime',
        },
        minimizer: [
            new MinifyPlugin(),
            new OptimizeJsPlugin({ sourceMap: false }),
        ],
        occurrenceOrder: true,
    },

What is the expected behavior?
in case of switchin new behavior in wp4 off - webpack should lift all common code on to one level upper in whole bundles hierarchy:
for an example:
(all pages have their own bundles)
We have start page Page1 and 3 pages PageA, PageB & PageC to go from the Page1. If we have some common code in those pages (PageA, PageB & PageC) and default new behavior is switched off - we shode move common code into the Page1.

Other relevant information:
webpack version:  4.8.1
Node.js version: 10.0.0
Operating System: Windows Server 2008R2
Additional tools:

remove optimization.splitChunks.cacheGroups.default: false. This disables the deduplication of common code. Moving common code to the parent doesn't make sense, because defeats the propose of Code Splitting.

Why it doesn't make sense??
PageA, PageB & PageC have some shared code and if it's lifted up to Page1 - it's the same as standalone async chunk but without additional request to the server.

I would actually second this request—having a vendor file extracted from your code, for example, is nice, but if it's fetched dynamically via webpack, you have to wait for your javascript to download and execute before the vendor file request is made. On the other hand, if you extracted it into a top-level standalone file, you can add it as a <script> tag in your html file and benefit from lookahead parsing so that the request is made before the initial html file is done even being parsed. That's a big difference!
Of course, I imagine you can take your extracted vendor file and place it into an html file (including the chunk hash) with ExtractTextWebpackPlugin, but in my personal case, we don't use webpack for anything more than javascript bundling, so it'd be nice if there was an option for this for people who don't use webpack for everything.
This could also be solved for me if we could pass a function to the output.chunkFilename option so that I could add a hash to all files except the vendor top-level file (i use a different tool in my workflow to hash my top-level files and add them to the html file).

producing a lot of async common chunks may be usefull for novices, but we dont use webpack in a wild

we need full control over our bundles to dynamically include them into HTML on server side
also we need to minimize all amount of connections on mobiles.
and the last thing - we use PWA so we dont need to use the default webpack's behaviour for novices - we need to have full control over producing bundles and have minimal count of bundles - one per route

producing a lot of async common chunks may be usefull for novices, but we dont use webpack in a wild

we need full control over our bundles to dynamically include them into HTML on server side
also we need to minimize all amount of connections on mobiles.
and the last thing - we use PWA so we dont need to use the default webpack's behaviour for novices - we need to have full control over producing bundles and have minimal count of bundles - one per route

by the way, the Parsel by default lift up common dependence.

produsing a lot of bundles make harder work for adding scripts to a page on server side (discovering on relation to the page)
I agree with your strategy - will struggle with bundles in server side :)

Lifting code to the parent will always cause unnecessary code to be loaded.

@sokra I don't think this is a necessarily-true statement. If you have a dynamic import, that means that it's called from your application javascript code; but in order for that to happen, your application javascript code must have been downloaded and executed. This code is, for single-page apps, often blocking, because without it your page won't work at all. If you have several required such top-level scripts, then by making them blocking you can at least guarantee their order of execution.
Additionally, by making them top-level, you benefit from the browser's look-ahead parser and get a head start on the request. if you have, say, a vendor file that is common across all of your bundles (let's say it's React and lodash), your load times will benefit from keeping that script as a top-level, blocking <script> tag as opposed to a dynamic import fetched in parallel with a chunk—since, of course, a chunk can be much smaller than a vendor file, causing the vendor file to be the limiting request to render.
Anyways, it'd still be desirable for me to be have an option to pull out an app-wide vendor file as top-level, and I imagine it'd be beneficial for other SPA developers for the same reasons. like I mentioned above, though, I could also solve it by having a function for options.chunkFilename.

@sokra can we reopen this issue? I really think this is something that should be addressed. Thank you!

ping @sokra. Should I just create a new issue?


Add ComputationalGridGenerator module

Use ComputationalGridGenerator instead of TetrahedralMeshGenerator

Fixed by #46 but we should probably keep using TetrahedralMeshGenerator or something similar that is more modular than ComputationalGridGenerator


Add a license

Please add a license and a CONTRIBUTING.md file to this repo. Adding a license will help regulate how people use your code and also a CONTRIBUTING.md file will help others know how to contribute to this project

LICENSE part has been done. I did not add any license since everything else, not just MY PART of the code, has to comply with the license. For instance, I think if something is licensed under GNU GPL v3, any modifications of that must also be licensed as the same GNU GPL v3. For now, without considering much, I have added The Unlicense license. If you find any compliance issues, feel free to point out.


⚠ ClamAV has degraded performance

In 30efa9a, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 142 ms

Resolved: ClamAV performance has improved in a585a54.


HasPropertyWithValue

I have looked and not found it in the API. I could be overlooking it, but it would be great to be able to do the following:
public class Foo {
	int amount;
	String name;
	List<String> items;

	public int getAmount() {...}

	public String getName() {...}

	public List<String> getItems() {...}
}

Foo foo = new Foo();
assertThat(foo).hasPropertyWithValue("amount", 5).hasPropertyWithValue("name", "Someone");

I guess this can be closed, as https://github.com/joel-costigliola/assertj-core/commit/77ab46110a5a9d579cc428d7977d49ce1e40bc82 added #hasFieldOrPropertyWithValue

Indeed !


What hardware is needed?

I have
rasberry pi 4 2gb or more ram
64 gig memory card
Unsure if i need
LoRa concentrator from rakk?
packet forwarder (LoRa esp development board?) or will the rasberry pi be efficient at this
lorawan gateway?
Any input on this would be great, thanks!

Hey, i'm not part of the Nebra team, but hardware wise the Nebra devices appear to use a custom mainboard and a raspberry pi compute board.
If your goal is to earn HNT crypto then you're out of luck with a DIY solution as you'll need a security chip. You could however build a packet forwarder based on the guide here

yep you can run this on a pi3 / pi4 probably with some minor modifications. but you won't be able to mine HNT without an onboarded secure element chip


Remove unwrap & Add clippy lint option to check the use of unwrap

Background

The development rules for our product say that we should use expect instead of unwrap in situations where we are confident that panic will not necessarily occur.
We should also make sure that the code we write in the future follows the same rules.
Therefore, we should proceed with the modification as shown below

Task

Remove unwrap(), which is used against the rules
Add a lint option to the Clippy part of ci.yml: -W clippy::unwrap_used

Resolved in f4c4dfa0e6c8f107a9afd4859a4ed3a96b338a77.


'NSInternalInconsistencyException', reason: 'Could not load NIB in bundle:

New issue checklist

[x] I have read all of the README, documentation, and FAQ.
[x] I have reviewed the contributing guidelines. Confirmation: ____
[x] I have searched existing issues and this is not a duplicate.

General information

Library version(s): 7.3.4
iOS version(s): 10.0
Devices/Simulators affected: iPhone SE
Reproducible in the demo project? (Yes/No):
Related issues:

What happened?
So I'm using objc combined with swift.
I'm calling a segue from objc:
-(void) tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
    index = indexPath.row;
    [tableView deselectRowAtIndexPath:indexPath animated:YES];
    [self performSegueWithIdentifier:@"ChatToDetail" sender:NULL];
}

- (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender {
    ChatViewController *c = segue.destinationViewController;
    c.senderIDswift = currentPhone;
    c.chatIDswift = _chatIDarray[index];
    NSLog(@"%@", c.senderIDswift);
}

and this call the swift with jsqmessagesviewcontroller.
and then when i click a list from the table i get this error:
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Could not load NIB in bundle: 'NSBundle </var/containers/Bundle/Application/C192F665-E5F4-4215-B858-115D64BFD8FC/FriendlyChatObjC.app> (loaded)' with name 'JSQMessagesViewController''
*** First throw call stack:
(0x18f0681c0 0x18daa055c 0x18f068108 0x1953b283c 0x10034eb34 0x100075670 0x100075bf8 0x194eb13dc 0x194ec8f70 0x1950514bc 0x194f69b84 0x194f697ec 0x194f69750 0x194eae54c 0x19237640c 0x19236b0e8 0x19236afa8 0x1922e7c64 0x19230f0d0 0x194ea3c1c 0x18f0157dc 0x18f01340c 0x18f01389c 0x18ef42048 0x1909c5198 0x194f1c628 0x194f17360 0x100073b20 0x18df245b8)
libc++abi.dylib: terminating with uncaught exception of type NSException

I tried to follow any instruction from anywhere about this error and nothing fixed this.
Is there anything i miss?
Anyway I'm using the tutorial from raywenderlich for the swift part.

Hey, @ianstephens. Not really sure where the problem is based on the information you provided. I am just guessing around here. Perhaps ChatViewController is not inherited from JSQMessagesViewController? Or perhaps there is a mismatch with the segue setup? You can take a look at the sample we provide. It should lead you to a right direction.

Checkout the swift example from the development branch it will be your most update resource.

Did you figure out what caused this? I'm having this problem after updating to cocoapods 0.39

I'm facing same issue. Any solution?

Hello everyone!
I'm sorry to inform the community that I'm officially deprecating this project. 😢 Please read my blog post for details:
http://www.jessesquires.com/blog/officially-deprecating-jsqmessagesviewcontroller/
Thus, I'm closing all issues and pull requests and making the necessary updates to formally deprecate the library. I'm sorry if this is unexpected or disappointing. Please know that this was an extremely difficult decision to make. I'd like to thank everyone here for contributing and making this project so great. It was a fun 4 years. 😊
Thanks for understanding,
— jsq


feat: 🎸 allow for skiping affirm for manual execution

Description
instruction executeManually method now accepts optional skipAffirmationCheck param. Useful when processing the affirmation earlier in the batch transaction.
Breaking Changes
None
JIRA Link
DA-756
Checklist

[ ] Updated the Readme.md (if required) ?

I made this a breaking change after trying out adding a new endpoint.
I am thinking an integrator using executeManual probably wants control, so shouldn't be too inconvenienced at inspecting the call site and deciding on the correct behavior.
By principle I dislike having boolean params that toggle internal logic, but I think this case is worth while making an exception for. instruction.executeManualButSkipAffirmationCheck doesn't look good as a name. Having to specify details when opting for manual execution seems reasonable and should be easy to update.
We have a breaking change here, so I am hoping these can go out together since they are both relatively minor: https://github.com/PolymeshAssociation/polymesh-sdk/pull/996

:tada: This PR is included in version 21.0.0-alpha.4 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 21.0.0-beta.1 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Guru meditation on nvs_close, nvs_erase and nvs_deinit (IDFGH-8887)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.
v5.0
Operating System used.
Windows
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
CMD
Development Kit.
ESP32-C3-DevKitM-1
Power Supply used.
USB
What is the expected behavior?
Invoking nvs_close, nvs_flash_deinit and nvs_flash_erase should perform the required operation without crashing the system.
What is the actual behavior?
Sometimes I get a Guru meditation when invoking nvs_close, nvs_flash_deinit and nvs_flash_erase (I call them to clear configuration on my device).
The issue does not happen 100% of the times but for sure it happens only when I made some changes to the data (using nvs_set_blob or nvs_set_str followed by nvs_commit)
The error message is the following:
Guru Meditation Error: Core 0 panic'ed (Store access fault). Exception was unhandled.
Stack dump detected
Core 0 register dump:
MEPC : 0x42035a72 RA : 0x42035a4e SP : 0x3fc9ea50 GP : 0x3fc96a00
0x42035a72: intrusive_list::erase(intrusive_list::iterator) at C:/Users/valter.minute/esp/esp-idf/components/nvs_flash/src/intrusive_list.h:195
(inlined by) nvs_close at C:/Users/valter.minute/esp/esp-idf/components/nvs_flash/src/nvs_api.cpp:308
0x42035a4e: nvs_close at C:/Users/valter.minute/esp/esp-idf/components/nvs_flash/src/nvs_api.cpp:302
TP : 0x3fc77e38 T0 : 0x4200ed76 T1 : 0x10000000 T2 : 0x00000000
nvs_api address may change, but all the errors reference intrusive_list::erase(intrusive_list::iterator).
Steps to reproduce.
I tried with a plain reproducer, performing all the operations in sequence, but I didn't manage to get a crash.
Debug Logs.
Guru Meditation Error: Core 0 panic'ed (Store access fault). Exception was unhandled.

Stack dump detected
Core 0 register dump:
MEPC : 0x42035a72 RA : 0x42035a4e SP : 0x3fc9ea50 GP : 0x3fc96a00
0x42035a72: intrusive_list::erase(intrusive_list::iterator) at C:/Users/valter.minute/esp/esp-idf/components/nvs_flash/src/intrusive_list.h:195
(inlined by) nvs_close at C:/Users/valter.minute/esp/esp-idf/components/nvs_flash/src/nvs_api.cpp:308

0x42035a4e: nvs_close at C:/Users/valter.minute/esp/esp-idf/components/nvs_flash/src/nvs_api.cpp:302

TP : 0x3fc77e38 T0 : 0x4200ed76 T1 : 0x10000000 T2 : 0x00000000

More Information.
Currently, my application is calling nvs_flash_init at startup, it uses wifi (doing scans only) and BT.
Sometimes it writes data to NVS (configuration parameters written using nvs_set_blog/nvs_set_string and nvs_commit).
I have a command to clean configuration that invokes nvs_close, nvs_flash_deinit, and nvs_flash_erase to remove all NVS content and this is where I get the error.
nvs_flash_init and nvs_open on different namespaces (2) are invoked at startup.
Flash write is called from different tasks, but there are no concurrent calls.
When a reset to factory command is received via BT the application closes the namespaces, de-initializes flash (nvs_flash_deinit), and erases it (nvs_flash_erase), forcing a reboot afterward.
I tried also to invoke nvs_flash_erase without first closing/deinitializing, but the result didn't change, unfortunately.

I forgot to attach registers values to the dump:
S0/FP   : 0x3fcc80b4  S1      : 0x3fc9eaa0  A0      : 0x00000001  A1      : 0xffffffff
A2      : 0x00000000  A3      : 0x00000001  A4      : 0x00000007  A5      : 0x3fcc80e4
A6      : 0x60023000  A7      : 0x0000000a  S2      : 0x3fc9fb38  S3      : 0x3fc9ea98
S4      : 0x00000000  S5      : 0x00000000  S6      : 0x00000000  S7      : 0x00000000
S8      : 0x00000000  S9      : 0x00000000  S10     : 0x00000000  S11     : 0x00000000
T3      : 0x00000000  T4      : 0x00000000  T5      : 0x00000000  T6      : 0x00000000
MSTATUS : 0x00001881  MTVEC   : 0x40380001  MCAUSE  : 0x00000007  MTVAL   : 0x0000000b

@ValterMinute Could you please attach the complete stack trace you get after the register dump? (You can get it if you run the program using idf.py monitor or the equivalent option in an IDE.)
In the absence your .elf file, the register values do not provide a lot of useful information, unfortunately.

I tried with a plain reproducer, performing all the operations in sequence, but I didn't manage to get a crash.

Could you try to describe what is different between your application and a "plain reproducer", to try to narrow down the possible cause of the issue? For example, are you using NVS APIs from multiple application tasks? Is the amount of heap memory always sufficient? Have you tried enabling heap poisoning to check if this could be caused by heap corruption? This or any other information might help us make this issue more actionable.

I am investigating heap corruption, trying to narrow this down in my code base.
Thanks a lot for the hint.
I think that the crash is a symptom, not the real issue.


GMZ option + Clarify Support of GML

Hello, Animelici!
It would be nice if a .gmz/.yyz file would be provided in a future release, as importing the project would be extremely simple with a single file. As far as I know, importing .gmz/.yyz files is available within GameMaker.
Speaking of GameMaker, what version does this project support? There is GameMaker: Studio 2, GameMaker: Studio, and GameMaker 8, and I'm a little confused on whether it will even work on the version in my computer...
Edit: I forgot that GMS2 export files were actually .yyz files. My apologies for the misunderstanding.
I have now inserted the term ".yyz" throughout my comment to compensate.

GMZ/GMX support will come later on, after its initial release (when everything is done basically). The project is supported on the beta version of Game Maker Studio 2.3.0, so therefore I don't know if it's supported on your Game Maker version. But don't worry, like I said, GMS 1.4 support will come when everything is done.

Wow, thanks for your time!
I just saw the changes you've made in your README file, and I believe that will be enough to ease my concerns. Hoping to get GM:S 1.4 support not too long in the future.
By the way, I think resolving an issue might just be the motivation you need, after all : )
Anyway, closing this issue now.

You're welcome.


CV loss oscillates near 140 from start

I ran custom dataset with librispeech/s0/run.sh and conf/train_conformer.yaml and CV loss oscillates near 140 from start without improvement.
What could be the reason for this?
Thanks in advance.

check your data prepare
try to use smaller learning_rate

I've tried lr 0.003, 0.001 and 0.0005, but without success.

How about u2++_conformer?

I meet the same problem, too. In my 36k hours Chinese + English + Mandarin-English codeswitch data, I use u2++conformer, with config of
output_size: 256    # dimension of attention
attention_heads: 4
linear_units: 2048  # the number of units of position-wise feed forward

and
    lr: 0.001
I Found the cv_loss is abnormal, then in third Epoch I decrease the lr to its half(0.0005).
the cv_loss is 98 after total 5 epochs!
Here is the log:
2023-01-30 18:47:07,107 DEBUG TRAIN Batch 4/203700 loss 12.646465 loss_att 10.921429 loss_ctc 16.671551 lr 0.00032621 rank 0
2023-01-30 18:47:16,614 DEBUG TRAIN Batch 4/203700 loss 16.885244 loss_att 13.554604 loss_ctc 24.656742 lr 0.00032621 rank 1
2023-01-30 18:47:22,712 DEBUG TRAIN Batch 4/203700 loss 19.729301 loss_att 16.203592 loss_ctc 27.955961 lr 0.00032621 rank 2
2023-01-30 18:49:20,301 DEBUG TRAIN Batch 4/203800 loss 23.600426 loss_att 18.615641 loss_ctc 35.231586 lr 0.00032619 rank 2
2023-01-30 18:49:20,315 DEBUG TRAIN Batch 4/203800 loss 18.340179 loss_att 15.005867 loss_ctc 26.120243 lr 0.00032619 rank 1
2023-01-30 18:49:20,438 DEBUG TRAIN Batch 4/203800 loss 25.618004 loss_att 20.509174 loss_ctc 37.538609 lr 0.00032619 rank 0
2023-01-30 18:49:55,773 DEBUG CV Batch 4/0 loss 28.517015 loss_att 24.142754 loss_ctc 38.723625 history loss 27.957858 rank 2
2023-01-30 18:49:56,046 DEBUG CV Batch 4/0 loss 28.402842 loss_att 24.164579 loss_ctc 38.292122 history loss 27.845923 rank 0
2023-01-30 18:49:56,076 DEBUG CV Batch 4/0 loss 28.509480 loss_att 24.174435 loss_ctc 38.624588 history loss 27.950470 rank 3
2023-01-30 18:49:56,101 DEBUG CV Batch 4/0 loss 28.402861 loss_att 24.164606 loss_ctc 38.292122 history loss 27.845942 rank 1
2023-01-30 18:50:31,741 DEBUG CV Batch 4/100 loss 30.877792 loss_att 24.287479 loss_ctc 46.255188 history loss 80.243644 rank 3
2023-01-30 18:50:31,741 DEBUG CV Batch 4/100 loss 31.406693 loss_att 24.250772 loss_ctc 48.103836 history loss 79.827912 rank 0
2023-01-30 18:50:31,970 DEBUG CV Batch 4/100 loss 30.851536 loss_att 24.290764 loss_ctc 46.160007 history loss 79.778125 rank 2
2023-01-30 18:50:32,342 DEBUG CV Batch 4/100 loss 31.406673 loss_att 24.250732 loss_ctc 48.103867 history loss 79.008956 rank 1
2023-01-30 18:51:05,132 DEBUG CV Batch 4/200 loss 46.388836 loss_att 37.140503 loss_ctc 67.968277 history loss 89.078245 rank 3
2023-01-30 18:51:05,888 DEBUG CV Batch 4/200 loss 46.388817 loss_att 37.140484 loss_ctc 67.968262 history loss 88.649869 rank 0
2023-01-30 18:51:06,272 DEBUG CV Batch 4/200 loss 46.388779 loss_att 37.140423 loss_ctc 67.968269 history loss 88.688824 rank 2
2023-01-30 18:51:07,147 DEBUG CV Batch 4/200 loss 46.388771 loss_att 37.140415 loss_ctc 67.968262 history loss 88.296744 rank 1
2023-01-30 18:51:30,497 DEBUG CV Batch 4/300 loss 42.442574 loss_att 33.455048 loss_ctc 63.413464 history loss 83.552503 rank 3
2023-01-30 18:51:32,700 DEBUG CV Batch 4/300 loss 42.442581 loss_att 33.455055 loss_ctc 63.413464 history loss 83.255786 rank 0
2023-01-30 18:51:32,858 DEBUG CV Batch 4/300 loss 42.442566 loss_att 33.455044 loss_ctc 63.413460 history loss 83.288357 rank 2
2023-01-30 18:51:33,321 DEBUG CV Batch 4/300 loss 42.116375 loss_att 33.400871 loss_ctc 62.452549 history loss 83.019157 rank 1
2023-01-30 18:51:58,000 DEBUG CV Batch 4/400 loss 47.048725 loss_att 37.091206 loss_ctc 70.282936 history loss 81.040529 rank 3
2023-01-30 18:51:58,237 DEBUG CV Batch 4/400 loss 47.314903 loss_att 37.104877 loss_ctc 71.138306 history loss 80.788295 rank 2
2023-01-30 18:51:58,431 DEBUG CV Batch 4/400 loss 47.050179 loss_att 37.100052 loss_ctc 70.267143 history loss 80.756375 rank 0
2023-01-30 18:52:01,045 DEBUG CV Batch 4/400 loss 47.088219 loss_att 37.086498 loss_ctc 70.425568 history loss 80.567495 rank 1
2023-01-30 18:52:32,657 DEBUG CV Batch 4/500 loss 38.062759 loss_att 30.567739 loss_ctc 55.551136 history loss 83.286071 rank 3
2023-01-30 18:52:32,728 DEBUG CV Batch 4/500 loss 37.896431 loss_att 30.466656 loss_ctc 55.232578 history loss 83.022444 rank 0
2023-01-30 18:52:33,422 DEBUG CV Batch 4/500 loss 37.911812 loss_att 30.471275 loss_ctc 55.273056 history loss 83.058120 rank 2
2023-01-30 18:52:34,479 DEBUG CV Batch 4/500 loss 38.062759 loss_att 30.567730 loss_ctc 55.551151 history loss 82.813904 rank 1
2023-01-30 18:53:14,712 DEBUG CV Batch 4/600 loss 47.122044 loss_att 38.425232 loss_ctc 67.414604 history loss 88.885744 rank 3
2023-01-30 18:53:14,742 DEBUG CV Batch 4/600 loss 46.342560 loss_att 38.402050 loss_ctc 64.870415 history loss 88.531659 rank 2
2023-01-30 18:53:14,749 DEBUG CV Batch 4/600 loss 47.122055 loss_att 38.425243 loss_ctc 67.414604 history loss 88.823756 rank 0
2023-01-30 18:53:14,764 DEBUG CV Batch 4/600 loss 46.351166 loss_att 38.398983 loss_ctc 64.906250 history loss 88.422146 rank 1
2023-01-30 18:53:54,965 DEBUG CV Batch 4/700 loss 44.441872 loss_att 36.677708 loss_ctc 62.558262 history loss 92.181358 rank 3
2023-01-30 18:53:55,065 DEBUG CV Batch 4/700 loss 44.877800 loss_att 36.743958 loss_ctc 63.856770 history loss 92.239779 rank 0
2023-01-30 18:53:55,341 DEBUG CV Batch 4/700 loss 44.877766 loss_att 36.743904 loss_ctc 63.856777 history loss 92.046780 rank 1
2023-01-30 18:53:55,344 DEBUG CV Batch 4/700 loss 44.877800 loss_att 36.743954 loss_ctc 63.856770 history loss 92.113521 rank 2
2023-01-30 18:54:33,266 DEBUG CV Batch 4/800 loss 30.649742 loss_att 23.923923 loss_ctc 46.343323 history loss 92.472580 rank 0
2023-01-30 18:54:33,383 DEBUG CV Batch 4/800 loss 30.626713 loss_att 23.903809 loss_ctc 46.313492 history loss 92.436917 rank 3
2023-01-30 18:54:34,417 DEBUG CV Batch 4/800 loss 31.421110 loss_att 23.947063 loss_ctc 48.860554 history loss 92.407726 rank 2
2023-01-30 18:54:34,842 DEBUG CV Batch 4/800 loss 30.599287 loss_att 23.910414 loss_ctc 46.206657 history loss 92.288636 rank 1
2023-01-30 18:55:21,506 DEBUG CV Batch 4/900 loss 33.508255 loss_att 27.452938 loss_ctc 47.637329 history loss 98.493538 rank 3
2023-01-30 18:55:21,754 DEBUG CV Batch 4/900 loss 33.477356 loss_att 27.457464 loss_ctc 47.523773 history loss 98.568809 rank 0
2023-01-30 18:55:22,038 DEBUG CV Batch 4/900 loss 33.460239 loss_att 27.503674 loss_ctc 47.358894 history loss 98.430041 rank 1
2023-01-30 18:55:23,380 DEBUG CV Batch 4/900 loss 33.436291 loss_att 27.461983 loss_ctc 47.376347 history loss 98.415872 rank 2
2023-01-30 18:55:39,040 INFO Epoch 4 CV info cv_loss 98.36615292046831
2023-01-30 18:55:39,041 INFO Epoch 4 TRAIN info final lr 0.0003261806929873899
2023-01-30 18:55:39,041 INFO Checkpoint: save to checkpoint exp/conformer_wavaug1/4.pt
2023-01-30 18:55:39,092 INFO Epoch 4 CV info cv_loss 98.3194536657683
2023-01-30 18:55:39,093 INFO Epoch 4 TRAIN info final lr 0.0003262001287504334
2023-01-30 18:55:39,093 INFO Epoch 5 TRAIN info init lr 0.0003262001287504334
2023-01-30 18:55:39,097 INFO using accumulate grad, new batch size is 16 times larger than before
2023-01-30 18:55:39,544 INFO Epoch 4 CV info cv_loss 98.33389081785192
2023-01-30 18:55:39,545 INFO Epoch 4 TRAIN info final lr 0.0003261862457080438
2023-01-30 18:55:39,545 INFO Epoch 5 TRAIN info init lr 0.0003261862457080438
2023-01-30 18:55:39,549 INFO using accumulate grad, new batch size is 16 times larger than before
2023-01-30 18:55:39,867 INFO Epoch 4 CV info cv_loss 98.20686797192958
2023-01-30 18:55:39,867 INFO Epoch 4 TRAIN info final lr 0.0003261917987122867
2023-01-30 18:55:39,867 INFO Epoch 5 TRAIN info init lr 0.0003261917987122867
2023-01-30 18:55:39,869 INFO using accumulate grad, new batch size is 16 times larger than before
2023-01-30 18:55:41,034 INFO Epoch 5 TRAIN info init lr 0.0003261806929873899
2023-01-30 18:55:41,038 INFO using accumulate grad, new batch size is 16 times larger than before
2023-01-30 18:56:46,874 DEBUG TRAIN Batch 5/0 loss 17.460732 loss_att 14.531824 loss_ctc 24.294846 lr 0.00032619 rank 2
2023-01-30 18:56:46,879 DEBUG TRAIN Batch 5/0 loss 14.466322 loss_att 11.996610 loss_ctc 20.228985 lr 0.00032620 rank 3
2023-01-30 18:56:46,882 DEBUG TRAIN Batch 5/0 loss 18.419432 loss_att 15.551132 loss_ctc 25.112129 lr 0.00032618 rank 1
2023-01-30 18:56:46,882 DEBUG TRAIN Batch 5/0 loss 38.082077 loss_att 26.783554 loss_ctc 64.445297 lr 0.00032618 rank 0

Then I change the model config, with:
    output_size: 512    # dimension of attention
    attention_heads: 8
    linear_units: 2048  # the number of units of position-wise feed forward

and
    lr: 0.001
Then the model can be trained successfully.
I've tried to debug, but i still can't find the reason.

I meet the same problem, too. In my 36k hours Chinese + English + Mandarin-English codeswitch data, I use u2++conformer, with config of
output_size: 256    # dimension of attention
attention_heads: 4
linear_units: 2048  # the number of units of position-wise feed forward

and  lr: 0.001
I Found the cv_loss is abnormal, then in third Epoch I decrease the lr to its half(0.0005). the cv_loss is 98 after total 5 epochs! Here is the log:
2023-01-30 18:47:07,107 DEBUG TRAIN Batch 4/203700 loss 12.646465 loss_att 10.921429 loss_ctc 16.671551 lr 0.00032621 rank 0
2023-01-30 18:47:16,614 DEBUG TRAIN Batch 4/203700 loss 16.885244 loss_att 13.554604 loss_ctc 24.656742 lr 0.00032621 rank 1
2023-01-30 18:47:22,712 DEBUG TRAIN Batch 4/203700 loss 19.729301 loss_att 16.203592 loss_ctc 27.955961 lr 0.00032621 rank 2
2023-01-30 18:49:20,301 DEBUG TRAIN Batch 4/203800 loss 23.600426 loss_att 18.615641 loss_ctc 35.231586 lr 0.00032619 rank 2
2023-01-30 18:49:20,315 DEBUG TRAIN Batch 4/203800 loss 18.340179 loss_att 15.005867 loss_ctc 26.120243 lr 0.00032619 rank 1
2023-01-30 18:49:20,438 DEBUG TRAIN Batch 4/203800 loss 25.618004 loss_att 20.509174 loss_ctc 37.538609 lr 0.00032619 rank 0
2023-01-30 18:49:55,773 DEBUG CV Batch 4/0 loss 28.517015 loss_att 24.142754 loss_ctc 38.723625 history loss 27.957858 rank 2
2023-01-30 18:49:56,046 DEBUG CV Batch 4/0 loss 28.402842 loss_att 24.164579 loss_ctc 38.292122 history loss 27.845923 rank 0
2023-01-30 18:49:56,076 DEBUG CV Batch 4/0 loss 28.509480 loss_att 24.174435 loss_ctc 38.624588 history loss 27.950470 rank 3
2023-01-30 18:49:56,101 DEBUG CV Batch 4/0 loss 28.402861 loss_att 24.164606 loss_ctc 38.292122 history loss 27.845942 rank 1
2023-01-30 18:50:31,741 DEBUG CV Batch 4/100 loss 30.877792 loss_att 24.287479 loss_ctc 46.255188 history loss 80.243644 rank 3
2023-01-30 18:50:31,741 DEBUG CV Batch 4/100 loss 31.406693 loss_att 24.250772 loss_ctc 48.103836 history loss 79.827912 rank 0
2023-01-30 18:50:31,970 DEBUG CV Batch 4/100 loss 30.851536 loss_att 24.290764 loss_ctc 46.160007 history loss 79.778125 rank 2
2023-01-30 18:50:32,342 DEBUG CV Batch 4/100 loss 31.406673 loss_att 24.250732 loss_ctc 48.103867 history loss 79.008956 rank 1
2023-01-30 18:51:05,132 DEBUG CV Batch 4/200 loss 46.388836 loss_att 37.140503 loss_ctc 67.968277 history loss 89.078245 rank 3
2023-01-30 18:51:05,888 DEBUG CV Batch 4/200 loss 46.388817 loss_att 37.140484 loss_ctc 67.968262 history loss 88.649869 rank 0
2023-01-30 18:51:06,272 DEBUG CV Batch 4/200 loss 46.388779 loss_att 37.140423 loss_ctc 67.968269 history loss 88.688824 rank 2
2023-01-30 18:51:07,147 DEBUG CV Batch 4/200 loss 46.388771 loss_att 37.140415 loss_ctc 67.968262 history loss 88.296744 rank 1
2023-01-30 18:51:30,497 DEBUG CV Batch 4/300 loss 42.442574 loss_att 33.455048 loss_ctc 63.413464 history loss 83.552503 rank 3
2023-01-30 18:51:32,700 DEBUG CV Batch 4/300 loss 42.442581 loss_att 33.455055 loss_ctc 63.413464 history loss 83.255786 rank 0
2023-01-30 18:51:32,858 DEBUG CV Batch 4/300 loss 42.442566 loss_att 33.455044 loss_ctc 63.413460 history loss 83.288357 rank 2
2023-01-30 18:51:33,321 DEBUG CV Batch 4/300 loss 42.116375 loss_att 33.400871 loss_ctc 62.452549 history loss 83.019157 rank 1
2023-01-30 18:51:58,000 DEBUG CV Batch 4/400 loss 47.048725 loss_att 37.091206 loss_ctc 70.282936 history loss 81.040529 rank 3
2023-01-30 18:51:58,237 DEBUG CV Batch 4/400 loss 47.314903 loss_att 37.104877 loss_ctc 71.138306 history loss 80.788295 rank 2
2023-01-30 18:51:58,431 DEBUG CV Batch 4/400 loss 47.050179 loss_att 37.100052 loss_ctc 70.267143 history loss 80.756375 rank 0
2023-01-30 18:52:01,045 DEBUG CV Batch 4/400 loss 47.088219 loss_att 37.086498 loss_ctc 70.425568 history loss 80.567495 rank 1
2023-01-30 18:52:32,657 DEBUG CV Batch 4/500 loss 38.062759 loss_att 30.567739 loss_ctc 55.551136 history loss 83.286071 rank 3
2023-01-30 18:52:32,728 DEBUG CV Batch 4/500 loss 37.896431 loss_att 30.466656 loss_ctc 55.232578 history loss 83.022444 rank 0
2023-01-30 18:52:33,422 DEBUG CV Batch 4/500 loss 37.911812 loss_att 30.471275 loss_ctc 55.273056 history loss 83.058120 rank 2
2023-01-30 18:52:34,479 DEBUG CV Batch 4/500 loss 38.062759 loss_att 30.567730 loss_ctc 55.551151 history loss 82.813904 rank 1
2023-01-30 18:53:14,712 DEBUG CV Batch 4/600 loss 47.122044 loss_att 38.425232 loss_ctc 67.414604 history loss 88.885744 rank 3
2023-01-30 18:53:14,742 DEBUG CV Batch 4/600 loss 46.342560 loss_att 38.402050 loss_ctc 64.870415 history loss 88.531659 rank 2
2023-01-30 18:53:14,749 DEBUG CV Batch 4/600 loss 47.122055 loss_att 38.425243 loss_ctc 67.414604 history loss 88.823756 rank 0
2023-01-30 18:53:14,764 DEBUG CV Batch 4/600 loss 46.351166 loss_att 38.398983 loss_ctc 64.906250 history loss 88.422146 rank 1
2023-01-30 18:53:54,965 DEBUG CV Batch 4/700 loss 44.441872 loss_att 36.677708 loss_ctc 62.558262 history loss 92.181358 rank 3
2023-01-30 18:53:55,065 DEBUG CV Batch 4/700 loss 44.877800 loss_att 36.743958 loss_ctc 63.856770 history loss 92.239779 rank 0
2023-01-30 18:53:55,341 DEBUG CV Batch 4/700 loss 44.877766 loss_att 36.743904 loss_ctc 63.856777 history loss 92.046780 rank 1
2023-01-30 18:53:55,344 DEBUG CV Batch 4/700 loss 44.877800 loss_att 36.743954 loss_ctc 63.856770 history loss 92.113521 rank 2
2023-01-30 18:54:33,266 DEBUG CV Batch 4/800 loss 30.649742 loss_att 23.923923 loss_ctc 46.343323 history loss 92.472580 rank 0
2023-01-30 18:54:33,383 DEBUG CV Batch 4/800 loss 30.626713 loss_att 23.903809 loss_ctc 46.313492 history loss 92.436917 rank 3
2023-01-30 18:54:34,417 DEBUG CV Batch 4/800 loss 31.421110 loss_att 23.947063 loss_ctc 48.860554 history loss 92.407726 rank 2
2023-01-30 18:54:34,842 DEBUG CV Batch 4/800 loss 30.599287 loss_att 23.910414 loss_ctc 46.206657 history loss 92.288636 rank 1
2023-01-30 18:55:21,506 DEBUG CV Batch 4/900 loss 33.508255 loss_att 27.452938 loss_ctc 47.637329 history loss 98.493538 rank 3
2023-01-30 18:55:21,754 DEBUG CV Batch 4/900 loss 33.477356 loss_att 27.457464 loss_ctc 47.523773 history loss 98.568809 rank 0
2023-01-30 18:55:22,038 DEBUG CV Batch 4/900 loss 33.460239 loss_att 27.503674 loss_ctc 47.358894 history loss 98.430041 rank 1
2023-01-30 18:55:23,380 DEBUG CV Batch 4/900 loss 33.436291 loss_att 27.461983 loss_ctc 47.376347 history loss 98.415872 rank 2
2023-01-30 18:55:39,040 INFO Epoch 4 CV info cv_loss 98.36615292046831
2023-01-30 18:55:39,041 INFO Epoch 4 TRAIN info final lr 0.0003261806929873899
2023-01-30 18:55:39,041 INFO Checkpoint: save to checkpoint exp/conformer_wavaug1/4.pt
2023-01-30 18:55:39,092 INFO Epoch 4 CV info cv_loss 98.3194536657683
2023-01-30 18:55:39,093 INFO Epoch 4 TRAIN info final lr 0.0003262001287504334
2023-01-30 18:55:39,093 INFO Epoch 5 TRAIN info init lr 0.0003262001287504334
2023-01-30 18:55:39,097 INFO using accumulate grad, new batch size is 16 times larger than before
2023-01-30 18:55:39,544 INFO Epoch 4 CV info cv_loss 98.33389081785192
2023-01-30 18:55:39,545 INFO Epoch 4 TRAIN info final lr 0.0003261862457080438
2023-01-30 18:55:39,545 INFO Epoch 5 TRAIN info init lr 0.0003261862457080438
2023-01-30 18:55:39,549 INFO using accumulate grad, new batch size is 16 times larger than before
2023-01-30 18:55:39,867 INFO Epoch 4 CV info cv_loss 98.20686797192958
2023-01-30 18:55:39,867 INFO Epoch 4 TRAIN info final lr 0.0003261917987122867
2023-01-30 18:55:39,867 INFO Epoch 5 TRAIN info init lr 0.0003261917987122867
2023-01-30 18:55:39,869 INFO using accumulate grad, new batch size is 16 times larger than before
2023-01-30 18:55:41,034 INFO Epoch 5 TRAIN info init lr 0.0003261806929873899
2023-01-30 18:55:41,038 INFO using accumulate grad, new batch size is 16 times larger than before
2023-01-30 18:56:46,874 DEBUG TRAIN Batch 5/0 loss 17.460732 loss_att 14.531824 loss_ctc 24.294846 lr 0.00032619 rank 2
2023-01-30 18:56:46,879 DEBUG TRAIN Batch 5/0 loss 14.466322 loss_att 11.996610 loss_ctc 20.228985 lr 0.00032620 rank 3
2023-01-30 18:56:46,882 DEBUG TRAIN Batch 5/0 loss 18.419432 loss_att 15.551132 loss_ctc 25.112129 lr 0.00032618 rank 1
2023-01-30 18:56:46,882 DEBUG TRAIN Batch 5/0 loss 38.082077 loss_att 26.783554 loss_ctc 64.445297 lr 0.00032618 rank 0

Then I change the model config, with:
    output_size: 512    # dimension of attention
    attention_heads: 8
    linear_units: 2048  # the number of units of position-wise feed forward

and  lr: 0.001 Then the model can be trained successfully.
I've tried to debug, but i still can't find the reason.

btw, The dict I used is 6300 Chinese chars and 5700 English BPE.

I found out the reason of my case, I changed the default SpecaugConf to:
    spec_aug_conf:
        num_t_mask: 2
        num_f_mask: 2
        max_t: 30
        max_f: 20

Because I use this config for my previous experiments.
This is OK with bigger Model. But smaller model may not learn the features well because of too many masks in y-axis.


Oops, Failed to convert world

Chunker Version
1.2.0-main-4ae23ae
Input World Version
Bedrock 1.21.30
Output World Version
Java 1.21.1
Platform / Operating System
win32-x64-10.0.22631
Issue Description
Error Chunker Displayed: A fatal error occurred during conversion.
Error identifier: 3e9bda0f-712f-4839-b4d5-bf4e9448a15a

This seems like a duplicate of https://github.com/HiveGamesOSS/Chunker/issues/71, we'll update that issue when a fix is released.


Possible bug?

I'm not sure if I'm using your library as intended, but I'm getting a lot of errors, like no parser registered on:
var bestEffortJsonParser = require("best-effort-json-parser")

const a = `{
a: "abc"`

let data = bestEffortJsonParser.parse(a)
console.log(data)

var bestEffortJsonParser = require("best-effort-json-parser")

const a = `{
a: "abc",
b: "def"
}`

let data = bestEffortJsonParser.parse(a)
console.log(data)

In a proper JSON string, the object key should be wrapped with double quotation.
For example:
{
  "a": "abc",
  "b": "def"
}

Maybe this library can do better effort to handle this kind of invalid but understandable input as well

yeah, some error handling would be better.. I ended up just using a different library

The update is released to npm as<EMAIL_ADDRESS>:rocket:
Feel free to re-open the issue if it doesn't address your case


Adding kubernetes resources to inventory

Opened #2916 instead as this PR has a commit that does not pass the cla/google check and we're not supposed to remove that flag.


Server is running, but do not appear on the steam serverlist

Server is running, appears shortly on the steam serverlist but dissappears immediately after finish refreshing. I can connect to the server if i am fast enough to klick on it while refreshing. Ingame serverlist is no problem.

okay. it was my bad. sorry. everything is okay =)


Use ExecutorService instead of ScheduledExecutorService where necessary

Fixes #9286
Description

Changed the two instances mentioned in the PR to use Execs.singleThreaded, which returns an ExecutorService, instead of a ScheduledExecutorService.
I looked at the concurrency checklist (Threads and Executors section), but don't see anything immediate that I also need to do. Please correct me if I missed something.

This PR has:

[x] been self-reviewed.

[x] using the concurrency checklist (Remove this item if the PR doesn't have any relation to concurrency.)

Hi @mgill25, thank you for your contribution. The change looks good to me, but technically this PR doesn’t fix the issue #9286 because it is about prohibiting this pattern by adding a new inspection rule. Are you interested in adding such a rule? If so please include the new rule in the PR. If not, please update the PR description to not include “Fixes #9286”.

@jihoonson My bad, I'm not too familiar with IntelliJ inspection, so I guess I missed it. :)


Create Posts “slug-test”

Automatically generated by Netlify CMS

👷 Deploy Preview for prismatic-hummingbird-16bb46 processing.

Name
Link

🔨 Latest commit
be46d277e9d8281d6d1ad35edab09d8dda63bf38

🔍 Latest deploy log
https://app.netlify.com/sites/prismatic-hummingbird-16bb46/deploys/63c3b3749459290008b80393


fix: return early from compile if not args.flags

Bug introduced in https://github.com/krady21/compiler-explorer.nvim/commit/761db3a6f7398ebd472b220b5f4b2937bd0e1c82
Previously, compile would continue execution only if the user exited/cancelled the compiler options prompt (i.e., only if get_input returned nil).

Thanks for catching this. Should be merged now.


[Spark 41366][CONNECT] DF.groupby.agg() should be compatible

What changes were proposed in this pull request?
This patch fixes small inconsistencies between the PySpark API and Spark Connect.
Why are the changes needed?
Compatibility
Does this PR introduce any user-facing change?
No
How was this patch tested?
UT

Can one of the admins verify this patch?


[Feature][Connector-v2] Support iceberg sink

Search before asking

[X] I had searched in the feature and found no similar feature requirement.

Description
Support iceberg sink #1946
Usage Scenario
No response
Related issues
No response
Are you willing to submit a PR?

[x] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

@2013650523

hi,I am working on the Sink Iceberg.

link #2615

i can work for it

You are welcome.

file compression reference：
https://iceberg.apache.org/docs/latest/flink/#rewrite-files-action
https://github.com/apache/iceberg/blob/master/flink/v1.15/flink/src/test/java/org/apache/iceberg/flink/actions/TestRewriteDataFilesAction.java#L168

@s7monk is this pr in progress?

I have worked on it in recent one week, and in testing progress

hi,I am working on the Sink Iceberg.

hi，is Sink Iceberg feature is finish？

@liugddx plz assign it to me. thx

hi，is Sink Iceberg feature is finish？When can it be used normally

@hailin0 hi, do you have the V2 connectors Development Guide? I want to develop my own connector based on seatunnel

I have finished two connector, sqs source connector and iceberg sink connector

when do we can see this feature?

when do we can see this feature?

@molsionmo Any progress yet?

is it ok?

how can find the iceberg sink connector v2?

support yet?

自动seatunnel的引擎的 sink iceberg的功能啥时候可以发布测试？

I have finished two connector, sqs source connector and iceberg sink connector

@bing-h  upload your code ?


Add support for convenient non-generic codec definition

circe currently doesn't include anything like Argonaut's jdecodeNL, casecodecN, etc.—you can define instances entirely by hand, semi-automatically with io.circe.generic.semiauto._, or fully automatically with io.circe.generic.auto._, but that's it.
There's currently no arity-level boilerplate in the core project, and I'm not sure how I want to handle this, but I want to provide something comparable to casecodecN in 0.3.0.

This will be easier now that the basic machinery for boilerplate is set up in #42.

Added in #237.


readme: replace Slack badge with Discuss link

Summary
Replace the Slack badge with a link to https://discuss.pomerium.com.
Related issues

https://github.com/pomerium/internal/issues/1858

Checklist

[x] reference any related issues
[ ] updated docs
[ ] updated unit tests
[ ] updated UPGRADING.md
[ ] add appropriate tag (improvement / bug / etc)
[ ] ready for review

coverage: 69.577%. remained the same
when pulling 3dab96fb822b695f21fe612b0fcae7f7a14bd679 on kenjenkins/readme
into 5829ef018013268b0f59d8446848ccae0da51358 on main.


Ionic v4 : Cannot to use ViewController

Bug Report
Ionic Info
Run ionic info from a terminal/cmd prompt and paste the output below.
Ionic:
ionic (Ionic CLI)          : 4.0.5 (/home/mrnvr/.config/yarn/global/node_modules/ionic)
Ionic Framework            : @ionic/angular 4.0.0-beta.2
@angular-devkit/core       : 0.7.3
@angular-devkit/schematics : 0.7.3
@angular/cli               : 6.1.3
@ionic/ng-toolkit          : 1.0.6
@ionic/schematics-angular  : 1.0.4
System:
NodeJS : v8.11.2 (/usr/bin/node)
npm    : 6.3.0
OS     : Linux 4.13
Describe the Bug
A clear and concise description of what the bug is.
Cannot use ViewController.
Steps to Reproduce
Steps to reproduce the behavior:

When the IDE imports it, I get
import { ViewController } from '@ionic/angular/dist/types/components/nav/view-controller';.
Then when I try to build/serve my project it displays
ERROR in node_modules/@ionic/angular/dist/types/components/nav/view-controller.d.ts(1,56): error TS2307: Cannot find module '../../interface'
I change the import to import { ViewController } from @ionic/angular, I get
TS2305: Module '"/home/marin/WebstormProjects/keyclic/applications/node_modules/@ionic/angular/dist/index"' has no exported member 'ViewController'.

Expected Behavior
A clear and concise description of what you expected to happen.
Being able to use ViewController
Additional Context
List any other information that is relevant to your issue. Stack traces, related issues, suggestions on how to fix, Stack Overflow links, forum links, screenshots, OS if applicable, etc.
I have the same problem as this issue #14749

Thanks it works. I thought you could only dismiss the modal from the component which created the modal.

@peterpeterparker  you saved me many times today.  V4 is amazing i don t regret switching even in Beta mode :D