text:
Remove UserProfileController

The value of the UserProfileController is fairly low: just one method getUserProfile to retrieve the current user profile.
To be consistent with other pac4j implementations (which don't have such element), it wold make sense to remove it.

@hugovalk : what do you think of this one?

How would we get access to the user profile in the Java demo application?
Maybe we can make use of action composition:
https://www.playframework.com/documentation/2.2.x/JavaActionsComposition#Authentication
However, it seems to be less powerful than the Scala variant.

Like in any other pac4j library: context -> manager -> user profile
PlayWebContext context = new PlayWebContext(ctx(), config.getSessionStore());
ProfileManager manager = new ProfileManager(context);
UserProfile profile = manager.get(true);

Here, it's true that you need to also inject the config. Maybe we should keep the userprofile.
Action composition is what we already use for the RequiresAuthentication annotation and RequiresAuthenticationAction action.

Another suggestion might be to rename it to UserProfileProvider which can be injected in the controllers. Then you get rid of the inheritance in favor of composition which is good practice.

Can you elaborate a little more on how we would use this injected UserProfileProvider?

The only method in UserProfileController does not have anything to do with controllers, just with getting the user profile. So rename it to UserProfileProvider and rename the method to get().
Use it like this (Java):
public class MyController extends Controller {
    @Inject
    private UserProfilePovider userProfile;
    ...
        CommonProfile profile = userProfile.get()
    ....
}

or Scala:
class MyController @Inject() (userProfile: UserProfileProvider) extends Controller {
  ...
    userProfile.get
}

Preferably I would love it for Scala to return an Option[CommonProfile]

But you need the Play ctx() to build the web context and profile manager to get the user profile, don't you? And this ctx() is only available in controllers.
Speaking of the Option, notice that pac4j v1.9 will be Java 8 and all play-pac4j versions based on it will be Java 8 as well.

In the Scala Security trait, this is not necessary, so maybe this could be done for the UserProfileProvider as well:
protected def getUserProfile(request: RequestHeader): P = {
  val webContext = new PlayWebContext(request, config.getSessionStore)
  val profileManager = new ProfileManager[P](webContext)
  profileManager.get(true)
}

Beyond implementation, do you think the UserProfileController or UserProfileProvider is necessary for play-pac4j users or we can remove it (and let users use the web context and profile manager)?

Must users then always use this code like in the snippet from my previous comment? I feel (until convinced otherwise) that the web context and profile manager are more about the inner workings of play-pac4j.
At this moment user code does not contain the web context and/or the profile manager. By keeping it this way, we would have more flexibility in refactoring later on.

OK. Let's keep this logic internal for now and let's try the composition approach as you proposed.

@hugovalk : something to propose on this one or do we close it?

Re-planned to 2.2.0

authors: hugovalk leleuj


text:
Rough object detection example

This is an object detection example.  It works and has some docs, but needs to be cleaned up a bit before adding to the official listing of examples.

LGTM

source: gharchive/pull-request

authors: JoeyZwicker dwhitena

repo: pachyderm/pachyderm

license_type: permissive

license_source: github-api


text:
Update CSI Docs and Demo Deployment

Some parts of the doc need to be updated such as:

Packet CSI version v0.0.2 supports Kubernetes version >=v1.10

The  --allow-privileged=true flag doesn't seem to be supported by the kubelet anymore but I was able to deploy the CSI driver without that requirement as mentioned in the docs.
The demo-deployment.yaml file doesn't work properly when you try to deploy it. It says the following:
error: unable to recognize "demo-deployment.yaml": no matches for kind "Deployment" in version "v1beta1"
It would also be helpful to have a sample deployment file for a PersistentVolume. All the demos as of now use PVCs.

The demo-deployment.yaml file doesn't work properly when you try to deploy it. It says the following:
error: unable to recognize "demo-deployment.yaml": no matches for kind "Deployment" in version "v1beta1"

Yes, good point. Deployment has been apps/v1 for quite some time, just supported the old extensions/v1beta1, which finally was deprecated. No reason not to change it.

See #63 for the first issue

It would also be helpful to have a sample deployment file for a PersistentVolume. All the demos as of now use PVCs

Yes. And I saw your comments in Slack. Please open a separate issue for this so we can track each separately with their detailed comments and have separate PRs to fix.

Thanks Avi, I opened a new issue for the PV sample. Check #64 .

Just been caught out by the allow-privileged not being used on kubelet too.

Thanks for the issue and thanks to everyone that contributed to the conversation.
I'm closing this as 'Will not fix' - see #103 (Equinix Metal Block Storage from Datera is EOL).

source: gharchive/issue

authors: deitch displague enkelprifti98 scottrobertson

repo: packethost/csi-packet


text:
TypeError: Object of type TestResult is not JSON serializable

Probably caused by #364 and/or #365

Task task.steve_jobs.process_message[1d82072b-5278-4158-8591-2b0e67015a8b] raised unexpected: EncodeError(TypeError('Object of type TestResult is not JSON serializable'))
--
  | Traceback (most recent call last):
  | File "/usr/local/lib/python3.7/site-packages/kombu/serialization.py", line 50, in _reraise_errors
  | yield
  | File "/usr/local/lib/python3.7/site-packages/kombu/serialization.py", line 221, in dumps
  | payload = encoder(data)
  | File "/usr/local/lib/python3.7/site-packages/kombu/utils/json.py", line 70, in dumps
  | **dict(default_kwargs, **kwargs))
  | File "/usr/lib64/python3.7/site-packages/simplejson/__init__.py", line 399, in dumps
  | **kw).encode(obj)
  | File "/usr/lib64/python3.7/site-packages/simplejson/encoder.py", line 296, in encode
  | chunks = self.iterencode(o, _one_shot=True)
  | File "/usr/lib64/python3.7/site-packages/simplejson/encoder.py", line 378, in iterencode
  | return _iterencode(o, 0)
  | File "/usr/local/lib/python3.7/site-packages/kombu/utils/json.py", line 59, in default
  | return super(JSONEncoder, self).default(o)
  | File "/usr/lib64/python3.7/site-packages/simplejson/encoder.py", line 273, in default
  | o.__class__.__name__)
  | TypeError: Object of type TestResult is not JSON serializable
  |
  | During handling of the above exception, another exception occurred:
  |
  | Traceback (most recent call last):
  | File "/usr/local/lib/python3.7/site-packages/celery/app/trace.py", line 449, in trace_task
  | uuid, retval, task_request, publish_result,
  | File "/usr/local/lib/python3.7/site-packages/celery/backends/base.py", line 149, in mark_as_done
  | self.store_result(task_id, result, state, request=request)
  | File "/usr/local/lib/python3.7/site-packages/celery/backends/base.py", line 407, in store_result
  | request=request, **kwargs)
  | File "/usr/local/lib/python3.7/site-packages/celery/backends/base.py", line 758, in _store_result
  | self.set(self.get_key_for_task(task_id), self.encode(meta))
  | File "/usr/local/lib/python3.7/site-packages/celery/backends/base.py", line 310, in encode
  | _, _, payload = self._encode(data)
  | File "/usr/local/lib/python3.7/site-packages/celery/backends/base.py", line 314, in _encode
  | return dumps(data, serializer=self.serializer)
  | File "/usr/local/lib/python3.7/site-packages/kombu/serialization.py", line 221, in dumps
  | payload = encoder(data)
  | File "/usr/lib64/python3.7/contextlib.py", line 130, in __exit__
  | self.gen.throw(type, value, traceback)
  | File "/usr/local/lib/python3.7/site-packages/kombu/serialization.py", line 54, in _reraise_errors
  | reraise(wrapper, wrapper(exc), sys.exc_info()[2])
  | File "/usr/local/lib/python3.7/site-packages/vine/five.py", line 194, in reraise
  | raise value.with_traceback(tb)
  | File "/usr/local/lib/python3.7/site-packages/kombu/serialization.py", line 50, in _reraise_errors
  | yield
  | File "/usr/local/lib/python3.7/site-packages/kombu/serialization.py", line 221, in dumps
  | payload = encoder(data)
  | File "/usr/local/lib/python3.7/site-packages/kombu/utils/json.py", line 70, in dumps
  | **dict(default_kwargs, **kwargs))
  | File "/usr/lib64/python3.7/site-packages/simplejson/__init__.py", line 399, in dumps
  | **kw).encode(obj)
  | File "/usr/lib64/python3.7/site-packages/simplejson/encoder.py", line 296, in encode
  | chunks = self.iterencode(o, _one_shot=True)
  | File "/usr/lib64/python3.7/site-packages/simplejson/encoder.py", line 378, in iterencode
  | return _iterencode(o, 0)
  | File "/usr/local/lib/python3.7/site-packages/kombu/utils/json.py", line 59, in default
  | return super(JSONEncoder, self).default(o)
  | File "/usr/lib64/python3.7/site-packages/simplejson/encoder.py", line 273, in default
  | o.__class__.__name__)
  | kombu.exceptions.EncodeError: Object of type TestResult is not JSON serializable

We could probably make the TestResult JSON serializable, but I'm just wondering why we didn't see this before.
Do we now return the TestResult somewhere so that celery tries to store that in a backend?

We could probably make the TestResult JSON serializable, but I'm just wondering why we didn't see this before.

The parsing and usage is quite new: #365

authors: jpopelka lachmanfrantisek

repo: packit-service/packit-service

license: MIT


text:
Run packit from distgit

Be able to run packit from distgit.

/packit copr-build

/packit copr-build

Maybe you could create a packit.dev PR with some docs so that a reviewer knows how to test/play with it?

Good point.
I am currently working on making LocalProject lazy what I would like to add here as well.

/packit copr-build

/packit copr-build

/packit copr-build

I am currently working on making LocalProject lazy what I would like to add here as well.

Not ready yet. It introduced some new problems. I am leaving the LocalProject rewriting to some other PR...;)

Related docs PR:
https://github.com/packit-service/packit.dev/pull/56

The copr still fails for rawhide:
Start: build phase for packit-0.6.2.dev39+ga7e1140-1.fc32.src.rpm
Start: build setup for packit-0.6.2.dev39+ga7e1140-1.fc32.src.rpm
Building target platforms: x86_64
Building for target x86_64
setting SOURCE_DATE_EPOCH=1569456000
Wrote: /builddir/build/SRPMS/packit-0.6.2.dev39+ga7e1140-1.fc32.src.rpm
No matches found for the following disable plugin patterns: local, spacewalk
Copr repository                                  43 kB/s | 3.3 kB     00:00
fedora                                          200 kB/s |  15 kB     00:00
Error:
 Problem: conflicting requests
  - nothing provides python3.8dist(marshmallow) < 3 needed by rebase-helper-0.18.0-1.fc32.noarch
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
Finish: build setup for packit-0.6.2.dev39+ga7e1140-1.fc32.src.rpm
Finish: build phase for packit-0.6.2.dev39+ga7e1140-1.fc32.src.rpm
INFO: chroot_scan: 3 files copied to /var/lib/copr-rpmbuild/results/chroot_scan
INFO: /var/lib/mock/1040546-fedora-rawhide-x86_64-1569492779.607722/root/var/log/dnf.log
/var/lib/mock/1040546-fedora-rawhide-x86_64-1569492779.607722/root/var/log/dnf.librepo.log
/var/lib/mock/1040546-fedora-rawhide-x86_64-1569492779.607722/root/var/log/dnf.rpm.log
ERROR: Exception(/var/lib/copr-rpmbuild/results/packit-0.6.2.dev39+ga7e1140-1.fc32.src.rpm) Config(1040546-fedora-rawhide-x86_64) 0 minutes 8 seconds
INFO: Results and/or logs in: /var/lib/copr-rpmbuild/results
INFO: Cleaning up build root ('cleanup_on_failure=True')
Start: clean chroot
INFO: unmounting tmpfs.
Finish: clean chroot
ERROR: Command failed:
 # /usr/bin/dnf builddep --installroot /var/lib/mock/1040546-fedora-rawhide-x86_64-1569492779.607722/root/ --releasever 32 --setopt=deltarpm=False --allowerasing --disableplugin=local --disableplugin=spacewalk --disableplugin=local --disableplugin=spacewalk /var/lib/mock/1040546-fedora-rawhide-x86_64-1569492779.607722/root//builddir/build/SRPMS/packit-0.6.2.dev39+ga7e1140-1.fc32.src.rpm --setopt=tsflags=nocontexts
No matches found for the following disable plugin patterns: local, spacewalk
Copr repository                                  43 kB/s | 3.3 kB     00:00
fedora                                          200 kB/s |  15 kB     00:00
Error:
 Problem: conflicting requests
  - nothing provides python3.8dist(marshmallow) < 3 needed by rebase-helper-0.18.0-1.fc32.noarch
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

It is probably not our fault. Isn't it?

It is probably not our fault. Isn't it?

nope, https://bugzilla.redhat.com/show_bug.cgi?id=1755931

recheck

recheck

Is there something I can/need to do with this?
0.494 | 0737: 2019-10-01 09:26:31.753079 | test-node | ERROR `fedpkg new-sources` failed for some reason. Either Fedora kerberos is invalid or there could be network outage.

ERROR    Failed when getting downstream PRs: 'NoneType' object has no attribute 'get_pr_list'
ERROR    Failed when getting Dist-git versions: 'NoneType' object has no attribute 'get_branches'
No Dist-git versions found.

@jpopelka Thanks for pointing it out. It should be fixed now.
$ packit status
Packit 0.6.2.dev45+g499a46f.d20191001 is being used.
Input is a directory: /home/flachman/Projects/src.fedoraproject/packit
Input directory is a downstream repository (upstream url does not match any git remote).
ERROR    Failed when getting upstream releases: Cmd('git') failed due to: exit code(128)
  cmdline: git clone --tags -v https://github.com/packit-service/packit /tmp/tmpgss44a2k
  stderr: 'Cloning into '/tmp/tmpgss44a2k'...
POST git-upload-pack (gzip 16077 to 8097 bytes)
error: RPC failed; curl 52 Empty reply from server
fatal: the remote end hung up unexpectedly
'

No downstream PRs found.

Dist-git versions:
f31: 0.6.1
master: 0.6.1

No upstream releases found.

Latest Bodhi updates:
Update                 Karma  status
-------------------  -------  --------
packit-0.6.1-1.fc29        4  stable
packit-0.6.1-1.fc32        0  stable
packit-0.6.1-1.fc30        4  stable

Latest Koji builds:
fc31: packit-0.6.1-1.fc31
fc30: packit-0.6.1-1.fc30
fc29: packit-0.6.1-1.fc29
fc32: packit-0.6.1-1.fc32

(The clone problem is not related. I have some problems with my network.)

ERROR    Failed when getting downstream PRs: 'NoneType' object has no attribute 'get_pr_list'
ERROR    Failed when getting Dist-git versions: 'NoneType' object has no attribute 'get_branches'
No Dist-git versions found.

@jpopelka Thanks for pointing it out. It should be fixed now.
$ packit status
Packit 0.6.2.dev45+g499a46f.d20191001 is being used.
Input is a directory: /home/flachman/Projects/src.fedoraproject/packit
Input directory is a downstream repository (upstream url does not match any git remote).
ERROR    Failed when getting upstream releases: Cmd('git') failed due to: exit code(128)
  cmdline: git clone --tags -v https://github.com/packit-service/packit /tmp/tmpgss44a2k
  stderr: 'Cloning into '/tmp/tmpgss44a2k'...
POST git-upload-pack (gzip 16077 to 8097 bytes)
error: RPC failed; curl 52 Empty reply from server
fatal: the remote end hung up unexpectedly
'

No downstream PRs found.

Dist-git versions:
f31: 0.6.1
master: 0.6.1

No upstream releases found.

Latest Bodhi updates:
Update                 Karma  status
-------------------  -------  --------
packit-0.6.1-1.fc29        4  stable
packit-0.6.1-1.fc32        0  stable
packit-0.6.1-1.fc30        4  stable

Latest Koji builds:
fc31: packit-0.6.1-1.fc31
fc30: packit-0.6.1-1.fc30
fc29: packit-0.6.1-1.fc29
fc32: packit-0.6.1-1.fc32

(The clone problem is not related. I have some problems with my network.)

$ git remote -v
fork	ssh://lachmanfrantisek@pkgs.fedoraproject.org/forks/lachmanfrantisek/rpms/packit.git (fetch)
fork	ssh://lachmanfrantisek@pkgs.fedoraproject.org/forks/lachmanfrantisek/rpms/packit.git (push)
origin	ssh://lachmanfrantisek@pkgs.fedoraproject.org/rpms/packit (fetch)
origin	ssh://lachmanfrantisek@pkgs.fedoraproject.org/rpms/packit (push)
$ packit srpm
Packit 0.6.2.dev45+g499a46f.d20191001 is being used.
Input is a directory: /home/flachman/Projects/src.fedoraproject/packit
Input directory is a downstream repository (upstream url does not match any git remote).
SRPM is /home/flachman/Projects/src.fedoraproject/packit/packit-0.6.2.dev25+g6f282fc-1.fc30.src.rpm
SRPM: /home/flachman/Projects/src.fedoraproject/packit/packit-0.6.2.dev25+g6f282fc-1.fc30.src.rpm

The code works for urls as well. (We only need to add upstream_project_url to config.)
$ packit status "https://github.com/packit-service/packit"
Packit 0.6.2.dev45+g499a46f.d20191001 is being used.
Input is a URL to a git repo: https://github.com/packit-service/packit
WARNING  We cannot determine, if the input is upstream or downstream. Using upstream as a default.
won't be doing kinit, no credentials provided
ERROR    Failed when getting upstream releases: Please, set 'upstream_project_url' in your config file.

$ packit status "https://src.fedoraproject.org/rpms/packit"
Packit 0.6.2.dev45+g499a46f.d20191001 is being used.
Input is a URL to a git repo: https://src.fedoraproject.org/rpms/packit
WARNING  'upstream_project_name' configuration key was renamed to 'upstream_package_name', please update your configuration file
Input directory is a downstream repository.
ERROR    Failed when getting upstream releases: Please, set 'upstream_project_url' in your config file.

Is there something I can/need to do with this?

It is probably not related to my changes. See other PR:
https://github.com/packit-service/packit/pull/545#issuecomment-536988166

The code works for urls as well. (We only need to add upstream_project_url to config.)

Why don't we guess from the spec file?

Why don't we guess from the spec file?

Yes, that's possible. Good idea!
Do I need to implement that here, or make an improvement after the merge?

Why don't we guess from the spec file?

Yes, that's a possibility. Good idea!
Do I need to implement that here, or make an improvement after the merge?

I'd do it afterwards.

/packit copr-build

recheck

What can we do with this?
 `fedpkg new-sources` failed for some reason. Either Fedora kerberos is invalid or there could be network outage.

/packit copr-build

What can we do with this?
 `fedpkg new-sources` failed for some reason.

There's more in logs:
E                  packit.exceptions.PackitException: archive does not exist

There's more in logs:
E packit.exceptions.PackitException: archive does not exist

Thanks, but it started to fail in more test suites without any change from my side. (And also in other PR.) I need to take a deeper look at the original cause.

I didn't say it's your fault :-)

authors: TomasTomecek jpopelka lachmanfrantisek

repo: packit-service/packit


text:
Signed-off-by: Packit hello@packit.dev -- what is the purpose and meaning?

What happened? What is the problem?
I see the commits in Fedora dist-git by packit have Signed-off-by: Packit <hello@packit.dev> in the commit messages.

This is not required in Fedora, EPEL, RHEL, CentOS Stream. There is nothing to sign off.
How can a robot/program legally sign anything off? What does this even mean?

What did you expect to happen?
No Signed-off-by: Packit <hello@packit.dev>.
Example URL(s)
No response
Steps to reproduce
No response
Workaround

[ ] There is an existing workaround that can be used until this issue is fixed.

Participation

[ ] I am willing to submit a pull request for this issue. (Packit team is happy to help!)

Thanks

repo: packit/packit


text:
upd(spotify-client-deb): 1.1.84.716.gc5f8b819 -> 1.1.84.716.gc5f8b819-2

Updated spotify-client-deb from 1.1.84.716.gc5f8b819 to 1.1.84.716.gc5f8b819-2
Everything should be working fine

Fix the PR title.

To what?

Like #2640.

Ah I see

Better?

Add the backticks

Done!

Single backticks

Now good? 🤔

repo: pacstall/pacstall-programs


text:
add: waydroid-deb

After all dependencies required by waydroid-deb has been merged, now finally waydroid-deb are gonna be added. Still based on requests #6454, it's the main app. After waydroid-deb has been merged, #6454 requests should be closed as complete. Please review immediately and merge it when everything's okay.

Somethings wrong, the tests says pkgdesc and source are missing but actually it present on pacscript. I'll convert into draft firsts and check somethings wrong.

Good, now #6454 should be closed as completed


text:
windows(LoadError): Cannot load such  file

Thank you for reporting a bug! We appreciate it very much. Issues are a big input into the priorities for Pact development
All italic text in this template is safe to remove before submitting
Thanks again!
Software versions
Please provide at least OS and version of pact-js

OS: Windows
Pact Node version: Pact v9.11.1 Node v14.4_
Node Version: 14.4
Other Versions: Any other versions you think might be relevant (optional)

Issue Checklist
Please confirm the following:

[x] I have upgraded to the latest
[x] I have the read the FAQs in the Readme
[x] I have triple checked, that there are no unhandled promises in my code
[x] I have set my log level to debug and attached a log file showing the complete request/response cycle
[ ] For bonus points and virtual high fives, I have created a reproduceable git repository (see below) to illustrate the problem

Expected behaviour
Provider Test cases should run
Actual behaviour
Provider Test cases Fails with LoadError
Steps to reproduce
Followed the steps by enabling long path in registry as given  here
Didn't Help
Relevant log files
node_modules/@pact-foundation/pact-node/standalone/win32-1.88.49/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.35.0/lib/pact/provider_verifier/app.rb:3:in `require': cannot load such file -- pact/provider_verifier/provider_states/add_provider_states_header (LoadError)

It looks like the long path issue though. Have you tried reducing the length of the project directory?
Also consider using the v3 beta release documented in the readme

As far as I understand, the long path limit in windows was removed in windows 10 (so the registry fix doesn't make a difference, because it's already implied to be enabled). However, as I understand it, Ruby still has a limit -even in the latest version.
For now the workarounds that Matt suggested are your options - reducing the length of the path that the project is running from, or using the v3 pact parts of the upcoming beta.
I'll leave this issue open because it does indicate that we need to update the documentation.

Closing as per the other windows issues. The latest version uses the new rust core which doesn't have this issue.

authors: TimothyJones Yashwanthhs mefellows

repo: pact-foundation/pact-js-core


text:
Can we use injected provider state for gRPC?

I've been trying to use gRPC and essentially get the functionality of queryParameterFromProviderState as documented here. However, given that we have to use PactBuilder for leveraging gRPC as seen here, I see no way to leverage queryParameterFromProviderState. Am I missing something or is this yet to be implemented?
Thanks

Duplicate of #69

gRPC does not support query parameters, but other values should be able to be used.

Completed in #69, see comments in issue

authors: YOU54F rholshausen senthil-yohana

repo: pactflow/pact-protobuf-plugin


text:
🛑 Bijbeldag is down

In 75eb7bf, Bijbeldag (https://bijbeldag.be) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Bijbeldag is back up in d2a367d.

repo: pageon/uptime


text:
🛑 Ik geloof in vlaanderen is down

In 463dc5a, Ik geloof in vlaanderen (https://ikgeloofinvlaanderen.be) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Ik geloof in vlaanderen is back up in 18bb0dd.


text:
🛑 School of intersession is down

In 5063f45, School of intersession (https://www.schoolofintercession.eu) was down:

HTTP code: 0
Response time: 0 ms

Resolved: School of intersession is back up in 253df87 after 48 minutes.


text:
Goal: Test Recipes Dynamically

Create a means of testing recipes that provides friendly feedback to the user regarding the proper functioning of recipes.
Possible ideas;

Simply generate py.test files by inspecting recipes and then execute those tests, gathering results at end to send somewhere.
Would a py.test plugin be useful?
Alternative test framework maybe? I'd be sad...

Ideally, it should integrate seamlessly into travis and also allow local testing of recipes during development. Like pakit, support python >= 2.7.

Current implementation seems adequate. Therefore closing this, though certainly may be room for improvements/suggestions.

license_source: bigquery


text:
Servlet endpoint for checking enable/disable status of stashbot

Added an endpoint so that js can check the enable/disable status of stashbot before showing/hiding links

All of your suggestions are good and I agree that the endpoint should return json because it would be easier to parse from any js code. The reason I just did a simple enable/disable check is because I didn't know what other data to expose and what data would actually be useful. In the case of showing or not showing certain links the text itself was adequate.

repo: palantir/stashbot


text:
New rule for object literal keys ordering

There is only one rule for it: "object-literal-sort-keys". This is rule about alphabetical order.
I have another idea about keys ordering in TypeScript. In TypeScript we have types and intarfaces for describe object and for keys order. Look at this:
type X = {
  type: string;
  id: number;
} // describe my order (not alphabetical)

const x: X = {
  type: "type1",
  id: 1,
}; // it's good, because follows X keys order

const y: X = {
  id: 2,
  type: "type2",
}; // it's bad, because doesn't follow right order

I wrote sketch of this rule by myself tslint-object-literal-smart-keys with some tests. It supports checking for object literal as argument, as return and as variable declarations. Nesting and optional properties are supported too.
What do you think about it?

@arusakov interesting proposal. We could add this as an option to object-literal-sort-keys by turning it into an optionally typed rule and requiring type information for the option... but that seems quite expensive. Let's hear if there's a strong need for it?
FWIW I'm -1 in general on these types of alphabetization rules. They tend to not be well received by many developers.

☠ TSLint's time has come! ☠
TSLint is no longer accepting most feature requests per #4534. See typescript-eslint.io for the new, shiny way to lint your TypeScript code with ESLint. ✨
It was a pleasure open sourcing with you all!

🤖 Beep boop! 👉  TSLint is deprecated 👈 (#4534)  and you should switch to typescript-eslint! 🤖
🔒 This issue is being locked to prevent further unnecessary discussions. Thank you! 👋

authors: JoshuaKGoldberg arusakov

repo: palantir/tslint


text:
"variable-name" rule for certain instances

Bug Report

TSLint version: 5.10.0
TypeScript version: 2.7.2
Running TSLint via: vscode

TypeScript code being linted
export const SupportForm = withFormik<IOtherProps, IFormValues>({
  handleSubmit: (values, { props }) => {
    props.supportStore.submitSupportformHandler(values);
  },
  mapPropsToValues: props => {
    return {
      message: '',
      subject: '',
    };
  },
  validationSchema: Yup.object().shape({
    message: Yup.string()
      .required('Message is required!'),
    subject: Yup.string()
      .required('Email is required!'),
  }),
})(BaseForm);

with tslint.json configuration:
{
    "extends": ["tslint:recommended", "tslint-react", "tslint-config-airbnb"],
    "rules": {
        "no-trailing-whitespace": false,
        "object-literal-shorthand": false,
        "trailing-comma": false,
        "quotemark": [true, "single", "jsx-double", "avoid-escape"],
        "jsx-no-lambda": false,
        "jsx-no-multiline-js": false,
        "jsx-wrap-multiline": false,
        "max-line-length": false,
        "variable-name": [true, "check-format", "allow-leading-underscore"],
        "ter-arrow-parens": [ true, "as-needed" ],
        "ter-indent": [ true, 2, { "SwitchCase": 1 } ],
        "import-name": false,
        "no-increment-decrement": false,
        "no-namespace": false,
        "max-classes-per-file": false
    }
}

Actual behavior
So it highlighting SupportForm saying
[tslint] variable name must be in lowerCamelCase or UPPER_CASE (variable-name)
Expected behavior
Would like to have it not complain in cases where the variable is a HoC or Functional Stateless component

@pmonty you are looking for the "allow-pascal-case" option. PascalCase is the name for "camelCase with a leading uppercase letter."

@giladgray If I add that option then it allows it everywhere. I need it only for certain sections like Functional components.

I believe @giladgray didn't entirely understand the issue because the example is somewhat convoluted and doesn't give a slightest hint that it's about React.
The related issue has been reported here:
https://github.com/palantir/tslint-react/issues/120

authors: giladgray pmonty pronebird


text:
FireFox 95 can't detect media streams

Currently Palava is not usable on my currently installed FireFox since it can't detect media streams. No error logs in the console or other issues, just nothing happening where a prompt for camera/microphone would be expected

@pascalwengerter I just checked for

Firefox 95.0 on desktop (Kubuntu 21.10)
Firefox 95.1.0 on mobile (Android 9)

Both seem to work fine for me when being connected over WiFi.
Could you share more information about your operating system and whether you were on WiFi or mobile connection when you saw the media stream issues?

Interesting...was connected to WiFi on my Ubuntu 21.XX (or sth, quite recent definitely) and have come across it some weeks ago already

Can confirm it works fine on Android ;)

Weirdly enough a system restart fixed this.
From my experience with other videocall tools, I also suspected other consumers of media streams (e.g. Zoom) not correctly terminating, but entered and left a Zoom call and could still successfully use Palava.tv afterwards (also after the restart, that is)
Sorry for the noise 🤗

authors: pascalwengerter paulgoetze

repo: palavatv/palava-web


text:
SERVER_NAME still implicitly changes routing behavior

Just like this old issue said, routing behavior changed even when subdomain_matching defaults to false, so take this repository as example, if you comment following lines,
@app.before_request
def start():
    """
    init globals and set the schema search path for the current request.
    """
    g.user = session.get('user', None)
    current_url = urlparse(request.url)
    subdomain = current_url.hostname.split('.')

    if subdomain.__len__() > 2:
        """
        redirect to home page
        """
        if current_url.path == "/":
            return redirect(url_for('index'))
        pass
    pass

then requests to user1.flask-subdomain.com won't route to index, default 404 as response. Or am I missing something, as a result have misunderstood it. Thanks very much.
@app.route('/')
def index():
    return render_template('index.html')

Environment

Python version: 3.6
Flask version: 1.1.1
Werkzeug version: 0.16.0

Hi can i take up this issue ?

I'm sorry, it looks like you're asking about code in another repository. As far as I can tell SERVER_NAME works as intended at this point.

#5634 in Flask 3.1 will further address this. SERVER_NAME no longer affects routing except to determine subdomains if subdomain_matching is enabled.

authors: BoWuGit davidism sagnik-chatterjee

repo: pallets/flask


text:
fix: [534] fix Webpack warning on named imports from json files

Github Issue or Trello Card
This PR addresses this issue: #534
This PR is just a demonstration of the current webpack 5 issues caused due to named import from json: https://webpack.js.org/blog/2020-10-10-webpack-5-release/#json-modules
as well as a possible solution.
test-project is just a create-react-app (which uses webpack5) that imports the locally built version of palmetto components. You can see the webpack errors by reverting the changes to token.ts and running npm start inside test-project. I've also attached screenshots of the changes below.
If the changes I've made to token.ts are acceptable as-is I can remove test-project from this PR and remove the do not merge label.
Before

After

What type of change is this?
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Updating documentation.
[ ] Updating deployment/build pipeline.
[ ] Updating Project Dependencies
[ ] Improving or adding to Test Coverage

Completeness Checklist

[ ] TESTS: My changes maintain the baseline required test coverage, as specified by code climate analysis.
[ ] DOCS: All new component work is covered in that component's Overview docs.
[ ] DOCS: All new component work is covered in a component Playground.
[ ] DOCS: All new visual changes or options are covered under relevant components' VisualTests.
[ ] My code has no linting or typescript compile warnings.
[ ] My work is tied to a Github issue and satisfies the acceptance criteria (if applicable) of the corresponding issue.

Quality Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes

UI Checklist

[ ] I have conducted visual UAT on my changes/features.
[ ] My solution works well on desktop, tablet, and mobile browsers.

Hey @dg-harris this is totally fine with me provided all the build jobs, tests, as well as the storybook run properly, which seems to be the case here.
Feel free to remove the test-project and we can get this merged.

Hey sorry I wasn't sure what the procedure was, should I be merging this?

Yeah I was trying to use this and got the same errors on my first import

And you can install from this branch either FYI

authors: dg-harris juanfabrega surfjedi

repo: palmetto/palmetto-components


text:
Full file paths are not unique

In the table for files full paths are not unique but they should be to avoid duplicated entries.

Issue has been resolved with new PR

repo: palzino/Video-File-Analyser


text:
error: "_SeriesGroupByScalar[Any]" has no attribute "diff"  [attr-defined]

import pandas as pd

index = pd.MultiIndex.from_product([["a", "b"], [1, 2, 3]], names=["foo", "bar"])
s = pd.Series(list(range(len(index))), index=index)
s.groupby("foo").diff()  # error: "_SeriesGroupByScalar[Any]" has no attribute "diff"  [attr-defined]

Ubuntu 22.04
python 3.10.6
mypy  1.2.0
pandas                              2.0.1
pandas-stubs                        1.5.3.230304

Need to add diff to core/groupby/generic.pyi in SeriesGroupBy

authors: Dr-Irv randolf-scholz

repo: pandas-dev/pandas-stubs


text:
added return types for "SeriesGroupBy" and "DataFrameGroupBy"

[x] Closes #438
[x] Tests added: Please use assert_type() to assert the type of any return value

thanks @ramvikrams

Thanks @Dr-Irv sir


text:
Data have rejected variables, but do not display in Warnings

Data have rejected variables, but do not display in Warnings
from pandas_profiling import ProfileReport
profile = ProfileReport(pd.DataFrame({"a": [1,1,1,1,1,1]}), minimal=True)

2.5.0

Thank you for reporting this. We invite interested contributors to create a pull request with this functionality. More details can be found in the contribution guide.

I noticed that four types of warning messages(Uniform,Unique,Rejected,Constant) are ignored when rendering. Since Rejected is always comes with other warnings, is it necessary to add all types of warnings above?
or it will end up like this:

v2.7.0 changes the behavior to report all warnings, except "rejected", as that would be redundant.

authors: NickYi1990 loopyme sbrugman

repo: pandas-profiling/pandas-profiling


text:
Index of type category fails on validation

Validation for an index of type "category" fails starting from version 0.8.0
Minimal reproducible example
import pandas as pd
import pandera as pa

class Schema(pa.SchemaModel):
    categorical_field: pa.typing.Index[pa.Category]

df = (
    pd.DataFrame({"categorical_field": ["a", "b", "c"]})
    .astype({"categorical_field": "category"})
    .set_index("categorical_field")
)
Schema.validate(df)

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/env/lib/python3.8/site-packages/pandera/model.py", line 256, in validate
    cls.to_schema().validate(
  File "/env/lib/python3.8/site-packages/pandera/schemas.py", line 513, in validate
    return self._validate(
  File "/env/lib/python3.8/site-packages/pandera/schemas.py", line 709, in _validate
    error_handler.collect_error("schema_component_check", err)
  File "/env/lib/python3.8/site-packages/pandera/error_handlers.py", line 32, in collect_error
    raise schema_error from original_exc
  File "/env/lib/python3.8/site-packages/pandera/schemas.py", line 701, in _validate
    result = schema_component(
  File "/env/lib/python3.8/site-packages/pandera/schemas.py", line 2043, in __call__
    return self.validate(
  File "/env/lib/python3.8/site-packages/pandera/schema_components.py", line 390, in validate
    super().validate(
  File "/env/lib/python3.8/site-packages/pandera/schemas.py", line 1976, in validate
    error_handler.collect_error(
  File "/env/lib/python3.8/site-packages/pandera/error_handlers.py", line 32, in collect_error
    raise schema_error from original_exc
pandera.errors.SchemaError: expected series 'categorical_field' to have type category, got object

Where it fails
Here
https://github.com/pandera-dev/pandera/blob/9a463e1757e2811bbfee4684562541a5f2110cc3/pandera/schema_components.py#L385-L387
the index gets converted to a numpy array but Categorical is not a numpy array and therefore validation fails
removing the numpy conversion lets the validation pass, but I do not know what else it would/could influence

thanks for reporting this @aartaria, this is definitely a bug!
don't exactly remember now why that to_numpy call is there, can you see which unit tests fail if you remove it? I have a suspicion it's there for the sake of supporting the pandas-like frameworks (pyspark.pandas, modin, or dask) but yeah ideally that wouldn't need to be called

https://github.com/unionai-oss/pandera/pull/856 fixed this apparantly, but just gonna keep this open, since #856 didn't add unit tests for the changes

authors: aartaria cosmicBboy

repo: pandera-dev/pandera


text:
Include doi as required field in meta.yaml

I am working through a documentation with @rabernat which outlines how a proper citation using pangeo-forge data would look like. We noticed that the catalog page does not display the doi, which is needed to cite the original data source in a paper.
I propose to add a required field in the meta.yaml that contains the doi (or possibly a list of dois) for a given dataset. This could be then be used to have a 'copy citation' button on each catalog entry.

More broadly, we could think about how we want recipes to be cited. Here is example we came up with today for this dataset.

The data in this study originated from the NASA "GPM IMERG Late Precipitation L3 1 day 0.1 degree x 0.1 degree V06 (GPM_3IMERGDL)" dataset (Huffman et al., 2019)
The data were accessed via the Pangeo Forge ARCO data repository (Stern et al., 2022) on Jan. 13, 2023.
The Pangeo Forge recipe that generated the data is located at https://pangeo-forge.org/dashboard/feedstock/81
Huffman, G.J., E.F. Stocker, D.T. Bolvin, E.J. Nelkin, Jackson Tan (2019), GPM IMERG Late Precipitation L3 1 day 0.1 degree x 0.1 degree V06, Edited by Andrey Savtchenko, Greenbelt, MD, Goddard Earth Sciences Data and Information Services Center (GES DISC). https://doi.org/10.5067/GPM/IMERGDL/DAY/06
Stern, Charles, R. Abernathey, J. Hamman, R. Wegener Rachel, C. Lepore, S. Harkins, A. Merose.
Pangeo Forge: Crowdsourcing Analysis-Ready, Cloud Optimized Data Production.
Frontiers in Climate, 10 February 2022
https://doi.org/10.3389/fclim.2021.782909

What's missing here is a good citation for the recipe author (in this case, @briannapagan). Brianna, I'm curious, what sort of acknowledgement of your role would make sense here?

I would second showing the doi/list of doi's. Recipe authors have the responsibility of properly citing the original dataset. As for acknowledging the recipe auhors - is adding a doi for the recipe itself over-doing it? Do we need recipe author acknowledgement at all? Using NASA as an example, the archivers/folks who are working at the data centers do not get acknowledgement for maintaining the data collections themselves, just a nod potentially to the data center itself.

I think we have the opportunity to change the status quo for the better here. I would personally advocate for a doi per recipe, which I think will acknowledge the important work which will be the foundation of how climate data science might be done in the future?
We cannot assume that recipe maintainers are financially compensated for their work (as is the case at NASA?), so I think providing an easy way to acknowledge their efforts is just fair, and might create a needed incentive for a diverse group of people to contribute recipes.
A practical consideration for reproducibility: If we e.g. decide to implement a zenodo webhook for feedstocks, we could get a doi + a secondary archived location for the code. This would increase the chance of researchers in the future to actually reproce a given dataset with a particular version of the recipe (even if it has to be run on your local computer).

Along the same lines, is the recipe maintainer which receives the acknowledgement also responsible for maintaining in perpetuity? I am going to sound like a broken record, but data archives are very much alive. If some reprocessing error is caught, and original data source republished, the zarr store must be updated. Is the onerous on the shoulders of the maintainer to always ensure the zarr store is accurate? How do we connect the upstream data providers to this?

I personally think we have the opportunity to change the status quo for the better here. I would personally advocate for a doi per recipe, which I think will acknowledge the important work which will be the foundation of how climate data science might be done in the future?

Also great! +2 for doi per recipe.

Is the onerous on the shoulders of the maintainer to always ensure the zarr store is accurate? How do we connect the upstream data providers to this?

Excellent point! Naively Id think we should aim to make them feedstock maintainers/contributors, but I realize this might be hard.

authors: briannapagan jbusecke rabernat


text:
add "serverless"

"serverless" seems to be a new hype alias for "cloud"
please add "serverless" as alternative to "cloud"

Can it be rewritten to pants-less?

We are going all pants-less: we move everything to the butt.

I feel like buttless may be better.  @panicsteve interested in the expansion at all? I can send you a PR

I prefer forks for this sort of thing because I like cloud-to-butt best as a one joke pony. But with your own fork, the world is your oyster...

authors: bexelbie chpio panicsteve shtrom

repo: panicsteve/cloud-to-butt

license: WTFPL


text:
你好，请问可以开个循环处理队列一直不关闭吗？会不会占用很高内存或者cpu

What is your question about ants?
可以开个循环处理队列一直不关闭吗？会不会占用很高内存或者cpu
Please describe your question meticulously.
伪代码：
p, _ := ants.NewPoolWithFunc(pos, taskFunc, ants.WithNonblocking(true))
defer p.Release()
for {
...
value, ok := q.Get()
p.Invoke(value)
...
}

谢谢

这么用没问题。


text:
[Bug]: concurrent map write and read

Actions I've taken before I'm here

[X] I've thoroughly read the documentations on this issue but still have no clue.
[X] I've searched the Github Issues but didn't find any duplicate issues that have been resolved.
[X] I've searched the internet for this issue but didn't find anything helpful.

What happened?

I have encounter panic fatal error: concurrent map read and map write when using this.
Major version of gnet
v2
Specific version of gnet
v2.5.7
Operating system
Linux
OS version
Ubuntu 20.04
Go version
go1.21
Relevant log output
fatal error: concurrent map read and map write

goroutine 77 [running, locked to thread]:
github.com/panjf2000/gnet/v2.(*connMatrix).getConn(...)
        /github.com/panjf2000/gnet/v2@v2.5.7/conn_map.go:66
github.com/panjf2000/gnet/v2.(*eventloop).close(0xc00080ab00, 0xc009306d20, {0x23ffc80, 0xc00b44c440})
        /github.com/panjf2000/gnet/v2@v2.5.7/eventloop_unix.go:230 +0x70
github.com/panjf2000/gnet/v2.(*eventloop).read(0xc00080ab00, 0xc009306d20)
        /github.com/panjf2000/gnet/v2@v2.5.7/eventloop_unix.go:139 +0x310
github.com/panjf2000/gnet/v2.(*conn).processIO(0xc009306d20, 0xc00087d650?, 0x19, 0x0?)
        /github.com/panjf2000/gnet/v2@v2.5.7/connection_linux.go:54 +0xa5
github.com/panjf2000/gnet/v2.(*eventloop).orbit.func1(0x1af, 0x19, 0x0)
        /github.com/panjf2000/gnet/v2@v2.5.7/reactor_default.go:66 +0x1b6
github.com/panjf2000/gnet/v2/internal/netpoll.(*Poller).Polling(0xc000c837a0, 0xc00177df28)
        /github.com/panjf2000/gnet/v2@v2.5.7/internal/netpoll/poller_epoll_default.go:136 +0x26c
github.com/panjf2000/gnet/v2.(*eventloop).orbit(0xc00080ab00)
        /github.com/panjf2000/gnet/v2@v2.5.7/reactor_default.go:54 +0x97

Code snippets (optional)
No response
How to Reproduce
Steps to reproduce the behavior:
This behavior only occur by chance, there is no reproduce steps.
As long as its is running with multi thread there will be chance for this panic to occur.
Does this issue reproduce with the latest release?
It can reproduce with the latest release

Is that all the fatal log? It contains within it all the goroutines accessing the map.
Also, could you provide a example showing how you configure and use gnet?

Thanks for the new details. But, I have no clue about this at the moment. We may need more debugging. Could you try to use WithReusePort or downgrade to v2.4.2 and see if this issue still exists?

Duplicate of #463 #479 #525 #577


text:
Include vite.config.ts in the list of ignored files

Hello,
I am sending this PR to include the vite.config.ts file to the list of ignored files when installing the package.
Thank you
Bilal

Hi @nunomaduro I hope all is well. Would love to explain to me why the vite.config.ts need not be ignored. I don't much PHP packages and I would love to learn. Thanks

repo: panphp/pan


text:
Release 2.1.149

Backlog:

[ ] Allow system_site_packages=True in Virtualenv.create() #1973
[ ] The --compile option is only useful for Python 2.7 #1939
[ ] Universal lock creation failure for disjoint IC and Requires-Python is correct but the error message from Pip / Pex is confusing. #1927
[ ] The __pex__ import hook does not handle registering top level PEP-420 packages #1910
[ ] Expose setuptools and wheel version flags for use with non-vendored Pips. #1895
[ ] Plumb --pip-version to Platform tag calculation. #1894

[ ] PEX_INHERIT_PATH+default shebangs don't interact well with virtualenvs #1344
[ ] Pex interpreter cache is not upgrade / downgrade safe. #1176
[ ] Provide a better resolve error message for a Platform DistributionTarget when --resolve-local-platforms. #1070
[ ] Remove PEX_PYTHON_PATH from build time interpreter selection. #1075

Broken off of #2244 to make way for --check zipapp ZIP64 check.

repo: pantsbuild/pex


text:
Deduplicate primitive types and use alloy's existing types

Describe the feature
ref https://github.com/alloy-rs/alloy/issues/255
ref #5746
currently all codec traits are implemented in reth-primitives via derive macros, therefor we're duplicating types that already exists in alloy:
https://github.com/paradigmxyz/reth/blob/9569692d474f7e6c7d4a843e8fe897848a9ba4fa/crates/primitives/src/transaction/access_list.rs#L43-L46
https://github.com/paradigmxyz/reth/blob/9569692d474f7e6c7d4a843e8fe897848a9ba4fa/crates/primitives/src/withdrawal.rs#L9-L12
https://github.com/paradigmxyz/reth/blob/9569692d474f7e6c7d4a843e8fe897848a9ba4fa/crates/primitives/src/log.rs#L6-L9
In order to replace them, we need to impl all the codecs for alloy types.
This can be done in two ways:

impl codecs in alloy directly
impl codecs in reth's codec crate https://github.com/paradigmxyz/reth/blob/9569692d474f7e6c7d4a843e8fe897848a9ba4fa/crates/storage/codecs/Cargo.toml#L2-L2

since codecs are a reth thing, we could pursue option 2.
This however, would require implementing codecs manually, because derive is not possible
we could also spin out codecs which is just the Compact trait to it's standalone repo and make it a feature in alloy (option 1.)
https://github.com/paradigmxyz/reth/blob/9569692d474f7e6c7d4a843e8fe897848a9ba4fa/crates/storage/codecs/src/lib.rs#L36-L36
wdyt @DaniPopes
Additional context
No response

I'm open to either. I do think the Compact eth specific encoding is valuable (optimal / zero cost?) so if it's worth pulling out of reth we should do that.

this should be integrated in the codecs crate for alloy-eips types
then replacing the duplicated reth-primitive types with alloy-eips

regarding the reth_codecs where should we spin it to a standalone one, maybe we create something like alloy/codecs, we need it to avoid circular deps while moving code around. Can you create the repo? @mattsse

these should be implemented where the Compact trait is defined, we discarded the other option.

oh I see, this is definitely easier to implement. I thought we wanted to move the whole Compact to alloy, it's clear now.

great!
I think we can move the impls in a new alloy.rs file here
https://github.com/paradigmxyz/reth/blob/57e25be058d041907840f81feb2e82a1aade6714/crates/storage/codecs/src/lib.rs#L18-L18

I will continue with Withdrawal, and AccessList then we can replace them in next PRs.

cool! ty
separately, we can now replace the reth_primitive::Log type in a separate pr

Thanks @mattsse for replacing duplicate Withdrawl part, I was a bit busy.

authors: 0xqd gakonst mattsse

repo: paradigmxyz/reth


text:
Remove _args prefix from modules in  node_core

Describe the feature
In crates/node-core/src/args, modules redundantly contain the _args when they're already in the args module
Additional context
No response

I'd like to tackle this

authors: DaniPopes estensen


text:
Add new NetIf variant to NatResolver for IP resolution via network interface

Closes https://github.com/paradigmxyz/reth/issues/10832

Hey @emhane could you PTAL again, thanks!

clippy unrelated

authors: garwahl mattsse


text:
Add needs-triage label to issue templates

What does this PR change?
Automatically sets needs-triage label to all issues created using issue templates.
Does the PR depend on any other PRs or Issues? If yes, please list them.
No
Checklist
I confirm, that I have...

[X] Read and followed the contributing guide in CONTRIBUTING.md
[X] Added tests for this PR
[X] Formatted the code using go fmt (if applicable)
[X] Updated documentation on the Paralus docs site (if applicable)
[X] Updated CHANGELOG.md

Codecov Report

Merging #155 (1d68a6a) into main (99cb376) will not change coverage.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@           Coverage Diff           @@
##             main     #155   +/-   ##
=======================================
  Coverage   34.64%   34.64%
=======================================
  Files          74       74
  Lines       11609    11609
=======================================
  Hits         4022     4022
  Misses       7046     7046
  Partials      541      541

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

repo: paralus/paralus


text:
Add social media icons to top of article pages

 Add social icons to top of article


text:
Support GUI configuration and improve UI response

This original goal of this PR  was to implement a config flow to allow the integration to be configured via the GUI.
When configured via the GUI a new device with a media player entity is now created.
I got a bit out of hand and I overhauled a number of other things

Removed usage of deprecated consts in favor of enums
Fixed an issue with unsubscribing
Preemptively updated local media player state instead of waiting for the topic. I found that shairport sync does not immediately send an "play_end" but instead a "play_flush" when paused and the lag was annoying.

This is awesome, @mill1000!
On the surface, this all looks good and is a nice catch-up on some Python (annotations) and HA updates. I've been thinking about implementing the config flow stuff, but I'm super short on time.
If you could also update the README to state which version you've tested with, I'd be happy to merge this. My own testing has just been against the one version I typically run.
My system using this is currently shut down, but I'll spin it up again soon (and probably upgrade everything on the Pi), which means I'll be in a better position to work on this project again and to test stuff.
For now, if we can just state which is the known version this was tested again, we're good to go (HA and Shairport Sync's versions).

@parautenbach, I think this is good to go know.

Muchas gracias!

repo: parautenbach/hass-shairport-sync


text:
Extended Go support

I've only done a light investigation on this, so this may still be bogus.
Elf symbols (.symtab) are often stripped using -ldflags="-s -w", but the .gosymtab elf section is almost always there, ideally we convert .gosymtab to a “normal” elf debug symbol table (.symtab), if it's not already the same, and upload that as debug info as if they had been there the entire time.
Edit: According to this email thread .gosymtab is empty and the content of .gopclntab is what we should be able to use.

Done, except #292

authors: brancz kakkoyun

repo: parca-dev/parca-agent


text:
client: RPC message too big

Just so I don't forget to look into this. I've occasionally stumbled upon this error

level=debug ts=2022-05-25T09:42:00.90387003Z caller=write_client.go:92 msg="batch write client failed to send profiles" retry=2.604991381s count=1 err="rpc error: code = Internal desc = failed to normalize pprof: Key with size 96032 exceeded 65000 limit. Key:\n00000000[...]"

Possible duplicate https://github.com/parca-dev/parca-agent/issues/203

I did some troubleshooting on this issue and I think the error message is come from the badger. This line of code(https://github.com/dgraph-io/badger/blob/master/txn.go#L357) match the error message above. Let me study how to fix this.

I think this issue is fixed by https://github.com/parca-dev/parca/pull/1178. Since this PR introduce some hashing to reduce the length of key.

@kakkoyun sounds good to me! Closing it, let's keep an eye just in case it happens again

authors: heylongdacoder javierhonduco kakkoyun


text:
.eh_frame: Initial ASLR support

Right now, processes that are loaded at a randomized address won't work
with the current dwarf-based stack unwinding code. The reason for this
is that the program counters aren't adjusted accordingly.
This commit adds a new package under pkg/executable that will host
code specific to executables. The IsASLRElegible is documented inline,
it's a pretty basic function and doesn't handle some edge cases, but
this should do for most of the processes I've tried in my host (see test
plan of this PR and in the upcoming sharded unwind table work).
In the future, this will be refactored in a more cohesive module that
will do more groundwork necessary for other parts of the profiler.
Caching will be added later on, too.
The first commit updates the testdata repository which adds the PIE executables.
Test Plan
Added unittest
[javierhonduco@fedora parca-agent]$ go test -v github.com/parca-dev/parca-agent/pkg/executable
=== RUN   TestASLRDisabled
--- PASS: TestASLRDisabled (0.00s)
=== RUN   TestASLREnabled
--- PASS: TestASLREnabled (0.00s)
PASS
ok      github.com/parca-dev/parca-agent/pkg/executable (cached)

e2e test
./testdata/out/basic-cpp-plt-pie

make build-dyn ENABLE_ASAN=yes &&  sudo dist/parca-agent-dyn --node=test --remote-store-insecure --remote-store-address=localhost:7070 --experimental-dwarf-unwinding-pids=`pidof basic-cpp-plt-pie`

Oops, sorry, thought auto merge would not only wait for CI, but also for at least 1x approval


text:
🛑 pdf-attr-extraction is down

In f5a98c8, pdf-attr-extraction (https://ai-prod.parspec-cp.io/health) was down:

HTTP code: 502
Response time: 9249 ms

Resolved: pdf-attr-extraction is back up in c93db4e after 19 minutes.

repo: parikshit-parspec/upptime


text:
DOC Changelog for version 0.8

This adds the changelog for version 0.8 (current master).
I'm going to make a release of the current master so that ramp.studio can be updated.
@glemaitre (or someone else with write permissions) Would you be able to push releases to PyPi, once the release is done?

Yes I can push. However, the CI in 0.8.X is broken

The failure is when uploading codecov coverage with,
    {'detail': ErrorDetail(string='Unable to locate build via Github Actions API. Please upload with the Codecov repository upload token to resolve issue.', code='not_found')}
Error: Codecov failed with the following error: The process '/bin/bash' failed with exit code 1

Restarting doesn't help. I think it's that particular commit so probably not too critical. Other CI issues should be resolved with https://github.com/paris-saclay-cds/ramp-board/issues/514

authors: glemaitre rth

repo: paris-saclay-cds/ramp-board


text:
Approach to retries

When an RPC server disconnects unexpectedly, do we attempt to reconnect, re-send any egress messages, misc? How about for transactions? If the user has encoded the transaction with a nonce and window of validity, yes. What if they have not? Should users need to explicitly opt into retry behavior? Should they specify their own back-off algorithm? Should they specify their own fallback logic beyond simply re-sending? A lot of questions to answer regarding approach to retries.

Message retry seems to depend on the message type.
Perhaps messages can be categorized in idempotent vs non-idempotent messages (like REST) depending on the operation that they trigger.
For example,

in a subscription to chain_subscribeNewHead, a subscription retry should be fine
in a author_submitAndWatchExtrinsic, an extrinsic retry should not be fine but a retry to monitor the extrinsic events should be fine

This leads me to think that the message producer needs some context to decide if a call/subscription can be retried.
Then, for message delivery strategies, there could be messages that are

fire and forget
fire and acknowledge success/failure
fire, retry x times and acknowledge success/failure
fire, timeout and ...

I completely agree with everything you wrote. Especially...

Perhaps messages can be categorized in idempotent vs non-idempotent messages

... and...

the message producer needs some context to decide if a call/subscription can be retried.

I think it's up to us to ensure that the necessary context is accessible to the developer, who can use it alongside their own monitoring/resubmission logic. Mocking out some example scenarios would be a good idea... assuming we think message-specific retries is an early priority (not so sure that it is––what're your thoughts?).
However... for fun, let's play this out a bit more. Your 4 bullet points highlight some key considerations, such as how do we identify whether a non-idempotent message has been received?, what stage it is in?, do we need to await confirmation that the message did not go through before resubmission?.
As I write out these questions, the hard-coding of use-case specific handling seems undesirable––even for std effects. Even if we do it "right," it will be "wrong" for some consumers. Probably best to steer clear of most message-related retries for now.

As I write out these questions, the hard-coding of use-case specific handling seems undesirable––even for std effects. Even if we do it "right," it will be "wrong" for some consumers. Probably best to steer clear of most message-related retries for now.

Yes, it seems that message retry should not be responsibility of the RPC client.
For now, it would be better to throw an error (as we currently do) and let the developer do the resubmission depending on the use-case.
In the future, we could add some helper utils to do the retries and I believe that those helpers do not need to be part of the RPC client implementation.

For reference: #492 #502

Let's create an examples/retries directory and showcase common things that one would want to retry. For instance, a redacted.eg.ts.

authors: harrysolovay kratico tjjfvi

repo: paritytech/capi


text:
feat: add reserve transfer example

Add reserve transfer asset example between Statemine and Trappist.
This example uses trappist#22755b2 which is compatible with polkadot v0.9.37 and polkadot-parachain v0.9.370
The example steps are

In Rococo, create a sufficient asset on Statemine (reserve parachain)
Notes

asset should be sufficient to be able to pay fees in Statemine
root is needed to create a sufficient asset
in a common good parachains, root is accessed through the relay chain

In Statemine, mint the new reserve asset
In Trappist, create an asset to pair it with the Statemeine reserve asset
In Trappist, register Trappist AssetId to Statemine AssetId
In Statemine, make a reserve transfer asset to Trappist

@harrysolovay @tjjfvi I need to setup docker to debug the GH action issue
In the meantime, feedback is welcome

Let's wait to merge this until after #823

@kratico Devnets has been merged, but it'll need to be modified to set up the hrmp channels.

authors: kratico tjjfvi


text:
Don't use saturated_into in informant

We should require the BlockNumber to implement Display + Serialize for the informant as a local where bound.
https://github.com/paritytech/substrate/pull/2602_

The issue here is that the informant shows for example "4.2 blocks per second".
It's not really possible to have decimal values, unless we hack together something by printing {}.{} and assuming that the block is displayed as a number.

A solution could be to use TryInto<u128>. If it succeeds, show decimals. If it fails, show a rounded integer.

authors: bkchr tomaka

repo: paritytech/substrate


text:
contracts: implement ext_runtime_get_storage

In order to allow smart contracts to query runtime storage, a new ext_ function is required:
fn ext_runtime_get_storage(key_ptr: u32, key_len: u32) -> u32

I've implemented a quick prototype: https://github.com/paritytech/substrate/compare/aj-contracts-get-storage.
However this is hard coded to hash the key twox_128(key)
Assuming we don't expect the contract itself to perform the key hashing, the remaining problem to solve is the API for correct hashing of keys for different storage types:

Value twox_128(key)
Map blake2_256(prefix + key)
Map2 twox_128(prefix + key)
LinkedMap blake2_256(prefix + key)
LinkedMap2 twox_128(prefix + key)
DoubleMap blake2_256(prefix + key) + blake2_256(key2)
DoubleMap2 twox_128(prefix + key) + twox_128(key2)

Rel: https://github.com/paritytech/ink/pull/204

Related previous discussion: #2214

Access the storage directly will make it very hard / impossible to upgrade runtime module storage format because it means all the contracts have to upgrade as well.

authors: ascjones xlc


text:
#[derive(MaxEncodedLen)]

Part of https://github.com/paritytech/substrate/issues/8719.

bot merge


text:
Next key storage cache.

This PR add a cache for next_key calls. At this point it really lacks testing.
But as the PR is already getting bit big, I am opening it as Draft PR to get initial feedbacks.
cc\ @arkpar
The cache is a btreemap containing key accessed when doing next_key call.
It stores the queried key with a state CachedInterval::Next and the resulting key with a state CachedInterval::Prev.
So CachedInterval::Next is not always an existing value (and can be remove when its interval is included in another).
When two cached interval are contigus, the common key changes its value to CachedInterval::Both.
This works as other storage cache: a local cache that get merge in shared lru cache.
When getting change from a new best block, cache intervals containing changes are updated (split if insert in interval,
merge or removed when remove).
On reorg, the cache intervals with changes are simply removed for modified keys.
Usage of BTreeMap is a bit awkward sometime (no good iterator api so ranges iterator are used).
Lru cache is implemented by adding managing a lru linked list through unsafe code.
This allows sharing Lru between top trie and child trie.
It could also be extended to storage maps to remove ratio definition (for child storage cache it would be
good in order to split to multiple maps).
Possibly could switch to storing key associated to its next_key in btreemap, and limit caching
to exact same key call.
Usually next_key is use for iterating so the case where key are random is just the first call
which usually is a fix value.
So should not really be worst, probably smaller for random calls, and a bigger for iteration.
Branch https://github.com/paritytech/substrate/compare/master...cheme:next_key_single_cache contains a version with a single cache limit for all LRU, it is better I think (will switch to it when clean).

Would be good to get an estimation of the performance improvement first. E.g. importing recent 10k polkadot or kusama blocks. End of epoch blocks are the most heavy on storage iteration and it is not really clear if with default cache size and ratio there will be any positive effect for such blocks.

I think CachedInterval design is not very good (avoid storing some key but make thing generally more complicated than just storing next_key), and will switch to storing just next key result with a Rc.

I did rework the logic to store a next key result per entry (instead of CachedInterval).
I am not 100% happy with the Rc part, but logic is simpler overall.
I also isolate LRU unsafe stuff, looks a bit better in my opinion.

Would be good to get an estimation of the performance improvement first. E.g. importing recent 10k polkadot or kusama blocks. End of epoch blocks are the most heavy on storage iteration and it is not really clear if with default cache size and ratio there will be any positive effect for such blocks.

@arkpar, I did run block import on polkadot for Imported 14465 blocks. Best: #5829204.
See no visible improvement.
Tracing next key access I indeed got 19k cache miss and 1k local cache hit. Shared cache is never hit.
19k are staking nominators storage map.
1k is staking validators and staking slashing spans storage map.
The 1k cache hit probably got some effect but nothing really visible without proper benchmarking (I only ran the import blocks process).

I am maintaining the branch, not sure if it is worth it.
For relay chain gains are hard to spot (current iteration of keys are spaced in time so I doubt it would help).
I still find https://github.com/paritytech/substrate/compare/master...cheme:next_key_single_cache branch interesting for using a single cache size limit for top trie and child trie.
CC\ @arkpar , to finalize this PR I would basically just need confirmation it's needed and also if cache design is ok (storing start_key and end_key with interval direction rather than just next_key for each start_key).

Tracing next key access I indeed got 19k cache miss and 1k local cache hit. Shared cache is never hit.

This is suspicious. There should be at least some hits, right?
The design looks good, but I don't think the added code complexity is worth it, if there's no measurable effect. If it works as intended, but the overall performance does not change much let's just archive it. It was an avenue worth exploring and we might get back to it if it becomes more relevant.

This is suspicious. There should be at least some hits, right?

I did look for duplicate of accessed key when doing the logging and did not really find occurence of uncached calls on same next key.
May be some careful implementation of runtime to avoid sate iteration as much as possible (since it is known to be slow).
But I was a bit surprise too.
Archiving for now.

authors: arkpar cheme


text:
get rid of confusing ACTIVATION_FRAME_COST constant

Hi, I'm working on adding a custom stack limiter for our protocol. It will provide API like that: (e.g. you can inject something instead of unreachable instruction)
wasm_instrument::inject_custom_stack_limiter(module, 20_000, |signature| vec![
    Instruction::Foo,
    Instruction::Bar,
    ...,
])

And I think I understood what the real problem was at #1
https://github.com/paritytech/wasm-instrument/blob/6307588b3dc508d8b24ee64c364841d89e558ec2/src/stack_limiter/mod.rs#L10-L19
So we have an instrumented_call! with a maximum stack height of 2, the same as the ACTIVATION_FRAME_COST constant.
// stack_height += stack_cost(F)
GetGlobal($stack_height_global_idx), // push #1
I32Const($callee_stack_cost), // push #2
// max_height = 2

Backing to problem #1: the function with index 0 has no arguments and no return value, so its max_height=0
(module
  (type (;0;) (func))
  (func (;0;) (type 0)
    call 0)
  (func (;1;) (type 0)
    call 0)
  (export "main" (func 1)))

We also have a main export that will call function 0 and it will not be instrumented due to the condition:
https://github.com/paritytech/wasm-instrument/blob/6307588b3dc508d8b24ee64c364841d89e558ec2/src/stack_limiter/thunk.rs#L44-L48
What is the best way to solve this problem? When the Call(idx) opcode is found, we need to check that idx is not an import and simply do:
let import_count = module.import_count(elements::ImportCountType::Function);
let mut max_height: u32 = 0;
let mut overhead_of_instrumented_call = 0;

...

match opcode {
    Call(idx) => {
        if idx >= import_count {
            overhead_of_instrumented_call = 2;
        }
    }
}

Ok(max_height + overhead_of_instrumented_call)

or we can start passing instrument_call! instructions instead of Call(idx) to match opcode

But even with non-imports the problem can arise if they have a zero cost without the constant?
Also, you still need the constant if the callee is an import?

But even with non-imports the problem can arise if they have a zero cost without the constant?

It should not because we need to charge for overhead of the instrumented call instructions. For example, instead of calculating the stack height for Call(0) we will replace the Call(0) with info[0] (sequence that we got from instrumented call! macro)
In this case, a call that does not change the stack will still cost 2.
#![feature(if_let_guard)]

#[derive(Debug, Clone, PartialEq, Eq)]
pub enum Instruction {
    Foo,
    Bar,
    Baz,
    Call(usize),
}

fn process(opcode: &Instruction) {
    println!("{opcode:?}");
}

fn main() {
    use Instruction::*;

    let info = vec![vec![Foo, Bar, Baz]];
    let xs = vec![Foo, Bar, Baz, Call(0), Foo];

    for opcode in xs.iter() {
        match opcode {
            Call(i) if let Some(slice) = info.get(*i) => {
                for opcode in slice {
                    process(opcode);
                }
            }
            _ => process(opcode),
        }
    }
}

Also, you still need the constant if the callee is an import?

Why do I need this constant if instrument_function will not process imports (since they have zero cost)?
https://github.com/paritytech/wasm-instrument/blob/0c739d92c453c2a1ff8a2a3c44e7299ff446ea94/src/stack_limiter/mod.rs#L164-L165
https://github.com/paritytech/wasm-instrument/blob/0c739d92c453c2a1ff8a2a3c44e7299ff446ea94/src/stack_limiter/mod.rs#L260-L266
For example, we have module
(module
  (import "env" "nop" (func $nop))
  (func $f1 (export "f2")
      call $nop
  )
)

After instrumentation:
(module
  (type (;0;) (func))
  (import "env" "nop" (func $nop (;0;) (type 0))) ;; cost of import = 0
  (func $f1 (;1;) (type 0) ;; cost of func = 0
    call $nop ;; it will not be processed by the `instrument_function`
  )
  (global (;0;) (mut i32) i32.const 0)
  (export "f2" (func $f1)) ;; thunk function is not created here, bcz we can safely call to original
)

What I am saying is that this is not only about imports is it? You can just call an zero cost function recursively without a constant cost for the activation.

I think you mean that example with empty functions, right? If you look at the PR, the tests pass and I'll explain why.
So we have function 0, which actually costs 0 (no params, nor results)
(func (;0;)
  call 0
)

but after the injection stack limiter it will look like this:
(func (;0;) (type 0)
  global.get 0
  i32.const 2
  i32.add
  global.set 0
  global.get 0
  i32.const 1024
  i32.gt_u
  if ;; label = @1
    unreachable
  end
  call 0
  global.get 0
  i32.const 2
  i32.sub
  global.set 0
)

Instead of counting the cost of Call(idx=0) we will count cost of instrument_call!(idx, 0, 0, 0). Therefore this function will have a maximum stack height of 2, not 0.

repo: paritytech/wasm-instrument


text:
Module::len_globals() incorrectly returns number of linear memories

I believe the code for len_globals is wrong here -- a copy-paste error from len_memories above:
https://github.com/paritytech/wasmi/blob/799995da7afb0ae02bb4fd1c9f242fe07c7ad824/crates/wasmi/src/module/mod.rs#L187-L189

@graydon good catch! very strange that this one was not caught before. Going to need further inspection.

Can I work on this?

@deepto98 Yes please. :)

authors: Robbepop deepto98 graydon

repo: paritytech/wasmi


text:
Bump .net Version

Bumped dotnet-sdk from 3.1 to 5.0
Added dotnet-runtime-5.0
Closes https://github.com/parkervcp/eggs/issues/1148

@parkervcp Any chance to get this merged?

repo: parkervcp/images


text:
npm ERR! libui-node@0.2.1 build: node-gyp configure build

git clone https://github.com/parro-it/libui-node.git
npm install
gyp ERR! configure error
gyp ERR! stack Error: `gyp` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onCpExit (/usr/lib/node_modules/npm/node_modules/node-gyp/lib/configure.js:345:16)
gyp ERR! stack     at ChildProcess.emit (events.js:182:13)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:240:12)
gyp ERR! System Linux 4.14.89-desktop-1.mga6
gyp ERR! command "/usr/bin/node" "/usr/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "configure" "build"
gyp ERR! cwd /home/disp/ideaworkspace/libui-node
gyp ERR! node -v v10.13.0
gyp ERR! node-gyp -v v3.8.0
gyp ERR! not ok
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! libui-node@0.2.1 build: `node-gyp configure build`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the libui-node@0.2.1 build script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/disp/.npm/_logs/2019-01-25T08_01_09_978Z-debug.log
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! libui-node@0.2.1 install: `libui-download && autogypi && npm run build`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the libui-node@0.2.1 install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/disp/.npm/_logs/2019-01-25T08_01_10_033Z-debug.log

Fixed, using this command.
sudo apt install libgtk-3-dev

repo: parro-it/libui-node

license: mit


text:
Adjust histogram look

remove the space between bars
related to the hist colors :
@parrt, you made a reference to this picture : https://github.com/tlapusan/dtreeviz/blob/master/testing/samples/iris-TD-2.svg. This is an histogram which adapts its colors based on number of classes. In ctreeviz_leaf_samples picture, we have a more general histogram, showing the distribution of leaf samples (not related to classes).
I found in colors.py the LIGHTBLUE constant and assign this color to the ctreeviz_leaf_samples histogram, but I'm not sure if it's the right one. If not, please suggest what color would you prefer :)

Cool. i'll merge and take a look. Less  concerned with the color and more about the look of the histograms.

authors: parrt tlapusan

repo: parrt/dtreeviz


text:
Feature suggestion: keep whole words, not cut them in half

Hello again!
Just a quick feature suggestion this time. How about keepWholeWords prop, that - if set to true - would make react-truncate-markup keep full words and not cut the in half? At the moment I keep getting truncated words, i.e. se (whole word is sed):

In this example this flag set to true could then render something like this:

So basically: if the word is going to be cut in half, just omit it in the result.
I tried to prepare a PR with this, but I got lost in the source code of this repo. I might try again during weekend though

Actually all the magic for this case happens in the splitString method. Currently we split strings in half, but with this "whole words" option we need to split it into words first, then split the list of words in half and concatenate again before returning it as a string again.
We would probably need to allow for the trailing space before ellipsis though, I'll need to think about that.
In the meantime, if you want to tackle the word truncation logic (without the trailing space), you might find the test app in the repo useful. Go to __tests__/app, install dependencies and run yarn develop - it'll start a dev server for examples in __tests__/app/src/pages dir and it'll autoupdate on any TruncateMarkup component src change

Wow! Love the description, thanks! I'll see what I can do :)

I've just sat down to this, since there is little work to be done this week. I started with something like this:
diff --git a/README.md b/README.md
index 91389a1..01eec00 100644
--- a/README.md
+++ b/README.md
@@ -153,6 +153,12 @@ const wordsLeftEllipsis = (rootEl) => {

 Numeric value for desired line height in pixels. Generally it will be auto-detected but it can be useful in some cases when the auto-detected value needs to be overridden.

+### `keepWholeWords`
+
+> default value: false
+
+Boolean value. If set to true, the truncation will keep whole words, rather than cut them in half. Defaults to `false` for backward compatibility.
+
 Contributing
 -----

diff --git a/index.d.ts b/index.d.ts
index 68c16a2..d63afec 100644
--- a/index.d.ts
+++ b/index.d.ts
@@ -4,6 +4,7 @@ export interface TruncateProps {
     lines?: number;
     ellipsis?: React.ReactNode | ((element: React.ReactNode) => React.ReactNode);
     lineHeight?: number | string;
+    keepWholeWords?: boolean;
 }

 declare class TruncateMarkup extends React.Component<TruncateProps> {}
diff --git a/src/index.js b/src/index.js
index d7c3f38..4a0e92c 100644
--- a/src/index.js
+++ b/src/index.js
@@ -59,12 +59,14 @@ export default class TruncateMarkup extends React.Component {
       PropTypes.func,
     ]),
     lineHeight: PropTypes.oneOfType([PropTypes.string, PropTypes.number]),
+    keepWholeWords: PropTypes.bool,
   };

   static defaultProps = {
     lines: 1,
     ellipsis: '...',
     lineHeight: '',
+    keepWholeWords: false,
   };

   state = {
@@ -303,6 +305,35 @@ export default class TruncateMarkup extends React.Component {
     return cloneWithChildren(node, newChildren, isRoot, level);
   }

+  regexIndexOf(string, regex, startPos) {
+    const indexOf = string.substring(startPos || 0).search(regex);
+    return (indexOf >= 0) ? (indexOf + (startPos || 0)) : indexOf;
+  }
+
+  getSplitStringPivotIndex(string) {
+    let ret, method;
+    if (this.props.keepWholeWords) {
+      const indexes = [];
+      for (let index = 1; index < string.length - 1; index++) {
+        if (/\W/.test(string[index])) {
+          indexes.push(index);
+        }
+      }
+      if (indexes.length === 0) {
+        ret = Math.ceil(string.length / 2);
+        method = 'fallback';
+      } else {
+        ret = indexes[Math.floor(indexes.length / 2)];
+        method = 'words';
+      }
+    } else {
+      ret = Math.ceil(string.length / 2);
+      method = 'letters';
+    }
+    console.log(method, ret, string);
+    return ret;
+  }
+
   splitString(string, splitDirections = []) {
     if (!splitDirections.length) {
       return string;
@@ -324,7 +355,7 @@ export default class TruncateMarkup extends React.Component {
     }

     const [splitDirection, ...restSplitDirections] = splitDirections;
-    const pivotIndex = Math.ceil(string.length / 2);
+    const pivotIndex = this.getSplitStringPivotIndex(string);

     if (splitDirection === SPLIT.LEFT) {
       const subString = string.substring(0, pivotIndex);

But the outcome is actually same as without the keepWholeWords prop (and it's because of the "fallback"). Without the fallback it enters infinite loop :(
I'm trying to get it working, but no success for now.

Hey @burtek, I'm going away for a month, if you won't manage to get it working, I'll take a stab at it when I get back!

Hopfully solved here https://github.com/parsable/react-truncate-markup/pull/18 :)

Indeed @stropho!

authors: burtek patrik-piskay stropho

repo: parsable/react-truncate-markup


text:
Hardware usage

Hello
Thank you for the great paper work.
I am slightly overwhelmed by the hardware usage that was written in the appendix.
Can you verify how much memory was used while training?
Using 528GB ram and eight A6000 GPUs does not convince me when analyzing the model.
Can you give details how much memory you used while running the model?
Thank you.

Also can I have a clue of the training time and inference time? Thank you

The training time for one epoch is ~2 mins for MIMIC-III mortality prediction.

authors: KyunghoonJeon pat-jj

repo: pat-jj/GraphCare


text:
Cannot use the ember-message-bus

I try to use 'ember-message-bus' module in my EmberApp but I can't, when I try to inject it, it shows me this error.
Error: Assertion Failed: Attempting to inject an unknown injection: 'service:message-bus'

I take it you figured things out?
On Fri, Mar 9, 2018 at 11:51 AM, Jeton Kadrija notifications@github.com
wrote:

Closed #6
https://github.com/patience-tema-baron/ember-message-bus/issues/6.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/patience-tema-baron/ember-message-bus/issues/6#event-1513677313,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACk2SMdzjkrM1ze8A9MbFa7ch2YcqfsJks5tcrMCgaJpZM4Skh78
.

authors: jetonk patience-tema-baron

repo: patience-tema-baron/ember-message-bus


text:
Possible bug in AdaptivePool

The following code seems to fail
import numpy as np
from torch import nn
import torch
import jax
import equinox as eqx

print(torch.__version__, eqx.__version__)

random_input = jax.random.normal(jax.random.PRNGKey(1), (10, 90, 90, 50))

ppool = torch.nn.AdaptiveAvgPool3d(4)
jpool = eqx.nn.AdaptiveAvgPool3d(4)
random_input_torch = torch.tensor(np.asarray(random_input))
pp = ppool(random_input_torch)
jj = jpool(random_input)

assert np.allclose(np.asarray(pp), np.asarray(jj)), print(np.asarray(jj) - np.asarray(pp))

Not sure if I'm missing something here, I just stumbled upon this trying to convert an Equinox model to pytorch.
I tried going over AdaptivePool but couldn't really figure out the problem. Same thing happens when using 2d pooling btw. Happy to make a PR fixing the issue with some guidance

I think this is expected -- I think the adaptive part of our pooling works in a slightly different way, as it was more computationally efficient for us to do it that way. (Adaptive pooling was added back in #129, although I don't see any discussion of PyTorch consistency there.)
Tagging @paganpasta in case they recall any other information.
Perhaps we should simply document this discrepancy?

Going through the corresponding issue (https://github.com/patrick-kidger/equinox/issues/121), it looks like we implemented adaptive pooling differently from PyTorch infavor of (potential) speed-up. The main difference being how shapes are carved from the original tensor.
Hope this helps.

Regarding performance, I think we achieved similar performance to PyTorch because we implemented it slightly differently. If we'd matched PyTorch exactly (i.e. chosen different pooling regions), then we'd have ended up being slightly slower.
If it does turn out to be possible to change things to match PyTorch, without a significant speed difference, then I'd be happy to take a PR on that.
Else, I'd suggest we should probably document this difference but otherwise just accept that we do things slightly differently.

@paganpasta yeah I got similar performance for both models (pytorch vs eqx one). I just tried porting my model to pytorch (collaborators still use torch) and a sanity test of getting the same output failed

I'm afraid getting precise compatibility between the frameworks is pretty hard. Even for the same algorithm then one sometimes gets meaningful differences in output, just due to the differences in the underlying compilers etc.
I think adaptive pooling and batch norm are the two places where we do something algorithmically different. Although we do have a PR out to change the latter, see #675. (That I really need to review...)
For something like max pool I thought we were the same. There's only one way to compute a maximum, after all.
In general we don't tend to diverge from PyTorch without a good reason, so I think most other layers should be compatible. FWIW I translate models PyTorch->Equinox (in my non-open-source actually-paid work!) and generally observe the same behaviour between the two libraries. When this is important I make sure to also include that as part of the tests for my Equinox implementation.

authors: paganpasta patrick-kidger yardenas

repo: patrick-kidger/equinox


text:
add Processor class

Hey Patrick Von Platen,
I love your repo and I'm using it to create my own ControlNet datasets etc :D
I made a general Processor Class that makes it even easier to load in your different models. Currently I just copied the code from my processing pipeline, but let me know if you would like to add it to your repo, then I can clean it up, add some more functionality and integrate it will your folder structure.
You just need to pass the processor_id and it will load in the correct processor!
I will still add functionality to put the model-based processors on CUDA etc and I can also change the way the user can choose the processor arguments (e.g. hand_and_face = True, ...)

Thanks for merging! However there still have to be some changes to make it fully functional with your code, I’ll make the changes and test them asap 😁


text:
Updating.

I use this system to run an Ark Survival: Ascended cluster.
Every time there is a large update, the system seems to stop functioning.
After the first detection of the update the log file will end with "Updating  Regular Build."
Each successive check results in "PS>TerminatingError(): "System error.""
I have to go and manually delete the lock file and update each server one by one.
Is there a way to use a download cache?
Update the first map, then copy the install across to the rest.
Or even just use a single install and just run multiple instances?

You can use the same server folder for multiple instances.
Replace the value of $Name by a plain text folder name for the following configuration options:
#Server Installation Path
Path                   = ".\servers$Name"
#Server configuration folder
ConfigFolder           = ".\servers$Name\ShooterGame\Saved\Config\WindowsServer"
#Server Executable
Exec                   = ".\servers$Name\ShooterGame\Binaries\Win64\ArkAscendedServer.exe"
Disable backups and auto-update for all but the main instance.
Set UsePID to $false in the main instance in order for the launcher to close all the instances at once before an update.

No sadly only the main instance will get the warning.

Please forgive the late reply, I have done as recommended, however the main instance is still having issues.
The main instance dosnt shut down the other instances. Main instance UsePID is set to $false.
The main instance starts to update, then for some reason stops.
At every scheduled Task check the main instance then returns Script error
I then have to manually delete the .LOCK file, Manually end all instances then start the main instance first, once its finished and loaded THEN start the other instances.


text:
Hide credentials from the code, use env variables instead.

Just an idea and I think it would be helpful since generally, we don't want to hard code our credentials to the code. Right now I have replaced the value of DB credentials in Constant.scala which holds me back from pushing the code to the cloud.

@tp-cai sorry probably have missed this, The db credentials can be provided via config. is that good enough? https://github.com/patsonluk/airline/blob/master/airline-data/src/main/scala/com/patson/data/Constants.scala#L190

authors: patsonluk tp-cai

repo: patsonluk/airline


text:
fix: unified font size to 16px

This is an extremely tiny change to Jump Links that resolves a font size mismatch.
Related issues

(#1859 ) Description of issue

Preview

Link(s) to demo page(s) where this element can be viewed:

Link

What has changed and why

The only files that have changed are a lockfile and sass file.

Testing instructions

[ ] Test case #1

Go here
Do this

[ ] Test case #2

Go here
Do this

Browser requirements
Your component should work in all of the following environments:

[ ] Latest 2 versions of Edge
[ ] Internet Explorer 11 (should be useable, not pixel perfect)
[ ] Latest 2 versions of Firefox (one on Mac OS, one of Windows OS)
[ ] Firefox 78 (or latest version for Red Hat Enterprise Linux distribution)
[ ] Latest 2 versions of Chrome (one on Mac OS, one of Windows OS)
[ ] Latest 2 versions of Safari
[ ] Android mobile device (such as the Galaxy S9)
[ ] Apple mobile device (such as the iPhone X)
[ ] Apple tablet device (such as the iPhone Pro)

Ready-for-merge Checklist

[ ] Expected files: all files in this pull request are related to one request or issue (no stragglers or scope-creep).
[ ] Tests have been updated to cover these changes.
[ ] Browser testing passed.
[ ] Changelog updated.
[ ] Documentation (README.md, WHY.md, etc.) updated or added.
[ ] Link to the demo recording:
[ ] Approved by designer.

Merging
Please squash when merging and ensure your commit message uses conventional commit formatting.
Be sure to share your updates with the patternfly-elements-contribute@redhat.com mailing list!

@coreyvickery

@Djfaucette We were pleased to merge pfe-2 earlier today. If this PR is still relevant, would you like help updating it?

@bennypowers I think that depends on the ETA of adoption for redhat.com
If it's less than 3 months I say we close this. In fact, I'll go ahead and close it. If the timeline is longer and we need to patch 1.x I'll let you reopen.

authors: Djfaucette bennypowers

repo: patternfly/patternfly-elements


text:
fix(table): fixed bug with mobile inheritable grid-column property

fixes https://github.com/patternfly/patternfly-next/issues/2557

PatternFly-Next preview: https://patternfly-next-pr-2558.surge.sh

Side note: looks like we lost table--id prop on tables that need it.

Should we update that here or open a new issue?

@mattnolting doh! looks like it was lost in this MDX conversion https://github.com/patternfly/patternfly-next/issues/2242
updated

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

authors: mattnolting mcoker patternfly-build redallen

repo: patternfly/patternfly-next


text:
JSX syntax highlighting

I am using patternplate for a React.js project.
All code blocks in my markdown files are labeled with ```jsx.
Result: nested elements are not highlighted correctly.
Related issues (via hightlight.js): https://github.com/isagalaev/highlight.js/issues?utf8=✓&q=jsx

Comparison: Codemirror.runMode
This might be an option.
CodeMirror.runMode(value, mode, node)

Sure, let's fix this.
Let's have a look at https://github.com/craftzdog/react-codemirror-runmode/blob/master/src/index.js to inform our implementation.

Had a look at this, CodeMirror doesn't play well with Node.js apparently :/

Maybe we can find some ideas here:
https://github.com/JedWatson/react-codemirror/issues/21
https://github.com/TypeCtrl/ngx-codemirror/pull/2

Looked into the referenced issues and code mirror def. does not support SSR - the supplied fixes conditionaly omit problematic requires on the server and disable code mirror.
I don't think there is a straightforward solution given only highlight.js runs universally and seems to have troubles fixing this.

Looking at https://github.com/wooorm/refractor we just might be able to use Prism highlighting on the server. We should give it a spin.

Release as of 2.5.25

authors: marionebl pixelass

repo: patternplate/patternplate


text:
heart rate measurement characteristics not read

I used heart rate data for mi band4, 5
"00002a37-0000-1000-8000-00805f9b34fb" this uuid can be read on iOS, but not on Android.
Android was this characteristics.properties.read = false
but iOS return true
and also bonded using the mi band official app.
what should i do to solve this problem?
this is my code :
for (blep.BluetoothCharacteristic c in _service!.characteristics) {
  String uuid = "0x${c.uuid.toString().toLowerCase().substring(4, 8)}";
  if (c.properties.read) {
    if (c.isNotifying) {
      await c.setNotifyValue(true);
    }
    c.read();
    if (uuid == "0x2a37") {
      debugPrint(
          ":::::::::: Heart Rate Measurement => ${c.lastValue[1]} ::::::::::");
    } else if (uuid == "0x2a39") {
      debugPrint(
          ":::::::::: Heart Rate Control Point => ${c.lastValue[1]} ::::::::::");
    }
  }
}

how did you solve this problem?

@brutalzinn
i solved this problem used try ~ catch
If a catch error appears, it is already connected, and if there is no error, it is judged as disconnect.

how did you solve this problem?

@brutalzinn
i solved this problem used try ~ catch
If a catch error appears, it is already connected, and if there is no error, it is judged as disconnect.

authors: brutalzinn giroskii


text:
Missing src/JavaScriptViewEngine.Mvc5 project

Hi,
I pulled the latest and attempt to build using ./build.ps1 and I encounter errors from the Build task about a missing JavaScriptViewEngine.Mvc5 project reference. Also attempt to load the solution in VS and the JavaScriptViewEngine.Mvc5 project doesn't load. Looking at the path in the .sln file it's referencing src/JavaScriptViewEngine.Mvc5/JavaScriptViewEngine.Mvc5.csproj, which doesn't appear to be in the repo. Perhaps an issue with .gitignore?
Cheers!

Yup, there was a relic entry in .gitignore from old project.json stuff which caused some stuff not to be checked in. It is in there now.
Also, 1.5.0 is available, which has .NET Standard 2.

repo: pauldotknopf/JavaScriptViewEngine


text:
🛑 Taqueria Bonjour is down

In 706a084, Taqueria Bonjour (https://bonjour.paulynomial.com) was down:

HTTP code: 502
Response time: 12942 ms

Resolved: Taqueria Bonjour is back up in 768b4e2.

repo: paulkiernan/paulynomial-uptime


text:
Mongodb

For Issue #1

Closing PR but keeping branch.

repo: paulodiovani/men-starter-kit


text:
README

README
User Story
As a boot camp student,
I want the prework notes to be structured on a webpage,
So that I can easily find and read the information.
Acceptance Criteria
GIVEN the prework project repository,
WHEN I view the README for the repository,
THEN I can see a professional README that provides information on the project and how to use it

Closed, still need to update title.

repo: paulruggiero/Prework-study-guide


text:
🛑 Examples is down

In 067fd5d, Examples (https://examples.platform-os.com) was down:

HTTP code: 404
Response time: 452 ms

Resolved: Examples is back up in dcbb6e1.

repo: pavelloz/instances-uptimez


text:
Generate functional class names

First off, thank you for this lib! I've really enjoyed using it. I was wondering if you would be interested in allowing an option to generate functional class names instead of unique class names? Similar to what CXS does. I'd be willing to try out a PR :) just let me know.

Hey @souporserious! This is actually an issue for glamor. glamorous doesn't actually have anything to do with the generated class names. Mind filing an issue over there?
I'm glad that you've enjoyed using the lib!

Will do! Thanks!

authors: kentcdodds souporserious

repo: paypal/glamorous