Add config options for eupf ebpf-program

At the moment the only way to configure ebpf befaviour is build options. There are several cases where start time configuration is more suitable:

local N3 ip address (is configured via FAR map currently)
?

Investigate possibility to use rodata section to setup startup configuration parameters. See bpf_config config in https://github.com/xdp-project/bpf-examples/blob/master/pping/pping_kern.c

Yet another hint https://stackoverflow.com/questions/70475993/how-to-let-user-space-to-populate-an-ebpf-global-data-at-load-time


Support external rendering

Hi,
It's quite common now to use a JS framework such as React or Vue to render the elements instead of D3.js DOM manipulation. While it's possible with most of the packages, d3-axis doesn't support this kind of operation which is useful not only for consistency and reactivity but also for rendering of labels outside of svg to keep font rendering and size consistent with the remaining page elements even when chart is being scaled.
Is it possible to make d3-axis more friendly for select-less operation? E.g. provide methods to get ticks coordinates, line path etc. I would file a PR if I was sure how to do it right but I'm not, so could you either implement it or guide me on how this can be done?

With apologies, but I don’t see this as being possible (or… feasible). Your best bet is probably forking this library and re-implementing it with your framework of choice.

Thanks!

Also, there’s already scale.ticks, d3.ticks, d3.format etc. for doing all this stuff outside of d3-axis. The remaining logic in this module is essentially mapping that to SVG (and handling transitions).


Deadlock when manually logging from on_train_epoch_end

Bug description
When using DDP and manually logging a TorchMetric by calling metric.update inside of training_step and then metric.compute inside of on_training_epoch_end, training appears to end up in a deadlock and eventually crashes with NCCL timeout errors.
This sort of logging setup is desirable when a TorchMetric returns a non-scalar data structure, i.e., a confusion matrix or dictionary, and some further processing is required at the end of the epoch before logging with self.log.
A minimal example is attached.  Deadlock only occurs when using DDP, multiple GPUs, and also logging the training loss with on_epoch.
What version are you seeing the problem on?
v2.1, v2.2
How to reproduce the bug
import os, sys

import torch
from torchmetrics import MeanSquaredError
from pytorch_lightning import LightningModule, Trainer
from torch.utils.data import DataLoader, Dataset

class RandomDataset(Dataset):
    def __init__(self, size, length):
        self.len = length
        self.data = torch.randn(length, size)

    def __getitem__(self, index):
        return self.data[index]

    def __len__(self):
        return self.len

class BoringModel(LightningModule):
    def __init__(self):
        super().__init__()
        self.layer = torch.nn.Linear(32, 32)

        # Use MSE for simple demo but this might be a complex
        # metric that doesn't return a scalar.
        self.metric = MeanSquaredError()

    def forward(self, x):
        return self.layer(x)

    def training_step(self, batch, batch_idx):
        targs = batch
        preds = self(batch)
        loss = torch.mean((preds - targs)**2)

        # Log the loss at each step
        self.log('train_loss/step', loss, on_step=True, on_epoch=False)

        # Log the loss averaged over each epoch.
        # IF THIS IS COMMENTED OUT, EVERYTHING WORKS!!
        self.log('train_loss', loss, on_step=False, on_epoch=True, sync_dist=True)

        # Update our custom metric.  We don't want to just log it directly with
        # `on_epoch=True` because it returns a complex data structure, e.g.,
        # a confusion matrix or a dictionary of values that need processing at the
        # end of the epoch.  Instead, we want to update it and later handle the
        # logging in `on_train_epoch_end`.  That way, we can inject cutom processing
        # at the end of the epoch.
        self.metric.update(preds, targs)

        return {'loss': loss, 'preds': preds, 'targs': targs}

    def on_train_epoch_end(self):
        print(f'logging metrics for rank `{os.environ.get("LOCAL_RANK", 0)}`.')
        sys.stdout.flush()

        # At the end of the epoch, we compute the metric and then reset it.
        metric_value = self.metric.compute()
        self.metric.reset()

        # We can do sophisticated steps here to convert `metric_value` into something
        # that can be logged.
        self.log('metric', metric_value, on_step=False, on_epoch=True, sync_dist=True)

    def validation_step(self, batch, batch_idx):
        targs = batch
        preds = self(batch)
        loss = torch.mean((preds - targs)**2)

        self.log('valid_loss', loss, on_step=False, on_epoch=True, sync_dist=True)

    def configure_optimizers(self):
        return torch.optim.SGD(self.layer.parameters(), lr=0.01)

def run():
    train_data = DataLoader(RandomDataset(32, 64), batch_size=2)
    val_data = DataLoader(RandomDataset(32, 64), batch_size=2)
    model = BoringModel()

    trainer = Trainer(
        default_root_dir=os.getcwd(),
        limit_train_batches=5,
        limit_val_batches=5,
        log_every_n_steps=2,
        num_sanity_val_steps=0,
        max_epochs=5,
        enable_model_summary=False,
        strategy='ddp', # Everything works fine when using a single GPU
        accelerator='gpu',
        devices=[0, 1],
    )
    trainer.fit(model, train_dataloaders=train_data, val_dataloaders=val_data)

if __name__ == '__main__':
    run()

Error messages and logs
This is the output, it hangs for a very long time before actually segfaulting.
GPU available: True (cuda), used: True
TPU available: False, using: 0 TPU cores
IPU available: False, using: 0 IPUs
HPU available: False, using: 0 HPUs
/home/eforney/venv/lightning_bug/lib/python3.8/site-packages/pytorch_lightning/trainer/connectors/logger_connector/logger_connector.py:75: Starting from v1.9.0, `tensorboardX` has been removed as a dependency of the `pytorch_lightning` package, due to potential conflicts with other packages in the ML ecosystem. For this reason, `logger=True` will use `CSVLogger` as the default logger, unless the `tensorboard` or `tensorboardX` packages are found. Please `pip install lightning[extra]` or one of them to enable TensorBoard support by default
You are using a CUDA device ('NVIDIA RTX A6000') that has Tensor Cores. To properly utilize them, you should set `torch.set_float32_matmul_precision('medium' | 'high')` which will trade-off precision for performance. For more details, read https://pytorch.org/docs/stable/generated/torch.set_float32_matmul_precision.html#torch.set_float32_matmul_precision
Initializing distributed: GLOBAL_RANK: 0, MEMBER: 1/2
Initializing distributed: GLOBAL_RANK: 1, MEMBER: 2/2
----------------------------------------------------------------------------------------------------
distributed_backend=nccl
All distributed processes registered. Starting with 2 processes
----------------------------------------------------------------------------------------------------

LOCAL_RANK: 1 - CUDA_VISIBLE_DEVICES: [0,1]
LOCAL_RANK: 0 - CUDA_VISIBLE_DEVICES: [0,1]
/home/eforney/venv/lightning_bug/lib/python3.8/site-packages/pytorch_lightning/trainer/connectors/data_connector.py:441: The 'train_dataloader' does not have many workers which may be a bottleneck. Consider increasing the value of the `num_workers` argument` to `num_workers=9` in the `DataLoader` to improve performance.
/home/eforney/venv/lightning_bug/lib/python3.8/site-packages/pytorch_lightning/trainer/connectors/data_connector.py:441: The 'val_dataloader' does not have many workers which may be a bottleneck. Consider increasing the value of the `num_workers` argument` to `num_workers=9` in the `DataLoader` to improve performance.
Epoch 0: 100%|█████████████████████████████████████████████████████████████████████████████████| 5/5 [00:00<00:00, 28.00it/s, v_num=23logging metrics for rank `1`.%|██████████████████████████████████████████████████████████████████████████| 5/5 [00:00<00:00, 440.52it/s]
Epoch 0: 100%|█████████████████████████████████████████████████████████████████████████████████| 5/5 [00:00<00:00, 20.92it/s, v_num=23][rank0]:[E ProcessGroupNCCL.cpp:523] [Rank 0] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=33, OpType=ALLREDUCE, NumelIn=1, NumelOut=1, Timeout(ms)=1800000) ran for 1800562 milliseconds before timing out.
[rank0]:[E ProcessGroupNCCL.cpp:537] Some NCCL operations have failed or timed out. Due to the asynchronous nature of CUDA kernels, subsequent GPU operations might run on corrupted/incomplete data.
[rank0]:[E ProcessGroupNCCL.cpp:543] To avoid data inconsistency, we are taking the entire process down.
[rank0]:[E ProcessGroupNCCL.cpp:1182] [Rank 0] NCCL watchdog thread terminated with exception: [Rank 0] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=33, OpType=ALLREDUCE, NumelIn=1, NumelOut=1, Timeout(ms)=1800000) ran for 1800562 milliseconds before timing out.
Exception raised from checkTimeout at ../torch/csrc/distributed/c10d/ProcessGroupNCCL.cpp:525 (most recent call first):
frame #0: c10::Error::Error(c10::SourceLocation, std::string) + 0x57 (0x7fe4691ffd87 in /home/eforney/venv/lightning_bug/lib/python3.8/site-packages/torch/lib/libc10.so)
frame #1: c10d::ProcessGroupNCCL::WorkNCCL::checkTimeout(std::optional<std::chrono::duration<long, std::ratio<1l, 1000l> > >) + 0x1e6 (0x7fe46a3a76e6 in /home/eforney/venv/lightning_bug/lib/python3.8/site-packages/torch/lib/libtorch_cuda.so)
frame #2: c10d::ProcessGroupNCCL::workCleanupLoop() + 0x19d (0x7fe46a3aac3d in /home/eforney/venv/lightning_bug/lib/python3.8/site-packages/torch/lib/libtorch_cuda.so)
frame #3: c10d::ProcessGroupNCCL::ncclCommWatchdog() + 0x119 (0x7fe46a3ab839 in /home/eforney/venv/lightning_bug/lib/python3.8/site-packages/torch/lib/libtorch_cuda.so)
frame #4: <unknown function> + 0xd6df4 (0x7fe4b40bbdf4 in /lib/x86_64-linux-gnu/libstdc++.so.6)
frame #5: <unknown function> + 0x8609 (0x7fe4b5264609 in /lib/x86_64-linux-gnu/libpthread.so.0)
frame #6: clone + 0x43 (0x7fe4b539e353 in /lib/x86_64-linux-gnu/libc.so.6)

terminate called after throwing an instance of 'c10::DistBackendError'
  what():  [Rank 0] NCCL watchdog thread terminated with exception: [Rank 0] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=33, OpType=ALLREDUCE, NumelIn=1, NumelOut=1, Timeout(ms)=1800000) ran for 1800562 milliseconds before timing out.
Exception raised from checkTimeout at ../torch/csrc/distributed/c10d/ProcessGroupNCCL.cpp:525 (most recent call first):
frame #0: c10::Error::Error(c10::SourceLocation, std::string) + 0x57 (0x7fe4691ffd87 in /home/eforney/venv/lightning_bug/lib/python3.8/site-packages/torch/lib/libc10.so)
frame #1: c10d::ProcessGroupNCCL::WorkNCCL::checkTimeout(std::optional<std::chrono::duration<long, std::ratio<1l, 1000l> > >) + 0x1e6 (0x7fe46a3a76e6 in /home/eforney/venv/lightning_bug/lib/python3.8/site-packages/torch/lib/libtorch_cuda.so)
frame #2: c10d::ProcessGroupNCCL::workCleanupLoop() + 0x19d (0x7fe46a3aac3d in /home/eforney/venv/lightning_bug/lib/python3.8/site-packages/torch/lib/libtorch_cuda.so)
frame #3: c10d::ProcessGroupNCCL::ncclCommWatchdog() + 0x119 (0x7fe46a3ab839 in /home/eforney/venv/lightning_bug/lib/python3.8/site-packages/torch/lib/libtorch_cuda.so)
frame #4: <unknown function> + 0xd6df4 (0x7fe4b40bbdf4 in /lib/x86_64-linux-gnu/libstdc++.so.6)
frame #5: <unknown function> + 0x8609 (0x7fe4b5264609 in /lib/x86_64-linux-gnu/libpthread.so.0)
frame #6: clone + 0x43 (0x7fe4b539e353 in /lib/x86_64-linux-gnu/libc.so.6)

Exception raised from ncclCommWatchdog at ../torch/csrc/distributed/c10d/ProcessGroupNCCL.cpp:1186 (most recent call first):
frame #0: c10::Error::Error(c10::SourceLocation, std::string) + 0x57 (0x7fe4691ffd87 in /home/eforney/venv/lightning_bug/lib/python3.8/site-packages/torch/lib/libc10.so)
frame #1: <unknown function> + 0xdf6b11 (0x7fe46a101b11 in /home/eforney/venv/lightning_bug/lib/python3.8/site-packages/torch/lib/libtorch_cuda.so)
frame #2: <unknown function> + 0xd6df4 (0x7fe4b40bbdf4 in /lib/x86_64-linux-gnu/libstdc++.so.6)
frame #3: <unknown function> + 0x8609 (0x7fe4b5264609 in /lib/x86_64-linux-gnu/libpthread.so.0)
frame #4: clone + 0x43 (0x7fe4b539e353 in /lib/x86_64-linux-gnu/libc.so.6)

Aborted (core dumped)

Environment

Current environment
- Lightning Component (e.g. Trainer, LightningModule, LightningApp, LightningWork, LightningFlow): Trainer / LightningModule
- PyTorch Lightning Version (e.g., 1.5.0): 2.2.1
- PyTorch Version (e.g., 2.0): 2.2.1
- Python version (e.g., 3.9): 3.8.10
- OS (e.g., Linux): Linux, Ubuntu 20.04.6 LTS
- CUDA/cuDNN version: 12.2
- GPU models and configuration: 2x RTX A6000
- How you installed Lightning(`conda`, `pip`, source): pip
- Running environment of LightningApp (e.g. local, cloud): local

More info
No response

Hi, I have the same problem, especially with confusion matrix from Torchmetrics.
Are there any updates on this issue?

@idfah self.log('train_loss', loss, on_step=False, on_epoch=True, sync_dist=True) do you maybe know what causes problems with this line, when it is uncommented? Is it on_epoch or sync_dist or smt else?

@idfah Additionally, I found that if you place whole code from on_train_epoch_end() in on_validation_epoch_end() or in on_train_epoch_start() it works normally, there is no deadlock.

My code looks like below, i want compute a validation metric based on entire validation dataset. so i will append every results in every batch into a list, and then in on_validation_epoch_end function to compute the metric.

It works fine with single GPU, but when i use ddp strategy the do so, i always meet

``

can someone help me?  Thanks in advance!
  self.validation_step_outputs = []
  self.validation_step_clusters = []

def validation_step(self, batch, batch_idx):
  batch_tokens, clusters = batch
  projection= self._common_step(batch_tokens)

  self.validation_step_outputs.append(projection)
  self.validation_step_clusters.append(clusters)

def on_validation_epoch_end(self):

  if self.trainer.is_global_zero:  # Check if this is the rank 0 process

    all_preds = torch.cat(self.validation_step_outputs, dim=0)

    all_clusters = LabelEncoder().fit_transform(list(itertools.chain.from_iterable(self.validation_step_clusters)))
    all_clusters = torch.tensor(all_clusters)

    self.validation_step_outputs.clear()
    self.validation_step_clusters.clear()

    loss = loss_func(all_preds, all_clusters)

    accuracy = self._cal_accuracy(all_preds, all_clusters)

    self.log('validation_loss', loss, on_epoch=True, prog_bar=True)
    self.log('accuracy', accuracy, on_epoch=True, prog_bar=True)

  self.trainer.strategy.barrier()

I am having the same issue.
The following solved the issue for me but it is a work-around:

@idfah Additionally, I found that if you place whole code from on_train_epoch_end() in on_validation_epoch_end() or in on_train_epoch_start() it works normally, there is no deadlock.

Same issue here. Calling:
                conf_mat = self.confusion_matrix_metrics[dataset_split][attribute.name] \
                    .compute() \
                    .detach() \
                    .cpu() \
                    .numpy()

inside on_train_epoch_start hangs when using DDP but works fine with single GPU. No issue when calling the same code in on_validation_epoch_end and on_test_epoch_end.

I experience the same issue with torch  2.2.1+cu118 and lightning 2.3.3 on linux. Running on 2 GPU machine.

I encountered similar issue when using self.log(..., sync_dist=True) in on_validation_epoch_end

Well the issue seems to be that one process comples N training loops, and another N+X. If one process asks for a synchronization (i.e. metric.compute), while other is outside of the loop already, you'll get your error.
As a rule of thumb: any metric computes MUST be available for execution regardless of conditions. You can't place metric.compute under any condition safely, including for loop.

Well the issue seems to be that one process comples N training loops, and another N+X. If one process asks for a synchronization (i.e. metric.compute), while other is outside of the loop already, you'll get your error.
As a rule of thumb: any metric computes MUST be available for execution regardless of conditions. You can't place metric.compute under any condition safely, including for loop.

I don't believe this is what is happening , the description of the issue does not have conditional execution, and on a personal note  in my code, all processes execute the same code regardless of their rank.


How to use it for vue3.x

How to use it for vue3.x

I'm also interested if this works or another project exists as a "vue3 electron starter template"

https://github.com/andotorg/electron-vue-app-template

我也很感兴趣这是否有效或另一个项目作为“vue3电子入门模板”存在
可以根据我的项目区使用新版vue
https://github.com/andotorg/electron-vue-app-template

@andotorg your template runs on Vue 2.6 according to the package.json and not on Vue 3.0

I am upgrading it and will write a quick document on how to use the combination of electron and Vue 3.0

@LauraWebdev You know  vue-cli-plugin-electron-builder ?

I'm also interested if this works or another project exists as a "vue3 electron starter template"

I created a clean, bare bones Electron + Vue 3 template which can be found electron-vue-template, because this project is not being maintained and is outdated.
Though if you want to use Vue 3.x in this project you should just be able to upgrade the current package and use the new Vue.createApp interface.


Add memo to OrderFulfillment and ETA to PhysicalDelivery

The OrderFulFillment protobuf should probably have a memo for any notes related to the fulfillment.
The PhysicalDelivery message should probably have an ETA field to indicate the shipping ETA.

cc @morebrownies and @jjeffryes
The reason for adding a memo is for the vendor to add a note attached to the fulfilment, e.g. "Sorry for the late dispatch, we had issues with our provider. We've upgraded shipping to Express."
The reason for adding an ETA for physical deliveries is pretty self-explanatory, e.g. "Estimated delivery between Jan 26 and Jan 28".

Since the ETA would be free text I think they can put this in the memo field anyways.

OrderFulfillment has a note field already.


Update Button Link for Incubation Projects Page

Update Button Link for Incubation Projects Page
Background:
We're in the process of creating a new Incubation Projects Highlight Page for our Docusaurus site see Issue #746  - Create an Incubation Projects Highlight Page. Once that page is completed, we need to update a button link to point to this new page.
Objective:
Update the buttonUrl property of the "Incubation Projects" button to direct users to the new Incubation Projects Highlight Page.
Task Details:

Note: Ensure Issue #746  - Create an Incubation Projects Highlight Page is completed before starting on this task, as the button should point to the newly created page.

File Location: Update the button in site/src/pages/community/index.js on line 213.

Modification:

Change the buttonUrl value from its current link ../open-source/incubation to the new incubation-projects page location ../community/incubation-project.

<Button
    heroText="Incubation Projects"
    buttonUrl="../community/incubation-project"
    buttonText="Discover More"
    bodyText="TBD Incubation projects are managed by community contributors."
    themeColor="cyan"
    primary
/>

Picking Up This Issue:

If you'd like to work on this, please comment "picking this up" below, and I'll assign the issue to you

Questions:

If you need assistance or clarification, feel free to comment below.
Feeling overwhelmed? Join our #hack-together channel and collaborate with a buddy.
New to open-source? Check out our Hacktober #getting-started channel.
Leaderboard: Check your ranking after finishing this task.

Resources:

Docusaurus Documentation: Familiarize yourself with how Docusaurus works. Here's the official documentation.
Creating a Pull Request: If you're new to GitHub and unsure how to create a pull request, follow this step-by-step guide.

Remember, communication is key! If you have any questions or face any challenges, we're here to help so please don't hesitate to reach out.
Good Luck! 🍁

Hey Team TBD, picking this up!

@comeworkwith-me Your second issue yay! 🥳 Keep in mind that this issue can't be worked on until issue #746 is completed. Let me know if you'd still like to pick it up and I'll assign it to you.
I'd also like to note that Hacktoberfest officially kicks off on October 1st. Contributions made before the event may not be eligible for the challenge. However, feel free to start working on it, but I'd recommend holding off on submitting your PR until the event begins.

to be eligible for Hacktoberfest's official prizes make sure you're registered, registration opens September 26th.

Yes, I'd still like to work on it @EbonyLouis 💯 🙂

@EbonyLouis picking this up

@EbonyLouis picking this up

If this issue is not resolved yet, can I work on it ?

This issued is assigned to me and being worked on @Himanshu9901 , thank you for double checking 💯

Hey @EbonyLouis @angiejones, can I pick this issue if it is idle?

@EbonyLouis may I work on this if it's not resolved?

Hey @KhoiUna , @aniketh-varma this issue is being blocked by this issue: https://github.com/TBD54566975/developer.tbd.website/issues/746.

Hey @KhoiUna , @aniketh-varma this issue is being blocked by this issue: https://github.com/TBD54566975/developer.tbd.website/issues/746.

Can I work on #746?


Update Containerapp example with a yaml configuration

@calvinsID : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#label:"aq-pr-triaged"

Closing in favor of PR into azure-docs-pr repo: https://github.com/MicrosoftDocs/azure-docs-pr/pull/179749


Cargo does not play nicely with sudo

Example:
sudo -Hs -u _homebrew cargo
error: could not crate home directory: '/usr/local/.multirust'
info: caused by: Permission denied (os error 13)

Ideally, sudo (at least when used with the -H option) should use the toolchain/settings for the parent user, not root/_homebrew/whatever use you're sudoing as.
Also, note the typo "crate" (should be "create").

Note, this is on OS X 10.12.

While I could definitely believe that Cargo itself doesn't play nicely with sudo (with the global cache) this specific error I believe is coming from rustup, not Cargo itself.

Oops, my bad, sorry.

No worries! My guess is that Cargo may have similar issues once it gets that far :)


[Feature request] Decouple metrics collection from /metrics endpoint

Metrics collection can take various amounts of time, for my instance for example (about 64.000 rows metrics output) the exporter takes about 21 seconds to collect all data.
Since Prometheus uses 1min scrape duration defaults (1), Kubernetes Liveness and readyness probes might put load on the endpoint as well, especially since the defaults (2) (periodSeconds 10sec, timeout 1sec) will not work properly.
The following things can be implemented to solve the issue:

Async metrics collection in a fine tunable interval from command line arguments or env variable & /metrics endpoint showing the latest data with some TTL, so no outdated data will be shown
Health endpoint responding if metrics collection was successfull and the cached data are still in the TTL

Major benefits:

The exporter can not be used to D/DOS the VCenter API
Queries will be way faster if the data has been collected in advance
Health collection does not require metrics overhead
Exporter will fit seamlessly into the K8S defaults, even the tight scrape interval defaults of Prometheus will work without hazzle

[1] https://prometheus.io/docs/prometheus/latest/configuration/configuration/#<duration>
[2] https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/

Hey @kremers!
Interesting feedback, my 2 cents:

async metrics collection is indeed possible and has some advantages, however is generally not the best practice [1], possible alternatives would be to:
a) run multiple exporters, each responsible for a subset of the collectors
b) consider supporting URL params for specifying the collectors during scrape, this way multiple scrape targets (black-exporter style) could be specified for each collector thus splitting the scrape to smaller portions.

Health endpoint should have very simple logic, mainly covering scenarios of application dead-locks, if there's an issue (error, timeouts, etc..) with metrics collection that should be returned with the scrape response (which indeed makes it more difficult with metrics are collected in an async way, and is generally why it's discouraged), which will provide the necessary input (in a form of "not up") to flag that there's an issue with metrics collection without unnecessarily killing/restarting the exporter.

[1] https://prometheus.io/docs/instrumenting/writing_exporters/#scheduling

Fully agree with @dannyk81. Don't think liveness/health checks should be putting load on the system. Async collection has been a PITA for me with other exporters and wold definitely want to stick with with official prometheus guidelines.
We probably could do something where multiple concurrent requests for the same data were done once and shared between requests but thats probably not a common problem (under the hood this would be a bit like a variation of the run_once_property primitive).

@dannyk81 thank you for mentioning the scheduling part.

If a metric is particularly expensive to retrieve, i.e. takes more than a minute, it is acceptable to cache it. This should be noted in the HELP string.
The default scrape timeout for Prometheus is 10 seconds. If your exporter can be expected to exceed this, you should explicitly call this out in your user documentation.

Depending on the vcenter size scrapes would take more than 10 seconds for sure. So we should put this into the docs?
Standard prometheus exporters expect to expose metrics from systems directly which is mostly cheap instead of calling external APIs to gather metrics. @Jc2k suggestion would solve the issue of possible DDOS the API through the exporter, at least for bigger queries.


support for ac3 voc files

the module returns application/octet-stream for ac3 and voc files
those are audio formats

File issue with https://github.com/jshttp/mime-db


Fixed checkbox component

There was a problem when creating checkboxes with comas in their names. I fixed it by using an array instead of strings to save the checkboxes data.

PhantomJS 1.9.8 (Mac OS X 0.0.0) builder.controller fbFormObjectEditableController $scope.setupScope() $scope.setupScope(formObject) copy properties from formObject without $$hashKey FAILED
It has nothing to do with what I have changed!
Tests are giving this same error if I clone your repository and run them.


Version for Laravel 6.x Support should be tagged

Hi,
there is no version tag for the changes that enabled support for Laravel 6.x. it's only in master

Same issue here - the composer require doesn't work on Laravel 6 because the last few commits on 'master' were not released. Was this package abandoned...?

Hi @Chalkin @yosifeldman
I've forked this package, please see comment: https://github.com/reshadman/laravel-optimistic-locking/issues/11#issuecomment-696233757

I just published an improvement over this package at https://github.com/qtsolv/laravel-locking please see and report any issues/feddback you may have.


fix #138: [jaspr_riverpod] update vsyncOverride to flutterVsyncs

Description
This PR is a fix for #138.
In riverpod,vsyncOverride was removed in riverpod v2.4.6 (https://github.com/rrousselGit/riverpod/pull/3072) and replaced with flutterVsyncs. This PR makes the same replacement in jaspr_riverpod.
Type of Change

[ ] ❌ Breaking change
[ ] ✨ New feature or improvement
[x] 🛠 Bug fix
[ ] 🧹 Code refactor
[ ] 📝 Documentation
[ ] 🗑 Chore

Ready Checklist

[x] I've read the Contribution Guide.
[x] In case this PR changes one of the core packages, I've modified the respective CHANGELOG.md file using
the semantic_changelog format.
[ ] I updated/added relevant documentation (doc comments with ///).
[x] I added myself to the AUTHORS file (optional, if you want to).

If you need help, consider asking for advice on the #contribute channel on Discord.

Hey, why it is not merged yet?
🙏


cellfinder v1.3.0 blog post

The next version of cellfinder is likely to be a (relatively) large one, and we should write a blog post to outline the differences. This will include:

Switch to torch backend (https://github.com/brainglobe/cellfinder/pull/396)
Support turning off classification or detection in GUI (https://github.com/brainglobe/cellfinder/pull/402)
Support for single z-stack tif file for input (https://github.com/brainglobe/cellfinder/pull/397)
Cell detection optimisation (#398) by (https://github.com/brainglobe/cellfinder/pull/407)
Pretrained models moving to ~.brainglobe/cellfinder, how the old models can be deleted, and how to re-install them in the new location (#176) (https://github.com/brainglobe/cellfinder/pull/414)
Maybe cell detection in torch.

cc @alessandrofelder

Here are the graphs and correlation/coefficients comparing tensorflow to torch on both Brain 1 and Brain 2 from the paper:

The timing information is below:

Brain 1 - paper
Brain 1 - torch
Brain 2 - paper
Brain 2 - torch
Brain 2 - torch + new detection

Candidate detection
50
46.5
48
64.5
48

Classification
33
35.5
43
39
39.5

Total
83
82
91
103.5
87.5

To clarify some points @IgorTatarnikov:

Based on the plots, torch is (technically, very slightly) better than TF?
The detection timings, is the main section of the plot the timings from the latest release, and "new detection" is from main (after @matham's PR)?

Correct, seems torch is a tiny bit better than TF.
For detection timings, all were run on the original machine from the paper. The "paper" columns are numbers taken from the cellfinder paper, the "torch" columns are the means of two runs using the detection code that is in the current release but with a torch backend. The last column is combining the new detection from https://github.com/brainglobe/cellfinder/pull/407 with a torch backend.

So to summarise, the next release will be pretty much the same accuracy and speed (but easier to maintain for us)?

Yup! It might be interesting to include some comparisons using a c-fos brain. I'm curious how the new release will compare to the old release with millions of cell candidates.

@alessandrofelder do you happen to have any data like this to hand?
I think we should include it if we have it, otherwise we can post something later on. This blog post could end up being longer than the original paper otherwise!

Due to various updates to other packages, have decided to create a blog post for the new version of the metapackage. This blogpost can be solely about the move to torch.

@alessandrofelder do you happen to have any data like this to hand?

Yes, I'll DM @IgorTatarnikov the details to it on our internal storage


Update to resolve breaking changes with provider release 0.3.2

Could you please run the pre-commit hooks to format the code?

This has already been addressed, hence I am closing this PR.


Update README.rst

Hi, @Manohar-mj. I don't know if this PR is intentional; if so, could you describe why you propose this change?


Navigate around SAP Data Hub, developer edition 2.4

Tutorial URL: https://developers.sap.com/tutorials/datahub-docker-v2-navigation.html
Please specify the step you are referring to
Step 1: Access UIs via a web browser
Same thing take a other port
https://issues.apache.org/jira/browse/HDFS-9427

This port change seems to happen with Hadoop 3.0.0. What version of Hadoop did you get in your hdfs container?
On my Data Hub Dev installation it is still 2.9, so using a port as in the tutorial.
$ docker exec -it hdfs bash

hdfs:/tmp # hadoop version
Hadoop 2.9.0
Subversion https://git-wip-us.apache.org/repos/asf/hadoop.git -r 756ebc8394e473ac25feac05fa493f6d612e6c50
Compiled by arsuresh on 2017-11-13T23:15Z
Compiled with protoc 2.5.0
From source with checksum 0a76a9a32a5257331741f8d5932f183
This command was run using /opt/hadoop-2.9.0/share/hadoop/common/hadoop-common-2.9.0.jar

PS C:\Users\TNEU> docker exec -it hdfs bash
hdfs:/tmp # hadoop version
Hadoop 2.9.0
Subversion https://git-wip-us.apache.org/repos/asf/hadoop.git -r 756ebc8394e473ac25feac05fa493f6d612e6c50
Compiled by arsuresh on 2017-11-13T23:15Z
Compiled with protoc 2.5.0
From source with checksum 0a76a9a32a5257331741f8d5932f183
This command was run using /opt/hadoop-2.9.0/share/hadoop/common/hadoop-common-2.9.0.jar
hdfs:/tmp #
Von: Vitaliy Rudnytskiy<EMAIL_ADDRESS>Gesendet: Montag, 8. April 2019 12:25
An: SAPDocuments/Tutorials<EMAIL_ADDRESS>Cc: Thomas Neuhaus<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Betreff: Re: [SAPDocuments/Tutorials] Navigate around SAP Data Hub, developer edition 2.4 (#3317)
This port change seems to happen with Hadoop 3.0.0. What version of Hadoop did you get in your hdfs container?
On my Data Hub Dev installation it is still 2.9, so using a port as in the tutorial.
$ docker exec -it hdfs bash
hdfs:/tmp # hadoop version
Hadoop 2.9.0
Subversion https://git-wip-us.apache.org/repos/asf/hadoop.git -r 756ebc8394e473ac25feac05fa493f6d612e6c50
Compiled by arsuresh on 2017-11-13T23:15Z
Compiled with protoc 2.5.0
From source with checksum 0a76a9a32a5257331741f8d5932f183
This command was run using /opt/hadoop-2.9.0/share/hadoop/common/hadoop-common-2.9.0.jar
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/SAPDocuments/Tutorials/issues/3317#issuecomment-480775038, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AuqaROBGbJJFZJaXYDUg7dVFXGcxHT_nks5vexkYgaJpZM4cgXta.

this one is related also to the occupied port which can also be closed. @thecodester


Jonmv/retry 429 and 503 when feeding

@thomasht86 please review.

Urgh, this turned ugly, but it seems to be the only way to make it work, perhaps because of the typing—when testing a similar setup locally, the simpler form worked perfectly.

Fixes #748


Idea: Checkbox Filter OR instead of AND

I would like to use multiple checkbox filters with an OR operration

Hi Melvin,
Great idea, let put it forward to the product manager. We are planning the extend the list view controles next year, this would definitely be a candidate.
Cheers, Andries

Good news, your requested change is now on or road map.

Feature implemented and release 1.1.0 https://appstore.home.mendix.com/link/app/105694/


A7670SA R2 With GPS  not works

Hello , So I have the module T-SIM-A7670-R2 (A7670SA R2 With GPS)  I am using Arduino to program.
I able to connect to the network but I couldn't get the GPS to work.
AT+CGNSSINFO
+CGNSSINFO: ,,,,,,,,
thank you so much

Hello. Which example are you using? Also make sure the antenna is outdoors

thanks...
I tested outdoors with antenna
my code:
#include "Arduino.h"
#define TINY_GSM_MODEM_SIM7600  //The AT instruction of A7670 is compatible with SIM7600
#define TINY_GSM_RX_BUFFER 1024 // Set RX buffer to 1Kb
#define SerialAT Serial1
// See all AT commands, if wanted
#define DUMP_AT_COMMANDS
#define uS_TO_S_FACTOR 1000000ULL  // Conversion factor for micro seconds to seconds
#define TIME_TO_SLEEP  600          // Time ESP32 will go to sleep (in seconds)
#define UART_BAUD    115200
#define PIN_DTR      25
#define PIN_TX       26
#define PIN_RX       27
#define PWR_PIN      4
#define BAT_ADC      35
#define BAT_EN       12
#define PIN_RI       33
#define RESET        5
#define SD_MISO     2
#define SD_MOSI     15
#define SD_SCLK     14
#define SD_CS       13
// Your GPRS credentials, if any
const char apn[]  = "zap.vivo.com.br";
const char gprsUser[] = "vivo";
const char gprsPass[] = "vivo";
#include "int.cpp"
#include <TinyGsmClient.h>
#ifdef DUMP_AT_COMMANDS  // if enabled it requires the streamDebugger lib
#include <StreamDebugger.h>
StreamDebugger debugger(SerialAT, Serial);
TinyGsm modem(debugger);
#else
TinyGsm modem(SerialAT);
#endif
void modem_on()
{
pinMode(BAT_EN, OUTPUT);
digitalWrite(BAT_EN, HIGH);

//A7670 Reset
pinMode(RESET, OUTPUT);
digitalWrite(RESET, LOW);
delay(100);
digitalWrite(RESET, HIGH);
delay(3000);
digitalWrite(RESET, LOW);

pinMode(PWR_PIN, OUTPUT);
digitalWrite(PWR_PIN, LOW);
delay(100);
digitalWrite(PWR_PIN, HIGH);
delay(1000);
digitalWrite(PWR_PIN, LOW);

}
bool reply = true;
// liga gps e flash
// AT+CGNSSPWR=1,1
//AT+CGPSINFO
void setup()
{
Serial.begin(115200); // Set console baud rate
SerialAT.begin(115200, SERIAL_8N1, PIN_RX, PIN_TX);
delay(10);
modem_on();
modem.gprsConnect(apn, gprsUser, gprsPass);
delay(2000);

****//turn on gps
Serial.println("\n---Starting GPS TEST---\n");
SerialAT.println("AT+CGNSSPWR=1,1");****

delay(10000);

if (modem.isGprsConnected()) {
    Serial.println("GPRS connected");
}

String ccid = modem.getSimCCID();
Serial.println("CCID: " + ccid);

String imei = modem.getIMEI();
Serial.println("IMEI: " + imei);

String cop = modem.getOperator();
Serial.println("Operator: " + cop);

IPAddress local = modem.localIP();
Serial.println("Local IP: " + String(local));

int csq = modem.getSignalQuality();
Serial.println("Signal quality: " + String(csq));

SerialAT.println("AT+CPSI?");     //Get connection type and band
modem.getModemInfo();

// get gps data
float lat,  lon;
if (modem.getGPS(&lat, &lon)) {     Serial.printf("lat:%f lon:%f\n", lat, lon);}

if (reply) {
    Serial.println(F("***********************************************************"));
    Serial.println(F(" You can now send AT commands"));
    Serial.println(F(" Enter \"AT\" (without quotes), and you should see \"OK\""));
    Serial.println(F(" If it doesn't work, select \"Both NL & CR\" in Serial Monitor"));
    Serial.println(F(" DISCLAIMER: Entering AT commands without knowing what they do"));
    Serial.println(F(" can have undesired consiquinces..."));
    Serial.println(F("***********************************************************\n"));
} else {
    Serial.println(F("***********************************************************"));
    Serial.println(F(" Failed to connect to the modem! Check the baud and try again."));
    Serial.println(F("***********************************************************\n"));
}

}
void loop()
{
while (true) {
    if (SerialAT.available()) {
        Serial.write(SerialAT.read());
    }
    if (Serial.available()) {
        SerialAT.write(Serial.read());
    }
    delay(10);
}

}

Reference example

Thanks, I used the code and add data APN. I sended for board. the chip not returned message of gps . Best regards for solutions.
thanks. I from brazil, need  the chip  any command?
// log port com
getGPS 463441
AT+CGNSSINFO
+CGNSSINFO: ,,,,,,,,
OK
getGPS 465446
AT+CGNSSINFO
+CGNSSINFO: ,,,,,,,,
OK
getGPS 467451
AT+CGNSSINFO
+CGNSSINFO: ,,,,,,,,
OK
getGPS 469456
AT+CGNSSINFO
+CGNSSINFO: ,,,,,,,,
OK
getGPS 471461
AT+CGNSSINFO
+CGNSSINFO: ,

A7670SA-FASE
OK
Modem Name: A7670SA-FASE
Manufacturer: INCORPORATED
Model: A7670SA-FASE
Revision: A7670M7_V1.11.1
IMEI:<PHONE_NUMBER>65927
+GCAP: +CGSM,+FCLASS,+DS

Is the antenna wired right. Can you take a picture of your board?

link
https://imgur.com/a/jLZ0BI8

Leave the example unchanged. Connect the MicroUSB and open the serial port with NMEA. See if there is data output . (The board needs to be positioned outdoors)

UHHHHHHHHHHHHHHH
CGNSSINFO: ,,,,,,,,
OK
getGPS 59215
AT+CGNSSINFO
+CGNSSINFO: ,,,,,,,,
OK
getGPS 61220
AT+CGNSSINFO
+CGNSSINFO: 3,08,,00,00,1947.80135,S,04354.86991,W,151122,124230.00,802.6,0.414,,12.,5.1,10.
OK
lat:-0.000000 lon:-0.000000
AT+CGPS=0
All ready.
thanks

Hello,
thank you very much.
I will try .

LilyGO-T-SIM7000G works Great! This one A7670SA R2 With GPS do not get GPS coordinates, no matter what we try, all the commands above.  Opening dispute on store to send it back.

Hello, thank you very much. I will try .

Please try again according to the above command

Hi. I have the T-SIM T-L7670E
I have uploaded the AT Debug, and gone through the process above.
I get the diagnostic information, but AT+CGNSSINFO and AT+CGPSINFO still always return blank.
What am I doing wrong, please?
$GAGSV,1,1,00,0*74
$GLGSV,1,1,00,0*79
$GNVTG,,,,,,,,,N*2E
$GNRMC,172922.00,V,,,,,,,070223,,,N,V*10
$GNGGA,172922.00,,,,,0,00,99.99,,,,,,*75
$GNGLL,,,,,172922.00,V,N*59
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,1*33
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,3*31
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,2*30
$GPGSV,1,1,03,05,,,31,16,,,24,02,,,18,0*6B
$GAGSV,1,1,00,0*74
$GLGSV,1,1,00,0*79
$GNVTG,,,,,,,,,N*2E
C$GNRMC,172922.50,V,,,,,,,070223,,,N,V*15
$GNGGA,172922.50,,,,,0,00,99.99,,,,,,*70
$GNGLL,,,,,172922.50,V,N*5C
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,1*33
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,3*31
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,2*30
$GPGSV,1,1,03,05,,,30,16,,,24,02,,,17,0*65
$GAGSV,1,1,00,0*74
$GLGSV,1,1,00,0*79
$GNVTG,,,,,,,,,N*2E
$GNRMC,172923.00,V,,,,,,,070223,,,N,V*11
$GNGGA,172923.00,,,,,0,00,99.99,,,,,,*74
$GNGLL,,,,,172923.00,V,N*58
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,1*33
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,3*31
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,2*30
$GPGSV,1,1,03,05,,,30,16,,,25,02,,,17,0*64
$GAGSV,1,1,00,0*74
$GLGSV,1,1,00,0*79
$GNVTG,,,,,,,,,N*2E
GN$GNRMC,172923.50,V,,,,,,,070223,,,N,V*14
$GNGGA,172923.50,,,,,0,00,99.99,,,,,,*71
$GNGLL,,,,,172923.50,V,N*5D
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,1*33
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,3*31
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,2*30
$GPGSV,1,1,03,05,,,29,16,,,20,02,,,17,0*69
$GAGSV,1,1,00,0*74
$GLGSV,1,1,00,0*79
$GNVTG,,,,,,,,,N*2E
S$GNRMC,172924.00,V,,,,,,,070223,,,N,V*16
$GNGGA,172924.00,,,,,0,00,99.99,,,,,,*73
$GNGLL,,,,,172924.00,V,N*5F
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,1*33
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.9S9,99.99,3*31
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,2*30
$GPGSV,1,1,03,05,,,29,16,,,20,02,,,17,0*69
$GAGSV,1,1,00,0*74
$GLGSV,1,1,00,0*79
$GNVTG,,,,,,,,,N*2E
$GNRMC,172924.50,V,,,,,,,070223,,,N,V*13
$GNGGA,172924.50,,,,,0,00,99.99,,,,,,*76
$GNGLL,,,,,172924.50,V,N*5A
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,1*33
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,3*31
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,2*30
$GPGSV,1,1,03,05,,,28,16,,,20,02,,,17,0*68
$GAGSV,1,1,00,0*74
$GLGSV,1,1,00,0*79
$GNVTG,,,,,,,,,N*2E
POR$GNRMC,172925.00,V,,,,,,,070223,,,N,V*17
$GNGGA,172925.00,,,,,0,00,99.99,,,,,,*72
$GNGLL,,,,,172925.00,V,N*5E
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,1*33
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,3*31
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,2*30
$GPGSV,1,1,03,05,,,30,16,,,20,02,,,17,0*61
$GAGSV,1,1,00,0*74
$GLGSV,1,1,00,0*79
$GNVTG,,,,,,,,,N*2E
T$GNRMC,172925.50,V,,,,,,,070223,,,N,V*12
$GNGGA,172925.50,,,,,0,00,99.99,,,,,,*77
$GNGLL,,,,,172925.50,V,N*5B
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,1*33
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,3*31
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,2*30
$GPGSV,1,1,03,05,,,30,16,,,20,02,,,17,0*61
$GAGSV,1,1,00,0*74
$GLGSV,1,1,00,0*79
$GNVTG,,,,,,,,,N*2E
S$GNRMC,172926.00,V,,,,,,,070223,,,N,V*14
$GNGGA,172926.00,,,,,0,00,99.99,,,,,,*71
$GNGLL,,,,,172926.00,V,N*5D
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,1*33
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,3*31
$GNGSA,A,1,,,,,,,,W,,,,,99.99,99.99,99.99,2*30
$GPGSV,1,1,03,05,,,30,16,,,20,02,,,17,0*61
$GAGSV,1,1,00,0*74
$GLGSV,1,1,00,0*79
$GNVTG,,,,,,,,,N*2E
I$GNRMC,172926.50,V,,,,,,,070223,,,N,V*11
$GNGGA,172926.50,,,,,0,00,99.99,,,,,,*74
$GNGLL,,,,,172926.50,V,N*58
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,1*33
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,3*31
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,2*30
$GPGSV,1,1,03,05,,,29,16,,,20,02,,,17,0*69
$GAGSV,1,1,00,0*74
$GLGSV,1,1,00,0*79
$GNVTG,,,,,,,,T,N*2E
C$GNRMC,172927.00,V,,,,,,,070223,,,N,V*15
$GNGGA,172927.00,,,,,0,00,99.99,,,,,,*70
$GNGLL,,,,,172927.00,V,N*5C
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,1*33
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,3*31
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,2*30
$GPGSV,1,1,03,05,,,29,16,,,20,02,,,17,0*69
$GAGSV,1,1,00,0*74
$GLGSV,1,1,00,0*79
$GNVTG,,,,,,,,,N*2E
H,,,,,,,,99.99,99.99,99.99,1*33
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,3*31
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,2*30
$GPGSV,1,1,03,05,,,29,16,,,21,02,,,17,0*68
$GAGSV,1,1,00,0*74
$GLGSV,1,1,00,0*79
$GNVTG,,,,,,,,,N*2E
=$GNRMC,172928.00,V,,,,,,,070223,,,N,V*1A
$GNGGA,172928.00,,,,,0,00,99.99,,,,,,*7F
$GNGLL,,,,,172928.00,V,N*53
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,1*33
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,3*31
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,2*30
$GPGSV,1,1,03,05,,,29,16,,,21,02,,,17,0*68
$GAGSV,1,1,00,0*74
$GLGSV,1,1,00,0*79
$GNVTG,,,,,,,,,N*2E
$GNRMC,172928.50,V,,,,,,,070223,,,N,V*1F
$GNGGA,172928.50,,,,,0,000,99.99,,,,,,*7A
$GNGLL,,,,,172928.50,V,N*56
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,1*33
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,3*31
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,2*30
$GPGSV,1,1,03,05,,,31,16,,,21,02,,,15,0*63
$GAGSV,1,1,00,0*74
$GLGSV,1,1,00,0*79
$GNVTG,,,,,,,,,N*2E
$GNRMC,172929.00,V,,,,,,,070223,,,N,V*1B
$GNGGA,172929.00,,,,,0,00,99.99,,,,,,*7E
$GNGLL,,,,,172929.00,V,N*52
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,1*33
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,3*31
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,2*30
$GPGSV,1,1,03,05,,,32,16,,,21,02,,,15,0*60
$GAGSV,1,1,00,0*74
$GLGSV,1,1,00,0*79
$GNVTG,,,,,,,,,N*2E
$GNRMC,172929.50,V,,,,,,,070223,,,N,V*1E
$GNGGA,172929.50,,,,,0,00,99.99,,,,,,*7B
$GNGLL,,,,,172929.50,V,N*57
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,1*33
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,3*31
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,2*30
$GPGSV,1,1,03,05,,,29,16,,,21,02,,,15,0*6A
$GAGSV,1,1,00,0*74
$GLGSV,1,1,00,0*79
$GNVTG,,,,,,,,,N*2E
,0$GNRMC,172930.00,V,,,,,,,070223,,,N,V*13
$GNGGA,172930.00,,,,,0,00,99.99,,,,,,*76
$GNGLL,,,,,172930.00,V,N*5A
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,1*33
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,3*31
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,2*30
$GPGSV,1,1,03,05,,,29,16,,,21,02,,,15,0*6A
$GAGSV,1,1,00,0*74
$GLGSV,1,1,00,0*79
$GNVTG,,,,,,,,,N*2E

OK
AT+CGPSINFO
+CGPSINFO: ,,,,,,,,

OK
AT+CGNSSINFO
+CGNSSINFO: ,,,,,,,,

OK

It can be seen that you did not operate according to the above method. When you turn on the GPS, you must turn on the power supply of the end of the world, otherwise you will not receive any satellite signals
https://github.com/Xinyuan-LilyGO/T-A7670X/issues/25#issuecomment-1346243254

The GPS antenna that came with the device isn't working as well as other antennas I have.
I have swapped the antenna and now the GPS fix happens in seconds.

I have swapped the antenna
Could you link the antenna you used for reference?

It's from a local supplier, but as long as it has the u.FL connector, then you should be ok.
Drone GPS antennas usually have that connection.

Onde posso arrumar uma firmware do a7670sa open ?? Para fazer modificações

Gostaria de modificar o nome da versão que aparece quando consulto pelo SMS com o comando version#, alguém pode me ajudar como consigo alterar ?


test(FormlyFormBuilder): add tests + small fixes.

Current coverage is 88.34% (diff: 46.15%)

Merging #244 into master will increase coverage by 3.87%

@@             master       #244   diff @@
==========================================
  Files            18         18
  Lines           934        944    +10
  Methods         214        212     -2
  Messages          0          0
  Branches        286        293     +7
==========================================
+ Hits            789        834    +45
+ Misses          145        110    -35
  Partials          0          0

Powered by Codecov. Last update 779590d...18cf99a


testfunctor.test_blindfunc fails on Python 3

In #62 I activated Python 3 tests and noticed that all but one test just work, after minor and obvious Python 3 fixes (imports and print).
The one failing test is testfunctor.test_blindfunc:
======================================================================
FAIL: testfunctor.test_blindfunc
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/travis/virtualenv/python3.4.4/lib/python3.4/site-packages/nose/case.py", line 198, in runTest
    self.test(*self.arg)
  File "/home/travis/build/iminuit/probfit/test/testfunctor.py", line 192, in test_blindfunc
    assert_almost_equal(arg[1], totest[1])
AssertionError: -0.4938177421680484 != -1.1665264284482637 within 7 places

https://travis-ci.org/iminuit/probfit/jobs/169564975#L229
I'm deactivating the test now in #62, because I'm not familiar with the code and don't have time.
This is a reminder issue that the test should be fixed on Python 3 (i.e. look why the result is different on Python 3 and fix the code to get the correct result on both Python 2 and 3) and re-activated.
@piti118 - Do you have time to look into this issue, or know someone that can?

I think the problem is due to the random module giving different numbers between Python 2 and Python 3, as in Mindwerks/worldengine#145.
For example, in Python 2:
$ python --version
Python 2.7.11
$ python -c 'from random import Random; print(Random("abc123").random())'
0.105877360912

But in Python 3:
$ python --version
Python 3.5.2
$ python -c 'from random import Random; print(Random("abc123").random())'
0.815454623872895

The random module is used by in probfit/functor.pyx to generate the blinding offsets. The tests fail under Python 3 because, presumably, the baseline value was computed by someone running Python 2.
One fix would be to use numpy.random instead:
$ python2 -c 'import numpy as np; np.random.seed(0); print(np.random.normal())'
1.76405234597
$ python3 -c 'import numpy as np; np.random.seed(0); print(np.random.normal())'
1.764052345967664

While I'm here, something that's tangentially related: I don't particularly like globally modifying the seed value, as is currently done in the tests. In the past I've implemented a context manager for such things:
@contextmanager
def temporary_seed(seed):
    """Context manager to temporarily set numpy's random seed.

    Example usage:

        >>> import numpy as np
        # Set a seed so this docstring is reproducible
        >>> np.random.seed(1233)
        >>> np.random.randint(10, size=5)
        array([0, 5, 8, 6, 8])
        # Temporarily set the seed within the context
        >>> with temporary_seed(1234):
        ...     print(np.random.randint(10, size=5))
        array([3, 6, 5, 4, 8])
        # Repeat to show we get the same values back
        >>> with temporary_seed(1234):
        ...     print(np.random.randint(10, size=5))
        array([3, 6, 5, 4, 8])
    """
    rand_state = np.random.get_state()
    np.random.seed(seed)
    yield
    np.random.set_state(rand_state)

@alexpearce - Thanks for looking into this issue!
+1 to use np.random instead.
I'm OK to use the temporary_seed context manager for now to fix this.
A better solution though would be to do what scikit-learn and others do, namely to have each function / class that generates random data optionally take a RandomState object.
I've documented in detail how to do this for a package I maintain here:
http://docs.gammapy.org/en/latest/development/howto.html#random-numbers
@alexpearce - If you have time, you could copy & paste the get_random_state utility function over to probfit and use it.

I agree, that solution is much nicer.
For now, I'll switch from random to numpy to fix this particular issue. I will open a separate issue for switching to the get_random_state method in the tests.


[Bug Fix] Fix a parameter passing issue.

Description
When using a HuggingFaceLLM with streaming generation in the query engine, the EOS tokens appear in the output text.
Fixes # (issue)
Version Bump?
Did I bump the version in the pyproject.toml file of the package I am updating? (Except for the llama-index-core package)

[ ] Yes
[x] No

Type of Change
Please delete options that are not relevant.

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

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[ ] Added new unit/integration tests
[ ] Added new notebook (that tests end-to-end)
[x] I stared at the code and made sure it makes sense

Suggested Checklist:

[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added Google Colab support for the newly added notebooks.
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] I ran make format; make lint to appease the lint gods

@BarryRun can you run make lint and also bump the package version in the pyproject.toml for huggingface llm?

@logan-markewich I directly submitted the PR by editing in github.com. If there is a block, you can close the PR and fix the problem by yourself : )


3.17-17acebe3-ls14

Test to check it updates

🦙 MegaLinter status: ✅ SUCCESS

Descriptor
Linter
Files
Fixed
Errors
Elapsed time

✅ DOCKERFILE
hadolint
1

0
0.16s

✅ EDITORCONFIG
editorconfig-checker
1

0
0.02s

✅ REPOSITORY
checkov
yes

no
11.71s

✅ REPOSITORY
gitleaks
yes

no
0.15s

✅ REPOSITORY
git_diff
yes

no
0.0s

✅ REPOSITORY
secretlint
yes

no
1.07s

✅ REPOSITORY
trivy
yes

no
5.64s

See detailed report in MegaLinter reports
Set VALIDATE_ALL_CODEBASE: true in mega-linter.yml to validate all sources, not only the diff
MegaLinter is graciously provided by


Fix summary fn

Codecov Report
Patch coverage: 72.72% and project coverage change: +0.14 :tada:

Comparison is base (2f2d3b0) 95.04% compared to head (5aa0482) 95.19%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #20      +/-   ##
==========================================
+ Coverage   95.04%   95.19%   +0.14%
==========================================
  Files          17       17
  Lines         808      811       +3
==========================================
+ Hits          768      772       +4
+ Misses         40       39       -1

Impacted Files
Coverage Δ

pysyncon/base.py
84.41% <0.00%> (+2.27%)
:arrow_up:

pysyncon/synth.py
91.30% <80.00%> (-1.92%)
:arrow_down:

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Phase End Milestone - Confetti forever

Describe the bug
Keep getting confetti if you make description changes to the locked end event
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.

@djnunez-aot what is the estimate here?

@Connor1892   please note that @djnunez-aot is now on holiday!


Audio duration is not loaded before playback is started

Looks like it is because when player is initialized, suspend event is triggered. As a result 'loadedmetadata' event is not fired until you start playing the audio. Tried the same mp3 file using raw audio html5 tag in Chrome, and duration is set fine before you even click on play button. Issue can be reproduced in mediaelement.js demo page v4.2.16

Looks like the reason is that 'preload' attribute is set to 'none' by default. But documentation says it should be 'metadata'
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/audio

The default value is different for each browser. The spec advises it to be set to metadata.


X-WOPI-ItemVersion required on PutFile, Lock, and Unlock responses

The documentation should say X-WOPI-ItemVersion is a required response on PutFile, Lock, and Unlock for partners doing the iOS/Mobile integration.

I suggest putting this on the requirements for iOS page.

This was addressed in commit eb64f84.


Provide .context() on miette::Report

Can we have .context() on miette::Report as an alias to wrap_err?
This is convenient to make fn_error_context work on miette::Result returning functions..
Note: both anyhow::Error and failure::Error have such method (but don't have wrap_err).

I guess I'll take a PR to do this, if that's ok :)

wait, I looked into this more and... do we even need that PR? .context() and .with_context() are already defined for Result? See https://github.com/zkat/miette/blob/main/src/eyreish/context.rs#L66-L79

Yes we need that, because fn_error_context does map_err(|e| e.context(...)). Most likely, the reason for that is that .context is a method, so you don't have to require users importing an extension trait. And extension maybe a problem if you use multiple of these libraries in the same file (one reason for that is to gradually migrate your code from one library to another)


build: when automatically pulling in changes from @octokit/openapi, automatically fix linting errors on the output

This updates the "update" task which pulls in changes to @octokit/openapi to run Prettier and automatically fix code style and formatting issues.
If we assume that the code currently in main is valid from a linting perspective - which it should be, given our required checks, and this will only affect code that was actually generated by the update flow.

The problem seems to be when the package.json files are modified in the update script.
This line of the update-package script should be running the linter, but it seems as though it isn't
https://github.com/octokit/openapi-types.ts/blob/8da5974b82683dce30330eafc740da21039f94f8/scripts/update-package.js#L34

The problem seems to be when the package.json files are modified in the update script.
This line of the update-package script should be running the linter, but it seems as though it isn't
https://github.com/octokit/openapi-types.ts/blob/8da5974b82683dce30330eafc740da21039f94f8/scripts/update-package.js#L34

The problem seems to be when the package.json files are modified in the update script.
This line of the update-package script should be running the linter, but it seems as though it isn't
https://github.com/octokit/openapi-types.ts/blob/8da5974b82683dce30330eafc740da21039f94f8/scripts/update-package.js#L34

Interesting! I didn't see that. What do you think of doing it this way instead? It's less error prone as it relies on the existing npm script (not an extra line of random code!) and it will make sure that all files are linted.

Interesting! I didn't see that.

It was added in #204

What do you think of doing it this way instead?
It's less error prone as it relies on the existing npm script (not an extra line of random code!)

I don't necessarily agree. We do it this way in many other repositories and it works just fine. ^1

it will make sure that all files are linted.

There's a workflow that will error if any files are not linted

Here's another script that modifies the package.json files and where it seems that prettier is not working:
https://github.com/octokit/openapi-types.ts/blob/d4826cf589a33cd635f9a1b9c7b7717ae17d13df/scripts/generate-types.js#L43
So the problem, in this case, is that the CLI interface is not returning the same results as the API interface

I'd be inclined to solve it this way because it's simpler, and I'm not sure what value we get out of calling prettier.format() from JavaScript rather than just using the npm script which is already there.
But I'm happy to leave this if people feel strongly!

I'd be inclined to solve it this way because it's simpler, and I'm not sure what value we get out of calling prettier.format() from JavaScript rather than just using the npm script which is already there.

I agree it's the simple way and will fix it.
Since we write the files from javascript itself, it makes sense to write the file back already linted, so you don't have to run the lint script yourself for the generated files.

@wolfy1339 Not sure if I understand your message - are you okay for me to move forward with this approach? 😊 (Just noticed that you haven't approved!)

I'm okay with the solution for now, until we find the actual cause of the issue

Closing in favour of #208


Add case split, add clause

How about I give you push access to the repo? Then I'll only need to do the bower releases

Up to you, you've pretty much instantly merged changes so far so no difference to me :)


Adb 2.0.0 beta-2  playback sensor Nvidia Shield tv not working

Hi'
I used the pluggin for a while and since i updated to the most recent version 2.0.0 beta-2 the playback sensor on my nvidia shield tv 2019 doesn't trigger anymore. I revented back to the last stable version 1.5.5 and its flawless.
Also tried the 2.0.0 beta-1 same thing as beta-2.
Thank you very much

Hey, Thank you for the report. Rereading the 1..5.5 version to figure out what missing.

With beta-3 it works when something play.
But when nothing plays the detector remains active or sometimes take 8 sec to the sensor to disengage.
thank you

It’s actually an intended behavior, but it can be configure in config.json with playbacksensordelay, which I forget to write in readme.md, but it’s  in Homebridge Config UI X’s plugins configuration. The default value is 10 seconds if you didn’t set the value.

But. Yes, you’re correct I notice the sensor sometimes didn’t turn off. Need to check on it.

Thank you

Merge with issue #81


Update(PolicyEngineRelease): Update to 0.2.1-rc

Added Release Candidate release, as it solves a critical bug for multiple customers

Update as per my request in https://armory.atlassian.net/browse/BOB-30516


[DEVOP] Use auto-changelog

I think we should investigate https://github.com/CookPete/auto-changelog and have contributor adopt a semi-strict commit message pattern. That way we generate the changelog once during release and it will auto-link all our github PR/issues as well.
Caveat is that it's a nodejs tool. But the good thing is only the release engineer will need to run it once every release.

This is an interesting idea, but to me it seems like policing commit messages might end up being more work than reminding people to add to the log before merge.
https://keepachangelog.com/en/1.0.0/#bad-practices


feat: Implement bulk-issuance for W3C credentials

[x] Implement W3C schema list for download template
[x] Download CSV template based on W3C schema
[x] Implement file upload for W3C CSV
[x] Add logic In the processer for W3C issuance
[x] Add error details while W3C issuance

PR LINK


Angular maps info window anchor

Is there an option to set the info window anchor position few px above its location?

That's google maps setting.
https://developers.google.com/maps/documentation/javascript/infowindows.
https://developers.google.com/maps/documentation/javascript/3.exp/reference#InfoWindowOptions
I see setPosition and pixelOffset.
People may wonder why I am just referencing google document without the actual implementation. It's because this is just wrapper of google maps api, and the implementation is just exactly the same as google api by setting attribute or using vanilla Javascript.
Closing this as out of scope.


Additional client attributes do not work anymore

I use my customer wrapper cookbook:
https://github.com/runningman84/chef-monitor/blob/master/recipes/default.rb
Since version 2.5 my nodes do not contain any additional attributes like platform and so on. Swichting back to 2.3 solved this issue.

works again with version 2.6


[StyleCop] Update XML documentation suppress rule

We remove the method to suppress the rule SA0001 applied to the projects which do not support ruleset files due to currently all the projects support the ruleset file defined.

Also, the rules SA0001 and SA1652 about the XML documentation was moved into the ruleset file.

Finally, we updated the StyleCop version to 1.1.0-beta008, to properly support the C# version used by the projects of the solution.

Currently, all the projects are configured to set the latest major version of C#.

Me parece confusa la primera oracion:
"We remove the method to suppress the rule SA0001 applied to the projects which do not support ruleset files due to currently all the projects support the ruleset file defined."
Pondria algo asi:
"Remove the SA0001 rule that applies to projects that don't support ruleset files as this feature was added for all the existing projects."
y en "Also, the rules SA0001 and SA1652 about the XML documentation was moved into the ruleset file." va were en lugar de was.
Despues esta todo bien para mi!

I think we might add some evidence about if the project uses C# 7.0. If I'm not mistaken, the Bot.Configuration project has some classes which implement C# 7.0 tuple syntax.


Feature: gamespy 2

Related issue: #11

Gs2 maybe late to Q1 due to many release windows opening that i have obligations with.

Superseeded by #47.
I did look into some stuff here when I got into issues on my rewrite, I will add you as a co-author.


Adding Python language

@ashish1294 I tried adding Python language to the tool. It's not working fine on my system. Can you please check and point out what's wrong with it?

Everything looks okay. But you will also have to edit the prog.py file to handle the python case.
It should work then. Note I am on vacation for a week and I will be able to help with code after that only.
Great work (y)

Just added Python to prog.py too. Still not working for me. Do check it once you're back.

Make sure to delete .code-now folder.

I tested it again on a stand alone Linux system and found it working again. So I will go ahead and merge it.

@sahildua2305 : I just spotted a silly bug. The template name should have been py_template.py. you named it as python_template.py causing the prog.py to raise exception. I have fixed this.


Write a R program to find volume of a cube

Description
Write a R program to find volume of a cube
Volume of cube = Side^3
Side : 2

Volume : 8

How to contribute

Save the solution in program/find_volume_of_a_cube.r file
Add find_volume_of_a_cube.r file in find-volume-of-a-cube folder

!assign

Duplicate of #63


PlatUI-3154: Add API test library dependencies

Simplify API test dependency management by including commonly required dependencies in library.

the pr builder says "tests completed successfully" but actually the build is shown as a failure in jenkins, seems like maybe not having any tests is causing the publishing to fail with junit, maybe - though I could be misreading
ERROR: Step ‘Publish JUnit test result report’ failed: No test report files were found. Configuration error?


Add wording around the time it takes images to be available

@justindavies : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@mlearned Can you review and approve please?

@mlearned - can you take a look?

Thank you for the feedback.
LGTM
#sign-off

@zr-msft: I'm sorry - only the author of this article, @mlearned, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.

@ktoliver : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@ktoliver : Thanks for your contribution! The author(s) have been notified to review your proposed change.


Allow customisation of Etcher's colour scheme

Potentially from an archive metadata.

After some thought, I believe this can be very easily solved with native CSS variables, which as it seems, they are dynamic, and we can change them at runtime, elegantly affecting every CSS component that uses them. See https://philipwalton.com/articles/why-im-excited-about-native-css-variables/. I think we can find a nice way to have SCSS and native CSS variables to operate together so we can introduce this feature without much friction.
As an alternative, we can:

Completely decouple the "color" rules from the "structure" rules.

Make use of the new classes by @extending them.
Simply modify the .theme-* rules at runtime. The fact that we're using @extend on them should make the changes reflect on the components that use them.

In any case, we must solve the color variable mess that we have at the moment, and decide on a sensible list of colors that we want to give users access to, potentially as a layer of abstraction above components.

In order for this task to be feasible, the first step is to drastically simplify the user interface and the colors currently being used there. Ideally, we'll have 3 "main" colors, and there will be straightforward rules to infer the remaining ones based on that.
This means:

Making sure we're not using slightly different colors in more than one location if using just one makes more sense.
Reducing extra colors as much as possible without sacrificing the experience.

See http://web.archive.org/web/20101101160133/http://blog.dabbledb.com/2007/04/white--or-green.html for some crazy inspiration.
The goal would be to have extended archives specify at most 3 primary colors, and build color palettes on the fly that are ensured to look good, drawing ideas from color theory, etc.

See http://web.archive.org/web/20101101160133/http://blog.dabbledb.com/2007/04/white--or-green.html for some crazy inspiration.

That's pretty neat! :-D
As long as there's also an option for the users to manually specify their colour scheme too.

I guess we could allow users to override certain colors if really needed, but that should be really discouraged though.

Honestly, I don't think that you would need to allow overrides. If you do, inevitably people are going to utilize the feature, and users will end up with an inconsistent experience with Etcher: First they see a pretty, well-designed app, but then it changes into something much uglier upon image selection. Start with the automatic option and then add a manual override if it is largely requested.

I was just thinking that an application that got auto-coloured with the bold colours from e.g. the Raspberry Pi logo might look a bit too "intense"? ;)
But I'm not a graphic designer, so feel free to ignore me...

That's definitely something to consider. It would be nice to see how a basic implementation of the proposed algorithm handled this case and then adjust expectations accordingly. Honestly, this is something that I would personally be interested in attempting if I had some free time and wasn't loaded with other GitHub projects to help maintain :laughing:


Auto-refresh by entering in "Peers"

If the user enter in the "peers" panel, it should refresh automatically just by entering in it.

To be closed with new version


fix: fish shell

This PR is replacing the here-document syntax with an install file due to fish shell not supporting the here-document syntax...
I've tested it on linux/fish and macOS.
resolves: #7

I changed it to just use bash -c can you test it does it still work on fish?

It does work with fish. You have a better solution!


Float-free libcore (for embedded systems and kernel drivers, among other things)

(I was talking to @huonw about embedded Rust the other day, and he suggested I write this up as an RFC issue. I hope this is in the correct place!)
I'm having a ton of fun hacking on kernels in Rust. Rust is a wonderful fit for the problem domain, and the combination of libcore and custom JSON --target specs makes the whole process very ergonomic. But there's one issue that keeps coming up on #rust-osdev: libcore requires floating point, but many otherwise reasonable environments place restrictions on floating point use.
Existing discussions of this issue can be found here:

Compiling libcore without SSE leads to LLVM ERROR: SSE register return with SSE disabled. If you disable floats in LLVM and rustc, you break the parts of libcore that deal with floats.
Fixes #26449. A pull request to support libcore without floats, closed without merge. A version of this patch is provided by rust-barebones-kernel, and this patch is frequently recommended on #rust-osdev.
Are floats really dependency free?. Briefly discusses the fact that libcore depends on floating point.
Pre-RFC: Dealing with broken floating point. This is a more general discussion of floating point issues, but at one point it proposes #[cfg(float_is_broken)]. Not sure how relevant this is.

Datum 1: Some otherwise reasonable processors do not support floating point
There's always been a market for embedded processors without an FPU. For the most part, these aren't pathologically weird processors. The standard ARM toolchain supports --fpu=none. Many of the older and/or lower-end ARM chips lack FPUs. For example, the FPU is optional on the Cortex-M4.
Now, I concur (enthusiastically) that not all embedded processors are suitable for Rust. In particular, there are processors where the smallest integer types are u32 and i32, making sizeof(char) == sizeof(uint32_t) == 1 in C, and where uint8_t literally does not exist. There were once quite a few CPUs with 36-bit words. I agree that all these CPUs are all fundamentally unsuitable for Rust, because Rust makes the simplifying decision that the basic integer types are 8, 16, 32 and 64 bits wide, to the immense relief of everybody who programs in Rust.
But CPUs without floating point are a lot more common than CPUs with weird-sized bytes. And the combination of rustc and libcore is an otherwise terrific toolchain for writing low-level code for this family of architecture.
Datum 2: Linux (and many other kernels) forbid floating point to speed up syscalls and interrupts
Another pattern comes up very often:

Everybody likes CPUs with a lot of floating point registers, and even a lot of vector floating point registers.
Saving all those floating point registers during a syscall or hardware interrupt can be very expensive. You need to save all the registers to switch tasks, of course, but what if you just want to call write or another common syscall?
It's entirely possible to write large amounts of kernel code without needing floating point.

These constraints point towards an obvious optimization: If you forbid the use of floating point registers in kernel space, you can handle syscalls and interrupts without having to save the floating point state. This allows you to avoid calling epic instructions like FXSAVE every time you enter kernel space.  Yup, FXSAVE stores 512 bytes of data.
Because of these considerations, Linux normally avoids floating point in kernel space. But ARM developers trying to speed up task switching may also do something similar. And this is a very practical issue for people who want to write Linux kernel modules in Rust.
(Note that this also means that LLVM can't use SSE2 instructions for optimizing copies, either! So it's not just a matter of avoiding f32 and f64; you also need to configure your compiler correctly. This has consequences for how we solve this problem, below.)
Possible solutions
Given this background, I'd argue that "libcore without floats" is a fairly well-defined and principled concept, and not just, for example, a rare pathological configuration to support one broken vendor.
There are several different ways that this might be implemented:

Make it possible to disable f32 and f64 when building libcore. This avoids tripping over places where the ABI mandates the use of SSE2 registers for floating point, as in https://github.com/rust-lang/rust/issues/26449. The rust-barebones-kernel libcore_nofp.patch shows that this is trivially easy to do.
Move f32 and f64 support out of libcore and into a higher-level crate. I don't have a good feel for the tradeoffs here—perhaps it would be good to avoid crate proliferation—but this is one possible workaround.
Require support for soft floats in the LLVM & rustc toolchain, even when the platform ABI mandates the use of SSE2 registers. But this is fragile and cumbersome, because it requires maintaining a (custom?) float ABI on platforms even where none exists. And this is currently broken even for x86_64 (https://github.com/rust-lang/rust/issues/26449 again), so it seems like this approach is susceptible to bit rot.
Compile libcore with floats and then try to remove them again with LTO. This is hackish, and it requires the developer to leave SSE2 enabled at compilation time, which may allow SSE2-based optimizations to slip in even where f32 and f64 are never mentioned, which will subtly corrupt memory during syscalls and interrupts.
Other approaches? I can't think of any, but I'm sure they exist.

What I'd like to see is a situation where people can build things like Linux kernel modules, pure-Rust kernels and (hypothetically) Cortex-M4 (etc.) code without needing to patch libcore. These all seem like great Rust use cases, and easily disabling floating point is (in several cases) the only missing piece.

/cc https://github.com/rust-lang/rust/issues/27701

[Option 4] Compile libcore with floats and then try to remove them again with LTO. This is hackish, and it requires the developer to leave SSE2 enabled at compilation time, which may allow SSE2-based optimizations to slip in even where f32 and f64 are never mentioned, which will subtly corrupt memory during syscalls and interrupts.

Since LLVM will implement small-ish memcpys by going through XMM registers, this is bound to happen. For example: [u64; 2] copies in release mode.

I think there's actually a bit of a matrix here which can be helpful when thinking about this, we've got the two vectors of "libcore explicitly uses floating point" and "llvm codegens using floating point". Looking at the possibilities here:

both turned on -- makes sense, it's what we do today.
libcore on, llvm off -- looks like this is https://github.com/rust-lang/rust/issues/26449, just yields an LLVM error (which kinda makes sense)
libcore off, llvm on -- this is isn't enough to cover the kernel use case unfortunately as @rkruppe mentioned. Although XMM registers aren't explicitly used LLVM will optimize patterns into using them.
both turned off -- this is what kernels will need to do (as you've discovered)

With this in mind, I think it may be better to frame this around "disabling floating point support in generated code" rather than specifically omitting it from libcore itself. For example if we look at the above matrix, if LLVM is allowed to use floating point registers, then there's no reason to omit the support from libcore anyway (modulo the fmod issue, which I think is somewhat orthogonal to the usability in kernels).
As a result, this may lead itself quite nicely to a non-invasive implementation. For example on intel processors there may be something like #[cfg(target_feature = "sse2")] which we could use to gate the emission of f32/f64 trait implementations in libcore. To me this makes more sense than "pass a semi-arbitrary cfg flag to libcore and also disable some codegen". I would personally be more amenable to a patch like this to libcore, and note that this also naturally extends itself well I believe to "libcore supports floats if the target does" so weird architectures may be covered by this as well.

@rkruppe I agree completely. If we don't want SSE2 instructions, we should tell LLVM not to generate them. Generating them and then trying to remove them will obviously fail.
@alexcrichton Thank you for clarifying the issues! If I understand it, you're proposing two things here:

Floats should always be included in libcore if the target supports them, and excluded if it doesn't.
This could be implemented by using conditional declarations like #[cfg(target_feature = "sse2")] in libcore.

Am I understanding you correctly? If so, I agree that (1) sounds like a perfectly plausible way to address these issues. But if you intended (2) as a literal proposal (and not just an abstract sketch of an implementation), then I'm not convinced it's the right way to go.
The problem with writing something like #[cfg(target_feature = "sse2")] is that libcore would need to know about every possible platform, and you'd quickly wind up with something like:
#[cfg(or(target_feature = "sse2", target_feature = "x87", target_feature = "neon",
         target_feature = "vfp", target_feature="vfp4", target_feature = "soft_float"))]

...just to cover the Intel and ARM architectures. And depending on how you implemented it, that conditional might have to appear multiple times in libcore. This seems like it would be both ugly and fragile.
Some possible alternatives might be:
 #[cfg(target_feature = "float"))]

…or:
 #[cfg(target_float))]

The advantage of these approaches is that libcore wouldn't need to contain long lists of target-specific features, and the decision-making process could be moved closer to librustc_back/target, which is in charge of other target-specific properties.
Logically, this information feels like it would be either:

A TargetOption, or
Something that librustc_back/target could infer from Target and TargetOption, using code that knows how to interpret features like sse2 and neon.

I'd guess that (1) is fairly easy to implement, and it would work well with the target *.json files. (2) would require adding new Rust code for each architecture, to interpret features correctly. Either would probably work.
But in the end, I'd be happy to implement just about any of these approaches—whatever works best for you. Like I said, my goal here is to provide a long-term roadmap for safely writing things like kernel modules using libcore, and I'm happy with anything that gets us there. :-)

@emk you're understanding is spot on, that's precisely what I was thinking. I'd be fine extending the compiler to have a higher level notion of "floating point support" and disabling that means something different on every platform, and adding a particular #[cfg] for that seems fine to me!
Some prior art here could be the recent addition of the target_vendor cfg gate. It's both feature gated (e.g. not available on stable by default) but defined in json files as well.

Great, thank you for the pointer to target_vendor.
Let me sketch out a design to see if I'm in the right ballpark.
Right now, TargetOptions has a bunch of fields that control specific kinds of code generation features, including disable_redzone, eliminate_frame_pointer, is_like_osx, no_compiler_rt, no_default_libraries and allow_asm.
We could add a has_floating_point to TargetOptions, and a #[cfg(target_has_floating_point)] option behind a feature gate. We could also use better names if anybody wants to propose them. :-) This #[cfg] could be used to conditionalize f32 and f64 in core.
This way, we could define a kernel-safe x86 target using something like:
    "features": "-mmx,-sse,-sse2,-sse3,-ssse3,-sse4.1,-sse4.2,-3dnow,-3dnowa,-avx,-avx2",
    "has-floating-point": false,
    "disable-redzone": true,

I think that this would actually be a fairly small, clean patch. (Alternatively, we could try something more ambitious, where has_floating_point automatically implied the corresponding features list, but that would probably require adding another field named something like features_to_disable_floating_point to TargetOptions.)
Would this design work as is? If not, how could I improve it? If we can come up with a basically simple and satisfactory design, I'd be happy to try to implement it. Thank you for your feedback!

@emk yeah that all sounds good to me, I'd be fine if disabling floats just implied all the necessary features to pass down to LLVM so they didn't have to be repeated as well.

@alexcrichton Thank you for the feedback!
For a first pass, I'll try to implement has_floating_point in TargetOptions. If we want that to automatically disable the corresponding features, though, we'd probably still need to specify what that means in the target file, at least in the general case:
    "features": "...",
    "disable-floating-point-features": "-mmx,-sse,-sse2,-sse3,-ssse3,-sse4.1,-sse4.2,-3dnow,-3dnowa,-avx,-avx2",
    "has-floating-point": false,
    "disable-redzone": true,

Above, we disable floating point, and then we need explain what that means, so that the compiler can do it for us.
I'm not sure that's really an improvement over:
    "features": "-mmx,-sse,-sse2,-sse3,-ssse3,-sse4.1,-sse4.2,-3dnow,-3dnowa,-avx,-avx2",
    "has-floating-point": false,
    "disable-redzone": true,

Can anybody think of a better design? I'm definitely open to suggestions here, and I'm sure I don't see all the use cases.
And thank you again for your help refining this design!

Hm yeah that's a good point I guess, the features being passed down do probably need to be generic. It's a little unfortunate that you can still construct an invalid target specification by disabling floating point and not disabling the features, but I guess that's not necessarily the end of the world.

OK, I've planned out a block of time to work on this week (hopefully by midweek-ish, if all goes well).

Ran into this again today :) @emk did you get a chance to work on it at all?

Not yet! I'm bounding between two different (free-time) Rust projects right
now, and this affects the other one. You're welcome to steal this out from
under me if you wish, or you can prod me to go ahead and finish it up as
soon as possible. :-)
Le sam. 12 déc. 2015 à 12:02, Steve Klabnik<EMAIL_ADDRESS>a
écrit :

Ran into this again today :) @emk https://github.com/emk did you get a
chance to work on it at all?
—
Reply to this email directly or view it on GitHub
https://github.com/rust-lang/rfcs/issues/1364#issuecomment-164168254.

Okay :) It's not mega urgent for me, either, so I might or might not :)

As a workaround, I created https://github.com/phil-opp/nightly-libcore. It includes thepowersgang's libcore patch.

Great idea guys. Though is getting rid of floating point only part of the picture?
Excuse me if I don't have the full perspective, but what I need is to disable (ARM) neon/vfp instructions in bootstrap/exception handler code so that I know that it won't require the fpu to be enabled or the fpu register file to be saved. (llvm-arm seems to like vldr and vstr for multi-word moves).
I would want to link with a core containing the fpu routines, but know that certain sections don't access the fpu registers. If I understand things the features are defined the root compilation unit making it hard to set compiler features for a section or sub-unit?

How would such an option affect the f32 and f64 types in the language? Would any use of these types become an a compile-time error?

How would such an option affect the f32 and f64 types in the language? Would any use of these types become an a compile-time error?

Nope. They'll just not be included in libcore.

You cannot “not” include primitive types. They are a part of the language.

@nagisa Of course not. They're primitive. But you can stop providing an API for them, which is what this RFC suggests.

@Ticki I guess quoting the original question is the best here, since there seems to be some misunderstanding:

How would such an option affect the f32 and f64 types in the language? Would any use of these types become an a compile-time error?

@Amanieu The answers are “in no way” and “no”. You would still be able to create floating point literals using the notations (0.0, 0.0f32, 0.0f64, 0E1 etc) you use today, use the types (but not necessarily the values of these types) f32 and f64 anywhere where the use is allowed today and use your own (possibly, software) implementations of operations on floating point values to do calculations.

Just chiming in to say that this is an issue I'm hitting too.

Whatever we decide as the solution, I think that it should be user-friendly enough that low-level crate developers can also selectively omit floating-point code from their crates. It should also be documented in the Rust Book so that people know about it.
By that, I mean that instead of a large list of targets to omit, we should definitely have a #[cfg(float)] or similar that people can remember and use easily.

Will it be possible to do things that llvm disallows?
https://llvm.org/bugs/show_bug.cgi?id=25823
http://reviews.llvm.org/rL260828

@petevine Generally, no. LLVM's assertions are there for a reason. It will almost per se lead to strange bugs.

Is there any progress on this? I think a has_floating_point flag in the target json as proposed by @emk would be the easiest solution. Then we wouldn't need to maintain custom no-float patches anymore.
It would also allow using cargo-sysroot for cross compiling, which makes development for custom targets much easier.

I'm see if I can free up some time again soon to take another look at this.

I had some free time today and started hacking on this. The results are in rust-lang/rust#32651.
Sorry for stealing this, @emk. I hope it's okay with you…

@phil-opp Never any problem at all. :-)

Just chiming in from the sidelines: there exist common CPUs which support single-precision floating point in hardware, but not double, for example often ARM Cortex-4M with fpu enabled. Maybe it make sense to have separate feature flags for f32 and f64…
On the other hand, probably any such platform that LLVM supports will have functional soft-float emulation for doubles, so perhaps distinguishing f64 and f32 support is more trouble than it's worth...

soft-float should work on all targets you just need the +soft-float target feature to make sure no floating point code (using SSE registers on x86) is generated in addition to using the soft float ABI which you get with -C soft-float . Then there's no real need to make the floats in core optional, is there?
(side note: I think the rustc -C help incorrectly says it will generates software floating point calls, when actually it just means a soft-float ABI is used but it could still generate code using the FPU)

@parched Not all targets support soft-float. In particular, x86_64 doesn't, which results in a LLVM assert if you try to do floating-point operations when the sse feature is disabled.

@Amanieu I'm not getting any LLVM assertions with x86-64 and -C soft-float -C target-feature=-fxsr,-mmx,-sse,-sse2,+soft-float, where are you seeing them?

@parched see https://github.com/rust-lang/rust/issues/26449

@Amanieu, yes I saw that, see my comment at the bottom, if you add +soft-float you don't get the assertion (I tested it)

I think what we should actually do concerning this general issue is:

Get rid of -C soft-float. It is useless because you need a new sysroot too when you change the abi

Add a float-abi option to the target configuration instead.

I've just tried the -C soft-float / +soft-float combination and it really works! The libcore library and the rest of my kernel compile without problems. The generated code contains no SSE instructions [1] and still runs without crashing, even if I leave SSE disabled in the hardware.
Thanks so much for the hint, @parched! I'm strongly in favor of a float-abi target feature.
--
[1] objdump still shows a few movaps instructions in implementations of core::num::GenericRadix::fmt_int. But I'm not sure if they're actually used.

@phil-opp Did you disable SSE as well (-sse target feature)? Keep in mind that even with floating-point disabled, the compiler can still vectorize integer operations using SSE instructions.

I use the features proposed by @parched above:
"features": "-mmx,-fxsr,-sse,-sse2,+soft-float",

Ok, I can't reproduce the movaps instructions. They're gone now…

Ok, I can't reproduce the movaps instructions. They're gone now…

Yes, I was surprised because I'm sure when I did objdump -d libcore*.rlib | grep xmm I got nothing.
Note also, the -sse2 isn't needed because it depends on sse

Note also, the -sse2 isn't needed because it depends on sse

Thanks! What about -fxsr? For what do we need it?

From a quick grep of LLVM, it seems all that flag does is enable/disable the FXSAVE and FXRSTOR instructions in the assembler.

Well, I don't think it's actually needs to be disabled, it's for storing and restoring fp registers, so it's never going to be used if mmx and sse are disabled.

In any case the compiler won't be generating that instruction on its own without explicitly calling the intrinsic for it.

Yes, so actually it's probably better not to disable this for kernel development as it could be useful intrinsic when switching user threads.

Disclaimer: I'm not an x86 kernel/OS dev :-)
Can someone confirm that using features: -sse,+soft-float,etc does everything that x86 kernel devs want i.e. fast context switches (LLVM doesn't use/emit SSE/MMX instructions/registers), core can be compiled without modification (no need to cfg away chunks of it) and floating point operations (e.g. x:f32 + y:f32) lower to software routines (e.g. __addsf3)? If yes then it sounds like this issue is solved and there's no need to modify the core crate or do some other language-level change to support this use case. Is my conclusion correct?

I can confirm they lower to software routines as expected and only use general purpose registers . I can't confirm this is enough for the Op, but believe it should be so.

I just tested this on AArch64 and it works fine with "features": "-fp-armv8,-neon". Note that you will need to recompile compiler-rt since these options change the ABI (in particular, floating-point values are passed in integer registers).

@parched @Amanieu Thanks for checking!

Note that you will need to recompile compiler-rt since these options change the ABI (in particular, floating-point values are passed in integer registers).

Interesting! Given that we would ultimately like to have Cargo build compiler-rt intrinsics when you build core/std, perhaps we'll have to add a target_float_abi field to target specifications; that way Cargo can check that field to build compiler-rt with the right float ABI. Or perhaps we'll port compiler-rt intrinsics to Rust before that becomes necessary.

In practice you can probably get away with a standard compiler-rt as long as you don't use any floating point values in your code.

From a quick grep of LLVM, it seems all that flag does is enable/disable the FXSAVE and FXRSTOR instructions in the assembler.

Hmm; does that mean that if you pass -sse, you can't use SSE instructions in inline assembly blocks?  Because that's somewhat unhelpful.

does that mean that if you pass -sse, you can't use SSE instructions in inline assembly blocks?

No it doesn't apparently (I just tested), but why would you want to use SSE instructions if you have turned it off?

The reason to turn it off is you don't want uncontrolled use of SSE (or, context switch unsafe) instructions, or use of them anywhere near ABI boundaries. Controlled use is fine, and desirable – you're probably going to want fast crypto, vector acceleration, etc. at some point.

Well in that case I would turn +sse back on for just that compilation unit then you get the benefit in rust code too.

That'd be pretty uncontrolled. Generally, a few inline functions to safely wrap assembly blocks will suffice.

What's the "state of the union" on this particular issue? Do we still need to use libcore_nofp.patch?

The state appears to be that according to @japaric (link] and @parched (link](https://github.com/rust-lang/rfcs/issues/1364#issuecomment-236380922)) using the new soft-float feature causes floating-point values to be stored in general-purpose registers and manipulated via software implementations. I guess @phil-opp is the one to ask as to whether that's sufficient for kernel development without modding libcore; I don't have the right setup to test it right now.

Well, you shouldn't really recompile anything. 'soft-float' (or equivalent for other targets) should already be set as a feature of the target (or not) which you shouldn't change with 'rustc' codegen options otherwise stuff won't link probably.
Obviously if you need to create a new custom target for this then all of 'core'/'std' needs to be compiled as usual with a custom target.

I would like to add, that it's actually possible to use floats inside Linux kernel:
	kernel_fpu_begin();
	...
	kernel_fpu_end();

But with some restrictions. This function is not rentable, is pretty undocumented and AFAIK would make current thread non-premptable.
The same story for Windows Kernel, thou is more documented. And it's seems it also makes thread non-preemptable (if I understand what "disables all kernel-mode APC delivery" means).
So to sum this up. In C world you could use floats in the kernel if made precautions, but it's encouraged to use it in localized code and disable FPU as soon as possible.
If we are talking about C float-related code could be moved to a separate .c file that is compiled with different options and then linked together with main code.
Not sure how that could be addressed in Rust and with libcore.  We could also use linker and move FPU code to separate crate, called using C ABI.  But perhaps a better solution could be worked.
P.S. I'm not experienced with this stuff, googled this stuff, and decided to add this info to the current thread as it's not covered in discussion.

This is a real pain for writing Rust for the Commodore 64 and other 6502 machines. Currently core needs to be patched to disable floating point.

Hitting this myself today, though not sure if this is a Rust language thing or an LLVM thing. The compiler appears to be emitting fmov instructions on aarch64 in a kernel context, which explicitly doesn't have CPACR_EL1[FPEN] set, which is causing ptr::volatile_write() to fail due to it being emitted in debug builds in the precondition check for pointer alignment.
Is there really no way to shut off floating point register / instruction emission in Rust after 9 years? GCC has had -mgeneral-regs-only for ages.

You can use the aarch64-unknown-none-softfloat target to generate AArch64 code which doesn't use the FP registers.

@Amanieu that doesn't seem to fix it when specifying it in "llvm-target": "aarch64-unknown-none-softfloat" in the target JSON file. I'm still getting an fmov emission.

This is a builtin rustc target, available through rustup.
If you're already using a target json then you can base it on the built-in json for the target:
rustc --print target-spec-json --target aarch64-unknown-none-softfloat -Z unstable-options


Refactor at rules

Refactor at-rules + fix edge cases bugs + tests + recovery mode for bad parsed at-rules + remove unnecessary methods + prepare for future improvements

Alternatively, you can just skip bumping version and I'll use a script to bump version.

yes, it will be good