can't work in catalina 10.15.5

Please see https://github.com/pilotmoon/Scroll-Reverser/issues/75 , it might contain useful hints

thx, it works when I enable it both in the Accessibility and Input Monitoring


When ran multiple times cron jobs get added again.

When installing performance graphs on a system for a second time the cron jobs responsible for generating the performance graphs are added again to the file /etc/cron.d/adsb-feeder-performance-graphs.

Fixed by checking for the existence of the file /etc/cron.d/adsb-feeder-performance-graphs and if it does exist it is deleted. Commit 2942298e59e894765e9702ad9b81953de57d4353.


Print source requirement file in peep_port

Will print as a comment the source requirement file path whenver it changes. This should help in splitting the files back out if they were originall split.
Also removes the different format for a single hash. I find this makes for a much more pleasing file, but could be convinced to leave it alone.

Thanks, pmac! I like the always-line-broken format better, too.


TF2 porting: category feature

Code Pull Requests
Here is the start of converting the category feature to TF2 eager execution.  More work is needed to complete.
The following have been implemented:

Setup category encoder and decoder
Adapt the category encoder to use current Ludwig Embed class
Custom softmax cross entropy loss function for training and evaluation
Custom softmax cross entropy metric function

At this point training phase completes w/o error.  As noted above only the Loss function has been implemented.
The predict phase fails because of an incomplete implementation of the predictions() method and missing metric functions.  The work to be done is  similar to what I did with the binary feature.
Since this is the first time I've implemented encoder and decoder, I'd appreciate if you would take a look at how I implemented them.
I'm attaching the training data I'm using for testing.  Included in the zip file is a log file from a test run.
ludwig_category_feature.zip
Here is the model definition I'm using
python -m ludwig.experiment --data_csv data4/train.csv \
  --skip_save_processed_input \
  --model_definition "{input_features: [{name: x1, type: numerical, preprocessing: {normalization: minmax}},
    {name: x2, type: numerical, preprocessing: {normalization: zscore}},
    {name: x3, type: numerical, preprocessing: {normalization: zscore}},
    {name: c1, type: category, embedding_size: 6}],
    combiner: {type: concat, num_fc_layers: 5, fc_size: 64},
    output_features: [{name: y, type: category}], training: {epochs: 10}}"

This commit https://github.com/uber/ludwig/pull/667/commits/cd780012b258f85eae47c4943eb3707bd9fd3b8b  added probabilities and predictions to the CategoryOutputFeature.predictions() method.  With this change the ludwig.experiment run completes w/o any noticeable errors.  This zip file contains the run log (ludwig_category_log2.txt) and contents of the directory results/experiment_run/.
ludwig_category_test_results.zip
From my perspective, I plan to do the following to finish the category feature

enable/test the sparse representation of a category feature
implement the remaining metrics
enable use of regularizers
clean-up removed commented out legacy code

Let me know if I missed anything.

re: these two comments

unpack the weighted cross entropy loss in a bunch of different losses

maybe here we can have all parameters unpacked, and pass **self.loss to the call instead of the dictionary

I understand this to mean to make the loss dictionary parameter more explicit in the function signature.
In the case of https://github.com/uber/ludwig/blob/126c1ca4df0c2f7a121cf68dadab01309f2fae43/ludwig/models/modules/loss_modules.py#L330
the loss dictionary parameter is replaced by keyword parameters class_weights=1, labels_smoothing=0.
Likewise for https://github.com/uber/ludwig/blob/126c1ca4df0c2f7a121cf68dadab01309f2fae43/ludwig/models/modules/loss_modules.py#L170
The loss dictionary parameter is replaced by keyword parameters such as sampler=null, negative_samples=0, distortion=1, etc.
Is this the correct interpretation of the guidance?

One more question re:

Maybe adding some unit tests here would be useful.

Is the focus of the 'unit test' on the loss function itself, i.e., returns corrects value or the use of the loss function in a training loop that demonstrates convergence?
I'm thinking you mean the former ('returns correct values') but I wanted to confirm.  In this case, do you have your favorite test cases that I can use to bootstrap this work?

Is this the correct interpretation of the guidance?

Yes.

Is the focus of the 'unit test' on the loss function itself, i.e.,

So, I would imagine a test to check the different loss (sampled, non sampled, weighted, non weighted) work for different parameters, Ideally providing the correct values.
The problem about using a integration test for this is that you would have to run a whole training for all different combination of parameters, which will be time consuming, while all you wanted to test is just the loss function with the different parameters combinations.
One ideally has both, but the unit one will do for now.
I don't have specific tests, but usually one thing I was doing when implementing that functionality was to have a dataset with a big output vocabulary, say 10000, and compare computation times and loss values between the regular softmax and the sampled one. Ideally the value of the loss is not too distant (although it will be different for sure, in particular at the beginning) while the speed of the sampled one would be much higher. Not sure this helps, but it's a good way to at least assess if the sampled softmax is running correctly.

I have a few question on the sampled softmax loss functions.
Re: loss[class_counts]
I see references to a parameter loss[class_counts] in couple of sections in the function sampled_softmax_cross_entropy()
https://github.com/uber/ludwig/blob/126c1ca4df0c2f7a121cf68dadab01309f2fae43/ludwig/models/modules/loss_modules.py#L174-L183
https://github.com/uber/ludwig/blob/126c1ca4df0c2f7a121cf68dadab01309f2fae43/ludwig/models/modules/loss_modules.py#L200-L209
As best I can tell, loss[class_counts] is an undocumented parameter.  I don't see it in the user guide nor do I see it in CategoryOutputFeature.populate_defaults() method.   Is this a new parameter for the loss dictionary?  If yes, what is a reasonable default value that I can use?
re: output_placeholder parameter.
I'm having difficulty understanding how to handle this parameter.  As I understand it, the parameter eventually makes its way to the parameter output_placeholder ==> output_ex ==> true_classes=ouput_exp parameter for functions such as tfnn.fixed_unigram_candidate_sampler, tf.nn.uniform_candidate_sampler, tf.nn.log_uniform_candidata_sampler and tf.nn.fixed_unigram_candidate_sampler functions.
One question I have, what is the difference between output_placeholder==>truce_classes=output_exp  and vector_labels both seem to represent the target category.
Assuming that target is an encoded integer, then I believe the shape for output_placeholder is [batch, 1].  However, the TF documentation for tf.nn.*sampler() functions imply the shape could be [batrch, num_true].  What is the implication of num_true > 1?
parameters class_weights and class_biases parameters
Are these the weight and biases used to create logits?

I have a few question on the sampled softmax loss functions.
Re: loss[class_counts]

To be hones, I implemented that part more than 2 years ago and i don't remember the details. What I belive to be true is that loss['class_counts'] should be a list of frequencies ordered by id, basically the content of the metadata idx2freq sorted by idx2str, but I don't remember why that parameter was undocumented. It's definitely a value that can be set within update_model_definition_with_metadata. because the information neededfor it comes from the metadata.

re: output_placeholder parameter.
One question I have, what is the difference between output_placeholder==>true_classes=output_exp and vector_labels both seem to represent the target category.

Yes they serve the same purpose, but some functions (specifically the erighted losses for isntance) need the labels as one_hots, others need them as integers, like the sampled softmax I believe, that's why you see them both used .

Assuming that target is an encoded integer, then I believe the shape for output_placeholder is [batch, 1]. However, the TF documentation for tf.nn.*sampler() functions say the shape is [batch, num_true]. What is the implication of num_true > 1?

For categorical, it is always one. For other types of features 9sets for instance) it may be more than one, ut for now don't worry and consider it to be 1. If you need I can provide you an explanation in general for the intuition behind sampled softmax as it seems it can be confusing, it may help you understand better what's going on with that loss.

parameters class_weights and class_biases parameters
Are these the weight and biases used to create logits?

Yes they are weiht and biases from the Classifier decoder. I'm pretty sure you can obtain them from a Dense object, something like Dense.kernel and Dense.bias or something similar.

Thank you for the clarifications.
re: loss['class_counts']
I understand that loss['class_counts'] is not user specified through the model_definition specification but can be computed and added to the loss{} dictionary.
re: class_weights and class_biases
Thank you for the pointer.  I believe these will retrieve the weights and biases, respectively, self.decoder_obj.get_weights()[0]' and self.decoder_obj.get_weights()[1]`
I'll proceed as described above.

I just noticed a potential naming conflict with the sampled softmax loss function.
Case 1: Current code invokes tf.nn.sampled_softmax_loss() https://github.com/uber/ludwig/blob/268eb7a319f31d03e9af911772891da4cd31b829/ludwig/models/modules/loss_modules.py#L213-L215
where class_weights and class_biases are

Yes they are weights and biases from the Classifier decoder. I'm pretty sure you can obtain them from a Dense object, something like Dense.kernel and Dense.bias or something similar.

Case 2: There is a second use of the name class_weights that comes for the model_definition for the loss specification, specifically (from the Ludwig user guide):

class_weights (default 1): the value can be a vector of weights, one for each class, that is multiplied to the loss of the datapoints that have that class as ground truth. It is an alternative to oversampling in case of unbalanced class distribution. The ordering of the vector follows the category to integer ID mapping in the JSON metadata file (the  class needs to be included too). Alternatively, the value can be a dictionary with class strings as keys and weights as values, like {class_a: 0.5, class_b: 0.7, ...}.

This conflict surfaced because https://github.com/uber/ludwig/pull/667#discussion_r399859339

maybe here we can have all parameters unpacked, and pass **self.loss to the call instead of the dictionary

So the elements in the model definition loss dictionary are now passed as keyword parameters, which makes class_weights in the second case now visible in the function invocation.
I'm planning to resolve this conflict by changing the names for class_weights and class_biases in Case 1 to decoder_weights and decoder_biases.  I figure this is a better change because it leaves the model definition specification unchanged.  Otherwise, change the name in Case 2 would result in a breaking change for users.
Let me know if I'm missing something.

Sounds perfect.

I'm closer to getting sampled softmax working.  The current hurdle I have to get over involves the call to tf.nn.sampled_softmax_loss() in this section of code of Ludwig's loss function sampled_softmax_cross_entropy() https://github.com/uber/ludwig/blob/268eb7a319f31d03e9af911772891da4cd31b829/ludwig/models/modules/loss_modules.py#L213-L220
The issue is in line 216.  As I understand this part, feature_hidden is the layer that is input into the category output feature's decoder method.  As best I can tell, feature_hidden is not addressable at this point when Ludwig's sampled_softmax_cross_entropy() is invoked.
In looking over the TF2 code base, I believe the required feature_hidden data structure is generated at this point in the processing https://github.com/uber/ludwig/blob/268eb7a319f31d03e9af911772891da4cd31b829/ludwig/models/ecd.py#L61-L72
I believe the required data decoder_last_hidden, which is eventually stored in the dictionary output_last_hidden[output_feature_name].  This dictionary is not returned out of this call.
I believe to complete the sampled softmax function we have to return output_last_hidden dictionary from this function.
I wanted to run this by you before making any changes.  I also noticed at least one other person has started contributing to the TF2 code base.  So if a change has to be made, I wanted to coordinate it with you to minimize generating merge conflicts.

You are right, what needs to be provided to  sampled softmax is decoder_last_hidden.
We have to figure out a clean way to do it. Maybe adding it to the predictions dictionary? Like we add logits for loss purposed, we can add decoder_last_hidden too?
Do you have other ideas?
Maybe you can give it a shot and I can comment on it, or if you prefer I can do pass.

Let me think about an approach.  I'll propose a change by tomorrow night.

This is my proposal for making decoder_last_hidden data structure visible when computing losses.  These were the design constraints that guided the approach:

Minimize changes to the existing code base
Require only the specific output feature to have knowledge on handling the decoder_last_hidden structure.

The following illustrates the approach on the numerical feature.  Although the numerical feature does not require decoder_last_hidden to calculate a loss value, I started with this because it works and was a simple case.  However, I used the debugger to confirm availability of decoder_last_hidden for loss computations.
Currently, this section of code in ecd.py
https://github.com/uber/ludwig/blob/268eb7a319f31d03e9af911772891da4cd31b829/ludwig/models/ecd.py#L61-L72
ECD.call() creates the structure
{
    'output_feature_name': decoder_logits
}

The above section changes to
        output_logits = {}
        output_last_hidden = {}
        for output_feature_name, decoder in self.output_features.items():
            decoder_logits, decoder_last_hidden = decoder(
                (combiner_outputs, output_last_hidden),
                training=training,
                mask=mask
            )
            output_logits[output_feature_name] = {}
            output_logits[output_feature_name]['logits'] = decoder_logits
            output_logits[output_feature_name]['last_hidden'] = decoder_last_hidden
            #output_last_hidden[output_feature_name] = decoder_last_hidden  #todo tf2 do we need this long-term give the above

        return output_logits

which now creates this structure
{
    'output_feature_name': {
        'logits': decoder_logits
        'last_hidden': decoder_last_hidden
    }
}

With this change the return value output_logits passes through the various levels without issue until it reaches the specific output feature's train_loss_function() and predictions() methods.
One consequence of this approach is that we won't be able to use any of the Keras standard loss classes out-of-the box.  We will have provide a simple wrapper around the Keras standard loss class.  The reason is that currently train_loss_function() sees for the parameter y_pred this structure:
decoder_logits

With the proposed change y_pred appears as this
{
    'logits': decoder_logits,
    'last_hidden': decoder_last_hidden
}

Our wrapper class extacts only the decoder_logits values to pass to the standard Keras loss classes.
To use the Keras loss class  MeanSquaredError, I added this custom wrapper class to numerical_feature.py
class MSE(tensorflow.keras.losses.MeanSquaredError):
    def __init__(self, **kwargs):
        super(MSE, self).__init__(**kwargs)

    def __call__(self, y_true, y_pred, sample_weight=None):
        logits = y_pred['logits']
        loss = super().__call__(y_true, logits, sample_weight=sample_weight)
        return loss

Using the debugger I confirmed that decoder_last_hidden is available in y_pred during __call__() method execution.
For any custom classes we write from scratch to calculate losses we would just account for the new structure coming out of ECD.call().
It is possible to use the standard Keras metric classes by modifying the output feature's predictions() method to remove decoder_last_hidden structure.  Here is how the numerical output feature's predictions() method was modified.
    def predictions(
            self,
            inputs,  # logits
    ):
        logits = inputs['logits']  #<== keep only the logits structurce, discard decoder_last_hidden
        predictions = logits

        if self.clip is not None:
            if isinstance(self.clip, (list, tuple)) and len(self.clip) == 2:
                predictions = tf.clip_by_value(
                    predictions,
                    self.clip[0],
                    self.clip[1]
                )
                logger.debug(
                    '  clipped_predictions: {0}'.format(predictions)
                )
            else:
                raise ValueError(
                    'The clip parameter of {} is {}. '
                    'It must be a list or a tuple of length 2.'.format(
                        self.feature_name,
                        self.cli
                    )
                )

        return {'predictions': predictions, 'logits': logits}

The above only required changing one line of code.
I confirmed with the above changes the numerical example full_experimeint() completes without issue.
To summarizse the changes:

Modify ECD.call() method to produce this output feature structure:

{
    'output_feature_name': {
        'logits': decoder_logits
        'last_hidden': decoder_last_hidden
    }
}

To use any standard Keras loss class we will have to provide a custom wrapper class to extract only the required values for the standard Keras loss class.

We will have to modify the the Output feature's predictions() method to use or ignore the decoder_last_hidden data structure as required.

Does this seem reasonable?
Do you want me to push this changes to the PR so you can take a closer look?

One additional data point.   I adapted the proposed approach for handling decoder_last_hidden structure to the category output feature for calculating the sampled softmax cross entropy loss.  it appears to work, in the sense it completes w/o raising an exception.

This sounds good to me, it makes sense sounds liek a really good design.
The only thing I'm considering is if it easier / better to write these wrapper losses or if it is better to make train_loss() from the base OutputFeature abstract.
In that case, every <Type>OutputFeature would implement it, and pass the right stuff (logits or last hidden) to the right loss.
One problem I see with this is that then the implementations of train_loss() will likely have many ifs, some per loss type (if sampled or if not samples for instance for the category case), so to make it easy to add a new loss one would have to create a dictionary with loss_name -> elements_needed (if needs logits, last hidden or both, or even the decoder weights and biases) which in turn would be clunky and would encode the same logic that is probably more easily encoded in your idea of wrapping the losses.
I think a good idea would be to make it work con category and push it so that I have the full picture and can also debug step by step and figure out what's the best design here.

I pushed what I had last night to give you a preview.
Current status:

Numerical feature with mean squared loss only
category feature with sampled cross entropy loss only

I'll work to finish the category feature and numerical feature to support the new structure later tonight
{
    'output_feature_name': {
        'logits': decoder_logits
        'last_hidden': decoder_last_hidden
    }
}

This commit https://github.com/uber/ludwig/pull/667/commits/cbd6955f639c6ca3e2a4b05c20a9b5c2451e1d06 has category feature "working" with both softmax and sampled softmax loss specifications.   "working" in this context says it does not raise an exception.
This should give you a complete view of the proposed solution.
Note:  Though in finishing up the support for sampled softmax loss for category output feature, the initial numerical output feature code now breaks.  I'm looking at this.

The last set of commits fixes the numeric output feature issue.  The resolution was to wrap the keras mse metric class with a ludwig specific wrapper class to extract out the require values.
Summary of what has been adapted to support the new prediction format:

Category output feature with softmax and sampled softmax loss computations
Numeric output feature with MSE loss function (only)

If the approach proposed in https://github.com/uber/ludwig/pull/667#issuecomment-608182704 is reasonable, I can do the retrofit of the

Numerical feature (retrofit for MAE loss)
Binary output feature

I'll wait to hear the verdict before continuing the work.

Ok I checked everything. Approve of this design :) Great job!
There are still some cleanup needed in some function, but you put already the todos there, so that's fine.
Also eventually I would want to clean up the losses in general, but that's on me to do after we get everything to work first.
One minor thing, 'type', 'logits' and 'final_hidden' now can definitely become constants.
Also, have you tested all the samplers? That would be useful to give confidence in the solidity of the implementation (again here a unit test may help).
You can move on and adapt this to binary and numerical.
Once that is done, we can look at the encoding side, to see if there's a way to use TF2 Embedding layer or to transform Ludwig's embedding mechanism in a TF2 Layer (would be useful for serialization and deserialization purposes), and we should test the loading and assignment of  pre-trained embeddings carefully.

Thank you.  I understand my next steps are

Convert 'type', 'logits' and 'last_hidden' to be Ludwig constants in constants.pyand propagate these through the new work.
Retrofit numerical and binary features to support the new prediction dictionary format
test out the other samplers in the sampled softmax loss computations.

oops...just a point of clarification, I may have had a typo in my earlier response.
What I've been using as 'last_hidden' you want to rename to be 'final_hidden'.

Question on coding convention on use of Ludwig/constants.py.  Some modules use from ludwig.constants import * other modules use from ludwig.contants import *. Right now I'm adhering to the convention I find in the specific module.
Is there preference which form to use?

What I've been using as 'last_hidden' you want to rename to be 'final_hidden'.

LAST_HIDDEN is fine.

Is there preference which form to use?

tl;dr do as you please
Since the beginning I've been using * in the import from constants because otherwise everytime i introduce a new one one would also have to change the imports. DeppSource complains about it so in some cases when adding new code I ended up importing the constant itself without *, bu haven't been consistent in removing * everywhere and adding the specific ones. I'll probably do it eventually, but so fat I always found a btter way to spend my Ludwig time :)

Status update:

constants.py updated to include LOGITS, TYPE and FINAL_HIDDEN.  Retrofitted these new constants in the code base.
completed updating numerical and binary features to support new predictions format

Re: test other samplers While I was working on this, I noticed there was no existing unit for simple features, e.g. numerical, binary, category features.  So I decided to add a new test harness test_simple_features.py based on test_experiment.py.
test_simple_features.py creates a simple model with one input feature to test the encoder, one output feature to test the decoder and provides an optional method to specify loss parameters. This capability was implemented using pytests decorator pytest.mark.parameterize
@pytest.mark.parametrize(
    'input_test_feature, output_test_feature, output_loss_parameter',

input_test_feature: specifies Ludwig's data generator function for the input feature, e.g., numerical_feature()
outout_test_feature: specifies Ludwig's data generator function for the output feature, e.g., numerical_feature()
output_loss_parameter: Is either None or the output feature's loss parameter

Example usage:
@pytest.mark.parametrize(
    'input_test_feature, output_test_feature, output_loss_parameter',
    [
        # numerical features
        (numerical_feature(), numerical_feature(), None),
        (
            numerical_feature(normalization='minmax'),
            numerical_feature(),
            {'loss': {'type':'mean_squared_error'}}
         ),

The above example specifies two test runs

First one specifies a model with numerical input feature with no pre-processing, numerical output feature and default loss specification
Second test run specifies a model with numerical input feature with minmax normalization, numerical output feature with mean_squared_error loss specification

In the case of the categorical feature, here are the test cases for each sampler.
        # Categorical feature
        (category_feature(), category_feature(), None),
        (
            category_feature(),
            category_feature(),
            {'loss': {'type':'softmax_cross_entropy'}}
        ),
        (
            category_feature(),
            category_feature(),
            {'loss': {
                        'type': 'sampled_softmax_cross_entropy',
                        'sampler': 'fixed_unigram',
                        'negative_samples': 10
                      }
            }
        ),
        (
            category_feature(),
            category_feature(),
            {'loss': {
                        'type': 'sampled_softmax_cross_entropy',
                        'sampler': 'uniform',
                        'negative_samples': 10
                    }
            }
        ),
        (
            category_feature(),
            category_feature(),
            {'loss': {
                        'type': 'sampled_softmax_cross_entropy',
                        'sampler': 'log_uniform',
                        'negative_samples': 10
                    }
            }
        ),
        (
            category_feature(),
            category_feature(),
            {'loss': {
                        'type': 'sampled_softmax_cross_entropy',
                        'sampler': 'learned_unigram',
                        'negative_samples': 10
                    }
            }
        )

Here is the pytest log for the tests/integration_tests/test_simple_features.py
root@a28f4a25cc7b:/opt/project# pytest tests/integration_tests/test_simple_features.py
=========================================================== test session starts ============================================================
platform linux -- Python 3.6.9, pytest-5.4.1, py-1.8.1, pluggy-0.13.1
rootdir: /opt/project
plugins: typeguard-2.7.1
collected 10 items

tests/integration_tests/test_simple_features.py ..........                                                                           [100%]

============================================================= warnings summary =============================================================
/usr/local/lib/python3.6/dist-packages/tensorflow_core/python/pywrap_tensorflow_internal.py:15
  /usr/local/lib/python3.6/dist-packages/tensorflow_core/python/pywrap_tensorflow_internal.py:15: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
    import imp

tests/integration_tests/test_simple_features.py::test_feature[input_test_feature3-output_test_feature3-None]
tests/integration_tests/test_simple_features.py::test_feature[input_test_feature4-output_test_feature4-None]
tests/integration_tests/test_simple_features.py::test_feature[input_test_feature5-output_test_feature5-output_loss_parameter5]
tests/integration_tests/test_simple_features.py::test_feature[input_test_feature6-output_test_feature6-output_loss_parameter6]
tests/integration_tests/test_simple_features.py::test_feature[input_test_feature7-output_test_feature7-output_loss_parameter7]
tests/integration_tests/test_simple_features.py::test_feature[input_test_feature8-output_test_feature8-output_loss_parameter8]
tests/integration_tests/test_simple_features.py::test_feature[input_test_feature9-output_test_feature9-output_loss_parameter9]
  /usr/local/lib/python3.6/dist-packages/sklearn/metrics/_classification.py:1272: UndefinedMetricWarning: Precision is ill-defined and being set to 0.0 in labels with no predicted samples. Use `zero_division` parameter to control this behavior.
    _warn_prf(average, modifier, msg_start, len(result))

-- Docs: https://docs.pytest.org/en/latest/warnings.html
===================================================== 10 passed, 8 warnings in 13.84s ======================================================
root@a28f4a25cc7b:/opt/project#

re: the category features sampler tests.  These tests shows the code runs to completion without issue.  I still have to look at how to test if the correct values are computed.
What do you think?

This all sounds great, thank you! Adding @msaisumanth to the discussion here as he was the one who implemented most of the tests to give an opinion ad suggestions, but it all looks good to me.

Sounds good.  I'll hold off on pushing any other changes to this PR until I hear back.
In the meantime, I can work offline on more robust testing of the category feature and sampled softmax testing.  re: your suggestion

I don't have specific tests, but usually one thing I was doing when implementing that functionality was to have a dataset with a big output vocabulary, say 10000, and compare computation times and loss values between the regular softmax and the sampled one. Ideally the value of the loss is not too distant (although it will be different for sure, in particular at the beginning) while the speed of the sampled one would be much higher. Not sure this helps, but it's a good way to at least assess if the sampled softmax is running correctly.

I understand the overall procedure to be:

generate a category output feature with a large vocabulary using Ludwig's data generation function, e.g., category_feature(vocab_size=10000).
Do two training runs.  One run with loss specified as softmax_cross_entropy and the second run with loss of sampled_softmax_cross_entropy.
compare the losses between the two runs.   The losses should be "close" and the run time of the sampled_softmax_cross_entropy should be faster.

Some questions on details:

If the output feature vocabulary size is 10,000, what size training data set should I create?  Do I need a size at least as large as the vocabulary size?
When I compare losses, what granularity of the loss?  Some examples I thought could be the basis of comparison:

loss per batch
mean loss per epoch overall all the batches in that epoch
loss as reported by the evaluation on the training dataset, or validation data set or test data set.

Given the above choices, I'm thinking the comparison should be the first one, loss per batch because that loss will drive calculating the gradients.
    @tf.function
    def train_step(self, model, optimizer, inputs, targets):
        with tf.GradientTape() as tape:
            logits = model(inputs, training=True)
            loss, _ = model.train_loss(targets, logits)
        gradients = tape.gradient(loss, model.trainable_variables)
        optimizer.apply_gradients(zip(gradients, model.trainable_variables))

        print('Training loss (for one batch): %s' % float(loss))

for the sampled_softmax_cross_entropy any recommended settings for the parameters associated with sampled softmax?
For purposes of this testing, I think a small number of epochs should be sufficient.  Do I need anything more than 2 or 3 epochs?

While working on the sampled softmax testing, I noticed that the values stored in <feature_name>_proabilities.csv is written as tensors, e.g.,
"tf.Tensor(0.0917323, shape=(), dtype=float32)","tf.Tensor(0.09546962, shape=(), dtype=float32)","tf.Tensor(0.09563452, shape=(), dtype=float32)","tf.Tensor(0.09365028, shape=(), dtype=float32)","tf.Tensor(0.0859547, shape=(), dtype=float32)","tf.Tensor(0.0921639, shape=(), dtype=float32)","tf.Tensor(0.090296395, shape=(), dtype=float32)","tf.Tensor(0.092099555, shape=(), dtype=float32)","tf.Tensor(0.083821714, shape=(), dtype=float32)","tf.Tensor(0.08591533, shape=(), dtype=float32)","tf.Tensor(0.09326165, shape=(), dtype=float32)"
"tf.Tensor(0.09311067, shape=(), dtype=float32)","tf.Tensor(0.10002747, shape=(), dtype=float32)","tf.Tensor(0.09493849, shape=(), dtype=float32)","tf.Tensor(0.094783254, shape=(), dtype=float32)","tf.Tensor(0.08606884, shape=(), dtype=float32)","tf.Tensor(0.08756173, shape=(), dtype=float32)","tf.Tensor(0.0891696, shape=(), dtype=float32)","tf.Tensor(0.091503404, shape=(), dtype=float32)","tf.Tensor(0.08338976, shape=(), dtype=float32)","tf.Tensor(0.08853781, shape=(), dtype=float32)","tf.Tensor(0.09090898, shape=(), dtype=float32)"
"tf.Tensor(0.09113735, shape=(), dtype=float32)","tf.Tensor(0.09825466, shape=(), dtype=float32)","tf.Tensor(0.09695278, shape=(), dtype=float32)","tf.Tensor(0.098814435, shape=(), dtype=float32)","tf.Tensor(0.079404235, shape=(), dtype=float32)","tf.Tensor(0.09384818, shape=(), dtype=float32)","tf.Tensor(0.08696946, shape=(), dtype=float32)","tf.Tensor(0.09264682, shape=(), dtype=float32)","tf.Tensor(0.080888115, shape=(), dtype=float32)","tf.Tensor(0.08343119, shape=(), dtype=float32)","tf.Tensor(0.09765276, shape=(), dtype=float32)"
"tf.Tensor(0.0917323, shape=(), dtype=float32)","tf.Tensor(0.09546962, shape=(), dtype=float32)","tf.Tensor(0.09563452, shape=(), dtype=float32)","tf.Tensor(0.09365028, shape=(), dtype=float32)","tf.Tensor(0.0859547, shape=(), dtype=float32)","tf.Tensor(0.0921639, shape=(), dtype=float32)","tf.Tensor(0.090296395, shape=(), dtype=float32)","tf.Tensor(0.092099555, shape=(), dtype=float32)","tf.Tensor(0.083821714, shape=(), dtype=float32)","tf.Tensor(0.08591533, shape=(), dtype=float32)","tf.Tensor(0.09326165, shape=(), dtype=float32)"

This commit https://github.com/uber/ludwig/pull/667/commits/73ef88451b8dc0700c85cc20f9daade360c6bcaf fixes the above issue.  Format of data written to <feature_name>_probabilities.csv now appears as this
0.092731796,0.100902446,0.09528344,0.098668285,0.08902399,0.09348325,0.08973809,0.08907923,0.08383052,0.08188916,0.08536975
0.0918586,0.09546873,0.09540367,0.09558848,0.08542835,0.097054325,0.09082846,0.09085872,0.08415315,0.08341262,0.08994486
0.08857817,0.09729856,0.09666546,0.09640322,0.08355103,0.098109104,0.091066405,0.086696416,0.08678802,0.08358456,0.09125907
0.08857817,0.09729856,0.09666546,0.09640322,0.08355103,0.098109104,0.091066405,0.086696416,0.08678802,0.08358456,0.09125907

Some questions on details:
* If the output feature vocabulary size is 10,000, what size training data set should I create?  Do I need a size at least as large as the vocabulary size?

* When I compare losses, what granularity of the loss?  Some examples I thought could be the basis of comparison:

  * loss per batch
  * mean loss per epoch overall all the batches in that epoch
  * loss as reported by the evaluation on the training dataset, or validation data set or test data set.

* for the `sampled_softmax_cross_entropy` any recommended settings for the parameters associated with sampled softmax?

* For purposes of this testing, I think a small number of epochs should be sufficient.  Do I need anything more than 2 or 3 epochs?

A general consideration that probably answers all the questions: the reasons why I didn't add a test like this before in the suite of tests is because this will be really slow compared to most other tests. As you noticed, having 10000 categories means that the datapoints have, at lease, to be 10000 and if you turn on stratified sampling in the synthesizer you'll get 1 sample per class, which is not great for comparing loss values, you are are probably better of with a greater number, say 100000. Now, generating data and training a model on 100000 datapoints may take minutes and it could be too expensive to run a regular CI task. Moreover, as you noticed, the idea of similar loss or potential similar accuracy is very fuzzy, the range of what is acceptable may vary depending on the number of categories and number of negative samples (in theory with 10000 categories and 9999 negative samples the losses should be identical for instance), so it's really difficult to give you a precise epsilon that is always acceptable and also a precise set of parameters. Also the number of epochs, may vary depending on data size and number of classes. This is another reason why I didn't want to include it in my suite of test and just use it as a sanity check.
Given this, I don't know if there's a mechanism in pytest to add a test case and tag it so that it is ignore, but it is still there for people to run it manually, that would be definitely useful.
A possible alternative is to use a dataset with relatively wide set of classes and see what the performance of samples vs non sampled in terms of loss and accuracy trends are.This will not allow to test the speed aspect (as with, say ,20 classes, the speed advantage of the sampled softmax will nto show up), but will give us confidence that overall the mechanism works. A possible example dataset for this could be ATIS intent classification task, but it would require us to have Sequence encoders already ported to TF2.

Thank you for the response.
I have a related question.  When running with sampled_softmax I see many occurrences of this message during training, probably once per batch.  These messages show up regardless of sampler specified.
WARNING:tensorflow:Gradients do not exist for variables ['ecd/category_output_feature_1/classifier/dense_2/kernel:0', 'ecd/category_output_feature_1/classifier/dense_2/bias:0'] when minimizing the loss.

Have you seen this message before?
I've done a search on 'gradients do not exist for variables`.  I found a few references in the Stack Overflow and Tensorflow's GitHub issue.  Based on my understanding, none seemed to point to a solution.
I've tried different settings for vocab_size, number of observations, number and size of fully connected layers.  The warning message always appear.

No I've never seen it, it could be a new TF2 thing. It partially makes sense, as only parts of those variables should receive gradients using sampled softmax (only the rows corresponding to the positive label and the negative sampled ones at each batch), but if they don't receive gradients at all, that's problematic.

@jimthompson5802 The tests look great! Thanks a lot

So I'm merging this.
I guess there are still a couple things to figure out:

TF2ization of the embedding encoder
figure out the weird error with sampled losses
We could open two separate PRs for those

Thank you for the merge.  Which one would you like me to focus on next?  And how do you want to keep track of the other one so it does not fall through the crack?

We can use this column: https://github.com/uber/ludwig/projects/1#column-8037588 to keep track, i will update it with the 2 items we discussed.
I believe the TF2ization will be fundamental when we reintroduce the model saving functionalities, and I believe we would have to find new solutions to pre-trained embeddings load, but at the same time I believe there is a bigger and more fundamental thing to do, which is tackling sequence features. if we tackle them, then text, timeseries and audio fall into place easily, while the remaining features are pretty straightforward. So, if you are ok with it, let's work on the sequence features first..

re:

So, if you are ok with it, let's work on the sequence features first..

I understand you'd like me to work on the sequence feature next. Similar to the work I did for the Binary and Category features.    I'll get started and submit a new PR for this work

Yes. Consider that the sequence feature is the most complex one to tackle because it has the greater number of different encoders, and because it has two decoders, the tagger should be easy, but the you already had a taster of the generator decoder :) But this time it will be easier because there won't be any mix of TF1 and TF2, it will be pure TF2, which will make things much easier.
I would start from the sequence input feature anyway, as that one is more straightforward than the output feature.

An additional note: @ydudin3 ported the image input feature to TF2 using TF layers (resnet is still WIP). I did an additional pass on both conv and fc layers to expose almost all their parameters all the way up the stack. The work done on Stacked2DCNN that you can see in the commits is a good blueprint on how to do the same kind of work for both Embed encoder for category features and all the encoders for the sequence features.

Thank you for the pointer to Stacked2DCNN.  I'll look at its implementation.


chore: refresh helm chart README; fix broken...

What does this PR do?
chore: refresh helm chart README; fix broken blog links - RHIDP-976
Signed-off-by: rhdh-bot service account<EMAIL_ADDRESS>Screenshot/screencast of this PR
N/A
What issues does this PR fix or reference?
N/A (or see commit message above for issue number)
How to test this PR?
N/A
PR Checklist
As the author of this Pull Request I made sure that:

[x] The Eclipse Contributor Agreement is valid
[x] Code produced is complete
[x] Code builds without errors
[ ] Tests are covering the bugfix
[x] The repository devfile is up to date and works, if one exists
[x] Sections What issues does this PR fix or reference and How to test this PR completed
[x] Relevant user documentation updated
[x] Relevant contributing documentation updated
[x] CI/CD changes implemented, documented and communicated

Reviewers
Reviewers, please comment how you tested the PR when approving it.

yarn prettier:fix also needs to be run

/lgtm

/lgtm

/override "PR Docker Build"


Stage

New branch "Stage" for all changes.

Please do not forget that the ,,issues" channel is only meant for issues.


Polygon2D UV should be defined in 0-1 space instead of texture-size space

I am confused little bit. Everytime/everywhere I work with UV it never depends on texture size and vary from 0 to 1. But not with Polygon2D. Why should I define Polygon2D UVs based on texture size? It is not universal. Each time I change polygon texture, I should take into account texture size.

I also find this very unintuitive. Besides, now when you attach a shader to the Polygon2D its UV property will change each time you assign a texture with different dimensions.

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.
The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.
If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!


change curve25519-n to curve25519-n2 to support Windows

curve25519-n isn't building on Windows 10. curve25519-n2 includes code to handle building on Windows 10. There are no other changes.

Is this a public package? I can't find curve25519-n2 in npmjs.com

Yes, I just published it so that's probably why you can't find it in the search.
Linked here: https://www.npmjs.com/package/curve25519-n2

Looks good.


Hackebrot convert test cookiecutter local with input

Convert test_main.TestCookiecutterLocalWithInput using monkeypatch of py.test.
According to the name of the original name and the doc string of test_cookiecutter_input_extra_context the no_input argument needs to be False, so I changed the former version.
Please let me know if this is correct.

@hackebrot I want to merge this in for the 1.0 release this weekend (#410) but the file has evolved a bit. Would you be up to rebasing and resubmitting?
(If not I completely understand)

@pydanny @michaeljoseph :bell:


Symfony install error

Symfony last official version skeleton by composer.
when I run the package installation
composer require kafkiansky/symfony-middleware

I get the error below
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - kafkiansky/symfony-middleware[0.1.0, ..., 0.2.1] require symfony/dependency-injection ^5.3 -> found symfony/dependency-injection[v5.3.0, ..., v5.4.33] but the package is fixed to v7.0.1 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
    - kafkiansky/symfony-middleware 0.3.0 requires symfony/dependency-injection ^6.0 -> found symfony/dependency-injection[v6.0.0, ..., v6.4.1] but the package is fixed to v7.0.1 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
    - kafkiansky/symfony-middleware 0.4.0 requires symfony/dependency-injection ^6.2 -> found symfony/dependency-injection[v6.2.0, ..., v6.4.1] but the package is fixed to v7.0.1 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
    - Root composer.json requires kafkiansky/symfony-middleware * -> satisfiable by kafkiansky/symfony-middleware[0.1.0, ..., 0.4.0].

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.
You can also try re-running composer require with an explicit version constraint, e.g. "composer require kafkiansky/symfony-middleware:*" to figure out if any version is installable, or "composer require kafkiansky/symfony-middleware:^2.1" if you know which you need.

Installation failed, reverting ./composer.json and ./composer.lock to their original content.

hello, @italodeveloper. thank you for the report. I fixed it, install version 1.0.0.


⚠ GLDDNS Server (ns2.glddns.com) has degraded performance

In dcd260c, GLDDNS Server (ns2.glddns.com) (ns2.glddns.com) experienced degraded performance:

HTTP code: 200
Response time: 696 ms

Resolved: GLDDNS Server (ns2.glddns.com) performance has improved in 95abcb6 after 6 minutes.


Format slack messages and shit

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.0 out of 2 committers have signed the CLA.:x: chrislu1207:x: tfshocknesschrislu1207 seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

oops


Strange behaviour if multiple coral dialogs are present in mark-up

The generic multifield dialog handler restores the previous dialogs by using the CSS selector coral-dialog coral-dialog-content. The problem arises as soon as multiple dialogs match this selector. That's why the selector has to be changed to select only the dialog which is active (has class is-open).

Fixed with commit 0f49bbf2c7988419786b862beabbeb28b0122fe8


xds: Set status code to INVALID_ARGUMENT when NACKing.

The Bazel RBE TSAN failure is an infrastructure failure.
The sanity check failure is a transient error fetching an external dependency.
Known issues: #24537 #23103 #24538


Have a test to run against https://github.com/ruby/spec

Whilst I appreciate you do not target full language compliance / spec, having some awareness of where it deviates would be good.
There may be some language edge-cases which have been dealt with in ruby that might be good to be aware of and tested against.

Thanks! We will run these specs before first release 😁


[Menu] Remove overflow style in MenuItem

[ x] I have followed (at least) the PR section of the contributing guide.
Fix #21639

@tj3407 It's a great first pull request on Material-UI 👌🏻. Thank you for working on it!


SP633E color issues

Hello,
I went through some issues that were already closed but didn't come across any like this one, although I see similar issues were fixed...
Version of the custom_component
UniLed 2.2.5
YAML
automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
bluetooth:
logger:

I got DIGITUS DN-30210-1 BT adapter and as soon as I pugged it in my SFF detected it and I was able to use it without any issues.

I integrated HA UniLED v2.2.5 - The Universal Light Controller as I have 6 or 7 cheap LED strip controllers, models are SP633E and application that drives them is BanlanX.

Per UniLed description, this is a supported adapter but for some reason, I can only toggle it on/off and change mode from static to dynamic. I really want to be able to control light colors. Have in mind that via BanlanX, I am able to do so much fun stuff, but for HA I am only seeking option to change color of the light..

Please help! I don't want to throw away few of the controllers I have.. If we can resolve it, I would gladly buy you a coffee as I am doing this for a restaurant.

I am not that tech savvy and I am willing to send any info you need!

Thanks in advance,
Mike

I need some log details to see what is going on asi cannot replicate as I don't have a physical device

Apologies Monty, as I said I am not tech savvy... I found this log under my Settings > Sys > Logs > SP633...
Let me know if this is the correct log. Thank you in advance for helping out, owners are still pushing me to complete this asap.. I will deff award you for landing me a hand...
home-assistant_2024-11-10T21-23-43.832Z.log

Thanks, log is fine will look into resolving shortly

Hello kind sir, I see you closed the case, but nothing changed on my end.. I restarted HA instance and tried re-installed uniled.. However, all options are still the same. Do I need to get new adapters after all? Thank you for your dedication and replies.

Apologies, looks like color settings are added and working properly! Please send me your patreon or paypal!!

No worries and welcome, you can buy me a coffee from the link below if you'd like.
https://buymeacoffee.com/monty68


How to use as a subclass ?

Context
(Still learning Vue.js.  Newbie question ahead. ☻ )
I have a custom Component.
I want to make my custom Component draggable, so I’ve been trying to use vue-drag-resize as a base Component.
  I have an extremely basic custom Component, and I just want it to subclass VueDragResize so I can make instances of my Component draggable.
Questions

What is the difference between Vue.extend( … ) and Vue.component('name', { extends: «Another Component», … })?

If I need to pass anything to VueDragResize, where do I do that?

Default values for props?
Returned values in data: function() {…}?
Using v-bind directives?

Basic working version can be found here
Show your code. You can post it here or use codesandbox with prepared DEMO which I linked above.


Sync benchmark folder from main

Description
The benchmark folder in 2.x branch is drifted a lot from main branch. Replaced the entire benchmark folder with the one from main branch
Issues Resolved
N/A
Check List

[X] New functionality includes testing.

[X] All tests pass

[X] New functionality has been documented.

[X] New functionality has javadoc added

[X] Commits are signed as per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

How did you test that there are no missing pieces, can you please share results here?

I just removed the folder from 2.x branch and copied the entire folder from main.

How did you test that there are no missing pieces, can you please share results here?

I just removed the folder from 2.x branch and copied the entire folder from main. I don't think there is any different between main and 2.x for benchmark test code. Therefore, if it works for main, it should work for 2.x

I see, we can probably fix errors if any when that is executed for a benchmark of some feature or for next release, I think that's fine.

How did you test that there are no missing pieces, can you please share results here?

I just removed the folder from 2.x branch and copied the entire folder from main. I don't think there is any different between main and 2.x for benchmark test code. Therefore, if it works for main, it should work for 2.x

I see, we can probably fix errors if any when that is executed for a benchmark of some feature or for next release, I think that's fine.

Actually, we only use benchmark tool from main branch. That is why people forget to backport benchmark related PR to 2.x.


Tolerate missing role in user creation

The changes you made were very helpful for me to better understand the code base, but didn't exactly solve the problem. As the role value (even when Nothing) was still being pushed to the database through the prepared statement. This pull request fixes this and adds a test case.
If the code style/quality needs improvement, let me know :relaxed:
This fixes #290

That's actually something I was wondering. If there is no default role in the database and the user doesn't give one, do we get an error message ?

It depends on how the user's database is configured.
On Sat, Sep 26, 2015 at 7:05 AM Pi3r<EMAIL_ADDRESS>wrote:

That's actually something I was wondering. If there is no default role in
the database and the user doesn't give one, do we get an error message ?
—
Reply to this email directly or view it on GitHub
https://github.com/begriffs/postgrest/pull/291#issuecomment-143421406.

@calebmer does the testing situation worry you or do you think this is good to merge?

Yes, it does worry me. Sadly I have not had the time to take a closer look
and I will not have that time for at least another week 😐
My specific issue was fixed, but another one appeared. It would seem like
the trigger placed on the postgrest.auth table is not firing. Is this a
result of the testing environment?
On Sun, Sep 27, 2015 at 2:01 AM Joe Nelson<EMAIL_ADDRESS>wrote:

@calebmer https://github.com/calebmer does the testing situation worry
you or do you think this is good to merge?
—
Reply to this email directly or view it on GitHub
https://github.com/begriffs/postgrest/pull/291#issuecomment-143522772.

I know it has nothing to do with this specific PR so sorry for the digression  but I was wondering if the use of unsafePerformIO was completely safe ? IO is explicitly forbidden in H.Tx. How do we know it is safe in  this case ?

@PierreR I'm no expert in the Hasql codebase but I believe that transactions are retried only upon serialization failure, not just any failure. In this case we are safe since PostgREST never uses serializable transactions but read committed instead.

Sorry for taking so long, I have not had a whole lot of time recently and it took a while to get used to a Haskell dev environment, but concerns addressing weird test behaviors have been addressed.

Looks good! How about adding a line to the changelog and then squashing all this into a single commit?

Ok, added a changelog line, and please do correct me if I'm wrong, but I believe squashage is done on your end? (git merge --squash)

Hm, it's still showing 9 commits. Maybe you squashed the most recent two only. Try doing a a git rebase -i cfbb157 and changing the p (for pick) into s (for squash) on all but the topmost commit. Afterwards you'll have to do a force push to this branch again because the history will have diverged.


Handle colon following create issue triggers

I think this format is pretty common:

Version: 1.43.0-insider (user setup)
Commit: 89cafb24e5d75a0c8d561a6cdd95e93b5679e152
Date: 2020-02-25T05:29:49.719Z
Electron: 7.1.11
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Windows_NT x64 10.0.19041
Ext: 2020.2.29762

Ran into this as well. Maybe it should match whitespace + todo + .*. I usually format my todos like // todo(connor4312): something so people know who to call if the blame gets obfuscated.

@connor4312 suggest that you also consider using todo@connor4312. It is one character less and the PR extension also offers completions when entering @.

It now does the insert in the first whitespace after the "todo" (or whatever your "todo" is). It does the same for the suggested issue title too.


Ability to set update policy

It'd be nice to have a task where we can set update policies for ostree, flatpak, etc.

The ostree component is partially resolved w/ a recent commit. I included an os_updates role where people can configure general preferences around updates. I want to include the systemd-timer component there, too.
Will need to work out the flatpak update policy. I'm sure I can figure it out, but I'm not sure where it's tracked offhand.


Javascript/JSON rainbow bracket matching not working?

Simple question, should it ?  looking at the DOM these files don't seem to have the cm-bracket classes applied to their markup.  How would I go about making this happen, or is this a fundamental restriction of the CodeMirror javascript mode ?

Hi. Your first sentence is a little hard to understand. Could you provide a specific example of what doesn't have cm-bracket classes and give us more info about your environment?

Sorry about that. using version 0.8.1 of lighttable for windows, with Rainbow 0.0.8 (default theme).   If I'm editing a javascript file or a json file (.js/.json) I expected the rainbow brackets plugin to 'work', that is to display the variously nested depth brackets in matching colours.
It does not appear to do this.  Looking at the DOM for the code-mirror editor instance it looks to me as though the code-mirror mode does not tokenise/expose the brackets to allow the highlighter to function.  Is this correct/expected behaviour?

When testing against a .js or .json file, there is indeed no delightful rainbow of syntax occurring.
A quick look at the README.md for https://github.com/LightTable/Rainbow suggests the plugin's current functionality is limited to CLJS.
As this issue pertains to the plugin, I am closing this issue and opening https://github.com/LightTable/Rainbow/issues/4


Upgrade to SCDF 1.0.0.RELASE SCDF APPS 1.0.2 RELEASE, Geode 1.0.0.M3 .....

updated SCDF + apps to the latest stable releases (demo is using old snapshots) that doesn't require patching.
fixed the SCF start script to match the new version.
fixed some build scripts to register the apps like enricher in the local repos (needed by SCDF to create the pipeline)
Updated to the latest Geode (M3)

@tzolov Couple of things I'd like to change on this before merging.

We should keep Maven offline, at least for this branch. It's made for bullet proof demos, and you don't want to depend on networking for that

"java -jar ./spring-cloud-dataflow-server-cloudfoundry-1.0.0.RELEASE.jar" - you don't want the need of the main SCDF Jar file to be copied to the demo local folder.  We should rather keep a variable like $SCDF_PATH and use that, like it was on the original script.

Removing the scdf-stream-apps.properties file adds the need of good networking for demos. Undesirable.

Maybe we'd like to keep a branch for online demos, but this one should be offline. You don't want to depend on networking while presenting at conferences and events...
How do you want to do it..? I appreciate the effort but maybe we can merge this into a new branch (assuming it's possible)?


Remove: bitvise.SSHClient version 9.17

## Replaced by 9.24

[X] Have you signed the Contributor License Agreement?
[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?

[ ] Have you tested your manifest locally with winget install --manifest <path>?
[ ] Does your manifest conform to the 1.2 schema?

@wingetbot run


updated how documentation reads the version number

Pull Request Test Coverage Report for Build 325

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 98.004%

Totals

Change from base Build 323:
0.0%

Covered Lines:
2210

Relevant Lines:
2255

💛  - Coveralls


sessionAffinity value is always true for installation via Cilium helm chart.

Bug report

General Information

Cilium version (run cilium version)
1.10.x helm chart

How to reproduce the issue

 helm fetch cilium/cilium --version 1.10.5  (I tested with 1.10.4 and verified whether this repeats on 1.10.5)
tar xf cilium-1.10.5.tgz
Edit values.yaml and uncomment sessionAfinity value in values.yaml file, leave the value at 'false'.
Now either install using helm or to test without install run helm template . -f values.yaml , in the generated manifest search for enable-session-affinity and check the value, this is always true.

This is fixed after 1.12.0, the commit is https://github.com/cilium/cilium/commit/19d94afdf7d31d3f9688c37265c73acf5a7241a1, part of this pr https://github.com/cilium/cilium/pull/16179


Incorrect behaviour of the algorithm responsible for filling the polygon (EditableGeoJsonLayer)

Reproduction steps:

Draw out a polygon in the DrawPolygonMode
Switch to the ModifyMode
Modify the polygon such that the edges overlap forming an hourglass

Expected behaviour:

The two triangles of the hourglass are filled

Actual behaviour:

The filling is lacking an edge

I believe deck.gl expects that the defined curve has a consistent “winding order”, you'll see a similar result on https://geojson.io/ and https://play.placemark.io/. Rendering relies on concepts like the nonzero rule and back-face culling.
If you were to load these points...
D    A

B    C

... in a 3D viewport and view from all sides, I think you'd see the renderer draws two triangles, ABC and CDA, with ABC facing up and CDA facing down. If you want to draw both sides of all triangles, you can disable back-face culling, but the result will still be a bit different from the hourglass you describe. For that I think you would need a more opinionated interpretation of the polygon.

Agree with @donmccurdy, this is expected behavior.  The side defines the "inside" of the shape. If you drag the fence to make an hourglass, the white side is no longer enclosed, and thus the fence no longer encloses an area, in other words it is not a valid polygon.
If you need to draw an hourglass, you need to trace both polygons with the same winding order

We're using the popular turf.js library to filter data points so that only the ones within the polygon are included, and we get an (here expected) hourglass behaviour there. Is it possible to configure or swap out from the outside the algorithm responsible for the calculation?

Or, alternatively, there is a setting called preventOverlappingLines. It would be great to enforce this behaviour when the user is editing the polygon as well. For instance, when the user lifts up the mouse key we could check for the overlap, and if so, a vertex could go back to where it was before the user started dragging.


Doc available as a tab under kitematic

Rather than switching/starting a browser window why not have the doc rendered/available as another
tab in kitematic?

@rkazak It could be done, but some of the formatting for the docs doesn't make it very friendly, especially when having to capture external links that could be in the docs.
If you'd like to give it a shot, please do and open a PR for us to checkout :D


/v1/provide-list-of-device-interfaces: wrong error response (message) for unknown mount-name

The service is called for mount-names, but the message states that nothing is found for "LINK".
This needs to be changed to mountName

Test was done in lab

can be closed, we will anyways harmonize responseCodes with 1.1.3


Backport: Replace memoizing Supplier by Cached in JvmInstallationMetadata

For compatibility with the configuration cache.

@bot-gradle test and merge

Your PR is queued. See the queue page for details.

@bot-gradle test and merge

Your PR is queued. See the queue page for details.

Let the commit find its way to release the usual way.


Optimize lodash

Before optimization:
 - dist/assets/dummy-aa8d2cb9308c6170ecb315cb96549af5.js: 34.54 KB (5.96 KB gzipped)
 - dist/assets/dummy-de3c495d5da3bffcdc865aaa60f76ab3.css: 22 B (42 B gzipped)
 - dist/assets/vendor-587a4740c9bd67b649fca71615bea161.js: 1 MB (244.52 KB gzipped)
 - dist/assets/vendor-d41d8cd98f00b204e9800998ecf8427e.css: 0 B

After optimization:
 - dist/assets/dummy-aa8d2cb9308c6170ecb315cb96549af5.js: 34.54 KB (5.96 KB gzipped)
 - dist/assets/dummy-de3c495d5da3bffcdc865aaa60f76ab3.css: 22 B (42 B gzipped)
 - dist/assets/vendor-b7c7526584242f9ac56ad1ebdac1649a.js: 923.63 KB (233.51 KB gzipped)
 - dist/assets/vendor-d41d8cd98f00b204e9800998ecf8427e.css: 0 B

Vendor build shrunk by ~8% (76.37 KB)

@dustinfarris it was too easy adding them to the package.json and it'll make it easier for an addon to automate populating that config via CI that scans their code for gathering a list of lodash methods used.

@dustinfarris I can't see any reason not to merge this as it shaves off 76K
Any reason we shouldn't?


Invalid http2 settings id may cause app crash.

There is a crash report, http2 settings value has some problem from server, but I think client must do some guard judgment agains this.
java.lang.ArrayIndexOutOfBoundsException
length=10; index=-27591
okhttp3.internal.http2.Settings.set(Settings.java:65)
okhttp3.internal.http2.Http2Reader.readSettings(Http2Reader.java:304)
okhttp3.internal.http2.Http2Reader.nextFrame(Http2Reader.java:149)
okhttp3.internal.http2.Http2Reader.readConnectionPreface(Http2Reader.java:83)
okhttp3.internal.http2.Http2Connection$ReaderRunnable.execute(Http2Connection.java:571)
okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32)
java.lang.Thread.run(Thread.java:818)

It would be good to reproduce this in a standalone test first, otherwise it's hard to know we have completely fixed this.  But as reported it does look like a bug as OkHttp shouldn't get into an undefined state or crash the app based on invalid responses from a single server.

Fixed already https://github.com/square/okhttp/commit/3819ed03996f1497512bffb445f81398a0bbaa17#diff-537e6894951189ccea5a38e6201e2161


[RFC][DNM]syscall: Move arch specific syscall code into its own header

Split out the arch specific syscall code to reduce include pollution
from other arch related headers.  For example on ARM its possible to get
errno.h included via SoC specific headers.  Which created an interesting
compile issue because of the order of syscall & errno/errno syscall
inclusion.
Signed-off-by: Kumar Gala<EMAIL_ADDRESS>

@andrewboie can you take a look and see what you think.  Before I go fixup arc & x86, wanted to see that the direction was acceptable.

Thanks @galak. This fixes #9054

Thanks @galak. This fixes #9054

Ah, nice side effective, wasn't sure if it would help there or not.

Yeah this LGTM

Codecov Report

Merging #9253 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #9253   +/-   ##
=======================================
  Coverage   52.46%   52.46%
=======================================
  Files         201      201
  Lines       25290    25290
  Branches     5286     5286
=======================================
  Hits        13268    13268
  Misses       9938     9938
  Partials     2084     2084

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b8ca8cf...7b891f2. Read the comment docs.

Some ARC-related issues revealed by CI, probably just a missing include, otherwise LGTM

Yeah, was being lazy and letting CI do a check for me.  Should hopefully now work on arc & x86.


FATAL OR BUG

When I tried to run this query :
$orders = $db->select('orders','order_id',[
'AND' => [
"order_id"    => [1,2,3],
"done"      => false
]
]);
The query does not return what I'm expected,
I started to debug it and i figure out that it happens only when the key start with "or.." (i.e. order_id),
when I changed it to another string (that doesn't starts with or..) that works.

Thanks for the report :)
This bug fixed.

There is a problem with the fix https://github.com/catfan/Medoo/commit/76574afc684ea95a7e8c101aef4d1e126e73e76c
The regexp won't match single 'OR' or single 'AND' (without ' #...' after), so a query like this won't work :
if ($database->has("account", [
"AND" => [
"OR" => [
"user_name" => "foo",
"email" => "foo"
],
"password" => "12345"
]
]))
because of imbricated AND/OR.
Here's a better fix :
/^(AND|OR)(\s+#.*)?$/i

@4t0m1k Good point :)


fix: updated broken links

Updated broken links to SCI guidance to valid ones and cleaned up linter warning.
Closes #164

Great @guidemetothemoon! And thanks for noticing that website/.htmltest.yml needed to be updated too!


SSR

SolidJS needs different Babel settings on server and client when using SSR. Not clear this is possible in Meteor, but maybe with a custom replacement for ecmacsript module.

Fixed by b05318f1937720cc4b529c1e47ba6f9bfc5682f7


[Bug]: Some backgrounds are transparent

Version

[X] Yes

General Question

[X] No

What happened?
After generating all the images, I noticed that a handfull of them have a transparent background. Upon looking at their corresponding json files, they should all have coloured backgrounds. Hard to explain but say for example two images have 'Light Blue' in their metadata, one appeared blue in the final image and the other just has a transparent background for some reason.
What have you tried?
I tried to see if it was a certain colour code that Visual Studio could not read, but there were finished images with the colours that were not working for others images.
Relevant log output
No error with coding.

Protect your information

[X] I Agree

I have a similar problem. Images are mostly with a white background, sometimes 100% of them.

I had a similar problem where a lot of my images ended up with a white background. It's actually caused by the layers not being exported appropriately from the drawing tool. The layer above the background was exported with a white background and overwrote the background color.


SAA-1380 correcting runbook for running job.

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

Comparison is base (c64da69) 86.88% compared to head (96dd164) 86.88%.

Additional details and impacted files
@@            Coverage Diff            @@
##               main     #694   +/-   ##
=========================================
  Coverage     86.88%   86.88%
  Complexity     3303     3303
=========================================
  Files           359      359
  Lines         11529    11529
  Branches        874      874
=========================================
  Hits          10017    10017
  Misses         1113     1113
  Partials        399      399

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


Display of environments for atoms at the boundary

Hello,
Great job with the chemiscope and I am hoping to use it more and more in my work. For simple stuff it worked really great but I hit some corner cases and it would be nice to have solution at some point of time.  The most annoying one is the display of local environment for a atom that is near periodic boundary. The highlight portion does not go across the box. Also the replicated unitcell does not highlight the replica atoms which would have by passed this problem.  See the screeshot for your zeolite example.

Also the replicated unitcell does not highlight the replica atoms which would have by passed this problem.

This should work if you are using a 3x3x3 supercell (to ensure there is a replicated cell on both sides of the central one). While it is not ideal, it should allow simple visualization, especially in conjunction with style: hide for  background atoms (in advanced environments options).

@Luthaf I see ! Thanks for the tip. Will try again.

Okay ..so this workaround solved the proble. If you prefer you can close this issue.

nono, this is a long-standing issue and I think we need a better solution.
there are many issues, you can click on atoms that are not environment
centers, and say you have only a few significant environments over a huge
structure, the json is huge just to hold NaNs.
On Sat, 29 May 2021 at 15:47, Sandip De @.***> wrote:

Okay ..so this workaround solved the proble. If you prefer you can close
this issue.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/cosmo-epfl/chemiscope/issues/133#issuecomment-850836365,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIREZYAT6Q53Y7IMS3RS5LTQDV6XANCNFSM45W6SCCQ
.

Are you talking about #134 and not this issue @ceriottm? But I agree we could find a better way to display environments at the boundary of the cell.

Ah yes, I meant #134. I don't know, we could have a "border" option if it's
possible - but a 3x3x3 cell seems a good enough solution 90% of the time
On Sat, 29 May 2021 at 20:31, Guillaume Fraux @.***>
wrote:

Are you talking about #134
https://github.com/cosmo-epfl/chemiscope/issues/134 and not this issue
@ceriottm https://github.com/ceriottm? But I agree we could find a
better way to display environments at the boundary of the cell.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cosmo-epfl/chemiscope/issues/133#issuecomment-850879003,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIREZ75AHP3D7QGEIN7AQLTQEXINANCNFSM45W6SCCQ
.

Let's close this saying that a 3x3x3 cell should be enough, and if someone comes up with a use case for something else they can open a new issue!


Missing SearchIndex values

According to https://webservices.amazon.com/paapi5/documentation/locale-reference/united-states.html#search-index it should be possible to specify for example MoviesAndTV and AmazonVideo, but these values are missing from SearchIndex https://github.com/nager/Nager.AmazonProductAdvertising/blob/master/src/Nager.AmazonProductAdvertising/Model/SearchIndex.cs

Absolutely correct.
The problem is that indices are differenzt for each localization.
https://webservices.amazon.com/paapi5/documentation/locale-reference.html
I will try to bring all indizes together into one list and then I will do a pull request.
For all practical purposes  every localization have to be implemented.


open foreign key also with no rows selected

Double-clicking on a foreign key when no row is selected in the table does not produce any effect.
It could be nice if an "Yes/No" message box comes out asking if you want to open the table anyway, without any filter.

Easier to do it wthout message box, just showing a message that no row was selected

warning message when no rows have been selected. Dialogs in JavaFX have just appeared in release 40, so too early to use them.


Documentation could benefit from "Binding Model" discussion

This seems non-trivial, but the issue has raises its head in a number of situations at this point.  So I think the docs need to get to this design issue quickly.
-- how does one bind parameters to a graph, and when
-- What is the motivation for the choices made. (What does it allow the runtime to do more efficiently?)

Updated this in the most recent commit (will take a few minutes to propagate to website). Let me know if that covers it.


configuration.settings are always strings, not symbols

After struggling to find why this configuration wasn't being applied, I found that it was loading from a symbol, meanwhile thinking_sphinx.yml's loaded variables were being treated as strings.

Thanks :) just merged this in (with a minor refactor in 9e7a13b4bfd99bb1787327f7b3d3a99e3d855c0a).


[CT-2868] [Feature] Enable dbt ls to access run results state (related to retry)

Is this your first time submitting a feature request?

[X] I have read the expectations for open source contributors
[X] I have searched the existing issues, and I could not find an existing issue for this feature
[X] I am requesting a straightforward extension of existing dbt functionality, rather than a Big Idea better suited to a discussion

Describe the feature
In a retry scenario, it may be useful to identify the models targeted for the rerun vs. just running them. dbt ls is well suited for listing models that would be targeted, EXCEPT that it doesn't support using the run_results.json to derive project state. I believe the set of supported selectors for ls are:
'new', 'old', 'modified', 'unmodified', 'modified.body', 'modified.configs', 'modified.persisted_descriptions', 'modified.relation', 'modified.macros', 'modified.contract'

Describe alternatives you've considered
Potentially a --dry-run mode in dbt retry itself.
Who will this benefit?
dbt Users (but only the good ones)
Are you interested in contributing this feature?
yes
Anything else?
No response

Nice one @matt-winkler 🧠
Are you thinking of new selectors for the "state" selection method that utilizes info from run_results.json within the --state directory? Maybe like these?

state:success
state:error

or maybe a new subselector like this?

state:status.success
state:status.error
state:status.empty

If so, then it could be used in multiple ways:
dbt ls --select state:error
dbt test --select state:error
dbt run --select state:error
# etc.

Hey @dbeatty10 good question! I was thinking it would look something like dbt ls --select result:error etc. If I understand correctly, the state selector identifies changes that occur in the manifest.json, and the result selector identifies outcomes from the run_results.json.
But other than that, it looks like we're thinking about this in much the same way - "more options on the result selector"

Unless I'm missing something big - I think this is already possible in exactly the way @matt-winkler hinted at above, using the result: selector:
dbt ls -s result:error result:fail result:skipped

https://docs.getdbt.com/reference/node-selection/syntax#the-result-status
You can see this maps to the "retryable" statuses we have defined for the retry task here:
https://github.com/dbt-labs/dbt-core/blob/8350dfead3cf3a9257d1d4e7f76d0a7e1f04d9d3/core/dbt/task/retry.py#L21
The only thing this doesn't work for is dbt source freshness, because:

it writes sources.json instead of run_results.json
it can produce the status runtime error, which contains a space in its string representation (mildly annoying; previously discussed in https://github.com/dbt-labs/dbt-core/issues/5276)


Python: Content Filter Exception not happening on Function Invoke

Describe the bug
I need to run a prompt I have in a jinja template and check it for filtered content by catching the exception in case it fails but when I run kernel.invoke I only receive KernelInvokeException instead of a ContentFilterAIException.
To Reproduce
Steps to reproduce the behavior:
This is my code:
self.kernel.add_service(AzureChatCompletion())
prompt = self.jinja2.get_prompt_string(file)
self.kernel.add_function(
    prompt=prompt,
    function_name=service_name,
    plugin_name=service_name,
    template_format="jinja2"
)
try:
    result = await self.kernel.invoke(function_name=service_id, plugin_name=service_id, **params)
except ContentFilterAIException as ex:
    self.logger.error('Content filter result', ex.content_filter_result)
    raise Exception(e) from e
except KernelInvokeException as ex:
    self.logger.exception(f"Kernel invoke exception: {ex.__cause__}")
    raise Exception(ex) from ex
except Exception as e:
    self.logger.exception(f"Error getting chat completion response: {e.__cause__}")
    raise Exception(e)

I get KernelInvokeException instead of ContentFilterAIException.
Expected behavior
I need the ContentFilterAIException to be able to handle the error properly.
Platform

OS: Windows
IDE: VS Code
Language: Python
Source: semantic-kernel 1.17.0

Additional context
I tried using this code https://github.com/microsoft/semantic-kernel/issues/4802 but is not valid any more.

Hi @afrancoc2000, the only time the ContentFilterAIException is raised is from a response from the model, as shown here:
https://github.com/microsoft/semantic-kernel/blob/926a59095b8b9a4a2f0b9cf616caf9a1045b360f/python/semantic_kernel/connectors/ai/open_ai/services/open_ai_handler.py#L94C13-L98C26
Do you have the proper configuration set in your Azure OpenAI deployment to filter the prompt? https://learn.microsoft.com/en-us/azure/ai-services/openai/concepts/content-filter?tabs=warning%2Cuser-prompt%2Cpython-new
For context, what message does the KernelInvokeException include?


Make static methods invertable

Since the TypeScript refactor, test are only invertable in the chain context.
Is there an elegant way to bring inversion to tests in the static context?

This should be solved by #3.


Allow providing a URL fragment for posts

A number of folks use a single page for multiple posts, using a URL
Fragment parameter to denote which of the posts on the given page should
be used, and are used to this experience with Bridgy.
To allow use of this on Bridgy Fed, too, we can add support for
discovering the ID of the h-entry to be Webmention'd in the same way
that we do with Bridgy.
This largely copies the structure of the existing tests, copying
test_activitypub_follow, and adding in multiple posts on the page.
For debugging purposes, we can make sure to log out the fragment.

This is great! So clean. Thank you so much for the contribution, test, and docs! Merging and deploying now.

Thanks!
I'm assuming it's not yet live as:
curl https://fed.brid.gy/webmention -d 'source=https://blogroll.jvt.me/contacts/carol/#2' -d target=https://fed.brid.gy

Returns a 400:
<!doctype html>

<title>400 Bad Request</title>

Bad Request

No microformats2 found on https://blogroll.jvt.me/contacts/carol/#2

Hmm! Deploy was at 14:55 UTC, it should be out. Let me confirm...yup, your change is in there. 🤷

Ah, it turns out my post didn't had ids on the h-entrys :upside_down_face:
Looks like I'm now getting:
<!doctype html>

<title>502 Bad Gateway</title>

Bad Gateway

401 Client Error: Unauthorized for url: https://mastodon.social/users/carolgilabert/inbox ; Unable to fetch key JSON at https://fed.brid.gy/blogroll.jvt.me

I'd hoped that setting the author on my post would be enough to convince Bridgy Fed to use my user for that.
May need to raise another PR for that :sweat:

blogroll.jvt.me and www.jvt.me are different domains, we can't know that they're owned by the same person. We could maybe do it if the use case was author on jvt.me points to www.jvt.me, since it's a subdomain, but I'm still reluctant.

Hmm, OK, that's fair. I'll look to merge this back into my main site then, thanks!

Managed to get this working on my main site :clap:
https://fed.brid.gy/user/www.jvt.me shows that the source URL is https://www.jvt.me/blogroll/__https_mastodon_social_carolgilabert instead of https://www.jvt.me/blogroll/#https_mastodon_social_carolgilabert

Awesome! And good catch, sounds like we need to wrap these in self._decode():
https://github.com/snarfed/bridgy-fed/blob/1f4c6433b5a3204a3119b89b5da19447f1f00607/models.py#L109-L114


fix(setup ci|cd): setup ci|cd pipelines

What does this PR do?

fixes setup ci|cd pipelines

Description of Task to be completed?

find heroku log
configures package.json
configures .travis.yml

How should this be manually tested?

Check heroku staging - https://staged-team-010-backend.herokuapp.com/
check travisCI build - https://travis-ci.com/github/BuildForSDG/team-010-backend/builds/166455125
check coveralls coverage - https://coveralls.io/github/BuildForSDG/team-010-backend

Any background context you want to provide?

Please take note that all test env variable would henceforth be added on .travis.yml file
ignore the currently unkown badges on the branch, the badges can only reflect the develop branch which would begin after merge

What are the relevant pivotal tracker stories?
Screenshots (if appropriate)
Questions:

Hi @torsami77 you have done a nice work here, kindly remove sequelize-test-helpers and parcel-bundler from the package.json file since we not use it for the project

Thanks for pointing those out bro, would effect those changes soon

@torsami77 also add the build folder to gitignore file as it is not necessary to push it to the repo


Add subdomain config in cookie sharing topic

Fixes #7392

@scottaddie Since Chris is OOF this week, I think we can go by his remark on the issue as to the sufficiency of these updates. :point_right: https://github.com/aspnet/Docs/issues/7392#issuecomment-402808388


List Data Type tutorial

Closes #330.
Open to feedback. Might take some time to come up with Rust examples because I don't know Rust.

@c-peters, should be okay. I don't know enough rust to add it here, unfortunately, and I can't find other examples in the docs in the string section for calling rust.
The test-node failure seems unrelated, since I didn't touch that code.

Hi @avimallu , I reviewed your PR. Thanks for the contribution, the comments mostly refer to how to link to the API documentation and to ensure the documentation remains agnostic to languages other than Python. That way we can insert node js / rust examples without changes the main documenation.

@c-peters, thank you so much for patiently pointing out where the pull request was lacking. I've addressed all your comments; just wanted to make sure you wanted to remove the pandas comparison for percentage ranks - it was a good one that's currently present and shows the expressiveness of the expression API.


vue-router doesn't accept components created with DefineComponent()

Version
2.7.6
Reproduction link
vue-2.7-router-issue
Steps to reproduce

run npm i
run npm run check

What is expected?
no type error
What is actually happening?
vue-tsc given following error.
src/router/index.ts:9:7 - error TS2322: Type 'ComponentPublicInstanceConstructor<Vue3Instance<Data, Readonly<ExtractPropTypes<__VLS_TypePropsToRuntimeProps<{ title: string; }>>>, Readonly<ExtractPropTypes<__VLS_TypePropsToRuntimeProps<{ title: string; }>>>, {}, {}, true, ComponentOptionsBase<...>> & ... 5 more ... & Readonly<...>, ... 4 more ..., MethodOptions>...' is not assignable to type 'Component | undefined'.
  Type 'ComponentPublicInstanceConstructor<Vue3Instance<Data, Readonly<ExtractPropTypes<__VLS_TypePropsToRuntimeProps<{ title: string; }>>>, Readonly<ExtractPropTypes<__VLS_TypePropsToRuntimeProps<{ title: string; }>>>, {}, {}, true, ComponentOptionsBase<...>> & ... 5 more ... & Readonly<...>, ... 4 more ..., MethodOptions>...' is missing the following properties from type 'VueConstructor<Vue<Record<string, any>, Record<string, any>, never, never, never, never, (event: string, ...args: any[]) => Vue<Record<string, any>, Record<string, any>, ... 4 more ..., ...>>>': extend, nextTick, set, delete, and 10 more.

9       component: TestPage,
        ~~~~~~~~~

Found 1 error in src/router/index.ts:9

It looks like a similar issue as composition-api #185.
The issue seems to be solved by modified ComponentPublicInstanceConstructor type to be mixed with VueConstructor.
diff --git a/types/v3-component-public-instance.d.ts b/types/v3-component-public-instance.d.ts
index a5bf6701..d616eff6 100644
--- a/types/v3-component-public-instance.d.ts
+++ b/types/v3-component-public-instance.d.ts
@@ -229,6 +229,6 @@ export type ComponentPublicInstanceConstructor<
   D = any,
   C extends ComputedOptions = ComputedOptions,
   M extends MethodOptions = MethodOptions
-> = {
+> = VueConstructor & {
   new (...args: any[]): T
 }

Reference from composition-api pull #189

Unfortunately the change will lead to an infinite loop in the type test suite. This should probably be fixed in a patch by vue-router.
/cc @posva


The program editor cursor is off by a few lines (Chrome on MacOS)

Just open any long program and go to the end.
Click there, and you will find the cursor is off by a couple of lines.
This is better visible when you click over the lines and highlight them.
This is confusing to the users. Is it because of the syntax highlighting module? If we can get rid of this bug by removing the syntax highlighting, that can be a better workaround.

This is a coding logic bug which can be resolved with some debugging. No need to remove syntax highlighting for this will send a PR for the same shortly.

great. Looking forward to the PR. Thanks.

I could not replicate this issue on the local machine. Please check if PR #47 fixes this as well.

This issue is still present. To reproduce, just open the concore editor https://controlcore-project.github.io/concore-editor/
Then upload the concore folder from the concore repository and open the "concoredocker.py" (or any sufficiently long file actually), in Chrome.
Then select all the text of the file, or just go to the last line. You start to see how the lines are off and you won't be able to figure out where you are actually typing.
I have included a screenshot in the original report of this bug. You can open it to see how it looks like.

Even after the last PR merge, the issue still exists.

We have observed this issue on Chrome on Mac OS.
The issue does not exist in Firefox on Mac OS.

Chrome on Windows does not have the cursor misaligned the way it is on macOS. So, this can be tricky to reproduce and fix.

Could you please share the chrome version info and check if any fonts "Arial", "Helvetica", or sans-serif are present?
This can be checked by going into browser settings.
Most likely, this is a font/ configuration issue, as I checked with a friend having mac and this issue doesn't appear.
The Chrome on macOS he tested had - Version 107.0.5304.87 (Official Build) (x86_64)

Upon digging further, I found this issue.
It clears that this is a browser issue and happens only on Chrome on macOS.
I will spend some time looking for a workaround to fix this. Otherwise, I would change the library used for syntax highlighting.

Great found. Thanks.

hey @pradeeban , can you please tell me about this bug some details , not able to properly understand it from above conversation , so that I will start work upon it

Hi @parteekcoder,
Please you open this screenshot ->> https://github.com/ControlCore-Project/concore-editor/blob/main/figures/program-editor.png
You will see the curser lines being off by several lines, making the program editor unusable on Chrome on MacOS. This is bad because Chrome is our officially supported browser, and this bug makes the program editor unusable altogether on MacOS.
Please let me know if that makes it clear.
@Aviral09 may have more pointers.

Hi @parteekcoder, Please you open this screenshot ->> https://github.com/ControlCore-Project/concore-editor/blob/main/figures/program-editor.png
You will see the curser lines being off by several lines, making the program editor unusable on Chrome on MacOS. This is bad because Chrome is our officially supported browser, and this bug makes the program editor unusable altogether on MacOS.
Please let me know if that makes it clear.
@Aviral09 may have more pointers.

yeah understood , Is it only happens with large files or small too?
@Aviral09 may have more pointers.  "what do you mean by this"

It happens with any file. But it will be more obvious in large files.
Appears only in MacOS. This was implemented by @Aviral09. So, I mean, he may be able to give you more guidance if needed (when/if his time permits, that is).

It

OK I will look into this issue

Great. Thanks.
Please make sure you have access to a Mac OS. It appears only in Mac OS, as far as I am aware.

hey @pradeeban @Aviral09 I am not able to reproduce this issue, Are able to reproduce this issue

Hi @parteekcoder, I can reproduce this even in your own github deployment.
You need MacOS and Chrome to reproduce this.
Open the demo/pm.py and highlight all the text. You will see the issue. The cursor is off by a few lines - especially noticeable in large files.

Can you please send a small video

It will be difficult to solve until I reproduce it

It could be an issue that is specific to certain versions of MacOS? Both Mark and I were able to reproduce this. If you cannot reproduce it, please do not attempt a fix.

hey @pradeeban did you find any solution for this issue?