Historical data modal cropped out of browser

Describe the bug
Historical data modal gets cropped out of browser when we resize the browser width to a size smaller than the modal.
To Reproduce
Steps to reproduce the behavior:

Go to any of the details pages
Display historical data of an item
Resize browser width to it's smaller than the modal
See that there is no way to reach the rest of the modal, we can't close the modal (close button is cropped out) or see the rest of it

Expected behavior
There should be a way to reach the whole modal when browser is too small to display it whole - the modal would be resized too, or we could scroll to the sides
Screenshots

Desktop (please complete the following information):

OS: RHEL
Browser Chrome
Version 73

The modal is a fixed size. If the window is smaller than the modal, you must scroll.

It scrolls only up and down, when I resized the browser down in terms of width, I couldn't get to the rest of the modal

Yes, this is nothing new. Scrolling horizontally is not currently supported by the PatternFly modal.
I've filed the issue below.
https://github.com/patternfly/patternfly-react/issues/new

This has been fixed in PatternFly and will be introduced to the koku-ui when the latest packages are updated.


PS-2335 Fix Race Condition

The real fix will need to be made on the connection, but this should put a stop to it for now.
vice https://keboola.atlassian.net/wiki/spaces/TECH/pages/2383511594/Input+mapping+to+workspace+Consolidation

Thanks odin, I added a comment there


iframe Support

Please add iframe support for markdown. Not to add new tags to support iframes (though that would work) but not to exclude iframes. Currently have a mix of markdown and iframes I need to support.

showdown does not exclude iframes. You can see an example here:
http://showdownjs.github.io/demo/#/<iframe src%3D"http%3A%2F%2Fwww.w3schools.com">
What version are you using?

Using BTF-Markdown for angular which it looks like it's using version ~0.3.1 of showdown.

That version is very outdated (current version is 1.3.*)
You should ask BTF to use a more updated version.
Alternatively, you might want to check ng-showdown (https://github.com/showdownjs/ng-showdown) the official angular integration for showdown.

showdown does not exclude iframes. You can see an example here:
http://showdownjs.github.io/demo/#/<iframe src%3D"http%3A%2F%2Fwww.w3schools.com">
What version are you using?

It doesn't work anymore, any idea?


update LTWA to the 14/09/2017 version

ie: words "beiešk-" is in this new version of LTWA
source: http://www.issn.org/services/online-services/access-to-the-ltwa/

Thanks for noticing! It should be fixed now.
For anyone interested, the process of getting the updated list was amusing – the website has an outdated .csv and even more outdated .pdf (of course!), so I tried scraping the html pages. Somehow after a few pages it starts throttling and serving one page (out of ~8500) per 2 seconds, and eventually it just disconnects. Even more weirdly, when I tried scraping from two different networks, one of them quickly got all pages that the other already had, and then they continued synchronously, throttled, eventually disconnecting. So there's some sort of caching, but given that each page has like <<1kb I can only imagine a poor guy switching floppy disks in the background. Hopeless.
The webpage is a mess, but I asked my brother and he quickly found some WordPress insecurities that allowed him to find the updated LTWA .csv hidden but public in a category named "(réservé à l’admin)". Phew!


Trying out https://github.com/gfx-rs/wgpu/pull/3780 directly

What
Running this locally I get:
  > "wasm-bindgen" "/Users/emilk/code/rerun/rerun/target_wasm/wasm32-unknown-unknown/debug/re_viewer.wasm" "--out-dir" "/Users/emilk/code/rerun/rerun/web_viewer" "--out-name" "re_viewer_debug" "--no-modules" "--no-typescript" "--debug"
  error: cannot import from modules (`env`) with `--no-modules`
  thread 'main' panicked at 'Failed to run wasm-bindgen', crates/re_build_web_viewer/src/lib.rs:128:5
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I wonder if the CI gets the same
Checklist

[x] I have read and agree to Contributor Guide and the Code of Conduct

PR Build Summary: {{ pr-build-summary }}

Repros here as well. This issue seems similar https://github.com/rustwasm/wasm-bindgen/issues/2160


Example lighting-app fix for ESP32 without display

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Inconsistencies between (-1.0) and (-. x)

It's a bit annoying to have that inconsistency between float literals with unary minus (-1.0) and float unary minus (-. x).
Would it be possible to achieve consistency by allow (- x) to work on float and int? It wouldn't cast, it would just take the type of the expression.
It not, could we make (-. 1.0) at least parse?

- x won't happen until modular implicits as I understand it

For what it's worth, the fact that (-1.0) works at all is due to how the raw code is parsed.  (-1.0) is parsed as a negative floating point literal.  (-x) is parsed as "prefix negation applied to x".

Yeah won't be possible within the syntax transform, sorry =/


Complete build logic for native-image

With #4 we have implemented the complex workflows for building the native images.
However, this does not yet work properly so some last rework is needed.
The native-images do not arrive here:
https://s01.oss.sonatype.org/content/repositories/snapshots/com/devonfw/tools/IDEasy/ide-cli/2024.01.001-SNAPSHOT/
PR #62 did not fix the problem.
IMHO there are different profiles but those attaching the native image artifacts are not activated in the nightly build.
Please check my review suggestions where I already gave:
https://github.com/devonfw/IDEasy/pull/2#discussion_r1329812445

Still failing:
[ERROR] Failed to execute goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13:deploy (injected-nexus-deploy) on project ide-cli: Failed to install artifact com.devonfw.tools.IDEasy:ide-cli:tar.gz:linux:2024.01.001-SNAPSHOT: /home/runner/work/IDEasy/IDEasy/cli/ide-cli-linux-x64 (No such file or directory) -> [Help 1]

I was able to download the windows package with the ide.exe. I could extract it normally with 7-Zip and also I can run the binary (e.g. print the help). Some things do not seem to work in the native image, but that is a different story so I will close this issue now.
p.s.: When I have investigated things that work in JVM mode but do not work in native-image, I will create individual bug issues for that.


Godot crashed leaving severe screen burn on my monitor wile using TileMap

Godot version
4.1.1.stable.official
System information
macOS 13.5.1 Apple M1 Pro
Issue description
While using the TileSet and TileMap windows, The TileMap stopped working (could not add tiles to 2D scene, the whole program started to flicker but was still responsive. The flickering was stopping/starting depending on how I zoomed in the scene or in the TileMap.
My whole computed started to be unresponsive. Had to force-restart.
I immediately saw my monitor had godot burnt into it.
The burn dissipated after a few minutes (15/20), and tweaking my monitor settings to try to make it refresh pixels.
Monitor is an LG 38GL950G, set at 3840x1600, 85Hz, no HDR.
I am afraid to open my project on this monitor now, and will not try to reproduce as it obviously harms the monitor somehow.
I can share the tileset png I used if necessary, but not publicly.

Steps to reproduce

Import art of tileset, from this specific pack: https://rafaelmatos.itch.io/epic-rpg-world-pack-ancient-ruins
Create a TileMap
Create a TileSet
Set Tile Size to 32x32
Import TileSet from png res://art/EPIC RPG World Pack - Ancient Ruins V 1.9/Tilesets/flooded grass- grass variation1.png
Zoom in/out in the TileSet, TileMap and 2D Scene windows... Try to add some tiles to the scene...

Minimal reproduction project
N/A

This is temporary image retention, which certain LCD monitors are prone to when displaying specific patterns (such as a 2×2 repeating checkerboard at 100% scale or black frame insertion with a 1-1 duty cycle for long enough periods of time).
We need someone to reproduce this and take a screenshot (not a picture of the screen) when it occurs.

Thanks for the insights. It's the first time ever this happens to me (started using Godot only ~7 days ago).
I will try to reproduce, to take a screenshot, but I can already tell you there was nothing unusual, the whole screen looked normal except it was kind of flickering (like if brightness was changing often).
The burnt areas where on the edge of the screen, for example the top-left macos menu you can see in my screen picture, so this is not an area where was displayed a specific pattern, as it was completely outside of Godot's window. I feel like the issue affected the whole monitor's interaction with the OS somehow.

@Calinou would it make sense to get a renderdoc capture?

@Calinou would it make sense to get a renderdoc capture?

RenderDoc captures aren't compatible across GPUs, so there would be no way for me to replay them.

Could this be a faulty controller found a similar model with the same issue?
https://www.reddit.com/r/ultrawidemasterrace/comments/ukyw4y/lg_38gn950b_image_retention_burn_in/


[dynamic-dns]: Requires TTL value but box not shown

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
[x] I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
[x] I have searched the existing issues and I'm convinced that mine is new.
[x] The title contains the plugin to which this issue belongs
Describe the bug
When trying to create a new Dynamic DNS for Namecheap I am told that 'Following input errors were detected': 'The TTL value needs to be a valid integer number.' However, the field does not appear. I do not think that it is required since my Namecheap account shows that it accepts Automatic (as well as 1, 5, 20, 30, 60 minutes).
To Reproduce
Steps to reproduce the behavior:

Go to 'Services > Dynamic DNS'
Click on '+ Add'
Fill in the form.
A. Choose Service type: Namecheap
B. Interface: WAN
C. Hostname
D. Password
Click Save

Expected behavior
The entry should be saved OR a TTL box should be displayed to enter a value.
Screenshots

Additional context
I was able to workaround the problem by removing the display:none from the html.
New to Opnsense and this was the first time I was setting this up so I do not know when it was introduced.
This affects more than just Namecheap.
Environment
OPNsense 20.1.8-amd64 on Fitlet2
Intel(R) Celeron(R) CPU J3455 @ 1.50GHz (4 cores)
Intel i211

Duplicate of #1903 -- pushing a fix to 20.1.8 shortly, but since 20.1.8 was wrapped up before this was included we have to sit the situation out a bit.


UI components - Form elements: Date time not filled at the beginning

Should be fixed in Framework7 V3, if not, please open new issue.


[feature request] Execution Drivers and Standardized Agent Interface

Currently the way to train an agent is to 1) Instantiate the environment, 2) Instantiate the agent, passing the environment in constructor and 3) calling the learn method.
Some agent frameworks have started implementing execution drivers, i.e., objects responsible for interacting the agent with the environment.
Would love to see such a feature in stable-baselines, given that it would facilitate a lot the pipeline for testing a new agent and comparing it with existing ones.
Current code:
env = gym.make("CartPole-v0")
agent = DQN(env, ...)
agent.learn(...)
What if there were driver objects such that the execution would go something like this:
driver = BottleneckDriver(max_timesteps=10000, max_episodes=200)
metrics = [TotalTimesteps(), AverageTimestepReward(), AverageEpisodeReward(), ...]
driver.run(agent, env, metrics)
for metric in metric:
      print(f"{metric.name}: {metric.result()}")

Example

class Driver(BaseDriver):
    """
      Runs until one of the conditions is met - max_timesteps or episodes
    """
    def __init__(self, agent, environment, max_timesteps=math.inf, max_episodes=math.inf, observers=None):
        super(BottleneckRunner, self).__init__(agent, environment, observers)
        self._timesteps = max_timesteps
        self._episodes = max_episodes

    def run(self):
        self._environment.reset()
        done = False
        while not done:
            self.step()
            done = self.total_episodes >= self._episodes or self.total_steps >= self._timesteps

And a base class:

Timestep = namedtuple("Timestep", "t state action reward next_state is_terminal info")

class BaseDriver(ABC):

    def __init__(self, agent, environment, observers):
        """
        :param agent: The agent to interact with the environment
        :param environment: The environment
        :param observers: The observers
        """
        self._agent = agent
        self._environment = environment
        self._observers = observers or []

        self._total_steps = 0
        self._total_episodes = 0

    @property
    def total_steps(self):
        return self._total_steps

    @property
    def total_episodes(self):
        return self._total_episodes

    @abstractmethod
    def run(self):
        raise NotImplementedError()

    def step(self):
        state = self._environment.state
        action = self._agent.action(state)
        timestep = self._environment.step(action)
        for observer in self._observers:
            observer(timestep)
            self._agent.reinforcement(timestep)
        self._total_steps += 1
        is_terminal = timestep.is_terminal
        if is_terminal:
            self._total_episodes += 1
        return timestep

    def episode(self):
        self._environment.reset()
        is_terminal = False
        trajectory = [self._environment.state]
        while not is_terminal:
            timestep = self.step()
            trajectory.append(timestep)
        return trajectory

Would love to contribute with such features.
Let me know what you think.

Closing this issue in favor of this one: https://github.com/hill-a/stable-baselines/issues/381


Configuration of placeholder only works with online image

Your proposed code for configuring the placeholder only works with an online source. If I use a local file I always get a route error. I'm not a rails pro by far... So tell me if I'm wrong :)

Hello everyone, I know that the issue dates a little but I had the same problem recently. So I am not an expert on RoR but I noticed that once the assets are compiled they are not separated in different development folder (images, stylesheets, javascripts and others). So in the config/initializers/lazyload.rb file the configuration for a static file looks like this:
the gif I use as a custom file is named lazyloader.gif
Lazyload::Rails.configure do |config|
  config.placeholder = '/assets/lazyloader.gif'
end

I hope it will serve to solve future issues.


Upgrade to Quill 2.0

Clear and concise description of the problem
Hi, I'm the maintainer of Quill. Thanks for making such a great Vue binding for Quill.
We are currently actively maintaining Quill 2.0 and anticipate releasing the stable version soon. Website is at https://v2.quilljs.com/. I thought it'd be great if this project can be upgraded to use Quill 2.0.
Suggested solution
Here's a guide for migrating Quill to 2: https://v2.quilljs.com/guides/upgrading-to-2-0. Feel free to let me know if you encounter any issues!
Alternative
No response
Additional context
No response
Validations

[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

@surmon-china Any plan to support quill 2.0? As it has close to being released now.

As alternative solution, I propose to use this library:
https://github.com/alekswebnet/vue-quilly
It provides a tiny component with HTML data model support that helps to build editors on top of Vue 3 and Quill 2


z is not working

./z.sh: 206: ./z.sh: Syntax error: "(" unexpected (expecting "}")

I'm using zsh and master of this repo.

I didn't create ~/.z file or anything like this, at least by hand (and I don't see it with ls -la). I have freshly installed ubuntu 12.04 alpha2, zsh, oh-my-zsh and now I'm trying to install z that I like a lot (thanks for it!).

I don't use zsh or oh-my-zsh so it's tough for me to figure out the issue. I'm not even completely sure whether the oh-my-zsh plugin is pulling from my repo, or from a fork. And it is possible I may have screwed up the quoting in that line, even though it does look right to me:
reply=(${(f)"$(_z --complete "$compl")"})
I wonder if @matthewmccullough or @sjl have any ideas?

I should sorry. I've reinstalled my system from scratch some time ago and forgot that around a year ago I've used this https://github.com/sjl/z-zsh fork to install z in my zsh. Of course it would be awesome to be able to run your original z in zsh, but it's not a bug in a strict sense.

@si14 I'm pretty sure this repo works fine with ZSH now.  I should probably mark my old port as deprecated.


Crowdstrike rules and workbook seem to not relate to the Crowdstrike solution

The  Crowdstrike solution  includes an azure function based connector and the parser function for it function called CrowdstrikeReplicator. The analytic rules and workbook included in the solution seem to require a function called CrowdStrikeFalconEventStream which is associated with the older parser based on CEF

@oshezaf , Moved CrowdStrikeFalconEventStream  parser to solution folder . https://github.com/Azure/Azure-Sentinel/pull/2735
This parser is part of CrowdStrike Falcon Endpoint Protection Solution which is already published.

As parser has moved to solution folder, closing the issue.


[Performance degradation] console log warning message on strike_lookup component

Have anyone have a workaround for the performance degradation warning for strike_lookups.
[Performance degradation] markup://aura:if ["158:208;a"] in c:strike_lookup ["148:208;a"] needed to clear unrendered body.
More info: https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/perf_warnings_if.htm
Component hierarchy:

@karthikkornalies when do you get this error? trying to reproduce this

Above warning occurs during the component load.  Any thoughts/workaround to fix it.

Has this been already fixed on the recent release?

@karthikkornalies I am unable to reproduce this error in any instance, if you are not on the latest version of strike of recommend you update your components. If you are still having trouble feel free to attach a screenshot or further explain the steps to produce the error.

I have the same.


Pin rotation

Hello,
when I have pin icon where it matters a rotation, could I rotate with pin like in native?
Or it is only option to rotate with image before putting to map?
Also it must be re-rendered after tilt.
https://developers.google.com/maps/documentation/android-api/marker

Thanks, I will add plan it. 👍

ref #PR102

I deployed 1.7.0-beta4 that includes this.
Please check it.


Context does not exist error during OIDC Federated Logout

Describe the issue:
The following error occurs while trying out the OIDC federated logout flow.
ERROR {org.wso2.carbon.identity.application.authentication.framework.handler.request.impl.DefaultRequestCoordinator} - Context does not exist. Probably due to invalidated cache. Requested client: <IP_ADDRESS>, URI :GET:/commonauth, User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0 , Referer: https://localhost:9443/ WARN {org.wso2.carbon.identity.application.authentication.framework.handler.request.impl.DefaultRequestCoordinator} - Authentication context is null, redirect parameter filtering will not be done for null
How to reproduce:
Setup OIDC federated authentication with two Identity Server Instances. [1][2]
Register a service provider(pickup-dispatch) and enable federated authentication.
Initiate the federated authentication flow by logging in via client application.
After logging in upon successful authentication, click on logout.
Notes:
Trying the authentication flow with federated authentication
Upon clicking on logout via the client application, the federated logout request; https://localhost:9444/oidc/logout, will have the id_token_hint, state and post_logout_redirect_uri as the parameters.
Then, the application registered in the second server (idp running on port 9444) will redirect to its registered callback URL (https://localhost:9443/commonauth).
Here, the state parameter sent in the federated logout request does not get appended to the callback URL redirect of the idp, causing the error.
However, if we append the state parameter in the federated logout request to the callback URL redirect and manually send the request in the browser, (https://localhost:9443/commonauth?state=xxxxx) the logout flow would complete successfully without any errors.
Trying the authentication flow with default authentication
The issue with the federated logout scenario was, state parameter not being added to the callback URL in the redirect. In that case, the SP callback URL in the IDP did not get appended with the state parameter sent in the logout request. Hence, the authentication flow was carried out without federated authentication to test whether this issue persists in the default authentication flow as well. There, if we initiate a logout request manually with a state parameter added to the logout request, the state parameter was appended to the callback URL in the redirect, and the logout completed successfully.
Environment information :

Product Version: IS 5.10.0/5.11.0-alpha2

[1] - https://is.docs.wso2.com/en/latest/learn/configuring-oauth2-openid-connect/
[2] - https://medium.com/@methmas/federated-authentication-with-wso2-identity-server-with-openid-protocol-and-wso2-playground2-app-212151d66f7a

@Yasasr1 will look into this.

This issue is due to the same host name in both Identity Servers. As cookies are set for the domain, both localhost:9443 and localhost:9444 will have the same commonAuthId cookie. During the logout 9443 will remove the commonAuthId cookie and 9444 won't have the commonAuthId cookie.
We can avoid this error by using a different host name for federated identity server.

The issue persists in scenarios where a federated idp is configured in different tenant of the same server. There, the different tenants will share the same domain and hence, will have the same commonAuthId cookie.

I using different server but facing the issue. Is there any other solution for the problem?

The issue persists in scenarios where a federated idp is configured in different tenant of the same server. There, the different tenants will share the same domain and hence, will have the same commonAuthId cookie.

Can we reverse proxy the requests send for that tenant which holds the federated IDP and treat that as a separate domain.

Tried to reproduce the error in WSO2 Identity Server 6.2.0 Alpha3. But the OIDC Federated logout flow was successfully completed. Refer the following screen recording.
https://github.com/wso2/product-is/assets/74205483/017ac8a0-747b-44b2-a148-f21f9a33ddd4
I have checked this issue with IS Alpha-4 (Upcoming Release - Current changes) as well. In that case also, the OIDC Federated logout flow was successfully completed.


add swift

add the swift toolchain to the joshua-agent image

How large is the Swift toolchain that's included in the agant image?
I'm OK with this change, but in the long term, we'd better come up with a better way of managing external tools that are independent from the Joshua framework itself.

As for installation method this is a bit ugly right now since Swift 5.9 which we depend on has not been released stable yet. Once it has, we'll be able to work on may be offering a package to install directly, or other streamlined methods (we have swiftly, a swift version manager/downloader as well). It would be also worth considering upgrading from CentOS7 eventually since it's EOL status 🤔 But we can definitely work on a better installation path, adding what's necessary in the official Swift repos etc 👍 Happy to revisit this once 5.9 is stable!
Hmmm, a "whole" slim docker image is 300mb or so, but that's the whole image. I've not measured how much exactly the minimal runtime bits are, we can check if necessary though the container already seems to have a lot of stuff there heh :)


fixes #2474 bash completion: possible retry loop

I opened #2474 more than a year ago and came to the conclusion that it was more bash-completion's fault than fzf's. However, it does not appear it's an easy fix in bash-completion, and it's a fairly easy fix in fzf. It also appears other people are running into it (ex: #2583) - I, myself, just ran into it again on a new machine - so maybe we should just fix it?
Open to other suggestions. This PR is my proposal from the ticket long ago =)

Merged, thanks!


FieldLogger inconsistency

Is there a reason part of FieldLogger interface methods return a concrete Entry instead of the interface?
The problem is that this precludes embedding existing FieldLogger while being able to reimplement (full) FieldLogger interface.

The interface matches the WithField methods of Logger and Entry otherwise they wouldn't implements this interface.
I suspect this interface has been added after the implementation of the former struct which couldn't be changed without a major interface change.

Yes, so it looks as if the PR that introduced the FieldLogger interface would've also updated the signatures of those methods, there would be no issue :-(

I'll tag this issue as 2.0 target as we can not change that without making a breaking interface change.

I second this issue.
I've run into this problem trying to implement a composite logger, returning Entry makes it impossible to fully implement this interface.

Also, FiledEntry interface lacks of methods Trace..., despite the fact that both Logger and Entry implement these methods.

There is also https://godoc.org/github.com/sirupsen/logrus#Ext1FieldLogger. Adding those extra methods to the interface would have broken backwards compatibility because anything else implementing that interface would then no longer be implementing it.
PS: interfaces should be defined locally. When/if we get to a v2, I'll be pushing to not provide the v2 equivalent of the logrus.FieldLogger or logrus.Ext1FieldLogger interfaces. If users need an interface they can and should define it locally to cover the methods of logrus.Logger / logrus.Field (or their v2 equivalents) that they use.

@freeformz I believe that the interface for the entity that writes the logs is necessary.
Firstly, it frees your hands when adding new entities for logging. You can never say for sure that the entities Logger and Entry will not be supplemented by anything else in a couple of years.
Secondly, as the most important point for me, passing an interface instead of a specific type along a long chain of objects saves you from long refactoring if something changes in this chain. In my project (sorry I can’t show - it’s private) the logger is passed to 20+ entities. At the top level, I create the base logger, and pass the logger directly to the child entities, or create the Entry with additional configuration using the WithFields (fields Fields) *Entry method. Some of these loggers are passed through to the child objects. In all entities that use logging, the logger or Entry created from it is stored as the FieldLogger type, and this is very convenient: this allows me to itemize logger for child entities without paying attention to the specific logger type, i.e. it doesn't matter to me is it Logger or Entry.
I know that every user of logrus can add the interface to his/her project, but it will not be the same as adding the interface directly to the logger project. The main problem is that the interface declared in the logrus states the appearance of the entities Logger and Entry: this gives stability to the code. The interface declared in my project does not guarantee that Logger and Entry will always have the same look.
I hope I convinced you. I would be glad to see your arguments in support of removing the interface common to loggers from the logrus project.

Closing per the project being put into maintenance mode

@belyshevdenis I agree with you. there's an issue I got with the same approach. There are some places that I need to add fields to the logger. the logger itself is passed as a FieldLogger to other functions. So, how do you cast from Entry to FieldLogger in this situation?

@AienTech
entry := logrus.Entry{}
var logger logrus.FieldLogger
logger = &entry
logger.Debug("Hello from Entry method")


Wrong usage of Compressor constructor

Hi there.
Recently i've tried to generate demo instance of django-shop from cookiecutter template.
It was generated successfully. But when i've tried to up services, web application started throwing errors.
So, i've tried to research problem and if I understood correctly, usage of Compressor constructor implies to pass positional resource_kind arg.
Seems the problem was added here: https://github.com/awesto/django-shop/commit/807c7c5d1797cb6353795223927cb9dfd0c849e7#diff-59d012f061f377c7836bdb130f0a5ad4R25
Here you can see Compressor constructor, if i figured out it correct:
https://github.com/django-compressor/django-compressor/blame/2.4/compressor/base.py#L35
Seems this issue reproduced in certain cookiecutter configuration  - with uwsgi server which a was select.

Hi @elipavlov,
possible related : https://github.com/awesto/cookiecutter-django-shop/pull/21
Otherwise what is the error output ?

Thanks for reporting. Actually, this special Sekizai compressor has been introduced recently into django-compressor, so there is no need to configure it through django-shop. I will fix this in the cookiecutter template.


Add directories support for oracle

It would be nice having oracle directories support:

Create, delete, rename directories
Check  directory detail: DIRECTORY_NAME, DIRECTORY_PATH, Privilege list

https://docs.oracle.com/cd/B19306_01/server.102/b14237/statviews_1050.htm#i1576965


Opprette spdx:algorithm

#52
"Range: spdx:checksumAlgorithm_sha1 Cardinality: 1..1 This property identifies the algorithm used to
produce the subject Checksum. Currently, SHA-1 is the only supported algorithm. It is anticipated that other algorithms will be supported at a later time."

Gjelder versjon 1.1


kubernetes cluster monitoring

Following comment on my PR : https://github.com/Dynatrace/helm-charts/pull/36
I included kubernetes monitor in common stuff

Will be done within our new operator:
https://github.com/Dynatrace/dynatrace-operator
Release is planned for this year


Help with UDA1334A Breakout Board

I have this breakout board from Adafruit and I'm having a problem getting any audio out from it.
I have spent hours researching what the problem could be but have found no solution. I have tested this library with the breakout board and had no problems getting it to play audio.
Any time audio is playing through Bluetooth and outputted through the 3.5mm jack the only thing that is present is static.
I have tried to change pretty much every parameter in the i2s_config. I even went so far as copying the i2s_config from the previously mentioned library yet still no luck.
Has anyone else experience this issue? It making me go crazy!
#include "BluetoothA2DPSink.h"

BluetoothA2DPSink a2dp_sink;

void setup() {
    static const i2s_config_t i2s_config = {
         .mode = (i2s_mode_t) (I2S_MODE_MASTER | I2S_MODE_TX),
         .sample_rate = 41000,
         .bits_per_sample = I2S_BITS_PER_SAMPLE_16BIT,
         .channel_format = I2S_CHANNEL_FMT_ALL_LEFT,
         .communication_format = (i2s_comm_format_t)I2S_COMM_FORMAT_I2S_MSB,
         .intr_alloc_flags = 0, // default interrupt priority
         .dma_buf_count = 8,
         .dma_buf_len = 64,
    };

    i2s_pin_config_t my_pin_config = {
        .bck_io_num = 27,
        .ws_io_num = 26,
        .data_out_num = 25,
        .data_in_num = I2S_PIN_NO_CHANGE
    };

    a2dp_sink.set_i2s_config(i2s_config);
    a2dp_sink.set_pin_config(my_pin_config);
    a2dp_sink.start("MyMusic");

}

void loop() {
}

That's difficult. I had a similar issue with another DAC and needed to connect ground to the mute pin to make it work. But this will unlikely help, if you get sound from another library.
The most frequent issue are the pin connections but the pin assignments look right (identical with your other library)!
For the I2S config you should use
.channel_format = I2S_CHANNEL_FMT_RIGHT_LEFT,
.communication_format = (i2s_comm_format_t) (I2S_COMM_FORMAT_I2S | I2S_COMM_FORMAT_I2S_MSB),
When you connect do not forget, that the volume on your mobile phone is controlling the volume of the output, so to be sure just put it to the maximum.
You can try to compile your sketch with the setting "Core Debug Level" verbose. This might give a hint if anything in the processing goes wrong...

For the I2S config you should use
.channel_format = I2S_CHANNEL_FMT_RIGHT_LEFT,
.communication_format = (i2s_comm_format_t) (I2S_COMM_FORMAT_I2S | I2S_COMM_FORMAT_I2S_MSB),

I will retry this when I get home. If that doesn't help I will upload pictures with my connections.

@pschatzmann Just got home to test what you suggested and no luck not even with another DAC I have on hand from adafruit (it's actually a I2S DAC + Amp)

Just found the following:
For what it's worth, if the issue is that you get more noise than sound, it could be the bit order. To get my PT8211 to work, I had to change I2S_COMM_FORMAT_I2S_MSB to I2S_COMM_FORMAT_I2S_LSB, here:
I think this is worth a trial....

@pschatzmann I will try this when I get the time today. Thank you for the suggestion.

@pschatzmann YES! This works!! I had to unplug and replug the connections and it started working with the I2S_COMM_FORMAT_I2S_LSB
If anyone has this problem in the future here is my code
#include "BluetoothA2DPSink.h"

BluetoothA2DPSink a2dp_sink;

void setup() {
    static const i2s_config_t i2s_config = {
         .mode = (i2s_mode_t) (I2S_MODE_MASTER | I2S_MODE_TX),
         .sample_rate = 41000,
         .bits_per_sample = I2S_BITS_PER_SAMPLE_16BIT,
         .channel_format = I2S_CHANNEL_FMT_RIGHT_LEFT,
         .communication_format = (i2s_comm_format_t) (I2S_COMM_FORMAT_I2S | I2S_COMM_FORMAT_I2S_LSB),
         .intr_alloc_flags = 0, // default interrupt priority
         .dma_buf_count = 8,
         .dma_buf_len = 64,
         .use_apll = false
    };

    i2s_pin_config_t my_pin_config = {
        .bck_io_num = 27,
        .ws_io_num = 26,
        .data_out_num = 25,
        .data_in_num = I2S_PIN_NO_CHANGE
    };

    a2dp_sink.set_i2s_config(i2s_config);
    a2dp_sink.set_pin_config(my_pin_config);
    a2dp_sink.start("MyMusic");

}

void loop() {
}


🐛 macOS: getHue needs colour space

Describe the bug
There is an error when compiling on macOS:
*** -getHue:saturation:brightness:alpha: not valid for the NSColor Catalog color: #$customDynamic AE0C4EC2-C8A0-4DCE-A908-7BF8E85ADE16; need to first convert colorspace.
This is in the internal func uiColorComponents() -> (hue: CGFloat, saturation: CGFloat, lightness: CGFloat) { ... } function.

Closed with #5


Fix contents parsing of messages

Fixes: https://github.com/microsoft/FluidFramework/issues/3804
The contents maybe jsonified. So check that and parse before doing any operation on it.

Is this path just not used in regular document flow?  All the recent docs I pulled with the fetch-tool have the stringified json contents, so it seems weird that this is only an issue for fetch-tool (and if only fetch-tool uses it, it should probably be refactored I guess)

It feels like this is an issue in fetch tool only, and should be addressed there, not here.
Can you please provide a bit more info if you believe this is the right place for a fix?

If this change is really needed, then many things would have been broken.   I think something else is happening here. I'd like to understand why we encounter this problem in the fetch tool and not other places first.

Yes, I thought the same but it is ODSP antiques. In normal flow, the messages that we receive on top of snapshot are ISeqDocMessages where this is always object type and therefore we never face this problem. For fetch tool, the messages are fetched through deltastorage, they are op type ISequencedDeltaOpMessage in which these contents are of type string(they are jsonified). So we only get this problem in fetch tool.

So my understanding is this could happen in prod as well?

yes. It is just that it never happens currently. But if it will this path, then yes.

@jatgarg, it feels like (based on your description) that we should rather fix delta storage pipeline to always return ops in same format.

No, that returns ops in same format: ISequencedDocumentMessage. The ops returned by server when made a get request are of type: ISequencedDeltaOpMessage. In that format the contents are stingified. We are not going to change the inner contents of each message. So this change seems the correct change.

It still does not compute to me :)
It's same ISequencedDocumentMessage in both places, no?
export interface ISequencedDeltaOpMessage {
    op: api.ISequencedDocumentMessage;
    sequenceNumber: number;
}

And only ISequencedDocumentMessage is exposed from SPO driver, ISequencedDeltaOpMessage is internal implementation of the driver.
In existing shipping product (using SPO), ops come from 3 sources:

delta storage (we catch up that way after tab was not active or computer was offline)
delta connection (executed all the time)
TreesLatest (exposed through delta storage API, also executed all the time).

All 3 return same format - the product works today as is!
So leaving fetch tool for a second, where do you see stringified content today?
BTW, this needs to be addressed - we should be strict and allow only one type on the wire:
export interface IDeltaStorageGetResponse {
value: api.ISequencedDocumentMessage[] | ISequencedDeltaOpMessage[];
}

I was wrong. With some more debugging, I found that the parsing of message contents was happening in delta manager and so that is why we were not hitting this in normal flow. For fetch tool, when we analyze fetched messages for stats etc, we use unpackRuntimeMessage which check the contents but we don't go through delta manager path because we are just analyzing the messages and that is why we skip the parsing of contents. So now I have added the same check in fetch tool to parse the contents before analyzing them.

Super! Should we move this logic from delta manager into driver? That way other tools / workflows would not need to know about that specific.

Super! Should we move this logic from delta manager into driver? That way other tools / workflows would not need to know about that specific.

I think no. Reasons:
1.) Delta manager is one stringifying the contents so it should have this responsibility too.
2.) In driver ops can come through many sources(Trees latest, delta storage, socket, initial messages), so needs to be added at multiple places while in delta manager it should be added at one place.
3.) In driver too, it should then be added to different drivers. So I guess in tools too it does not need to be added to all of them like it need to be added in this one just because it was a special case(where were using an exported independent api which required the input in a certain way).


[CSL-1957] Merge feature branch alfredo/wallet-new into master

@gromakovsky Apologies for another humongous PR, I think I have learnt the lesson that squashed merges and feature branches do not go along well. I have tried to cherry pick the commits which was produced after https://github.com/input-output-hk/cardano-sl/pull/1918, but I've got into painful conflict-resolution due to the refactoring which happened in core lately, so the path of least resistance seems to simply re-do the merging, this time the classic way, so that next merges are much, much smaller. Apologies 😞
EDIT: ah, looks like that luckly despite all the commits are still shown (due to the wrong merging stategy) at least the diff looks all-right, "just" 1646 SLOC 😉
It's still backward-compatible code, so reviewing it can be skipped or done very lightly.

@adinapoli-iohk

I see that you created https://iohk.myjetbrains.com/youtrack/issue/CSL-1957 for this merge. Thank you for doing that, I appreciate it, it's an essential part of our workflow. Can you please also update this PR's title and put [CSL-1957] there (and do it for all other PRs corresponding to issues)? Otherwise it's almost impossible to associate PRs and issues.
There is a cabal warning when I build wallet-new:

Warning: The following modules should be added to exposed-modules or other-modules in /home/gromak/Work/cardano-sl/wallet-new/cardano-sl-wallet-new.cabal:
    - In wallet-new-specs component:
        Cardano.Wallet.API.V1.Handlers.Info
        Cardano.Wallet.API.V1.Handlers.Settings

Can you fix them please? I am tolerant to code style in wallet-new, but I want all warnings to be fixed, because all devs need to build wallet-new to check they didn't break it and nobody wants to see warnings.
Apart from that looks good to me, almost no changes outside wallet-new, which is a good sign 😉

Thanks @gromakovsky , all excellent points, let me address those 😉

@gromakovsky This PR and this feature branch become bloated. I have decided to keep using this open PR as a guinea pig to get at the bottom of the CI failure, at which point I will close it and reopen a new PR where I will branch off from this one but will squash all the commits in a nice & clean commit labeled [CSL-1957] Merge wallet-new (Dec 2017).
Apologies for the mess!

Ok, CI finally passes on Win, so going to close and reopen.


Package request: doasedit

An equivalent to sudoedit for opendoas

Metadata

homepage URL: https://codeberg.org/TotallyLeGIT/doasedit
source URL: https://codeberg.org/TotallyLeGIT/doasedit
license: https://codeberg.org/TotallyLeGIT/doasedit/src/branch/main/LICENSE
platforms: linux

Add a :+1: reaction to issues you find important.

I have found a hacky workaround
alias snv='doas nvim -u $HOME/.config/nvim/doasinit.vim'
colorscheme lunaperche
source /home/$DOAS_USER/.config/nvim/modules/init.vimrc
source /home/$DOAS_USER/.config/nvim/modules/general.vimrc
source /home/$DOAS_USER/.config/nvim/modules/plugs.vimrc
source /home/$DOAS_USER/.config/nvim/modules/keys.vimrc

is my current config for working around this
My config is modular so it normally looks like this
colorscheme 256_noir
source ~/.config/nvim/modules/init.vimrc
source ~/.config/nvim/modules/general.vimrc
source ~/.config/nvim/modules/plugs.vimrc
source ~/.config/nvim/modules/keys.vimrc

Decent workaround, doesn't prevent the potential security issues from vim though, so, this should still be packaged.


[Errno 10054] An existing connection was forcibly closed by the remote host

RouterOS Version: 6.36.1 (stable)
Command line: python WinboxExploit.py <IP_ADDRESS>
Winbox works perfectly fine, discovering (among others) a neighbor at <IP_ADDRESS>. I can then attempt to log in with invalid credentials via its MAC address, which fails with the expected ERROR: wrong username or password.
When run, the script produces the following output:
Connection error: [Errno 10054] An existing connection was forcibly closed by the remote host
I expect that this is an issue with my configuration and not the script, but I appreciate the help.

Sounds like you might have some whitelisting on your Winbox service. Or possibly a firewall blocking you.
I don't think I have a test setup for this anymore, so I can't really test it.

That's understandable. I'll keep working with it and see what I come up with.


Add arrays for function parameters

for https://github.com/microsoft/pxt-microbit/issues/2205

Arrays just compile as type 'any[]' for now. It would be good to tighten this based on what the array is used for in the function in the future.

here's what it looks like!

Dependent on this blockly PR:
https://github.com/microsoft/pxt-blockly/pull/348
Try it with Arcade:
https://arcade.makecode.com/app/7cfe7f9222aeed78a5a9221974e8eaa15ae2c507-760d72a43e
and microbit!
https://makecode.microbit.org/app/deaaf58563e4bd915647f70815133cb33662675a-985bb5d9b4

LGTM, but please add some tests https://github.com/microsoft/pxt/tree/master/tests/blocklycompiler-test


Add --project and -p command line option

Currently we use "strict": true but have "strictNullChecks": false. When we run yarn tsc-strict we get 🎉  All files passed.
{
 "compilerOptions": {
   ...
   "strict": true,
   "strictNullChecks": false,
   "plugins": [
    {
     "name": "typescript-strict-plugin"
    }
   ]
 }
}

I am not sure how the plugin should work but I thought it would ignore the strictNullChecks and make it true.
I would like to keep the tsconfig.json as is and not remove "strictNullChecks": false so it can work with our current workflow. Can you allow tsc-strict to take the --project and -p command line options so we can point to another file (tsc-strict -p tsconfig-strict.json)?

I ended up renaming tsconfig.json to tsconfig-base.json and made tsconfig.json look like:
{
  "extends": "./tsconfig-base.json",
  "compilerOptions": {
    "strict": true,
    "strictNullChecks": true,
    "plugins": [
      {
        "name": "typescript-strict-plugin",
        "paths": ["./src/stores/", "./src/utils/"]
      }
    ]
  }
}

I think this works better because now my IDE displays the stricter warnings/errors but our build process can use the less strict version.
Maybe there should be a way to tell tsc-strict to override strictNullChecks or one of the other option(s) that is combined under the strict option? Then I wouldn't have to do the tsconfig extend thing.

I guess my team is not liking all the strict null warnings in the IDE. Maybe allowing tsc-strict to accept the --project and -p command line options is not a bad idea. Then I can slowly clean up the null warnings without the team seeing them.

To be honest we could actually pass all the arguments that typescript supports to the tsc not only --project. Right now we only pass --strict --noEmit but adding support to pass --project and the rest would be nice feature. I'll try to add this over the weekend. Thanks for the idea


Missleading error message for .get_object()

The code:
let glade_src = include_str!("gui.glade");
let builder = Builder::new_from_string(glade_src);
//...
let button1: gtk::Button = builder.get_object("button_toggle").unwrap();

If "button_toggle" is another kind of button (a ToggleButton instead of a Button), it crashes at runtime with: thread 'main' panicked at 'called 'Option::unwrap()' on a 'None' value. I would have expected a mismachted types error, because the "button_toggle" is defined in gui.glade.
This holds also for other kinds of Buttons.

As ToggleButton is also Button this error IMHO unrelated to mismatched types.
Can you show gui.glade?

Sorry, I made a mistake in the issue description. It is the other way round: I wanted to associate a Button to a ToggleButton. I already updated my issue. Please have a look.
Also, here is the glade file: https://gist.github.com/Ronaldho80/de0ca3e3e315d8effc39eb16f71eaba9

Currently get_object return Option and it don't contains error info as it unneeded in most cases ("don't found" not different from "unconvertable type")
    pub fn get_object<T: IsA<Object>>(&self, name: &str) -> Option<T> {
        unsafe {
            Option::<Object>::from_glib_none(
                ffi::gtk_builder_get_object(self.to_glib_none().0, name.to_glib_none().0))
                .and_then(|obj| obj.downcast().ok())
        }
}

If you really need react to typecast error, it simpler do it manually by getting gtk::Object first and downcasting it after.

Thanks for the hint.
My point of this issue is that "not found" and "unconvertable type" made quite a difference to me, because I could not solve the problem for quite a while. I was always wondering why it gave me a "not found" error although it is there.
I am a beginner with gtk-rs and I know that this lib is in its development. I was even wondering, if it is just now working.
I don't argue that this issue is a big thing. However, I think that a verbose and correct error message is really helpful. In particular, I am used to precise and verbose error messages from Rust.

Problem that error produced by not gtk's get_object but your .unwrap(), so we nothing can do about it :wink:

Ok, I see. It's a pity.
Anyway, thanks for your help and for gtk-rs!


New condition

limited zinc followed by zinc shock
def as for limited zinc + sudden exposure to zinc
PMID:29529046

I added
id: PECO:0000345
name: zinc starvation followed by zinc shock


add utility_update_version script

this PR includes:

new release_version.txt file that contains the new release version (if being updated)
in dev_tools: utility_update_version.ps1 that will use the release_version.txt to replace all occurrences of old version numbers in readme and script files with the new release version given

migrating over to internal repo before adding here


22 publish package on pypi

Hi all, is this the right approach to have the topobank plugin published on pypi.org?

Thanks!


Provide a netbsd way of finding executable path

It seems silly that it is incompatible with the freebsd one, but I think that sysctl exists for more things and it's just one of the options it can returns.

We don't support NetBSD at this time. Are you working on NetBSD port @coypoop? If not, then adding NetBSD specific defines is something I'm wary of doing. If you are, then I think a change like this would make the most sense as part of a larger NetBSD PR.

I am

Cool.
My preference would be to have 1 larger PR to support NetBSD. Are you ok with that? You could do the changes as a series of individual commits but open a single PR for them all that we could decide to squash if we wanted.
Question re: the port. Would you be willing the be the maintainer for the NetBSD port and update it as needed to keep bit-rot from setting in? We don't have an NetBSD CI available so that's a fairly high-concern on my part.
I did the Dragonfly port and haven't had time to maintain it and I'm going to end up removing the Dragonfly support as it's effectively unsupported. I wouldn't want to see the same thing happen to the NetBSD work you end up doing.

sure


added 404 page and route

Added the 404 page, still needs styling, @martijn9612 will take care of that

Looks good.

Looks good, nothing to comment. Tests fail though, fix that and we'll merge.


Unable to Parse Package Input When Running kurtosis run Command

System information
macOS Sequoia 15.1.1 - M2 chip (ARM64)
Commit id
d
Description & steps to reproduce
Issue: Unable to Parse Package Input While Running Kurtosis Command
I'm encountering an error when running the kurtosis run command with my Starlark script. Specifically, I get the following error message when attempting to import modules using import_module in the Starlark code:
Error Message:

There was an error interpreting Starlark code
Unable to parse package input '"constants = import_module("./src/package_io/constants.star") dict = import_module("./src/package_io/dict.star")"' into a dictionary. JSON other than dictionaries aren't support right now.
Error encountered running Starlark code.

Command Run:
kurtosis run --enclave cdk-v1 --args-file input_parser.star --image-download always .

Code in input_parser.star:
constants = import_module("./src/package_io/constants.star")
dict = import_module("./src/package_io/dict.star")

Desired behavior
I expect the command to execute successfully and the modules to be imported correctly, allowing me to use their contents within the Starlark script.
What is the severity of this bug?
Painful; This is causing significant friction in my workflow.

I'm getting the following error while executing this command "kurtosis run --enclave cdk ."


sign language view

Your implementation of the SignLanguageView is well-structured, and the integration of the Python script runner is a great addition for real-time recognition. The UI layout is intuitive,I appreciate how you preemptively included placeholders and action bindings for the Text-to-Speech modules—it made integrating my functionality seamless. Just a small note: remember to add Javadoc comments for the class and key methods to improve maintainability and clarity. Thank you for making the process so convenient!

Great view, button for setting can be added for the setting view


Fix #12 (Scroll in docs flooding browser history)

See #12 for context.
Please note, I'm not able to test the proposed change

Thanks, that's seem to do the trick.


feat(input): clear button

TASK: #887
Description, Motivation and Context
This PR add the clear button:

It’s optional
Not focusable with the tab key
When is clicked besides removing the value of the input it focus it
It’s displayed automatically when the value of the input is not empty
Custom click handlers to the button could be added
When the input is focused and escape key is pressed the value of the input is removed
Accessible name could be set by consumers

https://github.com/adevinta/spark/assets/6877967/c6983195-6710-4bc1-bfca-4df89b8a788c
Types of changes

[x] ✨ New feature (non-breaking change which adds functionality)
[x] 🧾 Documentation
[x] 🧪 Test
[x] 🧠 Refactor
[x] 💄 Styles

Maybe not for this PR, but the border-radius is not ok in Chrome for iPhone

Maybe not for this PR, but the border-radius is not ok in Chrome for iPhone

Thanks @turolopezsanabria I already opened a PR to fix it #1026

I think there is too much space

if the  gets a type="srearch" attr, what is the behavior given? Could we set it and hide the native clear icon?

I think there is too much space

It's because of the "safety area" but we still need to check the spacing with the design team

if the gets a type="srearch" attr, what is the behavior given? Could we set it and hide the native clear icon when including it as a prop or detecting the ClearButton inside ?

Yes! you are right. We need to hide it. We can do it in another PR

I dnt know why we are using the  with that space. I think we agree this should be fully clickable last wednesday. Can you please confirm if i'm wrong?

Sorry for being late: Yes it's correct @andresin87, the area should be fully clickable

I don't know why we are using that space. I think we agree this should be fully clickable last Wednesday. Can you please confirm if I'm wrong?


fix redis listall

Codecov Report

Merging #1889 (94afbdc) into main (0c69891) will increase coverage by 0.04%.
The diff coverage is 57.14%.

@@            Coverage Diff             @@
##             main    #1889      +/-   ##
==========================================
+ Coverage   61.29%   61.34%   +0.04%
==========================================
  Files         135      135
  Lines       23411    23415       +4
==========================================
+ Hits        14349    14363      +14
+ Misses       7389     7380       -9
+ Partials     1673     1672       -1

Impacted Files
Coverage Δ

pkg/object/redis.go
70.93% <57.14%> (-2.25%)
:arrow_down:

pkg/meta/sql.go
64.34% <0.00%> (-0.20%)
:arrow_down:

pkg/vfs/reader.go
80.29% <0.00%> (+3.10%)
:arrow_up:

Continue to review full report at Codecov.

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


Basic status certificate ctl command

What this PR does / why we need it:
This PR adds a new command status and subcommand status certificate that outputs the basic details of the current status of a Certificate resource.
The plan is to output more information about about related resources such as the CertificateRequest as well, which will be done in a seaparate PR.
This will be helpful for troubleshooting a Certificate.
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
Special notes for your reviewer:
Release note:

Add new ctl command that outputs the details of the current status of a Certificate resource

/kind feature
/area ctl

Few small things then LGTM!

/lgtm

/approve


Rebrand to FTorch-benchmark

Closes #19
Rebranding to FTorch-benchmark

[x] Update references in Main README and CMakeLists
[x] Check for any other references to fortran-pytorch-lib-benchmark
[ ] We could restructure the code into separate folders?
[x] Rename repo on github

Changes made and ready to rename repo and merge.
However, some thoughts:

Do we want to restructure here, or on another PR?
If this is more serious we should add a license - MIT?
Similarly the README should be fleshed out with contribution guidelines and code of conduct etc.

Thoughts @TomMelt / @ElliottKasoar

OK, I've added an MIT license directly to the main repo.
I feel this is most appropriate here and matched the main FTorch repo.
I will merge this now in that case, and restructuring and polish can be added in a future workload.

Thanks for this 👍


[INFRA] add issue forms

closes #2
Example form: https://github.com/Remi-Gau/oreoni/issues/new?assignees=&labels=&template=feature_request.yml&title=[ENH]+
Example ouput: https://github.com/Remi-Gau/oreoni/issues/1

Thank you so much @Remi-Gau this looks great! I can adapt the table according to this later on, would make things much tidier indeed :)

Actually check the flat version of the table I linked to on our email thread. Should be much easier to generate one subtable per section.


SSH Tunneling disabled breaks match

When SSH tunneling is disabled match breaks - CocoaPods and Git themselves are intelligently able to switch to HTTP which gets around this but Match continues to use SSH.

Hi @jcampbell05 Thanks for letting us know. Are you interested in submitting a PR?


Jira - Create EPIC field via API

Hello,
I would like to edit the field "Create EPIC" in a engagement using the DefectDojo APIv2 however I could not find where ?
Is this not implemented yet or I'm just blind ?
Regards,
xanhacks

I don't think it's implemented.


filter: add a new filter for organization membership

in some cases you want to restrict a CI run only for trusted
organization members
Signed-off-by: Maximilian Meister<EMAIL_ADDRESS>

This is authentication for PRs. I'd like the resource to no be in the business of authentication, since each request I've had for authentication has been different, including this.
What problem are you trying to solve?

@jtarchie to whitelist contributors for preventing ci runs that were submitted by people from outside the organization. an example would be someone tries to run malicious code in your infrastructure. this would be rather a security measure instead of an authentication.

I'm sorry, I meant authorization, not authentication, in my original comment. Pre-coffee comment.
I'd like to discuss this a bit more.
I don't want the resource to be in the business of doing authorization. There are just too many different combos that could be done.
Github provides the authorization methods for a PR.

You could use a private repo to ensure only people have access can make PRs.
There are labels that can be used for filtering.
Filter out PRs that are not from personal forks, but feature branches on the same repo.

Those options ensure Github has the responsibility of authorization, not the resource.

I see your point, I have considered your suggestions already, and tried to fit this in the existing options.

You could use a private repo to ensure only people have access can make PRs.

this is too exclusive i think when you want to have an open source project

There are labels that can be used for filtering.

i thought about using that feature, but that would require manual work (adding labels by an owner/admin/maintainer of the repo).
also i was not sure if the resource picks up a PR later if it has already been open for some time, and you just add a label to trigger the CI? not sure if that would work.

Filter out PRs that are not from personal forks, but feature branches on the same repo.

this would force all users within the organization to always submit a branch to upstream, which is again a negative side effect, as it enforces a certain workflow.
That's why I came up with that implementation of the option. I agree that there can be some different combinations of restrictions. but do you think that they would get in each other's way? if so this could perhaps be documented with a specific warning of a combination.

It is still an authorization feature request, which I don't want the resource to be responsible for.
I'm going to pass on this PR.
Thanks.

It is still an authorization feature request, which I don't want the resource to be responsible for.

makes sense, but then isn't the disable_forks option along the same line of authentication? you're restricting PR's from a group of users in the same way.

disable_forks looks at a value on the PR github API result. It does not make an assumption of what a user has access to. It just assumes that Github took care of that.

disable_forks looks at a value on the PR github API result. It does not make an assumption of what a user has access to. It just assumes that Github took care of that.

that's how it's done internally, i can see that. you compare the base repo and the head repo. it just seemed to me that you are restricting users that don't have push access to the upstream repo. but i guess then the option is for ensuring a specific workflow of submitting PR's. nevertheless thanks a lot for this resource, it's very helpful 👍


Wrong locaton for syntax error

Syntax errors inside function/modules get reported at the wrong location. Most often at the first line of the function where the syntax error happens. For example take a look at file_input() it passes the module as AST node to the error function.
Looks like this if inside syntax_error_dbg() is the reason, I'm wondering if the condition is just swapped or if the issue has to be handled in a different place?
Sorry for using a pull request for discussion / asking a question...

To be quite honest, I don't remember why I made the condition this way. This would need some testing to be sure that this fixes it. If it does, I will happily merge the change.

We'll let's see :-) We can revert it, if it breaks it.


Telemetry data under multiple prefixes.

Add another layer of abstraction, to allow telemetry counters to be
exported under prefixes other than stackdriver-nozzle. This paves
the way towards exporting nozzle-derived metrics based on firehose
data.

This change is

Hi Jeff,
This is the first step along the journey towards having the Nozzle export per-application HTTP metrics derived from HttpStartStop events. I went for a minimal change here, so I've kept the previous exported functions built on top of the new structs. If you'd prefer other approaches just let me know.
Cheers,
--alex

Review status: 0 of 1 files reviewed at latest revision, 1 unresolved discussion.

src/stackdriver-nozzle/telemetry/counters.go, line 24 at r1 (raw file):

)

const prefix = "stackdriver-nozzle/"

Essentially we're creating all sorts of data structures and factory methods to handle this string right here. We will maybe have 2 prefixes? stackdriver-nozzle/ and <user provided but firehose by default>/
I'd rather see either:

expose 'const Prefix', prepend it to all metric names that rely on this default

an options style API for specifying prefix, eg:
internalCounter = telemetry.NewCounter("internal")
firehoseMetricCounter = telemetry.NewCounter("internal", telemetry.Prefix("firehose"))

Comments from Reviewable

Review status: 0 of 1 files reviewed at latest revision, 1 unresolved discussion.

src/stackdriver-nozzle/telemetry/counters.go, line 24 at r1 (raw file):
Previously, johnsonj (Jeff Johnson) wrote…
Essentially we're creating all sorts of data structures and factory methods to handle this string right here. We will maybe have 2 prefixes? stackdriver-nozzle/ and <user provided but firehose by default>/
I'd rather see either:

expose 'const Prefix', prepend it to all metric names that rely on this default

an options style API for specifying prefix, eg:
internalCounter = telemetry.NewCounter("internal")
firehoseMetricCounter = telemetry.NewCounter("internal", telemetry.Prefix("firehose"))

The intent was to have >1, yes. I probably should have provided more context than the commit description.
I think it is important to distinguish between metrics that have come from the firehose directly and those that have been derived from that data, for the same reason that we distinguish between firehose data and the nozzle's internal metrics. Derived data requires Counters (and probably Gauges and other things) to track their values over time, so re-using the telemetry code seemed like the right thing to do.
I haven't completely firmed up the approach I want to take for the HTTP stats, but in terms of prefix either there would either be one prefix like "nozzle-derived" or "firehose-derived", or many -- this one would be something like "app-http-stats". Naming is hard :-(
I may be over-engineering for something that is demonstrating a proof-of-concept that may be better achieved in the gorouter. I think your criticism of there being way too much structure is entirely valid. But! The options syntax requires explicitly specifying the prefix for each metric, so it doesn't make much sense to me: the point of separating prefix from metric name is so that we don't have to do that.
I will rework this today and get back to you.

Comments from Reviewable

Review status: 0 of 1 files reviewed at latest revision, 1 unresolved discussion.

src/stackdriver-nozzle/telemetry/counters.go, line 24 at r1 (raw file):
Previously, fluffle (Alex Bee) wrote…
The intent was to have >1, yes. I probably should have provided more context than the commit description.
I think it is important to distinguish between metrics that have come from the firehose directly and those that have been derived from that data, for the same reason that we distinguish between firehose data and the nozzle's internal metrics. Derived data requires Counters (and probably Gauges and other things) to track their values over time, so re-using the telemetry code seemed like the right thing to do.
I haven't completely firmed up the approach I want to take for the HTTP stats, but in terms of prefix either there would either be one prefix like "nozzle-derived" or "firehose-derived", or many -- this one would be something like "app-http-stats". Naming is hard :-(
I may be over-engineering for something that is demonstrating a proof-of-concept that may be better achieved in the gorouter. I think your criticism of there being way too much structure is entirely valid. But! The options syntax requires explicitly specifying the prefix for each metric, so it doesn't make much sense to me: the point of separating prefix from metric name is so that we don't have to do that.
I will rework this today and get back to you.

How do you feel about this approach?
Usage would look like:
appPrefix := telemetry.MetricPrefix("app-httpstartstop")
appRequests := appPrefix.NewCounter("requests")
appResponseCodes := appPrefix.NewCounterMap("response_codes")
metricSet could be decomposed into two package-level vars as before, I guess.

Comments from Reviewable

Review status: 0 of 1 files reviewed at latest revision, 1 unresolved discussion.

src/stackdriver-nozzle/telemetry/counters.go, line 24 at r1 (raw file):
Previously, fluffle (Alex Bee) wrote…
How do you feel about this approach?
Usage would look like:
appPrefix := telemetry.MetricPrefix("app-httpstartstop")
appRequests := appPrefix.NewCounter("requests")
appResponseCodes := appPrefix.NewCounterMap("response_codes")
metricSet could be decomposed into two package-level vars as before, I guess.

It's not different though- is it? We need to knowledge of the appPrefix for each version. IMO the options approach is more go-like and keeps the struct's POD.
appPrefix := telemetry.MetrixPrefix("app-httpstartstop")
appRequests := appPrefix.NewCounter("requests")
// vs
appPrefix := telemetry.MetrixPrefix("app-httpstartstop")
appRequests :=telemetry.NewCounter("requests", telemetry.Prefix(appPrefix))

What I care about the most here is not duplicating any of the existing methods (Do,Get,New*) and creating a special case code path for nozzle metrics vs non-nozzle. If you want to accomplish that with the metricPrefix as a builder then I recommend dropping the package level version and expose var StackdriverNozzle MetricType

Comments from Reviewable

Review status: 0 of 13 files reviewed at latest revision, 1 unresolved discussion, some commit checks failed.

src/stackdriver-nozzle/telemetry/counters.go, line 24 at r1 (raw file):
Previously, johnsonj (Jeff Johnson) wrote…
It's not different though- is it? We need to knowledge of the appPrefix for each version. IMO the options approach is more go-like and keeps the struct's POD.
appPrefix := telemetry.MetrixPrefix("app-httpstartstop")
appRequests := appPrefix.NewCounter("requests")
// vs
appPrefix := telemetry.MetrixPrefix("app-httpstartstop")
appRequests :=telemetry.NewCounter("requests", telemetry.Prefix(appPrefix))

What I care about the most here is not duplicating any of the existing methods (Do,Get,New*) and creating a special case code path for nozzle metrics vs non-nozzle. If you want to accomplish that with the metricPrefix as a builder then I recommend dropping the package level version and expose var StackdriverNozzle MetricType

That makes sense. I kept the package-level functions because it involved less refactoring, so the diff had a higher SNR. I've added a second commit on top of the first in this PR so that there are no longer package-level functions in telemetry. The refactoring made it a little clearer that counters should be exported for testing -- they are de-facto public anyway because they can be retrieved via the telemetry package.
It seems I misunderstood your suggestion of the Options approach, I was mostly averse to repeating constant strings for each metric. I still think it's overly complex for what's needed here. If we had more than one option, or if the prefix was in fact optional, then sure. But the prefix isn't really optional here, and the infrastructure for options processing feels a bit like my first pass at this change: lots of functions to handle a string. This way it really is just a string. But if you still feel strongly about it, I will take that approach.

Comments from Reviewable

Review status: 0 of 13 files reviewed at latest revision, 4 unresolved discussions, some commit checks failed.

src/stackdriver-nozzle/metrics_pipeline/auto_culled_metrics_buffer.go, line 32 at r3 (raw file):

var (
	// Exported so that tests outside the metrics_pipeline package can read values.

I don't see any tests outside of metrics_pipeline that need this. Maybe I'm missing it- I did just have eye surgery (hehe).
Instead of exporting all of the counters (which I agree is the same as it used to be), I'd prefer a change to the tests to be in the same package (s/metrics_pipeline_test/metrics_pipeline). If you don't want to do all that work in this change that's fine.

src/stackdriver-nozzle/nozzle/nozzle_test.go, line 51 at r3 (raw file):

	It("updates the counter", func() {
		nozzle.FirehoseEventsTotal.Set(0)

suggest moving to the BeforeEach block, If that seems too broad then put in its own Context("telemetry tests", func() {..) and do it there.

src/stackdriver-nozzle/stackdriver/metric_adapter_test.go, line 240 at r3 (raw file):

	It("increments metrics counters", func() {
		stackdriver.FirehoseEventsCount.Set(0)

This should be in a BeforeEach somewhere (same comment to other affected tests)

src/stackdriver-nozzle/telemetry/counters.go, line 24 at r1 (raw file):
Previously, fluffle (Alex Bee) wrote…
That makes sense. I kept the package-level functions because it involved less refactoring, so the diff had a higher SNR. I've added a second commit on top of the first in this PR so that there are no longer package-level functions in telemetry. The refactoring made it a little clearer that counters should be exported for testing -- they are de-facto public anyway because they can be retrieved via the telemetry package.
It seems I misunderstood your suggestion of the Options approach, I was mostly averse to repeating constant strings for each metric. I still think it's overly complex for what's needed here. If we had more than one option, or if the prefix was in fact optional, then sure. But the prefix isn't really optional here, and the infrastructure for options processing feels a bit like my first pass at this change: lots of functions to handle a string. This way it really is just a string. But if you still feel strongly about it, I will take that approach.

OK with me.
Prefix would be optional if we default it to stackdriver-nozzle but perhaps that's not good. I think a package level variable to contain the name as you've done here is a nice solution.
I don't think the naming is right, "a MetricPrefix builds a Counter" which makes me hesitant about the API. That's why I lean towards the prefix being part of the creation call "the telemetry package creates a Counter with a MetricPrefix and Name".
I think it's structurally sound and will accomplish what we both want so let's move forward.  The removal of the telemetrytest package to me is a good sign that this is progress.

Comments from Reviewable

Review status: 0 of 23 files reviewed at latest revision, 4 unresolved discussions.

src/stackdriver-nozzle/metrics_pipeline/auto_culled_metrics_buffer.go, line 32 at r3 (raw file):
Previously, johnsonj (Jeff Johnson) wrote…
I don't see any tests outside of metrics_pipeline that need this. Maybe I'm missing it- I did just have eye surgery (hehe).
Instead of exporting all of the counters (which I agree is the same as it used to be), I'd prefer a change to the tests to be in the same package (s/metrics_pipeline_test/metrics_pipeline). If you don't want to do all that work in this change that's fine.

Sure, I can do that. I thought there were gingko-related reasons as to why metrics_pipeline and metrics_pipeline_test were separate packages, that's why I didn't take this approach at first.

src/stackdriver-nozzle/nozzle/nozzle_test.go, line 51 at r3 (raw file):
Previously, johnsonj (Jeff Johnson) wrote…
suggest moving to the BeforeEach block, If that seems too broad then put in its own Context("telemetry tests", func() {..) and do it there.

Done, I should have done that to begin with sorry!

src/stackdriver-nozzle/stackdriver/metric_adapter_test.go, line 240 at r3 (raw file):
Previously, johnsonj (Jeff Johnson) wrote…
This should be in a BeforeEach somewhere (same comment to other affected tests)

Done.

src/stackdriver-nozzle/telemetry/counters.go, line 24 at r1 (raw file):
Previously, johnsonj (Jeff Johnson) wrote…
OK with me.
Prefix would be optional if we default it to stackdriver-nozzle but perhaps that's not good. I think a package level variable to contain the name as you've done here is a nice solution.
I don't think the naming is right, "a MetricPrefix builds a Counter" which makes me hesitant about the API. That's why I lean towards the prefix being part of the creation call "the telemetry package creates a Counter with a MetricPrefix and Name".
I think it's structurally sound and will accomplish what we both want so let's move forward.  The removal of the telemetrytest package to me is a good sign that this is progress.

Hmmm. I see your point about the naming. And I am aware I have a weakness for putting methods on things :-)
It's a minor change to reinstate the package-level New functions and require a MetricPrefix as their first argument -- after all that's basically what happens under the hood anyway, it's just a question of how you want the syntax to look. We go from:
counter := telemetry.Nozzle.NewCounter("name")

to
counter := telemetry.NewCounter(telemetry.Nozzle, "name")

The latter is very similar to the Option approach you proposed but without the ... optionality? :-D

Comments from Reviewable

 awesome work @fluffle, between this CR and your help with #152 this has been a huge leap for the nozzle in metric usability and code health.

Reviewed 2 of 13 files at r3, 21 of 21 files at r4.
Review status: all files reviewed at latest revision, 4 unresolved discussions.

src/stackdriver-nozzle/cmd/firehose_rate.go, line 58 at r4 (raw file):

	defer counter.Stop()
	for _ = range messages {
		counter.Increment("count")

forgot about this code! thanks for find/fix :)

src/stackdriver-nozzle/metrics_pipeline/auto_culled_metrics_buffer.go, line 36 at r4 (raw file):

func init() {
	eventsSampledCount = telemetry.NewCounter(telemetry.Nozzle, "metrics.firehose_events.sampled.count")

this looks great!

src/stackdriver-nozzle/telemetry/counters.go, line 24 at r1 (raw file):
Previously, fluffle (Alex Bee) wrote…
Hmmm. I see your point about the naming. And I am aware I have a weakness for putting methods on things :-)
It's a minor change to reinstate the package-level New functions and require a MetricPrefix as their first argument -- after all that's basically what happens under the hood anyway, it's just a question of how you want the syntax to look. We go from:
counter := telemetry.Nozzle.NewCounter("name")

to
counter := telemetry.NewCounter(telemetry.Nozzle, "name")

The latter is very similar to the Option approach you proposed but without the ... optionality? :-D

Awesome awesome awesome.

src/stackdriver-nozzle/telemetry/counters.go, line 32 at r4 (raw file):

}

// IntValue returns the counter's value as an int rather than an int64. Tests are

agreed this is needed. I personally think it's a shame ginkgo/gomega doesn't match Expect(int64(5)).To(Be(5)) given 5 is a constant.

Comments from Reviewable


⚠ Fortnite has degraded performance

In b743587, Fortnite (https://fortnite.com) experienced degraded performance:

HTTP code: 200
Response time: 1604 ms

Resolved: Fortnite performance has improved in 8be97d4.


rebrand dev portal URL

Docs Build status updates of commit edb0bfa:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

Advertising/bingads-12/guides/geographical-location-codes.md
:white_check_mark:Succeeded

Advertising/bingads-13/guides/geographical-location-codes.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Couldn't connect Homebridge

I hate to post another issue about this, but I've tried everything from the similar issues I've read and I still can't complete setup in iOS (10.2.1).
I'm unning Homebridge on OSX Sierra. Homebridge starts with no errors. I've started with and without platforms and accessories, makes no difference.
When I enter the code on my phone it circles for a while and ultimately says it couldn't connect. Please advise.

Hey,
have you tried:

Homebridge server thinks it's been paired with, but iOS thinks otherwise. Fix: deleted persist/ directory which is next to your config.json.

iOS device has gotten your Homebridge username (looks like a MAC address) "stuck" somehow, where it's in the database but inactive. Fix: change your username in the "bridge" section of config.json to be some new value.

I have tried both of these and it still doesn't work. I've also changed the port to 36631, just to see if that would work.
I'll also not that "scanning" the code from my app also doesn't work. I get the box and so on, but it ends up going to a screen to manually input the code, which I do and then it tries to pair for ~1 min before telling me it couldn't add Homebridge.

I got this working on another Mac in Sierra vs El Cap. I have no idea why it wasn't working on the other machine. Now I'm trying to get it running in the background -- see this issue.


integrations: Render zulip_bots/bots/<bot_name>/doc.md files.

This PR is related to and depends on zulip/python-zulip-api#129.
The easiest way to test these changes would be to checkout zulip/python-zulip-api#129 and copy the static files for the xkcd bot to zulip/static/generated/bots/xkcd/, checkout this PR, and then run the dev server to see how these files are rendered.
I would like to have a longer discussion about this tomorrow at the integrations meeting as well! This is largely a WIP as of now. :)
Thanks
-Eeshan

Merged, after reordering the commits to a sequence that makes sense:

First, package upgrade to get the new xkcd docs
Then, add the macro
Then, add the xkcd bot to the docs


fix(useQuery): streamline parameters passed to useErrorBoundary function to be the same as onError of the queryCache

:tada: This PR is included in version 3.34.16 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 4.0.0-alpha.14 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Update fragment-introspection.md

Update small patch into the documentation
PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows our guidelines: https://github.com/graycoreio/daffodil/blob/develop/CONTRIBUTING.md#commit
[x] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

Fixes: N/A
What is the new behavior?
Does this PR introduce a breaking change?
[ ] Yes
[ ] No

Other information

Replaced by https://github.com/graycoreio/daffodil/pull/2468


Restore defaultForCurrency variable in the Card

@Maxim-Inv Where is this property on the card resource? I'm not seeing it here https://stripe.com/docs/api/cards/object

@Andrewangeta  Oh, really. I still get this field because I haven't upgraded the API version. I'll try to update it now.

@Andrewangeta I've checked Stripe API version 2023-10-16, the default_for_currency field is present in the response.
  {
      "id": "card_......",
      "object": "card",
      "account": "acct_......",
      "address_city": null,
      "address_country": null,
      "address_line1": null,
      "address_line1_check": null,
      "address_line2": null,
      "address_state": null,
      "address_zip": null,
      "address_zip_check": null,
      "available_payout_methods": [
        "standard",
        "instant"
      ],
      "brand": "MasterCard",
      "country": "US",
      "currency": "usd",
      "cvc_check": "pass",
      "default_for_currency": true,
      "dynamic_last4": null,
      "exp_month": 12,
      "exp_year": 2025,
      "fingerprint": "......",
      "funding": "debit",
      "last4": "0000",
      "metadata": {},
      "name": null,
      "status": "new",
      "tokenization_method": null,
      "wallet": null
    },

@Andrewangeta actually, this variable was in the previous versions and I use it in my project. So, it would be great if you accept this PR.

Thank you!


Added Miami University of Ohio (USA)

Miami University, Oxford, OH
https://miamioh.edu/
https://miamioh.edu/cec/departments/computer-science-software-engineering/index.html
https://miamioh.edu/policy-library/students/undergraduate/academic-regulations/student-email-policy.html

@caleb-mostyn I am sorry, the domain miamioh.edu is removed from our trusted domains list because it was abused in the past. If you are the student of this school, please enroll to GitHub Student Developer Program. Then apply for JetBrains educational subscription with your GitHub account (GitHub tab at https://www.jetbrains.com/shop/eform/students).

because it was abused in the past.

@philipto I'm curious what you mean by abused. To my knowledge, the university previously provided unlimited access to the .edu addresses to all graduates, and that could very well open up to abuse, but that has very recently changed. Now, all prior graduates have had their accounts deleted and new graduates only maintain their account for 180 days after graduating.
From Miami's website: "Our recent grads will keep Google email accounts for 180 days post departure from the university. While they will have access to their email address, Google Drive and Photos during that 180 days, they will not be able to create new documents, or edit existing documents."

@caleb-mostyn Thank you for your comment and for the update.
By "abused" I meant that in September of 2023 we found out that about 70 email addresses @miamioh.edu were used by third parties who are not students at the university. Given that the changes you mentioned happened in April 2024, I remove miamioh.edu from the list of abused domains, and accept this pull request.
A note for the future commenters: that if you have any concerns or feedback it's better sending it to<EMAIL_ADDRESS>because the comments to closed pull requests are not monitored.
Pull request merged. Please start requesting the licenses in about an hour, to let the changes to propagate through our system. Thank you.


All tests are going to be broken by new import pipeline

Because the database layout has changed completely, all existing tests are going to be broken when the new_import branch is deployed. These will need to be fixed!

Many tests have been converted, but there are still tests left to do.

The remaining tests appear to be:
paraminfo/tests.py (all)
results/tests.py (a few - many of these will need significant modification)
search/tests.py (a few at the end)
ui/tests.py (all)

These have been broken out into separate bugs


Data quality issue with CVE-2016-10506

The CVE ID
CVE-2016-10506
Describe the data quality issue observed
A clear and concise description of what the observed issue with the record is.
The affected versions about CVE-2016-10506 was wrong. The website versions is '2.5.0-2', '2.4.0-5', '2.5.0-1', '2.5.0-2~hurd.1', '2.4.0-6', '2.4.0-4', '2.4.0-3'. But in fact, vulnerabilities have been fixed on these versions. The incorrect vulnerability version can cause difficulties for developers and vendors, but I think the correct vulnerability version should be ['opj0-97', 'version.2.0', 'version.1.5', 'start', 'wg1n6848', 'version.1.3', 'version.2.0.1', 'version.1.2', 'v2.1.2', 'version.2.1', 'version.1.5.2', 'version.1.1', 'v2.1.1', 'version.1.5.1', 'version.1.4'].
Suggested changes to record
Check the version affected by the vulnerability.
Additional context
Patch
Error version
Right version

Thanks for reporting this issue! This seems like a Debian issue where they mark this CVE as affecting all the versions that they release: https://security-tracker.debian.org/tracker/CVE-2016-10506
Can you report this to the Debian security team? https://wiki.debian.org/Teams/Security

It does seem to be marked as unimportant by them as well, which might be why it has not been updated. This unimportant tag is also imported into OSV entries.

ok~ Thanks


error[internal]: left behind trailing whitespace on demo file

Hello together,
I was working on a project using VSCode and rust-analyzer as an IDE when my autoformatting (format on save) stopped working.
While running cargo fmt I got the following message: error[internal]: left behind trailing whitespace.
I was able to build a minimal file that reproduces the error. The file can be found here: demo.rs
The bug was reproducible by running cargo fmt --check demo.rs with version rustfmt 1.5.2-stable (8ede3aae 2023-07-12)  and the latest master.
I'm pretty sure the bug is caused by the arrow syntax of the array_macro crate.
Thanks for your awesome work on rust and its tools!
Kaladum

I got the same error but my case is different. I produced what I think is an MRE for my case. But in mine if I shorten the long line by one char from the string argument then the problem goes away.
Maybe it's macros that are long or go beyond the end of the line. I further noticed that if I wrap that leg of the match in braces the problem also goes away even if I make the line longer.
I created a repo with my MRE.
Excerpt from main:
fn main() {
    match File::open("NON-EXISTENT") {
        Ok(_) => {
            "anything".to_string()
        }
        Err(_) => format!("1234567890+1234567890+1234567890+1234567890+1234567890+1234567890+1234567890+123456789"),
    };
    // If the text inside of the format string is 1 char shorter the problem goes away
}

My error message is:
error[internal]: left behind trailing whitespace
 --> /home/one/rustfmt_mre/src/main.rs:5:5:19
  |
5 |         Ok(_) => {
  |                   ^^^
  |

warning: rustfmt has failed to format. See previous 1 errors.

If it is of any value the line I think in my real project that triggers the error is this one

@c-git Thanks for reaching out. The issue here is the long unbreakable string literal, and is unrelated to this report. The issue is that rustfmt is unable to format all the match arms within the max_width, and therefore fails to rewrite the entire match statement. Your best option is to increase the max_width.
I've also checked and using version=Two formats your code like this:
fn main() {
    match File::open("NON-EXISTENT") {
        Ok(_) => "anything".to_string(),
        Err(_) => format!(
            "1234567890+1234567890+1234567890+1234567890+1234567890+1234567890+1234567890+123456789"
        ),
    };
    // If the text inside of the format string is 1 char shorter the problem goes away
}

Inlining the code snippet posted by @Kaladum
use super:: TMP;

const TEST: [FOO; 64] = array![i => {
	bar(42,&[(0,1)]),
};64];

and here's the error message:
error[internal]: left behind trailing whitespace
 --> <stdin>:3:3:38
  |
3 | const TEST: [FOO; 64] = array![i => {
  |
  |

warning: rustfmt has failed to format. See previous 1 errors.

I'm pretty sure the bug is caused by the arrow syntax of the array_macro crate.

I'm also pretty sure it's the arrow syntax that's causing rustfmt to fail here. Macro formatting is difficult because macros can contain any valid tokens, not necessarily valid rust code. rustfmt is only able to format macros if their arguments parse as valid rust.
Your best option is to manually remove the trailing whitespace.


) at the end of a link is interpreted as part of it

It seems as if closing curved brackets are interpreted as part of the link.

Parens are valid in URLs. The post should've used Markdown for the Link instead of relying on the auto-link behaviour.
Example: [https://github.com/schtibe/postcardy/issues/1](https://github.com/schtibe/postcardy/issues/1)
Example of an URL with parens: https://en.wikipedia.org/wiki/Pennywise_(band)
I'll probably have to fix this in the DB or implement the edit post functionality mentioned in #3.


rustc warning: ... range patterns are deprecated

warning: `...` range patterns are deprecated
  --> /home/trivikr/.cargo/registry/src/github.com-1ecc6299db9ec823/vlq-0.5.1/src/lib.rs:35:13
   |
35 |         b'A'...b'Z' => Ok(input - b'A'),
   |             ^^^ help: use `..=` for an inclusive range
   |
   = note: #[warn(ellipsis_inclusive_range_patterns)] on by default

Code which needs to be updated: https://github.com/tromey/vlq/blob/5d13a5c037cb1eb4ba63f728994fcf1804e0dcf6/src/lib.rs#L35-L37

Thanks for the heads up @trivikr -- are you interested in submitting a pull request to fix this?

are you interested in submitting a pull request to fix this?

Sure, I would love to.
Note that inclusive range syntax became stable in v1.26.0 (Release Notes).
Do you plan to support rust versions older than v1.26.0?

IMO it's fine to just drop older versions, but probably @fitzgen should say for sure.  OOC is there a way to support both?

I think it is fine to drop support for older rustc with this crate.

OOC is there a way to support both?

I think just doing #[allow(ellipsis_inclusive_range_patterns)] on the function

OOC is there a way to support both?

I'm not sure, as most repos I'd cut similar issues with stated reasons related to supporting old versions:

https://github.com/alexcrichton/rustc-demangle/issues/33#issuecomment-538721701
https://github.com/bluss/either/issues/41#issuecomment-538725934

I think it is fine to drop support for older rustc with this crate.

Is there an official way to show supported versions in rust?
For node packages, it's specified in the "engines" field in package.json (docs)


Checkpointing support

There is a technique called checkpointing when activations remembered only in specific nodes in computation graph and for other nodes they are recomputed during backpropagation. It allows greatly reduce memory usage at the cost of extra computations, and it is supported in PyTorch: https://pytorch.org/docs/stable/checkpoint.html
I haven't found any functionality related to checkpointing in Candle, so for now I'm using a dirty hack:

on feedforward step build an additional computation graph that stores only initial activations,
put empty tensors to Candle's backprop graph instead of original tensors to allow them to be removed from memory,
use CustomOp*s to recover removed tensors from additional graph during backprop.

Is there any tool for enabling checkpointing in Candle I haven't found? Or maybe exists a more convenient way to implement it in Candle?

The idea with another graph was not working as expected because we cannot specify an order of Candle's computation graph traversal.
I end up using different approach. Let we have some operation sequence for which we don't want to remember intermediate values. To achieve this the sequence is wrapped in closure and put in CustomOp*:

On forward pass the closure is executed and result is detached.
On backward pass the closure is executed again and backward method is called for result, and then we extract gradients for input values from GradStore.

This method is not very convenient and requires inner closure to be fully reproducible (e.g. it cannot use random functionality like dropout). But it's pretty simple to implement it without messing with Candle internals.


Not a support request, but more of a THANK YOU

WOOT!   I have almost 22 integrations in Smartthings that seamlessly worked after installing your plugin.
Keep up the awesome work and integration with this!
Wes

Thanks!


Bad lastTraining date when training fails

On Russell's agent I keep seeing lastTraining: " Invalid Date" which suggests to me that when training fails we are still writing the date, but to a bad one.
Investigate and correct if possible. Or strip lastTraining dates on export since they really won't apply to new imports.

This is probably due to the library in charge of translate the date to "time ago". Let me check

I imported and checked in multiple scenarios but wasn't able to reproduced it, I used bad date string but it didn't show Invalid Date. Please post what is your scenario.

Okay, we'll see if it creeps back up in Russell's testing.


please update to support SQLitePCL.raw 0.8.2 (package name has changed)

Please update to support SQLitePCL.raw 0.8.2 - Note this package name has changed by the author and has dropped the _basic of the old package on Nuget.  SQLitePCL.raw 0.8.2 now includes the SQLite <IP_ADDRESS> binary.

Echoing the same comment--see https://www.nuget.org/packages/SQLitePCL.raw_basic/ "Note that with the 0.8.0 release, the package ID is changing from 'SQLitePCL.raw_basic' to 'SQLitePCL.raw'. For now, the package exists under both IDs and they are identical. Eventually the old ID may stop getting "
For whatever reason today I'm unable to resolve the "basic"package.  If I update my packages.config to reference SQLitePCL.raw then I get a runtime error because SQLite-net can't find SQLitePC.raw_basic <IP_ADDRESS>


How to implement try-with-resources support

I want use try-with-resources with ActiveJDBC but neither Base nor DB implements Closable. Is possible to implement or is irrelevant??
I am sorry to post here but someone to answer my question: http://stackoverflow.com/questions/38442356/how-to-load-two-or-more-models-in-same-query

@programadorthi you are correct, we need this feature. By the way, I provided an answer on the SO, and deleted your comment as irrelevant  for this issue.
In fact we will implement this in 1 - 2 days and will make the snapshot available.

Thanks. I had an urgent problem and I solved using basic try-finally.

@programadorthi I will close when I commit code :)

@ipolevoy Sorry, I haven't seen that I had closed. I clicked in the wrong button and closed the window! kkk

@programadorthi no worries, will close soon

@programadorthi this is done: http://javalite.io/database_connection_management#use-try-with-resources