text:
New task for adding scalar values  (0 or 1)

Common Settings
The model is trained on 2-layer feedforward controller (with hidden sizes 128 and 256 respectively) with the following set of hyperparameters:

RMSProp Optimizer with learning rate of 10⁻⁴, momentum of 0.9.
Memory word size of 10, with a single read head.
A batch size of 1.
input_size = 3.
output_size = 1.
sequence_max_length = 100.
words_count = 15.
word_size = 10.
read_heads = 1.

A square loss function of the form: (y - y_)**2 is used. Where both 'y' and 'y_' are scalar numbers.
The input is a (1, random_length, 3) tensor, where the 3 is for a one-hot encoding vector of size 3, where:
010 is a '0'
100 is a '1'
001 is the end mark
So, and example of an input of length 10 will be the next 3D-tensor:
[[[ 0.  1.  0.]
[ 0.  1.  0.]
[ 0.  1.  0.]
[ 1.  0.  0.]
[ 0.  1.  0.]
[ 0.  1.  0.]
[ 1.  0.  0.]
[ 0.  1.  0.]
[ 0.  1.  0.]
[ 0.  0.  1.]]]
This input is a represenation of a sequence of adding 0 or 1 values in the form of:
0 + 0 + 1 + 0 + 0 + 1 + 0 + 0 + (end_mark)
The target outoput is a 3D-tensor with the result of this adding task. In the example above:
[[[2.0]]]
The DNC output is a 3D-tensor of shape (1, random_length, 1). For example:
[[[ 0.45]
[ -0.11]
[ 1.3]
[ 5.0]
[ 0.5]
[ 0.1]
[ 1.0]
[ -0.5]
[ 0.33]
[ 0.12]]]
The target output and the DNC output are both then reduced with tf.reduce_sum() so we end up with two scalar values. For example:
Target_output: 2.0
DNC_output:    5.89
And we apply then the square loss function:
loss = (Target_o - DNC_o)**2
and finally the gradient update.
Results
The model is going to recieve as input a random length sequence of 0 or 1 values like:
Input: 1 + 0 + 1 + 1 + 0 + 0 + 0 + 0 + 1
Then it will return a scalar value for this input adding proccess. For example, the DNC will output something like: 3.98824.
This value will be the predicted result for the input adding sequence (we are going to truncate the integer part of the result):
DNC prediction:   1 + 0 + 1 + 1 + 0 + 0 + 0 + 0 + 1  = 3 [3.98824]
Once we train the model with:
$python tasks/copy/train.py --iterations=50000

we can see that the model learns in less than 1000 iterations to compute this adding function, and the loss drop from:
Iteration 0/1000
Avg. Logistic Loss: 24.9968
to:
Iteration 1000/1000
Avg. Logistic Loss: 0.0076
It seems like the DNC model is able to learn this pseudo-code:
function(x):
if (x == [ 1.  0.  0.])
return (near) 1.0 (float values)
else
return (near) 0.0 (float values)
Generalization test
We use for the model a sequence_max_length = 100, but in the training proccess we use just random length sequences up to 10 (sequence_max_length/10). Once the train is finished, we let the trained model to generalize to random length sequences up to 100 (sequence_max_length).
Results show that the model successfully generalize the adding task even with sequence 10 times larger than the training ones.
These are real data outputs:
Building Computational Graph ... Done!
Initializing Variables ... Done!
Iteration 0/1000
Avg. Logistic Loss: 24.9968
Real value:  0 + 1 + 0 + 0 + 0 + 1 + 0 + 1 + 1 + 1  = 5
Predicted:   0 + 1 + 0 + 0 + 0 + 1 + 0 + 1 + 1 + 1  = 0 [0.000319847]
Iteration 100/1000
Avg. Logistic Loss: 5.8042
Real value:  0 + 1 + 0 + 0 + 1 + 0 + 1 + 0 + 1 + 1  = 5
Predicted:   0 + 1 + 0 + 0 + 1 + 0 + 1 + 0 + 1 + 1  = 6 [6.1732]
Iteration 200/1000
Avg. Logistic Loss: 0.7492
Real value:  1 + 1 + 1 + 1 + 1 + 1 + 1 + 0 + 1 + 1  = 9
Predicted:   1 + 1 + 1 + 1 + 1 + 1 + 1 + 0 + 1 + 1  = 8 [8.91952]
Iteration 300/1000
Avg. Logistic Loss: 0.0253
Real value:  0 + 1 + 1  = 2
Predicted:   0 + 1 + 1  = 2 [2.0231]
Iteration 400/1000
Avg. Logistic Loss: 0.0089
Real value:  0 + 1 + 0 + 0 + 0 + 1 + 1  = 3
Predicted:   0 + 1 + 0 + 0 + 0 + 1 + 1  = 2 [2.83419]
Iteration 500/1000
Avg. Logistic Loss: 0.0444
Real value:  1 + 0 + 1 + 1  = 3
Predicted:   1 + 0 + 1 + 1  = 2 [2.95937]
Iteration 600/1000
Avg. Logistic Loss: 0.0093
Real value:  1 + 0 + 1 + 1 + 0 + 0 + 0 + 0 + 1  = 4
Predicted:   1 + 0 + 1 + 1 + 0 + 0 + 0 + 0 + 1  = 3 [3.98824]
Iteration 700/1000
Avg. Logistic Loss: 0.0224
Real value:  0 + 1 + 1 + 0 + 1 + 1 + 1 + 1 + 0 + 0  = 6
Predicted:   0 + 1 + 1 + 0 + 1 + 1 + 1 + 1 + 0 + 0  = 5 [5.93554]
Iteration 800/1000
Avg. Logistic Loss: 0.0115
Real value:  0 + 0  = 0
Predicted:   0 + 0  = -1 [-0.0118587]
Iteration 900/1000
Avg. Logistic Loss: 0.0023
Real value:  1 + 1 + 0 + 0 + 1 + 1 + 1 + 0 + 0  = 5
Predicted:   1 + 1 + 0 + 0 + 1 + 1 + 1 + 0 + 0  = 4 [4.97147]
Iteration 1000/1000
Avg. Logistic Loss: 0.0076
Real value:  1 + 0 + 0 + 1 + 1 + 0 + 0 + 1  = 4Done!
Testing generalization...
Iteration 0/1000
Predicted:   1 + 0 + 0 + 1 + 1 + 0 + 0 + 1  = 4 [4.123]
Saving Checkpoint ...
Real value:  1 + 1 + 0 + 0 + 0 + 1 + 0 + 0 + 1 + 1 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 1 + 0 + 0  = 6
Predicted:   1 + 1 + 0 + 0 + 0 + 1 + 0 + 0 + 1 + 1 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 1 + 0 + 0  = 6 [6.24339]
Iteration 1/1000
Real value:  1 + 0 + 1 + 0 + 0 + 1 + 1 + 0 + 1 + 1 + 1 + 0 + 1 + 0 + 0 + 0 + 0 + 1 + 0 + 0 + 1 + 1  = 11
Predicted:   1 + 0 + 1 + 0 + 0 + 1 + 1 + 0 + 1 + 1 + 1 + 0 + 1 + 0 + 0 + 0 + 0 + 1 + 0 + 0 + 1 + 1  = 11 [11.1931]
Iteration 2/1000
Real value:  0 + 0 + 0 + 1 + 0 + 0 + 0 + 1 + 1 + 1 + 0 + 1 + 1 + 0 + 1 + 0 + 1 + 0 + 0 + 1 + 0 + 1 + 1 + 0 + 0 + 0 + 1 + 0 + 1 + 0 + 0 + 1 + 0 + 1 + 1 + 0 + 1 + 0 + 1 + 1 + 0 + 1 + 1 + 1 + 0 + 1 + 0 + 0 + 1 + 1 + 0 + 0 + 1 + 0 + 0 + 0 + 1 + 0 + 1 + 0 + 0 + 0 + 1 + 0 + 0 + 0 + 1 + 1 + 1 + 1  = 33
Predicted:   0 + 0 + 0 + 1 + 0 + 0 + 0 + 1 + 1 + 1 + 0 + 1 + 1 + 0 + 1 + 0 + 1 + 0 + 0 + 1 + 0 + 1 + 1 + 0 + 0 + 0 + 1 + 0 + 1 + 0 + 0 + 1 + 0 + 1 + 1 + 0 + 1 + 0 + 1 + 1 + 0 + 1 + 1 + 1 + 0 + 1 + 0 + 0 + 1 + 1 + 0 + 0 + 1 + 0 + 0 + 0 + 1 + 0 + 1 + 0 + 0 + 0 + 1 + 0 + 0 + 0 + 1 + 1 + 1 + 1  = 32 [32.9866]
Iteration 3/1000
Real value:  1 + 0 + 1 + 1 + 0 + 1 + 0 + 0 + 1 + 1 + 0 + 0 + 0 + 1 + 0 + 0 + 1 + 1 + 0 + 1 + 1 + 1 + 0 + 1 + 0 + 0 + 1 + 0 + 0 + 0 + 1 + 1  = 16
Predicted:   1 + 0 + 1 + 1 + 0 + 1 + 0 + 0 + 1 + 1 + 0 + 0 + 0 + 1 + 0 + 0 + 1 + 1 + 0 + 1 + 1 + 1 + 0 + 1 + 0 + 0 + 1 + 0 + 0 + 0 + 1 + 1  = 16 [16.1541]
Iteration 4/1000
Real value:  1 + 0 + 0 + 1 + 1 + 1 + 0 + 0 + 1 + 0 + 0 + 0 + 0 + 1 + 1 + 1 + 0 + 1 + 1 + 1 + 1 + 0 + 0 + 0 + 0 + 0 + 1 + 0 + 1 + 0 + 1 + 1 + 0 + 0 + 0 + 1 + 0 + 1 + 1 + 1 + 1 + 0 + 0 + 1 + 0 + 1 + 1 + 1 + 1 + 0 + 1 + 0 + 0 + 1 + 0 + 1 + 1 + 0 + 1 + 0 + 0 + 0 + 0 + 1 + 1 + 1 + 1 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 1 + 1 + 0 + 1 + 0 + 1 + 0 + 1 + 1 + 1 + 1 + 0 + 1 + 0 + 0  = 44
Predicted:   1 + 0 + 0 + 1 + 1 + 1 + 0 + 0 + 1 + 0 + 0 + 0 + 0 + 1 + 1 + 1 + 0 + 1 + 1 + 1 + 1 + 0 + 0 + 0 + 0 + 0 + 1 + 0 + 1 + 0 + 1 + 1 + 0 + 0 + 0 + 1 + 0 + 1 + 1 + 1 + 1 + 0 + 0 + 1 + 0 + 1 + 1 + 1 + 1 + 0 + 1 + 0 + 0 + 1 + 0 + 1 + 1 + 0 + 1 + 0 + 0 + 0 + 0 + 1 + 1 + 1 + 1 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 1 + 1 + 0 + 1 + 0 + 1 + 0 + 1 + 1 + 1 + 1 + 0 + 1 + 0 + 0  = 43 [43.5211]

Impressive work!
I'm certainly curious about how it was able to generalize with the same amount of memory locations!
What do you think about taking it up a notch?
Let's remove that reduce_sum and see if it can learn to add on its own. Here's how I think it could go: your input sequence would go something like this:
1 + 0 + 0 + 1 + 1 + 1 + 0 + 1 + 0 = , and your target output would be the scalar 5. instead of attempting to copy the sequence via adding, we make the task that at the step containing '' the model should output the value of the summation! Your loss would be the squared difference between between the output at that step and your target output, the loss at all previous step is omitted (you can find the technique of omitting the loss on specific steps in the recently pushed bAbI task).
I've just pushed new updates to the code that include optimizations in both memory and execution time performance, so you would be able to leave it training for more iterations while doing this more quickly!
I'm looking forwrad to see your results with this!

Hello, @Mostafa-Samir.
You can get the code of the adding task without the tf.resume_sum() in here: https://github.com/Zeta36/DNC-tensorflow/blob/master/tasks/adding/train_v2.py.
But I'm afraid that removing the tf.reduce_sum() makes the model unable to generalize with success with a fixed memory size as before. In this new version of the code, the model is still able to learn to resolve any sequence of 0 and 1 sums, but it fails when we try to use the learned model to larger sequences than that used in the training process.
I think that's because the original version I pulled here make use of the tf.reduce_sum() as a way of accumulator. I think the model learns an algorithm like this:
function(X):
for each x in X:
if (x == [ 1. 0. 0.])
return (near) 1.0 (float value)
else
return (near) 0.0 (float value)
And later, the tf.reduce_sum() makes the correct sum over all the sequence output. The output will have a nearly 1 for each [ 1. 0. 0.] input vector, and a nearly 0 in other case, and finally the tf.reduce_sum() will give the correct answer no matter the large the input is. And I think is because this little "if else"  f(x) algorithm is easy to learn that the model is able to generalize to unlimited large inputs X sequences with a fixed memory size.
As soon as we remove the tf.reduce_sum() like in the version I made following your instructions, this trick doesn't work and the model has to learn other more complex and less generalizable algorithm than the f(x) I told you before.
What do you think, @Mostafa-Samir?
Regards,
Samu.

Here you have a little excerpt of a real training result:
Iteration 800/1001
Avg. Cross-Entropy: 0.0231753
Avg. 100 iterations time: 0.03 minutes
Approx. time to completion: 0.00 hours
DNC input
[[[ 0.  1.  0.]
[ 1.  0.  0.]
[ 0.  1.  0.]
[ 1.  0.  0.]
[ 0.  1.  0.]
[ 0.  1.  0.]
[ 0.  0.  1.]]]
Text input:      1 + 0 + 1 + 0 + 1 + 1  = -
Target_output [[[ 0.]
[ 0.]
[ 0.]
[ 0.]
[ 0.]
[ 0.]
[ 4.]]]
DNC output [[[ 0.        ]
[ 0.        ]
[ 0.        ]
[ 0.        ]
[ 0.        ]
[ 0.        ]
[ 3.52538943]]]
Real operation:    1 + 0 + 1 + 0 + 1 + 1  = 4
Predicted result:  1 + 0 + 1 + 0 + 1 + 1  = 4 [3.52539]
...
...
Iteration 1000/1001
Avg. Cross-Entropy: 0.0046492
Avg. 100 iterations time: 0.03 minutes
Approx. time to completion: 0.00 hours
DNC input
[[[ 0.  1.  0.]
[ 1.  0.  0.]
[ 1.  0.  0.]
[ 1.  0.  0.]
[ 1.  0.  0.]
[ 1.  0.  0.]
[ 1.  0.  0.]
[ 0.  0.  1.]]]
Text input:      1 + 0 + 0 + 0 + 0 + 0 + 0  = -
Target_output [[[ 0.]
[ 0.]
[ 0.]
[ 0.]
[ 0.]
[ 0.]
[ 0.]
[ 1.]]]
DNC output [[[ 0.        ]
[ 0.        ]
[ 0.        ]
[ 0.        ]
[ 0.        ]
[ 0.        ]
[ 0.        ]
[ 0.86268544]]]
Real operation:    1 + 0 + 0 + 0 + 0 + 0 + 0  = 1
Predicted result:  1 + 0 + 0 + 0 + 0 + 0 + 0  = 1 [0.862685]
Iteration 1001/1001
Saving Checkpoint ... Done!
Testing generalization...
Iteration 0/1000
Real operation:    1 + 0 + 1 + 0 + 0 + 1 + 0 + 0 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 0 + 1 + 0 + 0 + 0 + 0 + 1 + 1 + 0 + 0 + 1 + 1 + 0 + 0 + 1 + 0 + 1 + 1 + 1 + 1 + 0 + 0 + 1 + 1 + 0 + 1 + 0 + 1 + 1 + 0 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 0 + 0 + 1 + 0 + 1 + 1 + 1 + 1 + 1 + 0 + 1 + 1 + 0 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 0 + 1 + 0 + 1 + 1 + 1 + 0 + 0 + 0  = 56
Predicted result:  1 + 0 + 1 + 0 + 0 + 1 + 0 + 0 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 0 + 1 + 0 + 0 + 0 + 0 + 1 + 1 + 0 + 0 + 1 + 1 + 0 + 0 + 1 + 0 + 1 + 1 + 1 + 1 + 0 + 0 + 1 + 1 + 0 + 1 + 0 + 1 + 1 + 0 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 0 + 0 + 1 + 0 + 1 + 1 + 1 + 1 + 1 + 0 + 1 + 1 + 0 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 0 + 1 + 0 + 1 + 1 + 1 + 0 + 0 + 0  = 9316 [[ 9316.20117188]]
Iteration 1/1000
Real operation:    1 + 0  = 1
Predicted result:  1 + 0  = 1 [[ 0.853342]]
Iteration 2/1000
Real operation:    1 + 0 + 1 + 1 + 1 + 1 + 0 + 0 + 1 + 0 + 1 + 0 + 0 + 0 + 0 + 0 + 0 + 1 + 1 + 0 + 0 + 0 + 0 + 1 + 1 + 1 + 1 + 0 + 1 + 1 + 0 + 0 + 0 + 0 + 1 + 0 + 1  = 17
Predicted result:  1 + 0 + 1 + 1 + 1 + 1 + 0 + 0 + 1 + 0 + 1 + 0 + 0 + 0 + 0 + 0 + 0 + 1 + 1 + 0 + 0 + 0 + 0 + 1 + 1 + 1 + 1 + 0 + 1 + 1 + 0 + 0 + 0 + 0 + 1 + 0 + 1  = 74 [[ 73.88546753]]

@Mostafa-Samir, due to the great improvement in the core of your DNC implementation I've developed another task for testing the project.  I've developed a model that successfully is able to learn a argmax function over a input.
The model is feed with a vector of one_hot integer values, and the target output is the index of the vector with the maximum value. I'm glad to say you that your DNC is able to learn this function using just a feedforward controller, and even better, ¡is able to generalize to larger vectors of those used in the training process!
You can test the code here: https://github.com/Zeta36/DNC-tensorflow/blob/master/tasks/argmax/train_v2.py.
You can see some results here:
...
...
Iteration 9900/10001
Avg. Cross-Entropy: 0.1064857
Avg. 100 iterations time: 0.16 minutes
Approx. time to completion: 0.00 hours
DNC input [[[ 0.  0.  1.  0.  0.  0.  0.  0.  0.  0.]
[ 0.  0.  0.  0.  0.  0.  0.  1.  0.  0.]
[ 0.  0.  0.  1.  0.  0.  0.  0.  0.  0.]
[ 0.  0.  0.  0.  0.  1.  0.  0.  0.  0.]
[ 1.  0.  0.  0.  0.  0.  0.  0.  0.  0.]
[ 0.  0.  0.  0.  0.  0.  0.  1.  0.  0.]
[ 0.  0.  0.  1.  0.  0.  0.  0.  0.  0.]
[ 0.  0.  1.  0.  0.  0.  0.  0.  0.  0.]
[ 0.  0.  0.  0.  0.  1.  0.  0.  0.  0.]
[ 0.  0.  0.  0.  0.  0.  0.  1.  0.  0.]
[ 0.  0.  0.  0.  0.  0.  1.  0.  0.  0.]
[ 0.  1.  0.  0.  0.  0.  0.  0.  0.  0.]
[ 0.  0.  0.  0.  0.  0.  0.  0.  0.  1.]]]
Target_output [[[ 0.]
[ 0.]
[ 0.]
[ 0.]
[ 0.]
[ 0.]
[ 0.]
[ 0.]
[ 0.]
[ 0.]
[ 0.]
[ 0.]
[ 1.]]]
DNC output [[[ 0.        ]
[-0.        ]
[ 0.        ]
[ 0.        ]
[ 0.        ]
[ 0.        ]
[ 0.        ]
[ 0.        ]
[ 0.        ]
[ 0.        ]
[ 0.        ]
[ 0.        ]
[ 1.44688594]]]
Real argmax(X):  1
Predicted f(X):  1
Iteration 10000/10001
Avg. Cross-Entropy: 0.0603415
Avg. 100 iterations time: 0.16 minutes
Approx. time to completion: 0.00 hours
DNC input [[[ 0.  0.  1.  0.  0.  0.  0.  0.  0.  0.]
[ 0.  0.  0.  1.  0.  0.  0.  0.  0.  0.]
[ 0.  0.  1.  0.  0.  0.  0.  0.  0.  0.]
[ 0.  0.  0.  0.  0.  1.  0.  0.  0.  0.]
[ 1.  0.  0.  0.  0.  0.  0.  0.  0.  0.]
[ 0.  0.  0.  0.  0.  0.  0.  0.  1.  0.]
[ 0.  0.  0.  1.  0.  0.  0.  0.  0.  0.]
[ 0.  0.  0.  0.  0.  1.  0.  0.  0.  0.]
[ 0.  0.  0.  1.  0.  0.  0.  0.  0.  0.]
[ 0.  0.  0.  0.  1.  0.  0.  0.  0.  0.]
[ 0.  0.  0.  0.  0.  0.  0.  0.  0.  1.]]]
Target_output [[[ 0.]
[ 0.]
[ 0.]
[ 0.]
[ 0.]
[ 0.]
[ 0.]
[ 0.]
[ 0.]
[ 0.]
[ 5.]]]
DNC output [[[ 0.        ]
[ 0.        ]
[ 0.        ]
[ 0.        ]
[ 0.        ]
[ 0.        ]
[ 0.        ]
[ 0.        ]
[ 0.        ]
[ 0.        ]
[ 4.93556786]]]
Real argmax(X):  5
Predicted f(X):  5
Saving Checkpoint ... Done!
Testing generalization...
Iteration 0/10000
Real argmax(X):  3
Predicted f(X):    3
Iteration 1/10000
Real argmax(X):  2
Predicted f(X):    2
Iteration 2/10000
Real argmax(X):  4
Predicted f(X):    3
Iteration 3/10000
Real argmax(X):  0
Predicted f(X):    0
Iteration 4/10000
Real argmax(X):  1
Predicted f(X):    1
Iteration 5/10000
Real argmax(X):  3
Predicted f(X):    3
Iteration 6/10000
Real argmax(X):  1
Predicted f(X):    2
Iteration 7/10000
Real argmax(X):  3
Predicted f(X):    2
Iteration 8/10000
Real argmax(X):  6
Predicted f(X):    6
Iteration 9/10000
Real argmax(X):  5
Predicted f(X):    4
Iteration 10/10000
Real argmax(X):  2
Predicted f(X):    2
Iteration 11/10000
Real argmax(X):  5
Predicted f(X):    4
Iteration 12/10000
Real argmax(X):  2
Predicted f(X):    2
Iteration 13/10000
Real argmax(X):  0
Predicted f(X):    2
Iteration 14/10000
Real argmax(X):  2
Predicted f(X):    5
Iteration 15/10000
Real argmax(X):  0
Predicted f(X):    0
Iteration 16/10000
Real argmax(X):  1
Predicted f(X):    1
Iteration 17/10000
Real argmax(X):  2
Predicted f(X):    2
Iteration 18/10000
Real argmax(X):  2
Predicted f(X):    2
Iteration 19/10000
Real argmax(X):  2
Predicted f(X):    2
Iteration 20/10000
Real argmax(X):  1
Predicted f(X):    1
Iteration 21/10000
Real argmax(X):  4
Predicted f(X):    4
Iteration 22/10000
Real argmax(X):  10
Predicted f(X):    10
Iteration 23/10000
Real argmax(X):  6
Predicted f(X):    5
Iteration 24/10000
Real argmax(X):  1
Predicted f(X):    2
Iteration 25/10000
Real argmax(X):  4
Predicted f(X):    3
Iteration 26/10000
Real argmax(X):  1
Predicted f(X):    3
Iteration 27/10000
Real argmax(X):  2
Predicted f(X):    2
Iteration 28/10000
Real argmax(X):  0
Predicted f(X):    0
Iteration 29/10000
Real argmax(X):  3
Predicted f(X):    3
Iteration 30/10000
Real argmax(X):  0
Predicted f(X):    0
Iteration 31/10000
Real argmax(X):  0
Predicted f(X):    0
Iteration 32/10000
Real argmax(X):  0
Predicted f(X):    0
Iteration 33/10000
Real argmax(X):  0
Predicted f(X):    0
Iteration 34/10000
Real argmax(X):  6
Predicted f(X):    6
Iteration 35/10000
Real argmax(X):  0
Predicted f(X):    0
Iteration 36/10000
Real argmax(X):  5
Predicted f(X):    4
Iteration 37/10000
Real argmax(X):  0
Predicted f(X):    0
Iteration 38/10000
Real argmax(X):  2
Predicted f(X):    2
Iteration 39/10000
Real argmax(X):  3
Predicted f(X):    3
Iteration 40/10000
Real argmax(X):  4
Predicted f(X):    4
Iteration 41/10000
Real argmax(X):  6
Predicted f(X):    6
Iteration 42/10000
Real argmax(X):  15
Predicted f(X):    14
Iteration 43/10000
Real argmax(X):  1
Predicted f(X):    1
Iteration 44/10000
Real argmax(X):  2
Predicted f(X):    2
Iteration 45/10000
Real argmax(X):  11
Predicted f(X):    10
Iteration 46/10000
Real argmax(X):  3
Predicted f(X):    3
Iteration 47/10000
Real argmax(X):  1
Predicted f(X):    1
Iteration 48/10000
Real argmax(X):  1
Predicted f(X):    1
Iteration 49/10000
Real argmax(X):  13
Predicted f(X):    13
...
...
I don't know how the hell the model is able to figure out where has been the highest value in the sequence of onehot encoded input values but it does, and even is able to generalize this learned method to sequences double of the size used in the training process without more memory use. DeepMind has found something big with this DNC, and there are improving it with a sparse version able to use less resources: https://arxiv.org/pdf/1610.09027v1.pdf
Regards,
Samu.

Great work Samu @Zeta36 !
Regarding the adding task
I have a comment about how you apply the wights to the loss. You use the following:
loss = tf.reduce_mean(tf.square((loss_weights * output) - ncomputer.target_output))

while you should be using:
loss = tf.reduce_mean(loss_weights * tf.square(output - ncomputer.target_output))

Remember, you're weighting the contribution of the loss of each step not the significance of each step on its own. Mathematically it's written as

not

I don't really know how you generate the output vector, but the 1st formulation can easily overestimate your loss value.
Try to adopt this change and see if it has any effect on the model. You should also try to test the generalization of the adding by using the same trained model but with larger memory matrix (more locations) just as you can find in the visualization notebook of the copy task. It'd also be a good idea to separate the generalization tests into different scripts than the training one, and try to use a single descriptive statistic (like the percentage of correct answers, or the percentage of error or whatever you decide) to describe your results so instead of dumping the entire log in the README you can just add one or two examples from the log and describe your results with that statistic!
I'll be happy then to merge your contributions to repo!

Hi @Zeta36 and @Mostafa-Samir ,
I am really excited about the results of your tasks and about the DNC's potentiality.
For this reason, I am trying to implement a further task by myself. I am interested in understanding if a DNC can solve it. I would really appreciate any feedback from you, thanks.
Task description
The task is to count the total number of repeated numbers in a list.
For example:
Input: [ 1, 2, 3]
Output: [0]

Input: [ 1, 2, 3, 2, 4, 1, 5]
                  X     X     : Repetitions
Output: [2]

The pseudo code the DNC should learn is:
function(x, seenNumbers):
   if x in seenNumbers:
       return 1
   else:
       return 0

I am wondering if the DNC can manage by itself the seenNumber list.
Settings
Assuming that the DNC can solve the task (I suppose a simple LSTM net can), I would structure the data as follows:

Input: (1, random length, 1) tensor
Output: Either  (1, random length, 1) tensor or scalar containing the sum of the repetitions
Loss: depending on the output structure, a square loss function element by element or between two scalars
DNC parameters: Currently it is obscure to me how to set the memory parameters (word size, number of words)

What do you think? Do you think that it would be feasible for the DNC to solve the task?
Thanks,
Alessandro

authors: Mostafa-Samir Zeta36 cornagli

repo: Mostafa-Samir/DNC-tensorflow


text:
Cannot read views using geoparquet files while reading from s3 compatible storage

Describe the bug
Using 0.2.12 (Metabase v0.51.3 + DuckDB v1.1.3) Cannot read views using geoparquet files while reading from s3 compatible storage
It worked in version 0.2.9.  (duckdb 1.0.0 , metabase 0.50.33)
To Reproduce
Example view:
create or replace view my_schema.my_geo_table   as
SELECT OBJECTID, CODIGO, SHAPE_Length, SHAPE_Area, codigo_municipio,
CODIGO_DEPARTAMENTO, periodo_anio, unique_id, WKB, WKB_bbox
FROM read_parquet('s3://mybucket/bronze/geo/**/GEOPARQUET/my_geo_table.*.parquet',  hive_partitioning = false);

Example error:

2024-12-09 15:17:18,679 ERROR models.field-values :: Error fetching field values
clojure.lang.ExceptionInfo: Error executing query: java.sql.SQLException: Binder Error: Contents of view were altered: types don't match! Expected [BIGINT, VARCHAR, DOUBLE, DOUBLE, VARCHAR, VARCHAR, INTEGER, VARCHAR, GEOMETRY, STRUCT(xmin FLOAT, ymin FLOAT, xmax FLOAT, ymax FLOAT)], but found [BIGINT, VARCHAR, DOUBLE, DOUBLE, VARCHAR, VARCHAR, INTEGER, VARCHAR, BLOB, STRUCT(xmin FLOAT, ymin FLOAT, xmax FLOAT, ymax FLOAT)] instead {:driver :duckdb, :sql ["-- Metabase" "SELECT" "  \"bronze_cat_geo\".\"r_sector\".\"WKT\" AS \"WKT\"" "FROM" "  \"bronze_cat_geo\".\"r_sector\"" "GROUP BY" "  \"bronze_cat_geo\".\"r_sector\".\"WKT\"" "ORDER BY" "  \"bronze_cat_geo\".\"r_sector\".\"WKT\" ASC" "LIMIT" "  1000"], :params nil, :type :invalid-query}

Caused by: java.sql.SQLException: java.sql.SQLException: Binder Error: Contents of view were altered: types don't match! Expected [BIGINT, VARCHAR, DOUBLE, DOUBLE, VARCHAR, VARCHAR, INTEGER, VARCHAR, GEOMETRY, STRUCT(xmin FLOAT, ymin FLOAT, xmax FLOAT, ymax FLOAT)], but found [BIGINT, VARCHAR, DOUBLE, DOUBLE, VARCHAR, VARCHAR, INTEGER, VARCHAR, BLOB, STRUCT(xmin FLOAT, ymin FLOAT, xmax FLOAT, ymax FLOAT)] instead

Caused by: java.sql.SQLException: Binder Error: Contents of view were altered: types don't match! Expected [BIGINT, VARCHAR, DOUBLE, DOUBLE, VARCHAR, VARCHAR, INTEGER, VARCHAR, GEOMETRY, STRUCT(xmin FLOAT, ymin FLOAT, xmax FLOAT, ymax FLOAT)], but found [BIGINT, VARCHAR, DOUBLE, DOUBLE, VARCHAR, VARCHAR, INTEGER, VARCHAR, BLOB, STRUCT(xmin FLOAT, ymin FLOAT, xmax FLOAT, ymax FLOAT)] instead
        at org.duckdb.DuckDBNative.duckdb_jdbc_prepare(Native Method)

Environment

Docker :  FROM eclipse-temurin:23.0.1_11-jre-noble

Thanks for the report. Is there a sample geoparquet file with this schema you can share with us?

You can find an example in the following file:
dane_mgn_mpio_politico_2021_4326_15.zip

source: gharchive/issue

license_type: permissive

license_source: github-api


text:
Tried creating a world and this happened :(

version 5.3.0 build 11
https://pastebin.com/Z98Nbawc
Terasology Error Report.log

Running engine:5.3.0 with Josharias Survival.
Some errors are logged, but since loading continued I don't think they are responsible for the crash here. Nevertheless, I'd be curious to investigate why this happens.
11:03:15.530 [main] ERROR o.t.g.m.s.JavaModuleClassLoader - Denied access to class (not allowed with this module's permissions): org.terasology.gestalt.module.sandbox.API
11:03:15.530 [main] ERROR o.t.g.m.s.JavaModuleClassLoader - Denied access to class (not allowed with this module's permissions): org.terasology.gestalt.module.sandbox.API
11:03:15.530 [main] ERROR o.t.g.m.s.JavaModuleClassLoader - Denied access to class (not allowed with this module's permissions): org.terasology.gestalt.module.sandbox.API
11:03:15.531 [main] ERROR o.t.g.m.s.JavaModuleClassLoader - Denied access to class (not allowed with this module's permissions): org.terasology.gestalt.module.sandbox.API
11:03:15.552 [main] ERROR o.t.e.u.gson.UriTypeAdapterFactory - URI type interface org.terasology.engine.core.Uri lacks String constructor

There are some more errors on ComponentSystem (I think these are artifacts of a half-finished migration):
11:03:18.407 [main] ERROR o.t.e.core.ComponentSystemManager - Cannot load BulletPhysics, must be a subclass of ComponentSystem
11:03:18.411 [main] ERROR o.t.e.core.ComponentSystemManager - Cannot load ModuleRendering, must be a subclass of ComponentSystem

and finally some warnings about the rendering graph, but the logs seems to be truncated:
11:03:20.188 [main] WARN  o.t.engine.rendering.dag.RenderGraph - WARNING: destination connection (Output:CoreRendering:finalHazeNode:BufferPair1(connected to CoreRendering:alphaRejectBlocksNode:BufferPair1, CoreRendering:opaqueBlocksNode:BufferPair1, CoreRendering:opaqueObjectsNode:BufferPair1, ;)) is already connected to ({CoreRendering:alphaRejectBlocksNode:BufferPair1=Input:CoreRendering:alphaRejectBlocksNode:BufferPair1(connected to CoreRendering:finalHazeNode:BufferPair1, ;), CoreRendering:opaqueBlocksNode:BufferPair1=Input:CoreRendering:opaqueBlocksNode:BufferPair1(connected to CoreRendering:finalHazeNode:BufferPair1, ;), CoreRendering:opaqueObjectsNode:BufferPair1=Input:CoreRendering:opaqueObjectsNode:BufferPair1(connected to CoreRendering:finalHazeNode:BufferPair1, ;)}
11:03:20.188 [main] WARN  o.t.engine.rendering.dag.RenderGraph - Trying to disconnect two nodes that aren'

@Peter226 are you sure these logs are complete? If you try it again, can you post the full log, most importantly the last parts at the very bottom?

@skaldarnar The logs are complete, it's just a pastebin bug that they are shortened in the normal view. If you look at the raw view everything is there including the actual issue:
11:03:22.103 [main] ERROR o.t.engine.core.modes.StateLoading - Error while loading org.terasology.engine.core.modes.loadProcesses.SetupLocalPlayer@3b308104
java.lang.IllegalArgumentException: Out of bounds: (-33, -33) for region BlockArea[(-30, -30)...(30, 30)]
	at org.terasology.engine.world.generation.facets.base.BaseFacet2D.getWorldIndex(BaseFacet2D.java:41)
	at org.terasology.engine.world.generation.facets.base.BaseFieldFacet2D.getWorld(BaseFieldFacet2D.java:31)
	at org.terasology.core.world.generator.facetProviders.DensityNoiseProvider.process(DensityNoiseProvider.java:59)
	at org.terasology.engine.world.generation.ScalableFacetProvider.process(ScalableFacetProvider.java:10)
	at org.terasology.engine.world.generation.RegionImpl.getFacet(RegionImpl.java:41)
	at org.terasology.engine.logic.spawner.AbstractSpawner.findSpawnPosition(AbstractSpawner.java:46)
	at org.terasology.engine.logic.spawner.FixedSpawner.getSpawnPosition(FixedSpawner.java:36)
	at org.terasology.core.world.generator.worldGenerators.SimplexFacetedWorldGenerator.getSpawnPosition(SimplexFacetedWorldGenerator.java:51)
	at org.terasology.engine.logic.players.PlayerSystem.onConnect(PlayerSystem.java:143)
	at org.terasology.engine.logic.players.PlayerSystemMethodAccess.invoke(Unknown Source)
	at org.terasology.engine.entitySystem.event.internal.EventSystemImpl$ByteCodeEventHandlerInfo.invoke(EventSystemImpl.java:399)
	at org.terasology.engine.entitySystem.event.internal.EventSystemImpl.sendStandardEvent(EventSystemImpl.java:264)
	at org.terasology.engine.entitySystem.event.internal.EventSystemImpl.send(EventSystemImpl.java:255)
	at org.terasology.engine.core.bootstrap.eventSystem.AbstractEventSystemDecorator.send(AbstractEventSystemDecorator.java:67)
	at org.terasology.engine.network.NetworkEventSystemDecorator.send(NetworkEventSystemDecorator.java:54)
	at org.terasology.engine.core.bootstrap.eventSystem.AbstractEventSystemDecorator.send(AbstractEventSystemDecorator.java:67)
	at org.terasology.engine.recording.RecordingEventSystemDecorator.send(RecordingEventSystemDecorator.java:34)
	at org.terasology.engine.entitySystem.entity.internal.BaseEntityRef.send(BaseEntityRef.java:190)
	at org.terasology.engine.network.internal.NetworkSystemImpl.connectClient(NetworkSystemImpl.java:892)
	at org.terasology.engine.network.internal.NetworkSystemImpl.joinLocal(NetworkSystemImpl.java:325)
	at org.terasology.engine.core.modes.loadProcesses.SetupLocalPlayer.step(SetupLocalPlayer.java:29)
	at org.terasology.engine.core.modes.StateLoading.update(StateLoading.java:259)
	at org.terasology.engine.core.TerasologyEngine.tick(TerasologyEngine.java:512)
	at org.terasology.engine.core.TerasologyEngine.mainLoop(TerasologyEngine.java:472)
	at org.terasology.engine.core.TerasologyEngine.runMain(TerasologyEngine.java:448)
	at org.terasology.engine.core.TerasologyEngine.run(TerasologyEngine.java:414)
	at org.terasology.engine.Terasology.call(Terasology.java:190)
	at org.terasology.engine.Terasology.call(Terasology.java:70)
	at picocli.CommandLine.executeUserObject(CommandLine.java:1933)
	at picocli.CommandLine.access$1200(CommandLine.java:145)
	at picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2332)
	at picocli.CommandLine$RunLast.handle(CommandLine.java:2326)
	at picocli.CommandLine$RunLast.handle(CommandLine.java:2291)
	at picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2159)
	at picocli.CommandLine.execute(CommandLine.java:2058)
	at org.terasology.engine.Terasology.main(Terasology.java:139)

@Peter226 This is a sporadic we're currently facing and haven't been able to fix yet (see #5056 )
I'll close this as its a duplicate of that issue tracked in #5056

@skaldarnar The logs are complete, it's just a pastebin bug that they are shortened in the normal view. If you look at the raw view everything is there including the actual issue:
11:03:22.103 [main] ERROR o.t.engine.core.modes.StateLoading - Error while loading org.terasology.engine.core.modes.loadProcesses.SetupLocalPlayer@3b308104
java.lang.IllegalArgumentException: Out of bounds: (-33, -33) for region BlockArea[(-30, -30)...(30, 30)]
	at org.terasology.engine.world.generation.facets.base.BaseFacet2D.getWorldIndex(BaseFacet2D.java:41)
	at org.terasology.engine.world.generation.facets.base.BaseFieldFacet2D.getWorld(BaseFieldFacet2D.java:31)
	at org.terasology.core.world.generator.facetProviders.DensityNoiseProvider.process(DensityNoiseProvider.java:59)
	at org.terasology.engine.world.generation.ScalableFacetProvider.process(ScalableFacetProvider.java:10)
	at org.terasology.engine.world.generation.RegionImpl.getFacet(RegionImpl.java:41)
	at org.terasology.engine.logic.spawner.AbstractSpawner.findSpawnPosition(AbstractSpawner.java:46)
	at org.terasology.engine.logic.spawner.FixedSpawner.getSpawnPosition(FixedSpawner.java:36)
	at org.terasology.core.world.generator.worldGenerators.SimplexFacetedWorldGenerator.getSpawnPosition(SimplexFacetedWorldGenerator.java:51)
	at org.terasology.engine.logic.players.PlayerSystem.onConnect(PlayerSystem.java:143)
	at org.terasology.engine.logic.players.PlayerSystemMethodAccess.invoke(Unknown Source)
	at org.terasology.engine.entitySystem.event.internal.EventSystemImpl$ByteCodeEventHandlerInfo.invoke(EventSystemImpl.java:399)
	at org.terasology.engine.entitySystem.event.internal.EventSystemImpl.sendStandardEvent(EventSystemImpl.java:264)
	at org.terasology.engine.entitySystem.event.internal.EventSystemImpl.send(EventSystemImpl.java:255)
	at org.terasology.engine.core.bootstrap.eventSystem.AbstractEventSystemDecorator.send(AbstractEventSystemDecorator.java:67)
	at org.terasology.engine.network.NetworkEventSystemDecorator.send(NetworkEventSystemDecorator.java:54)
	at org.terasology.engine.core.bootstrap.eventSystem.AbstractEventSystemDecorator.send(AbstractEventSystemDecorator.java:67)
	at org.terasology.engine.recording.RecordingEventSystemDecorator.send(RecordingEventSystemDecorator.java:34)
	at org.terasology.engine.entitySystem.entity.internal.BaseEntityRef.send(BaseEntityRef.java:190)
	at org.terasology.engine.network.internal.NetworkSystemImpl.connectClient(NetworkSystemImpl.java:892)
	at org.terasology.engine.network.internal.NetworkSystemImpl.joinLocal(NetworkSystemImpl.java:325)
	at org.terasology.engine.core.modes.loadProcesses.SetupLocalPlayer.step(SetupLocalPlayer.java:29)
	at org.terasology.engine.core.modes.StateLoading.update(StateLoading.java:259)
	at org.terasology.engine.core.TerasologyEngine.tick(TerasologyEngine.java:512)
	at org.terasology.engine.core.TerasologyEngine.mainLoop(TerasologyEngine.java:472)
	at org.terasology.engine.core.TerasologyEngine.runMain(TerasologyEngine.java:448)
	at org.terasology.engine.core.TerasologyEngine.run(TerasologyEngine.java:414)
	at org.terasology.engine.Terasology.call(Terasology.java:190)
	at org.terasology.engine.Terasology.call(Terasology.java:70)
	at picocli.CommandLine.executeUserObject(CommandLine.java:1933)
	at picocli.CommandLine.access$1200(CommandLine.java:145)
	at picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2332)
	at picocli.CommandLine$RunLast.handle(CommandLine.java:2326)
	at picocli.CommandLine$RunLast.handle(CommandLine.java:2291)
	at picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2159)
	at picocli.CommandLine.execute(CommandLine.java:2058)
	at org.terasology.engine.Terasology.main(Terasology.java:139)

@Peter226 This is a sporadic we're currently facing and haven't been able to fix yet (see #5056 )
I'll close this as its a duplicate of that issue tracked in #5056

authors: Peter226 jdrueckert josephine-rueckert skaldarnar

repo: MovingBlocks/Terasology


text:
Make o.t.world.sun available for modules

Fixes #1483

Thanks, seems like a sensible tweak. Didn't fix TTA for me though :-)

source: gharchive/pull-request

authors: Cervator msteiger


text:
Strict eslint

As defined in #15
Make eslint fail build
Special note: also added more aggressive uglifyJS rules

Will test on next project, test on your own and let me know

repo: MozaikAgency/wp-theme-starter

license: mit

license_source: bigquery


text:
bug: frozen file not found

risingwave panic after a while with:
thread 'risingwave-batch-tasks' panicked at 'frozen file not found', /root/.cargo/git/checkouts/foyer-e7ae575671bf01ff/8e80c6c/foyer/src/store/read_only_file_store.rs:331:22
stack backtrace:
   0:     0x55c8c29079fc - std::backtrace_rs::backtrace::libunwind::trace::h43d94404a3e24b5e
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1:     0x55c8c29079fc - std::backtrace_rs::backtrace::trace_unsynchronized::hb80ac700c030e86a
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x55c8c29079fc - std::sys_common::backtrace::_print_fmt::h6b86e24d9aefa090
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/std/src/sys_common/backtrace.rs:65:5
   3:     0x55c8c29079fc - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h49d07dd1f79a975a
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/std/src/sys_common/backtrace.rs:44:22
   4:     0x55c8bd191e1f - core::fmt::rt::Argument::fmt::h1864a7d8f112957b
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/core/src/fmt/rt.rs:138:9
   5:     0x55c8bd191e1f - core::fmt::write::hd813644c20dd03f8
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/core/src/fmt/mod.rs:1094:21
   6:     0x55c8c2902d6f - std::io::Write::write_fmt::h6fea2a18781d1e2e
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/std/src/io/mod.rs:1712:15
   7:     0x55c8c2907805 - std::sys_common::backtrace::_print::h9d3d888fc0c72876
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/std/src/sys_common/backtrace.rs:47:5
   8:     0x55c8c2907805 - std::sys_common::backtrace::print::h04abcd5816949a30
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/std/src/sys_common/backtrace.rs:34:9
   9:     0x55c8c2908d67 - std::panicking::default_hook::{{closure}}::ha75ea1b8d759bad4
  10:     0x55c8c2908b74 - std::panicking::default_hook::he2c557a4cfe41c90
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/std/src/panicking.rs:288:9
  11:     0x55c8c228a23b - call<(&core::panic::panic_info::PanicInfo), (dyn core::ops::function::Fn<(&core::panic::panic_info::PanicInfo), Output=()> + core::marker::Send + core::marker::Sync), alloc::alloc::Global>
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/alloc/src/boxed.rs:1999:9
  12:     0x55c8c228a23b - {closure#0}
                               at /risingwave/src/utils/runtime/src/lib.rs:119:9
  13:     0x55c8c228a23b - {closure#0}<risingwave_rt::set_panic_hook::{closure_env#0}>
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/std/src/panicking.rs:234:47
  14:     0x55c8c2909384 - <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call::hcf9192dbf6344206
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/alloc/src/boxed.rs:1999:9
  15:     0x55c8c2909384 - std::panicking::rust_panic_with_hook::hb4b975f86bb49bbc
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/std/src/panicking.rs:695:13
  16:     0x55c8c2909114 - std::panicking::begin_panic_handler::{{closure}}::h381a1086a75e4820
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/std/src/panicking.rs:582:13
  17:     0x55c8c2907dd6 - std::sys_common::backtrace::__rust_end_short_backtrace::h2f950c06980ecb26
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/std/src/sys_common/backtrace.rs:151:18
  18:     0x55c8c2908eb2 - rust_begin_unwind
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/std/src/panicking.rs:578:5
  19:     0x55c8bd18eb23 - core::panicking::panic_fmt::he9fd35b0a19637c8
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/core/src/panicking.rs:67:14
  20:     0x55c8bd18e983 - core::panicking::panic_display::ha29c9cb28ca203a7
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/core/src/panicking.rs:150:5
  21:     0x55c8bd18e983 - core::panicking::panic_str::ha5696582f17c5eba
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/core/src/panicking.rs:134:5
  22:     0x55c8bd18e983 - core::option::expect_failed::h2745ad5925c1c797
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/core/src/option.rs:1932:5
  23:     0x55c8be065f7d - expect<&foyer::store::read_only_file_store::Frozen>
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/core/src/option.rs:898:21
  24:     0x55c8be065f7d - {async_block#0}<risingwave_storage::hummock::tiered_cache::SstableBlockIndex, alloc::vec::Vec<u8, alloc::alloc::Global>>
                               at /root/.cargo/git/checkouts/foyer-e7ae575671bf01ff/8e80c6c/foyer/src/store/read_only_file_store.rs:328:17
  25:     0x55c8bdf06990 - poll<alloc::boxed::Box<(dyn core::future::future::Future<Output=core::result::Result<(), foyer::store::error::Error>> + core::marker::Send), alloc::alloc::Global>>
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/core/src/future/future.rs:125:9
  26:     0x55c8bdf06990 - {async_fn#0}<risingwave_storage::hummock::tiered_cache::SstableBlockIndex, foyer::policies::tinylfu::TinyLfu<risingwave_storage::hummock::tiered_cache::SstableBlockIndex>, foyer::policies::tinylfu::Handle<risingwave_storage::hummock::tiered_cache::SstableBlockIndex>, alloc::vec::Vec<u8, alloc::alloc::Global>, foyer::store::read_only_file_store::ReadOnlyFileStore<risingwave_storage::hummock::tiered_cache::SstableBlockIndex, alloc::vec::Vec<u8, alloc::alloc::Global>>>
                               at /root/.cargo/git/checkouts/foyer-e7ae575671bf01ff/8e80c6c/foyer/src/container.rs:236:38
  27:     0x55c8bdf06990 - {async_fn#0}<risingwave_storage::hummock::tiered_cache::SstableBlockIndex, foyer::policies::tinylfu::TinyLfu<risingwave_storage::hummock::tiered_cache::SstableBlockIndex>, foyer::policies::tinylfu::Handle<risingwave_storage::hummock::tiered_cache::SstableBlockIndex>, alloc::vec::Vec<u8, alloc::alloc::Global>, foyer::store::read_only_file_store::ReadOnlyFileStore<risingwave_storage::hummock::tiered_cache::SstableBlockIndex, alloc::vec::Vec<u8, alloc::alloc::Global>>>
                               at /root/.cargo/git/checkouts/foyer-e7ae575671bf01ff/8e80c6c/foyer/src/container.rs:142:32
  28:     0x55c8bdf06990 - {async_fn#0}
                               at /risingwave/src/storage/src/hummock/tiered_cache.rs:120:18
  29:     0x55c8bdf06990 - {async_block#0}
                               at /risingwave/src/storage/src/hummock/sstable_store.rs:206:69
  30:     0x55c8bdf5cc59 - {async_block#0}<risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure_env#0}, risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure#0}::{async_block_env#0}>
                               at /risingwave/src/storage/src/hummock/block_cache.rs:205:35
  31:     0x55c8bdf5cc59 - {async_block#0}<(u64, u64), alloc::boxed::Box<risingwave_storage::hummock::sstable::block::Block, alloc::alloc::Global>, risingwave_storage::hummock::block_cache::{impl#5}::get_or_insert_with::{closure_env#0}<risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure_env#0}, risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure#0}::{async_block_env#0}>, risingwave_storage::hummock::error::HummockError, risingwave_storage::hummock::block_cache::{impl#5}::get_or_insert_with::{closure#0}::{async_block_env#0}<risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure_env#0}, risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure#0}::{async_block_env#0}>>
                               at /risingwave/src/common/src/cache.rs:967:55
  32:     0x55c8bdf5cc59 - poll<risingwave_common::cache::{impl#14}::lookup_with_request_dedup::{async_block_env#0}<(u64, u64), alloc::boxed::Box<risingwave_storage::hummock::sstable::block::Block, alloc::alloc::Global>, risingwave_storage::hummock::block_cache::{impl#5}::get_or_insert_with::{closure_env#0}<risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure_env#0}, risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure#0}::{async_block_env#0}>, risingwave_storage::hummock::error::HummockError, risingwave_storage::hummock::block_cache::{impl#5}::get_or_insert_with::{closure#0}::{async_block_env#0}<risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure_env#0}, risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure#0}::{async_block_env#0}>>>
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tracing-0.1.37/src/instrument.rs:272:9
  33:     0x55c8bdf87987 - {closure#0}<tracing::instrument::Instrumented<risingwave_common::cache::{impl#14}::lookup_with_request_dedup::{async_block_env#0}<(u64, u64), alloc::boxed::Box<risingwave_storage::hummock::sstable::block::Block, alloc::alloc::Global>, risingwave_storage::hummock::block_cache::{impl#5}::get_or_insert_with::{closure_env#0}<risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure_env#0}, risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure#0}::{async_block_env#0}>, risingwave_storage::hummock::error::HummockError, risingwave_storage::hummock::block_cache::{impl#5}::get_or_insert_with::{closure#0}::{async_block_env#0}<risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure_env#0}, risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure#0}::{async_block_env#0}>>>, alloc::sync::Arc<tokio::runtime::scheduler::current_thread::Handle>>
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.0/src/runtime/task/core.rs:223:17
  34:     0x55c8bdf87987 - with_mut<tokio::runtime::task::core::Stage<tracing::instrument::Instrumented<risingwave_common::cache::{impl#14}::lookup_with_request_dedup::{async_block_env#0}<(u64, u64), alloc::boxed::Box<risingwave_storage::hummock::sstable::block::Block, alloc::alloc::Global>, risingwave_storage::hummock::block_cache::{impl#5}::get_or_insert_with::{closure_env#0}<risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure_env#0}, risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure#0}::{async_block_env#0}>, risingwave_storage::hummock::error::HummockError, risingwave_storage::hummock::block_cache::{impl#5}::get_or_insert_with::{closure#0}::{async_block_env#0}<risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure_env#0}, risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure#0}::{async_block_env#0}>>>>, core::task::poll::Poll<core::result::Result<risingwave_common::cache::CacheableEntry<(u64, u64), alloc::boxed::Box<risingwave_storage::hummock::sstable::block::Block, alloc::alloc::Global>>, risingwave_storage::hummock::error::HummockError>>, tokio::runtime::task::core::{impl#6}::poll::{closure_env#0}<tracing::instrument::Instrumented<risingwave_common::cache::{impl#14}::lookup_with_request_dedup::{async_block_env#0}<(u64, u64), alloc::boxed::Box<risingwave_storage::hummock::sstable::block::Block, alloc::alloc::Global>, risingwave_storage::hummock::block_cache::{impl#5}::get_or_insert_with::{closure_env#0}<risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure_env#0}, risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure#0}::{async_block_env#0}>, risingwave_storage::hummock::error::HummockError, risingwave_storage::hummock::block_cache::{impl#5}::get_or_insert_with::{closure#0}::{async_block_env#0}<risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure_env#0}, risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure#0}::{async_block_env#0}>>>, alloc::sync::Arc<tokio::runtime::scheduler::current_thread::Handle>>>
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.0/src/loom/std/unsafe_cell.rs:14:9
  35:     0x55c8bdf48d74 - poll<tracing::instrument::Instrumented<risingwave_common::cache::{impl#14}::lookup_with_request_dedup::{async_block_env#0}<(u64, u64), alloc::boxed::Box<risingwave_storage::hummock::sstable::block::Block, alloc::alloc::Global>, risingwave_storage::hummock::block_cache::{impl#5}::get_or_insert_with::{closure_env#0}<risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure_env#0}, risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure#0}::{async_block_env#0}>, risingwave_storage::hummock::error::HummockError, risingwave_storage::hummock::block_cache::{impl#5}::get_or_insert_with::{closure#0}::{async_block_env#0}<risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure_env#0}, risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure#0}::{async_block_env#0}>>>, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle>>
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.0/src/runtime/task/core.rs:212:13
  36:     0x55c8be04585a - {closure#0}<tracing::instrument::Instrumented<risingwave_common::cache::{impl#14}::lookup_with_request_dedup::{async_block_env#0}<(u64, u64), alloc::boxed::Box<risingwave_storage::hummock::sstable::block::Block, alloc::alloc::Global>, risingwave_storage::hummock::block_cache::{impl#5}::get_or_insert_with::{closure_env#0}<risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure_env#0}, risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure#0}::{async_block_env#0}>, risingwave_storage::hummock::error::HummockError, risingwave_storage::hummock::block_cache::{impl#5}::get_or_insert_with::{closure#0}::{async_block_env#0}<risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure_env#0}, risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure#0}::{async_block_env#0}>>>, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle>>
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.0/src/runtime/task/harness.rs:476:19
  37:     0x55c8be04585a - call_once<core::task::poll::Poll<core::result::Result<risingwave_common::cache::CacheableEntry<(u64, u64), alloc::boxed::Box<risingwave_storage::hummock::sstable::block::Block, alloc::alloc::Global>>, risingwave_storage::hummock::error::HummockError>>, tokio::runtime::task::harness::poll_future::{closure_env#0}<tracing::instrument::Instrumented<risingwave_common::cache::{impl#14}::lookup_with_request_dedup::{async_block_env#0}<(u64, u64), alloc::boxed::Box<risingwave_storage::hummock::sstable::block::Block, alloc::alloc::Global>, risingwave_storage::hummock::block_cache::{impl#5}::get_or_insert_with::{closure_env#0}<risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure_env#0}, risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure#0}::{async_block_env#0}>, risingwave_storage::hummock::error::HummockError, risingwave_storage::hummock::block_cache::{impl#5}::get_or_insert_with::{closure#0}::{async_block_env#0}<risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure_env#0}, risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure#0}::{async_block_env#0}>>>, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle>>>
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/core/src/panic/unwind_safe.rs:271:9
  38:     0x55c8be04585a - do_call<core::panic::unwind_safe::AssertUnwindSafe<tokio::runtime::task::harness::poll_future::{closure_env#0}<tracing::instrument::Instrumented<risingwave_common::cache::{impl#14}::lookup_with_request_dedup::{async_block_env#0}<(u64, u64), alloc::boxed::Box<risingwave_storage::hummock::sstable::block::Block, alloc::alloc::Global>, risingwave_storage::hummock::block_cache::{impl#5}::get_or_insert_with::{closure_env#0}<risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure_env#0}, risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure#0}::{async_block_env#0}>, risingwave_storage::hummock::error::HummockError, risingwave_storage::hummock::block_cache::{impl#5}::get_or_insert_with::{closure#0}::{async_block_env#0}<risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure_env#0}, risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure#0}::{async_block_env#0}>>>, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle>>>, core::task::poll::Poll<core::result::Result<risingwave_common::cache::CacheableEntry<(u64, u64), alloc::boxed::Box<risingwave_storage::hummock::sstable::block::Block, alloc::alloc::Global>>, risingwave_storage::hummock::error::HummockError>>>
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/std/src/panicking.rs:485:40
  39:     0x55c8be04585a - try<core::task::poll::Poll<core::result::Result<risingwave_common::cache::CacheableEntry<(u64, u64), alloc::boxed::Box<risingwave_storage::hummock::sstable::block::Block, alloc::alloc::Global>>, risingwave_storage::hummock::error::HummockError>>, core::panic::unwind_safe::AssertUnwindSafe<tokio::runtime::task::harness::poll_future::{closure_env#0}<tracing::instrument::Instrumented<risingwave_common::cache::{impl#14}::lookup_with_request_dedup::{async_block_env#0}<(u64, u64), alloc::boxed::Box<risingwave_storage::hummock::sstable::block::Block, alloc::alloc::Global>, risingwave_storage::hummock::block_cache::{impl#5}::get_or_insert_with::{closure_env#0}<risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure_env#0}, risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure#0}::{async_block_env#0}>, risingwave_storage::hummock::error::HummockError, risingwave_storage::hummock::block_cache::{impl#5}::get_or_insert_with::{closure#0}::{async_block_env#0}<risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure_env#0}, risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure#0}::{async_block_env#0}>>>, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle>>>>
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/std/src/panicking.rs:449:19
  40:     0x55c8be04585a - catch_unwind<core::panic::unwind_safe::AssertUnwindSafe<tokio::runtime::task::harness::poll_future::{closure_env#0}<tracing::instrument::Instrumented<risingwave_common::cache::{impl#14}::lookup_with_request_dedup::{async_block_env#0}<(u64, u64), alloc::boxed::Box<risingwave_storage::hummock::sstable::block::Block, alloc::alloc::Global>, risingwave_storage::hummock::block_cache::{impl#5}::get_or_insert_with::{closure_env#0}<risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure_env#0}, risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure#0}::{async_block_env#0}>, risingwave_storage::hummock::error::HummockError, risingwave_storage::hummock::block_cache::{impl#5}::get_or_insert_with::{closure#0}::{async_block_env#0}<risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure_env#0}, risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure#0}::{async_block_env#0}>>>, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle>>>, core::task::poll::Poll<core::result::Result<risingwave_common::cache::CacheableEntry<(u64, u64), alloc::boxed::Box<risingwave_storage::hummock::sstable::block::Block, alloc::alloc::Global>>, risingwave_storage::hummock::error::HummockError>>>
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/std/src/panic.rs:142:14
  41:     0x55c8be04585a - poll_future<tracing::instrument::Instrumented<risingwave_common::cache::{impl#14}::lookup_with_request_dedup::{async_block_env#0}<(u64, u64), alloc::boxed::Box<risingwave_storage::hummock::sstable::block::Block, alloc::alloc::Global>, risingwave_storage::hummock::block_cache::{impl#5}::get_or_insert_with::{closure_env#0}<risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure_env#0}, risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure#0}::{async_block_env#0}>, risingwave_storage::hummock::error::HummockError, risingwave_storage::hummock::block_cache::{impl#5}::get_or_insert_with::{closure#0}::{async_block_env#0}<risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure_env#0}, risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure#0}::{async_block_env#0}>>>, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle>>
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.0/src/runtime/task/harness.rs:464:18
  42:     0x55c8be04585a - poll_inner<tracing::instrument::Instrumented<risingwave_common::cache::{impl#14}::lookup_with_request_dedup::{async_block_env#0}<(u64, u64), alloc::boxed::Box<risingwave_storage::hummock::sstable::block::Block, alloc::alloc::Global>, risingwave_storage::hummock::block_cache::{impl#5}::get_or_insert_with::{closure_env#0}<risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure_env#0}, risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure#0}::{async_block_env#0}>, risingwave_storage::hummock::error::HummockError, risingwave_storage::hummock::block_cache::{impl#5}::get_or_insert_with::{closure#0}::{async_block_env#0}<risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure_env#0}, risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure#0}::{async_block_env#0}>>>, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle>>
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.0/src/runtime/task/harness.rs:198:27
  43:     0x55c8be04585a - poll<tracing::instrument::Instrumented<risingwave_common::cache::{impl#14}::lookup_with_request_dedup::{async_block_env#0}<(u64, u64), alloc::boxed::Box<risingwave_storage::hummock::sstable::block::Block, alloc::alloc::Global>, risingwave_storage::hummock::block_cache::{impl#5}::get_or_insert_with::{closure_env#0}<risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure_env#0}, risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure#0}::{async_block_env#0}>, risingwave_storage::hummock::error::HummockError, risingwave_storage::hummock::block_cache::{impl#5}::get_or_insert_with::{closure#0}::{async_block_env#0}<risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure_env#0}, risingwave_storage::hummock::sstable_store::{impl#1}::get_block_response::{async_fn#0}::{closure#0}::{async_block_env#0}>>>, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle>>
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.0/src/runtime/task/harness.rs:152:15
  44:     0x55c8c29a516b - poll
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.0/src/runtime/task/raw.rs:200:18
  45:     0x55c8c29a516b - run<alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle>>
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.0/src/runtime/task/mod.rs:394:9
  46:     0x55c8c29a516b - {closure#0}
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.0/src/runtime/scheduler/multi_thread/worker.rs:464:18
  47:     0x55c8c29a516b - with_budget<core::result::Result<alloc::boxed::Box<tokio::runtime::scheduler::multi_thread::worker::Core, alloc::alloc::Global>, ()>, tokio::runtime::scheduler::multi_thread::worker::{impl#1}::run_task::{closure_env#0}>
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.0/src/runtime/coop.rs:107:5
  48:     0x55c8c29a516b - budget<core::result::Result<alloc::boxed::Box<tokio::runtime::scheduler::multi_thread::worker::Core, alloc::alloc::Global>, ()>, tokio::runtime::scheduler::multi_thread::worker::{impl#1}::run_task::{closure_env#0}>
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.0/src/runtime/coop.rs:73:5
  49:     0x55c8c29a516b - run_task
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.0/src/runtime/scheduler/multi_thread/worker.rs:463:9
  50:     0x55c8c29a47c3 - run
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.0/src/runtime/scheduler/multi_thread/worker.rs:426:24
  51:     0x55c8c2997f2d - {closure#0}
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.0/src/runtime/scheduler/multi_thread/worker.rs:406:17
  52:     0x55c8c2997f2d - set<tokio::runtime::scheduler::multi_thread::worker::Context, tokio::runtime::scheduler::multi_thread::worker::run::{closure_env#0}, ()>
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.0/src/macros/scoped_tls.rs:61:9
  53:     0x55c8c29a4238 - run
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.0/src/runtime/scheduler/multi_thread/worker.rs:403:5
  54:     0x55c8c2986dfc - {closure#0}
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.0/src/runtime/scheduler/multi_thread/worker.rs:365:45
  55:     0x55c8c2986dfc - poll<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}, ()>
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.0/src/runtime/blocking/task.rs:42:21
  56:     0x55c8c2986dfc - poll<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>>
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tracing-0.1.37/src/instrument.rs:272:9
  57:     0x55c8c298c29d - {closure#0}<tracing::instrument::Instrumented<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>>, tokio::runtime::blocking::schedule::BlockingSchedule>
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.0/src/runtime/task/core.rs:223:17
  58:     0x55c8c298c29d - with_mut<tokio::runtime::task::core::Stage<tracing::instrument::Instrumented<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>>>, core::task::poll::Poll<()>, tokio::runtime::task::core::{impl#6}::poll::{closure_env#0}<tracing::instrument::Instrumented<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>>, tokio::runtime::blocking::schedule::BlockingSchedule>>
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.0/src/loom/std/unsafe_cell.rs:14:9
  59:     0x55c8c298c29d - poll<tracing::instrument::Instrumented<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>>, tokio::runtime::blocking::schedule::BlockingSchedule>
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.0/src/runtime/task/core.rs:212:13
  60:     0x55c8c296ed2f - {closure#0}<tracing::instrument::Instrumented<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>>, tokio::runtime::blocking::schedule::BlockingSchedule>
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.0/src/runtime/task/harness.rs:476:19
  61:     0x55c8c296ed2f - call_once<core::task::poll::Poll<()>, tokio::runtime::task::harness::poll_future::{closure_env#0}<tracing::instrument::Instrumented<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>>, tokio::runtime::blocking::schedule::BlockingSchedule>>
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/core/src/panic/unwind_safe.rs:271:9
  62:     0x55c8c296ed2f - do_call<core::panic::unwind_safe::AssertUnwindSafe<tokio::runtime::task::harness::poll_future::{closure_env#0}<tracing::instrument::Instrumented<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>>, tokio::runtime::blocking::schedule::BlockingSchedule>>, core::task::poll::Poll<()>>
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/std/src/panicking.rs:485:40
  63:     0x55c8c296ed2f - try<core::task::poll::Poll<()>, core::panic::unwind_safe::AssertUnwindSafe<tokio::runtime::task::harness::poll_future::{closure_env#0}<tracing::instrument::Instrumented<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>>, tokio::runtime::blocking::schedule::BlockingSchedule>>>
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/std/src/panicking.rs:449:19
  64:     0x55c8c296ed2f - catch_unwind<core::panic::unwind_safe::AssertUnwindSafe<tokio::runtime::task::harness::poll_future::{closure_env#0}<tracing::instrument::Instrumented<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>>, tokio::runtime::blocking::schedule::BlockingSchedule>>, core::task::poll::Poll<()>>
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/std/src/panic.rs:142:14
  65:     0x55c8c296ed2f - poll_future<tracing::instrument::Instrumented<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>>, tokio::runtime::blocking::schedule::BlockingSchedule>
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.0/src/runtime/task/harness.rs:464:18
  66:     0x55c8c296ed2f - poll_inner<tracing::instrument::Instrumented<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>>, tokio::runtime::blocking::schedule::BlockingSchedule>
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.0/src/runtime/task/harness.rs:198:27
  67:     0x55c8c296ed2f - poll<tracing::instrument::Instrumented<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>>, tokio::runtime::blocking::schedule::BlockingSchedule>
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.0/src/runtime/task/harness.rs:152:15
  68:     0x55c8c296d910 - poll
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.0/src/runtime/task/raw.rs:200:18
  69:     0x55c8c296d910 - run<tokio::runtime::blocking::schedule::BlockingSchedule>
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.0/src/runtime/task/mod.rs:431:9
  70:     0x55c8c296d910 - run
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.0/src/runtime/blocking/pool.rs:159:9
  71:     0x55c8c296d910 - run
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.0/src/runtime/blocking/pool.rs:513:17
  72:     0x55c8c2995e45 - {closure#0}
                               at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.0/src/runtime/blocking/pool.rs:471:13
  73:     0x55c8c2995e45 - __rust_begin_short_backtrace<tokio::runtime::blocking::pool::{impl#6}::spawn_thread::{closure_env#0}, ()>
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/std/src/sys_common/backtrace.rs:135:18
  74:     0x55c8c297a692 - {closure#0}<tokio::runtime::blocking::pool::{impl#6}::spawn_thread::{closure_env#0}, ()>
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/std/src/thread/mod.rs:529:17
  75:     0x55c8c297a692 - call_once<(), std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<tokio::runtime::blocking::pool::{impl#6}::spawn_thread::{closure_env#0}, ()>>
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/core/src/panic/unwind_safe.rs:271:9
  76:     0x55c8c297a692 - do_call<core::panic::unwind_safe::AssertUnwindSafe<std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<tokio::runtime::blocking::pool::{impl#6}::spawn_thread::{closure_env#0}, ()>>, ()>
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/std/src/panicking.rs:485:40
  77:     0x55c8c297a692 - try<(), core::panic::unwind_safe::AssertUnwindSafe<std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<tokio::runtime::blocking::pool::{impl#6}::spawn_thread::{closure_env#0}, ()>>>
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/std/src/panicking.rs:449:19
  78:     0x55c8c297a692 - catch_unwind<core::panic::unwind_safe::AssertUnwindSafe<std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<tokio::runtime::blocking::pool::{impl#6}::spawn_thread::{closure_env#0}, ()>>, ()>
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/std/src/panic.rs:142:14
  79:     0x55c8c297a692 - {closure#1}<tokio::runtime::blocking::pool::{impl#6}::spawn_thread::{closure_env#0}, ()>
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/std/src/thread/mod.rs:528:30
  80:     0x55c8c297a692 - call_once<std::thread::{impl#0}::spawn_unchecked_::{closure_env#1}<tokio::runtime::blocking::pool::{impl#6}::spawn_thread::{closure_env#0}, ()>, ()>
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/core/src/ops/function.rs:250:5
  81:     0x55c8c290f035 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::h05bc36bea856dce6
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/alloc/src/boxed.rs:1985:9
  82:     0x55c8c290f035 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::h76ae250201c440c9
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/alloc/src/boxed.rs:1985:9
  83:     0x55c8c290f035 - std::sys::unix::thread::Thread::new::thread_start::h032990071e345e22
                               at /rustc/c373194cb6d882dc455a588bcc29c92a96b50252/library/std/src/sys/unix/thread.rs:108:17
  84:     0x7f8b5a2c3b43 - <unknown>
  85:     0x7f8b5a355a00 - <unknown>
  86:                0x0 - <unknown>

The old storage engine will be removed soon.

repo: MrCroxx/foyer


text:
Record pain strength while timer is running

It would be nice to be able to change the pain strength multiple times while a timer is running.
Currently, when I use the application I have a lot of small recordings with different levels, because the pain rarely is the same level over a long period of time.
I can imagine that this is quite a big feature request though..

Yes, I know the problem.
As you say, it would be a pretty big change.
You would still have to create a new record in the database for each change in pain strength (or even other parameters). Otherwise I would have to change the whole data structure - I don't want to do that.
Maybe you have an idea how to finish a recording and start a new one faster? This way, the data structure and the operating paradigm could be kept.

Maybe the small save button underneath the timer can still be active during recording and start a new one?

And what about the other parameters? Pain intensity is important for you at the moment. I know of another user for whom the pain region changes relatively quickly. I find it difficult to imagine a quick recording interface that covers all parameters. Especially the region. But I am open to concrete suggestions.

That's true, so it's probably best to keep the same option window, to not exclude other preferences.

So it is basically the same as if you press Stop, Save and then Start again :wink:.
I think the effort is too big to save the one click. If you are a programmer, you can try it, PR are welcome.

authors: MrReSc tversteeg

repo: MrReSc/Headi

license: MIT


text:
download with doc.save works everywhere except samsung internet browser

Thank you for submitting an issue to jsPDF. Please read carefully.
Are you using the latest version of jsPDF?
yes
Have you tried using jspdf.debug.js?
Steps to reproduce
on a samsung galaxy S6, when you click on the purple internet button
Ideally a link too. Try fork this http://jsbin.com/rilace/edit?html,js,output
What I saw
it gives message you can only download http or https urls.
So n ow i tried to use
window.open(URL.createObjectURL(blob));
it opens the url but replaces
blob:https://
with
blob:https%3A//
How can i avoid this?  So the : sign is not correct given.
What I expected

Your provided fork uses not the latest version.
the : with blob is I think the result of sanitization routines from the browser. Or else you could load binary data as payload of a trojan or hack from a remote server.
You need to find a different solution.

Duplicate of #697

authors: arasabbasi stefanaerts

repo: MrRio/jsPDF


text:
Script opening "Touch Bar Settings" instead of "Keyboard Shortcuts"

https://user-images.githubusercontent.com/37064641/229309245-79f57ebc-0a20-46ee-b5cb-9ebc5d26c942.mov
As written in the title, the script run and led to "Touch Bar Settings" make the script stopped. It seems the Settings app get updated and has different UI. It's just me or happen to everyone?  I forgot when I last update the OS but here's the current OS information:

Hello – thanks for opening the issue, and for the pull request. I was indeed wondering how people with a dynamic Touch Bar Mac got on with the script – turns out you are the first! I particularly like the use of you posting a video – I need to start doing that when I raise issues too – it makes it really clear to understand!
Pull request may work for you, but unfortunately breaks it for everybody else - I'll see if I can make the script more dynamic… I might need you to try it out when it's ready if that's okay?

Ofc, just tell me. 👍🏻

So just a General update on this as it's been quite awhile. I've looked into this thoroughly and it is impossible to actually pull the name of the buttons as Apple just doesn't float in the name or description on any of the button meta data fields. I might try and work on looking for the amount of buttons then clicking an appropriate one, but all this is an absolute nightmare in AppleScript as it's not the most forgiving language and comes with no tooling! Let me work on it further now get back to you when I can.

Closing for now as I just can't find a way to make this script dynamic to fit this situation since button names just aren't floated to AppleScript.

authors: MrSimonC fyfirman

repo: MrSimonC/Toggle-Mac-Function-Keys


text:
Add option to throw exception if configuration is not loaded

Could we add similar feature as .AddJsonFile() optional parameter does ? It should allow throwing exception if credentials/token are invalid or there are some issues connecting to vault.

Fixed. Release will be soon.

authors: MrZoidberg pseben


text:
Add MudLoggingService

Description

This PR adds a MudLoggingService that is automatically injected into all components which inherit from MudComponentBase.
It offers a simple API, accessible from the LoggingService property:

Log
Warn
Error

The service prints log, warning, and error messages to the console using JS interop, but is safe to use at any point in the Blazor render pipeline. A ConcurrentQueue is used internally to maintain log message order prior to the availability of JS interop after component render.
Alternatively, the MudLoggingService can be injected into any component and used manually.
How Has This Been Tested?

Unit test mocking JS.
Types of changes

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

Checklist:

[x] The PR is submitted to the correct branch (dev).
[x] My code follows the code style of this project.
[x] I've added relevant tests.

Can someone explain me why there is need for such service? When you can just inject a common ILogger and there exist already a provider for browser console logging WebAssemblyConsoleLoggerProvider and the WebAssemblyConsoleLogger pretty much does the same as MudLoggingService?

The goal was to support both Server and WASM deployments.

@henon I suppose we could implement ILogger instead of doing it entirely ourselves.

This is maybe worth a read.  Its MAUI but it also applies to BSS.
https://github.com/dotnet/maui/issues/6110
I kind of agree that Console.Log shouldn't really be used for Application Logging.  It doesn't seem the right place.
Not sure I agree about the trust boundaries bit.
Is this just for debug/dev  stuff?
In that case the output window of the app  would show console logging for BSS.

Can someone explain me why there is need for such service? When you can just inject a common ILogger and there exist already a provider for browser console logging WebAssemblyConsoleLoggerProvider and the WebAssemblyConsoleLogger pretty much does the same as MudLoggingService?

A valuable suggestion. Will BSS also log to the browser console?

Can someone explain me why there is need for such service? When you can just inject a common ILogger and there exist already a provider for browser console logging WebAssemblyConsoleLoggerProvider and the WebAssemblyConsoleLogger pretty much does the same as MudLoggingService?

A valuable suggestion. Will BSS also log to the browser console?

Not by default - Only using something like this PR uses
_ = JSRuntime.InvokeVoidAsync("console.log", "some js runtime log");
MS didn't write a console logging provider for BSS probably due to the discussions in the article above

In a BSS app wouldn't you want nice. persistent log files on your server though?

Is this just for debug/dev stuff?
In that case the output window of the app in your IDE would show console logging for BSS.
See: https://github.com/MudBlazor/MudBlazor/pull/5488#issuecomment-1287193560
The driving force behind this PR was to provide a method of alerting devs of an misconfigured component without crashing the entire app, which would happen if a basic throw were used. You are right that someone could view the Console.WriteLine messages directly, however.

A valuable suggestion. Will BSS also log to the browser console?
I looked over the source for WebAssemblyConsoleLoggerProvider and I believe the answer is yes, with the big caveat that it would only work when IJSRuntime is available. My implementation specifically seeks to support messages that occur prior to its availability.

In a BSS app wouldn't you want nice. persistent log files on your server though?
Generally yes, and that's what ILogger is for.

you might also want to be able receive logs w/o having to access the server. but I can see how that is probably not something MudBlazor needs to provide as a core functionality.

you might also want to be able receive logs w/o having to access the server. but I can see how that is probably not something MudBlazor needs to provide as a core functionality.

In that case, how should #5488 handle alerting devs of misconfigured T values? Console.WriteLine?

you might also want to be able receive logs w/o having to access the server. but I can see how that is probably not something MudBlazor needs to provide as a core functionality.

In that case, how should #5488 handle alerting devs of misconfigured T values? Console.WriteLine?

I don't know, via ILogger? Let's wait for this discussion to come to a conclusion, then look at our options. And to be clear, I see value in the logging service for BSS, and I don't understand the concerns there yet. Let's accumulate pros and cons and let us decide at the end how to proceed with this PR.

Debug.WriteLine?
This would execute
console.warning on WASM in debug build and be removed in release.
For BSS it would show in the debug window of the IDE and also removed in release.

@Mr-Technician I read the PR but could you. provide a brief explanation about the T and type mismatch in MudFileUpload and the problem.
That would help me a lot thks 😄

@mikes-gh Sure thing, the MudFileUpload is generic so it can support both IBrowserFile and IReadOnlyList<IBrowserFile>. A single file is IBrowserFile, and one or more is IReadOnlyList<IBrowserFile>. The error message is needed in case the dev tries to set T to any other type, as the MudFileUpload does not support this. The error could also be expanded to show an error if Multiple is true when T is IBrowserFile, for example, as multiple files won't work with IBrowserFile.

The goal was to support both Server and WASM deployments.

Oh, you want server-side too, i see. But like, is it really practical for BSS? Because browser console is only used for development, you don't use it in production, but since it's for development I don't really see the problem to open the BSS terminal and look at the output there? That's why I'm asking if it's a normal practice because I've never seen this.

a method of alerting devs of an misconfigured component without crashing the entire app, which would happen if a basic throw were used

I don't see a problem if it will be written in terminal, not browser-console. If there are some warnings that the dev should pay attention, then MS is writing in the dev terminal, and I didn't see if anyone has an issue with this appraoch.

without crashing the entire app,

If it's misconfigured in a way that the app shouldn't really work, I think Fail Fast principle should be used, this is much better than fail silently and write in log.

but I can see how that is probably not something MudBlazor needs to provide as a core functionality

This is what I think as well. This looks like an unnecessary "bloat" to me in the framework. Unless there are really good pros that indeed improve dev life.

Sure thing, the MudFileUpload is generic so it can support both IBrowserFile and IReadOnlyList. A single file is IBrowserFile, and one or more is IReadOnlyList.

I have a really stupid question, but can't it just be a IReadOnlyList<IBrowserFile> in case of single file too? Just the difference that with single file it will be always an array of single element? And if you need to change behavior/UI depending on multiple files/single file then you just have something like AllowMultipleFiles?

I have a really stupid question, but can't it just be a IReadOnlyList<IBrowserFile> in case of single file too? Just the difference that with single file it will be always an array of single element? And if you need to change behavior/UI depending on multiple files/single file then you just have something like AllowMultipleFiles?

I considered this, but it would undermine the experience of binding to a model class that expects a single file of type IBrowserFile.

Because browser console is only used for development, you don't use it in production, but since it's for development I don't really see the problem to open the BSS terminal and look at the output there?

Fair point.

I considered this, but it would undermine the experience of binding to a model class that expects a single file of type IBrowserFile.

Properties/methods(or extension?) IReadOnlyList<IBrowserFile> GetFiles and IBrowserFile? GetFile => return GetFiles.FirstOrDefault() can solve this issue. I don't think it's a bad decision, it should be intuitive taking into the account that MudFileUpload supports single and multiple files. FileDialog in the WinForm/WPF works in similar way.

@henon This should be ready for merge.

Thanks @Mr-Technician, this is really the best solution.

authors: Mr-Technician ScarletKuro henon mikes-gh

repo: MudBlazor/MudBlazor


text:
Docs: fix typo in overview page

Description

How Has This Been Tested?

Types of changes

[ ] 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)

Checklist:

[x] The PR is submitted to the correct branch (dev).
[x] My code follows the code style of this project.
[ ] I've added relevant tests.

@ingkor thanks

authors: ScarletKuro ingkor


text:
Some context menus show weird graphical glitches under mouse move.

The context menu of Committed Files and  "Author/Committer" have this problem, and other menus seem fine. Arch, KDE Plasma 6, Wayland, fractional scaling, Flatpak Gittyup v1.3.0 - Monday, 10 July 2023 - 6bf49f0
"Default" theme
Screencast_20240508_062247.webm
"Dark" theme
Screencast_20240508_062143.webm
"System" theme
Screencast_20240508_062011.webm

If you don't use fractional scaling. Is it working fine? Just for testing

authors: HubKing Murmele

repo: Murmele/Gittyup


text:
adding a file of singly linked list to the folder in c++ code

Added a c++ file containing the implementation of a singly linked list.

My first pull request from this repo in Hactoberfest.


text:
web worker

closes #601 (kind of)
I've confused the concept of ServiceWorker and SharedWorker a lot of times. What we have here is a SharedWorker... in the future this will make it easier for a ServiceWorker to connect to the one canonical instance of Mutiny, whether or not the app is open.
For now, the main win is getting all the mutiny work off the main UI thread. Everything should be more responsive (no blocking) and in some cases faster (no contention, so faster, though there is a serialization cost going across threads).
EDIT:
it's a web worker now, not a shared worker. thx chrome android
TODO:

[x] add the doc strings
[ ] test everything

in some places you do sw.function() and others you do sw?.function() what is the reasoning there?

What we have here is a SharedWorker.

this site says it doesn't work for chrome android :cry:, will need to test

What we have here is a SharedWorker.

this site says it doesn't work for chrome android 😢, will need to test
probably should add to the screen where we detect if js/wasm is enabled, that shared workers are available

THIS IS SO SAD :(. It's a one line change to make it a non-shared worker, but I might look into detecting Chrome Android specifically so we can use sharedworker other places. But that means I need to bring back all the double init defense stuff :(
I'm also having trouble with capacitor right now. It's not working iOS or Android, for what might be different reasons. One problem is this import.meta.url which doesn't seem to exist in the Capacitor environment, trying to figure it out.

Got android working...

But iOS is mad about something. Works in desktop safari...

Everywhere where you do // PAIN in the worker is where we return a wasm_bindgen type instead of a JsValue this was supposed to be nicer for you but seems like it is worse now. Maybe in mutiny-wasm we should just try to do JsValue everywhere now

yeah it sucks because the JsValue erases the type so I have to go digging to figure out what it's actually returning. do you remember why this was rejected btw? https://github.com/MutinyWallet/mutiny-node/pull/882

Wasm bindgen does the same thing, it just doesn't work for async functions yet. I think they recently merged support for it though

My mainnet tests on my android phone are great. No more flicker. Page switches are much faster now. Signet will need a full end to end test but this is really smooth. Nice work!

I don't think it's intended to be at the bottom?

authors: TonyGiorgio benthecarman futurepaul

repo: MutinyWallet/mutiny-web


text:
🛑 Client Api is down

In f291a4a, Client Api (https://client.api.transport.miaguila.com/) was down:

HTTP code: 503
Response time: 362 ms

Resolved: Client Api is back up in adff740 after 2 hours, 17 minutes.

repo: MyEagle-Transport/status


text:
Unable to Select "Journler" from Memoir Team "+" Dropdown

To Reproduce

Steps to reproduce the behavior:
ogin to the application.
Click on the "+" symbol under the Memoir Team section.
Observe the dropdown menu showing both "Dairy" and "Journler" options.
Attempt to select "Journler."
Journler" cannot be selected .
Once "Dairy" is selected, "Dairy" option disappears from the dropdown.
Only "Journler" remains in the dropdown after "Dairy" is selected.

Actual result

Journler" cannot be selected .
Once "Dairy" is selected, "Dairy" option disappears from the dropdown.
Only "Journler" remains in the dropdown after "Dairy" is selected.

Excellent! Initial build will remove this item, but captured for fix in re-release of journaler

authors: Mookse Vudum

repo: MyLife-Services/mylife-maht


text:
All test failing - Fix journey_views undefined variable issue

All tests are failing because of undefined variable in journey_views.

This should be fixed on dev already. If not, let me know and I will merge this
I see someone had fixed it in dev. will close the PR


text:
Change self.emitter.emit to self.bus.emit in the docs for MessageBus Types

https://mycroft-ai.gitbook.io/docs/mycroft-technologies/mycroft-core/message-types
Under the 'Generating Message from MycroftSkill' code tab. Change self.emitter.emit to self.bus.emit in the docs. Very confusing to try to get working..
Originally here:
https://github.com/MycroftAI/mycroft-core/issues/2611

Thanks auwsom!
I've updated the method to the new self.bus.emit and extended the examples to show what needs to be imported:
https://mycroft-ai.gitbook.io/docs/mycroft-technologies/mycroft-core/message-bus#mycroftskill-interaction

@krisgesling , thanks a ton!

authors: auwsom krisgesling

repo: MycroftAI/documentation


text:
[BUG]: CLI - Binaries (1.7.0) MainNet (1.6.3)

Steps to Reproduce Issue
Setup a mainnet environment via CLI
Run:
sui client gas 0x4a58765fdf12b0467fe68fa66d1e2b3d26bc13ed26ac00df053ddbf044b5bc09
Expected Result
Expected listing of gas objects
Actual Result
Result:
RPC call failed: ErrorObject { code: ServerError(-32000), message: "Index store not available on this Fullnode.", data: None }

Caused by:
    RPC call failed: ErrorObject { code: ServerError(-32000), message: "Index store not available on this Fullnode.", data: None }

Ok

RPC: https://fullnode.mainnet.sui.io/
request
{"jsonrpc":"2.0","id":"0","method":"suix_getDynamicFields","params":["0x49136005e90e28c4695419ed4194cc240603f1ea8eb84e62275eaff088a71063",null,null]}

response
{
    "jsonrpc": "2.0",
    "error": {
        "code": -32000,
        "message": "Index store not available on this Fullnode."
    },
    "id": "0"
}

{
    "jsonrpc": "2.0",
    "error": {
        "code": -32000,
        "message": "Index store not available on this Fullnode."
    },
    "id": 1
}

@uvd @FrankC01 Thank you both for flagging this! This was caused by a configuration error and it should be fixed now. Could you re-check?

@666lcz
Works fine for me!

My wallet

0x33b6f51abbf01665f3f30c737ad678509fbe2e95799fa64e54a960a80d0d1fbc

repo: MystenLabs/sui


text:
v1 execution layer

Description
Make a v1 execution layer.
From now on the production release will always be v_next_ while latest is the development branch. We will come up with a cadence for deploying latest, which is likely to be variable and be few weeks apart.
This should change nothing for everybody developing on the execution layer.
Hot fixes should go to v_next_ and latest otherwise development should go to _latest_ and they will be deployed at some point.
suivm is going to disappear soon and become latest.
latest will be the release to go to devnet while v_next_ will go to testnet and mainnet.
We will write a post about what is going on to keep everybody up to date.
Test Plan
Existing tests

If your changes are not user-facing and not a breaking change, you can skip the following section. Otherwise, please indicate what changed, and then add to the Release Notes section as highlighted during the release process.
Type of Change (Check all that apply)

[ ] protocol change
[ ] user-visible impact
[ ] breaking change for a client SDKs
[ ] breaking change for FNs (FN binary must upgrade)
[ ] breaking change for validators or node operators (must upgrade binaries)
[ ] breaking change for on-chain data layout
[ ] necessitate either a data wipe or data migration

Release notes

LGTM! Double confirming that as per the PR description, once this change lands, no more changes to the latest execution layer will make it to a production network. It's also worth landing this quickly so that we don't effectively rollback a change that did land.

correct, though the non determinism error is back. I suppose that static initialized that @lxfind was referring to is back in action :)
I'll find where that is and change it

@amnn could you check the latest commit and make suggestions if you see anything wrong.
That fixes the sim test but it creates some other problems (I think, we'll see the run).
Basically there were a bunch of hardcoded latest dependencies that I changes to v1

😢 sounds reasonable.  Let's meet when I'm back from the builder house to strategise on how to get this over the line?

not needed an longer

authors: amnn dariorussi


text:
trading example upgrade to new version name: TransactionBlock => Transaction, useSignTransactionBlock => useSignTransaction

Description
Describe the changes or additions included in this PR.
trading example upgrade to new version name: TransactionBlock => Transaction, useSignTransactionBlock => useSignTransaction
Test plan
How did you test the new or updated feature?

Release notes
Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required.
For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates.

[ ] Protocol:
[ ] Nodes (Validators and Full nodes):
[ ] Indexer:
[ ] JSON-RPC:
[ ] GraphQL:
[ ] CLI:
[ ] Rust SDK:

@manolisliolios @hayes-mysten I think the new TypeScript SDK did some changes so we need to update this example. If I recall correctly, this looks right, but let's get another pair of eyes here please.
Thanks!

@manolisliolios @hayes-mysten I think the new TypeScript SDK did some changes so we need to update this example. If I recall correctly and after checking the migration guide, this looks right, but let's get another pair of eyes here please.
Thanks!

Thanks for your fixes @bityoume!

authors: bityoume stefan-mysten


text:
Move the logout inside the msin header bar

💡 Description

Currently the logout button is on top of the header bar, see screenshot:

It would look nicer inside the msin header bar, on the right side, near FAQ.
'logout' would be enought, I don't think we need the username to show here. or maybe in a tooltip...

@tloubrieu-jpl is this something we really need? or is it a nice-to-have feature?

authors: jordanpadams tloubrieu-jpl

repo: NASA-PDS/doi-ui


text:
Clean YAMLS for Parameters code-sprint

Similar to https://github.com/JCSDA-internal/mpas-jedi/pull/662, some changes are needed in yaml stubs in order to avoid validation errors.
The environment is modified to enforce YAML validation and the default build is updated to 22OCT2021.
Two cycles of 3denvar-60-iter_OIE120km completed successfully, including HofX.

Two experiments (one cycle) were ran: OIE120km with 3denvar and with eda_3denvar (5 members). Results are similar to my comment on https://github.com/NCAR/MPAS-Workflow/pull/38#issuecomment-955796963
All jobs completed successfully for OIE120km 3denvar, but for OIE120km eda_3denvar VerifyModelBG2-4 jobs fail due to walltime limit.
Logs can be found at /glade/scratch/ivette/cylc-run/PR39 and /glade/scratch/ivette/pandac/PR39

repo: NCAR/MPAS-Workflow