text:
Inquiry About Slow Training Speed

Hello AnFreTh,
Thank you for your work on this project. I am currently using Mambular to process tabular data, but I am experiencing very slow training speeds. On average, each epoch is taking around 80 minutes to complete.
Here are the details of my setup:

Batch size: 256
GPU: NVIDIA 4090
Data: 8139 samples, each with 425 features
Model settings: default parameters

For comparison, when I use ResNet or FT-Transformer as tabular encoder with the same setup, the training speed is approximately 25 seconds per epoch, which is significantly faster. Is it expected that Mambular would be much slower than ResNet or FT Transformer? Or could this be an issue with my configuration or code?
I would appreciate any insight you could provide. Is there any known issue, or something I can adjust in my configuration to improve the speed?
Please let me know if you need additional information to help diagnose the problem.
Thank you for your time and assistance!

It is expected that Mambular is slower than e.g. FT-Transformer, especially for datasets with a lot of features, since training time increases linearly with sequence length (number of features). However, we experienced this by a factor of 2.5-3 while being more memory efficient than FT-Transformer.
Could you provide a minimal code example with simulated data where you experience similar training times? Then we can verify.

Hello AnFreTh,
Thank you for your reply. Based on your suggestion, I have prepared a minimal code example for you to review.
In my current framework, I am using Mambular as the tabular encoder within a table-image contrastive learning setting. I defined a CustomMambularEncoder class, making the following modifications:

I used an embedding method consistent with FT-Transformer due to differences in how the data is read.
I removed the classification head, so the encoder outputs only the feature vectors from Mambular.

For simplicity, the provided code example only uses simulated tabular data. This dataset has 8139 samples in total, with 6530 samples split between the training and validation sets. Each sample consists of 423 numerical features only, with no categorical features.
When running this simplified code (with a batch size of 16), training the Mambular encoder takes approximately 2.5 hours per epoch, while using the FT-Transformer encoder takes around 15 seconds per epoch, and using ResNet as the encoder takes about 7 seconds per epoch.
I have attached the code example for your review. Please let me know if anything else is needed to further investigate the issue.
Thank you again for your help!
import torch
import pytorch_lightning as pl
from torch.nn import functional as F
from mambular.arch_utils.mamba_arch import Mamba
from mambular.arch_utils.normalization_layers import (
    RMSNorm,
    LayerNorm,
    LearnableLayerScaling,
    BatchNorm,
    InstanceNorm,
    GroupNorm,
)
from mambular.configs.mambular_config import DefaultMambularConfig
from mambular.base_models.basemodel import BaseModel
from typing import List
from torch import Tensor
# embedding methods from FT-Transformer
from models.rtdl_revisiting_models import LinearEmbeddings, _CLSEmbedding

class CustomMambularEncoder(BaseModel):
    """
    Modified encoder based on Mambular:
    - the embedding layer is modified to be consistent with FT-Transformer.
    - the tabular head is removed.
    """

    def __init__(
        self,
        n_cont_features: int,
        cat_cardinalities: List[int],
        n_categories: List[int],
        config: DefaultMambularConfig = DefaultMambularConfig(),
        **kwargs,
    ):
        super().__init__(**kwargs)
        self.save_hyperparameters(ignore=["cat_feature_info", "num_feature_info"])

        self.lr = self.hparams.get("lr", config.lr)
        self.lr_patience = self.hparams.get("lr_patience", config.lr_patience)
        self.weight_decay = self.hparams.get("weight_decay", config.weight_decay)
        self.lr_factor = self.hparams.get("lr_factor", config.lr_factor)
        self.pooling_method = self.hparams.get("pooling_method", config.pooling_method)
        self.shuffle_embeddings = self.hparams.get(
            "shuffle_embeddings", config.shuffle_embeddings
        )

        self.mamba = Mamba(
            d_model=self.hparams.get("d_model", config.d_model),
            n_layers=self.hparams.get("n_layers", config.n_layers),
            expand_factor=self.hparams.get("expand_factor", config.expand_factor),
            bias=self.hparams.get("bias", config.bias),
            d_conv=self.hparams.get("d_conv", config.d_conv),
            conv_bias=self.hparams.get("conv_bias", config.conv_bias),
            dropout=self.hparams.get("dropout", config.dropout),
            dt_rank=self.hparams.get("dt_rank", config.dt_rank),
            d_state=self.hparams.get("d_state", config.d_state),
            dt_scale=self.hparams.get("dt_scale", config.dt_scale),
            dt_init=self.hparams.get("dt_init", config.dt_init),
            dt_max=self.hparams.get("dt_max", config.dt_max),
            dt_min=self.hparams.get("dt_min", config.dt_min),
            dt_init_floor=self.hparams.get("dt_init_floor", config.dt_init_floor),
            norm=globals()[self.hparams.get("norm", config.norm)],
            activation=self.hparams.get("activation", config.activation),
            bidirectional=self.hparams.get("bidiretional", config.bidirectional),
            use_learnable_interaction=self.hparams.get(
                "use_learnable_interactions", config.use_learnable_interaction
            ),
            AD_weight_decay=self.hparams.get("AB_weight_decay", config.AD_weight_decay),
            BC_layer_norm=self.hparams.get("AB_layer_norm", config.BC_layer_norm),
            layer_norm_eps=self.hparams.get("layer_norm_eps", config.layer_norm_eps),
        )
        norm_layer = self.hparams.get("norm", config.norm)
        if norm_layer == "RMSNorm":
            self.norm_f = RMSNorm(
                self.hparams.get("d_model", config.d_model), eps=config.layer_norm_eps
            )
        elif norm_layer == "LayerNorm":
            self.norm_f = LayerNorm(
                self.hparams.get("d_model", config.d_model), eps=config.layer_norm_eps
            )
        elif norm_layer == "BatchNorm":
            self.norm_f = BatchNorm(
                self.hparams.get("d_model", config.d_model), eps=config.layer_norm_eps
            )
        elif norm_layer == "InstanceNorm":
            self.norm_f = InstanceNorm(
                self.hparams.get("d_model", config.d_model), eps=config.layer_norm_eps
            )
        elif norm_layer == "GroupNorm":
            self.norm_f = GroupNorm(
                1,
                self.hparams.get("d_model", config.d_model),
                eps=config.layer_norm_eps,
            )
        elif norm_layer == "LearnableLayerScaling":
            self.norm_f = LearnableLayerScaling(
                self.hparams.get("d_model", config.d_model)
            )
        else:
            raise ValueError(f"Unsupported normalization layer: {norm_layer}")

        # >>> Feature & cls embeddings in FT-Transformer.
        self.cont_embeddings = (
            LinearEmbeddings(n_cont_features+ len(cat_cardinalities), config.d_model) if n_cont_features > 0 else None
        )
        self.cls_embedding = _CLSEmbedding(config.d_model)
        # <<<

        if self.pooling_method == "cls":
            self.use_cls = True
        else:
            self.use_cls = self.hparams.get("use_cls", config.use_cls)

        if self.shuffle_embeddings:
            self.perm = torch.randperm(self.embedding_layer.seq_len)

    def forward(self, x):
        # cls embedding
        x_embeddings: List[Tensor] = []
        if self.cls_embedding is not None:
            x_embeddings.append(self.cls_embedding(x.shape[:-1]))

        # feature embedding, only numerical features in this case
        x_embeddings.append(self.cont_embeddings(x))

        x = torch.cat(x_embeddings, dim=1)

        if self.shuffle_embeddings:
            x = x[:, self.perm, :]

        x = self.mamba(x)

        if self.pooling_method == "avg":
            x = torch.mean(x, dim=1)
        elif self.pooling_method == "max":
            x, _ = torch.max(x, dim=1)
        elif self.pooling_method == "sum":
            x = torch.sum(x, dim=1)
        elif self.pooling_method == "cls_token":
            x = x[:, -1]
        elif self.pooling_method == "last":
            x = x[:, -1]
        else:
            raise ValueError(f"Invalid pooling method: {self.pooling_method}")

        x = self.norm_f(x)

        return x

class MinimalContrastiveMambularModel(pl.LightningModule):
    """
    Contrastive model for tabular data.
    """
    def __init__(self, feature_dim=128):
        super().__init__()
        self.mambular_encoder = CustomMambularEncoder(
            n_cont_features=423,
            cat_cardinalities=[],
            n_categories=[]
        )
        self.projection_head = torch.nn.Sequential(
            torch.nn.Linear(64, feature_dim),
            torch.nn.ReLU(),
            torch.nn.Linear(feature_dim, feature_dim)
        )

    def forward(self, x):
        encoded = self.mambular_encoder(x)
        projected = self.projection_head(encoded)
        return F.normalize(projected, dim=1)

    def training_step(self, batch, batch_idx):
        x1, x2 = batch
        z1 = self.forward(x1)
        z2 = self.forward(x2)
        loss = self.contrastive_loss(z1, z2)
        self.log('train_loss', loss)
        return loss

    def contrastive_loss(self, z1, z2, temperature=0.5):
        # NT-Xent Loss
        z1 = F.normalize(z1, dim=1)
        z2 = F.normalize(z2, dim=1)
        batch_size = z1.shape[0]
        similarity_matrix = torch.matmul(z1, z2.T) / temperature
        labels = torch.arange(batch_size, device=z1.device)
        loss = F.cross_entropy(similarity_matrix, labels)
        return loss

    def configure_optimizers(self):
        return torch.optim.Adam(self.parameters(), lr=1e-4)

# Simulated tabular data
# 6530 samples in the training & validation set
# 423 numerical features, 0 categorical features
simulated_data_1 = torch.rand(6530, 423)
simulated_data_2 = torch.rand(6530, 423)

# DataLoader
train_dataset = torch.utils.data.TensorDataset(simulated_data_1, simulated_data_2)
train_loader = torch.utils.data.DataLoader(train_dataset, batch_size=16)

# training
model = MinimalContrastiveMambularModel()
trainer = pl.Trainer(max_epochs=5, gpus=1, limit_train_batches=1.0)
torch.cuda.empty_cache()
trainer.fit(model, train_loader)

I could not recreate the extreme differences you reported, but still using default Mambular was 10x slower than FTTransformer for this specific setup. We will update the current Mambablock implementation to increase speed. I will transfer this issue to #133

I could not recreate the extreme differences you reported, but still using default Mambular was 10x slower than FTTransformer for this specific setup. We will update the current Mambablock implementation to increase speed.

update mamba-arch with parallel scan for speed improvement.
include LSTM for larger datasets. see LSTM/GRU identity issue #134

Thank you for taking the time to investigate the issue. I will try these and look forward to your updates. Thanks again for your help and support!

If you experiment further you could -instead of the python mamba implementation from Mambular- try out the original Mamba implementation: https://pypi.org/project/mamba-ssm/
If you do so, please let us know whether it improves speed :).

Since a true fix made available in the package might take some time, there are two fixes you could try to solve the issue faster:
First, try the TabulaRNN(model_type="LSTM", d_conv=16) but from the develop branch. So install the package via:
pip install git+https://github.com/basf/mamba-tabular.git@develop

This should be more memory efficient and similar in speed to the FT-Transformer. I would advise increase the kernel size of the convolution, given your large number of variables.
Second, depending on your ressources, you cuold try to leverage the original mamba implementation. This can be tricky, since not all systems/GPUs are supported.
pip install mamba-ssm

Then simply import mamba and switch it with the pytorch version from Mambular.
from mamba_ssm import Mamba #You could also try Mamba2

# in your class switch out the Mamba from Mambular with
self.mamba = nn.ModuleList()
for _ in range(n_layers):
self.mamba.append(Mamba(
            d_model=self.hparams.get("d_model", config.d_model),
            expand_factor=self.hparams.get("expand_factor", config.expand_factor),
            d_conv=self.hparams.get("d_conv", config.d_conv),
        )
)

See: https://github.com/state-spaces/mamba for further details on the original implementation.

Since a true fix made available in the package might take some time, there are two fixes you could try to solve the issue faster:
First, try the TabulaRNN(model_type="LSTM", d_conv=16) but from the develop branch. So install the package via:
pip install git+https://github.com/basf/mamba-tabular.git@develop

This should be more memory efficient and similar in speed to the FT-Transformer. I would advise increase the kernel size of the convolution, given your large number of variables.
Second, depending on your ressources, you cuold try to leverage the original mamba implementation. This can be tricky, since not all systems/GPUs are supported.
pip install mamba-ssm

Then simply import mamba and switch it with the pytorch version from Mambular.
from mamba_ssm import Mamba #You could also try Mamba2

# in your class switch out the Mamba from Mambular with
self.mamba = nn.ModuleList()
for _ in range(n_layers):
self.mamba.append(Mamba(
            d_model=self.hparams.get("d_model", config.d_model),
            expand_factor=self.hparams.get("expand_factor", config.expand_factor),
            d_conv=self.hparams.get("d_conv", config.d_conv),
        )
)

See: https://github.com/state-spaces/mamba for further details on the original implementation.

Thank you for your advice! I have tried the original Mamba implementation as suggested, and the training speed has significantly improved. It is now similar in speed to FT-Transformer and ResNet :).

V1.0.0 now includes both, Mamba1 and Mamba2 from the mamba-ssm package. I will close this issue, but feel free to reopen when there are further issues :)

authors: AnFreTh Jasmine-ycj

repo: basf/mamba-tabular


text:
Memory Leak in Lager [JIRA: RIAK-2132]

With active record in the log I see the memory increase. Are you familiar with the memory leak issue in lager? When you turn off the lager issue is fixed.

    {lager, [
        {handlers, [
            {lager_console_backend, debug},
            {lager_file_backend, [
                {file, "log/error.log"},
                {level, warning}
            ]},
            {lager_file_backend, [
                {file, "log/console.log"},
                {level, info}
            ]}
        ]},
        {crash_log, "log/crash.log"},
        {colored, true},
        {colors, [
            {debug, "\e[0;38m"},
            {info, "\e[0;32m"},
            {notice, "\e[1;36m"},
            {warning, "\e[1;33m"},
            {error, "\e[1;31m"}
        ]},
        {error_logger_hwm, 550}
    ]},

We affected by this too.

I have noticed this as well with the following configuration.
  {lager, [
    {handlers, [
      {lager_console_backend, [info, {lager_default_formatter, [time, " [",severity,"] ", {pid, ""}, {module, ["@", module, ":"], ""}, {function, [function, ":"], ""}, {line, ""}, " ", message, "\n"]}]}
    ]}
  ]},

Increasing the log level solves the problem as it eliminates the majority of the logs. Observing the node while the problem is happening reveals that lager_event is holding onto the memory despite the message queue not backing up. This seems like it might be a binary memory leak.

We removed whole lager_console_backend in our production profile's `environment and It served well for several days.

The problem does seem to only manifest with the console backend. I noticed no memory consumption with the file backend.

In case it's useful, in the past I've seen interesting hangs in the VM waiting on console output on Solaris and it's derivatives (SmartOS) which cleared when I attached direct to the VM over the 'to_erl' pipe and hit a few carriage returns.  I haven't seen it on other platforms to date, but we disabled the console backend for Riak in production so there would be less chance of it happening.

Can you let us know what version of Erlang you're using as well please? The connection to the console backend suggests it may also be a known issue with Erlang 18 (OTP-12941) that was fixed with Erlang 18.03 - If you're running 18, but not 18.03, could you upgrade your application and see if the problem persists?

I was using 18.0, running a small test on 18.0. 3 it appears that the memory leak is gone.

18.0.3 solves the problem, thanks

Thanks for the follow-up. Given the confirmations that 18.03 seems to solve the issue, and the know issue in Erlang 18 < 18.03, I'm going to close this issue for now. If anyone is seeing this in other Erlang versions, please reopen this and we'll take a more in-depth look at the issue.

This was caused by an issue in Erlang 18, before 18.03, where the console implementation had a memory leak - closed unless someone can reproduce it outside of the affected Erlang releases.
[posted via JIRA by Douglas Rohrer]

source: gharchive/issue

authors: Basho-JIRA JeetKunDoug LeoKudrik chwevans jonmeredith reith

repo: basho/lager

license_type: permissive

license_source: bigquery


text:
commit a change to see if we get codecov to send happily

Description
Include a summary of the changes this PR is bringing. Bring in any relevant context or motivation for the change that you deem useful to have in this PR description.
Example:
The aim of the PR is achieved by:

doing this amazing thing
this other one
deprecating this thing
changing this thing

How has this change been tested?
Supporting doc, tickets, issues
Merge Instructions (Optional)
Note to reviewer (Optional)
I'd like the reviewer to focus especially on ...

closing this because the testing is satisfactory

closing this because the testing is satisfactory

source: gharchive/pull-request

repo: bastienboutonnet/sheetwork

license: MIT

license_source: github-api


text:
🛑 SAT - Portal CFDI is down

In 7b2e881, SAT - Portal CFDI (https://portalcfdi.facturaelectronica.sat.gob.mx) was down:

HTTP code: 503
Response time: 294 ms

Resolved: SAT - Portal CFDI is back up in 22a260b.

repo: batnieluyo/sat-monitor


text:
bounding box bug if annotations are closed

dear support, thanks for your plugin. I encounter a problem when I try to add new annotations. If the bounding box have some overlapp with an other annotation, the part of this annotation is understood to belong to the new annotation. See the image :

Hey @matfallet,
I tried to reproduce it, but it works fine for me:
Object 1:

Object 2:

Could you provide some more information on this? What exact steps do you take when this problem occurs?

Closing this issue for now. If this error still occurs, we can reopen it.

authors: bauerdavid matfallet

repo: bauerdavid/napari-nD-annotator


text:
argparse-esque compat

[x] strip '-' from flags/args
[ ] typecast / typecheck parameters
[x] dot access

typing will require some further advanced reflection - calling good for now!

repo: bazaar-projects/docopt-ng


text:
Verify metadata.json integrity in CI?

As shown by https://github.com/bazelbuild/bazel-central-registry/pull/306, it's currently possible for the repository metadata to end up in a corrupted format.
I think the previous workflow we had that was removed with https://github.com/bazelbuild/bazel-central-registry/pull/237 would have caught this(though more "on accident" than being dedicated to this), so apparently the BuildKite presubmit checks aren't sufficient to catch this.
How do we want to deal this? Set up a dedicated metadata.json validation workflow?

The verify_stable_archives.py won't be able to catch this because it only reads the source.json file, not the metadata.json file.
We can implement the validation in https://github.com/bazelbuild/bazel-central-registry/blob/main/tools/bcr_validation.py

Copying my comment over from another thread:
I expected our validation script to catch it actually, but maybe json parsing failure isn't a hard error?
https://github.com/bazelbuild/bazel-central-registry/blob/8427967d922497e36dffe06bec46e8b1ead7edb4/tools/registry.py#L236-L239

Tested manually, json.load should throw the error
json.decoder.JSONDecodeError: Expecting ':' delimiter: line 27 column 17 (char 611)

The problem is that in https://github.com/bazelbuild/bazel-central-registry/pull/305 we only changed the metadata.json and not any specific module version, so the presubmit was totally bypassed.
https://buildkite.com/bazel/bcr-presubmit/builds/750#0184e213-962f-487e-ad45-6c1b21b2f68f
No target modules detected in this branch!

authors: Wyverald hobofan meteorcloudy

repo: bazelbuild/bazel-central-registry


text:
Call hotswap when ibazel run'ing Java binaries

I don't run any Java binaries so this is a FR for someone who does. It would be possible to detect that you're running a java_binary under the hood and leave the command running in the background then hot swap in the newest version of the code to prevent having to restart the server.

hi @achew22, thank you for suggesting this, i am from the future, and i am the user who needs this FR. lol
is this something that i can potentially contribute?

@sgammon this would be a great thing to contribute! We even have a nice hook for you.
What you're going to need to do is create a new Command that calls the appropriate command for hotswapping the Java binary out. You'll do that in the NotifyOfChanges function. Feel free to put the code in the same directory as notify_changes.go, and even use it as a template for writing this.
I'll think about how an e2e test can be written for this so that we can validate the behavior doesn't regress.

if we can keep this open, i'd love to pick it up over a weekend in the next month or so

Sounds good to me!

lol @achew22

Such an aggressive robot!

repo: bazelbuild/bazel-watcher


text:
add plus one deps transitive mode for compilation

Tries to balance between sternness of strict-deps off and strict-deps on cache issues and false positives.
We, Wix, have been using strict-deps=error for a long time and have been enjoying the relative ease a developer has when needing to add a new dependency.
However the current strict-deps compiler plugin has a serious drawback in generating too many false positives (causing errors about dependencies which aren't really used because of the compiler eagerness). This is a much bigger issue for us then the cache hits (which we also care about) since this means that:

Builds on master fail from seemingly innocent changes. This is because we have many repositories in a logical head dependency.
Additionally this causes developer fatigue which just try to "please the beast".

OTOH using strict-deps off has similar issues of easily breaking builds. For examples you can see the tests I added and also this scala-center discussion.
This PR adds a new heuristic mode which I hope will strike a better balance between the two. It passes to the compiler all direct dependencies and their direct dependencies since very often this is needed by the compiler. This was also confirmed by offline discussions with the google java people.
We also hope in the future to add some kind of post processing action (inside the bazel build) which might work over the byte code or source code to find strict-deps infringements of these plus one deps.
Additionally we have an internal tool in beta mode which goes over the compiler output and via various analyzers (mainly regex based) finds the needed FQN and then looks them up in bazel-out, external binary dependencies as well as a global index we have for our own source code.
This tool is run outside of bazel by the user.
We hope to open source this tool as well as the global index server API.

btw, I really wanted to refrain from adding the aspect to the deps attribute but rather run the aspect from command line but unfortunately this behaved very differently.

@ittaiz can you comment more or share any links about discussions with the google folks? Can you give some references: is this how it works at Google internally, do the standard java rules work this way?
I'd really like to be moving in the other way: less configuration. Adding a new compilation mode adds complexity and tends to cut the effectiveness of our tests since we generally are not multiplicatively expanding our tests to check all configurations.
I wouldn't want to keep inviting new heuristics for people to bolt into the rules that each company thinks is a good solution to the problem. I'd rather push the concerns upstream to scalac where possible, and follow the java standard rules as much as possible.

the discussions were offline with @cushon.
AFAIU the java rules work similarly to this but not exactly. They add all of the dependencies that were used in the previous layer.
Example:
A->B->(C,D) and D isn' used then AFAIU they will compile A with B and C.
In general the java rules are much more robust (and complicated) since they have more time/people/history behind it.
I agree I'd like less configuration but I have to say that the current default is mainly because it's what Stripe uses and Stripe started the project. It doesn't mean direct-only is the right mode and I'll even add that all of the google people I talked to thought it's unreasonable (see this discussion for a bit info).
Adding things to scalac might be a good long term goal but we can't hold our breath for it.
I'll add that as far as we're concerned we can definitely discuss removing the current implementation of strict-deps

I’ll also add that e2e indeed aren’t multiplied but the regular test/... are multiplied
Lastly I’d encourage many different approaches from different companies in hopes we’ll find a good one. From my examples you can see the direct mode breaks on simple usecases. People can get used to adding transitive dependencies without understanding but I don’t think it’s something we want to aspire to you.

I remembered one more thing about java rules- AFAIR they have one action which gets all of the transitive classpath to it but the differences from our current strict deps approach are:

They try to compile with the +1 variation I explained above and if fail they compile with all of it (as a single bazel action)
Their strict deps analysis mechanism is vastly superior to ours due to many reasons (javac/java simpler

Closed by mistake

@johnynek ?

@johnynek replied to everything. Feel free to reopen if you feel I've missed something.
Also not 100% sure about the documentation I added so open for feedback.

@johnynek wdyt? Also the breakage is due to jmh reproducibility flakiness

@ittaiz there was a recent change the jmh rules: #695 I wonder if that could be causing the issue.

re recent change in jmh- don't think it's related since my branch predates it

👍

authors: ittaiz johnynek


text:
Add static_files attribute to ts_web_test & ts_web_test_suite

Allows re-enabling packages/upgrade/test:test_web test in angular/angular: https://github.com/gregmagolan/angular/tree/ts-web-test-static-files (based off of https://github.com/angular/angular/pull/23845)

Resolves #131


text:
Update zio, zio-test, zio-test-sbt to 2.0.11

About this PR
📦 Updates

dev.zio:zio
dev.zio:zio-test
dev.zio:zio-test-sbt

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

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

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

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #71.

repo: bbarker/diz


text:
Translate readme into korean

Translated README.md into Korean for easy use for Korean people (added newly README_ko.md).
Any feedback and advice would be appreciated :)

Thanks for the effort, but I can't really accept this PR as this is not something I can maintain myself (I definitely don't know any Korean :-) ). I think it'd be best if you kept the korean version in your personal fork and updated it occassionally.

authors: MosesKim bbatsov

repo: bbatsov/rubocop


text:
test_json throwing errors

Seen when running make test
ERROR: test_dump_nmos_json (test_json.TestJSON)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/jamessa/BBC/IPStudio/dev/nmos-common/tests/test_json.py", line 89, in test_dump_nmos_json
    decoded = nmos_json.loads(fp.getvalue())
  File "nmoscommon/json.py", line 73, in loads
    return json.loads(*args, **kwargs)
  File "/usr/lib/python2.7/json/__init__.py", line 352, in loads
    return cls(encoding=encoding, **kw).decode(s)
  File "/usr/lib/python2.7/json/decoder.py", line 364, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "nmoscommon/json.py", line 96, in raw_decode
    value = self._reinterpret_object(value)
  File "nmoscommon/json.py", line 105, in _reinterpret_object
    o[key] = self._reinterpret_object(o[key])
  File "nmoscommon/json.py", line 113, in _reinterpret_object
    return Timestamp.from_tai_sec_nsec(o)
  File "nmoscommon/timestamp.py", line 498, in from_tai_sec_nsec
    return cls.from_sec_nsec(ts_str)
  File "nmoscommon/timestamp.py", line 171, in from_sec_nsec
    return cls(sec=sec, ns=ns, sign=sign)
  File "nmoscommon/timestamp.py", line 478, in __init__
    super(Timestamp, self).__init__(sec, ns, sign)
TypeError: super(type, obj): obj must be an instance or subtype of type

======================================================================
ERROR: test_dumps_nmos_json (test_json.TestJSON)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/jamessa/BBC/IPStudio/dev/nmos-common/tests/test_json.py", line 94, in test_dumps_nmos_json
    decoded = nmos_json.loads(encoded)
  File "nmoscommon/json.py", line 73, in loads
    return json.loads(*args, **kwargs)
  File "/usr/lib/python2.7/json/__init__.py", line 352, in loads
    return cls(encoding=encoding, **kw).decode(s)
  File "/usr/lib/python2.7/json/decoder.py", line 364, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "nmoscommon/json.py", line 96, in raw_decode
    value = self._reinterpret_object(value)
  File "nmoscommon/json.py", line 105, in _reinterpret_object
    o[key] = self._reinterpret_object(o[key])
  File "nmoscommon/json.py", line 113, in _reinterpret_object
    return Timestamp.from_tai_sec_nsec(o)
  File "nmoscommon/timestamp.py", line 498, in from_tai_sec_nsec
    return cls.from_sec_nsec(ts_str)
  File "nmoscommon/timestamp.py", line 171, in from_sec_nsec
    return cls(sec=sec, ns=ns, sign=sign)
  File "nmoscommon/timestamp.py", line 478, in __init__
    super(Timestamp, self).__init__(sec, ns, sign)
TypeError: super(type, obj): obj must be an instance or subtype of type

======================================================================
ERROR: test_load_nmos_json (test_json.TestJSON)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/jamessa/BBC/IPStudio/dev/nmos-common/tests/test_json.py", line 101, in test_load_nmos_json
    decoded = nmos_json.load(fp)
  File "nmoscommon/json.py", line 65, in load
    return json.load(*args, **kwargs)
  File "/usr/lib/python2.7/json/__init__.py", line 291, in load
    **kw)
  File "/usr/lib/python2.7/json/__init__.py", line 352, in loads
    return cls(encoding=encoding, **kw).decode(s)
  File "/usr/lib/python2.7/json/decoder.py", line 364, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "nmoscommon/json.py", line 96, in raw_decode
    value = self._reinterpret_object(value)
  File "nmoscommon/json.py", line 105, in _reinterpret_object
    o[key] = self._reinterpret_object(o[key])
  File "nmoscommon/json.py", line 113, in _reinterpret_object
    return Timestamp.from_tai_sec_nsec(o)
  File "nmoscommon/timestamp.py", line 498, in from_tai_sec_nsec
    return cls.from_sec_nsec(ts_str)
  File "nmoscommon/timestamp.py", line 171, in from_sec_nsec
    return cls(sec=sec, ns=ns, sign=sign)
  File "nmoscommon/timestamp.py", line 478, in __init__
    super(Timestamp, self).__init__(sec, ns, sign)
TypeError: super(type, obj): obj must be an instance or subtype of type

======================================================================
ERROR: test_loads_nmos_json (test_json.TestJSON)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/jamessa/BBC/IPStudio/dev/nmos-common/tests/test_json.py", line 106, in test_loads_nmos_json
    decoded = nmos_json.loads(NMOS_JSON_STRING)
  File "nmoscommon/json.py", line 73, in loads
    return json.loads(*args, **kwargs)
  File "/usr/lib/python2.7/json/__init__.py", line 352, in loads
    return cls(encoding=encoding, **kw).decode(s)
  File "/usr/lib/python2.7/json/decoder.py", line 364, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "nmoscommon/json.py", line 96, in raw_decode
    value = self._reinterpret_object(value)
  File "nmoscommon/json.py", line 105, in _reinterpret_object
    o[key] = self._reinterpret_object(o[key])
  File "nmoscommon/json.py", line 113, in _reinterpret_object
    return Timestamp.from_tai_sec_nsec(o)
  File "nmoscommon/timestamp.py", line 498, in from_tai_sec_nsec
    return cls.from_sec_nsec(ts_str)
  File "nmoscommon/timestamp.py", line 171, in from_sec_nsec
    return cls(sec=sec, ns=ns, sign=sign)
  File "nmoscommon/timestamp.py", line 478, in __init__
    super(Timestamp, self).__init__(sec, ns, sign)
TypeError: super(type, obj): obj must be an instance or subtype of type

Fixed by https://github.com/bbc/nmos-common/pull/29/commits/c2bca19aa2f0f4e5a090384e140c4a56e79d227f

repo: bbc/nmos-common