firefox-bin: add libXtst and libXrandr to lib path

firefox nightly now requires libXtst.so.6
without this change firefox nightly from the mozilla overlay fails to
start
added libXrandr too since libxul.so requires it
libXrandr.so.2 => not found
libXtst.so.6 => not found

Motivation for this change
Things done
before
ldd result/usr/lib/firefox-bin-96.0a1/libxul.so | rg 'not found'
	libmozsandbox.so => not found
	liblgpllibs.so => not found
	libmozsqlite3.so => not found
	libmozgtk.so => not found
	libmozwayland.so => not found
	libXrandr.so.2 => not found
	libXtst.so.6 => not found

after
ldd result/usr/lib/firefox-bin-96.0a1/libxul.so  | rg not
	libmozsandbox.so => not found
	liblgpllibs.so => not found
	libmozsqlite3.so => not found
	libmozgtk.so => not found
	libmozwayland.so => not found

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Thanks @Artturin !


Connection to HF2LI

Hi all,
I was previously using the old qcodes to connect to my HF2LI as
from qcodes.instrument_drivers.ZI.ZIUHFLI import ZIUHFLI
ZIUHFLI(name='u1', device_ID='DEV405')

and it worked great.
I was obtaining the following print
Discovered device `dev405`: HF2LI with options MF, WEB.
Creating an API session for device `dev405` on `<IP_ADDRESS>`, `8005` with apilevel `1`.

I recently updated my workstation to the new qcodes and I got a deprecated message while using that code
QCoDeSDeprecationWarning: The class <ZIUHFLI> is deprecated, because There is a new UHFLI driver from Zurich Instruments. Use "instrument_drivers.zurich_instruments.uhfli.UHFLI" as an alternative.
  issue_deprecation_warning(f'{t} <{n}>', reason, alternative)

I so used the suggested code and I simply can't connect to the HF2LI anymore.
from  qcodes.instrument_drivers.zurich_instruments.uhfli import UHFLI
UHFLI(name='uhf4',
           serial='dev405',
           interface='USB',
           port=8005,
           api=1)

gives me
Successfully connected to data server at localhost:8005 api version: 1
Successfully connected to device DEV405 on interface USB
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-19-33866b347b0b> in <module>
----> 1 UHFLI(name='uhf4',
      2                    serial='dev405',
      3                    interface='USB',
      4                    port=8005,
      5                 api=1)

~\Anaconda3\lib\site-packages\zhinst\qcodes\uhfli.py in __init__(self, name, serial, interface, host, port, api, **kwargs)
    383         **kwargs,
    384     ) -> None:
--> 385         super().__init__(name, "uhfli", serial, interface, host, port, api, **kwargs)
    386         submodules = self.nodetree_dict.keys()
    387         # initialize submodules from nodetree with blacklist

~\Anaconda3\lib\site-packages\zhinst\qcodes\base.py in __init__(self, name, device_type, serial, interface, host, port, api, **kwargs)
     81                 f"Device type {device_type} is currently not supported in ziQCoDeS. Supported types are {supported_types}"
     82             )
---> 83         self._connect()
     84
     85     def _connect(self) -> None:

~\Anaconda3\lib\site-packages\zhinst\qcodes\uhfli.py in _connect(self)
    409         )
    410         self._controller.setup()
--> 411         self._controller.connect_device(nodetree=False)
    412         self.connect_message()
    413         self._get_nodetree_dict()

~\Anaconda3\lib\site-packages\zhinst\toolkit\control\drivers\uhfli.py in connect_device(self, nodetree)
     69
     70         """
---> 71         super().connect_device(nodetree=nodetree)
     72         self._get_streamingnodes()
     73         if "AWG" in self._options:

~\Anaconda3\lib\site-packages\zhinst\toolkit\control\drivers\base\base.py in connect_device(self, nodetree)
    110         if nodetree:
    111             self._nodetree = NodeTree(self)
--> 112         self._options = self._get("/features/options").split("\n")
    113         self._init_settings()
    114

~\Anaconda3\lib\site-packages\zhinst\toolkit\control\drivers\base\base.py in _get(self, command, valueonly)
    207         """
    208         self._check_connected()
--> 209         return self._controller.get(command, valueonly=valueonly)
    210
    211     def _get_nodetree(self, prefix: str, **kwargs) -> Dict:

~\Anaconda3\lib\site-packages\zhinst\toolkit\control\connection.py in get(self, command, valueonly)
    487             else:
    488                 data = self._connection.get(node_string, settingsonly=False, flat=True)
--> 489             data = self._get_value_from_dict(data)
    490             if valueonly:
    491                 if len(data) > 1:

~\Anaconda3\lib\site-packages\zhinst\toolkit\control\connection.py in _get_value_from_dict(self, data)
    541             if isinstance(data_dict, list):
    542                 data_dict = data_dict[0]
--> 543             if "value" in data_dict.keys():
    544                 new_data[key] = data_dict["value"][0]
    545             if "vector" in data_dict.keys():

AttributeError: 'str' object has no attribute 'keys'

If someone could give me some clue, that would be nice!

Hi @slaven92,
Unfortunately not really.
I contacted ZI directly and this was their reply:

The old driver, the one in qcodes.instrument_drivers.ZI.ZIUHFLI, was originally written by people in Copenhagen for the UHFLI only. It was working with the HF2LI only by chance on a subset of features. For example the multiple demodulators are not correctly mapped and would fail in many cases.
Unfortunately in zhinst-qcodes we don’t support the HF2LI since this instrument is quite different from the others and we don’t have short term plans to add it.
There is a specific driver for the HF2 maintained by the community, you can find it in the qcodes contrib drivers.
The zhinst-qcodes is an open source project, so we welcome patches by the community, if you wish to add any functionality in it.

So I went back to the old driver from qcodes.instrument_drivers.ZI.ZIUHFLI import ZIUHFLI and ignore the warning.

@edumur Did you have a look at the driver in qcodes contrib drivers? https://github.com/QCoDeS/Qcodes_contrib_drivers/blob/master/qcodes_contrib_drivers/drivers/ZurichInstruments/HF2LI.py
That one would probably be a better alternative than the one in qcodes since it is not deprecated

@jenshnielsen I did and I think it has much less feature.

Ok thanks, do you think it would make sense to port those features over? Or move that driver to contrib drivers and mark it as a HF2LI only driver?
In the long run we would like to remove the UHFLI driver from qcodes since the one in zi-qcodes is more suitable for the UHLFI

I do not have a clear reply to this.
The current situation is the following:

qcodes.instrument_drivers.zurich_instruments.uhfli does not work for the HF2LI.
qcodes.instrument_drivers.ZI.ZIUHFLI works but is written deprecated.
qcodes_contrib_drivers.drivers.ZurichInstruments.HF2LI works but, as written in the docstring of the instrument,

This driver is meant to emulate a single-channel lockin amplifier,
so one instance has a single demodulator, a single sigout channel,
and multiple auxout channels (for X, Y, R, Theta, or an arbitrary manual value).
Multiple instances can be run simultaneously as independent lockin amplifiers.
This instrument has a great deal of additional functionality that is
not currently supported by this driver.".

So we went for 2 since in the end it worked for us...
In the long run I would say that the contrib_driver implements a specific use of the HF2LI which is not general enough compare to what the "official" ZI drivers are offering.
However there is no official driver for the HF2LI and they have no plan to add it.
The only long term solution I see is to mark the HF2LI contrib_driver as the only driver for the HF2LI and to work on it to make it more general.
It is still not perfect though.

Just to clarify qcodes.instrument_drivers.zurich_instruments.uhfli is actually an alias to zhinst.qcodes.uhfli and lives in this repository.
What I suggest as a medium term solution is: Take the current uhfli driver from qcodes qcodes.instrument_drivers.ZI.ZIUHFLI and copy it to contrib drivers next to the current HF2LI driver. Rename it to something with HF2LI and do whatever easy cleanups can be done and remove the deprecation warning. Then in the future that can be used as a more complete starting point for a new HF2LI driver.

Thanks for the precision.
I like your solution!

Happy to announce that with the latest changes which we now support HF2 devices within out driver.
We plan to release a new version to pypi next week.


[proj] Remove hardcoded definition PROJ_DATA

Fix #40055

Avoid passing in hardcoded paths that are not used https://github.com/OSGeo/PROJ/blob/9.4.1/src/filemanager.cpp#L1389-L1394
The internal lib is obtained from a relative path, so there is no need to specify environment variables https://github.com/OSGeo/PROJ/blob/9.4.1/src/filemanager.cpp#L1508-L1509

Checklist

[x] Changes comply with the maintainer guide.
[x] SHA512s are updated for each updated download.
[ ] ~The "supports" clause reflects platforms that may be fixed by this new version.~
[ ] ~Any fixed CI baseline entries are removed from that file.~
[ ] ~Any patches that are no longer applied are deleted from the port's directory.~
[x] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[x] Only one version is added to each modified port's versions file.

Test
The port installation tests pass with the following triplets:

x64-windows

The internal lib is obtained from a relative path, so there is no need to specify environment variables

This might not work as expected for static linkage. Environment variables and/or configuration API can and should be used.

This might not work as expected for static linkage. Environment variables and/or configuration API can and should be used.

Seem doesn't to affect the built library's use of environment variables.


test(e2e): add kind and minikube tests

Summary
Adding small e2e tests to start for kind and minikube. More incoming in future PR's but they're being separated for cognitive load.
Additions

e2e action

kind and minikube jobs

make run-local target

Closing to bundle in with an upcoming PR.


Manage allowed domains from admin settings.

Fixes: #1867.

Automated message from Dropbox CLA bot
@HarshitOnGitHub, it looks like you've already signed the Dropbox CLA. Thanks!

@timabbott I think it's complete now. :)

@timabbott Done.

Merged, after renaming the fields returned in the views to be e.g. domains instead of aliases.  This has been on the roadmap since something like a year ago, so I'm excited to have it finished!
Huge thanks for building this @HarshitOnGitHub!!
I opened https://github.com/zulip/zulip/issues/3145 for further cleaning up the RealmAlias model.


Integration of ion-tab in @ionic/angular to display custom content without using routes

Feature Request
Ionic version:
[x] 4.0.0
Describe the Feature Request
Please include reinclude ion-tab removed in 4.0.0 beta 18 in order to use with useRouter="false"
Describe Preferred Solution
ion-tab to display the content when useRouter="false" for example:
<ion-tab tab="test" active="true">
    <ion-nav id="test"></ion-nav>
</ion-tab>

Describe Alternatives
I do not have alternatives
Related Code
  <ion-tab-button tab="test">
    <ion-icon name="add"></ion-icon>
    <ion-label</ion-label>
  </ion-tab-button>

<ion-tab tab="test" active="true">
    <ion-nav id="test"></ion-nav>
</ion-tab>

@paulstelzer I hope now is correct.

Perfect :) But i cannot promise you if this will be integrated

You can use ion-tab-bar as a standalone component, you don't need tabs in order to implement your own "tabs" solution, that does not use routing!!

We will extend the docs to explain how this is possible!

@manucorporat the latest docs is still wrong I would like to see the changes thanks so mutch
https://beta.ionicframework.com/docs/api/tabs

I talked with @manucorporat about this and the solution is very simple. Just use the ion-tab-bar

      <ng-container *ngIf="tab === 'calendar'">
        Your calendar content
      </ng-container>

      <ng-container *ngIf="tab === 'speakers'">
        Your speakers content
      </ng-container>

      <ng-container *ngIf="tab === 'map'">
        Your map content
      </ng-container>

    <ion-tab-bar slot="bottom">
      <ion-tab-button (click)="show('calendar')">
        <ion-icon name="calendar"></ion-icon>
        <ion-label>Schedule</ion-label>
        <ion-badge>6</ion-badge>
      </ion-tab-button>

      <ion-tab-button (click)="show('speakers')">
        <ion-icon name="contacts"></ion-icon>
        <ion-label>Speakers</ion-label>
      </ion-tab-button>

      <ion-tab-button (click)="show('map')">
        <ion-icon name="map"></ion-icon>
        <ion-label>Map</ion-label>
      </ion-tab-button>
    </ion-tab-bar>

And inside your ts:
  tab = 'calendar';

  show(tab) {
    this.tab = tab;
  }

@paulstelzer thank you so mutch, This should be a typical use case for me and should be possible because i set useRouter="false"  in order to call tab content without router. I was able to make it works without work around from ionic 3.x.x to ionic 4.0.0 beta 17, after beta 18 no anymore.
However I used your code but I get the error below, how is possible that you do not get this error?
Missing "tab" property in
I am using the latest version 4.0.0-rc.0

@paulstelzer in my case the docs confuse me, I use angular but I will like to use:
Home Content
Settings Content
WIth that was so easy before 4.0.0 beta 18

@paulstelzer  any news?

I presented you a working solution -> https://github.com/ionic-team/ionic/issues/16796#issuecomment-449085001
A fix can be made to ion-tab-bar to reduce the css boilerplate. And related to tabs see this comment https://github.com/ionic-team/ionic/issues/16267#issuecomment-450417435

@paulstelzer  does not work because an error come up:
Missing "tab" property in ion-tab-button

That must be just a warning and the app should work without problems. This log will be removed soon


create the data source for Italy

Pyrosm currently uses data from Italy from geofabrik.
Geofabrik presents the data from Italy up to the macro-regions (= territorial aggregations - without administrative value - with which the national statics institute of Italy creates 4 territorial areas).
Istead the Italian administrative subdivision is made according to this hierarchical order
regions -> provinces -> municipalities
Wikimedia Italy has created the service "OSMit Estratti" that offers - in various formats (including pbf) - the extractions for these administrative levels.
This data is stored on a machine of WMI and elaborated every day with an extraction from Geofabrik.
If you move here:
https://osmit-estratti.wmcloud.org/dati/poly/
you can find the pbf files for: regions, provinces and municipalities
The list of the names of each resource can be also extracted by reading these geojson files https://github.com/GISdevio/estratti_OSM_Italia/tree/main/webapp/public/static/boundaries

@HTenkanen
I created the code on my fork
You can visit the difference here
I created the file osmitaly.py and modified the file _init_.py both in the path pyrosm/data
the code loads the (topo) json files on initialization with the information on the names of the regions and provinces (so if anything changes everything is automated) and then offers the data sources.
I believe the resource could be improved by integrating with the code in geofabrik.py
Let me know if it's ok so I can proceed with the pull request


Add instructions to install from conda-forge.

ragna has recently been brought to conda-forge; see this feestock and the package information.
This PR

addresses a TODO in the root's readme to add installation instructions via conda
adds a button to access find the package on conda-forge, imitating the PyPI button

Hi @pmeier ! I attended your workshop at PyData Berlin last week - thank you!
I wanted to get started with ragna and realized it wasn't on conda-forge yet. Hence I brought it to conda-forge. This is a PR to add some information on ragna's availability on conda-forge.

@pmeier thanks for your response!

 Let me ask around if there is a good solution to the problem. I'm sure we are not the first ones to hit this.

I understand. Iirc the way this is usually done is to have two outputs in the conda recipe. For instance, the matplotlib recipe has one output called matplolib, which includes all dependencies as well as matplotlib-base, which includes a barebones set of dependencies.
Should I look into setting this up, tag you in the feedstock PR, and create a follow-up ragna PR once this is settled?

Iirc the way this is usually done is to have two outputs in the conda recipe. For instance, the matplotlib recipe has one output called matplolib, which includes all dependencies as well as matplotlib-base, which includes a barebones set of dependencies.

That is what I got from my sources as well.

Should I look into setting this up, tag you in the feedstock PR, and create a follow-up ragna PR once this is settled?

Yes, that would be awesome. TBH, we should probably have a discussion about the same for our PyPI releases. Not only will it be awkward if conda and pip installs diverge, but also pip install ragna should give you what you need without looking up installation instructions.

Should I look into setting this up, tag you in the feedstock PR, and create a follow-up ragna PR once this is settled?

Maybe hold off on this one. I'll start an issue soon on how we want to do this. I got some conflicting opinions from people that know conda / conda-forge a lot better than me.


Introduce a way for getting operation type w/o having to parse request document twice

To be able to tell if you're running a query, mutation or subscription you need a DocumentNode, but a DocumentNode is being built internally (inside \GraphQL\Server\Helper::promiseToExecuteOperation it looks like - using Parser::parse).
Of course I can get it by invoking Parser::parse() manually, but then the request ends up being parsed twice which isn't very efficient. I'm worried that if the request is very big, this can leave a noticeable performance impact.

You can parse the query string yourself and pass the parsed DocumentNode to the executor.

You can parse the query string yourself and pass the parsed DocumentNode to the executor.

Not a great option, considering much of StandardServer up has to be copy-pasted into a custom implementation (because a lot of helpful methods of GraphQL\Server\Helper are private) just to get this information.

Not a great option, considering much of StandardServer up has to be copy-pasted into a custom implementation (because a lot of helpful methods of GraphQL\Server\Helper are private) just to get this information.

True, it is not that straightforward.
https://github.com/webonyx/graphql-php/blob/5289a5440e0bfb56d883ab0cd57a46b6a97d41fc/src/Server/Helper.php#L284-L290
You can just do:
$helper = new Helper();
$parsedBody = $helper->parseHttpRequest();
$parsedBody->query = Parser::parse($parsedBody->query);

Open to PRs to make the standard server and/or helper more modular and convenient to extend.

True, it is not that straightforward.
https://github.com/webonyx/graphql-php/blob/5289a5440e0bfb56d883ab0cd57a46b6a97d41fc/src/Server/Helper.php#L284-L290
You can just do:
$helper = new Helper();
$parsedBody = $helper->parseHttpRequest();
$parsedBody->query = Parser::parse($parsedBody->query);

Open to PRs to make the standard server and/or helper more modular and convenient to extend.


Update Taskade AI

Thanks for including Taskade! Would love to make a few edits if possible.

Update the description for Taskade to:

Taskade AI is a dynamic productivity suite that enhances team efficiency through AI. Users can build, train, and deploy autonomous AI agents for task management, team collaboration, and workflow automation within a unified workspace. Featuring tools like task and project management, notes, docs, mind maps, and AI chat, Taskade automates over 700 tasks, seamlessly integrating essential functions and transforming real-time collaboration.

Include a few more links for Taskade AI such as

docs
apps
github

Thanks for considering!

Happy to send a PR as well @slavakurilyak


Added LB refs to client_channel

the client channel needs to get a weak reference on the lb_policy for its on_resolver_results_changed callback. Otherwise the LB policy may get destroyed while the resolver hasn't called the callback yet.
This was (seldom) observed during internal testing with internal resolvers.

Is there a reasonable way to add a test for this?

I'll try to devise a way to test this... It's certainly getting exercised by a lot of the other tests already, but presumably not for the path it's trying to address.

I can't come up with any reasonable way to test this, other than the integration/stress tests we have that push things so that we end up with the situation described in the PR's description.

Could you do it by writing a custom LB policy and custom resolver that both have condition variables that allow you to control the synchronization?
May not be worth the effort, though.

The changes in this PR are not needed. While correct, the new weak refs are redundant given the strong one at https://github.com/grpc/grpc/blob/master/src/core/ext/client_channel/client_channel.c#L411
The crash that motivated this fix was actually caused by what #8786 addressed (that PR has in turn been superseded by #8787). Closing this PR.


.pdf Samuel Kelsey: Page 1 Address

Address autofills with former address instead of current address.

It's consistent so I assume this is a naming in .pdf issue and not a coding issue.

I was wrong. Ignore me.


Update documentation files

Update CONTRIBUTING.md
Update the README -> this is not a WIP anymore 🎉

bors merge


[BUG] 7.46.0 workloadmeta failures under load

Agent Environment
7.46.0
Describe what happened:

Crazy user starts Argo workflows that result in 10K+ pods over several minutes
Some nodes end up running 100 pods or more
Agent crashes in multiple ways, probably due to race conditions:

fatal error: concurrent map iteration and map write

goroutine 504 [running]:
github.com/DataDog/datadog-agent/pkg/workloadmeta.(*store).GetKubernetesPodForContainer(0x51e2fc0?, {0xc00111981d, 0x40})
	/omnibus/src/datadog-agent/src/github.com/DataDog/datadog-agent/pkg/workloadmeta/store.go:285 +0x155

or
panic: interface conversion: workloadmeta.Entity is nil, not *workloadmeta.KubernetesPod

goroutine 600 [running]:
github.com/DataDog/datadog-agent/pkg/workloadmeta.(*store).GetKubernetesPodForContainer(0x51e2fc0?, {0xc00114dead, 0x40})
	/omnibus/src/datadog-agent/src/github.com/DataDog/datadog-agent/pkg/workloadmeta/store.go:286 +0x31a

There might be more. I noticed that quite a few failures are not preserved, as the agent seems not to handle perfectly its own logs across restarts.
Describe what you expected:
No crashes
Steps to reproduce the issue:

Hire our crazy user or, otherwise, run hundreds of pods on a single node

Additional environment details (Operating System, Cloud provider, etc):
We are running EKS 1.25, but I suspect this makes little difference.
I saw that this code is different in 7.47.0. There is a mutex now, which might help with concurrency, but is it enough to avoid the nil pointers?

Hi @therc
thanks for reporting this issue, We quickly looked at the code path and the bug seems to be fixed now on the main branch but also in the next version 7.47.0 that we are currently releasing (QA in progress).
 Do you think it can be liveable to wait 7.47.0? knowing that older version (< 7.46.0 are also impacted).

For production deployment we can't recommend to run an RC build.
hopefully final 7.47.0 should be not so fare.

Fixed in https://github.com/DataDog/datadog-agent/pull/16803


Undefined Offset, when making an image prediction

ErrorException  : Undefined offset: 4677996
at /home/ubuntu/environment/vendor/rubix/ml/src/Kernels/Distance/Euclidean.php:43
39|     {
40|         $distance = 0.;
41|
42|         foreach ($a as $i => $value) {

43|             $distance += ($value - $b[$i]) ** 2;
44|         }
45|
46|         return sqrt($distance);
47|     }

Exception trace:
1   Illuminate\Foundation\Bootstrap\HandleExceptions::handleError("Undefined offset: 4677996", "/home/ubuntu/environment/vendor/rubix/ml/src/Kernels/Distance/Euclidean.php", [])
/home/ubuntu/environment/vendor/rubix/ml/src/Kernels/Distance/Euclidean.php:43
2   Rubix\ML\Kernels\Distance\Euclidean::compute()
/home/ubuntu/environment/vendor/rubix/ml/src/Classifiers/KNearestNeighbors.php:273

@webciter
Can you please post your inference script?

Feel free to open the issue again if/when you're ready to provide the requested info
Thank you!


[WIP] Update Travis configuration to fail on warnings/violations

Do not merge yet. Must make sure that this PR is compatible with #80 .
This pull request should make Travis fail on warnings generated by the plugins. Current master has all errors fixed, so we should be able to keep up with all errors quite easily now.
Checkstyle:

https://travis-ci.org/SERG-Delft/jpacman-framework/jobs/125239738#L1291
PMD:

https://travis-ci.org/SERG-Delft/jpacman-framework/jobs/125239739#L1523
Findbugs:

https://travis-ci.org/SERG-Delft/jpacman-framework/jobs/125239740#L1573-L1576
Also adds the container configuration of the new Travis builds.

Fixes #57

I would disagree against merging this pr. Making a build fail for a check style warning devalues the worth of the build in my opinion. Build failures should flag a test failing, indication that something is functioning improperly, making build fail for trivial check style warnings acts a bit like a brittle test.
With a brittle test at some point you can get used to having the build fail, When the build fails the idea is oh it's probably a brittle test again that doesn't matter to much.
The same thing can happen with check style warnings. If a build failure happens for a check style error they will happen more often and can trigger the reaction of regarding a build failure as less important or simply ignored because it's "just a check style warning".
If we deeply care about keeping the repository check style warning clean, other steps can be taken.
In my opinion build failures should be about the tests.
However this is meant as a exemplar project for the students, which gives it some value here.
I wonder wat @avandeursen thinks about this.

Failing a build on the output of a linter such as eslint or jshint is common practice in frontend development. Moreover, we require students to maintain high quality code and we grade them on it. If we do not lead by example, these statements are less valued.
To make sure that the code style is uniform between different developers by using a linter such as Checkstyle, the end result is that the code is more readable. Actively notifying contributors that their code does not conform to the current standards will deter generating warnings over time. If we do not, I think the output is ignored and the plugin remains unused.
In the end, merging a pull request with failing tests or a failing build in general is bad practice.

We require students to maintain high quality code and we grade them on it.

Yes, but code quality is not equal to zero warnings. In fact, we challenge students to discuss the warnings they receive. And often the warning is not even valid, or not pragmatically reasonable to fix. Checkstyle apart, but PMD and Findbugs are imho mostly a learning tool: learn the flaws from your language, and be notified about smelly constructs in your system. These tools can and will however be wrong sometimes. Or you would have to boil down their configurations to the bare minimum.

There are two different topics of discussion in this thread:
Plugin reports a warning
(note: this PR does not change the usage of the plugins)
In the event of a plugin reporting a warning there are three possible actions:

Update the code to resolve the warning

Remove the warning by removing the corresponding rule in the configuration file
Suppress the warning using @SuppressWarnings

It is not possible to ignore the warning. Firstly because it will clutter the report over time, secondly because it requires the maintainers to create a mental map of what warnings should be ignored and lastly because new contributors will not be able to plugin at all. If the contributors sees a long list of existing warnings, he/she will not be able to see if his/her changes are introducing new warnings.
Whether the plugins are correctly configured or are too strict, that is a different topic and we should create a separate issue tracking this discussion if desired.
Actively enforcing the plugins
This PR makes sure that the plugins are actively enforced. As a result, warnings can be observed from the moment they are introduced and resolving them will take considerably less time. Moreover, it lessens the burden of the reviewer. He/she can now rely on the automatic check, whereas previously he/she would need to generate the report themselves and communicate this back to the contributor.

I am fine with reevaluating the configuration of the tools to optimize their usage, but I do think active enforcement of these tools is required to make them useful. If you do not, the tools will only result in an increasing number of maintainability problems on the codebase.

I would not be in favor of having the build fail for a linter warning.
The first reason being that this endorses blindly following a set of rules for which we already know that they will never be perfect, no matter how much you slim down the strictness of the config. There will always be false positives and false negatives that cause students to get more motivated in folowing the linter than folowing common sense.
The second reason is that I think a build should not fail on things that are not mission critical. If you work for a company (or a course, for that matter) and have to stress for a deadline, having your build fail on a Checkstyle warning is at best darn annoying and at worst it encourages developers to ignore build failures (as Liam noted). It in such situations actively hinders developers from adding value to a product and denies them the posibility of making a trade-off.
The third reason I think this is a bad idea is that from an educational perspective, we want to encourage students to think of the warnings they receive, having builds fail on linter warnings does not teach them anything at best, and at worst that the linter is some holy tool never to be ignored. In my opinion having a build failure for this is only suitable in some cases when developers are experienced enough to know the reasons behind a certain configuration of the linter.

Given the above discussion, I will close this issue. I do want to point out that failing CI builds is best practice on the open source web development community. Given that a significant portion of students will eventually join the community, they should be aware that these practices exist.


Print Fibonacci series without recursion

Description
Input  : 5
Output : 0 1 1 2 3

Program added successfully :tada:
Thanks for your contribution :hugs:


Service worker

Reopening PR #87, which was closed in the big dist refactor.
Fixes #6
To test it, edit index.html and set useServiceWorker = true. Then, use the Application tab in Chrome to see the service worker register. You can then check the "Offline" button and refresh to see it working offline.
Note that as of right now, the master branch isn't very useful offline, but if you include my fix for #80, users could go to iplayif.com, click the browser's "install" button to install it locally, and use that to play locally downloaded games offline.
Also note that we're dropping serviceworker.js in the same directory as the index.html file, aka the root directory, because otherwise it doesn't work.
To learn about service workers:

Do Google's free Udacity web course. (You can skip the last bit about IndexedDB.) https://www.udacity.com/course/offline-web-applications--ud899
Read my blog post https://redfin.engineering/service-workers-break-the-browsers-refresh-button-by-default-here-s-why-56f9417694 (linked above) and its corresponding part 2 https://redfin.engineering/how-to-fix-the-refresh-button-when-using-service-workers-a8e27af6df68
Rewrite my service worker code from scratch, fixing bugs as you go (and feel free to ask me anything you like). It's only a few dozen lines, but there are a lot of weird failure cases (which you'll encounter while working on the Udacity course); by the time you could write this PR yourself, you'll be ready to merge it.

The server migration seems to have gone ahead successfully, so I'll start moving on this now.


Jake's 2nd last pull

Edits up to line 135 with some of the intl affairs contributions but more to make if there is time

Will do. Sorry for the delay and thanks
Envoyé by Jake Hirsch-Allen from +16472629202

From: Glen Weyl @.>
Sent: Sunday, March 24, 2024 2:58:34 PM
To: pluralitybook/plurality @.>
Cc: jakehirschallen @.>; Author @.>
Subject: Re: [pluralitybook/plurality] Jake's 2nd last pull (PR #815)
@GlenWeyl requested changes on this pull request.
This has conflicts and has come after the deadline, so will be community reviewed. As such, to receive credit you'll need to file and get funded an issue in Gov4Git/GitRules that this then resolves.
—
Reply to this email directly, view it on GitHubhttps://github.com/pluralitybook/plurality/pull/815#pullrequestreview-1956629541, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAILL6AWOR7H3VY33RCROQ3YZ4O5VAVCNFSM6AAAAABFFWSQ4KVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTSNJWGYZDSNJUGE.
You are receiving this because you authored the thread.Message ID: @.***>


Haplotype filters implementation

Coverage increased (+12.8%) to 67.361% when pulling 0ed117a2daca750ceeb4bbb9e701bcb81cdafa08 on dgs_haplotype_filters into d6236cd7b3fb5350c61e741763a775cb4fa110c2 on master.

Coverage increased (+12.8%) to 67.361% when pulling 0ed117a2daca750ceeb4bbb9e701bcb81cdafa08 on dgs_haplotype_filters into d6236cd7b3fb5350c61e741763a775cb4fa110c2 on master.

Coverage increased (+12.8%) to 67.361% when pulling 0ed117a2daca750ceeb4bbb9e701bcb81cdafa08 on dgs_haplotype_filters into d6236cd7b3fb5350c61e741763a775cb4fa110c2 on master.

Coverage increased (+12.002%) to 63.636% when pulling ff5a8b964929705f0484f01c2c5cc9448eb8ab1b on dgs_haplotype_filters into 8f047eb418bd69be322832acca538db178e4e549 on master.

Coverage increased (+11.7%) to 63.348% when pulling ff5a8b964929705f0484f01c2c5cc9448eb8ab1b on dgs_haplotype_filters into 8f047eb418bd69be322832acca538db178e4e549 on master.

Coverage increased (+11.4%) to 63.063% when pulling bb04b86c5974aab0c184ffdd2203dcee5b2447d4 on dgs_haplotype_filters into 8f047eb418bd69be322832acca538db178e4e549 on master.

Coverage increased (+11.3%) to 62.896% when pulling fc449036e49070e33fc7132f90eecdb7503802df on dgs_haplotype_filters into 8f047eb418bd69be322832acca538db178e4e549 on master.

Coverage increased (+11.3%) to 62.896% when pulling 45137d5aaed38c37a4a4b8132c11bb627cc34fe2 on dgs_haplotype_filters into 8f047eb418bd69be322832acca538db178e4e549 on master.


Add extra text snippet for error page

The error page was using the snippet for the "bad hours" page which is not
correct for the general error. This should clarify the intention of the error
page
How is the policy with adding new text snippet? Do I need to update all the other language files too?
See https://github.com/apereo/cas/issues/2958.

 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.Oliver Hinckel seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Errors due to wildcard characters in path names

Attempting to compile pc-print-deploy-client[papercutserver.mydomain.com].msi to an intuenwin file causes New-IntuneWin32AppPackage to fail with a "file not found" error. This unfortunate naming convention chosen by PaperCut is problematic because the square brackets in the file name are wildcard characters in PowerShell. See about_Wildcards.
This can be fixed by changing instances of Test-Path -Path to Test-Path -LiteralPath wherever it occurs in various IntuneWin32App module files.

This sounds like a reasonable and easy improvement, I'll add that to 1.4.2. Thank you for reporting!

This will be fixed in 1.4.2 where both -Path and -LiteralPath will be tested to ensure compatibility.

Thank you. LiteralPath will most likely work properly. From what I could see, none of the Test-Path calls were intended to iterate over a set of files that might be returned by a wildcard in the path name. I didn't do a thorough review for other cmdlets that might accept a LiteralPath parameter vs. Path, but I did test the module myself with Test-Path -LiteralPath substituted for Test-Path -Path, and it worked with no problems. I certainly appreciate your efforts producing and maintaining this module.

I was thinking if some people were using virtual paths for some reason. Not sure if that even works, but I feel it was best to keep it for potential compatibility issues. Thanks!

Yes, for backward compatibility, it makes sense to keep the -Path parameter and add another parameter set with -LiteralPath. Thanks.


WIP docker: splits the invenio dockerfile

BETTER Splits the invenio dockerfiles in one generic without code
and a dockerfile for a basic Invenio installation.

Moves the invenio files from /home/invenio to /opt/invenio
and the static files (bower) to /opt/invenio_static.

Moves all code and also packages that get installed in editable mode
from /code to /src

Installs vim-tiny and adds a symlink it to vim.

Outputs more information at creation time and bower install.

Adds libjpeg-dev for the pillow jpeg support.

Signed-off-by: David Zerulla<EMAIL_ADDRESS>

It might make sense to move the bower downloads outside of the docker_boot.sh script?
Usage of the invenio-base image can be seen in PR https://github.com/CERNDocumentServer/cds/pull/51.

@ddaze the base Docker image should probably go to Invenio-Base package.

Okay, and there than in the sub folder docker-base?
Or even as a own repository?

Is not longer relevant. (See other Docker improvements)


Running "fix" on an empty module fails

Sister ticket to https://github.com/com-lihaoyi/mill/issues/4006

A project with just this build.mill (using Mill 0.12.2) dies on ./mill __.fix.
package build

import $ivy.`com.goyeau::mill-scalafix::0.4.2`
import com.goyeau.mill.scalafix.ScalafixModule
import mill.scalalib.SbtModule

object main extends SbtModule with ScalafixModule {
    def scalaVersion = "2.13.15"
}

It might seem strange not to have any sources in a module but I have a couple of "aggregation" modules that simply list other modules that they depend on. This used to work fine (pre 0.12).
Adding a single source file makes the problem go away ... but then I have a useless source file. :-)

CC @joan38 , not sure how easy this is to fix but it seems like it shouldn't be too hard


System environment parity

In preparation for #5 and #18
Ubuntu 20.04 is currently the Ubuntu LTS version used by GitHub, Heroku, and Heroku's managed Postgres instance. PostGIS is an extension to PostgreSQL used by GeoDjango. PostGIS and GeoDjango both depend on some scientific libraries:

GDAL
PROJ
GEOS

The combination of these dependencies can have slightly different behaviors when different versions are used. We can reduce these inconsistencies by switching to Ubuntu 20.04 for our runtime environment.


Paste from Google Docs

I'm addressing a particular use case where I should paste content copied from a generic Google Docs document.
So far, on a Mac with OS X 10.11 with Chrome 50 whenever I try to do so, somehow the whole document get styled 'BOLD'.
If I try to do the same, but going through the "Notes" app (copy > paste > copy > paste), then the content looks alright.
I'm not sure where I should look at while trying to address such issue, any idea?

This is an issue you should probably handle yourself, it seems out of scope for this kind of a library to handle the nuances of Google Docs' clipboard handling. If you look at the clipboard content coming from Google Docs (set a breakpoint inside of a handlePastedText handler) you'll see that Google Docs surrounds its entire HTML structure in a <b> tag, which Draft technically handles correctly. I have an in-house solution that I'm planning on open-sourcing soon, but the gist of it is you need to process the HTML to extract the inner HTML elements and then use Modifier to insert the result into the document.

Google Docs surrounds its entire HTML structure in a <b> tag

why would it do that… @_@

¯\_(ツ)_/¯ not sure why the wrapping in a <b> tag, but all of their blocks are styled inline, so a bold chunk of text is a <span style="...;font-weight:700;...">, etc. Writing the parser was a party

Thanks @aem, I wasn't sure what was happening, I'm having a look at the solution you're suggesting.

As followup, today I open-sourced the solution that I built internally. Doesn't cover all cases, but should be enough to get started. Contributions welcome :)

This worked for me
`handlePastedText = (text, html,editorState) => {
const blocksFromHTML = convertFromHTML(html.replace(/<b/g,'<p').replace(/</b/,'</p'));
const newState = ContentState.createFromBlockArray(
blocksFromHTML.contentBlocks,
blocksFromHTML.entityMap,
);
  this.onChange(EditorState.push(editorState, newState, 'insert-fragment'))
  return true

}`


Using hotkey pollutes current file with extraneous character

When using the alt+] hotkeys, the file that is currently selected will get polluted with the following character: ‘ It seems to me it's because the hotkey is not being captured?

Thanks for the report Amir. I noticed this too and traced it down to a bug in a core package (atom/atom-keymap#205) a while ago. Unfortunately I haven't seen much activity in a while on this issue.
As a workaround, I believe using a different binding that doesn't involve alt should work. The readme includes an example of how to do this.


Add no results content for about GiT events page

Trello card
Trello-3911
Context
We currently don't display any specific message when there are no Get Into Teaching events left for the current year.
Add content for when there are 0 GiT events.
Changes proposed in this pull request

Add no results content for about GiT events page

Guidance to review
Do we want to automate the year so it changes from 2023 to 2024 etc at a certain time of year?

Mobile
Desktop

Looks good to me @ethax-ross if @philspray and @gazcarr are happy with it (I've left one minor comment for @philspray)
You asked whether it would be worth automating the year - it is a bit more complex that this as we have Autumn, Spring and Summer programmes so we'd have to update seasons as well. Is it worth it or do we just do a manual change for now?


Bit shaving results in non-layout independent History?

The GMAO-OPS @rlucches  team reported that the GEOS-IT system was giving different diagnostic output at different layouts (but the model itself is layout independent as far as the checkpoints) but @lltakacs traced it down to the bit shaving as the culprit.
Indeed, I've been able to reproduce with "main" branch of the GEOSgcm fixture as of 1/20/2023 (that's when model I just ran was cloned and built). At C48, I have collection that is output on the native grid of the fields, the fields are 2D, so there's no processing. If I turn on bit shaving I get different results at 1x12 and 4x48 for the collection at the first write. If I turn off bit-shaving, the collection is layout independent.
I'll investigate; I'm perplexed as the bit shaving should be an element wise operation, just not seeing how the layout could possibly matter, but apparently it does.

Part of the scheme involves extracting the average before the bit shaving.   I suspect that this is the culprit.
But surprised this is the first time it has shown up.     Guess our usual tests only look at checkpoints.

Ok, as @tclune pointed out, the bit-shaving algorithm that we still use that was implemented by Arlindo a long time ago, is a little more complicated than I realized (I have not looked at it in at least half a decade) and maybe doing some for a math to prevent bias after the shaving, in which case if this is done on the distributed arrays may be the issue. I will confirm this by seeing if doing on the bit shaving on the gather trays on the server side fixes this, although this brings up other thorny design issues we will have to address if indeed solves the problem.

@rlucches @rtodling @lltakacs
Indeed @tclune was right it is more complicated and not just a element by element operation, and here I have thought for a decade our bit shaving was some really naive throw away some bits thing.
I've confirmed that if I hack the bit shaving over on the server when the data is gathered it seems to fix any bit shaving related layout problem. (rather than do the bit shaving on the History/griddedio side when the data is still distributed). Now the trickier part is doing this in a clean way in the current history/griddedio/pfio output server system we have. Hopefully this is not too bad to shift this over to the server. I will let everyone know when I have a solution and I imagine whatever I do in MAPL develop will need to be backported if that GEOS-IT is using that MAPL 2.8.0.X series where we have been collecting patches as needed to avoid forcing a bigger number update.

@rlucches @rtodling @lltakacs
I figured out how with a few MPI calls to make the bit shaving layout independent. I'll shortly make PR into MAPL develop in our development.
Is there an older MAPL tag I should back port this into for the GEOSadas or any other older system?


TrIgger Control Submit make server error

Hello
Raspberry pi5 8Gb
raspiCamSrv V2.9.2 seems to be an error on window Trigger __ Control_ Submit  than
Bad Request
The browser (or proxy) sent a request that this server could not understand.
maybe error between control and images request ?

Hi,
thanks for reporting this issue.
It is fixed in V2.10.0

Hi,
tested with V2.10.1 it works again
thanks for the fast resolving 👍


[WIP] SSA construction on the fly

In order to feed WebAssembly as an input to Cretonne and produce native code from it, we need to translate WebAssembly into Cretonne IL. One of the challenges it poses is SSA construction (WebAssembly is not in SSA form).
Here is a proposal for an SSA construction API that can be invoked on the fly while constructing the Cretonne IL control flow graph, block by block.

I wonder if it is necessary to make a distinction between Block and Ebb? It seems to me that an algorithm concerned with building SSA form will only ever care about basic blocks that are at the top of an EBB. An internal basic block will never need a phi.
The EntityMap and SparseMap data structures are somewhat specialized. They are based on arrays indexed by the EntityRef, so they use a fair bit of memory. They are best used at the top level, like you are doing in struct SSABuilder. Using them in struct VariableData is problematic, I think, since you will have many instances of that. Since you are just hashing out the interface now, you could just use standard library data structures in struct VariableData for now, and I can nag you about an efficient representation later.
About the Variable entity reference: Somebody using this library to build SSA form will probably already have their own representation of local variables. For example, a WebAssembly translator will have local variable numbers. Since you are allocating the Variable references in make_var, the library user is forced to maintain a mapping from their own variable representation to yours.
An alternative would be to allow the user to provide their own Variable references by making it a generic parameter:
pub struct SSABuilder<Variable>
    where Variable: EntityRef {

You can then use the user-provided Variable references to index into an EntityMap or SparseMap. This is very similar to how you are using the user-provided Ebb references already.

Concerning the distinction between Block and Ebb: yes, we need it. Indeed, imagine you use_var in a basic block b and there is no definition of the variable inside b. Then you will proceed to search for a definition in the predecessors of b. Let pred be a predecessor of this basic block. If pred is an Ebb, it might contain the definition we're looking for but this definition could be after the instruction jumping to b, and in that case we don't want to take it into account.
That is the reason we need Block which contains more information than Ebb. Nevertheless you're right, an internal basic block of an Ebb will never have a phi because it has an unique predecessor.
Thanks for your advice on the data structures, I'll proceed as you said. Very good idea for switching Variable to a module parameter, it does implement more efficiently what I was seeking.

I had an idea: using the SSABuilder API is quite cumbersome for now, but actually a lot of the calls related to instructions arguments and results could be hidden by an enhanced InstBuilder API parametrized by Variable, the representation of variables in the original language.

I like your idea of making an InstBuilder with SSA construction built in. That sounds fun :-).

So now I need to optimize my data structures and create a optimized representation for pairs of (Block, Value), (Block, Inst) and (Variable,Value) where Block, Inst, Variable and Value have the EntityRef trait.
The naïve way of doing that would be to have three new opaque refs BlockValuePair, VariableValuePair, BlockInstPair and 3 associated EntityMaps, so that we can store the new opaque refs into EntityList inside each BlockData or VariableData. Is it fine do to that or is it too much memory and reference allocation?

I think it would be good to collect some real-world data before we try to optimize anything.
That means landing this PR as is and building a WebAssembly frontend.

Outdated, closed in favor of https://github.com/stoklund/cretonne/pull/97


"Mission control" protocol plugin

We should have a protocol plugin which allows the bot to communicate with authorized users over HTTP. It should be able to serve a website, adjust settings, and interact with plugins.

Initial work here: https://github.com/TheDiscordian/onebot/commit/33ce45243c547448db53c9629bed051debbafba5

While I would love for this to have (many) more features, this issue is complete.


waitForSelector("…:focus") doesn’t resolve on focus change

Steps to reproduce
Tell us about your environment:

Puppeteer version: 7.0.1
Platform / OS version: NixOS
URLs (if applicable):
Node.js version: 14.15.4

What steps will reproduce the problem?
const puppeteer = require("puppeteer");

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.evaluate(() => {
    const e = document.createElement("input");
    document.body.append(e);
    setTimeout(() => e.focus(), 1000);
  });
  await page.waitForSelector("input:focus");
  await browser.close();
})();

What is the expected result?
waitForSelector("input:focus") should resolve when focus changes to the input element.
What happens instead?
waitForSelector("input:focus") hangs and times out. I think this is because it’s only listening to DOM mutations, which a focus change is not.
If I await page.waitForSelector("input:focus", { visible: true }) instead, that resolves as expected.

Still reproduces in Puppeteer 15.1.0.

Still reproduces in Puppeteer 17.0.0.

It looks like it does not work because Puppeteer is using the mutation observer to determine when to re-query things. The workarounds are to use await page.waitForSelector("input:focus", {visible:true}) which should switch to RAF-based polling to await page.waitForFunction that polls are regular intervals.


Fix issues with doc/code/manifest generation

Sometimes we had to run "generate" and/or "manifest" make targets twice
in order to have the doc generated. This should fix it.
Also, use the existing go-get-tool function to get crdoc, to unify with
existing tooling download method

thanks @mariomac
/approve


GestureState helper

failing test to make green

I'll let @carson-katri sign off on this next week


Brush doesn't properly work

Expected behaviour:
It will draw a line thicker than a pixel, will be able to change colour and size.
Actual behaviour:
Draws two parallel lines both about pixel size.

the colour and thickness of the square and  the line should be the same

  // drawing things
            sf::Uint8 *pixels = new sf::Uint8[
                int(
                    (brush_size * brush_size)
                )
                * 4
                ];
            // for (int i = int(brush_size);i > 0; i--)
                bckgrnd.update(
                    pixels, unsigned(brush_size), unsigned(brush_size), //
                    unsigned(mousepos.x) + 1, unsigned(mousepos.y) + 10);

code related to the issue

Going in the right direction I guess? now it just shows grey. Sometimes with different opacity.

Line's R,G,B values

218,0,0
184,0,0
107,0,0
37,0,0

All of these lines are supposed to be red with the rest of the color values set to 0 (alpha channel isn't even included in the array, so I don't why doesn't it even show some red).
            int  pixel_arr_sz=(brush_size * brush_size) * 4 ;

            sf::Uint8 pixels[pixel_arr_sz];
            for (int i = 0; i != pixel_arr_sz; i++) {
                pixels[i] = brush.getFillColor().r;
                pixels[i + 1] = brush.getFillColor().g;
                pixels[i + 2] = brush.getFillColor().b;
                if (brush.getFillColor().r > 0)
                    pixels[i + 3] = brush.getFillColor().r;
                if (brush.getFillColor().g  > 0  )
                    pixels[i + 3] = brush.getFillColor().g;
                if(brush.getFillColor().b > 0)
                    pixels[i + 3] = brush.getFillColor().b;
            }

            if ((float(mousepos.x) < bckgrnd_box.getSize().x) &&
                (float(mousepos.y) < bckgrnd_box.getSize().y)) {
                bckgrnd.update(pixels,               //
                               unsigned(brush_size), //
                               unsigned(brush_size), //
                               unsigned(mousepos.x) + 1,
                               unsigned(mousepos.y) + 10);
                bckgrnd_sprt.setTexture(bckgrnd);
            }

But the size thing works, so that's good

Also when at least one of the RGB values becomes 255, the gray doesn't even output.

After some testing it turned out not to be a transparency issue, but the colour output issue.


Add tests to SwiftPM sample

I know this is wrong, but I had started this last week and ran into some weird errors:

Task :app:linkTest FAILED
Undefined symbols for architecture x86_64:
"__T07GreeterAACABycfC", referenced from:
_main in main.o
"__T07GreeterAACMa", referenced from:
_main in main.o
ld: symbol(s) not found for architecture x86_64

I think this means I'm not getting the transitive dependencies from the binary-under-test.
I also haven't looked into how to update the Package.swift file to include the new tests.

This should be mergeable once https://github.com/gradle/gradle/pull/3297 is merged and a nightly has been released with those fixes in it, and we use the nightly from the gradlew for these samples.


Upgrade version.pitest-git 1.0.10 -> 1.0.11

This PR contains the following updates:

Package
Type
Update
Change

com.groupcdg:pitest-git-plugin
build
patch
1.0.10 -> 1.0.11

com.groupcdg:pitest-github-maven-plugin
build
patch
1.0.10 -> 1.0.11

com.groupcdg:pitest-git-maven-plugin
build
patch
1.0.10 -> 1.0.11

[ ] If you want to rebase/retry this PR, check this box

Suggested commit message:
Upgrade Pitest Git plugins 1.0.10 -> 1.0.11


Add Twitter Sentiment Analysis Project

I would like to propose adding a new project focused on sentiment analysis of Twitter data under advanced level in machine learning. It will demonstrate how to analyze public sentiment on various topics by processing live tweets.

I am the mentor of this project.
Hello @rishikaa1
I appreciate your pull issue Can you describe little bit and give screenshots!!

@SakiraAli1115 hello. this project will implement a sentiment analysis model for classifying tweets into three categories: positive, negative, and neutral. it will utilize the Sentiment140 dataset from Kaggle to analyze public sentiment through tweets, instead of relying on the Twitter API for live data, which has become more restrictive these days.
I will build and train a logistic regression classifier to predict tweet sentiments, along with providing performance metrics and visualizations for added details and interpretation.
Sample screenshot:

@rishikaa1 Tell me where you can contribute?
@Kushal997-das kindly assign this issue!!!!

@SakiraAli1115 i want to contribute this project to the advanced level under machine learning.

@rishikaa1 like under GSSoC'24 extended edition and hacktoberfest?

@SakiraAli1115 yes

@SakiraAli1115 hey, i was thinking if i could implement this same project using deep learning to achieve better accuracy and add both models to the repo if assigned?

@rishikaa1 We will determine whether it falls under advanced or intermediate. For now, please mention which program it is under, as requested by Mentor @SakiraAli1115 . Kindly reply there first.

@Kushal997-das i have replied that i want to contribute under GSSoC'24 extended and hacktoberfest.

@Kushal997-das @SakiraAli1115 could you tell me under which section in machine learning should i add this project?


[NOP]sort two json

we also need to update Makefile to parse package.json differently... not worth it


integration test timing issues

Had to resolve a couple of timing based issues with the integration tests for Redis OM. Two primary problems
1: In a previous PR I fixed an issue where if a script was reloaded properly, the mock sha that we use for our unit tests was wrong, it appears that I missed a couple of them
2: The timing from #206 was slightly off - yes the "we started out with 5000 ms timeout, delayed a second so we should have less than a 4000 ms timeout" logic seems sound, but Task.Delay only guarantees accuracy to the resolution of the system clock, so it was a few millisecond off, I added some extra buffer so hopefully that shouldn't be an issue anymore
I've run the tests 10 times without a failure (was failing at least 1 / 3 times before) so hopefully this fixes it 🤞


It is not possible to install on a server installed on a docker version of the pi

What version of Music Assistant has the issue?
latest
The problem
When trying to install the Music Assistant server using docker on a pi4, an error is received:
no matching manifest for linux/arm/v8 in the manifest list entries
How to reproduce
Docker installation on pi 4
Relevant log output
No response
Additional information
No response
What version of Home Assistant Core are your running
2023.5.4
What type of installation are you running?
Home Assistant Container
On what type of hardware are you running?
Raspberry Pi

Are you running the 64bit version of the OS
.

Yes.

If you are using the latest tag that isn’t working. You need to try something  like
ghcr.io/music-assistant/server:latest@sha256:519de4ae6fd774646091a50014eb2da506daf1b0e2b8640e515a4046cbc56551

I managed to install, but the server does not work and the log is empty

It takes a few minutes to start but if it isn’t working you will need to supply more info about log entries in MA and HA. Exactly what environment you are installing into and how. Whether the addon shows that it has started and whether it continues to show that it is running. Whether any error messages are shown when you attempt to open the UI. Screenshots can help.

Installed in docker on pi4
The docker is active but not working
The docker log is empty
Trying to access the MA interface using address <IP_ADDRESS>:8095 and there is no access, does not work.
I didn't get to the stage of connecting to HA, so the log is not relevant

How much RAM have you allocated to the container? You need 2GB minimum

The container is not limited.  There is 7GB RAM available
music-assistant-server:
    container_name: music-assistant-server
    image: ghcr.io/music-assistant/server:latest@sha256:519de4ae6fd774646091a50014eb2da506daf1b0e2b8640e515a4046cbc56551 # <<< Desired release version here
    container_name: music-assistant-server
    restart: unless-stopped
    # Network mode must be set to host for MA to work correctly
    network_mode: host
    volumes:
      - /home/pi/docker/docker-mounts/music-assistant-server/data:/data/
      - /home/pi/docker/docker-mounts/ha/media:/media-ha/

Ok looking back at the error message seems like some sort of compatibility issue. Let’s see what @marcelveldt thinks…

I think think this is somewhat the same issue as what has been reported by someone else where the docker container would simply not start or crash at the beginning. This is reported fixed in beta36 so please give that version a test drive and let us know

How do I install beta35?  I didn't find any mention of it.

music-assistant-server:
container_name: music-assistant-server
image: ghcr.io/music-assistant/server:2.0.0b35

Unable to install
Pulling music-assistant-server (ghcr.io/music-assistant/server:2.0.0b35)...
2.0.0b35: Pulling from music-assistant/server
ERROR: no matching manifest for linux/arm/v8 in the manifest list entries

Try b36

ERROR: manifest unknown

Actually sorry I got ahead of myself we are only up to 35

Very strange, tak 2.0.0b35 is available...
https://github.com/music-assistant/server/pkgs/container/server

What did you do before when you said you managed to install? Please completely uninstall then try whatever that was again and check which version you are running (should be beta 35) and let us know what happens

Maybe arm v8 is not auto matched with arm64 ?
Maybe try with the direct tag instead: docker pull ghcr.io/music-assistant/server:38af96a5@sha256:b91647df31baa72ecdf6af42130c8997c6bcac7c5acfe25d241a3258cd0e0248

Maybe arm v8 is not auto matched with arm64 ? Maybe try with the direct tag instead: docker pull ghcr.io/music-assistant/server:38af96a5@sha256:b91647df31baa72ecdf6af42130c8997c6bcac7c5acfe25d241a3258cd0e0248

In this way it works

But that doesn't solve the problem.  The docker does not work.

@OzGav why did you close?  The docker does not work

Because you said “in this way it works”. Please provide more info about what does not work. Does anything appear in the log? Does the container start?

The tank is installed, but does not rise.  Blog has nothing listed

the problem is still there...

Not sure what to tell you as many others have this working. Look at your docker config. Maybe try asking in a docker specific forum?

Not sure what to tell you as many others have this working. Look at your docker config. Maybe try asking in a docker specific forum?

The problem is not only with the installation, even when I manage to install the docker does not work.

I managed to install the latest version: image: ghcr.io/music-assistant/server:d5e7b861@sha256:b23026b8083fb298b48bac9a9c98c0531d809321780ab7132e44bae171f1e29c
The docker does not come up.

What OS are you running on the Pi? Maybe that is the problem…? Again this seems not to be a MA problem…

This issue is stale and will be closed soon without more info

Docker is installed but the service does not start.  Docker log: No log line matching the '' filter


MaxPool op resolved as Aten OP

I created a small model training script, to test out maxpool gradient op for OneDNN EP, and the model definition below was used. But for some reason, the maxpool was resolved to Aten Op in the onnx graph. Is there a way to force torch-ort to use maxpool instead aten op? (maybe by disabling use of aten ops?)
class Net(nn.Module):
    def __init__(self):
        super(Net, self).__init__()
        self.conv1 = nn.Conv2d(1, 10, kernel_size=5)
        self.conv2 = nn.Conv2d(10, 20, kernel_size=5)
        self.maxpool1 = nn.MaxPool2d(2)
        self.maxpool2 = nn.MaxPool2d(2)
        #self.conv2_drop = nn.Dropout2d()
        self.fc1 = nn.Linear(320, 50)
        self.fc2 = nn.Linear(50, 10)

    def forward(self, x):
        x = F.relu(self.maxpool1(self.conv1(x)))
        x = F.relu(self.maxpool2(self.conv2(x)))
        x = x.view(-1, 320)
        x = F.relu(self.fc1(x))
        x = F.dropout(x, training=self.training)
        x = self.fc2(x)
        return F.log_softmax(x)

looks like max_pool2d is registered as AtenOp - onnxruntime/orttraining/orttraining/python/training/ortmodule/_custom_op_symbolic_registry.py
I am not aware of custom setting to disable/enable the registry. I'll check around.
Perhaps you can disable it from the code, and build it to try?

Yeah, I can give that a try.

I tried disabling the code, but it still seems to be registering maxpool_2d as an ATen Op. Is there a reason why it was designed to be registered as ATen op and not maxpool of onnx?

@chethanpk I just tried this on my end as well. If I comment out this code in my local pip directory, I can avoid generating the Aten nodes that you're seeing in your graph. Here is the sample I am using (from you example):
import torch.nn as nn
import torch.nn.functional as F
import torch
from onnxruntime.training import ORTModule

from onnxruntime.training.ortmodule import DebugOptions

class Net(nn.Module):
    def __init__(self):
        super(Net, self).__init__()
        self.conv1 = nn.Conv2d(1, 10, kernel_size=5)
        self.conv2 = nn.Conv2d(10, 20, kernel_size=5)
        self.maxpool1 = nn.MaxPool2d(2)
        self.maxpool2 = nn.MaxPool2d(2)
        #self.conv2_drop = nn.Dropout2d()
        self.fc1 = nn.Linear(320, 50)
        self.fc2 = nn.Linear(50, 10)

    def forward(self, x):
        x = F.relu(self.maxpool1(self.conv1(x)))
        x = F.relu(self.maxpool2(self.conv2(x)))
        x = x.view(-1, 320)
        x = F.relu(self.fc1(x))
        x = F.dropout(x, training=self.training)
        x = self.fc2(x)
        return F.log_softmax(x)

x = torch.randn([1, 1, 30, 30], dtype=torch.float32)
net = ORTModule(Net(), DebugOptions(save_onnx=True, onnx_prefix='test'))
out = net(x)
print(out)

Here is the graph I get:

I actually did comment out the same part of the code. Let me try a fresh rebuild of the wheel.

Rebuilding the wheel worked, thanks.


Supplementary Views Rendering on Wrong Days

[X] I have verified there are no duplicate active or recent bugs, questions, or requests
[X] I have verified that I am using the latest version of CVCalendar.
[X] I have given my issue a non-generic title.

Expected Behavior
Every day prior to the current one should have a blue circular supplementary view, and all views past today's date should not have any view at all.
Current Behavior
The days that actually have the supplementary view applied are wrong. When trying to apply the supplementary views to days previous to the current one, this is the result that I'm getting:

Also, when I scroll between months, it crashes on a nil dayView value. This does not happen sans supplementary view.
Sidebar: I have also noticed that when I apply the supplementary view to -all- dayViews, I still get weird behavior. This is especially noticeable when I scroll from one month to another. Example with supplementary view applied to all dayviews:

Next Month:

Possible Solution
Hard to say. Obviously, the supplementary views are being applied to the day views incorrectly. When trying to apply the sup view to past days, certain days of the week are always given a supplementary view no matter what.  The columns that are incorrectly given a supplementary view are consistent across simulators.
Steps to Reproduce (for bugs)

Using pod version 1.2.9. Besides the supplementary views, the calendar is working as intended. My basic setup uses the .Month presentation mode and the first weekdays is set to .Sunday.

I have set up the supplementary view delegate methods as follows:

    func supplementaryView(viewOnDayView dayView: DayView) -> UIView {
        let view = UIView()
        let sideLength = min(dayView.frame.width - 10,dayView.frame.height - 10)
        view.frame.size = CGSizeMake(sideLength, sideLength)
        view.center = dayView.center
        view.layer.cornerRadius = sideLength / 2
        view.backgroundColor = .lightBlue()
        view.clipsToBounds = true
        return view
    }

    func supplementaryView(shouldDisplayOnDayView dayView: DayView) -> Bool {
        if dayView.date.convertedDate() < NSDate() {
            return true
        }
        return false
    }

Note: I added an NSDate extension to make it comparable, but this is not affecting the bug in any way.
Context
I am trying to add a supplementary view to only particular dayViews. Namely, I would like all days prior to the current date to have a small blue circle around it (much like the circleview used for dots and selections, but with a different color).
Your Environment

Version used (Cocoapods spec): 1.2.9
Device used:: Reproduced bug on 5, 6, 6s simulators
Physical device (y/n):  No
Link to your project (if available): Private Repository

Here's a small update:
It looks like the application of supplementary views on weeks / months is off.
I tried adding a view to only a specific month, like so:
 func supplementaryView(shouldDisplayOnDayView dayView: DayView) -> Bool {
        let date = CVDate(date: NSDate())
        if dayView.date != nil {
            if dayView.date.month == date.month {
                return true
            }
        }
        return false
    }

However, when run, this is the current month:

And the 'next month' is:

For some reason, the supplementary views are being applied in an 'every-other' type fashion, since days that should have a supView on the current month instead have that view applied to the next month.

I had the same problem and I tried to use the fix made by "gregazevedo", changing the "    insertSubview(preView, atIndex: 0)" for the "weekView.insertSubview(preView, atIndex: 0)", and it worked.

@nunesdennis Would you be so kind to submit a PR? This looks like a serious issue to me, so we should fix it asap.

I am not sure if it works in every situation, but I just got the fix from here "sup view frame bug fix #247" , made by @gregazevedo, and I didn't have time to test it very well (I would recommend @gregazevedo to retry the PR in case there is anything else on his fix)


Opus support

This PR should add basic opus support. This however does not work as the client will not output anything.
I figure that this is due to a problem in node-opus as node-opus as well creates empty output.
Even if this is not working it might still be usefull.

Does node-opus create empty output though? It creates non-ogg .opus output, yes, but when run through encoder and then decoder it does create proper pcm output, right?
That's what we should see here too. Mumble encodes opus, node-mumble decodes opus and then streams the PCM out. So yes, it should be noisy and not perfect, but there should still be audio. Will test this in an hour or so when I get off work.

Yeah please have a look at it I do not understand as much of this as you do.

Thanks for the base! Ended up rewriting quite bit of the code, but the original PR acted as decent starting point.
It feels like there's still some sound quality issues with the implementation - not really sure what would cause that. Mind you my own tests have been mainly with the loopback and sin examples.
Could be something to do with the sample rate, jitter buffer or so. Oh well, at least the Opus somewhat works now. Will take a look at the other issues later.

Thank you.


Hyprland crashes after plugin finishes building.

Whenever the plugin finishes building, Hyprland crashes and have to force reboot.
This happens only on the initial build.
Steps to reproduce.

Build Hyprland.
Launch Hyprland from tty.
Build plugin. hyprpm update
Crashes to tty Just after plugin finishes updating.

Unsure if this is plugin specific or Hyprland but i've attached a crash report.
hyprlandCrashReport156445.txt

Yeah, that has solved the crash for me. Cheers!


Update the "Closed date"

The "Closed date" of task is used in the calendar view which is good. However, I often forget to close a task just when it is finished. Therefore I can't use the calendar view to remember when exactly I did a task.
It may be useful to add the possibility to update the "Closed date" on closed tasks. In the "Update task" view for example, or near the "Start date, Time estimated, ..." in the header of the task view, or anywhere else.

Duplicate with #419


Dependency updates: Spring Boot 3.0.5, Spring Data Commons 3.0.4

Description
Dependency updates: Spring Boot 3.0.5, Spring Data Commons 3.0.4
Issues Resolved
N/A
Check List

[ ] New functionality includes testing.

[ ] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[X] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@dblock @dlvenable  please need your review


Adjust RpcLocking test contention to avoid test being flacky

Description
Checklist

[ ] Code compiles correctly
[ ] Tests for the changes have been added
[ ] All tests passing
[ ] This PR change is backwards-compatible
[ ] This PR CONTAINS a (planned) breaking change (it is NOT backwards-compatible)

Related Issue
Closes #<issue_number>

@samuel27m I am trying to adjust some options for this test to hopefully with the flacky issues, after you fix the env


[FEATURE] Error checking of data/resources.yml and other YAML files

Describe your suggested improvement
There are to be many edits expected to be made to the underlying data of the Knowledge Hub by various people. Adding testing of these YAML files would ensure that:

YAML files are valid
All the necessary fields are filled out

This ensures that no errors will leak through into production.
Would you be capable/willing to implement the improvement?
Yes 🚀🚀🚀

Done!

Done!


Improving Scrollbar Visibility

Description
This pull request introduces changes to improve the visibility of the scrollbar in both light and dark modes. Previously, the scrollbar was hard to see in light mode due to its default color. This update ensures the scrollbar is easily visible regardless of the theme.
Related Issues
This PR addresses the issue of scrollbar visibility mentioned in discussions (#875).
Changes Proposed
I've added CSS rules to the global stylesheet to customize the scrollbar appearance for both light and dark modes. In light mode, the scrollbar now has a darker track and thumb to contrast against the lighter background. Conversely, in dark mode, the scrollbar features lighter elements to stand out against the dark background. These changes were implemented using the ::-webkit-scrollbar, ::-webkit-scrollbar-track, and ::-webkit-scrollbar-thumb pseudo-elements for webkit browsers, and the scrollbar-color property for Firefox.
Screenshots
https://github.com/shyamtawli/devFind/assets/116752300/a107176f-41bb-4038-b6ff-29e4f90ddfe0

I am at work, so I won’t be able to work on it until 7pm ish.
Get Outlook for iOShttps://aka.ms/o0ukef

From: Shyam Tawli @.>
Sent: Monday, February 19, 2024 12:27:08 PM
To: shyamtawli/devFind @.>
Cc: Sean Lewertow @.>; Mention @.>
Subject: Re: [shyamtawli/devFind] Improving Scrollbar Visibility (PR #876)
@seanlewertowhttps://github.com/seanlewertow Are you working on it?
—
Reply to this email directly, view it on GitHubhttps://github.com/shyamtawli/devFind/pull/876#issuecomment-1952922619, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A32X7LHDJM6GINOWLVZ75SLYUODOZAVCNFSM6AAAAABDBDR2DSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJSHEZDENRRHE.
You are receiving this because you were mentioned.Message ID: @.***>


Webpack module federation not using webpack nonce

Bug report

What is the current behavior?
When setting a webpack nonce as per the webpack content security policy page, the webpack nonce is not being properly inserted in the remoteEntry.js file, so the desired CSP doesn't pass.
If the current behavior is a bug, please provide the steps to reproduce.
I've reproduced the problem on my github, at https://github.com/trevorgithub/module-federation-nonce-issue.  Detailed repro steps are in the readme.md, along with my analysis of the problem

What is the expected behavior?
When the webpack nonce is set, it should cause all webpack related code (included those files generated as part of webpack module federation) to look at the webpack nonce and set it on script and style tags, so that the page hosting the webpack generated code's CSP that provides the same nonce value should be satisified, and the browser allows the code to execute.

Other relevant information:
webpack version:  5.72.0
Node.js version: v16.13.2
Operating System: Windows 10 (but will also fail on Ubuntu 20.04 and presumably other OSs)
Additional tools:

Sounds like enhancement

I thought it was more of a bug, as the Webpack CSP docs  say:

Webpack is capable of adding nonce to all scripts that it loads

This is script it both loads and generates.  There's really no workaround, except having a wide open CSP.  Regardless of how it's categorized, I'm really hopeful the team can implement the fix and/or add the feature soon. Module federation is very cool.
Thank you :)

but nonce could be changed and remoteEntry could be the same..

https://gist.github.com/ScriptedAlchemy/642b31c375843152b7c7860ba47eaa7c


Style of PyKwiki 2 has several issues

I just created a new, default site with PyKwiki and found two problems (IMO):

The layout of the footer doesn't scale well when the browser's window is rescaled. In fact, it's partially "outside" the window, becoming visible only when the window is scaled to be very large.
The default colors applied to the navigation bar do not have good contrast. Dark green on a lighter green background makes it hard to read the text.

Hey Phayz,
Thanks again for all the feedback. I've made several tweaks to the existing style (and adding a few new ones) this week; they'll be on pip by the end of the week.
You can preview the coming default style here: pykwiki.nullism.com -- let me know if you think it still has the contrast issues.
What browser are you using? The footer seems fine on Chrome, but more testing is definitely needed.

Thanks for the fast reply.
My concern about contrast is only valid (if at all) when the menu items are not active. When each menu item is hovered over, the contrast is just fine. I really need to try another theme since I don't really like the new default.
For the footer layout I was testing in both the latest version of Google Chrome, also Opera Beta. The issue in both browsers is that I have a scroll bar, despite the fact that the window is larger than 1024 x 768.

Understood. Thanks for the information.
I think I've fixed the issue; I cannot reproduce on Chrome Windows, Chrome Linux, or Firefox Linux.
I'll also add a black & white theme like with Pykwiki 1.0.
I will close this issue with the commit when I have it tested. Thanks again for the input!

Thanks. I have attached a screenshot so that you know what I'm seeing.
In this case, there's little content to the page but instead of the footer being completely visible at the bottom of the screen, it's not visible at all and requires scrolling to see it. That seems odd to me.

On the topic of themes, I'd certainly appreciate a theme that is similar or the same as that of PyKwiki.
Would it be possible to provide a theme "base colour" configuration option? That way the layout aspects of the theme could remain the same, but it would look different because of the different colour. For example, you might have a green, grey and blue option.

Hey Phayz,

That way the layout aspects of the theme could remain the same, but it would look different because of the different colour. For example, you might have a green, grey and blue option

You got it! That's a BIG reason I changed Pykwiki to be based on scss/sass. It should allow for very easy customization for a given style. I'm working on adding a style closer to Pykwiki classic, an orange style, a blue style, dark, and a couple more. My target for these is this week/weekend.
On the subject of the footer. I agree with your assessment. I need to figure out a way to handle sticky footers. I also hope to have this fixed this week.
After I update Pykwiki on pip, you'll need to do the following:

Update Pykwiki. (pip install pykwiki --upgrade, but I'm sure you knew that).
Install the latest style(s), navigate to your project directory and run pykwiki style info to see the available styles, and pykwiki style install <name> to install that style (need to add a -f to overwrite a style if you already have it installed in your project).

Thanks again for the input. It's very much appreciated.

Awesome! You're way ahead of my on the themeing, which is good. :D
I look forward to testing the new themes, whenever they're available.

Hey Phayz,
I've added the styles of classic, dark, and sapphire. The footer issue should now be fixed. These styles are available in Pykwiki v2.1.12.
To install all styles, run pk style install -f.
To try out a style, change style: default to style: <name> in config.yaml, then run pk cache -f.
Let me know what you think. There are more styles coming soon.

First - sorry for the loooong delay in replying.
Second - Thank you for adding those styles. I'll test them on a sample site and see if you've resolved the issues I reported.

I'm going to resolve this ticket. Checkout http://pykwiki-styles.nullism.com/default/ for style previews. My goal is to keep that site updated with all the new styles being added. If you still feel there are display issues, please let me know. Thanks for the ideas!

Great! I love the ability to go to http://pykwiki-styles.nullism.com/default/ and preview to themes available.
If I find any further issues, I'll raise them here in a new issue.


feat: On Canvas UI Colors and Widget API to consume these colors

Description

[!TIP]
Add a TL;DR when the description is longer than 500 words or extremely technical (helps the content, marketing, and DevRel team).
Please also include relevant motivation and context. List any dependencies that are required for this change. Add links to Notion, Figma or any other documents that might be relevant to the PR.

Fixes #Issue Number
or
Fixes Issue URL

[!WARNING]
If no issue exists, please create an issue first, and check with the maintainers if the issue is valid.

Automation
/ok-to-test tags=""
:mag: Cypress test results

[!CAUTION]
If you modify the content in this section, you are likely to disrupt the CI result for your PR.

Communication
Should the DevRel and Marketing teams inform users about this change?

[ ] Yes
[x] No

@riodeuno
Note: Due to the fact that we've updated the main container resizer z-index. Let's confirm if this works in the final PR.


Better handling of attachments

@RocketChat/android
Closes #169
This is not a final solution since there are some missing points:

audio attachments
video attachments
show the timestamp
make attachment collapse
have a thumb for image and opening the full image at a touch
respect mobile option from settings

Audio and video will need a special solution for each case (with embedded players and so).
The timestamp depends on formatters not available at the module. Instead of copying it or whatever, maybe it would be better to deal with the data better (maybe using MVP).
The collapse behavior may be easy to do. Not sure about that.
Show an image thumb and show the full image is too complex and should have a task of it own.
Respect settings should be a task of it own.

By the way, we would be happy if https://cdn-demo.rocket.chat/avatar/<username>?_dc=0 has a option to get the image with PNG format. (SVG cannot be parsed easily with Android app... 😓 )
Is there a possibility that such feature is implemented on Rocket.Chat server side?

About SVG: maybe we may find something to deal with that. Fresco has support for custom decoders (https://github.com/facebook/fresco/issues/1008) and that may help.

About SVG: maybe we may find something to deal with that. Fresco has support for custom decoders (facebook/fresco#1008) and that may help.

Thank you for the good news!

Material design guideline says that pure black text color should be used only for important text.
So actually it would be better to set alpha=87% for some TextViews.
However almost great 👍  Let's modify them after merging this PR.
Thank you for your contribution!


[text analytics] Upgrade to v3.1-preview.1

[ ] Add aspects and opinions to SentenceSentiment if opinionMining is True and passed to analyzeSentiment

Close this issue in favor of #9989.


Is it expected to generate a "position x barcode" matrix?

Hi,  I wonder if this is the expected result? A VCF with positions as rows and droplet barcode as columns?
Just to confirm if I am using it correctly.
Thanks!

Yes, it is. From v0.1.6, if you use -O out_dir instead of -o out_file, you will also have the sparse matrices.


Potential performance improvements for reading Parquet to StringViewArray/BinaryViewArray

Is your feature request related to a problem or challenge? Please describe what you are trying to do.
In https://github.com/apache/arrow-rs/issues/ @ariesdevil @XiangpengHao  and I implemented pretty fast reading of data in Parquet to Arrow StringViewArray
The solution we have so far is https://github.com/apache/arrow-rs/pull/5877 which doesn't copy the string data 🎉 , but does track a set of offsets which are then converted into StringViewArray
@ariesdevil  had a more comprehensive approach in https://github.com/apache/arrow-rs/pull/5557 that built the StringViews directly from the encoded data but hadn't yet removed the string copies
Describe the solution you'd like
It may be worth looking at the StringViewDecoding to see if there is more performance to be had.
Specifically we can se the arrow_array_reader/StringViewArray and related benchmarks to profile and identify any additional potential improvements
Describe alternatives you've considered
It may be good enough now
Additional context

Can/will this incorporate deduping/interning/implicitly using the gc function that landed recently?

The current gc function won't deduplicating strings, it only use GenericByteViewBuilder to create a new instance of the array.
I think it would be a great addition to implement the deduplicating logic. A straightforward approach is to use a hash table to track the location of the strings while building the GenericByteView.
It is not on my top priority list, but might give it a try when I have time.

Can/will this incorporate deduping/interning/implicitly using the gc function that landed recently?

I filed https://github.com/apache/arrow-rs/issues/5910 to track discussing this option

take

label_issue.py automatically added labels {'arrow'} from #5970