Lightning is very slow between epochs, compared to PyTorch.

I converted some Pytorch code to Lightning. The dataset is loaded lazily by the train & eval dataloaders.
However, when moving the code to Lightning, I noticed a huge slowdown. After digging around, I noticed that there was a ~10 seconds delay between each epoch. For comparison, on my vanilla Pytorch, an epoch takes ~4s.
I first thought it was a data loading problem, but during the 10s delay, no data is loaded (at least that's what my print tell me).
I think the issue is related to the number of workers, because setting n_workers=0 solves the problem (but is slower in the end, since only one worker is not enough). I know starting workers is slow, however I have persistent_workers=True and this does not happen in normal Pytorch. My data loaders also have pin_memory=True (removing pin_memory does not solve the problem).
Since this is company code, I cannot disclose the before/after, but I'll try to "anonymize" some code if necessary. Here is the lightning module:
class RawModule(pl.LightningModule):
    def __init__(self):
        super(RawModule, self).__init__()

        self.encoder1 = nn.Sequential(...)
        self.encoder2 = nn.Sequential(...)

    def forward(self, data1, data2):
        result1 = self.encoder1(data1)
        result2 = self.encoder2(data2)

        result1 = result1 .view(result1 .size(0), -1)
        result2 = result2 .view(result2 .size(0), -1)

        result1 = F.normalize(result1 , p=2, dim=1)
        result2 = F.normalize(result2 , p=2, dim=1)

        return result1, result2

    def calculate_loss(self, batch):
        x, r, y = batch
        a, v = self.forward(r, x)

        d = nn.functional.cosine_similarity(a, v)
        loss = logloss(d.unsqueeze(1), y)

        return loss

class Module(RawModule):
    def training_step(self, batch, batch_idx):
        loss = self.calculate_loss(batch)
        self.log("train_loss", loss)
        return loss

    def validation_step(self, batch, batch_idx):
        loss = self.calculate_loss(batch)
        self.log("validation_loss", loss)
        return loss

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

if __name__ == '__main__':
    # stuff...

    train_loader = data_utils.DataLoader(
        train_dataset, batch_size=256, shuffle=True,
        num_workers=5, persistent_workers=True,
        pin_memory=True,
    )

    val_loader = data_utils.DataLoader(
        test_dataset, batch_size=256,
        num_workers=2, persistent_workers=True,
        pin_memory=True,
    )

    # Model
    load_from_pytorch = True

    if checkpoint_path is None:
        model = Module()

        if load_from_pytorch:
            if not checkpoint_path:
                raise ValueError("Please provide a checkpoint path")
            model.load_state_dict(torch.load(checkpoint_path)['state_dict'])
    else:
        model = Module.load_from_checkpoint(checkpoint_path)

    trainer = pl.Trainer(
        gpus=1,
        max_epochs=5,
        check_val_every_n_epoch=10,
        log_every_n_steps=5,
    )
    trainer.fit(model, train_loader, val_loader)

Here is the result of profiler="simple":
Action                                  |  Mean duration (s)    |Num calls              |  Total time (s)       |  Percentage %         |
----------------------------------------------------------------------------------------------------------------------------------------
Total                                   |  -                    |_                      |  48.813               |  100 %                |
----------------------------------------------------------------------------------------------------------------------------------------
run_training_epoch                      |  27.922               |1                      |  27.922               |  57.202               |
fetch_next_sanity_check_batch           |  4.4013               |3                      |  13.204               |  27.05                |
get_sanity_check_batch                  |  4.4013               |3                      |  13.204               |  27.05                |
fetch_next_train_batch                  |  1.2734               |10                     |  12.734               |  26.087               |
get_train_batch                         |  1.2734               |10                     |  12.734               |  26.087               |
run_training_batch                      |  0.47733              |9                      |  4.296                |  8.8009               |
optimizer_step_with_closure_0           |  0.40089              |9                      |  3.608                |  7.3915               |
validation_step                         |  0.664                |2                      |  1.328                |  2.7206               |
evaluation_step_and_end                 |  0.664                |2                      |  1.328                |  2.7206               |
training_step_and_backward              |  0.12644              |9                      |  1.138                |  2.3313               |
backward                                |  0.096889             |9                      |  0.872                |  1.7864               |
training_step                           |  0.029556             |9                      |  0.266                |  0.54494              |
model_forward                           |  0.029556             |9                      |  0.266                |  0.54494              |
on_train_start                          |  0.016                |1                      |  0.016                |  0.032778             |

Here is the result of profiler="advanced": https://pastebin.com/q3C5P826.
 I'm printing each piece of data loading, to prove it's not the issue.
https://user-images.githubusercontent.com/30944236/140587623-ae184fa3-370a-42be-8593-200026d11ba4.mp4
Random informations:

OS: Windows 10
CPU: AMD Ryzen 5 5600X 6 Core
GPU: Nvidia RTX 3070
Pytorch version: 1.10.0
Pytorch Lightning version: 1.5.0
Cuda version: 11.5
How did I install Pytorch: conda install pytorch torchvision torchaudio cudatoolkit=11.3 -c pytorch
Python 3.8

cc @tchaton @rohitgr7 @borda @akihironitta

After a lot of digging around, I managed to pin down the line causing the problem.
It's the line 142 in loops/epoch/training_epoch_loop.py :
self._dataloader_iter = _update_dataloader_iter(data_fetcher, self.batch_idx + 1)

Therefore, the culprit is:
def _update_dataloader_iter(data_fetcher: AbstractDataFetcher, batch_idx: int) -> Iterator:
    """Attach the dataloader."""
    if not isinstance(data_fetcher, DataLoaderIterDataFetcher):
        # restore iteration
        dataloader_iter = enumerate(data_fetcher, batch_idx)
    else:
        dataloader_iter = iter(data_fetcher)
    return dataloader_iter

It's indeed related to dataloaders, as expected. I still don't know what is the root reason, but I'll try to find it.

Just a guess, but maybe having a different number of workers between the training and validation step so it may be spinning up news workers and getting rid of them between epochs?
Try making the number of workers equal for both train and val dataloaders (5-6 based on your CPU).

Just a guess, but maybe having a different number of workers between the training and validation step so it may be spinning up news workers and getting rid of them between epochs?
Try making the number of workers equal for both train and val dataloaders (5-6 based on your CPU).

I just tried this, it does not solve the problem. It would have been weird IMO, since it does not cause any problem with vanilla Pytorch.

I see, that's interesting.  Like you said, It does seem to be a dataloading issue.  Maybe try removing
        check_val_every_n_epoch=10,
        log_every_n_steps=5

from the trainer call and explicitly set "reload_dataloaders_every_epoch=False" and see what happens.
Other than that, i'd try a fresh install of pytorch-lightning in a new venv.

I see, that's interesting. Like you said, It does seem to be a dataloading issue. Maybe try removing
        check_val_every_n_epoch=10,
        log_every_n_steps=5

from the trainer call and explicitly set "reload_dataloaders_every_epoch=False" and see what happens.
Other than that, i'd try a fresh install of pytorch-lightning in a new venv.

I just tried that, but it has no effect. The Trainer's methods _reset_eval_dataloader and reset_train_dataloader are never called (except once at the beginning), so it doesn't look like it's Lightning manually resetting the data loaders.
I just tried a fresh conda environment, but that didn't work either. I'm still trying to understand how the data loaders are getting reset, but I can't find anything really interesting yet.

I had a similar observation where data_fetcher caused unusual long run times. For me it was indeed fixed by completely disabling multiprocess dataloading (num_workers=0). Although, I have not tried to set "reload_dataloaders_every_epoch=False“. Interesting to see that others have the same issue/observation. Funnily, setting num_workers=0 has led me to open #10182. Perhaps, there is something more to this?

 I discovered the problem was that the _iterator property of the DataLoader was always set to None somewhere between epochs. When _iterator is None, the DataLoader is reseted and needs to start everything from scratch.
# Original DataLoader
class DataLoader(Generic[T_co]):
    def __iter__(self):
        if self.persistent_workers and self.num_workers > 0:
            if self._iterator is None:
                self._iterator = self._get_iterator()
            else:
                self._iterator._reset(self)
            return self._iterator
        else:
            return self._get_iterator()

# Custom DataLoader
class CustomDataLoader(DataLoader)
    def __iter__(self) -> '_BaseDataLoaderIter':
        print(f'\n> DataLoader __iter__ with {self._iterator=} starting.\n')
        return super().__iter__()

As you can see in the normal DataLoader, having self._iterator set to None causes a call to self._get_iterator(), which relaoads everything.
I decided to override _iterator with a custom property (getter & setter), to print the stack trace when ._iterator is set to None:
class CustomDataLoader(DataLoader)
    ...
   @property
    def _iterator(self):
        return self.__iterator

    @_iterator.setter
    def _iterator(self, value):
        if value is None:
            print('\nSetting __iterator to None. Stack trace:')
            import traceback
            traceback.print_stack()
        self.__iterator = value
        return self.__iterator

(I could also use the debugger for this)
This leads to 2 different yet very similar stack traces (respectively, evaluation & training loaders):
  File "env\lib\site-packages\pytorch_lightning\trainer\trainer.py", line 1370, in _run_sanity_check
    self._evaluation_loop.run()
  File "env\lib\site-packages\pytorch_lightning\loops\base.py", line 144, in run
    self.advance(*args, **kwargs)
  File "env\lib\site-packages\pytorch_lightning\loops\dataloader\evaluation_loop.py", line 109, in advance
    dl_outputs = self.epoch_loop.run(dataloader, dataloader_idx, dl_max_batches, self.num_dataloaders)
  File "env\lib\site-packages\pytorch_lightning\loops\base.py", line 139, in run
    self.on_run_start(*args, **kwargs)
  File "env\lib\site-packages\pytorch_lightning\loops\epoch\evaluation_epoch_loop.py", line 87, in on_run_start
    self._dataloader_iter = _update_dataloader_iter(data_fetcher, self.batch_progress.current.ready)
  File "env\lib\site-packages\pytorch_lightning\loops\utilities.py", line 121, in _update_dataloader_iter
    dataloader_iter = enumerate(data_fetcher, batch_idx)
  File "env\lib\site-packages\pytorch_lightning\utilities\fetching.py", line 198, in __iter__
    self.reset()
  File "env\lib\site-packages\pytorch_lightning\utilities\fetching.py", line 214, in reset
    CombinedLoader._shutdown_workers_and_reset_iterator(self.dataloader)
  File "env\lib\site-packages\pytorch_lightning\trainer\supporters.py", line 498, in _shutdown_workers_and_reset_iterator
    dataloader._iterator = None

  File "env\lib\site-packages\pytorch_lightning\trainer\trainer.py", line 1314, in _run_train
    self.fit_loop.run()
  File "env\lib\site-packages\pytorch_lightning\loops\base.py", line 144, in run
    self.advance(*args, **kwargs)
  File "env\lib\site-packages\pytorch_lightning\loops\fit_loop.py", line 234, in advance
    self.epoch_loop.run(data_fetcher)
  File "env\lib\site-packages\pytorch_lightning\loops\base.py", line 139, in run
    self.on_run_start(*args, **kwargs)
  File "env\lib\site-packages\pytorch_lightning\loops\epoch\training_epoch_loop.py", line 142, in on_run_start
    self._dataloader_iter = _update_dataloader_iter(data_fetcher, self.batch_idx + 1)
  File "env\lib\site-packages\pytorch_lightning\loops\utilities.py", line 121, in _update_dataloader_iter
    dataloader_iter = enumerate(data_fetcher, batch_idx)
  File "env\lib\site-packages\pytorch_lightning\utilities\fetching.py", line 198, in __iter__
    self.reset()
  File "env\lib\site-packages\pytorch_lightning\utilities\fetching.py", line 212, in reset
    self.dataloader.reset()
  File "env\lib\site-packages\pytorch_lightning\trainer\supporters.py", line 504, in reset
    apply_to_collection(self.loaders, DataLoader, self._shutdown_workers_and_reset_iterator)
  File "env\lib\site-packages\pytorch_lightning\utilities\apply_func.py", line 92, in apply_to_collection
    return function(data, *args, **kwargs)
  File "env\lib\site-packages\pytorch_lightning\trainer\supporters.py", line 498, in _shutdown_workers_and_reset_iterator
    dataloader._iterator = None

Well... We're nearly there. It looks like advancing 1 epoch calls self.reset() on the DataFetcher itself, which then resets the DataLoader and leads to our problem.
Indeed, when checking AbstractDataFetcher, we have this:
class AbstractDataFetcher(...):
    def __iter__(self) -> Generator[Tuple[Any, bool], None, None]:
        if self.dataloader is None:
            raise MisconfigurationException("The iterate hasn't been provided. HINT: Did you call setup function ?.")
-->     self.reset()
        self.dataloader_iter = iter(self.dataloader)
        self._apply_patch()
        self.prefetching(self.prefetch_batches)
        return self

# And iter(AbstractDataFetcher) is called here, in utilities.py:
def _update_dataloader_iter(data_fetcher: AbstractDataFetcher, batch_idx: int) -> Iterator:
    """Attach the dataloader."""
    if not isinstance(data_fetcher, DataLoaderIterDataFetcher):
        # restore iteration
-->     dataloader_iter = enumerate(data_fetcher, batch_idx)
    else:
        dataloader_iter = iter(data_fetcher)
    return dataloader_iter

So... I guess we found the problem? Each time a new epoch runs, it calls self.advance on the FitLoop/EvalLoop, which then calls self.on_run_start. on_run_start will create the _dataloader_iter (which is a normal behavior), which itself calls _update_dataloader_iter. This function, through enumerate, calls AbstractDataFetcher.__iter__ which calls self.reset(), entirely reloading the DataLoader.
Notice that self.reset() is also called in the __init__ method of AbstractDataFetcher, for setup purposes.
I just commented the self.reset() line of AbstractDataLoader, located at line 198 of pytorch_lightning/utilities/fetching.py.  I'll wait until the Lightning team fixes the problem before trying anything serious.
What a ride.

Nice find, I'm on an older version (1.3.7) with a project I'm working on and I can't find a "fetching.py" under utilities. It must be something fairly new, maybe it was meant to be inside a conditional for "reload_dataloaders_every_epoch".

Should have been fixed by #10434 which landed with the 1.5.1 release

Tested the new 1.5.1 release today, looks like performance is back on track. Thanks to everyone!

Dear @TheMrZZ,
Thanks for your investigation and hopefully we solved this ugly bug.
Best,
T.C

Hi everyone... This topic is very interesting as I'm striking the same issue.
I'm comparing the same implementation, in Torch and Lightning. I came across this post, so I noticed I was using the ancient Lightning 1.4.7, so I updated to 1.5.9. I repeated my test and nothing changed... Torch was still significantly faster than lightning.
So, as @TheMrZZ suggested, I commented reset in the __iter__ function, and repeated the test. Sure enough, Lightning was... lightning fast now!  I'm loading images so I got the following:

lightning (vanilla 1.5.9): 11 images/s, total runtime 407s
lightning (no mod): 108 images/s, total runtime 56s
torch (no mod): 40 images/s, total runtime 373s

Apparently, the performance issue has been fixed in 1.5.1, however, it seems that with 1.5.9 the reset line is still here. So, I'm curious, why do we need to reset the data fetcher, after each epoch?

@isvogor-foi Are you saying you are again experiencing this problem with version 1.5.9 but not 1.5.1?
If so, can you try the versions in-between and report back your findings?

@carmocca Hi, well, I didn't try 1.5.1, I tried only 1.4.7, and 1.5.9. I'll see whether I can try 1.5.1 and get back at you with this!

@carmocca Sure, vanilla - meaning, it's the one taken from official implementation:
Lightning: https://github.com/PyTorchLightning/pytorch-lightning/blob/master/pl_examples/domain_templates/imagenet.py
Torch: https://github.com/pytorch/examples/blob/master/imagenet/main.py
Try running those on the same device, with the same image dataset, batch size, etc. I've tried on my machine, AWS instance, even Colab, and Torch is always much better.

Sounds like this issue should be reopened

@amin-nejad I agree. @TheMrZZ shall we reopen?
@carmocca did you test?

Hi @isvogor-foi!
I had a look but I'm not observing any speed differences after commenting reset.
Can you describe exactly what changes are you making? Is the same behaviour reproducible in master?
You can also reach me in our Slack if you find that easier.

@carmocca This is very curious. Hmm... this is most curious, there should be some difference.
So it should take effect if you use at least 10k images, and multiple epochs, e.g. 50. It should be faster since the DataLoader will not be reset after the epoch, and recreated. This recreation is usually expensive. Do you know whether you're using the "fork" or "spawn" setting?

Here are some simple time results which shows Lightning being a bit faster:
PyTorch Lightning
real    1m24.267s
user    5m20.939s
sys     0m32.915s

Pytorch
real    1m52.581s
user    5m38.935s
sys     0m42.090s

For PyTorch Lightning I used https://github.com/PyTorchLightning/pytorch-lightning/blob/master/pl_examples/domain_templates/imagenet.py verbatim, called with
time python imagenet.py fit --model.data_path /home/imagenet/data --trainer.limit_train_batches=100 --trainer.limit_val_batches=0 --trainer.max_epochs=2

And for PyTorch, I used https://github.com/pytorch/examples/blob/master/imagenet/main.py with the following changes applied to disable validation, validation checkpointing, and stop at 100 batches:
249c249
<         acc1 = validate(val_loader, model, criterion, args)
---
>         #acc1 = validate(val_loader, model, criterion, args)
252,253c252,253
<         is_best = acc1 > best_acc1
<         best_acc1 = max(acc1, best_acc1)
---
>         is_best = False
>         best_acc1 = best_acc1
281a282,283
>         if i == 100:
>             break

time python torch_imagenet.py /home/imagenet/data --epochs=2

This was using 1 NVIDIA GeForce RTX 3090 and current PyTorch Lightning master, commit a34930b7721c88f9dc6c3af5824df0bc4960bda1

Here are some simple time results:
This was using 1 NVIDIA GeForce RTX 3090 and PyTorch Lightning 1.6.0dev, commit 8394770d4afa5480f881229b150ac44eaa8c41b0, torch==1.10.1, torchmetrics==0.7.0, torchvision==0.11.2, Python 3.8.12.
PyTorch Lightning
real    1m28.276s
user    5m29.551s
sys     0m34.544s

I used https://github.com/PyTorchLightning/pytorch-lightning/blob/master/pl_examples/domain_templates/imagenet.py verbatim, called with
time python imagenet.py fit --model.data_path /home/imagenet/data --trainer.limit_train_batches=100 --trainer.limit_val_batches=0 --trainer.max_epochs=2

Pytorch
real    1m29.662s
user    5m15.496s
sys     0m31.530s

I used https://github.com/pytorch/examples/blob/master/imagenet/main.py with the following changes applied to disable validation, and stop at 100 batches:
249c249
<         acc1 = validate(val_loader, model, criterion, args)
---
>         #acc1 = validate(val_loader, model, criterion, args)
252,253c252,253
<         is_best = acc1 > best_acc1
<         best_acc1 = max(acc1, best_acc1)
---
>         is_best = False
>         best_acc1 = best_acc1
281a282,283
>         if i == 100:
>             break

time python torch_imagenet.py /home/imagenet/data --epochs=2

So basically the same speed.

Hm... very interesting. I did the same with mnist example that comes in the lightning examples. And noticed that Torch was only slightly better in my case, a second or so.  However, I've just dismantled the advance call in training_epoch_loop.py. So the training loop is this:
with self.trainer.profiler.profile("run_training_batch"):
    batch_output = self.batch_loop.run(batch, batch_idx)

and before it, this part takes a lot of time:
  response = self.trainer.call_hook("on_train_batch_start", batch, batch_idx, **extra_kwargs)
  if response == -1:
      self.batch_progress.increment_processed()
      raise StopIteration

and after it there is another long call:
  self.trainer.call_hook("on_train_batch_end", batch_end_outputs, batch, batch_idx, **extra_kwargs)
  self.trainer.call_hook("on_batch_end")
  self.trainer.logger_connector.on_batch_end()

So, in my particular case, I was using lightning 1.5.9 with one V100, and the aforementioned hook calls seem to build up over time, so in my long experiment with 100 epochs, with 256 batch size, and 35k images Torch performs better. Using just 1 GPU. I didn't try multiple GPUs. I think we can leave it at that.
@carmocca thanks!

Just asking, how many gpu did you use? were you using colab?
Thx for answering?

Just asking, how many gpu did you use? were you using colab? Thx for answering?

Nothing fancy, just a single V100. As for colab, yep.. I also tried Colab. The results were similar, but I couldn't perform an extensive test, as Colab limits usage.

Occurred the same problem on pl 1.5.10...... I have to refactor my code using only pytorch...

@mayiran1999 Have you tried the 1.7.0 release?

I have similar issue with version 1.7.1 and torch 1.12.1+cu102 using more than one worker (3)
The trainer is taking few seconds before ending.

This issue appears to be back in the latest version of PyTorch Lightning (1.7.7), I was training the model on a rather small dataset so each epoch would take only ~1 min, but the trainer would take a ~1m40s pause between each epoch. Using torch 1.9.0+cu111.
It went away after downgrading to version 1.5.1

Can you provide a reproducible snippet? Alternatively, you could try git bisecting to find out which commit causes this

I'm also having this issue with num_workers=0, ddp with 4 GPUs, lightning 1.7.7 and torch 1.12.0. Interestingly, it only happens if I try to cache my entire dataset during the setup method of the datamodule, which takes up about 150 gigs out of 250. If I load data in on the fly (which is unfortunately much slower) there is no pause between epochs. The problem is not present in 1.6.5, but is there in 1.7.0 and above.

@carmocca I ran git bisect and this is what I get:
cd01856ffcbbf4d7b6dc494fef3d63cfc2eb6563 is the first bad commit
commit cd01856ffcbbf4d7b6dc494fef3d63cfc2eb6563
Author: Rohit Gupta<EMAIL_ADDRESS>Date:   Tue May 3 17:57:06 2022 +0530

    Add `LightningDataModule.load_from_checkpoint` to load datamodules directly from checkpoint (#12550)

    Co-authored-by: Carlos Mocholí<EMAIL_ADDRESS>    Co-authored-by: Jirka Borovec<EMAIL_ADDRESS>    Co-authored-by: otaj<EMAIL_ADDRESS>
 CHANGELOG.md                                       |   2 +
 docs/source/common/checkpointing_basic.rst         |   1 +
 pytorch_lightning/core/datamodule.py               |  76 +++++++-
 pytorch_lightning/core/saving.py                   | 214 ++++++++++++---------
 .../trainer/connectors/checkpoint_connector.py     |  20 +-
 tests/models/test_hparams.py                       |  99 +++++++---
 6 files changed, 279 insertions(+), 133 deletions(-)

Thank you. That is very helpful. cc @rohitgr7
Are you using self.save_hyperparameters()?

Yes I am using save hyperparameters. Happy to help!
On Sat, Oct 22, 2022 at 2:54 AM Carlos Mocholí @.***>
wrote:

Thank you. That is very helpful. cc @rohitgr7
https://github.com/rohitgr7
Are you using self.save_hyperparameters()?
—
Reply to this email directly, view it on GitHub
https://github.com/Lightning-AI/lightning/issues/10389#issuecomment-1287698434,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABHDTFJ2MEX4NYBHMANHCF3WEO2UPANCNFSM5HPZAV3A
.
You are receiving this because you commented.Message ID:
@.***>

@lminer this is not good. Can you share a reproducible script using BoringModel to check this issue?

I wouldn't know how to make this reproducible either, but I have pinned PL to 1.6.5 in my project because I observe the same behavior as @lminer on 1.7.* with very slow epochs. I also have very large memory usage, although I am using single gpu and I am not calling save_hyperparameters at all. Could there be other underlying factor?

okay... then there might be something wrong here. For starters, I'd suggest using a simple profiler (using profiler='simple' to test things out. Try turning of checkpointing completely (using enable_checkpoint_callback=False).
make sure to use limit_train_batches/limit_val_batches so that you don't have to wait for the whole dataset to complete. You can also just return from training_step/validation_step without doing any model computation :)

@rohitgr7  I think I've found the issue. Previously, I was passing the datasets into the LightningDataModule, running save_hyperparameters and then accessing them via self.hparams["train_dataset"], self.hparams.["validation_dataset"], etc. It seems as if the entire cached dataset was being cached in this case.
The fix is to explicitly make these modules instance variables and then run self.save_hyperparameters(ignore=["train_dataset", "validation_dataset", "test_dataset"])

great!
datasets are not hparams so you should be careful with what you are saving in them.
@jzazo is it a similar issue in your case as well? can you check your datamodule hparams?

I am not using datamodules, I am passing dataloaders directly to the trainer. I am also not using save_hyperparameters functionality. But I will check whatever I am attaching to the module in case there is any serialization happening. I will profile the training as well. I think I will have some time next week to verify this and I will report back.

@lminer You are correct, this is the right way to handle this when using save_hyperparameters().
@jzazo My recommendation is to check whether checkpointing is taking a long time (this happens between epochs). You could check by simply setting enable_checkpointing=False in the Trainer. Please fell free to report back in a new issue with your findings. Or ping us on slack if you need more guidance on debugging this.

Is this still fixed on 2.0.4? I'm still seeing this behavior. This code runs lightning fast (albeit with warnings about not having any workers):
    train_data_loader = DataLoader(
        NameDataset("data/training.csv", char_to_int),
        batch_size=TRAIN_BATCH_SIZE,
        shuffle=True,
        # num_workers=4,
    )
    eval_data_loader = DataLoader(
        NameDataset("data/eval.csv", char_to_int, debug=False),
        batch_size=TRAIN_BATCH_SIZE,
        shuffle=False,
        # num_workers=4,
    )

    lightning_model = PlContactEncoder(
        model, criterion, SIMILARITY_METRIC(0.5, return_distance=True), LEARNING_RATE
    )
    lightning_model.to(device)

    trainer = pl.Trainer(max_epochs=N_EPOCHS, max_steps=50)
    trainer.fit(
        model=lightning_model,
        train_dataloaders=train_data_loader,
        val_dataloaders=eval_data_loader,
    )
    ```

Adding the workers makes the warnings go away, but freezes ~15 seconds before validation or a new epoch:
```python
    train_data_loader = DataLoader(
        NameDataset("data/training.csv", char_to_int),
        batch_size=TRAIN_BATCH_SIZE,
        shuffle=True,
        num_workers=4,
    )
    eval_data_loader = DataLoader(
        NameDataset("data/eval.csv", char_to_int, debug=False),
        batch_size=TRAIN_BATCH_SIZE,
        shuffle=False,
        num_workers=4,
    )

    lightning_model = PlContactEncoder(
        model, criterion, SIMILARITY_METRIC(0.5, return_distance=True), LEARNING_RATE
    )
    lightning_model.to(device)

    trainer = pl.Trainer(max_epochs=N_EPOCHS, max_steps=50)
    trainer.fit(
        model=lightning_model,
        train_dataloaders=train_data_loader,
        val_dataloaders=eval_data_loader,
    )
    ```

Hi,
This issue still persists in 2.1.3. I'm directly passing the dataloaders to the Trainer
train_dataloader=DataLoader(train_dataset,batch_size=64,collate_fn=collate_fn_train,drop_last=True,shuffle=True,pin_memory=True,num_workers=8,prefetch_factor=8,persistent_workers=True,)
but the training freezes for a few seconds after each epoch. When I ran the advanced profiler in run_training_epoch, I saw that reset is called every epoch (dataloader.py:1086(_reset) and training_epoch_loop.py:143(reset)). The training is extremely slow if I set num_workers=0.
Is there a fix/workaround for this?

Is there any update on this? It seems like I'm not the only one facing this issue. I started using PTL since 2.x and would prefer not to downgrade to 1.5.1 to make this issue go away. Is there a 2.x version that doesn't have this issue?
@awaelchli @Borda @carmocca

This is indeed an issue with the latest version still... I have checked a few things such as persistent workers and so on and made a small comparison against vanilla PyTorch with a nested for loop and I can confirm "lightning" may be an inaccurate way to describe this library right now.

I think this issue should be reopened. I meet this problem with the pl version 2.0.3

This issue still exists in version 2.3.3.
With higher num_workers, the time between epochs is significantly longer. I tested the influence of saving checkpointing or hyperparameters and finds that these settings do not affect the runtime. The bug is the same as the initial finding which is caused by dataloader.
An easy fix can be setting num_workers=0 or add persistent_workers=True when instantiating dataloader.

I think this issue need to be reopened and fixed as soon as possible. @awaelchli

persistent_workers=True
did not actually worked around the issue when I was testing
On Wed, Jul 31, 2024 at 21:23 Jin Zehao @.***> wrote:

This issue still exists in version 2.3.3.
With higher num_workers, the time between epochs is significantly longer.
I tested the influence of saving checkpointing or hyperparameters and finds
that these settings do not affect the runtime. The bug is the same as the
initial finding which is caused by dataloader.
An easy fix can be setting num_workers=0 or add persistent_workers=True
when instantiating dataloader.

I think this issue need to be reopened and fixed as soon as possible.
@awaelchli https://github.com/awaelchli
—
Reply to this email directly, view it on GitHub
https://github.com/Lightning-AI/pytorch-lightning/issues/10389#issuecomment-2261886326,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAP5M3FKYTFCQBF73YGK6JLZPGS2PAVCNFSM5HPZAV3KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMRWGE4DQNRTGI3A
.
You are receiving this because you commented.Message ID:
@.***>

Hi, version v2.4 still has this issue, and the recommendations mentioned are not working.

Folks, I might have a solution.
TL;DR: use OMP_NUM_THREADS=1 MKL_NUM_THREADS=1
The problem stems from a combination of a weird torch default, using Slurm or some comparable scheduler tool without containerization, and large num_worker count.
By default, torch uses as many threads as possible for interop and intraop operations. This "as many" is determined by the number of CPU cores in your system (see here).
If you are using a scheduler such as Slurm, torch will think that you have access to all the CPUs in your machine (since the node resources are visible to the job) even if you have limited the number of cores allocated to the job. Therefore, e.g. in a 100-core node, torch will spawn hundreds of threads for each worker, suffocating your system.
The solution is to reduce the number of threads that torch can spawn using the above-mentioned environment variables (1 is not required, I believe, but keeping it somewhat close to the actual number of CPUs would be smart). Alternatively, use containerization, people. Don't let Slurm pull you into its evil ways.
In my experiments, this seems to resolve a couple deadlocks I have been hitting, and considerably improve the behavior for this particular issue. There is still some delay when switching between train and validation workers, which might be a bug on lightning side (verification needed), but at least the training is now manageable.
This might be the same issue as #4450, or pretty much most other non-reproducible performance issues in torch/lightning repos.

I tracked down my problem to evaluation_loop.py in PL.
This line of code iter(data_fetcher)  # creates the iterator inside the fetcher takes too much to run. I guess data_fetcher is culprit here.

in my case persistent_workers=True solved the issue

in my case persistent_workers=True solved the issue

Sounds good, would you give a try?

Still an issue in v2.4.0. persistent_workers=True, num_workers=0, and OMP_NUM_THREADS=1 MKL_NUM_THREADS=1 did not help

I noticed that decreasing number of model parameters from +100M to <3M resulted in a significant speedup, so I tried disabling checkpointing. This made the time between epochs basically 0.
# Copyright The Lightning AI team.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
from typing import Any

import torch
import torch.nn as nn
import torch.nn.functional as F
from torch import Tensor
from torch.utils.data import DataLoader, Dataset, Subset

from pytorch_lightning import LightningDataModule, LightningModule, Trainer
from pytorch_lightning.utilities.types import STEP_OUTPUT

from argparse import ArgumentParser

class RandomDataset(Dataset):
    """
    .. warning::  This is meant for testing/debugging and is experimental.
    """

    def __init__(self, size: int, length: int):
        self.len = length
        self.data = torch.randn(length, 1, size, size)

    def __getitem__(self, index: int) -> Tensor:
        return self.data[index]

    def __len__(self) -> int:
        return self.len

class BoringDataModule(LightningDataModule):
    """
    .. warning::  This is meant for testing/debugging and is experimental.
    """

    def __init__(self, size: int) -> None:
        super().__init__()
        self.length = 100
        self.random_full = RandomDataset(size=size, length=self.length)

    def setup(self, stage: str) -> None:
        n = self.length // 2
        self.random_train = Subset(self.random_full, indices=range(n))
        self.random_val = Subset(self.random_full, indices=range(n, 2 * n))

    def train_dataloader(self) -> DataLoader:
        return DataLoader(self.random_train,num_workers=16,persistent_workers=True)

    def val_dataloader(self) -> DataLoader:
        return DataLoader(self.random_val,num_workers=16,persistent_workers=True)

class DemoModel(LightningModule):
    """
    .. warning::  This is meant for testing/debugging and is experimental.
    """

    def __init__(self, dim: int = 10, size: int=32, learning_rate: float = 0.02):
        super().__init__()
        self.model = Net(dim=dim, size=size)
        self.learning_rate = learning_rate

    def forward(self, x: Tensor) -> Tensor:
        return self.model(x)

    def step(self, batch: Any, batch_nb: int) -> STEP_OUTPUT:
        x = batch
        x = self(x)
        return x.sum()

    def training_step(self, batch: Any, batch_nb: int) -> STEP_OUTPUT:
        return self.step(batch, batch_nb)

    def validation_step(self, batch: Any, batch_nb: int) -> STEP_OUTPUT:
        return self.step(batch, batch_nb)

    def configure_optimizers(self) -> torch.optim.Optimizer:
        return torch.optim.Adam(self.parameters(), lr=self.learning_rate)

class Net(nn.Module):
    """
    .. warning::  This is meant for testing/debugging and is experimental.
    """

    def __init__(self, dim, size) -> None:
        super().__init__()
        self.conv1 = nn.Conv2d(1, dim, 3, 1, 1)
        self.conv2 = nn.Conv2d(dim, 2 * dim, 3, 1, 1)
        self.dropout1 = nn.Dropout(0.25)
        self.dropout2 = nn.Dropout(0.5)
        self.fc1 = nn.Linear(dim // 2 * size * size, 128)
        self.fc2 = nn.Linear(128, 10)

    def forward(self, x: Tensor) -> Tensor:
        x = self.conv1(x)
        x = F.relu(x)
        x = self.conv2(x)
        x = F.relu(x)
        x = F.max_pool2d(x, 2)
        x = self.dropout1(x)
        x = torch.flatten(x, 1)
        x = self.fc1(x)
        x = F.relu(x)
        x = self.dropout2(x)
        x = self.fc2(x)
        return F.log_softmax(x, dim=1)

if __name__ == "__main__":
    parser = ArgumentParser()
    parser.add_argument("--dim", type=int, required=True)
    args = parser.parse_args()

    size = 32
    model = DemoModel(dim=args.dim, size=32)

    datamodule = BoringDataModule(size=size)
    trainer = Trainer(devices=1, max_epochs=2,enable_checkpointing=False)
    trainer.fit(model, datamodule=datamodule)

I noticed that decreasing number of model parameters resulted in a significant speedup in the time between epochs, so I tried disabling checkpointing. This made the time between epochs basically 0.
# Copyright The Lightning AI team.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
from typing import Any

import torch
import torch.nn as nn
import torch.nn.functional as F
from torch import Tensor
from torch.utils.data import DataLoader, Dataset, Subset

from pytorch_lightning import LightningDataModule, LightningModule, Trainer
from pytorch_lightning.utilities.types import STEP_OUTPUT

from argparse import ArgumentParser

class RandomDataset(Dataset):
    """
    .. warning::  This is meant for testing/debugging and is experimental.
    """

    def __init__(self, size: int, length: int):
        self.len = length
        self.data = torch.randn(length, 1, size, size)

    def __getitem__(self, index: int) -> Tensor:
        return self.data[index]

    def __len__(self) -> int:
        return self.len

class BoringDataModule(LightningDataModule):
    """
    .. warning::  This is meant for testing/debugging and is experimental.
    """

    def __init__(self, size: int) -> None:
        super().__init__()
        self.length = 100
        self.random_full = RandomDataset(size=size, length=self.length)

    def setup(self, stage: str) -> None:
        n = self.length // 2
        self.random_train = Subset(self.random_full, indices=range(n))
        self.random_val = Subset(self.random_full, indices=range(n, 2 * n))

    def train_dataloader(self) -> DataLoader:
        return DataLoader(self.random_train,num_workers=16,persistent_workers=True)

    def val_dataloader(self) -> DataLoader:
        return DataLoader(self.random_val,num_workers=16,persistent_workers=True)

class DemoModel(LightningModule):
    """
    .. warning::  This is meant for testing/debugging and is experimental.
    """

    def __init__(self, dim: int = 10, size: int=32, learning_rate: float = 0.02):
        super().__init__()
        self.model = Net(dim=dim, size=size)
        self.learning_rate = learning_rate

    def forward(self, x: Tensor) -> Tensor:
        return self.model(x)

    def step(self, batch: Any, batch_nb: int) -> STEP_OUTPUT:
        x = batch
        x = self(x)
        return x.sum()

    def training_step(self, batch: Any, batch_nb: int) -> STEP_OUTPUT:
        return self.step(batch, batch_nb)

    def validation_step(self, batch: Any, batch_nb: int) -> STEP_OUTPUT:
        return self.step(batch, batch_nb)

    def configure_optimizers(self) -> torch.optim.Optimizer:
        return torch.optim.Adam(self.parameters(), lr=self.learning_rate)

class Net(nn.Module):
    """
    .. warning::  This is meant for testing/debugging and is experimental.
    """

    def __init__(self, dim, size) -> None:
        super().__init__()
        self.conv1 = nn.Conv2d(1, dim, 3, 1, 1)
        self.conv2 = nn.Conv2d(dim, 2 * dim, 3, 1, 1)
        self.dropout1 = nn.Dropout(0.25)
        self.dropout2 = nn.Dropout(0.5)
        self.fc1 = nn.Linear(dim // 2 * size * size, 128)
        self.fc2 = nn.Linear(128, 10)

    def forward(self, x: Tensor) -> Tensor:
        x = self.conv1(x)
        x = F.relu(x)
        x = self.conv2(x)
        x = F.relu(x)
        x = F.max_pool2d(x, 2)
        x = self.dropout1(x)
        x = torch.flatten(x, 1)
        x = self.fc1(x)
        x = F.relu(x)
        x = self.dropout2(x)
        x = self.fc2(x)
        return F.log_softmax(x, dim=1)

if __name__ == "__main__":
    parser = ArgumentParser()
    parser.add_argument("--dim", type=int, required=True)
    args = parser.parse_args()

    size = 32
    model = DemoModel(dim=args.dim, size=32)

    datamodule = BoringDataModule(size=size)
    trainer = Trainer(devices=1, max_epochs=2,enable_checkpointing=False)
    trainer.fit(model, datamodule=datamodule)

In my case, it was not the data loader. It was that the Trainer writing model checkpoints to the disk. Setting lightning.Trainer(enable_checkpointing=False) solved thie issue for me.

I am having the same issue, delay is almost 5min between epochs with a 50M param model (~200MB). I am using 2.2.2


make Julia optional dependency

used python implementation if Julia isn’t installed but throw warning

use xr_bitround instead of jl_bitround

helps #95 and Julia installation issues

Continues #126

In the pangeo show case @rsignell-usgs also copied some code to not import xbitinfo due to julia

Just want to report here that the xbitinfo-python package worked nicely with the quick-start.ipynb: https://nbviewer.org/gist/7d297d9421f90bae38d69809f7028914
Great work guys!

Glad to hear that! We should adapt the README and mention the two different package versions there.


Missing document properties

colorSamplerList
countClass
compsList
numberOfGuides
selection
points
artboards
globalAngle
json
slicesVisibility
viewTransform
pageSetup
printSettings
rulerPoints

@jardicc I've added them all. For pageSetup and printSettings  I get an error when I try to fetch those with Alchemist, so I've set them to any for now. Do you know their exact type?
Also, I was wondering why these properties are hidden on the Document Descriptor..

Some are hidden because their existence is conditional. E.g. countClass will show only when you used the count tool. Others could be hidden for performance reasons and for the rest I don't know. Maybe someone did no though that he should add it :-D
I will look for pageSetup later.

The first reason is what i thought at first, too. But even when I had the specific thing active (counts, selection, ruler-line etc.) and logged a full document descriptor, they didn't show up. So I guess you have to directly ask for the property.
Oh and I forgot to ask: Is there even a rulerPoints property? The values are already stored in the points object I think.

@jardicc the points / rulerPoints still has me confused. I can now access the rulerPoints property, but the property name is actually points (shown in Alchemist's return). Accessing the points property gives me the "command currently not available" error.
Anways, I've added rulerPoints as an optional property.


[AIRFLOW-1332] Split logs based on try number

Dear Airflow maintainers,
Please accept this PR. I understand that it will not be reviewed until I have checked off all the steps below!
JIRA

[x] My PR addresses the following Airflow 1332 issues and references them in the PR title.

Description

[x] Here are some details about my PR, including screenshots of any UI changes:
This PR splits logs based on try number and add tabs to display different task instance tries.

Note this PR is a temporary change for separating task attempts. The code in this PR will be refactored in the future. Please refer to #2422 for Airflow logging abstractions redesign.
Tests

[x] My PR adds the following unit tests OR does not need testing for this extremely good reason:

Added unit tests.
Tested on localhost.
Tested on production environment with S3 remote storage, MySQL database, Redis, one Airflow scheduler and two airflow workers.

Commits

[x] My commits all reference JIRA issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

@aoen @saguziel

I'm not very enthusiastic out this. I don't really see the use case for it.

@bolkedebruin To give more context, please also refer to this PR: https://github.com/apache/incubator-airflow/pull/2380. This change is to enable us to display logs for each task retry/rerun in different tabs instead of one long document. The try_number / attempt is indeed confusing. Basically, it's a monotonically increasing field that keeps track of the number of times a certain task instance gets picked up and executed. In the future, it can be used as part of the name of the log file to separate each attempt.

Mmm still not convinced. Especially on elastic search it is just easier to use the start_date to shard on.
In addition I'm very against the managing of log files this way. Log files are already a mess and should be refactored to be consistent and to be managed from one place. The docker packagers can already not package airflow correctly without jumping through hoops. Arbitrarily naming it certainly does not help here.

@bolkedebruin I will send an email to airflow mailing list and let's move the discussion there :)

Perfect.

Is the code quality decrease in the landscape results a false positive?

@aoen lots of false positives. Not sure why code quality examines everything including things I didn't change.

Hi guys,
I see a lot of hard work and I understand what you are trying to accomplish. However, I do think you are trying to tackle too many things in on PR making it too big. In addition I would like to see a better design description. The commit and PR message do not describe why and what with reasoning. This makes it very hard to review.
Overall I think this PR needs to be split. I suggest splitting it into:

Add max_tries and attempt to task instances
(Question: is max_tries related to attempts or retries? Please make sure you name correctly and update documentation)

Move logging handling for TIs into logging.py

Obtain log per attempt per task instance in UI

This makes it more manageable and allows for tracking down issues/regressions per commit.

@bolkedebruin  First of all, I totally agree current logging mechanism is not ideal. Users should be able to setup their log handlers and not necessarily use the file handler. I also agree the PR has too many things. I will refactor the db migration part out of this PR.
In order to prioritize my tasks, I need a little bit more information. How urgent is to add customized log handler for each task instance? If this file directory approach is really not ideal, I can wait for the better approach to handle logging and focus more on #2380.

By false positives I meant more like the new errors it gives for the new code are not correct. Code quality will not say coverage decreased if you just move around code (it will say that you have X new errors in the new code and highlight them, but it will also say X errors were fixed from the old removed code).

I agree with Bolke, but refactoring can be quite hard and I don't think the win in commit granularity has huge value, if you think it won't be super hard to refactor this into 3 PRs then I would encourage it (let's say less than an hour of work), otherwise I think it's OK to leave it. Also I think there might be some coupling between the parts that Bolke outlined (e.g. logging has to be changed if we break logs up by attempt # anyways).
Let's also make sure to add the note about the lock required for DB migrations and the addition of dag parsing to DB migrations, and the non-backwards compatible log locations to the commit message as these are big changes.

Codecov Report

Merging #2383 into master will increase coverage by 0.01%.
The diff coverage is 44.76%.

@@            Coverage Diff             @@
##           master    #2383      +/-   ##
==========================================
+ Coverage   69.31%   69.32%   +0.01%
==========================================
  Files         146      146
  Lines       11242    11272      +30
==========================================
+ Hits         7792     7814      +22
- Misses       3450     3458       +8

Impacted Files
Coverage Δ

airflow/www/views.py
67.03% <10.52%> (-0.59%)
:arrow_down:

airflow/utils/dates.py
87.09% <100%> (+1.38%)
:arrow_up:

airflow/utils/logging.py
34% <100%> (+7.33%)
:arrow_up:

airflow/models.py
87.41% <100%> (+0.07%)
:arrow_up:

airflow/bin/cli.py
52.24% <58.82%> (+0.38%)
:arrow_up:

airflow/jobs.py
75.05% <0%> (-0.41%)
:arrow_down:

airflow/utils/state.py
96.66% <0%> (+10%)
:arrow_up:

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 3b863f1...0b75dba. Read the comment docs.

LGTM

One last issue I noticed in the landscape results:
def _get_log(self, ti, log_filename):
Unused argument 'ti'

@aoen I'm a bit surprised why this was merged. I my opinion the refactor Allison is doing should have been the one going in and it will soon. This one just creates new legacy and should not arrive in any release. What was the rush? If it was really needed you could have just used it in a local build?
Moreover it does not keep to the commit guidelines. With such a big change that really isn't nice.

This was merged by accident, my apologies for the confusion. I reverted it immediately. Allison had another similarly named PR and I had two tabs open and merged the wrong one.

@bolkedebruin I mentioned in the other thread (logging refactor) and didn't get any -1s so went ahead:

There is still a lot of work left here so we are going to spend a bit more time flushing out a design > doc for Airflow logging, and merge the initial change that we initially though should be blocked by > this one: #2383 (comment) . The reason being that although the PR above does make logging a > little bit messier, it makes the semantics of a logfile a lot more reasonable so it is still a net win. We > will continue to iterate on the Airflow logging design in parallel.
By messier I am referring to the other PR I referenced (#2383 (comment)), we are going to merge > that as is without blocking on this PR while continuing on this PR in parallel.

Ok I don't know if I agree with your assessment Airflow is better off this way. I wouldn't be very happy to have this in a release. But given the progress Allison is making with the other PR, one that I am willing to test, lets agree to disagree and help Allison as much as we can.
Concerning this PR I though it existed of two commits, but you probably squashed them. The '-' is minor. The description isn't really what/why, but more concerning is the lack of a documentation update as it does change things operationally. This can catch people by surprise as has happened with logging before.

Ok I don't know if I agree with your assessment Airflow is better off this way. I wouldn't be very happy to have this in a release. But given the progress Allison is making with the other PR, one that I am willing to test, lets agree to disagree and help Allison as much as we can.
I am happy to start a vote or discuss further with you via video chat if you feel it is important, please let me know. I believe pretty strongly in this change, but we should keep things democratic, and can revert the change based on the vote result. FWIW I did run this by Max early on, and he agreed with the change. In addition we created a thread in the mailing list to discuss these changes and hear people's concerns (though albeit not the slightly more complex logic that would be required on the logging side) since it was a decently-sized changed to the core.

Concerning this PR I though it existed of two commits, but you probably squashed them.
I think we should follow 1 commit to 1 PR as much as possible on master to keep history linear and sane (and so that the JIRA tags will be unique and match correctly). I also think that 1 commit was a reasonable granularity for this change. The reason I asked Allison to create a separate commit instead of force pushing was so that it would be easy for me to safely review the changes from the 1st commit to the 2nd commit (really the 2nd commit was just bug fixes on the first one).

The description isn't really what/why, but more concerning is the lack of a documentation update as it does change things operationally. This can catch people by surprise as has happened with logging before.
This is definitely true, I was operating on the precedent of previous logging changes not being communicated, but I agree this is not a good excuse. I have asked Allison to create a follow-up PR to add some additional details to the log section of the configuration.rst document. If there are additional kinds of communication you think are warranted please let me know.

@aoen No need to vote. Your judgement is as good as mine. I'm not happy with it, but the right fix, imho, is in progress. Let's work together on getting that one in.
On the PR squashing: I overlooked your squash that is what I meant to say. So the 'merge' was fine. Just some details with the PR itself that weren't as nice.


Remove last #filePath usage

Every other assertion function is using #file instead, which I think
will be preferred once SE-0274 is entirely rolled out.

@swift-ci please test

Thanks!


Fail to work on s390 in Debian

The source build but fail to work on s390 when built for Debian.  See https://buildd.debian.org/status/fetch.php?pkg=libelfin&arch=s390x&ver=0.2-5&stamp=1479224801 for the complete build log.  This is the error:
PASS dump-segments golden-gcc-4.9.2/example
FAIL dump-lines golden-gcc-4.9.2/example
	./test.sh: line 24: 24954 Aborted                 ../examples/dump-$dump golden-$compiler/$binary 1>&$output.out
	failed: exit status 134
	--- golden-gcc-4.9.2/lines	2016-09-28 18:00:31.000000000 +0000
	+++ /tmp/libelfin.iav8gPN88i.out	2016-11-15 15:46:34.004275388 +0000
	@@ -1,10 +1,2 @@
	---- <0>
	-x/example.c                                    2            0x4004b6
	-x/example.c                                    3            0x4004c2
	-x/example.c                                    4            0x4004c8
	-x/example.c                                    5            0x4004cd
	-x/example.c                                    6            0x4004eb
	-x/example.c                                    9            0x4004f2
	-x/example.c                                   10            0x400501
	-x/example.c                                   11            0x40050b
	-
	+terminate called after throwing an instance of 'dwarf::format_error'
	+  what():  unknown compilation unit version 1024
PASS dump-syms golden-gcc-4.9.2/example
FAIL dump-tree golden-gcc-4.9.2/example
	./test.sh: line 24: 24959 Aborted                 ../examples/dump-$dump golden-$compiler/$binary 1>&$output.out
	failed: exit status 134
	--- golden-gcc-4.9.2/tree	2016-09-28 18:00:31.000000000 +0000
	+++ /tmp/libelfin.iav8gPN88i.out	2016-11-15 15:46:34.012275388 +0000
	@@ -1,65 +1,2 @@
	---- <0>
	-<b> DW_TAG_compile_unit
	-      DW_AT_producer GNU C 4.9.2 -mtune=generic -march=x86-64 -g -fdebug-prefix-map=/home/amthrax/r/libelfin/test=x
	-      DW_AT_language 0x1
	-      DW_AT_name example.c
	-      DW_AT_comp_dir x
	-      DW_AT_low_pc 0x4004b6
	-      DW_AT_high_pc 0x57
	-      DW_AT_stmt_list <line 0x0>
	- <2b> DW_TAG_subprogram
	-       DW_AT_external true
	-       DW_AT_name fib
	-       DW_AT_decl_file 0x1
	-       DW_AT_decl_line 0x1
	-       DW_AT_prototyped true
	-       DW_AT_type <0x59>
	-       DW_AT_low_pc 0x4004b6
	-       DW_AT_high_pc 0x3c
	-       DW_AT_frame_base <exprloc>
	-       (DW_AT)0x2116 true
	-       DW_AT_sibling <0x59>
	-  <4c> DW_TAG_formal_parameter
	-        DW_AT_name x
	-        DW_AT_decl_file 0x1
	-        DW_AT_decl_line 0x1
	-        DW_AT_type <0x59>
	-        DW_AT_location <exprloc>
	- <59> DW_TAG_base_type
	-       DW_AT_byte_size 0x4
	-       DW_AT_encoding 0x5
	-       DW_AT_name int
	- <60> DW_TAG_subprogram
	-       DW_AT_external true
	-       DW_AT_name main
	-       DW_AT_decl_file 0x1
	-       DW_AT_decl_line 0x8
	-       DW_AT_prototyped true
	-       DW_AT_type <0x59>
	-       DW_AT_low_pc 0x4004f2
	-       DW_AT_high_pc 0x1b
	-       DW_AT_frame_base <exprloc>
	-       (DW_AT)0x2116 true
	-       DW_AT_sibling <0x9e>
	-  <81> DW_TAG_formal_parameter
	-        DW_AT_name argc
	-        DW_AT_decl_file 0x1
	-        DW_AT_decl_line 0x8
	-        DW_AT_type <0x59>
	-        DW_AT_location <exprloc>
	-  <8f> DW_TAG_formal_parameter
	-        DW_AT_name argv
	-        DW_AT_decl_file 0x1
	-        DW_AT_decl_line 0x8
	-        DW_AT_type <0x9e>
	-        DW_AT_location <exprloc>
	- <9e> DW_TAG_pointer_type
	-       DW_AT_byte_size 0x8
	-       DW_AT_type <0xa4>
	- <a4> DW_TAG_pointer_type
	-       DW_AT_byte_size 0x8
	-       DW_AT_type <0xaa>
	- <aa> DW_TAG_base_type
	-       DW_AT_byte_size 0x1
	-       DW_AT_encoding 0x6
	-       DW_AT_name char
	+terminate called after throwing an instance of 'dwarf::format_error'
	+  what():  unknown compilation unit version 1024
2 test(s) failed

Thank you very much for providing the self test in the code. It avoided uploading broken binaries to Debian. :)

Note, it failed on at least hppa and powerpc too.  See https://buildd.debian.org/status/package.php?p=libelfin&suite=unstable for a complete list.  Endian problem?

This issue is tracked as https://bugs.debian.org/844465 in Debian.

libelf++ supports non-native byte orders, but I never implemented this for libdwarf++. I'm not sure when I'll get around to this (patches welcome). However, a helpful first step someone else could do would be to build test/example.c on a big endian machine using gcc -g -fdebug-prefix-map=$PWD=x example.c (from test/golden-gcc-4.9.2/NOTES) and post the binary and gcc -v.

[Austin Clements]

libelf++ supports non-native byte orders, but I never implemented this
for libdwarf++. I'm not sure when I'll get around to this (patches
welcome). However, a helpful first step someone else could do would be
to build test/example.c on a big endian machine using gcc -g -fdebug-prefix-map=$PWD=x example.c (from
test/golden-gcc-4.9.2/NOTES) and post the binary and gcc -v.

Very glad to hear that this should work.  I ran the above command on the
s390x porter box in Debian.  This is gcc -v:
Using built-in specs.

--
Happy hacking
Petter Reinholdtsen

@petterreinholdtsen, I think this should do it, but can you test on a big endian machine? I was able to confirm that my little endian machine was able to process the big endian binary, which strongly suggests that this should work, but there could still be bugs.

[Austin Clements]

@petterreinholdtsen, I think this should do it, but can you test on a
big endian machine? I was able to confirm that my little endian
machine was able to process the big endian binary, which strongly
suggests that this should work, but there could still be bugs.

Thank you very much.
I can confirm that 'make check' now work on s390x:
(sid_s390x-dchroot)pere@zelenka:~/libelfin$ uname -a
Linux zelenka 3.16.0-4-s390x #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) s390x GNU/Linux
(sid_s390x-dchroot)pere@zelenka:~/libelfin$ make check
cd test && ./test.sh
PASS dump-sections golden-gcc-4.9.2/example
PASS dump-sections golden-gcc-6.2.1-s390x/example
PASS dump-segments golden-gcc-4.9.2/example
PASS dump-segments golden-gcc-6.2.1-s390x/example
PASS dump-lines golden-gcc-4.9.2/example
PASS dump-lines golden-gcc-6.2.1-s390x/example
PASS dump-syms golden-gcc-4.9.2/example
PASS dump-syms golden-gcc-6.2.1-s390x/example
PASS dump-tree golden-gcc-4.9.2/example
PASS dump-tree golden-gcc-6.2.1-s390x/example
(sid_s390x-dchroot)pere@zelenka:~/libelfin$
I hope you can make a new release soon with this change, and We'll get
it into Debian as soon as possible after this.
--
Happy hacking
Petter Reinholdtsen

Btw, looking at the code and the files in test/golden-gcc-*/ make me suspect the test will fail when a new compiler show up or for all architectures that do not have its own directory there.  Is this correct?  There are as mentioned earlier several big endian architectures in Debian, and I worry that the current fixes only make the s390x build work, while the others will keep failing.

I hope you can make a new release soon with this change, and We'll get
it into Debian as soon as possible after this.

Release v0.3 created.

Btw, looking at the code and the files in test/golden-gcc-*/ make me suspect the test will fail when a new compiler show up or for all architectures that do not have its own directory there. Is this correct?

No, this shouldn't be a problem. For example, I ran the 6.2.1-s390x tests on my x86 machine that doesn't have GCC 6.2.1. Since the test binaries are already made, it doesn't matter what architecture is running them or what compilers are available.

[Austin Clements]

Release v0.3 created.

Thank you.  It is now uploaded to Debian.

No, this shouldn't be a problem. For example, I ran the 6.2.1-s390x
tests on my x86 machine that doesn't have GCC 6.2.1. Since the test
binaries are already made, it doesn't matter what architecture is
running them or what compilers are available.

You are absolutely right.  The automatic builds confirm that the patch
get the code working on all Debian architectures.  You can check the
status on <URL: https://tracker.debian.org/pkg/libelfin >.
Happy hacking
Petter Reinholdtsen


How can i customize the style? I've already tried the mycomponent.component.css file and nothing.

I had same problem

I also have this problem. Any luck, @finzaiko or @BCaldas ?

@meetmicah sadly, nothing here =(. We solved this probleam editing the component css and versioning it on our repository.

It seems be the only way, since third-party components css always ovewrite yours component css.

I inspect and overwrite the css

@finzaiko how r u doing it? I tried so much with no success. Can u show me a example?

Has anyone tried ng-style ?


iPhone 6 support?

Will this work on an iPhone 6?

Please search existing issues before you post anything.
Read here


Failed to execute 'querySelector' on 'Document' (in load's fetch)

Describe the bug
When using fetch in load and the url contains double quotes (", haven't tested other special characters/symbols yet) it gives the following error (500):
Failed to execute 'querySelector' on 'Document': 'script[type="svelte-data"][url="<my_api_url>/apiv2/trips/trip_templates?$filter={"d":0}&$order_by=id&$direction=DESC"]' is not a valid selector.

Error: Failed to execute 'querySelector' on 'Document': 'script[type="svelte-data"][url="<my_api_url>/apiv2/trips/trip_templates?$filter={"d":0}&$order_by=id&$direction=DESC"]' is not a valid selector.
    at initial_fetch (http://localhost:1111/.svelte/dev/runtime/internal/start.js:353:26)
    at send (http://localhost:1111/src/lib/helpers/api.ts:15:10)
    at Module.get (http://localhost:1111/src/lib/helpers/api.ts:37:10)
    at load (http://localhost:1111/src/routes/templates/index.svelte?import:585:30)
    at Renderer._load_node (http://localhost:1111/.svelte/dev/runtime/internal/start.js:785:37)
    at Renderer.start (http://localhost:1111/.svelte/dev/runtime/internal/start.js:452:29)
    at async start (http://localhost:1111/.svelte/dev/runtime/internal/start.js:1022:15)

To Reproduce
Try a fetch (https://kit.svelte.dev/docs#loading-input-fetch) in load with a double quite in the query parameters, like fetch('<my_api_url>/apiv2/trips/trip_templates?$filter={"d":0}&$order_by=id&$direction=DESC')
Expected behavior
Load data from the requested source.
Severity
I was able to solve it with an additional encodeURIComponent('$filter={"d":0}') and it worked, but it would be nice if we didn't have to this.

I'm not getting the error in the latest SvelteKit version anymore, perhaps it has been resolved after upgrading node-fetch.


MAINT: special version hex cleanup

Just poking around after gh-20373, I think this can be removed now from scipy/special/ufunc.h:
#if (PY_VERSION_HEX < 0x030a00f0)
// This function is standard in Python >=3.10, we just add it here for convenience.
inline int PyModule_AddObjectRef(PyObject *module, const char *name, PyObject *value) {
    Py_INCREF(value);
    return PyModule_AddObject(module, name, value);
}
#endif

Not sure if the C++ stuff just makes it all obsolete anyway. That's the last remaining usage of PY_VERSION_HEX we have.

Just poking around after gh-20373, I think this can be removed now from scipy/special/ufunc.h:
#if (PY_VERSION_HEX < 0x030a00f0)
// This function is standard in Python >=3.10, we just add it here for convenience.
inline int PyModule_AddObjectRef(PyObject *module, const char *name, PyObject *value) {
    Py_INCREF(value);
    return PyModule_AddObject(module, name, value);
}
#endif

Not sure if the C++ stuff just makes it all obsolete anyway. That's the last remaining usage of PY_VERSION_HEX we have.

Oh, ok, great! I literally just put that in a couple of weeks ago, but if we are now on Python 3.10 then good stuff.

I have removed this in https://github.com/scipy/scipy/pull/20403.


Feature: Store chat history in Cosmos DB

Purpose
This PR extends the chat history feature added in #1988 to store chat history server-side (Cosmos DB) when user authentication is enabled.
Does this introduce a breaking change?
When developers merge from main and run the server, azd up, or azd deploy, will this produce an error?
If you're not sure, try it out on an old environment.
[ ] Yes
[x] No

Does this require changes to learn.microsoft.com docs?
This repository is referenced by this tutorial
which includes deployment, settings and usage instructions. If text or screenshot need to change in the tutorial,
check the box below and notify the tutorial author. A Microsoft employee can do this for you if you're an external contributor.
[ ] Yes
[x] No

Type of change
[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[ ] Other... Please describe:

Code quality checklist
See CONTRIBUTING.md for more details.

[x] The current tests all pass (python -m pytest).
[ ] I added tests that prove my fix is effective or that my feature works
[ ] I ran python -m pytest --cov to verify 100% coverage of added lines
[x] I ran python -m mypy to check for type errors
[x] I either used the pre-commit hooks or ran ruff and black manually on my code.

Woot! I know this is a very popular request, thanks for the PR, I'll review it this week. In the meantime, if anyone subscribed tries it out as well, please report on the PR with your feedback as well. I'll also ask Cosmos DB team to take a look.

I'm reviewing now, have made a few cosmetic changes and added a test. I'll add a few more tests tomorrow and test my deploy. Have also asked a Cosmos DB colleague to review.

Update: I found an issue with the authentication decorator being used for the /items/id get and delete routes and have fixed it. It's working well for me locally now.
I'll add additional pytests tomorrow.

@fujita-h I added pytest for 97% coverage of CosmosDB. While adding the tests, I made a few changes:

400 instead of 405 for CosmosDB feature disabled (I think 405 is meant to specifically indicate that a different HTTP method would have worked, but none would work in this case)
204 instead of 200 for successful item deletion, as that seems to be the web convention
Removed the check in the "/item_id" paths for "if not item_id" as I don't think there's any possible way to reach that code path- if no item_id is specified, it won't match the route and will 404 instead.

@pamelafox Thank you for adding the test, I have read and understood your corrections.

I looked at the Bicep validation error but I think that is an unrelated issue, likely due to a newer version of Bicep that's stricter.


Add proper OAuth support to the API

Support the creation and management of tokens via the JWT standard.

So the changes with the API Auth handling allows for custom auth handlers, this would be to write a default, configurable handler for OAuth.


Fix broken TLS tests

brew was removed from $PATH on Ubuntu runners, see https://github.com/actions/runner-images/issues/6283.

I guess an option is to try to make use of the the pre-built binaries (https://github.com/FiloSottile/mkcert#linux) instead, but this was the simplest solution. It adds approximately 20 seconds though, not too terrible IMHO.


gcov: accommodate the execution_count format change in GCC 8.1

The format of gcov's execution_count has been extended to indicate any
unexecuted blocks in a single line, with a following '*':
https://github.com/gcc-mirror/gcc/commit/3cf7fddf54b5160e83236f1b9b3129e2a3a417c6
This confuses cpp-coveralls and leads to a parsing error:
Traceback (most recent call last):
[...]
    coverage.append(int(cov_num))
ValueError: invalid literal for int() with base 10: '2*'

Is this related to #126?

The Travis build error is unrelated to this change
https://travis-ci.org/eddyxu/cpp-coveralls/jobs/397341693#L491
RuntimeError: cryptography requires setuptools 18.5 or newer, please upgrade to a newer version of setuptools
which only happens on Python 3.3
This change passes on Python 2.7, 3.4, 3.5, and pypy.

Thanks for providing the link to the upstream change, merging now as it seems safe.
Ideally we should add some unit testing (using example gcov outputs), but such is life.


Release Event Hubs March 2020 update for JavaScript

This is a parent issue tracking the work planned for Event Hubs for the March update.
Code complete date: March 6th, 2020
API design

[ ] In Progress Propose smarter send APIs such that the user doesnt have to one by one fill the EventDataBatch to be able to send events
[ ] In Progress Propose API to control greedy claiming of partitions by the Event Processor

Features

[x] Code sample showing how to convert IotHub connection string to an Event Hubs compatible one which points to the built-in Event Hubs endpoint
[ ] In Progress Receiver Redirect feature
[ ] In Progress Review current logging experience, come up with a plan to streamline and be consistent across languages for ease of customer support, tackle low hanging fruits

Testing

[x] Test Event Hubs and Storage Blob checkpoint store in Azure Stack

cc @chradek, @richardpark-msft

Pending tasks have been moved to the April update as tracked in #7783
The March update for Event Hubs is version 5.0.2
Read the Changelog for details.


ARMNN prepare API takes lot of time when using GPU

Dear team,
I try to run mobilenetv2 model using ARMNN , but the prepare API for GPU target  take 10 times more time than the CPU target
Tiime taken by ARMNN CPU to prepare : 992ms
ARMNN GPU : 9607ms
Tiime taken by opensource tflite CPU plugin : 44ms
Could you let me know what could be the root cause?
Does the pipline creation takes more time?
I need to review the usage of the ARMNN further for our  Use case
, but in case prepare takes lot of time then i need an understanding about it.

Hi @abhajaswal
The preparation time for CPU and GPU includes time taken to compile the kernels used by those backends. This can be quite time consuming but only occurs once.
Yesterday @morgolock gave some more information on the issue you raised on ComputeLibrary:
https://github.com/ARM-software/ComputeLibrary/issues/977
Best regards,
Mike

Thanks Mike , I will check this. You can close the issue from here  I think , as the improvements would be seen on ARMNN automatically  once ACL side optimizations are done


Flow typed

How do you feel about adding Flow to this project? Could even add inline comments while doing this so docs can be generated later.
We could even take it a step further and remove PropTypes in favor of just Flow with babel-plugin-react-flow-props-to-prop-types.

Can I work on this ? (PR) I've used Flow earlier!

having a type system makes it easy to understand the codebase rather than increasing verbosity @kentcdodds

I'm not worries about increased verbosity. I'm worried about familiarity for beginners. But maybe that concern is overblown and it won't be bad. Feel free to submit a pull request. Thanks!

Awesome!!

I'll tell you what. If we can add a short intro and links to resources in the CONTRIBUTING.md, then I say let's go for adding flow to the project :+1:

Intro and links about setting up Flow or ?

Intro and links about the basics of what Flow is and the syntax. Everything someone would need to know to contribute to a flow codebase for the first time.

Could just be a link to a blog post.

Sure! I'll add a section for Flow in the CONTRIBUTING.md 👍

Hi All,
I see that the PR for this added a .flow.js file which is awesome, but what about actually adding types to the code itself? It would make code changes a lot safer since you would have static type checking and there would be one type definition less to maintain, since it can be automatically generated?

Hey @vejersele! I've definitely considered adding flow to my libraries. My main concern is that it will hinder contributions because folks who are unfamiliar with flow will have a hard time contributing....

If the source code itself is going to be typed then TypeScript should be also evaluated. I am biased towards TypeScript, so I will stay out of the discussion. Just reminding about the options. 😊
The feature sets on both type systems are more than enough.
What should be evaluated then?

activity on 3rd party library definition creation TS & Flow
tooling
which libraries have taken the TypeScript/Flow to the internals

Thanks for chiming in @ttamminen.
So long as I'm a maintainer on this project, it's very unlikely I'll choose TS over Flow. I don't have time to go into it, but just know that if I do add types, it'll be flow, not TypeScript.

I'll start working on the Flow definition files (busy with some personal work). @ttamminen thanks for your suggestion but let's avoid adding types to the codebase and keep it minimal and clean. Also, let's not forget about the other contributors who are yet not comfortable with the JavaScript toolchain (Flow, TypeScript, etc). I remember, I started adding types to the codebase (downshift) but it affected the readability so we went with the option of creating the type declaration files instead.
How you can help ?
I'll continue to work on the Flow PR (type declaration file) and you can collaborate with me. You can also check its progress here #180

Hi. Everybody who want to participate are welcome to comment on this PR https://github.com/paypal/downshift/pull/399. Thank you

@dashed they are merged in next branch and will be released as part of v2.0

<EMAIL_ADDRESS>will be released soon with this! Thanks @stereobooster!
Learn more: #461


Enhancements/Fixes

Address issue #3 #41  LinkedIn Messaging now hides names/photos
Address issue #7 Github now supported
Address issue #8 Meetup now supported
Address issue #47 #48 #49

Pulled the code locally, and I don't think Github names are working.

Made a commit for Github Profile names.

I'm sorry I let this get so stale - I really want to thank you for your contributions to project this is great.
For future contributions, I'd suggest disabling your autoformatters if they don't match the existing format in the code to avoid massive diffs. I'll look through this and hopefully we'll get it in and life this week.

I really want to thank you for all this work once again; this is all wonderful stuff 🙌
If you choose to help the project out in the future, it'd be great to have separate prs for each ticket, but this was great! Thanks again!


Change DB interface

https://github.com/kotakanbe/go-cve-dictionary/blob/master/db/db.go#L19-L20
In the current implementation, DB Error is only logging.
It's better to return an error.

#75


Provide Intel compiler triplet

Due to https://www.scivision.dev/intel-oneapi-fortran-install/
there should be an Intel community triplet.

Related #15053.


Atomic Batch Ingestion: Add an api to replace multiple segments

When uploading offline segments it would be useful to have an api that can take a list of old segments and replace them with a list of new segments. This can be useful for lambda architecture where data for an entire day/hour is replaced atomically.

This can be done with the segment lineage feature contributed by @snleee. Do we have some user doc for this @snleee?

Added #7813. Let's move the discussion there.


Page for extending AutoFixture

Fixes #30

@zvirja I'd love to hear your thoughts on this page. Specifically, I had some issues with the part regarding the behaviors as I have never really worked with them.


Cannot read new protein_domains.RDs file

Issue
I have recently requested the protein domains for FAM205A and as far as I am aware, the protein_domains.RDs file has been updated with this gene/protein. But I cannot read the new protein_domains.RDs file. I think there is a problem with this .RDs file as I can read other .RDs files by running readRDS(). Here is the command and error message:
Command
# Replace previous protein_domains.RDs file with updated one
domain_data_src = system.file('extdata', 'protein_domains.RDs', package = 'maftools')
download.file(url = "https://github.com/PoisonAlien/maftools/raw/master/inst/extdata/protein_domains.RDs",
destfile = domain_data_src)

# Run lollipopPlot using maftools
lollipopPlot(maf = all_genes_ged_maf, gene = 'FAM205A', AACol = 'HGVSp', labelPos = 'all', legendTxtSize = 1,
             showMutationRate = TRUE,showDomainLabel = F,pointSize = 3, labPosSize = 1.1,labPosAngle = 90, cBioPortal = T,
             defaultYaxis = T)

Error in readRDS(file = gff) : error reading from connection

Session info
R version 4.0.5 (2021-03-31)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 18363)

Matrix products: default

locale:
[1] LC_COLLATE=English_United Kingdom.1252  LC_CTYPE=English_United Kingdom.1252    LC_MONETARY=English_United Kingdom.1252
[4] LC_NUMERIC=C                            LC_TIME=English_United Kingdom.1252

attached base packages:
 [1] parallel  stats4    grid      stats     graphics  grDevices utils     datasets  methods   base

other attached packages:
 [1] BSgenome_1.58.0      rtracklayer_1.49.5   Biostrings_2.58.0    XVector_0.30.0       GenomicRanges_1.42.0 GenomeInfoDb_1.26.7  IRanges_2.24.1
 [8] S4Vectors_0.28.1     BiocGenerics_0.36.1  ComplexHeatmap_2.6.2 maftools_2.6.05      KEGGREST_1.30.1      BiocManager_1.30.15  rstatix_0.7.0
[15] RColorBrewer_1.1-2   scales_1.1.1         colorspace_2.0-1     ggpubr_0.4.0         cluster_2.1.2        scatterplot3d_0.3-41 forcats_0.5.1
[22] stringr_1.4.0        dplyr_1.0.6          purrr_0.3.4          readr_1.4.0          tidyr_1.1.3          tibble_3.1.2         ggplot2_3.3.3
[29] tidyverse_1.3.1

loaded via a namespace (and not attached):
 [1] bitops_1.0-7                matrixStats_0.59.0          fs_1.5.0                    lubridate_1.7.10            httr_1.4.2
 [6] tools_4.0.5                 backports_1.2.1             utf8_1.2.1                  R6_2.5.0                    DBI_1.1.1
[11] GetoptLong_1.0.5            withr_2.4.2                 tidyselect_1.1.1            curl_4.3.1                  compiler_4.0.5
[16] Biobase_2.50.0              cli_2.5.0                   rvest_1.0.0                 Cairo_1.5-12.2              xml2_1.3.2
[21] DelayedArray_0.16.3         Rsamtools_2.6.0             digest_0.6.27               foreign_0.8-81              rio_0.5.26
[26] pkgconfig_2.0.3             MatrixGenerics_1.2.1        dbplyr_2.1.1                rlang_0.4.11                GlobalOptions_0.1.2
[31] readxl_1.3.1                rstudioapi_0.13             shape_1.4.6                 generics_0.1.0              jsonlite_1.7.2
[36] BiocParallel_1.24.1         zip_2.2.0                   car_3.0-10                  RCurl_1.98-1.3              magrittr_2.0.1
[41] GenomeInfoDbData_1.2.4      Matrix_1.3-3                Rcpp_1.0.6                  munsell_0.5.0               fansi_0.5.0
[46] abind_1.4-5                 lifecycle_1.0.0             stringi_1.6.2               carData_3.0-4               SummarizedExperiment_1.20.0
[51] zlibbioc_1.36.0             crayon_1.4.1                lattice_0.20-44             haven_2.4.1                 splines_4.0.5
[56] circlize_0.4.12             hms_1.1.0                   pillar_1.6.1                rjson_0.2.20                ggsignif_0.6.1
[61] XML_3.99-0.6                reprex_2.0.0                glue_1.4.2                  data.table_1.14.0           modelr_0.1.8
[66] png_0.1-7                   vctrs_0.3.8                 cellranger_1.1.0            gtable_0.3.0                clue_0.3-59
[71] assertthat_0.2.1            xfun_0.23                   openxlsx_4.2.3              broom_0.7.6                 survival_3.2-11
[76] GenomicAlignments_1.26.0    tinytex_0.32                ellipsis_0.3.2

Hi,
You can just reinstall the package from GitHub or Bioconductor. It has been updated.

Hi,
I'm having trouble reinstalling the latest version of maftools either from GitHub or Bioconductor (it installs version 2.6.05 instead).
But I downloaded the protein_domains.RDs from the Bioconductor/maftools.2.8.0.tar.gz and it works fine now! Thanks!


Upgraded xterm.js to 2.2.3

Fix for #2121
New messages to stdout should no longer scroll down to the bottom.
@foot Please review.

I couldn't get this going: I think this build process has changed a bit on the way to 2.2.3, code w/ require()s in it ends up in the browser, I had a little fiddle w/ webpack but no luck yet!

@foot I added a more specific regex to the webpack config noParse field. It should resolve that require problem. Could you try again please?

oh no, did you push up that webpack conf change or did i smush it w/ a push -f?

@foot It came over in a rebase. It won't show in the diff, but it should show in the src

Nice!
I was getting lots of warnings[0] when running npm run build so I fiddled w/ webpack.prod until they went away WDYT?
[0]
WARNING in ./~/xterm/lib/addons/terminado/terminado.js.map
Module parse failed: /Users/simon/weave/src/github.com/weaveworks/scope/client/node_modules/xterm/lib/addons/terminado/terminado.js.map Unexpected token (1:10)
You may need an appropriate loader to handle this file type.
SyntaxError: Unexpected token (1:10)
    at Parser.pp$4.raise (/Users/simon/weave/src/github.com/weaveworks/scope/client/node_modules/webpack/node_modules/acorn/dist/acorn.js:2221:15)
    at Parser.pp.unexpected (/Users/simon/weave/src/github.com/weaveworks/scope/client/node_modules/webpack/node_modules/acorn/dist/acorn.js:603:10)
    at Parser.pp.semicolon (/Users/simon/weave/src/github.com/weaveworks/scope/client/node_modules/webpack/node_modules/acorn/dist/acorn.js:581:61)
    at Parser.pp$1.parseExpressionStatement (/Users/simon/weave/src/github.com/weaveworks/scope/client/node_modules/webpack/node_modules/acorn/dist/acorn.js:966:10)
    at Parser.pp$1.parseStatement (/Users/simon/weave/src/github.com/weaveworks/scope/client/node_modules/webpack/node_modules/acorn/dist/acorn.js:730:24)
    at Parser.pp$1.parseBlock (/Users/simon/weave/src/github.com/weaveworks/scope/client/node_modules/webpack/node_modules/acorn/dist/acorn.js:981:25)
    at Parser.pp$1.parseStatement (/Users/simon/weave/src/github.com/weaveworks/scope/client/node_modules/webpack/node_modules/acorn/dist/acorn.js:709:33)
    at Parser.pp$1.parseTopLevel (/Users/simon/weave/src/github.com/weaveworks/scope/client/node_modules/webpack/node_modules/acorn/dist/acorn.js:638:25)
    at Parser.parse (/Users/simon/weave/src/github.com/weaveworks/scope/client/node_modules/webpack/node_modules/acorn/dist/acorn.js:516:17)
    at Object.parse (/Users/simon/weave/src/github.com/weaveworks/scope/client/node_modules/webpack/node_modules/acorn/dist/acorn.js:3098:39)
    at Parser.parse (/Users/simon/weave/src/github.com/weaveworks/scope/client/node_modules/webpack/lib/Parser.js:902:15)
    at NormalModule.<anonymous> (/Users/simon/weave/src/github.com/weaveworks/scope/client/node_modules/webpack/lib/NormalModule.js:104:16)
    at NormalModule.onModuleBuild (/Users/simon/weave/src/github.com/weaveworks/scope/client/node_modules/webpack-core/lib/NormalModuleMixin.js:310:10)
    at nextLoader (/Users/simon/weave/src/github.com/weaveworks/scope/client/node_modules/webpack-core/lib/NormalModuleMixin.js:275:25)
    at /Users/simon/weave/src/github.com/weaveworks/scope/client/node_modules/webpack-core/lib/NormalModuleMixin.js:259:5
    at Storage.finished (/Users/simon/weave/src/github.com/weaveworks/scope/client/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:38:16)
    at /Users/simon/weave/src/github.com/weaveworks/scope/client/node_modules/graceful-fs/graceful-fs.js:78:16
    at FSReqWrap.readFileAfterClose [as oncomplete] (fs.js:416:3)
 @ ./~/xterm/lib/addons ^\.\/.*$

Terminal seems to work okay with or without the warnings fix though.

My change was to the noParse field, but I think it effectively did the same thing as yours. I checked that npm run build and npm run build-external both run without warnings. Also, no warnings in the browser.


[Event Request] Database::"Sales Header" - Field "Prepmt. Payment Terms Code" - OnValidatePaymentTermsCodeOnBeforeValidatePrepaymentDueDate

We need an event "OnValidatePaymentTermsCodeOnBeforeValidatePrepaymentDueDate" on field "Prepmt. Payment Terms Code" (as for field "Payment Terms Code"):
field(139; "Prepmt. Payment Terms Code"; Code[10])
{
    Caption = 'Prepmt. Payment Terms Code';
    TableRelation = "Payment Terms";

    trigger OnValidate()
    var
        PaymentTerms: Record "Payment Terms";
        IsHandled: Boolean;
    begin
        if ("Prepmt. Payment Terms Code" <> '') and ("Document Date" <> 0D) then begin
            PaymentTerms.Get("Prepmt. Payment Terms Code");
            if IsCreditDocType() and not PaymentTerms."Calc. Pmt. Disc. on Cr. Memos" then begin
                //>>>>>>>>>>>>>>>>>>>>>>>> NEW CODE START <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<///
                IsHandled := false;
                OnValidatePaymentTermsCodeOnBeforeValidatePrepaymentDueDate(Rec, xRec, CurrFieldNo, IsHandled);
                if not IsHandled then
                //>>>>>>>>>>>>>>>>>>>>>>>> NEW CODE END <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<///
                    Validate("Prepayment Due Date", "Document Date");
                Validate("Prepmt. Pmt. Discount Date", 0D);
                Validate("Prepmt. Payment Discount %", 0);
            end else begin
                IsHandled := false;
                OnValidatePaymentTermsCodeOnBeforeCalcDueDate(Rec, xRec, FieldNo("Prepmt. Payment Terms Code"), CurrFieldNo, IsHandled);
                if not IsHandled then
                    "Prepayment Due Date" := CalcDate(PaymentTerms."Due Date Calculation", "Document Date");
                IsHandled := false;
                OnValidatePaymentTermsCodeOnBeforeCalcPmtDiscDate(Rec, xRec, FieldNo("Prepmt. Payment Terms Code"), CurrFieldNo, IsHandled);
                if not IsHandled then
                    "Prepmt. Pmt. Discount Date" := CalcDate(PaymentTerms."Discount Date Calculation", "Document Date");
                if not UpdateDocumentDate then
                    Validate("Prepmt. Payment Discount %", PaymentTerms."Discount %")
            end;
        end else begin
            Validate("Prepayment Due Date", "Document Date");
            if not UpdateDocumentDate then begin
                Validate("Prepmt. Pmt. Discount Date", 0D);
                Validate("Prepmt. Payment Discount %", 0);
            end;
        end;
    end;
}

[IntegrationEvent(false, false)]
local procedure OnValidatePaymentTermsCodeOnBeforeValidatePrepaymentDueDate(var SalesHeader: Record "Sales Header"; xSalesHeader: Record "Sales Header"; CurrentFieldNo: Integer; var IsHandled: Boolean)
begin
end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


[RTL] Improve hint and url tags interaction.

Improves hint and url tags interaction by adding offset to nested outline (only one level deep, since RTL currently support only one underline of the same time at a time).

test [hint="tooltip"]hello[/hint] test [url="https://example.com"]hello[/url] test
test [hint="tooltip"][url="https://example.com"]hello[/url][/hint] test
test [hint=" tooltip"]world[url="https://example.com"]hello[/url]world[/hint] test
test [url="https://example.com"]world[hint="tooltip"]hello[/hint]world[/url] test

This would admittedly be a rather niche interaction especially more-so if/when https://github.com/godotengine/godot/pull/99481 is merged

Seems ok, but does it play well with custom theme overrides? Overall it seems to be an uncommon behavior to expect so I'm not sure we really need to bother.
A quick HTML check with:

Some abbr

Seems to show that there's only the underline, not dashed line:


Update to Deno 1.10.2

Please merge this ASAP. Deno versions prior to 1.10.2 have a critical security vulnerability (CVE-2021-32619, advisory will be published later this week).

Yours messed with the formatting, so updated in https://github.com/TooTallNate/vercel-deno/pull/70.

Thanks!


fix comment about number of constraints

It seems there're only 2 constraints in Field.is_not_equal?

Oops, let is_neq: Boolean<E> = witness!(|self, other| self != other); is the 3rd constraint I missed...


Test existing keys in apt.key

Is your feature request related to a problem? Please describe.
In the docker example I noticed some tests to avoid rewriting keys that already exist.  Perhaps these tests can be folded into the apt.key() operation.
Describe the solution you'd like
Add a keyword to ensure the key exists, e.g.
apt.key(
    name="Add the Docker apt gpg key if we need to",
    src="https://download.docker.com/linux/ubuntu/gpg",
    exists=True,
)

If the key exists, don't  bother adding the key.  Otherwise, add the key.
You can then write cleaner code without the testing logic.

The checking/implementation of this was actually completed in https://github.com/Fizzadar/pyinfra/commit/776b35c81ef936df661ffc09543a05d674ded093#diff-73efd0d9dd8a7cadf7e9e96baa7ef1cfe911a3d1b1cf14b009667cd64f232748! I need to fix the example to remove the now pointless check.

Manual check removed in https://github.com/Fizzadar/pyinfra/commit/3f3cda771c3f2c1fc483946d7d408bee42e998d1 :)


Add possibility to fetch and embed graphs from remote server

Updated patch as promised in findmypast/icingaweb2-module-graphite/pull/26

Is there any problem / doubt with this? I'll be happy to correct it.

Thanks for this feature, just what i was looking for and it works very nicely!

Hey @smelchior and @xert, thanks for the PR and very sorry about the delayed response!
Have you by any chance had a look into the conflict here?

@sashman I'll try to look into this and solve the conflict.

Hi can you please look at this and possibly merge?

Hey @xert thanks for the fix, I have one query though, as I'm new to this chunk of code and there seems to be non-trivial changes, do you mind giving me a little run through of what this affects please? Would be very appreciated and help out loads!

Hi @sashman, sure.
The feature here is to implement fetching the graph from remote server, if the server is not accessible from icingaweb2 users browser. This is for example when using multi-tenant icingaweb2 installation and http basic auth to icingaweb and graphite with the same credentials is not desirable.
When this feature is turned on, then the code fetches the image from remote servers and inlines the data in the img tag  instead of simply creating the image tag
Is this explanation sufficient?

Any news on merging this? :)

@xert @friesoft apologies for the delayed response, this seems sensible to me!

Thank you very much for this feature :) it works great for the embedded graphs.
What doesn't work is clicking on the graphs and having it fetch it also using remote_fetch.
Our situation: we have a proxy which proxies icingaweb2. The graphite render URL isn't available externally - so now we have the small embedded graphs when accessing icingaweb2 externally but not the whole graph when clicking on the small ones.
Any chance this could also be implemented?

Hi @friesoft
can You post your config and what link is generated on your small images (pointing to larger ones)? I'm using this in similar setup (for this reason I've made this PR) and both small and large graphs are embedded. Are You using current master?

I guess our problem is with http/https. Our proxy is https and we are using ProxyPass + ProxyPassReverse to icingaweb2 running on http.
We also didn't have ProxyPreserveHost set which led to the following code not working:
application/controllers/IndexController.php:22
        if ($this->grapher->getRemoteFetch()) {                                $this->view->url = $this->_request->getScheme()."://".                                $this->_request->getHttpHost().
getHttpHost returned our internal URL to icingaweb2.
With ProxyPreserveHost this correctly returns our proxy host but getScheme returns the scheme of our internal URL (http). This still leads to not working requests as we now get mixed content warnings in the browsers.

My workaround for the moment:
        $scheme = $this->_request->getScheme();
        if ($this->_request->getHeader("X_FORWARDED_PROTO")) {
            $scheme = $this->_request->getHeader("X_FORWARDED_PROTO");
        }
        if ($this->grapher->getRemoteFetch()) {
            $this->view->url = $scheme."://".

And my apache config:
  <Location "/icingaweb2">
    ProxyPreserveHost On
    RequestHeader set X-FORWARDED-PROTO https
    ProxyPass http://<IP_ADDRESS>/icingaweb2
    ProxyPassReverse http://<IP_ADDRESS>/icingaweb2
  </Location>

@xert ping :) can my workaround be upstreamed?

@friesoft please make a new pull request as there is no way @sashman can merge this.


Instance Normalization not implemented right

See this post.

See https://github.com/tensorflow/tensorflow/issues/11690#issuecomment-318373681

Ok, then I close this issue.