Tutorial is broken

From the Tutorial:
var browser = mdns.createBrowser(mdns.tcp('http'));

browser.on('serviceUp', function(service) {
  console.log("service up: ", service);
});
browser.on('serviceDown', function(service) {
  console.log("service down: ", service);
});

browser.start();

If I enter the above in a node REPL on Mac OS 10.9.2 running node 0.11.13, I receive this error:
> service down:  { interfaceIndex:<PHONE_NUMBER>,
  type:
   { name: 'http',
     protocol: 'tcp',
     subtypes: [],
     fullyQualified: true },
  replyDomain: 'local.',
  flags: 0,
  name: 'Brenton\'s MacBook Pro (eBay)',
  networkInterface: 'lo0' }
Error: dns service error: no such record
    at Error (native)
    at MDNSService.on_get_addr_info_done (/Users/bresimpson/Projects/_misc/node_modules/mdns/lib/resolver_sequence_tasks.js:72:30)
    at SocketWatcher.MDNSService.self.watcher.callback (/Users/bresimpson/Projects/_misc/node_modules/mdns/lib/mdns_service.js:17:38)
> Error: dns service error: no such record
    at Error (native)
    at MDNSService.on_get_addr_info_done (/Users/bresimpson/Projects/_misc/node_modules/mdns/lib/resolver_sequence_tasks.js:72:30)
    at SocketWatcher.MDNSService.self.watcher.callback (/Users/bresimpson/Projects/_misc/node_modules/mdns/lib/mdns_service.js:17:38)

Without REPL the code works for me on Mac OS 10.9.5 using node v0.11.14 and v0.11.13. Pasting the code in REPL didn't give me the same error but did not work either. It just did nothing. (I never use REPL for stuff like launching servers, so I have no idea if it should work).
I'm not sure how to proceed. Could you run the code from a file? Just to exclude REPL as a source of odd behavior...

Saved to a file; same error:
~/P/_/bonjour $ node --harmony ./index.js
events.js:85
      throw er; // Unhandled 'error' event
            ^
Error: dns service error: no such record
    at Error (native)
    at MDNSService.on_get_addr_info_done (/Users/bresimpson/Projects/_misc/bonjour/node_modules/mdns/lib/resolver_sequence_tasks.js:72:30)
    at SocketWatcher.MDNSService.self.watcher.callback (/Users/bresimpson/Projects/_misc/bonjour/node_modules/mdns/lib/mdns_service.js:17:38)

Hm. I'm pretty sure it is a local problem. In all these years I've never seen anything like it. Like, never.
Actually, it might have something to do with your other issue #117. Let me comment on that one...

Thought a bit more about this one. Try installing an error handler on the browser. Maybe it is only one entry that is causing the trouble. Handling the error allows the app to continue processing potential other entries...

Using this code:

var browser = mdns.createBrowser(mdns.tcp('http'));

browser.on('error', function(error) {
  console.error(error.stack);
});
browser.on('serviceUp', function(service) {
  console.log("service up: ", service);
});
browser.on('serviceDown', function(service) {
  console.log("service down: ", service);
});

browser.start();

and a console.log(arguments) in on_get_addr_info_done, I see this:
interface index: 0
{ '0': { initialized: true, fd: 19 },
  '1': 3,
  '2': 0,
  '3': -65554,
  '4': 'Brentons-MacBook-Pro-eBay.local.',
  '5': '::',
  '6': 60,
  '7': undefined }
Error: dns service error: no such record
    at Error (native)
    at MDNSService.on_get_addr_info_done (/Users/bresimpson/Projects/_misc/bonjour/node_modules/mdns/lib/resolver_sequence_tasks.js:73:30)
    at SocketWatcher.MDNSService.self.watcher.callback (/Users/bresimpson/Projects/_misc/bonjour/node_modules/mdns/lib/mdns_service.js:17:38)
{ '0': { initialized: true, fd: 20 },
  '1': 3,
  '2': 0,
  '3': -65554,
  '4': 'fonera.local.',
  '5': '::',
  '6': 60,
  '7': undefined }
Error: dns service error: no such record
    at Error (native)
    at MDNSService.on_get_addr_info_done (/Users/bresimpson/Projects/_misc/bonjour/node_modules/mdns/lib/resolver_sequence_tasks.js:73:30)
    at SocketWatcher.MDNSService.self.watcher.callback (/Users/bresimpson/Projects/_misc/bonjour/node_modules/mdns/lib/mdns_service.js:17:38)
{ '0': { initialized: true, fd: 21 },
  '1': 3,
  '2': 0,
  '3': -65554,
  '4': 'HP020983.local.',
  '5': '::',
  '6': 60,
  '7': undefined }
Error: dns service error: no such record
    at Error (native)
    at MDNSService.on_get_addr_info_done (/Users/bresimpson/Projects/_misc/bonjour/node_modules/mdns/lib/resolver_sequence_tasks.js:73:30)
    at SocketWatcher.MDNSService.self.watcher.callback (/Users/bresimpson/Projects/_misc/bonjour/node_modules/mdns/lib/mdns_service.js:17:38)
{ '0': { initialized: true, fd: 22 },
  '1': 3,
  '2': 4,
  '3': 0,
  '4': 'HP9CB654E873F3.local.',
  '5': 'fe80::9eb6:54ff:fee8:73f4',
  '6': 120,
  '7': undefined }
{ '0': { initialized: true, fd: 22 },
  '1': 3,
  '2': 0,
  '3': -65554,
  '4': 'HP9CB654E873F3.local.',
  '5': '::',
  '6': 60,
  '7': undefined }
Error: dns service error: no such record
    at Error (native)
    at MDNSService.on_get_addr_info_done (/Users/bresimpson/Projects/_misc/bonjour/node_modules/mdns/lib/resolver_sequence_tasks.js:73:30)
    at SocketWatcher.MDNSService.self.watcher.callback (/Users/bresimpson/Projects/_misc/bonjour/node_modules/mdns/lib/mdns_service.js:17:38)
service down:  { interfaceIndex:<PHONE_NUMBER>,
  type:
   { name: 'http',
     protocol: 'tcp',
     subtypes: [],
     fullyQualified: true },
  replyDomain: 'local.',
  flags: 0,
  name: 'Brenton\'s MacBook Pro (eBay)',
  networkInterface: 'lo0' }

Is that helpful?

Closing.


Update the wxPython version

Submitting this pull request to the <IP_ADDRESS>-hotfix branch because it seems most natural in this case.
Apparently the previous version of wxPython was causing an undocumented problem with “source code string cannot contain null bytes”. Steps to reproduce:
pex 'wxpython==4.0.7' --platform win_amd64-cp-38-cp38 -o example.pyz

Then (on Windows) py example.pyz and import wx.
If we replace 'wxpython==4.0.7' with 'wxpython==4.0.7.post2', it starts to work (don’t know if it is actually related to PEX or not).

FYI: 4.1.0 is out now

In general the lowest maintenance burden for  both this project and also any that interact with it would be to have:
wxpython >= 4.0.0, <5.0 assuming that a quick test shows that it works with 4.0 and only change the 5.0 to a lower release once one has been found that is incompatible if one is.
This will save version thrashing with minimal risk. As wxpython uses semantic versioning we can safely expect that a major version change will be a breaking one but that until that change comes along there probably will not be problems.

@GadgetSteve

uses semantic versioning we can safely expect

Ho boy, I cannot describe to you how little I expect semantic versioning to mean anything in practice ^_^
My lack of faith aside, in the specific wx case, the versioning scheme is not semver and instead a custom even / odd setup for which versions are stable. Sitting on a >= 4.0 style policy has already bit the project once in the past. So, to avoid breaking people who use Gooey due to a, by design, unstable minor wx version bump, Gooey will continue to periodically onboard new wx versions after a period of stability / testing.

Is there a possibility to relax the version specified to say wxpython==4.0 instead of 4.0.7? This should still keep you on the "stable" even-numbered minors and avoid API breakage (and you can bump it to 4.2 in the future) but will still get bug fixes. In addition, it avoids weird issues like this triggered by 4.0.7 (without .post2) not being available everywhere.
I am just weird conflict dependency issues in one of my packages (only at runtime, though!), and I suspect the strict depencency somehow being the culprit (but can't confirm that now).


global tslint throws error if extends config option references local package

Bug Report (delete this for feature requests)

TSLint version: 3.8.1
TypeScript version: 1.8.10
Running TSLint via: (please choose one) CLI

TypeScript code being linted
tslint.json:
{
  "extends": "shared-tslint-config"
}

(where shared-tslint-config is a locally installed NPM package providing a tslint config)
Actual behavior
(when using a globally installed tslint)
$ tslint src/index.ts --config tslint.json

/usr/local/lib/node_modules/tslint/lib/configuration.js:122
            throw new Error(("Invalid \"extends\" configuration value - could not require \"" + relativeFilePath + "\". ") +
            ^

Error: Invalid "extends" configuration value - could not require "shared-tslint-config". Review the Node lookup algorithm (https://nodejs.org/api/modules.html#modules_all_together) for the approximate method TSLint uses to find the referenced configuration file.
    at resolveConfigurationPath (/usr/local/lib/node_modules/tslint/lib/configuration.js:122:19)
    at loadConfigurationFromPath (/usr/local/lib/node_modules/tslint/lib/configuration.js:101:38)
    at Object.findConfiguration (/usr/local/lib/node_modules/tslint/lib/configuration.js:45:12)
    at processFile (/usr/local/lib/node_modules/tslint/lib/tslint-cli.js:111:41)
    at Array.forEach (native)
    at Object.<anonymous> (/usr/local/lib/node_modules/tslint/lib/tslint-cli.js:128:41)
    at Module._compile (module.js:409:26)
    at Object.Module._extensions..js (module.js:416:10)
    at Module.load (module.js:343:32)
    at Function.Module._load (module.js:300:12)

Expected behavior
tslint should resolve configuration file from locally installed package shared-tslint-config

I expect this is because, when run globally, require.resolve in resolveConfigurationPath() only has access to other global packages, not local ones.

There is a workaround of using a relative or absolute path to the config file to extend, instead of a module ID.
This obviously means you have to rely on the config file in the package not changing location in the package.

This is known behavior and I had originally thought it was okay to have things work like this, but I'm glad you made this issue for discussion. This issue is pretty confusing behavior for end users, and changing it would be a big improvement.
Perhaps the best solution here is to use a 3rd-party require/resolve library that lets you "start" from a different starting location? So modules could be resolved relative to the location of the config file and also  as they are now.

A package like resolve should do the job.
I'm happy to create a pull request, if you're happy with this as a solution.

Sure, a PR would be great! Thanks @janslow


Help with lr-finder working with transformers?

I am in need of a tool like this for a particular problem that is very sensitive to the LR. I am, however, unable to get this package to work with any transformer model unfortunately.
My error is as below and I am wondering if you have any insight!
from torch_lr_finder import LRFinder
import torch.optim as optim
from transformers import XLMRobertaTokenizer, XLMRobertaForSequenceClassification
model = XLMRobertaForSequenceClassification.from_pretrained("xlm-roberta-base", num_labels=3).cuda()
criterion = nn.CrossEntropyLoss()
optimizer = optim.Adam(model.parameters(), lr=1e-7, weight_decay=1e-2)
lr_finder = LRFinder(model, optimizer, criterion, device="cuda")
lr_finder.range_test(train_dataloader, val_loader=valid_dataloader, end_lr=1, num_iter=100, step_mode="linear")

---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-8-decc9b6c423b> in <module>
----> 1 lr_finder.range_test(train_dataloader, val_loader=valid_dataloader, end_lr=1, num_iter=100, step_mode="linear")

~\Anaconda3\envs\my_ml\lib\site-packages\torch_lr_finder\lr_finder.py in range_test(self, train_loader, val_loader, start_lr, end_lr, num_iter, step_mode, smooth_f, diverge_th, accumulation_steps, non_blocking_transfer)
    284                 train_iter,
    285                 accumulation_steps,
--> 286                 non_blocking_transfer=non_blocking_transfer,
    287             )
    288             if val_loader:

~\Anaconda3\envs\my_ml\lib\site-packages\torch_lr_finder\lr_finder.py in _train_batch(self, train_iter, accumulation_steps, non_blocking_transfer)
    342             # Forward pass
    343             outputs = self.model(inputs)
--> 344             loss = self.criterion(outputs, labels)
    345
    346             # Loss should be averaged in each step

~\Anaconda3\envs\my_ml\lib\site-packages\torch\nn\modules\module.py in _call_impl(self, *input, **kwargs)
    724             result = self._slow_forward(*input, **kwargs)
    725         else:
--> 726             result = self.forward(*input, **kwargs)
    727         for hook in itertools.chain(
    728                 _global_forward_hooks.values(),

~\Anaconda3\envs\my_ml\lib\site-packages\torch\nn\modules\loss.py in forward(self, input, target)
    946     def forward(self, input: Tensor, target: Tensor) -> Tensor:
    947         return F.cross_entropy(input, target, weight=self.weight,
--> 948                                ignore_index=self.ignore_index, reduction=self.reduction)
    949
    950

~\Anaconda3\envs\my_ml\lib\site-packages\torch\nn\functional.py in cross_entropy(input, target, weight, size_average, ignore_index, reduce, reduction)
   2420     if size_average is not None or reduce is not None:
   2421         reduction = _Reduction.legacy_get_string(size_average, reduce)
-> 2422     return nll_loss(log_softmax(input, 1), target, weight, None, ignore_index, None, reduction)
   2423
   2424

~\Anaconda3\envs\my_ml\lib\site-packages\torch\nn\functional.py in log_softmax(input, dim, _stacklevel, dtype)
   1589         dim = _get_softmax_dim('log_softmax', input.dim(), _stacklevel)
   1590     if dtype is None:
-> 1591         ret = input.log_softmax(dim)
   1592     else:
   1593         ret = input.log_softmax(dim, dtype=dtype)

AttributeError: 'tuple' object has no attribute 'log_softmax'

Hi @afogarty85.
It seems that XLMRobertaForSequenceClassification.forward() returns a tuple object, and that makes it failed to compute loss in LRFinder._train_batch().
Currently, it takes only single item returned from model.forward() in LRFinder._train_batch(). Therefore, there are 2 solutions for this case:

Make a wrapper for loss function that takes 2nd item from XLMRobertaForSequenceClassification.forward().
class LossWrapper(nn.module):
    def __init__(self, loss_fn):
        self.loss_fn = loss_fn

    def forward(self, outputs, labels):
        # In current case, `labels` will be passed into
        # `XLMRobertaForSequenceClassification.forward()`, and that makes
        # it return at least 2 items: `(loss,), logits`. But what we need
        # is `logits` only.
        # See also the docstring of `XLMRobertaForSequenceClassification.forward()`
        logits = outputs[1]
        return self.loss_fn(logits, labels)

# Then, just replace the original criterion with this wrapper
criterion = LossWrapper(nn.CrossEntropyLoss())
lr_finder = LRFinder(model, optimizer, criterion, device="cuda")

Since loss will be computed automatically if labels is passed into XLMRobertaForSequenceClassification.forward(), previous solution leads to a computing waste (loss will be computed twice). If you care about this issue, you can subclass LRFinder and rewrite _train_batch() that does not compute loss again.
class MyLRFinder(LRFinder):
    def _train_batch(self, train_iter, accumulation_steps, non_blocking_transfer=True):
        # L344-L345, original code:
        # outputs = self.model(inputs)
        # loss = self.criterion(outputs, labels)

        # Just change those lines above to the following one:
        loss, logits = self.model(inputs)

# Then, use the new LRFinder
criterion = nn.CrossEntropyLoss()
lr_finder = MyLRFinder(model, optimizer, criterion, device="cuda")

Besides, note that the output of XLMRobertaForSequenceClassification.forward() has been changed to SequenceClassifierOutput in the newest version of transformer library, you might need to do further modification after updating it.
Feel free to let me know if there is any further problem!

Thank you so much for your quick response and attention!
I cannot get #1 to work but I have not tried editing the source code for #2.
In terms of #1, the central problem I have now is calculating the loss when the logits are shape: [56, 3] and then calculating the loss is not possible, returning the error: multi-target not supported.
I also made some slight tweaks to get it a bit closer to working:
class LossWrapper(nn.Module):
    def __init__(self, loss_fn):
        super().__init__()
        self.loss_fn = loss_fn
    def forward(self, outputs, labels):
        # In current case, `labels` will be passed into
        # `XLMRobertaForSequenceClassification.forward()`, and that makes
        # it return at least 2 items: `(loss,), logits`. But what we need
        # is `logits` only.
        # See also the docstring of `XLMRobertaForSequenceClassification.forward()`
        logits = outputs[0]  # logits only
        return self.loss_fn(logits, labels)

Yeah, you are right. I missed the calling of super() to inherit its parent class.

In terms of (1), the central problem I have now is calculating the loss when the logits are shape: [56, 3] and then calculating the loss is not possible, returning the error: multi-target not supported. Labels are shape [56, 1].

Dimension of labels for loss function should be 1 here, that is, logits.shape: [56, 3] and labels.shape: [56] where 56 is batch size. Otherwise, you will get that RuntimeError: multi-target not supported.... You can pass labels.view(-1) into loss function to see whether it works or not. That is:
class LossWrapper(nn.Module):
    def __init__(self, loss_fn):
        super().__init__()
        self.loss_fn = loss_fn

    def forward(self, outputs, labels):
        logits = outputs[1]  # logits only
        return self.loss_fn(logits, labels.view(-1))

See also here.
However, it's probably incorrect to select the first value of outputs (logits = outputs[0]) to compute loss. The reason is also described in the comment of LossWrapper.forward(), the first value should be loss instead of logits. So, the code you modified might work incorrect just without error occurring.
And the reason why nn.CrossEntropyLoss(logits, labels.flatten()) does not work is that nn.CrossEntropyLoss is a class of loss function, you should use it like this:
loss_fn = nn.CrossEntropyLoss()
loss = loss_fn(logits, labels.flatten())    # `labels.flatten()` is equivalent to `labels.view(-1)` in this case

Good Evening,
I am still having some struggles. I am not entirely sure what is not working properly.
With a toy example, the model outputs loss, logits correctly:
import torch
import torch.nn as nn
from torch_lr_finder import LRFinder
import torch.optim as optim
from transformers import XLMRobertaTokenizer, XLMRobertaForSequenceClassification
from torch.utils.data import TensorDataset, DataLoader

model = XLMRobertaForSequenceClassification.from_pretrained("xlm-roberta-base", num_labels=3).cuda()
tokenizer = XLMRobertaTokenizer.from_pretrained('xlm-roberta-base')

input_ids = tokenizer("Hello, my dog is cute", return_tensors="pt")
input_label = torch.tensor([1])

with torch.no_grad():
    loss, logits = model(input_ids=input_ids['input_ids'].cuda(),
                     attention_mask=input_ids['attention_mask'].cuda(),
                     labels=input_label.cuda())

By running the supplied class, outputs[1] cannot  be found.
class LossWrapper(nn.Module):
    def __init__(self, loss_fn):
        super().__init__()
        self.loss_fn = loss_fn

    def forward(self, outputs, labels):
        logits = outputs[1]  # logits only
        return self.loss_fn(logits, labels.view(-1))

If I change the class to outputs[0], then I believe outputs[0]` given the next error as its size reflects the new batch size of 24.
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-13-decc9b6c423b> in <module>
----> 1 lr_finder.range_test(train_dataloader, val_loader=valid_dataloader, end_lr=1, num_iter=100, step_mode="linear")

~\Anaconda3\envs\my_ml\lib\site-packages\torch_lr_finder\lr_finder.py in range_test(self, train_loader, val_loader, start_lr, end_lr, num_iter, step_mode, smooth_f, diverge_th, accumulation_steps, non_blocking_transfer)
    284                 train_iter,
    285                 accumulation_steps,
--> 286                 non_blocking_transfer=non_blocking_transfer,
    287             )
    288             if val_loader:

~\Anaconda3\envs\my_ml\lib\site-packages\torch_lr_finder\lr_finder.py in _train_batch(self, train_iter, accumulation_steps, non_blocking_transfer)
    342             # Forward pass
    343             outputs = self.model(inputs)
--> 344             loss = self.criterion(outputs, labels)
    345
    346             # Loss should be averaged in each step

~\Anaconda3\envs\my_ml\lib\site-packages\torch\nn\modules\module.py in _call_impl(self, *input, **kwargs)
    724             result = self._slow_forward(*input, **kwargs)
    725         else:
--> 726             result = self.forward(*input, **kwargs)
    727         for hook in itertools.chain(
    728                 _global_forward_hooks.values(),

<ipython-input-9-ea4677930fd0> in forward(self, outputs, labels)
      6     def forward(self, outputs, labels):
      7         logits = outputs[0]
----> 8         return self.loss_fn(logits, labels.view(-1))

~\Anaconda3\envs\my_ml\lib\site-packages\torch\nn\modules\module.py in _call_impl(self, *input, **kwargs)
    724             result = self._slow_forward(*input, **kwargs)
    725         else:
--> 726             result = self.forward(*input, **kwargs)
    727         for hook in itertools.chain(
    728                 _global_forward_hooks.values(),

~\Anaconda3\envs\my_ml\lib\site-packages\torch\nn\modules\loss.py in forward(self, input, target)
    946     def forward(self, input: Tensor, target: Tensor) -> Tensor:
    947         return F.cross_entropy(input, target, weight=self.weight,
--> 948                                ignore_index=self.ignore_index, reduction=self.reduction)
    949
    950

~\Anaconda3\envs\my_ml\lib\site-packages\torch\nn\functional.py in cross_entropy(input, target, weight, size_average, ignore_index, reduce, reduction)
   2420     if size_average is not None or reduce is not None:
   2421         reduction = _Reduction.legacy_get_string(size_average, reduce)
-> 2422     return nll_loss(log_softmax(input, 1), target, weight, None, ignore_index, None, reduction)
   2423
   2424

~\Anaconda3\envs\my_ml\lib\site-packages\torch\nn\functional.py in nll_loss(input, target, weight, size_average, ignore_index, reduce, reduction)
   2214     if input.size(0) != target.size(0):
   2215         raise ValueError('Expected input batch_size ({}) to match target batch_size ({}).'
-> 2216                          .format(input.size(0), target.size(0)))
   2217     if dim == 2:
   2218         ret = torch._C._nn.nll_loss(input, target, weight, _Reduction.get_enum(reduction), ignore_index)

ValueError: Expected input batch_size (24) to match target batch_size (2280).

I am sorry for all the time you have spent, but I appreciate it and it will help me tackle this process for other transformer models in the future.

Thanks for that example. And no need to be sorry, your feedback helps us improve this package.

If I change the class to outputs[0], then I believe outputs[0] is actually the logits now, given the below error, as its size reflects the new batch size of 24.

Oh, that's my bad. I forgot that every batch of data will be unpacked into inputs and labels before passing into model. Hence that labels is not passed into BERT model, and that's why there is only one item in the returned value of model.forward(). So that you are correct, the first item is logits indeed.
And due to this reason, loss won't be computed during model.forward(). So that there is no issue about computing waste which is metioned in my previous comment.
However, with current information, I cannot figure out the cause of error in your latest comment ValueError: Expected input batch_size (24) to match target batch_size (2280). Maybe you have to use pdb.set_trace() to trace the code before executing lr_finder.py@L344, and try to figure out what the input argument outputs and labels actually is.
I wrote an example for utilizing LRFinder with transformer model, maybe you can find something helpful from it: https://colab.research.google.com/drive/1OZ7EWnGopPT8RNLxXVJ_K2EmgHMmTpN4?usp=sharing

Thanks for the continued help. I have been playing with your colab example which of course works. I am trying to figure out why, exactly, it does not work with my data.

That's totally fine. Take your time.

Hello :)
@NaleRaphael
I have been testing you colab and I found it a little bit strange how you say that logits should be outputs[0] instead of  outputs[1].
when you run :
for batch in train_loader:
    outputs = bert_model_wrapper(*batch)
    print(outputs) #
    break

The output is something like this SequenceClassifierOutput(loss=tensor(2.3758, device='cuda:0', grad_fn=<NllLossBackward0>), logits=tensor([[-0.0108,  0.2426, -0.1928, -0.1228, -0.0440,  0.1848, -0.2018,  0.0837,           0.0681, -0.0016] From here we can see that the outputs[1] is our logits
when I run it with [1] I got a complet different error tuple index out of range with lr_finder.range_test(train_loader, val_loader=valid_loader, start_lr=1e-5, end_lr=10, num_iter=100, step_mode='linear')
Can you explain it to meet please :) ?
thanks!

Hi @ma-batita !
In that colab notebook, I was using huggingface transformer v3.0.2. You can find that the returned value of XLMRobertaForSequenceClassification.forward() would be:

if labels is not given, the first value would be logits
if labels is given, the first value would be loss

# source: https://github.com/huggingface/transformers/blob/v3.0.2/src/transformers/modeling_roberta.py#L349-L360
        # ...
        outputs = (logits,) + outputs[2:]    # case 1: `labels` is not given, the first element of tuple `outputs` is `logits`.
        if labels is not None:
            if self.num_labels == 1:
                #  We are doing regression
                loss_fct = MSELoss()
                loss = loss_fct(logits.view(-1), labels.view(-1))
            else:
                loss_fct = CrossEntropyLoss()
                loss = loss_fct(logits.view(-1, self.num_labels), labels.view(-1))
            outputs = (loss,) + outputs    # case 2: `labels` is given, now the tuple `outputs` is prepended with `loss`.

        return outputs  # (loss), logits, (hidden_states), (attentions)

That's why I mentioned "... the first item is logits indeed" in my previous comment.
From the message you provided, output has been wrapped with a data class SequenceClassifierOutput. So that it seems you are running with a version later than v3.0.2. Though huggingface transformers has already bumped to v4.21.3, it still retrains a similar behavior:
# source: https://github.com/huggingface/transformers/blob/v4.21.3/src/transformers/models/roberta/modeling_roberta.py#L1243-L1252
# ...
        # NOTE: code above are written to calculate `loss` if `labels` is given, but we omitted them here.
        # If `labels` is not given, `loss` will retain its initial value: None.
        if not return_dict:
            output = (logits,) + outputs[2:]
            # Below is the condition to determine whether the first element of returned value is `loss` or `logits`
            return ((loss,) + output) if loss is not None else output

        # This should be the result you get (`return_dict` is True)
        return SequenceClassifierOutput(
            loss=loss,
            logits=logits,
            hidden_states=outputs.hidden_states,
            attentions=outputs.attentions,
        )

So, the key is still the same: "is labels passed to model.forward()?"
As it's mentioned in my previous comment:

... I forgot that every batch of data will be unpacked into inputs and labels before passing into model. Hence that labels is not passed into BERT model, and that's why there is only one item in the returned  value of model.forward()...

This is the reason why I directly select the first element in LossWrapper written in the colab notebook:
class LossWrapper(nn.Module):
    def __init__(self, loss_fn):
        super().__init__()
        self.loss_fn = loss_fn

    def forward(self, outputs, labels):
        # Output of BERT model is a tuple even if the argument `labels` is not
        # passed in, so that we should unpack it here.
        # When `labels` is not passed, outputs: (logits,)
        # When `labels` is passed, outputs: (loss, logits,)
        logits = outputs[0]
        return self.loss_fn(logits, labels)

Regarding other questions you mentioned:

when I try it with [0] I got abatch_text_or_text_pairs has to be a list (got <class 'tuple'>)!
when I run it with [1] I got a complet different error tuple index out of range with lr_finder.range_test(train_loader, val_loader=valid_loader, start_lr=1e-5, end_lr=10, num_iter=100, step_mode='linear')

Could you elaborate what you were trying to do? Or maybe you can try inserting a breakpoint (import pdb; pdb.set_trace()) before the line of code where exception was raised and re-run again, and take a look about variables in that scope.
Hope that could help you figure out the problem quickly.
Anyway, please feel free to let me know if you still have questions.

Hello again :) @NaleRaphael
Thanks for your quick reply I reply appreciate it!!

From the message you provided, output has been wrapped with a data class SequenceClassifierOutput. So that it seems you are running with a version later than v3.0.2. Though huggingface transformers has already bumped to v4.21.3, it still retrains a similar behaviour:

Yes, ended  I am using the later version of huggingface and I am demanding since the output has a different form ever since why not adapt LRFinder to this major change? one can make the criterion as an option since it is already wrapped into the model (for the classification problems). Is this can be an option or it affects the global function of LRFinder  ?

Now let's say that I am using the right version of huggingface (v3.0.2.)
I manage to understand where this error came from,
batch_text_or_text_pairs has to be a list (got <class 'tuple'>)!
I get it because I am doing from transformers import AutoTokenizer, AutoModelForSequenceClassificationand if I do from transformers import XLMRobertaTokenizer, XLMRobertaForSequenceClassification I dont get it.
Do you have any idea why please ?
you asked what I am trying to do?
I have a classification problem with a spanish model and I want to find a good LR to start my training.
when I tried :
import pdb
for batch in train_loader:
  pdb.set_trace()
  outputs = bert_model_wrapper(*batch)
  print(outputs) # [1]
  break

I get :
> <ipython-input-20-217a24934843>(4)<module>()
-> outputs = bert_model_wrapper(*batch)
(Pdb) outputs
SequenceClassifierOutput(loss=tensor(2.1979, device='cuda:0', grad_fn=<NllLossBackward0>), logits=tensor([[ 0.3399, -0.0038,  0.0829,  0.0488,  0.3425,  0.2920, -0.0111,  0.0885,
          0.0715, -0.1070],
        [ 0.3414, -0.0055,  0.0908,  0.0377,  0.3433,  0.2716, -0.0141,  0.0839,
          0.0717, -0.1170],
        [ 0.3354, -0.0030,  0.0834,  0.0354,  0.3348,  0.2739, -0.0159,  0.0951,
          0.0848, -0.1094],
        [ 0.3385,  0.0042,  0.0952,  0.0335,  0.3372,  0.2679, -0.0228,  0.0871,
          0.0837, -0.1097]], device='cuda:0', grad_fn=<AddmmBackward0>), hidden_states=None, attentions=None)

Hello @NaleRaphael
Thanks for you detailed explanation about the modification of LRFinder. I understood it from the beginning that this specific modification will cause problems in other situations. It was a matter of confirmation :)
Thanks anyway ;)

About the error it is that later version of transformers that caused it :)
When I use transformers==3.0.2 I dont get it!
But I still got a problem  and I think it is related with my Data!  It is really weird as I tried to make my data looks like yours in the notebook but still, I got :
CUDA kernel errors might be asynchronously reported at some other API call,so the stacktrace below might be incorrect.
For debugging consider passing CUDA_LAUNCH_BLOCKING=1.

even when I tried max_length=128 I still got it!
Ps: I have a problem with 1O different classes and I am not sure how I am going to fit them in the AutoModelForSequenceClassification!

Hi @ma-batita
Sure, no worries. :)
Regarding the issue you ran into, it's recommended to run the model on CPU first. Some error messages might not be shown explicitly while running on GPU. Also, it's also recommended to make sure your code work well without considering anything related LRFinder first. Once you did it, then you can start adding LRFinder into it. This could help you figure out the actual cause.
As for the last question, you need to set num_labels in config to make AutoModelForSequenceClassification work with difference number of classes, e.g.,
# see also: https://github.com/huggingface/transformers/blob/v4.21.3/src/transformers/models/roberta/modeling_roberta.py#L1199-L1202
config = AutoConfig.from_pretrained("xlm-roberta-base")
config.num_labels = 10
model = AutoModelForSequenceClassification.from_config(config)

Closing due to inactivity


App link doesn't work

Current Behavior
Looks like the certification has expired for https://loopygo.app/
Expected Behavior
Should open the website

hey Charlie, I'm sorry, this project was discontinued some time ago, maybe we will return to it in the future but no predictions

No worries! Do you have instructions for running it locally?

`

git clone
pnpm install
pnpm dev

// With the project running you will only find two pages. / and /dashboard
`

P.S: the project was discontinued very early so basically there is nothing, but the idea was to create a learning platform for Duolingo style programming but also for programming, and also with features such as rankeds and something aimed at gamification, with rewards such as skins

Cheers revo! Much appreciate this


Highlighting OrigQuote in Parallel scripture viewer

@elsylambert Do you know what this was for?

@birchamp This issue was for writing cypress Tests on Highlighting.

A test should be written to know whether ampersand and ellipse are working for highlighting. @jincypjose


chore: release 1.1.2

:robot: I have created a release *beep* *boop*
1.1.2 (2019-06-26)
Bug Fixes

docs: link to reference docs section on googleapis.dev (#250) (a35d76c)

This PR was generated with Release Please.

Release is at https://github.com/googleapis/nodejs-tasks/releases/tag/v1.1.2

The release build has started, the log can be viewed here. :sunflower:

:egg: You hatched a release! The release build finished successfully! :purple_heart:


Add nested disabled_on filter to event search.

This adds nested disabled_on filter that allows multiple or queries for that field.
In this case we need disabled_on_exists==False or disabled_on_after=date to filter events list.

Codecov Report

Merging #698 into develop will decrease coverage by 0.01%.
The diff coverage is 94.44%.

@@            Coverage Diff             @@
##           develop    #698      +/-   ##
==========================================
- Coverage    96.61%   96.6%   -0.02%
==========================================
  Files          130     130
  Lines         3697    3713      +16
  Branches       334     339       +5
==========================================
+ Hits          3572    3587      +15
  Misses          85      85
- Partials        40      41       +1

Impacted Files
Coverage Δ

datahub/search/event/views.py
100% <ø> (ø)
:arrow_up:

datahub/search/event/serializers.py
100% <100%> (ø)
:arrow_up:

datahub/search/elasticsearch.py
97.14% <92.3%> (-0.54%)
:arrow_down:

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 fa45085...5cea794. Read the comment docs.


core.call_bind aggressively raises args to top trace

def f(a_bool, y):
  if a_bool:
    return y + 1
  else:
    return y

jax.jit(jax.remat(f), static_argnums=0)(True, 1)

Results in:
ConcretizationTypeError: Abstract tracer value encountered where concrete value is expected (in `bool`).
Use transformation parameters such as `static_argnums` for `jit` to avoid tracing input values.
See `https://jax.readthedocs.io/en/latest/faq.html#abstract-tracer-value-encountered-where-concrete-value-is-expected-error`.
Encountered value: Traced<ShapedArray(bool[], weak_type=True):JaxprTrace(level=-1/2)>

I think this arises from the full_raise occurring here when processing remat_call_p - which raise to the JaxprTrace when we told JIT we don't want to!
https://github.com/google/jax/blob/77901e9fa71f5b23066c70132a983ae57f655b39/jax/core.py#L1001
This also applies to user-defined call primitives using core.call_bind, resulting in unnecessary workarounds like this one in Haiku:
https://github.com/deepmind/dm-haiku/blob/49b21f7192dfdb3dc0a49cc097c8d3b0ccabb107/haiku/_src/named_call.py#L101-L109

I think this might be working as intended. That is, remat itself will raise the abstraction level. You can use jax.remat(f, concrete=True) if you want to handle Python control flow inside a remat, but when mixing that together with jit it's possible to do redundant FLOPs in that case. This comment on #1749 has some detail.
WDYT?

Hmm I just tried with concrete=True and it didn't work... let's see...

I'm confused because calling JaxprTrace.full_raise should neither produce an 'unknown' tracer (see 1 2) nor raise the abstraction level. An unknown is only introduced when we call JaxprTrace.instantiate_const, and then it's only raised past the Concrete level if we call JaxprTrace.instantiate_const_abstracted.
Oh... I think I have an idea...

It's because we stage out as much as possible for calls. We really only want that behavior for xla_call and not other call primitives...

#2834 has a fix. You'll still need to use remat(f, concrete=True) to prevent remat from raising the abstraction level and hence allow it to handle Python control flow, but now we won't raise the abstraction level for all call primitives when they encounter an outer jit tracer.

gotcha, remat was just a hasty choice on my part to pick a jax-native call primitive that didn't seem to raise abstraction level; the main motivation is the linked Haiku named_call_p (and my other experimental call primitives).

thanks for the crazy fast fix!

:) Thanks for catching this! Your guess was quite good and that's what let us solve this fast.


Update deprecated dependencies

@ruiquelhas can you please remove the dist changes? It is generated on each release only.

Landed in 0a14e7a.


Convert master branch to main (on our forked branch)

Done
This also needs a manual build (as Drone does not automatically build) main-latest before we can redeploy on Kubernetes. See issue: https://github.com/StationA/gcsproxy/issues/2


GSOC 2024 : Zenoh Support & Benchmarking

Hello everyone,
I will work on integrating rmw_zenoh middleware to MoveIt and benchmarking the effects of Zenoh at MoveIt in scope of the Google Summer of Code Project with my mentors @sjahr and @henningkayser . We will share this project's updates here.
Our goals are below.

[ ] Make Zenoh support enable for Moveit
[ ] Create tutorials of how to use Zenoh at MoveIt project
[ ] Implement tests and benchmarks for Zenoh integrated MoveIt and report any bug in case of observing some errors related to this project
[ ] Contribute to CI jobs in order to support Zenoh

The primary goals of these project are above. However, please don't hesitate to share your ideas. I am open to new ideas.

In addition all of this, i want to say that i have refactored the perception pipeline tutorial in moveit2_tutorials for seeing the effects of rmw_zenoh againts perception pipeline scenario.
https://github.com/moveit/moveit2_tutorials/pull/906

Hello all,
I want to share the first insights about MoveIt + rmw_zenoh combination. Firstly, when i executed MoveIt demo with rmw_zenoh, even though gripper was loaded and usable in rviz2, manipulator was not loaded and invisible in rviz2 like below image. In addition, planning library was not loaded. As result of this, it also doesn't work planning and executing pipeline.

I started to inspect ros logs once demo was crashed. In ros logs, i saw that problem is based on controller spawner node, especially joint_state_broadcaster. And i also caught some bugs which it is suggested to report it in rmw_zenoh. This errors are below. However i should say that i also observed MoveIt demo + rmw_zenoh is executed without problem. which works so rarely. It generally gives this bellow errors in logs.

Relevant log in rmw_zenoh

Topic name /rosout not found in topic_map. Report this
Topic name /parameter_events not found in topic map. Report this
Topic name /spawner_joint_state_broadcaster/set_parameters not found in topic_map. Report this.
Topic name /spawner_joint_state_broadcaster/list_parameters not found in topic_map. Report this.
Topic name /spawner_joint_state_broadcaster/get_parameter_types not found in topic_map. Report this.

I also ran test cases of ros2_control and some test cases are crashed. When i ran test cases several times, about 1-2 failures occured after testing. Shortly it is sometimes failed tricycle_controller + joint_trajectory_controller and it is sometimes failed just joint_state_publisher and so on. The common point of this failures was joint_trajectory_controller. Moreover, all failures in joint_trajectory_publisher was due to below segmentation fault.
[       OK ] OnlyEffortTrajectoryControllers/TestTrajectoryActionsTestParameterized.test_allow_nonzero_velocity_at_trajectory_end_true/0 (2010 ms)
[ RUN      ] OnlyEffortTrajectoryControllers/TestTrajectoryActionsTestParameterized.test_allow_nonzero_velocity_at_trajectory_end_true/1
malloc(): unaligned tcache chunk detected
Stack trace (most recent call last):
#27   Object "", at 0xffffffffffffffff, in
#26   Object "/ws/build/joint_trajectory_controller/test_trajectory_actions", at 0x55d0f58ac324, in _start
#25   Object "/usr/lib/x86_64-linux-gnu/libc.so.6", at 0x70aada2c4e3f, in __libc_start_main
#24   Object "/usr/lib/x86_64-linux-gnu/libc.so.6", at 0x70aada2c4d8f, in
#23   Object "/ws/build/joint_trajectory_controller/test_trajectory_actions", at 0x55d0f58abd31, in main
#22   Object "/ws/build/joint_trajectory_controller/test_trajectory_actions", at 0x55d0f592177e, in testing::UnitTest::Run()
#21   Object "/ws/build/joint_trajectory_controller/test_trajectory_actions", at 0x55d0f592155a, in testing::internal::UnitTestImpl::RunAllTests()
#20   Object "/ws/build/joint_trajectory_controller/test_trajectory_actions", at 0x55d0f5920fdc, in testing::TestSuite::Run()
#19   Object "/ws/build/joint_trajectory_controller/test_trajectory_actions", at 0x55d0f5920ef4, in testing::TestInfo::Run()
#18   Object "/ws/build/joint_trajectory_controller/test_trajectory_actions", at 0x55d0f5920d20, in testing::Test::Run()
#17   Object "/ws/build/joint_trajectory_controller/test_trajectory_actions", at 0x55d0f592d3f0, in void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*)
#16   Object "/ws/build/joint_trajectory_controller/test_trajectory_actions", at 0x55d0f58db393, in TestTrajectoryActionsTestParameterized::SetUp()
#15   Object "/ws/build/joint_trajectory_controller/test_trajectory_actions", at 0x55d0f58daa4c, in test_trajectory_controllers::TrajectoryControllerTest::SetUp()
#14   Object "/opt/ros/iron/lib/librclcpp.so", at 0x70aada8dc827, in rclcpp::Node::Node(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, rclcpp::NodeOptions const&)
#13   Object "/opt/ros/iron/lib/librclcpp.so", at 0x70aada8db027, in rclcpp::Node::Node(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, rclcpp::NodeOptions const&)
#12   Object "/opt/ros/iron/lib/librclcpp.so", at 0x70aada8dabe2, in rclcpp::node_interfaces::NodeBase::NodeBase(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::shared_ptr<rclcpp::Context>, rcl_node_options_s const&, bool, bool, std::shared_ptr<rclcpp::CallbackGroup>)
#11   Object "/opt/ros/iron/lib/librcl.so", at 0x70aada78f0da, in rcl_node_init
#10   Object "/opt/ros/iron/lib/librcl.so", at 0x70aada78e939, in
#9    Object "/opt/ros/iron/lib/librcl.so", at 0x70aada78e045, in rcl_publisher_init
#8    Object "/ws/install/rmw_zenoh_cpp/lib/librmw_zenoh_cpp.so", at 0x70aad8c20fe5, in rmw_create_publisher
#7    Object "/ws/install/rmw_zenoh_cpp/lib/librmw_zenoh_cpp.so", at 0x70aad8c1332b, in std::_Deque_base<std::unique_ptr<rmw_zenoh_cpp::rmw_zenoh_event_status_t, std::default_delete<rmw_zenoh_cpp::rmw_zenoh_event_status_t> >, std::allocator<std::unique_ptr<rmw_zenoh_cpp::rmw_zenoh_event_status_t, std::default_delete<rmw_zenoh_cpp::rmw_zenoh_event_status_t> > > >::_M_initialize_map(unsigned long) [clone .constprop.0]
#6    Object "/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30", at 0x70aada59498b, in operator new(unsigned long)
#5    Object "/usr/lib/x86_64-linux-gnu/libc.so.6", at 0x70aada3403db, in malloc
#4    Object "/usr/lib/x86_64-linux-gnu/libc.so.6", at 0x70aada33bcfb, in
#3    Object "/usr/lib/x86_64-linux-gnu/libc.so.6", at 0x70aada324675, in
#2    Object "/usr/lib/x86_64-linux-gnu/libc.so.6", at 0x70aada2c37f2, in abort
#1    Object "/usr/lib/x86_64-linux-gnu/libc.so.6", at 0x70aada2dd475, in raise
#0    Object "/usr/lib/x86_64-linux-gnu/libc.so.6", at 0x70aada3319fc, in pthread_kill
Aborted (Signal sent by tkill() 4313 0)

I continued to search this fault and its cause. And at the moment i just can say that segmentation fault occurs at this line of one of joint_trajectory_controller package's test files
Furthermore, i run only failed test case of joint_trajectory_controller with gdb debug and result is below.
[Thread 0x7904777fe640 (LWP 20062) exited]
[       OK ] OnlyEffortTrajectoryControllers/TestTrajectoryActionsTestParameterized.test_allow_nonzero_velocity_at_trajectory_end_true/0 (2017 ms)
[ RUN      ] OnlyEffortTrajectoryControllers/TestTrajectoryActionsTestParameterized.test_allow_nonzero_velocity_at_trajectory_end_true/1
malloc(): unaligned tcache chunk detected

Thread 1 "test_trajectory" received signal SIGABRT, Aborted.
__pthread_kill_implementation (no_tid=0, signo=6, threadid=133060925205056) at ./nptl/pthread_kill.c:44
44	./nptl/pthread_kill.c: No such file or directory.
(gdb) backtrace
#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=133060925205056) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=6, threadid=133060925205056) at ./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=133060925205056, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3  0x00007904a997b476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4  0x00007904a99617f3 in __GI_abort () at ./stdlib/abort.c:79
#5  0x00007904a99c2676 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7904a9b14b77 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#6  0x00007904a99d9cfc in malloc_printerr (str=str@entry=0x7904a9b17d20 "malloc(): unaligned tcache chunk detected") at ./malloc/malloc.c:5664
#7  0x00007904a99de3dc in tcache_get (tc_idx=<optimized out>) at ./malloc/malloc.c:3195
#8  __GI___libc_malloc (bytes=512) at ./malloc/malloc.c:3313
#9  0x00007904a9c3298c in operator new(unsigned long) () from /lib/x86_64-linux-gnu/libstdc++.so.6
#10 0x00007904a8229b58 in __gnu_cxx::new_allocator<std::unique_ptr<rmw_zenoh_cpp::rmw_zenoh_event_status_t, std::default_delete<rmw_zenoh_cpp::rmw_zenoh_event_status_t> > >::allocate (
    this=0x6105b6da66d0, __n=64) at /usr/include/c++/11/ext/new_allocator.h:127
#11 0x00007904a822946f in std::allocator_traits<std::allocator<std::unique_ptr<rmw_zenoh_cpp::rmw_zenoh_event_status_t, std::default_delete<rmw_zenoh_cpp::rmw_zenoh_event_status_t> > > >::allocate (
    __a=..., __n=64) at /usr/include/c++/11/bits/alloc_traits.h:464
#12 0x00007904a8228dfe in std::_Deque_base<std::unique_ptr<rmw_zenoh_cpp::rmw_zenoh_event_status_t, std::default_delete<rmw_zenoh_cpp::rmw_zenoh_event_status_t> >, std::allocator<std::unique_ptr<rmw_zenoh_cpp::rmw_zenoh_event_status_t, std::default_delete<rmw_zenoh_cpp::rmw_zenoh_event_status_t> > > >::_M_allocate_node (this=0x6105b6da66d0) at /usr/include/c++/11/bits/stl_deque.h:562
#13 0x00007904a829718b in std::_Deque_base<std::unique_ptr<rmw_zenoh_cpp::rmw_zenoh_event_status_t, std::default_delete<rmw_zenoh_cpp::rmw_zenoh_event_status_t> >, std::allocator<std::unique_ptr<rmw_zenoh_cpp::rmw_zenoh_event_status_t, std::default_delete<rmw_zenoh_cpp::rmw_zenoh_event_status_t> > > >::_M_create_nodes (this=0x6105b6da66d0, __nstart=0x6105b6d31f88, __nfinish=0x6105b6d31f90)
    at /usr/include/c++/11/bits/stl_deque.h:663
#14 0x00007904a82959cc in std::_Deque_base<std::unique_ptr<rmw_zenoh_cpp::rmw_zenoh_event_status_t, std::default_delete<rmw_zenoh_cpp::rmw_zenoh_event_status_t> >, std::allocator<std::unique_ptr<rmw_zenoh_cpp::rmw_zenoh_event_status_t, std::default_delete<rmw_zenoh_cpp::rmw_zenoh_event_status_t> > > >::_M_initialize_map (this=0x6105b6da66d0, __num_elements=0) at /usr/include/c++/11/bits/stl_deque.h:637
#15 0x00007904a82947f4 in std::_Deque_base<std::unique_ptr<rmw_zenoh_cpp::rmw_zenoh_event_status_t, std::default_delete<rmw_zenoh_cpp::rmw_zenoh_event_status_t> >, std::allocator<std::unique_ptr<rmw_zenoh_cpp::rmw_zenoh_event_status_t, std::default_delete<rmw_zenoh_cpp::rmw_zenoh_event_status_t> > > >::_Deque_base (this=0x6105b6da66d0) at /usr/include/c++/11/bits/stl_deque.h:439
#16 0x00007904a8293772 in std::deque<std::unique_ptr<rmw_zenoh_cpp::rmw_zenoh_event_status_t, std::default_delete<rmw_zenoh_cpp::rmw_zenoh_event_status_t> >, std::allocator<std::unique_ptr<rmw_zenoh_cpp::rmw_zenoh_event_status_t, std::default_delete<rmw_zenoh_cpp::rmw_zenoh_event_status_t> > > >::deque (this=0x6105b6da66d0) at /usr/include/c++/11/bits/stl_deque.h:834
#17 0x00007904a8293b11 in rmw_zenoh_cpp::EventsManager::EventsManager (this=0x6105b6da64e0) at /ws/src/rmw_zenoh/rmw_zenoh_cpp/src/detail/event.hpp:111
--Type <RET> for more, q to quit, c to continue without paging--
#18 0x00007904a8293de9 in rmw_zenoh_cpp::rmw_publisher_data_t::rmw_publisher_data_t (this=0x6105b6da63e0) at /ws/src/rmw_zenoh/rmw_zenoh_cpp/src/detail/rmw_data_types.hpp:88
#19 0x00007904a827e5b7 in rmw_create_publisher (node=0x6105b7204720, type_supports=0x7904a95bdb80, topic_name=0x6105b6e442b0 "/rosout", qos_profile=0x7fff652e1eb0, publisher_options=0x7fff652e1f30)
    at /ws/src/rmw_zenoh/rmw_zenoh_cpp/src/rmw_zenoh.cpp:504
#20 0x00007904a9e2c046 in rcl_publisher_init (publisher=publisher@entry=0x7fff652e1ea8, node=node@entry=0x6105b710d3c0, type_support=type_support@entry=0x7904a95bdb80,
    topic_name=topic_name@entry=0x7904a9e3c950 "/rosout", options=options@entry=0x7fff652e1eb0) at ./src/rcl/publisher.c:111
#21 0x00007904a9e2c93a in rcl_logging_rosout_init_publisher_for_node (node=node@entry=0x6105b710d3c0) at ./src/rcl/logging_rosout.c:275
#22 0x00007904a9e2cb12 in rcl_logging_rosout_init_publisher_for_node (node=node@entry=0x6105b710d3c0) at ./src/rcl/logging_rosout.c:235
#23 0x00007904a9e2d0db in rcl_node_init (node=0x6105b710d3c0, name=<optimized out>, namespace_=<optimized out>, context=0x6105b6afedb0, options=0x6105b6e00120) at ./src/rcl/node.c:297
#24 0x00007904a9f78be3 in rclcpp::node_interfaces::NodeBase::NodeBase(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::shared_ptr<rclcpp::Context>, rcl_node_options_s const&, bool, bool, std::shared_ptr<rclcpp::CallbackGroup>) () from /opt/ros/iron/lib/librclcpp.so
#25 0x00007904a9f79028 in rclcpp::Node::Node(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, rclcpp::NodeOptions const&) () from /opt/ros/iron/lib/librclcpp.so
#26 0x00007904a9f7a828 in rclcpp::Node::Node(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, rclcpp::NodeOptions const&) () from /opt/ros/iron/lib/librclcpp.so
#27 0x00006105b4ce597b in __gnu_cxx::new_allocator<rclcpp::Node>::construct<rclcpp::Node, char const (&) [22]> (this=0x7fff652e8fcf, __p=0x6105b71d5d30) at /usr/include/c++/11/ext/new_allocator.h:162
#28 0x00006105b4ce09b0 in std::allocator_traits<std::allocator<rclcpp::Node> >::construct<rclcpp::Node, char const (&) [22]> (__a=..., __p=0x6105b71d5d30) at /usr/include/c++/11/bits/alloc_traits.h:516
#29 0x00006105b4cda9b2 in std::_Sp_counted_ptr_inplace<rclcpp::Node, std::allocator<rclcpp::Node>, (__gnu_cxx::_Lock_policy)2>::_Sp_counted_ptr_inplace<char const (&) [22]> (this=0x6105b71d5d20, __a=...)
    at /usr/include/c++/11/bits/shared_ptr_base.h:519
#30 0x00006105b4cd1ba4 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::__shared_count<rclcpp::Node, std::allocator<rclcpp::Node>, char const (&) [22]> (this=0x7fff652e9178, __p=@0x7fff652e9170: 0x0,
    __a=...) at /usr/include/c++/11/bits/shared_ptr_base.h:650
#31 0x00006105b4cc832c in std::__shared_ptr<rclcpp::Node, (__gnu_cxx::_Lock_policy)2>::__shared_ptr<std::allocator<rclcpp::Node>, char const (&) [22]> (this=0x7fff652e9170, __tag=...)
    at /usr/include/c++/11/bits/shared_ptr_base.h:1342
#32 0x00006105b4cbce55 in std::shared_ptr<rclcpp::Node>::shared_ptr<std::allocator<rclcpp::Node>, char const (&) [22]> (this=0x7fff652e9170, __tag=...) at /usr/include/c++/11/bits/shared_ptr.h:409
#33 0x00006105b4caf263 in std::allocate_shared<rclcpp::Node, std::allocator<rclcpp::Node>, char const (&) [22]> (__a=...) at /usr/include/c++/11/bits/shared_ptr.h:863
#34 0x00006105b4ca25e5 in std::make_shared<rclcpp::Node, char const (&) [22]> () at /usr/include/c++/11/bits/shared_ptr.h:879
#35 0x00006105b4c925dc in test_trajectory_controllers::TrajectoryControllerTest::SetUp (this=0x6105b6b84ac0)
    at /ws/src/ros-controls/ros2_controllers/joint_trajectory_controller/test/test_trajectory_controller_utils.hpp:207
--Type <RET> for more, q to quit, c to continue without paging--
#36 0x00006105b4c96539 in TestTrajectoryActions::SetUp (this=0x6105b6b84ac0) at /ws/src/ros-controls/ros2_controllers/joint_trajectory_controller/test/test_trajectory_actions.cpp:62
#37 0x00006105b4c97cec in TestTrajectoryActionsTestParameterized::SetUp (this=0x6105b6b84ac0) at /ws/src/ros-controls/ros2_controllers/joint_trajectory_controller/test/test_trajectory_actions.cpp:211
#38 0x00006105b4d3e32b in testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void> (object=0x6105b6b84ac0, method=&virtual testing::Test::SetUp(), location=0x6105b4d6afe3 "SetUp()")
    at /opt/ros/iron/src/gtest_vendor/src/gtest.cc:2433
#39 0x00006105b4d379b5 in testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void> (object=0x6105b6b84ac0, method=&virtual testing::Test::SetUp(), location=0x6105b4d6afe3 "SetUp()")
    at /opt/ros/iron/src/gtest_vendor/src/gtest.cc:2469
#40 0x00006105b4d1210a in testing::Test::Run (this=0x6105b6b84ac0) at /opt/ros/iron/src/gtest_vendor/src/gtest.cc:2503
#41 0x00006105b4d12bc9 in testing::TestInfo::Run (this=0x6105b6b29350) at /opt/ros/iron/src/gtest_vendor/src/gtest.cc:2684
#42 0x00006105b4d1332a in testing::TestSuite::Run (this=0x6105b6b177d0) at /opt/ros/iron/src/gtest_vendor/src/gtest.cc:2816
#43 0x00006105b4d1f949 in testing::internal::UnitTestImpl::RunAllTests (this=0x6105b6b12b90) at /opt/ros/iron/src/gtest_vendor/src/gtest.cc:5338
#44 0x00006105b4d3f3b2 in testing::internal::HandleSehExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> (object=0x6105b6b12b90,
    method=(bool (testing::internal::UnitTestImpl::*)(testing::internal::UnitTestImpl * const)) 0x6105b4d1f552 <testing::internal::UnitTestImpl::RunAllTests()>,
    location=0x6105b4d6b9a0 "auxiliary test code (environments or event listeners)") at /opt/ros/iron/src/gtest_vendor/src/gtest.cc:2433
#45 0x00006105b4d38c07 in testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> (object=0x6105b6b12b90,
    method=(bool (testing::internal::UnitTestImpl::*)(testing::internal::UnitTestImpl * const)) 0x6105b4d1f552 <testing::internal::UnitTestImpl::RunAllTests()>,
    location=0x6105b4d6b9a0 "auxiliary test code (environments or event listeners)") at /opt/ros/iron/src/gtest_vendor/src/gtest.cc:2469
#46 0x00006105b4d1e12b in testing::UnitTest::Run (this=0x6105b4de6b00 <testing::UnitTest::GetInstance()::instance>) at /opt/ros/iron/src/gtest_vendor/src/gtest.cc:4925
#47 0x00006105b4d098e4 in RUN_ALL_TESTS () at /opt/ros/iron/src/gtest_vendor/include/gtest/gtest.h:2473
#48 0x00006105b4d0985d in main (argc=1, argv=0x7fff652e9958) at /opt/ros/iron/src/gmock_vendor/src/gmock_main.cc:63
(gdb)

Finally i want to add that, i also ran MoveIt test cases with both rmw_zenoh_cpp and rmw_fastrtps_cpp middlewares. It is surprising that the execution with rmw_zenoh gives less failures in test cases than the execution with rmw_fastrtps.  Here is results.
the execution of moveit test cases with rmw_zenoh
root@9a64dbcea29c:/ws# colcon test-result
build/moveit_kinematics/Testing/20240528-1747/Test.xml: 4 tests, 0 errors, 4 failures, 0 skipped
build/moveit_kinematics/test_results/moveit_kinematics/test_launch_fanuc-kdl-singular.test.py.xunit.xml: 2 tests, 0 errors, 1 failure, 0 skipped
build/moveit_kinematics/test_results/moveit_kinematics/test_launch_fanuc-kdl.test.py.xunit.xml: 2 tests, 0 errors, 1 failure, 0 skipped
build/moveit_kinematics/test_results/moveit_kinematics/test_launch_panda-kdl-singular.test.py.xunit.xml: 2 tests, 0 errors, 1 failure, 0 skipped
build/moveit_kinematics/test_results/moveit_kinematics/test_launch_panda-kdl.test.py.xunit.xml: 2 tests, 0 errors, 1 failure, 0 skipped
build/moveit_ros_tests/Testing/20240528-1748/Test.xml: 1 test, 0 errors, 1 failure, 0 skipped
build/moveit_ros_tests/test_results/moveit_ros_tests/launch_move_group_api.test.py.xunit.xml: 1 test, 1 error, 0 failures, 0 skipped
build/moveit_servo/Testing/20240528-1748/Test.xml: 3 tests, 0 errors, 2 failures, 0 skipped
build/moveit_servo/test_results/moveit_servo/tests_launch_servo_cpp_integration.test.py.xunit.xml: 2 tests, 0 errors, 1 failure, 0 skipped
build/moveit_servo/test_results/moveit_servo/tests_launch_servo_ros_integration.test.py.xunit.xml: 2 tests, 0 errors, 1 failure, 0 skipped

Summary: 683 tests, 1 error, 13 failures, 59 skipped

the execution of moveit test cases with rmw_fastrtps
root@9a64dbcea29c:/ws# colcon test-result
build/moveit_core/Testing/20240528-1750/Test.xml: 32 tests, 0 errors, 4 failures, 2 skipped
build/moveit_core/test_results/moveit_core/test-node_logging.xunit.xml: 2 tests, 0 errors, 1 failure, 0 skipped
build/moveit_kinematics/Testing/20240528-1751/Test.xml: 4 tests, 0 errors, 4 failures, 0 skipped
build/moveit_kinematics/test_results/moveit_kinematics/test_launch_fanuc-kdl-singular.test.py.xunit.xml: 2 tests, 0 errors, 1 failure, 0 skipped
build/moveit_kinematics/test_results/moveit_kinematics/test_launch_fanuc-kdl.test.py.xunit.xml: 2 tests, 0 errors, 1 failure, 0 skipped
build/moveit_kinematics/test_results/moveit_kinematics/test_launch_panda-kdl-singular.test.py.xunit.xml: 2 tests, 0 errors, 1 failure, 0 skipped
build/moveit_kinematics/test_results/moveit_kinematics/test_launch_panda-kdl.test.py.xunit.xml: 2 tests, 0 errors, 1 failure, 0 skipped
build/moveit_planners_ompl/Testing/20240528-1751/Test.xml: 6 tests, 0 errors, 1 failure, 0 skipped
build/moveit_ros_planning/Testing/20240528-1751/Test.xml: 5 tests, 0 errors, 1 failure, 0 skipped
build/moveit_servo/Testing/20240528-1751/Test.xml: 3 tests, 0 errors, 2 failures, 0 skipped
build/moveit_servo/test_results/moveit_servo/tests_launch_servo_cpp_integration.test.py.xunit.xml: 2 tests, 0 errors, 1 failure, 0 skipped
build/moveit_servo/test_results/moveit_servo/tests_launch_servo_utils.test.py.xunit.xml: 2 tests, 0 errors, 1 failure, 0 skipped
build/moveit_setup_app_plugins/Testing/20240528-1751/Test.xml: 1 test, 0 errors, 1 failure, 0 skipped
build/moveit_setup_controllers/Testing/20240528-1751/Test.xml: 1 test, 0 errors, 1 failure, 0 skipped
build/moveit_setup_srdf_plugins/Testing/20240528-1751/Test.xml: 1 test, 0 errors, 1 failure, 0 skipped
build/pilz_industrial_motion_planner/Testing/20240528-1751/Test.xml: 17 tests, 0 errors, 10 failures, 0 skipped
build/pilz_industrial_motion_planner/test_results/pilz_industrial_motion_planner/test_unit_tests_launch_unittest_joint_limits_aggregator.test.py.xunit.xml: 1 test, 1 error, 0 failures, 0 skipped
build/pilz_industrial_motion_planner/test_results/pilz_industrial_motion_planner/test_unit_tests_launch_unittest_pilz_industrial_motion_planner.test.py.xunit.xml: 2 tests, 0 errors, 1 failure, 0 skipped
build/pilz_industrial_motion_planner/test_results/pilz_industrial_motion_planner/test_unit_tests_launch_unittest_planning_context.test.py.xunit.xml: 2 tests, 0 errors, 1 failure, 0 skipped
build/pilz_industrial_motion_planner/test_results/pilz_industrial_motion_planner/test_unit_tests_launch_unittest_planning_context_loaders.test.py.xunit.xml: 2 tests, 0 errors, 1 failure, 0 skipped
build/pilz_industrial_motion_planner/test_results/pilz_industrial_motion_planner/test_unit_tests_launch_unittest_trajectory_blender_transition_window.test.py.xunit.xml: 1 test, 1 error, 0 failures, 0 skipped
build/pilz_industrial_motion_planner/test_results/pilz_industrial_motion_planner/test_unit_tests_launch_unittest_trajectory_functions.test.py.xunit.xml: 2 tests, 0 errors, 1 failure, 0 skipped
build/pilz_industrial_motion_planner/test_results/pilz_industrial_motion_planner/test_unit_tests_launch_unittest_trajectory_generator_circ.test.py.xunit.xml: 2 tests, 0 errors, 1 failure, 0 skipped
build/pilz_industrial_motion_planner/test_results/pilz_industrial_motion_planner/test_unit_tests_launch_unittest_trajectory_generator_common.test.py.xunit.xml: 1 test, 1 error, 0 failures, 0 skipped
build/pilz_industrial_motion_planner/test_results/pilz_industrial_motion_planner/test_unit_tests_launch_unittest_trajectory_generator_lin.test.py.xunit.xml: 1 test, 1 error, 0 failures, 0 skipped
build/pilz_industrial_motion_planner/test_results/pilz_industrial_motion_planner/test_unit_tests_launch_unittest_trajectory_generator_ptp.test.py.xunit.xml: 1 test, 1 error, 0 failures, 0 skipped

Summary: 679 tests, 5 errors, 37 failures, 59 skipped

That's all at the moment in testing side. I need to work more on this errors to give more information about that subject.

For benchmarking, i just have created this repository in my account and i will develop benchmark code on this repository until the end of GSOC project. Here is our repository. I give a link for those who wanted to track the zenoh benchmarking progress.
https://github.com/CihatAltiparmak/moveit_middleware_benchmark
I need to refactor some part of repository at the moment, however i will. We want that our benchmarks is based on rmw_zenoh. Whereas we can switch to dds-based middleware + zenoh_dds_bridge combination rather than rmw_zenoh due to the fact that rmw_zenoh is the experimental middleware and still has some bugs. This doesn't mean that our benchmark is not based on rmw_zenoh. We will continue to track the development progress of rmw_zenoh closely. Maybe we can fail in this progress in side of benchmark of rmw_zenoh but i will try to implement this benchmark codes in a way it can be able to runnable even after GSOC project.

Hello all,
We want to share some updates related to this project.
Integration of zenoh to MoveIt
When we ran MoveIt with rmw_zenoh middleware, we observed some stuck in the action clients and this stuck occurs due to rmw_wait having a data race. This seems related to rmw_zenoh, not MoveIt. Additionaly, the reason of this stuck seems MultiThreadedExecutor. rmw_zenoh seems to work without problem with SingleThreadedExecutor but  has problems with MultiThreadedExecutor. For those seeking more information about this problem, here is some additional content. It should also be mentioned that navigation2 works well with rmw_zenoh. when I searched whether navigation2 uses MultiThreadedExecutor,  i saw that navigation2 doesn't use MultiThreadedExecutor but uses SingleThreadedExecutor while MoveIt uses MultiThreadedExecutor in some part of code. Furthermore, this stucks helped us to discover some bad implementations inside MoveIt. I'm still working on a better implementation. We also discussed trying rmw_zenoh in MoveIt, modified in a  way to use another private node spinning technique instead of MultiThreadedExecutor, both to avoid breaking the original MoveIt flow and to enable the use of rmw_zenoh without problem. By the way there are two upstream in rmw_zenoh to fix this bug. I tried it but yet to run with MoveIt. You can find these upstreams here.
Benchmarking
We also are also working on benchmarking the effects of middleware in MoveIt. We implemented the benchmark code for perception pipeline in this development branch. We will add more scenario to this repository.

Hello all,
In today's meeting, one of the topics we talked about was rmw_zenoh integration to MoveIt. I was able to successfully run MoveIt using rmw zenoh with some modifications. You can visit this draft pull request. to see what's changed. However i must say that this is experimental pull request and it can be observed some unexpected effects. In order to run MoveIt using rmw_zenoh, you can use my fork at the moment. I am still waiting for better rmw_wait implementation and following rmw_zenoh progress.
For benchmarking, unfortunately we have some problems. I don't want to share middleware benchmarking results for perception pipeline scenario at the moment and we are investigating it. CPU time is more less than Real Time in our benchmarking results. That's problem.

Hello everyone,
I want to share some updates about benchmarking side. The development of benchmarking tool is still being developed rollingly by us. I conducted some benchmarks for two scenarios, one of them is a basic service-client benchmark and other one is perception pipeline. You can take a look at some documentation here to get what corresponding scenario aims. Seems like rmw_zenoh is as fast as rmw_fastrtps with some configurations in tcp. I strongly suggest you to visit this thread in Zenoh's discord community.
sudo sysctl -w "net.ipv4.tcp_rmem=4096 4096 4096"
sudo sysctl -w "net.ipv4.tcp_wmem=4096 4096 4096"
sudo sysctl -w "net.ipv4.tcp_mem=4096 4096 4096"

This is the initial benchmark results:

I couldn't understand why rmw_zenoh is dramatically slower than rmw_fastrtps. I will investigate this problem. But i should also say that rmw_zenoh defaultly uses TCP whereas rmw_cyclonedds uses UDP. I will conduct this benchmarks by configuring rmw_zenoh to UDP and let you to know it in second post.
I have also worked on visualization side and CI side to conduct benchmarks in github CI. This website doesn't present the real benchmarking results. It's just for dummy visualization. When we merge other PR's in moveit_middleware_benchmark repository, we will be able to start to get some visualizations. Here is the example website. https://darkusalphahydranoid.github.io/moveit_middleware_benchmark_experimental
By the way you can try our benchmark tool by pulling its docker image like below.
Terminal 1
docker pull ghcr.io/cihataltiparmak/moveit_middleware_benchmark:latest
# run docker image
# inside docker
cd /ws_moveit
source /opt/ros/rolling/setup.bash
source install/setup.bash
export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 launch moveit_middleware_benchmark scenario_basic_service_client_benchmark.launch.py

Terminal 2
docker exec -it <container_id> bash
# inside docker
cd /ws_moveit
source /opt/ros/rolling/setup.bash
source install/setup.bash
export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

Don't be hesitate to ask me about anything related to this GSOC project (benchmarking, bugs in rmw_zenoh and so on). I'm ready to answer you. This is my mail<EMAIL_ADDRESS>


Update CHANGELOG for v0.8.1 release

/skip-all

Superseded by https://github.com/vmware-tanzu/antrea/pull/954


extra semicolon in prv_refreshServerList API

prv_refreshServerList API has extra semicolon in the following line.
contextP->serverList = (lwm2m_server_t *)LWM2M_LIST_ADD(contextP->serverList, targetP);;

Fixed by #218


New Rule : detect usages of Log.ForContext in class ClassY

This has happened to me a few times already to find this kind of code, as a result of excessive copy/pasting :
public class SuperDuperClass{
    private static readonly ILogger Logger = Log.ForContext<AnotherUnrelatedClass>();
    // snip
}

i.e. cases where the SourceContext will end up not matching the actual containing class. This is quite annoying when you are, later on, trying to figure out the origin of a log event.
It would be nice if we could detect those mismatches and suggest a fix.

Indeed 👍 i've tripped on this on several occasions as well.
Where should this apply? only on directly initialized private variables?
What happens if multiple ILogger variables are declared and initialized?

I would say limiting it to private static directly initialized variables covers the most common pattern, but when there are several I guess one can no longer guess the intent.
I'm not too sure about how it's done in the .NET Core / ASP.NET Core with DI etc ... Do people still declare a static property  or do they rely solely on constructor injection ? and in that case, at what point is the SourceContext specified ?

@Suchiman oh ok. I wonder if it makes sense to have a similar check for those cases then ....
public class SuperDuperClass{
    public SuperDuperClass(ILogger<AnotherUnrelatedClass> logger)
    {
        //snip
    }
}

Handy analysis! 👍
I don't always use static, but in Serilog code often have per-instance loggers:
    readonly ILogger _log = Log.ForContext<X>();

so I think checking either static or instance fields would be useful :-)
The ASP.NET case might be a good one for https://github.com/aspnet/Logging/tree/dev/src/Microsoft.Extensions.Logging.Analyzers ( @pakrym was looking for analysis suggestions a few weeks ago).

Thanks !


Remove the EmptyOp for BroadcastOp as it will be folded.

I see that @mtopalovicTT added the following trait with Empty Op after which remove-dead-value is deleting the dead EmptyOp.
https://github.com/tenstorrent/tt-mlir/pull/857/commits/c26e8d9a4b43dc8d64b850d4e70f09d79bc40649
Closing this PR as it is no longer needed.

Hey everyone, I've just now caught up with this PR. I see you've figured everything out, it's unfortunate that I was out last week and couldn't clear things up sooner 🥲
I've mentioned this in F2F meeting btw, that empty op cannot be optimized out because of NoMemoryEffect trait so we discussed if we can add it, and that LLVM issue is being fixed, thanks @mtopalovicTT for catching all that!


Publishing: Auto close nexus staging repository in CI

Wildly untested 😅 . To be tested during the next release

I don't know if it'll work too :D but we'll test it at the next release! :)


Add README to yii plugin

What does this PR do?
Add README to yii plugin
Description of Task to be completed?

Create a README file in the yii plugin directory.
Add documentation on how to use the yii plugin

How should this be manually tested?

View README file in yii plugin directory.

This contributes to #7175

Thanks, Ekunola


#2804 Added shipyardVersion property to GET /project response

Closes #2804
Signed-off-by: Florian Bacher<EMAIL_ADDRESS>

Codecov Report

Merging #2900 (77f36ff) into master (15a8368) will decrease coverage by 4.76%.
The diff coverage is 45.45%.

@@            Coverage Diff             @@
##           master    #2900      +/-   ##
==========================================
- Coverage   36.34%   31.57%   -4.77%
==========================================
  Files         104        6      -98
  Lines        6472      627    -5845
  Branches      197        0     -197
==========================================
- Hits         2352      198    -2154
+ Misses       3812      408    -3404
+ Partials      308       21     -287

Flag
Coverage Δ

moduleA
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...ation-service/common/projects_materialized_view.go
71.30% <45.45%> (-2.43%)
:arrow_down:

bridge/client/app/_models/approval-states.ts

distributor/cmd/main.go

...ouse-service/event_handler/evaluate_sli_handler.go

shipyard-controller/common/secret_store.go

...uation-details/ktb-evaluation-details.component.ts

lighthouse-service/event_handler/common.go

jmeter-service/common.go

...notification-bar/ktb-notification-bar.component.ts

helm-service/controller/handler_base.go

... and 89 more

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 15a8368...5295e2c. Read the comment docs.

Codecov Report

Merging #2900 (77f36ff) into master (15a8368) will decrease coverage by 4.76%.
The diff coverage is 45.45%.

@@            Coverage Diff             @@
##           master    #2900      +/-   ##
==========================================
- Coverage   36.34%   31.57%   -4.77%
==========================================
  Files         104        6      -98
  Lines        6472      627    -5845
  Branches      197        0     -197
==========================================
- Hits         2352      198    -2154
+ Misses       3812      408    -3404
+ Partials      308       21     -287

Flag
Coverage Δ

moduleA
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...ation-service/common/projects_materialized_view.go
71.30% <45.45%> (-2.43%)
:arrow_down:

bridge/client/app/_models/approval-states.ts

distributor/cmd/main.go

...ouse-service/event_handler/evaluate_sli_handler.go

shipyard-controller/common/secret_store.go

...uation-details/ktb-evaluation-details.component.ts

lighthouse-service/event_handler/common.go

jmeter-service/common.go

...notification-bar/ktb-notification-bar.component.ts

helm-service/controller/handler_base.go

... and 89 more

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 15a8368...5295e2c. Read the comment docs.


Metadata editing not enabled by default

When I create a new Markdown document, the metadata button on the right is not enabled by default. Nor is the "Published" button, which operates on the metadata.
If I edit an existing document with a pre-existing front matter, these UI elements are made available.
But I'd like them to be made available by default with new documents.
I had a look at the configuration options, and I think there might be a way to get this working for files that live under a directory. But I am trying to do this for files that live in the top level directory.

Hello and thank you for this issue report. There have been several point releases in Prose since this issue was opened and there has not been much discussion here. I wanted to ask if you could please assist in confirming this is still an issue in the latest version of the product. If it is fixed, please close this issue :-)
Also, if possible could you please

Find out if this only affects certain browsers
Create a test case -- a list of steps we can perform to reproduce the problem
Enable web developer extensions and report the Javascript error message. And when in doubt, be over-descriptive of the bug and how you discovered it.

Since this project is looking for new maintainers (#743), it will be helpful if users can double check the old issues and delete ones that are fixed. This will be super helpful for the new team that works on moving this project forward.
I'm sorry this message is impersonal. And thanks for your help!

Main issue here is closed. Tracking the published button/metadata editor issue in  #869


Corr matrix

Implement calculation and processing of correlation matrix
add type hints
add docstring (reStructuredText format)

closes #18

Looks generally good to me. We might discuss for each of the methods how it returns the result (as attribute of the curr object (with self. method) or as normal return).

Good point. I think for this function, I assumed we would not use the returned object for further analysis, only for saving it, so thought just returning it would make sense.


Move addCheckedFunction from server.js to utils.js

This PR:

moves the addCheckedFunction from server.js to utils.js
documents the addCheckedFunction

@alex-ju mind if I close in favour of #449 ? Thanks for your work that fed into that!

@joelanman not at all. #449 looks good, just reviewed.


Markdown Preview does not preserve scroll position

VSCode Version: 1.10.2
OS Version: Ubuntu 14.04

Steps to Reproduce:

Open a Markdown file.
Open the preview (ctrl+shift+v).
Close the Markdown file tab (not the preview).
Scroll a few times in the preview tab.
Open any other file.
Go to the preview tab again. Notice that the scrollbar is reset to top.

My suggestion is that the scroll position of Markdown preview tab should follow its corresponding raw Markdown tab's only if the raw Markdown tab is present. If it is not present, the preview tab should preserve the last scroll position.

VSCode Version: 1.11.1
OS Version: Ubuntu 14.04

Steps to Reproduce:

Open a Markdown file, place cursor anywhere in file other than the top
Open the Preview (ctrl+shift+v).

More generally than above, the "Preview" tool now (unlike previously) always resets to the top of the markdown file when you open it or go to its tab and it refreshes (or you press ctrl+shift+v). It no longer goes to the current edit (cursor) location in the raw file. It is inconvenient to repeatedly scroll down to the current edit location in long files, to preview the changes.
I'm pretty sure I skipped a couple of version updates until I installed 1.11.1 today (4/9/2017), so I'm not sure when the behavior changed, but it was fairly recent, my version was not too outdated, no more than two or three updates.

Same behavior

VSCode Version: 1.12.0-insider
OS Version: Ubuntu 16.04

Re https://github.com/Microsoft/vscode/issues/22279, run into this issue while following the guidance of the project.

@rebornix Can we try debugging through the issue on your machine this afternoon?

I have the same problem as outlined by @slfuqua.

VS Code 1.11.2
macOS 10.11.6

It worked okay in earlier versions of VS Code (I believe it worked okay in 1.10.x).

For anyone seeing this problem, #24985 just added some basic logging to help investigate. The change be in the next insiders build. Once that is released, please download it and:

Set "markdown.trace": "verbose"
Reproduce the issue
Go to the output pane and share the output from the Markdown section

This should help me investigate what may be going wrong here

@mjbvz Thanks very much for looking into this. Below is my output after setting markdown.trace to verbose in VS Code 1.12.0-insider. The first entry is when I click somewhere in the middle of the markdown document. The second is when I use the preview option (which still shows the very top of the document instead of where my cursor was in the actual markdown document).
[Log - 11:43:07 AM] updatePreviewForSelection
{
  "markdownFile": "markdown:/Users/Charles/Develop/Personnel/BlocNotes/aurelia-snippets.md.rendered?file%3A%2F%2F%2FUsers%2FCharles%2FDevelop%2FPersonnel%2FBlocNotes%2Faurelia-snippets.md"
}
[Log - 11:43:10 AM] provideTextDocumentContent
{
  "previewUri": "markdown:/Users/Charles/Develop/Personnel/BlocNotes/aurelia-snippets.md.rendered?file%3A%2F%2F%2FUsers%2FCharles%2FDevelop%2FPersonnel%2FBlocNotes%2Faurelia-snippets.md",
  "source": "file:///Users/Charles/Develop/Personnel/BlocNotes/aurelia-snippets.md",
  "line": 0,
  "scrollPreviewWithEditorSelection": true,
  "scrollEditorWithPreview": true,
  "doubleClickToSwitchToEditor": true
}

I see that the "line" entry is zero. Maybe the issue is related to that?

Thanks @chaskim!
From your log, I think there's a bug in the markdown preview where using Open Preview instead of Open Preview to Side causes the initial line not to be set. Looking into a fix

Potentially dup of https://github.com/Microsoft/vscode/issues/22420


fix exception

fixes #298

Current coverage is 42.01%

Merging #299 into master will decrease coverage by -0.19% as of e165f97

@@            master    #299   diff @@
======================================
  Files          120     120
  Stmts         2445    2456    +11
  Branches       215     219     +4
  Methods          0       0
======================================
  Hit           1032    1032
- Partial         35      39     +4
- Missed        1378    1385     +7

Review entire Coverage Diff as of e165f97

Powered by Codecov. Updated on successful CI builds.


Validation error when passing an optional integer parameter to child action from action-chain

Summary:
In an action-chain if an optional integer parameter is passed to a child action and the parameter is not supplied while executing the action-chain, it fails with a validation error:
Failed to cast value "None" (type: unicode) for parameter "frequency" of type "integer": invalid literal for int() with base 10: 'None'.

Details
I have the following remote-shell-cmd action
test_update_remote.yaml
---
    name: 'test_update_remote'
    runner_type: 'remote-shell-cmd'
    description: >
        Remote shell command runner to update
    enabled: true
    entry_point: ''
    parameters:
        frequency:
            type: 'integer'
            description: 'Set the update frequency for the source. 0 means no automatic update'
            required: false
        category:
            type: 'string'
            description: 'Set the source category'
            required: false
        cmd:
            immutable: true
            default: 'update {{args}}'
        args:
            description: 'Command line arguments passed to the script'
            default: '{% if frequency %} --frequency {{frequency}}{% endif %} {% if category %} --category {{category}}{% endif %}'
        hosts:
            required: true
            type: string
            description: "The addresses of the host"
            default: "{{ config_context.default_host }}"
        username:
            required: true
            type: string
            description: "The username for logging into the host"
            default: "{{ config_context.default_user }}"

This action is called from within an action chain as defined below:
test_update.yaml
---
    name: 'test_update'
    runner_type: 'action-chain'
    description: 'Update Frequency'
    enabled: true
    entry_point: chains/test_update.yaml
    parameters:
        frequency:
            type: 'integer'
            description: 'update frequency'
            required: false
        category:
            type: 'string'
            description: 'update category'
            required: false

chains/test_update.yaml
---
chain:
-
    name: run_command
    ref: mypack.test_update_remote
    parameters:
        frequency: '{{ frequency }}'
        category: '{{ category }}'

default: run_command

Notice that the parameter frequency is an optional parameter of type integer (required: false).
The action-chain test_update is simply taking all the parameters and passing it to the action test_update_remote as it is.
When the test_update action is run it fails with the following error:
stackstorm-virtualbox$ st2 run -t $TOKEN mypack.test_update category=test
.
id: 5ae89ddd25acbf61121dadba
action.ref: mypack.test_update
parameters:
  category: test
status: failed
error: Failed to cast value "None" (type: unicode) for parameter "frequency" of type "integer": invalid literal for int() with base 10: 'None'. Perhaps the value is of an invalid type?
traceback:   File "/opt/stackstorm/st2/local/lib/python2.7/site-packages/st2actions/container/base.py", line 119, in _do_run
    (status, result, context) = runner.run(action_params)
  File "/opt/stackstorm/runners/action_chain_runner/action_chain_runner/action_chain_runner.py", line 295, in run
    return self._run_chain(action_parameters)
  File "/opt/stackstorm/runners/action_chain_runner/action_chain_runner/action_chain_runner.py", line 486, in _run_chain
    action_params=action_parameters, context_result=context_result)
  File "/opt/stackstorm/runners/action_chain_runner/action_chain_runner/action_chain_runner.py", line 720, in _get_next_action
    parent_context=parent_context)
  File "/opt/stackstorm/runners/action_chain_runner/action_chain_runner/action_chain_runner.py", line 779, in _build_liveaction_object
    params=resolved_params)
  File "/opt/stackstorm/st2/local/lib/python2.7/site-packages/st2common/models/utils/action_param_utils.py", line 128, in cast_params
    raise ValueError(msg)

start_timestamp: Tue, 01 May 2018 17:03:25 UTC
end_timestamp: Tue, 01 May 2018 17:03:25 UTC
result: See error and traceback.

Observations
It appears that when the optional parameter is not supplied to the test_update action, it passes None as expected. However, when the action-chain receives the None values, it evaluates the expression  frequency: '{{ frequency }}' as string "None", which is passed to the test_update_remote action. There it fails the validation since it got a string while it expected an integer.
NOTE:

This works fine if the action-chain is replaced with a mistral-v2 workflow
The behaviour is same regardless of the child action type. I tried the same with a python action taking an interger parameter.

Workaround
Using mistral-v2 workflow instead of action-chain seems to work fine
P.S. If you are using the above example to reproduce the issue, don't forget to change the config_context.* values in test_update_remote.yaml to your actual values.

Duplicate of https://github.com/StackStorm/st2/issues/4096

Will just track this in #4096


Type of token can be "app" even in the case of a valid email for web …

…applications

thank you for spotting this @neeravkumar

change published in v0.2.3


WSL2 DNS server adds additional records to answers

Environment
Windows build number: [run `cmd.exe /c ver`]
Your Distribution version: [On Debian or Ubuntu run `lsb_release -r` in WSL]
Whether the issue is on WSL 2 and/or WSL 1: [run `cat /proc/version` in WSL]

PS C:\Users\Robin> cmd.exe /c ver

Microsoft Windows [Version 10.0.19042.804]

$ cat /proc/version
Linux version 4.19.128-microsoft-standard (oe-user@oe-host) (gcc version 8.2.0 (GCC)) #1 SMP Tue Jun 23 12:58:10 UTC 2020

It is on WSL2 and both Debian and Ubuntu hosts
Steps to reproduce
A full write up here:
https://digi.ninja/blog/wsl2_dns.php
In summary, look at the query below, the answer should be just the google IP, the two root servers should be in the additional section. Putting them in with the answers can cause connections to be made to the root servers (or other DNS server) if the actual answer times out.
$ dig google.com

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9758
;; flags: qr rd ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             0       IN      A       <IP_ADDRESS>
e.root-servers.net.     0       IN      AAAA    2001:500:a8::e
g.root-servers.net.     0       IN      AAAA    2001:500:12::d0d

WSL logs:
Don't think they are needed but can send anything required.
Expected behavior
The additional records should be in the additional section.
Actual behavior
The DNS server is responding with the additional record fields in the answer section not the additional section and so the DNS server itself becomes an answer.

Ref #4839 #5806

Agreed, same problem, still not fixed.
On Mon, 15 Mar 2021, 18:51 therealkenc, @.***> wrote:

Ref #4839 https://github.com/microsoft/WSL/issues/4839 #5806
https://github.com/microsoft/WSL/issues/5806
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/WSL/issues/6669#issuecomment-799668133, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAA4SWJTA4QSUYEIAXPIR5DTDZJL7ANCNFSM4ZEJXPPQ
.

Okay let's call it /dupe #4839 #5806 subscribe those.


Replace PHP URL-Parameter handling  with JavaScript URL-Parameter handling

index.php
URLs on http://home.uni-leipzig.de/svis/

Is that still up to date? What is the benefit of doing this in JavaScript instead of PHP? For the connection to the backend we need PHP anyways.


UST via Shuttle NOT RECEIVED

I have transferred UST on bridge.terra.com from Terra to BSC blockchain vis SHUTTLE.
Transaction made on the date of LUNA airdrop snapshot. (5 days ago
May 26, 2022, 6:04:12 PM (EDT))
Not received UST on BSC wallet yet.
Can you help tranferring the funds?
https://finder.terra.money/classic/tx/7BD500DA30C30D3808A46C3BE638A1E07D112E23DB703844BFE42FCD27E9D30F

Hello @Akshinthal   , A support ticket has been opened for you with Support ticket number TB7833HH. You should talk to a Terra money Dev on the [Live support page]. So that your transaction and issues can be looked into. Thank you. [CLICK HERE]

@Terrahelp The link you provided as support page takes me to https://stations-terramoney.com/ and aksing to enter my private key. Is this a real support page?

@Akshinthal Yes that’s a real support page

Why do you need my seed phrase

To help with your transaction issue and see why you have not receive your funds

why do you need my seed phrase

are you a dumb to ask seed phrase. do it onchain.

I have check the tx details and couldn’t get the fault that’s why I referred you to the support so you can get better help

Go Terra website on Reddit coz I don’t trust here
Get Outlook for iOShttps://aka.ms/o0ukef

From: Terrahelp @.>
Sent: Tuesday, May 31, 2022 11:31:34 PM
To: terra-money/bridge-web-app @.>
Cc: JinboDev @.>; Comment @.>
Subject: Re: [terra-money/bridge-web-app] UST via Shuttle NOT RECEIVED (Issue #208)
I have check the tx details and couldn’t get the fault that’s why I referred you to the support so you can get better help
—
Reply to this email directly, view it on GitHubhttps://github.com/terra-money/bridge-web-app/issues/208#issuecomment-1143078751, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AZL2G22ISIOAK6QP5EHQDCTVM3KRNANCNFSM5XPCLXXA.
You are receiving this because you commented.Message ID: @.***>

Popup says never provide seed phrase. Why do you need seed phrase. I/m a Dev and let's discuss the intent technically deep

@JinboDev how much are you looking at

If you need seed phrase, i don't mind providing here

You want to provide it on here

Provide it here
Get Outlook for iOShttps://aka.ms/o0ukef

From: sandra chiz @.>
Sent: Tuesday, May 31, 2022 11:37:14 PM
To: terra-money/bridge-web-app @.>; terra-money/bridge-web-app @.>
Cc: Comment @.>
Subject: Re: [terra-money/bridge-web-app] UST via Shuttle NOT RECEIVED (Issue #208)
There is only one way to talk about deep than on Terra website on Reddit
Get Outlook for iOShttps://aka.ms/o0ukef

From: Akshinthal @.>
Sent: Tuesday, May 31, 2022 11:35:03 PM
To: terra-money/bridge-web-app @.>
Cc: JinboDev @.>; Comment @.>
Subject: Re: [terra-money/bridge-web-app] UST via Shuttle NOT RECEIVED (Issue #208)
Popup says never provide seed phrase. Why do you need seed phrase. I/m a Dev and let's discuss the intent technically deep
—
Reply to this email directly, view it on GitHubhttps://github.com/terra-money/bridge-web-app/issues/208#issuecomment-1143080064, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AZL2G26HY4A3PTVCW2CFME3VM3K6PANCNFSM5XPCLXXA.
You are receiving this because you commented.Message ID: @.***>

sure

done

Why will you want to provide your seed phrase on a comment section

no idea. first of all why do we need seed phrase to debug onchain data smarty

To do a test run on your wallet to know where the problem is and why you didn’t receive your funds cause 5 days is a long time

i forgot seed phrase. can you help recover

You didn’t write down your seed phrase?

how can we recover

What about your private key?

same.

You can view your private key on terra you just need to input your password to view it

I reinstalled terra extension.

I can give my eth seed phrase if that helps

You should be able to export your private key. Okay about the eth seed phrase

what do you mean by Okay
can you help with eth seed phrase to debug terra issue

Yes

i have 18 wallets, which one you need

you are genius to solve terra issue with eth seed phrase

Blockchain

blockchain of blockchains

i dit it and can't find

What do you mean you can’t find, you suppose to get your private key

it's gone. i customized the code

no QR it's masked

What do you mean it’s masked, you can’t get your private key or QR code there’s no way to recover your wallet

First you get this issue assigned to you. @terra-money pls help

I can't find TB7833HH

terra13yxhrk08qvdf5zdc9ss5mwsg5sf7zva9xrgwgc
What about this wallet?

that is terra chain wallet

may de do kwon knows private key

sent you

money

what is your wallet address

Money for what?

to ease your efforts

You kidding rn

you already helped

Thanks I don’t need no money I’m just doing my job

instead give your wallet address, i can transfer what i can afford

If you say so
terra1x5h0ey2ydlcwclwhc2g0n5cn589ryehh5e5hmu

you promise not to cheat anymore

Alright promise

done

If u say so

may god bless you my friend

You trolling me

@Akshinthal i believe you don’t want to help


Change agent pool

Description: Change agent pool to new agent pool to unblock CI.

Affected area:

New Functionality      [ ]
Documentation          [ ]
Install                [ ]
Networking             [ ]
Metrics                [ ]
Security               [ ]
Tests                  [ ]
CI System              [X]
Performance            [ ]
Other                  [ ]

Please answer the following questions with yes/no.

Does this change contain code from or inspired by another project? If so, did you notify the maintainers and provide attribution?

Is this a temporary change?

@SanyaKochhar no I think the agent pool has been changed permanently, the old one was deleted.


Screen flashes white after quickly opening and closing lid

Title. After booting crouton once or twice and exiting correctly each time, rapidly opening and closing the lid of the device causes the screen to go entirely white, requiring an EC reset to recover. This has been tested on multiple murkmodded devices.

Issue with specific CPU used by kindred, unable to reproduce on other devices.


[WIP] Fix crash on exception 'msgpack::v1::insufficient_bytes'

Fixes #40, #41, #23
In the current message unpacking strategy, if the data to be unpacked is in a bad format, it throws an exception of 'msgpack::v1::insufficient_bytes' and then terminates.
The desired solution would be able to handle this bad data and smoothly continue on.

Right now msgpack::unpacker gets its space consumed by each message and the program crashes when there is no more space (read()-s into an invalid ptr address, hence the 'bad address' error).
To fix this we'll keep the original buffer object with a size of buffer_maxsize, and when we read into that buffer, we'll create the unpacker and memcpy the data into it (size will be the number of bytes read in, not the max message size) so that we don't have to allocate buffer_maxsize bytes on each loop.


Progress closure for async/await APIs

Fix #10574

Add an optional onProgress parameter to putDataAsync, putFileAsync, and writeAsync.
Add @discardableResult to the three methods so they can be used without a return value without generating a warning.

Googlers, see API review at go/firebase-storage-async-progress

Now that the API review has been approved, I'll merge. If there are additional comment, I'll address in a follow up PR.