text:
VirtualBox - Problem with graphical interface. User member of the wheel group

I recently set up a FreeBSD-13-Release using the "desktop-installer" (out of curiosity) on a VM in the Virtual Box. I installed the environment with XFCE. When I finished the procedure, I noticed an unusual behavior.
When trying to start the graphical interface, there was a problem and a blank screen is left with just the mouse pointer. I checked the entire environment and realized that the problem only happened with a user who was a member of the wheel group. When removing the user from the wheel group everything worked correctly.
Analyzing the situation better, I realized that the problem was being caused by the package "virtualbox-ose-additions-6.1.18" (services vboxguest_enable="YES" and vboxservice_enable="YES") that was automatically installed during the execution of "desktop-installer ".
When disabling these services, the problem disappeared and the user member of the wheel group can normally access the graphical interface.
Basically, if I activate the vboxguest and vboxservice services and the user is a member of the wheel group, the graphical interface (xfce) does not work.
I thought about reporting the problem to the maintainer of the "virtualbox-ose-additions-6.1.18" package, but I thought it was important to first communicate this to you and ask for your opinion.
To reproduce the problem:

Install FreeBSD-13-Release on Virtual Box
Set up the environment using "desktop-installer"
Add the common user to the wheel group
Restart the VM
Run XDM or
With a common user (member of the wheel group), execute "startxfce4".

The "desktop-installer" is great! It helped me to save a lot of time when setting up the desktop.
Thank's

Thanks very much for the PR.  I recently became aware of the issue and suspected the guest additions.
Are you running a FreeBSD guest on a FreeBSD host?  I have seen similar issues with a FreeBSD guest on a FreeBSD host, but a FreeBSD guest on MacOS works fine, as do other guest operating systems on a FreeBSD host.

Thank you for responding so quickly! I am currently using a FreeBSD guest on a MacOS High Sierra host. The virtualbox I use is in version "6.1.18 r142142 (Qt5.6.3)"

I verified that the same problem exists in a FreeBSD guest with Lumina desktop.  The symptoms are different, in that the Lumina desktop is rendered at login, but then doesn't respond to keyboard or mouse event.  I also confirmed that it only happens for members of the wheel group and with vbox guest/service enabled.
That was some nice detective work that should make it relatively easy to track down the issue.
This should be reported via https://www.freebsd.org/support/bugreports/.  You want to do the honors?  Before opening a new PR, though, let's see if your discovery is related to this one:  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254458

Ok, perfect. We will wait for an answer. Thanks!

Have you tried FreeBSD 12.2?  I have an older VM that works fine, but I don't know if it's because it's FreeBSD 12 vs 13, or if there is some other package or setting that makes it work.

I tested a FreeBSD-12 here and the same problem happened. In 12, even removing the user from the group "wheel", the graphical interface does not work, it is left with a blank screen with the mouse pointer. It only worked normally when I turned off the "vboxguest and vboxservice" services.
I tested it twice on two VMs:

I installed FreeBSD-12
I upgraded to the latest version:
freebsd-update fetch
freebsd-update install
run the desktop-installer
chose to install XFCE

In the end, I had to manually install the "xf86-video-vmware" package for the video to work. Without this package, Xorg will not work. I didn't realize before because I always install all the "xf86-video- *" packages, because it is easier for me to test the system in different environments.

That's very odd.  I tried xf86-video-vmware on my 13.0 guest, and it did not help.  It seemed to override the vbox guest additions.
At any rate, we should move this discussion over to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254458 since this is not a desktop-installer bug.

I suspect the problem is "virtualbox-ose-addions-6.1.18". In 12-Release and 13-Release they use the same version "6.1.18" and in both it is enough to deactivate it that everything works. I tested it on 12-Release just to try to help a little more. The problem is not really in the "desktop-installer". Let's wait for some response from the PR. Thank you very much for your help!

@snip3r what's the result for you with VBoxSVGA?

Indeed...
I see that my 13.0 VM defaulted to VMSVGA while 12.2 defaulted to VBoxVGA.
Switching the former for VBoxSVGA solves the display issue for root.
Just commented at https://github.com/outpaddling/desktop-installer/issues/8.
Maybe we should patch the port to default to VBoxVGA or VBoxSVGA on all FreeBSD versions until the VMSVGA issue is resolved.

my 13.0 VM defaulted to VMSVGA while 12.2 defaulted to VBoxVGA.

If you create a FreeBSD guest: regardless of version, the default is VMSVGA.

… patch the port to default to

Is that possible?

VBoxVGA or VBoxSVGA on all FreeBSD versions

Re: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254266#c7 as far as I can tell, if guest additions will be installed (I should assume so, with desktop environments), and if the host is FreeBSD, then the guest should use VBoxSVGA.
I assume that the same will be true for FreeBSD guests with non-FreeBSD hosts: VBoxSVGA.

until the VMSVGA issue is resolved.

As far as I can tell, there's no issue with VMSVGA. I assume that it works as intended where guest additions are not installed.

The default GPU must have changed recently, because I never altered the GPU emulation on any of my VMs.  Honestly never considered it until now since I'm not concerned about graphics performance.
Regarding the patch, I mean patch the virtualbox-ose port on the host to default to VBoxSVGA for all FreeBSD guests.  Once tested, upstream the patches and suggest they be applied to all host platforms.  I should have been more clear about this.
The issue with VMSVGS is it does not work for members of the wheel group if guest additions are installed.  Remove the user from wheel and guest additions work fine.  Do you believe this behavior is intentional?

… The issue with VMSVGS is it does not work for members of the wheel group if guest additions are installed. Remove the user from wheel and guest additions work fine. …

Not fine for me.
Windows 10 20H2 host, FreeBSD 13.0-RELEASE guest with sddm and KDE Plasma from latest. Previously working with VBoxSVGA and grahamperrin in wheel.
I removed grahamperrin from wheel, set the guest to use VMSVGA, started the guest, sddm fails to appear:

… guest additions work fine …

Including the bi-directional shared clipboard?

Maybe because sddm runs as root and uses syscalls that trigger the problem?  My test systems were using xdm, which works fine in any case.  The problem showed up after logging in as a member of wheel, so something in the desktop-env triggered it for me.
Haven't tested the clipboard and won't bother unless there's real interest in fixing vmsvga.

VMSVGA, wheel
For reference only (off-topic, and (at this time) I can't recommend using VMSVGA with virtualbox-ose-additions)

… Remove the user from wheel and guest additions work fine. …

With VMSVGA, and grahamperrin not a member of wheel, SLiM login to LXDE fails:

In summary, the problem is with the virtual VMSVGA device and FreeBSD guests.  Using VBoxSVGA appears to be the best choice.  Unfortunately, VirtualBox currently defaults to VMSVGA for FreeBSD.  This should probably be changed.  In any case, this is not a desktop-installer bug.

authors: grahamperrin outpaddling snip3r

repo: outpaddling/desktop-installer


text:
Remove line between "Edit Containers"  and "+"

to

Thanks! The fix for Containers extension has been included (I merged it locally, but that still retains authorship of the tweak).
I think the padding in the context menus might be good to keep to maintain similar spacing above/below all items and keep in similar to the original ones:

Left is no changes, right is with padding removed

Thanks for the merge!
Regarding the context menu, for the #context-navigation the padding creates a tiny grey-60 padding
above it which doesn't blend in very well.
I thought of two options to mediate this, either remove the padding or changing everything in the context menu to grey-60.
I chose for the latter option and left the padding now as is.

Removing the darker color on the top navigation buttons but be a good way to go.  I'll play with that look a bit.

The darker color on the navigation items has now been removed

source: gharchive/pull-request

authors: Shourai overdodactyl

repo: overdodactyl/ShadowFox

license: MIT

license_type: permissive

license_source: github-api


text:
Import 6b6699ceea: Added back accidentally removed laser pointer app from unpublished scripts (by Maki)

This is an automated proposal to look at a commit made by Maki and import it into Overte

Commit:
6b6699ceeaeaafcf640ceed54e25dc9996006e8f

Author:
Maki

Date:
Sun, 29 Mar 2020 00:57

Added back accidentally removed laser pointer app from unpublished scripts

Stats:

Filename
Stats
Lines
Added
Removed
Lines in blame

unpublishedScripts/marketplace/laser/laser-a.svg

0
0
0
107

unpublishedScripts/marketplace/laser/laser.svg

0
0
0
106

unpublishedScripts/marketplace/laser/laserPointerApp.js

273
273
0
273

3 files
-
273
273
0
486

To work on this, please assign the issue to yourself, then look at the commit and decide whether this would be a good addition to Overte.

If the commit is useful, tag it with "Tivoli: Keep", and keep it open until it's merged.
If the commit is not useful, tag it with "Tivoli: Discard", and close it.
If the commit is not useful right now, but might be later, tag it with "Tivoli: Maybe later", and close it.
If it's hard to decide, tag it with "Tivoli: Discuss", and keep it open.

Useful commits should be submitted as a PR against Overte. Tag this issue in PR, so that it's automatically closed once the PR is merged.
You can cherry-pick this issue with this command:
git cherry-pick 6b6699ceeaeaafcf640ceed54e25dc9996006e8f

looks useful

This app is already in our repo

source: gharchive/issue

authors: JulianGro daleglass

repo: overte-org/tivolicloud


text:
fix #57: multi value better handling

Working on #57 .
Tried to cover standard cases. Runned some tests, but they are not exhaustive.

@tduboys : if you can try it and confirm, would be awesome !

HI,
I confirm it works.
The patch creates a new variable called « _list » that contains all selected options on a list format
and a second variable  with the REOPTALT option to be used on FETCH.
I only tested on a FETCH filter, but it's working on this case.
Thanks @redref

@redref : Sorry, I worked on the same subject yesterday night and tonight... And I just discovered you also did a PR for the same issue.
We may discuss it on monday maybe ?

@pi-r-p : Closing this, despite my concerns on your PR, it is better styled and cover a bit more.

authors: pi-r-p redref tduboys


text:
How to access hot-reloaded bundles and on-disk static files at same time?

I have hot-reloading working as per http://owaislone.org/blog/webpack-plus-reactjs-and-django/ but since I've changed STATIC_URL = 'http://localhost:3000/assets/bundles/' I can no longer access other non-bundled static files.
What's the recommended approach here?

You shouldn't change STATIC_URL. If you're using the render_bundle template tag, it'll choose what URL to put in the tag based on your webpack.config. In particular, it uses the value in config.output.PublicPath.
So my dev webpack config has this as part of it:
{
  "output": {
    "publicPath": "http://localhost:3000/static/"
  }
}

In my setup, I run webpack with a different config file when I'm developing. But I don't have to change any of the Django templates, because it's all in the webpack config.

Ah I see, there was a comment in the aforementioned post saying // Tell django to use this URL to load packages and not use STATIC_URL + bundle_name and I took that to mean django had to be explicitly told where to look. Thanks for clarifying.

@ryanhiebert Thanks

authors: dwjp owais ryanhiebert

repo: owais/django-webpack-loader


text:
Data generation scripts for RTMV: A Ray-Traced Multi-View Synthetic Dataset for Novel View Synthesis

Hi there, great work!
Any plans on releasing the data generation scripts for RTMV: A Ray-Traced Multi-View Synthetic Dataset for Novel View Synthesis? Thanks in advance.

@TontonTremblay is the guy to ask for this one. I don't personally see why this couldn't happen though. :)

Thanks! I got in touch with @TontonTremblay over email.

authors: natevm zubair-irshad

repo: owl-project/NVISII


text:
Trying to copy a file into a readonly share gives HTTP 500 error

Describe the bug
Trying to copy a file into a readonly share gives HTTP 500 error
Steps to reproduce
Steps to reproduce the behavior:

as admin create folder sfold
as admin share sfold with Einstein as Viewer
as Einstein accept sfold
as Einstein create a file lorem.txt
as Einstein copy file lorem.txt to Shares/sfold/lorem.txt

curl https://localhost:9200/remote.php/webdav/lorem.txt -XCOPY -H Destination:https://localhost:9200/remote.php/webdav/Shares/sfold/lorem.txt -vk -u Einstein:relativity

Expected behavior
Request fails with status 403 and appropriate message
Actual behavior
Request fails with status 500 and no body
Logs

2021-06-11T15:01:52+05:45 WRN http end="11/Jun/2021:15:01:52 +0545" host=127.0.0.1 method=GET pkg=rhttp proto=HTTP/1.1 service=storage size=0 start="11/Jun/2021:15:01:52 +0545" status=404 time_ns=239786 traceid=9c6c430ba0f913e92e255c0fe6d349c5 uri=/data/groups/grp1 url=/data/groups/grp1
2021-06-11T15:01:52+05:45 ERR could not load group error="group with id grp1 not found" id=grp1 service=accounts
2021-06-11T15:01:52+05:45 INF access-log from=127.0.0.1:44740 method=COPY path=COPY service=proxy
2021-06-11T15:01:52+05:45 WRN ../../../../go/pkg/mod/github.com/cs3org/reva@v1.7.1-0.20210531093513-b74a2b156af6/internal/grpc/services/storageprovider/storageprovider.go:569 > path not found when stating pkg=rgrpc service=storage traceid=853db78d828de56c5f96c253819e112f
2021-06-11T15:01:52+05:45 INF file download data-server=http://localhost:9155/data/simple/lorem.txt fn=/home/lorem.txt pkg=rgrpc service=storage traceid=853db78d828de56c5f96c253819e112f
2021-06-11T15:01:52+05:45 ERR ../../../../go/pkg/mod/github.com/cs3org/reva@v1.7.1-0.20210531093513-b74a2b156af6/internal/grpc/services/storageprovider/storageprovider.go:345 > permission denied error="error: permission denied: 8e3911a5-5a58-470e-87ff-921229d7d76c/lorem.txt" pkg=rgrpc service=storage traceid=853db78d828de56c5f96c253819e112f
2021-06-11T15:01:52+05:45 ERR error descending directory error="status code 8" depth=infinity dst=/home/Shares/sfold/lorem.txt pkg=rhttp service=storage src=/home/lorem.txt traceid=853db78d828de56c5f96c253819e112f
2021-06-11T15:01:52+05:45 ERR http end="11/Jun/2021:15:01:52 +0545" host=127.0.0.1 method=COPY pkg=rhttp proto=HTTP/1.1 service=storage size=0 start="11/Jun/2021:15:01:52 +0545" status=500 time_ns=45525902 traceid=853db78d828de56c5f96c253819e112f uri=/remote.php/webdav/lorem.txt url=/remote.php/webdav/lorem.txt
2021-06-11T15:01:52+05:45 INF access-log from=[::1]:54702 method=GET path=GET service=proxy

Setup
Please describe how you started the server and provide a list of relevant environment variables.

OCIS_VERSION=vX.X.X
BRANCH=vX.X.X
STORAGE_FRONTEND_UPLOAD_DISABLE_TUS=false

Additional context
Add any other context about the problem here.

re-tested oCIS 1.11
COPY https://localhost:9200/remote.php/webdav/lorem.txt  get 403 Forbidden
with message:
<d:error xmlns:d="DAV" xmlns:s="http://sabredav.org/ns"><s:exception>Sabre\DAV\Exception\PermissionDenied</s:exception><s:message>Permissions denied to create /home/Shares/folder1/lorem.txt</s:message></d:error>
@dpakach I think it's fixed. You can close

authors: ScharfViktor dpakach

repo: owncloud/ocis


text:
Redirect loop on missing extended attributes in the metadata storage

Describe the bug
After a badly time reboot (running ocis debug session), the extended attributes in the metadata-storage where gone (~/.ocis/storage/metadata/spaces/re/dacted-uuid-49fc-8203-0558109d1b4f/nodes/re/da/ct/ed/-uuid-469c-b126-fee53edbd8ba). When logging into the web interface it went into a redirect loop.
Expected behavior
Login working properly.
Actual behavior
WebUI went into login redirect loop.
Setup
Arch Linux, home directory on ext4 partition.

@kulmann web or backend ticket 😄 ?

why not both, there should be a "please contact your admin" message when that happens.

@dragonchaser  Could you add steps how to recreate the state?

@kulmann sure
$> cd .ocis/storage/metadata
$> find |grep accounts
$> cd <resultfolder from step above>

you will find 3 symlinks there accounts, bundles, values
$> xattr -c {accounts,values,bundles}

then start ocis and try to login

authors: dragonchaser kulmann micbar


text:
Allow desktop client to cache resources

Related: #5513, https://github.com/owncloud/client/pull/10526, https://talk.owncloud.com/channel/infinitescale?msg=9yG3dcnfCHiXygFDk
The desktop client wants to use Qt's built-in network cache to cache resources to both reduce the amount of data that needs to be fetched from the server and also to make data available for offline use.
The server's current cache policies prevent that. Qt prevents caching of resources that have must-revalidate set in the Cache-Control header (whether that is 100% accurate or not may be debated). Unfortunately,
Of course, we could hack around this locally, but I think it's better for everyone (and of course easier for us, too) if the server reviews the current cache policies and adjusts them where needed.
We are supposed to cache the following resources due to customer requests:

server side theme (theme.json as well as the resources it points to; all of them can be downloaded without authentication)

Furthermore, what would be nice to cache in my opinion:

user avatars

(These lists may be extended if we find additional resources to be cached.)
As far as I can tell, just removing must-revalidate should do the trick. To quote the Mozilla docs:

HTTP allows caches to reuse stale responses when they are disconnected from the origin server. must-revalidate is a way to prevent this from happening - either the stored response is revalidated with the origin server or a 504 (Gateway Timeout) response is generated.

In general, max-age should be chosen in a sensible way. Instance themes rarely change, user avatars may change more frequently. It's up to you to decide on these values, of course.
If needed, you could serve different Cache-Control headers based on the user agent, but I don't think it makes a lot of sense to differentiate between web and native clients.

@TheOneRing FYI

@fmoc See linked PR.

authors: fmoc micbar michaelstingl


text:
feat(ast): add AssignmentTargetRest

closes #2598

#2601  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @Boshen and the rest of your teammates on  Graphite

Merge activity

Mar 4, 1:31 AM EST: @Boshen merged this pull request with Graphite.

repo: oxc-project/oxc


text:
feat(linter): Fix suggestion for eslint:no_empty_static_block rule

Relates to https://github.com/oxc-project/oxc/issues/4179

Merge activity

Oct 21, 4:20 AM EDT: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.

authors: Boshen tapanprakasht


text:
Primal feasibility guarantee?

Hi there,
Thanks for providing this awesome library.  I have more of a theoretical question: does OSQP (or ADMM in general) guarantees primal feasibility with finite amount of iterations?
I notice that the paper provides proof for primal and dual feasibility in the limit of infinite number of iterations.  However, I found that the solution returned by OSQP always has a non-zero primal residual.  If I really really need to find a solution within the feasible region, is it possible to achieve that with OSQP (or ADMM in general)?

The short answer is no, ADMM is not guaranteed to converge to a feasible point in a finite number of iterations.
However, within the OSQP solver itself things are bit better.   If you have polishing enabled, then after the solver reaches its convergence tolerance it will make a guess at the correct active set and try to compute a high precision solution while treating that active set as a collection of equality constraints.
If this is successful, then the solver will return the ‘polished’ solution and it will be very accurate (and primal feasible).
On 7 Oct 2018, at 23:15, Qingnan Zhou <notifications@github.commailto:notifications@github.com> wrote:
Hi there,
Thanks for providing this awesome library. I have more of a theoretical questions: does OSQP (or ADMM in general) guarantees primal feasibility with finite amount of iterations?
I notice that the paperhttp://web.stanford.edu/~boyd/papers/pdf/admm_distr_stats.pdf provides proof for primal and dual feasibility in the limit of infinite number of iterations. However, I found that the solution returned by OSQP always has a non-zero primal residual. If I really really need to find a solution within the feasible region, is it possible to achieve that with OSQP (or ADMM in general)?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/oxfordcontrol/osqp/issues/97, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGhaqVhptmxd6nVICNzQQyi_7CayQL4pks5uin0SgaJpZM4XMEKz.

Thanks @goulart-paul for the quick answer!  Unfortunately, polishing is not successful in my case...

If it is not successful then it means that the solver is either not getting to the correct active set, or that your problem is actually infeasible.
You could try tightening the termination tolerances to ensure you are closer to optimality before attempting to polish.   You may need to also increase the allowable number of iterations if you do this, since convergence to high accuracy is not always that fast.
On 7 Oct 2018, at 23:50, Qingnan Zhou <notifications@github.commailto:notifications@github.com> wrote:
Thanks @goulart-paulhttps://github.com/goulart-paul for the quick answer! Unfortunately, polishing is not successful in my case...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/oxfordcontrol/osqp/issues/97#issuecomment-427693957, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGhaqQxn-XfNxreCnjfTrZguoC1M0jitks5uioUtgaJpZM4XMEKz.

A few comments:

the same issue appears with interior-point methods where the residuals converge to zero in the limit.

Primal dual feasibility are controlled using the rho parameter. To get primal feasibility satisfied as quickly as possible (ignoring optimality) I suggest you to decrease rho and remove the auto option.  I would also change the primal/dual feasibility tolerances accordingly. You might get very suboptimal solutions this way.

The polishing step works better then the tolerances are small (sometimes 1e-05 or 1e-08). This also requires many more iterations though.

Primal active set methods could be an alternative to get what you need. They aim at dual feasibility and complementary slackness in the limit while satisfying primal feasibility.  However they do not tend to work well for large QPs/LPs with many constraints.  Our method instead always satisfies complementary slackness while aiming at primal and dual feasibility in the limit. How large is your problem?

Thanks for the suggestions.  My pursuit for feasibility is unfortunately not successful.  First of all, the problem I am solving has theoretical guarantee on feasibility, and I am able to validate that in my implementation by constructing a feasible point.
I am testing on simple toy problems for now.  My setup consists of 209 variables and 288 constraints.  I should probably mention that some of the constraint are equality constraints (enforced by setting l[i] == u[i]), and I set P == 0 (i.e. linear programming) to remove confounding factors.
Here is my settings:
solver.setup(P, q, A, l, u,
            verbose=True,
            polish=True,
            eps_prim_inf=0,
            eps_dual_inf=0,
            eps_abs=5e-10,
            eps_rel=1e-12,
            max_iter=1e7,
            polish_refine_iter=1e7,
            rho=1e-12,
            adaptive_rho_fraction=1.0);

I was only able to reduce primal residual to around 5e-10.  After that the residual value will only fluctuate around but not decrease further.   Even with residual this small, the polishing step has not been successful so far.  It is possible the above setting contains obvious mistakes.  Any hint is appreciated.

A few comments from my side:

It is not advised to set tolerances eps_prim_inf and eps_dual_inf to zero. This would mean that your infeasibility checks will never be satisfied.

There is no need to perform 1e7 iterative refinement iterations. The default value for polish_refine_iter is set to 3 which is almost always sufficient. You may consider taking 5 or 10 steps, but 10 million steps is not what you want.

Polishing will typically succeed only if both primal and dual residuals are small enough.

If having primal residual being 1e-10 is not sufficiently small for your application, then you are probably doing something wrong. Which accuracy do you hope for?

Thanks again for the help and suggestions.  Both primal and dual residual are of similar magnitude (around 5e-10).  It is certainly small enough.  :)  The only unsatisfactory point is that I was not able to get the polishing step to work no matter how small the residuals are.
I am closing this issue as it is getting beyond my original question.  Thanks so much for the discussion!

Feel free to send us your QP data if you would like us to try to get polishing to work. We are slowly collecting problems where the convergence is problematic.

authors: bstellato gbanjac goulart-paul qnzhou

repo: oxfordcontrol/osqp

license_source: bigquery


text:
Typo in Changelog: Talks about "TSL layer"

Changelog talks about requirements for enabling the "TSL layer". That should be TLS.

Should this issue be closed?

Indeed. Thanks

authors: Tpt joepie91 jonassmedegaard

repo: oxigraph/oxigraph


text:
Precompute some statistics about the graph

I first just want to say thanks for your work! I've now loaded a dataset with 36 million triples into Oxigraph:

I was wondering if Oxigraph could (perhaps while loading) keep some statistics about the number of triples in the entire graph and each named graph.
This might help queries like the one shown return faster.

Yes, Oxigraph should definitely keep some statistics, at least in order to be able to better optimize query evaluation.
When it is done we might add a piece of code that looks for "count the number of triples" queries and use the statistics for that.
However it is hard to do such query matching properly and using statistics would require them to be exact and not only an approximation.

authors: Tpt alexkreidler


text:
Upload File - When cancelled out the file still appears when upload file is opened again.

Steps used to verify:
Go to Upload file
Select any file csv, geo.json or kml.
Cancel
Open Upload file again
RESULTS - The previously chosen file is still in the file field.
EXPECTED RESULTS - The file field should clear out when cancelled.

Passed on dev.

repo: ozone-development/meridian


text:
feat(508): Text alternatives for non-text content

@wski
@clarkjefcoat

:+1:

As soon as Ricardo fixes the Intents icon alt text - :+1:

:+1:

can this branch be deleted @SOAP1914?

yes
On Wed, Jan 13, 2016 at 10:40 AM, Bethany notifications@github.com wrote:

can this branch be deleted @SOAP1914 https://github.com/SOAP1914?
—
Reply to this email directly or view it on GitHub
https://github.com/ozone-development/ozp-center/pull/386#issuecomment-171334442
.

repo: ozone-development/ozp-center


text:
OWF throws unhelpful exception when theme directory not found

When OWF attempts to open a theme that does not exist an exception similar to the following is logged:
ERROR [org.codehaus.groovy.grails.web.servlet.view.GroovyPageView] Error processing GroovyPageView: Cannot invoke method exists() on null object
java.lang.NullPointerException: Cannot invoke method exists() on null object
	at ozone.owf.grails.services.ThemeService.getTheme(ThemeService.groovy:67)
	at ozone.owf.grails.services.ThemeService$getTheme.callCurrent(Unknown Source)
	at ozone.owf.grails.services.ThemeService.getCurrentTheme(ThemeService.groovy:85)
	at ozone.owf.grails.services.ThemeService$$FastClassByCGLIB$$2e630feb.invoke(<generated>)
	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
...

As the stack trace notes the origin of the problem is the following section in ThemeService.groovy:
if (!(themeName && resource.exists()))
    throw new OwfException(message: "Cannot find the requested CSS theme: ${themeName}", exceptionType: OwfExceptionTypes.GeneralServerError)

Adding the ? operator before the call to the exists() method will allow the check to throw the cleaner Cannot find the requested CSS theme as intended.

It appears that this was fixed at some point.  I now get the expected error message when following the Steps to Reproduce.

authors: UberGeekxor rpokorny

repo: ozoneplatform/owf-framework


text:
fix bug where first episode using Epsilon_Greedy_Exploration is random

In Epsilon_Greedy_Exploration.py, self.random_episodes_to_run is set to zero by default. To check if our episode should be random, we need episode_number >= self.random_episodes_to_run, since episode_number is zero-indexed. (Instead of episode_number >= self.random_episodes_to_run.)

thanks a lot Simon


text:
Further Tester statistics

In place of:
Instrumented 154 scheduling points (on last iteration).
We should say:
Average scheduling points in terminating executions: blah
It is useful to know the "expected" length of execution of a program. What do you think?

My only worry is programs with unfair infinite executions. But we can maybe (also) show median value?

On 27 Jul 2016, at 08:55, Akash Lal notifications@github.com wrote:
In place of:
Instrumented 154 scheduling points (on last iteration).
We should say:
Average scheduling points in terminating executions: blah
It is useful to know the "expected" length of execution of a program. What do you think?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

We only average across executions that terminate normally (i.e., not hit the bound). Perhaps min and max would also be useful to show.

Addressed in #84

authors: akashlal pdeligia

repo: p-org/PSharp

license: mit


text:
0.27.0 blue marker bar does not follow mouse cursor

macOS 13.6, Mac Studio M1
Just installed 0.27.0 and the blue marker bar does not follow the mouse cursor anymore when you open Maccy by clicking on the icon in the menu bar.
It still works when you open the list via hotkey or if you click in the search field AFTER clicking the menu bar icon - but it stops working in all cases if you move the mouse cursor out of the list and back in.

@valynor Can you record a small video showing the issue? I'm running macOS 14 already and I cannot reproduce the problem.

@p0deje
Here you go:
https://github.com/p0deje/Maccy/assets/23384233/6fddb6cb-456a-42eb-873f-c3d6a674f394
Worked fine in 0.26.x and immediately broke after installing 0.27.0
I killed & restarted Maccy, no change.

I faced the same issue on my MacBook Air M1, macOS 13.5.2

I only have macOS 14 and macOS 10.14 available and I cannot reproduce them there 😞

Same for me on Ventura 13.6 M1 MacBook Air. Sometimes it works, most of the time it does not.
When it works, I just need to move the mouse down and up a few times over the items, then it stops working.
But I have also seen it happen with CopyClip, just not as often.

@p0deje
Is it safe to manually go back to 0.26.5 or would that break stuff?

@valynor It should be safe.

Thanks. I restored 0.26.5 from Time Machine Backup and Maccy works perfectly again.

It still works when you open the list via hotkey or if you click in the search field AFTER clicking the menu bar icon - but it stops working in all cases if you move the mouse cursor out of the list and back in.

@valynor Hmm, are you sure it never happens when popping up via hotkey? What if change "Popup at" to "Menu icon" in Maccy "Appearance" preferences?

I faced the same issue on my MacBook Air M1, macOS 13.5.2
I updated to macOS 14.0 today and the issue seems gone 😂

Hmm, are you sure it never happens when popping up via hotkey? What if change "Popup at" to "Menu icon" in Maccy "Appearance" preferences?

Can't test anymore because I went back to 0.26.5 but I remember I opened it a couple times and it worked. Moving the mouse pointer away and back on the list caused it to break again, though.

I can reproduce the issue (haven't yet updated to Sonoma). The issue lies in this line
https://github.com/p0deje/Maccy/blob/a68ff52911946194ad5636b1ecbe8958d156a0cd/Maccy/RunLoopLocalEventMonitor.swift#L23
It causes mouse movement events to be swallowed (not sure exactly why. Maybe the re-dispatching mechanism doesn't work for mouse events). Changing it to [.keyDown, .keyUp] fixes it for me. Though according to the comment
this might cause incorrectly ordered events?

Thank you, @weisJ - I am going to apply your change. My quick testing didn't reveal issues with events order, let's see if any other issue is going to be raised.

@valynor Please try using Maccy 0.27.1 and comment if the issue is still there.

I can confirm that this is now fixed for me on M2 Ventura. Thanks!

@p0deje @weisJ
0.27.1 fixed the bug for me, thanks! ❤


text:
Remove unnecessary nested statement

This pull request is a simple suggestion.
I removed the unnecessary nested if statement that i thought.

Thank you!


text:
LN-DLC: Allow force-close at any point

We must let consumers trigger force-close at any point in the protocol.
I think we will need to handle some states differently. For instance, with an Offered state I think we would need to fall back to the previous commitment transaction (sans split transaction), whereas with CloseConfirmed we would need to use the newly negotiated state (sans split transaction too).
I open this issue because of this check which ensures that the subchannel is in the Signed state:
https://github.com/p2pderivatives/rust-dlc/blob/add0b0a7f1ade21a31bad2c6781fe6864980ce25/dlc-manager/src/sub_channel_manager.rs#L709-L714

I think this whole issue has finally been addressed with #128.


text:
Update deps to latest versions

There are some descriptors tests failing in the dlc crate, not sure why seems like it is from updating the descriptor dependency. Otherwise this is essentially a remake of #74 on top of #65
Note: this PR will need to be merged and the rust-bitcoin-coin-selection dep and be changed back to point to the p2pderivatives repo

Thanks! I'll try to check the descriptor issue.

Note: this PR will need to be merged and the rust-bitcoin-coin-selection dep and be changed back to point to the p2pderivatives repo

If you don't mind I would prefer to first have a PR to update the dependency and version in the rust-bitcoin-coin-selection repo, tag it and point to the tag here.

I had a quick look but it's not obvious to me right now what is the issue. I'll try to dig more but it'll have to wait a bit.

@benthecarman I've found the issue in the new version of miniscript we need to pass the pubkey value to the pkh tag and the the actual pubkey hash. Anyway please have a look and I'll merge. Thanks for the PR!

lgtm, switched it back to the correct repo now that https://github.com/p2pderivatives/rust-bitcoin-coin-selection/pull/7 is merged

@benthecarman I've found the issue in the new version of miniscript we need to pass the pubkey value to the pkh tag and the the actual pubkey hash. Anyway please have a look and I'll merge. Thanks for the PR!

lgtm, switched it back to the correct repo now that p2pderivatives/rust-bitcoin-coin-selection#7 is merged

Ooops sorry just saw your message after force pushing to change that as well. Shouldn't matter though, will merge.

authors: Tibo-lg benthecarman


text:
Change semantics for setInvalid for Issue 995

We changed the definition of setInvalid for header union members.
We added the definition of setInvalid for header unions.

Fixes #995

Sorry to be so noisy on this issue, but a couple of comments:
(a) I agree that header stacks are not a frequently used feature of the language today, and have no fundamental objections to this change.
(b) IF we make this change, are we willing to actually follow semantic versioning and call the next version of the P4_16 language spec version 2.0.0?  If not, why not?

If we do make this change, and if this comment: https://github.com/p4lang/p4-spec/issues/995#issuecomment-996201592
applies after this change, but not before this change, then I think it would be good to add some kind of note about that requirement of how implementations must behave, similar to the example in the comment linked above.

Can we close this PR? It is a significant change in the language semantics.

This semantics seems more natural, so let's leave this open for now...

In the interest of tidying up the set of active issues on the P4 specification repository, I'm marking this as "stalled" and closing it. Of course, we can always re-open it in the future if there is interest in resurrecting it.

authors: MollyDream jafingerhut jfingerh jnfoster mbudiu-vmw


text:
Simple L2 Switch - stuck on launching P4Runtime-shell

I get this error while running example L2 Switch.
pi@p4pi:~$ sudo t4p4s-p4rtshell l2switch
Generating P4Runtime files...
~/t4p4s/examples/p4rt_files /home/pi
/home/pi
Launching P4Runtime-shell...
CRITICAL:root:StreamChannel error, closing stream
CRITICAL:root:P4Runtime RPC error (UNAVAILABLE): failed to connect to all addresses
CRITICAL:root:Failed to establish session with server

https://github.com/p4lang/p4pi/issues/46 We fixed this issue by replacing the Raspberry Pi 4 with a brand new one. The Pi we had before didn't indicate any hardware problems and worked fine with most tasks except compiling and running P4Runtime-shell. We will make further examinations with the Pi and see if we find any hardware issues.

I had the same problem - the reason was too little amount of RAM (2 GB instead of 4 GB).

authors: grbrr memovers


text:
Is there an open source "protobuf message validator" program?

Suppose I have a P4Info file contents that I have edited by hand, or generated from some program, e.g. p4c, and I want to check whether it has a "valid schema" that conforms to what is defined in the .proto files in this p4runtime repository.
Is there some existing open source program I can run, providing it the name of the P4Info file (preferably with a choice between any of JSON, text, or binary format, but at least one of those is better than none), plus the name of one or more of the p4runtime .proto files, and reports errors or "all ok"?

I believe you can use protoc with the --encode / --decode options. There are probably some third-party tools available online as well, or some third-party protoc plugins.
However, if you are specifically interested in validating P4Info messages, you can use the pi_convert_p4info binary installed by p4lang/PI. It is meant for conversion between different formats. However, it does validation implicitly when loading the P4Info message, and you can choose the same output format as input format... Feel free to submit patches to pi_convert_p4info as well if the tool is useful to you.

OK, I tried out this command:
$ pi_convert_p4info -f prototext -t prototext -i $j -o $j.converted.txt

where j is a shell variable ranging over all of the files with names ending with the suffix ".p4info.txt" in this directory: https://github.com/p4lang/p4c/tree/master/testdata/p4_16_samples_outputs
Does the format prototext seem like the right one for those files?  I do not know the correspondence between the four file format names supported by the pi_convert_p4info command vs. the 3 formats that can be generated by p4c, but prototext gave the fewest error messages :-)
The command succeeded for all of the files except for one (more on that file below).
For the majority of files on which it succeeded, it seems like the pkg_info message near the beginning of those files was removed in the 'converted' output files:
pkg_info {
  arch: "psa"
}

Also, even though the output file is specified on the command line via -o (and the command requires this to be specified or it gives an error), it also prints the output to stdout as well.  Is that intentional?  Not a big deal, but seems a bit odd for a command where the output file must be given on the command line.
The one file where the command failed was from this command run in that directory:
$ pi_convert_p4info -f prototext -t prototext -i p4rt_digest_complex.p4.p4info.txt -o p4rt_digest_complex.p4.p4info.txt.converted.txt
Packed type for digest too complex
Error while importing protobuf message to p4info.

for the p4c repository as of this commit: https://github.com/p4lang/p4c/commit/b79021f377e5e6689c30a697c12bdd55b0d8d713
I do not understand why there is an error for that file.  Do you see anything wrong with it?

Also, do you know if this is the correct syntax for a prototext format file that has a map value like those inside of the P4TypeInfo message, that has multiple different key/value pairs?  In particular, is it supposed to be that the new_types { ... } is repeated for each key/value pair, if there is more than one?
https://github.com/jafingerhut/p4-guide/blob/master/p4runtime/expected-p4info-files/psa-example-digest-bmv2.psa.p4info.txt#L85-L103

Yes in Protobuf text format you repeat the map name for each entry, just like for a repeated field.
Regarding the tool, I was a bit optimistic, it won't be able to do just validation of the Protobuf message. It does validation of the Protobuf message (which just means parsing the file and instantiating the in-memory Protobuf message), but it also transforms the P4Info message into an internal data structure for the PI library. This means that a lot of semantic validations are performed on the message (e.g. are the ids consistent?) but it also means that the P4Info will be rejected if the program is too complex for PI to handle (this must be what's happening with p4rt_digest_complex.p4). The internal representation is then converted to the desired format. Unfortunately in your case the whole process loses information: what is not relevant to PI is discarded (e.g. pkg info) and some structures are simplified / flattened.
I could modify the tool to do validation only. Note that the validation part itself is 3 lines of code (parsing of the file). If you are interested I suggest you write a Python script to do that instead. You can also make the script much better by adding semantic checks. You can check for consistent ids, you can check that the P4TypeInfo message is correct, ... It's a bit sad because pi_convert_p4info already does all of these things but unfortunately in the case of pi_convert_p4info, P4Info messages which are too complex for PI are also rejected and there is no way to separate the 2 checks.
I have been meaning to create a p4runtime-tools repository in the p4lang Github organization. It would be a good place for such a validation tool. It would also be a good place for a P4Runtime CLI eventually.

I have hacked up this small Python program that may be a start at what you described, Antonin:
https://github.com/jafingerhut/p4-guide/blob/master/bin/parse-p4info.py
Current limitations:

It only supports reading the text format of P4Info, not the binary or JSON formats
It does not do any sanity checking, other than the syntax checking done by the Python library code that reads it, e.g. it checks that all field names are legal ones according to the '.proto' file message definitions, and that their corresponding values have the proper type (e.g. integer, string, LPM/EXACT/TERNARY keyword thing, etc.)
It does not write out a P4Info file after reading it, only a few summary statistics about the objects and type_info read.
It may use non-recommended ways of accessing the Python data structures created -- I did not know what the recommended methods were.  I just started hunting and peeking around in an interactive Python session trying to figure out which methods were available.  If there is some documentation you are aware of that describes better the methods available, I'd be happy to link to them from inside that program, for anyone else that wants to extend it.

authors: antoninbas jafingerhut


text:
Add error_status field to StreamMessageResponse oneof

This field may be used by the server to report errors generated by
invalid / unauthorized StreamMessageRequests.
Fixes #215

I think there are at least three options for this (as Antonin said in his email):

Drop this PR.
Accept as is.
Add a new field called packet_out_error of type PacketOutError to StreamMessageResponse (not a oneof though, as Antonin said, maybe that would be a forth proposal).  This error will only be used for PacketOut and nothing else, and PacketOutError for now only contains a Status.

I'm okay with 1 and 3, I think 2 would not be good:

If we want to add any additional information to the error for packet out, we can only do this in an unstructured way (details of the Status).
The proposal says this will also be used for other errors in the future potentially, in which case we have no way of distinguishing packet-out errors from those future errors (other than in an unstructured way in details).
We can't extend the packet-out error with more information in the future in a clean way.  If there is a PacketOutError message, however, we can just add more fields if that becomes desirable, in a backwards compatible way.
This proposal limits how any future error reporting for other features of the stream channel looks like.  In particular, if another kind of error reporting wants to always include more information, we are again bound to only doing that in an unstructured way in the details field.

One objection to 3 (over 2) might be added complexity because of the one additional message type.  I would actually argue 3 is much less complex overall, because it clearly specifies error handling for packet-out errors and nothing else. 2 on the other hand will limit any future error reporting we might want.  Thinking about all possible futures is really hard.
We should definitely also wait and see what @pudelkoM and Carmelo think.

@ccascone @pudelkoM
Could we have your input on this, since the WG is unsure which way to go?
Please refer to https://docs.google.com/document/d/1qzeAnKDDOIgBzq3sLS1C1CacunTtrV5x5T5xPXUFRGM/edit#heading=h.7b84013o7tmu for some context on the discussion.

Sorry for the late reply, I was on vacation.
Based on our original concern, i.e., provide ways to the client to detect that a packet-out message was rejected, this PR works as-is. Indeed, I agree that stream error reporting should be provided for debugging purposes only. For this reason, I don't think we would need to carry any other additional information besides an error code and message (already included in .google.rpc.Status), not even the original packet-out message that caused the error, as packet-out messages should be considered best-effort/ephemeral (the resulting data plane packet could be dropped along the way for many other reasons).
However, I understand @stefanheule concerns. Perhaps defining a field for each possible error in the StreamMessageResponse's oneof would add too much complexity, and there could be cases where we want just to convey an error code and message. For this reason, I would define a generic StreamErrorStatus message that looks like .google.rpc.Status but provides a more structured way to convey additional information. For example that looks like this:
message StreamMessageResponse {
  oneof update {
    MasterArbitrationUpdate arbitration = 1;
    PacketIn packet = 2;
    DigestList digest = 3;
    IdleTimeoutNotification idle_timeout_notification = 4;
    .google.protobuf.Any other = 5;
    StreamErrorStatus error_status = 6;
  }
}

message StreamErrorStatus {
  // The status code, which should be an enum value of
  // google.rpc.Code. Expected to be non-OK status code.
  int32 code = 1;
  // Optional. An explanation of the error.
  string message = 2;
  // Optional. Used by the server to convey additional
  // information about the error.
  oneof details {
  	PacketOutError packet_out = 1;
  	DigestListAckError digest_list_ack = 2;
  	StreamOtherError other = 3;
  	// etc..
  }
}

message PacketOutError {
	// The packet out message that caused the error.
	PacketOut packet_out = 1;
}

message DigestListAckError {
	// The packet out message that caused the error.
	DigestListAck digest_list_ack = 1;
}

message StreamOtherError {
	// The "other" message that caused the error.
	google.protobuf.Any other = 1;
}

authors: antoninbas ccascone stefanheule


text:
Define unidirectional vs. bidirectional tables in spec

The current PNA says that the main control processes a mingled stream of packets, some from network-to-host, others from host-to-network, in the same P4 control, each with their direction identified via a standard metadata direction input field.
Regardless of whether we keep this, or have separate P4 controls for network-to-host and host-to-network directions, but both of those controls can make calls to 'shared' controls that contain tables, there will be tables that can be apply'd by packets being processed in both directions.
There are several packet processing use cases that require either a table that can be apply'd on packets in both directions, or some communication and cooperation between pairs of tables.  The current PNA architecture is based upon the idea that tables that are apply'd by packets in both directions of traffic flow through a NIC are useful things that should be supported explicitly.
As long as such tables are supported in PNA by one of the mechanisms described above, or a different mechanism, it seems to be a useful adjective to define explicitly in the PNA specification.  Here is a first cut at such definitions:
A table is bidirectional if it can be apply'd sometimes by packets in net-to-host direction, and sometimes by packets in the host-to-net direction.
A table is unidirectional if it can only be apply'd by packets in one of those two directions, never the other.
Given the current P4_16 language specification and all of the ways that PNA code might be organized described above, it is possible to determine from static analysis of a P4 program whether a table is bidirectional or unidirectional.  This can be done by examining the complete conditional expression that qualifies apply() statements on the table.  If that condition implies that the packet's direction is always net-to-host, or always host-to-net, then the table is unidirectional.  If the condition is sometimes true for host-to-net packets, and sometimes true for net-to-host packets, then the table is bidirectional.
We could imagine creating an annotation indicating what the developer thinks each table should be, and have the compiler give an error if that annotation is statically determined by the compiler to be incorrect, but it is not obvious that this is a very valuable kind of consistency/lint type of check in a P4 program.  I mention it only because there should be no need for such an annotation, and even if there were one, the compiler should be able to determine what the annotation should be, given the contents of the rest of the program.
If a bidirectional table has direct resources, e.g. direct counter, direct meter, direct register idle_timeout timer state, or data plane add-on-miss functionality, it is far easier to implement it as a single physical table in hardware.  If one attempted to implement such a bidrectional table as two unidirectional tables in hardware, it would lead to the same kinds of potential inconsistencies between the state of the two hardware tables that one finds in switch architectures with such tables, and multiple independent pipelines.  See https://p4.org/p4-spec/docs/PSA-v1.1.0.html#appendix-multi-pipeline-psa-devices for some discussion of that topic.

Just to note: given mutable state (e.g., registers) and any form of recirculation, it probably won't be decidable whether a table is bidirectional or unidirectional.

If this is more subtle than I am imagining, it is probably best to talk about this in person rather than over Github issues, but all I am thinking of here is that in a single execution of a P4 control, it should be possible to symbolically and statically determine from the source code of that control a logical condition under which a table is applied if it is true, and not applied if it is false.
I realize that not all formulas are this simple, but a straightforward example is:
if ((stdmeta.direction == PNA_Direction_t.NET_TO_HOST) && (meta.foo == 5)) {
    t1.apply();
}

This is clearly a unidirectional table, since the condition implies that the stdmeta.direction must be NET_TO_HOST.
There are other such logical formulas where it either definitely does NOT imply that stdmeta.direction is always one value, or always the other.  If there truly are undecidable cases, then I'd say that a compiler should call it a bidirectional table in the absence of strong evidence that it is unidirectional.

Why use annotation? Use a new table property to specify if a table is used for incoming or outgoing or both direction.  For Network Packet Broker, only hardware is used with a symmetric hash which matches both directions.

authors: hesingh jafingerhut jnfoster


text:
Google Maps not working & email config info not found

Iv added the api key for google maps. The maps still do not show.
Where is the info to add the email config to be able to send emails of newsletters and new users? Only thing Iv seen so far is adding the email addresses and nothing regarding setup for the site to send any emails.

When you installed you entered admin, no reply, feedback and bug email addresses. These are stored in database. The software sends mail using a third party library called "swiftmailer" you don't need to do anything. Outgoing email is delivered using the email address you entered in the no reply field upon installation.
The maps work perfectly so your problem is on googles side again. Have you set the API settings correctly there?
This is the last issue you will get a response from me for!

It gives a mail error. which this does even send any emails at all.

The following error was found:
Oops! Our email server encountered an internal error. The email could not be sent. Please try again later

authors: Undefined-Variables ultra-pool


text:
profileManager.get(true) randomly throws java.util.concurrent.TimeoutException

Context: play 2.6.3,  "org.pac4j" % "play-pac4j" % "4.0.0-SNAPSHOT" and pac4jVersion = "2.1.0".
I occasionally get java.util.concurrent.TimeoutException thrown by profileManager.get(readFromSession = true) (it's hanging/blocking for a few seconds where it shouldn't, and throws the exception afterwards).
this code is called from a controller action (basically based on example in https://github.com/pac4j/play-pac4j-scala-demo/blob/0e2a7fa80e5e7cd177d72b90a707174f04eb4fe0/app/controllers/ApplicationWithFilter.scala#L22-L27 )
  def getProfile(implicit request: RequestHeader) = {
    import scala.collection.JavaConverters._
    val webContext = new PlayWebContext(request, playSessionStore)
    val profileManager = new ProfileManager[CommonProfile](webContext)
    val profile = profileManager.get(true) // randomly throws java.util.concurrent.TimeoutException
    profile
  }

I use:
// in SecurityModule.configure:
bind(classOf[PlaySessionStore]).to(classOf[PlayCacheSessionStore])

// and in build.sbt
libraryDependencies += ehcache

https://gist.github.com/vidma/a7c2154e15f74285c77b48508a78f066

cc @leleuj

Do you have some specific configuration for EhCache? I mean: is it shared between nodes or something which could explain the hanging...

Also any idea what your load is? The get could be doing blocking i/o under the hood, if distributed you might be blocking on a network call. Under load this would escalate very quickly if you have a limited threadpool for play to work on. I'm not sure if play assumes non-blocking i/o or not though, so this is conjecture.

it's default play cache config (i.e. no ehcache config).
I get the error on my laptop with sbt run, with only a single request at once...

Have you already encountered this problem with the 4.0.0-SNAPSHOT or is it a very recent issue?

I tried 4.0.0-RC1 which never worked (was always throwing this error or a similar one), and 4.0.0-SNAPSHOT works 4/5 times (since yesterday or the day before).
just in case FYI, here's an excerpt from my build.sbt:
scalaVersion := "2.12.2"
val playVersion = "2.6.3"
val pac4jVersion = "2.1.0"
// see https://github.com/pac4j/play-pac4j-scala-demo/blob/20ccf821bc557347ca2e555fb1c85d4afea92366/build.sbt#L9-L29
val pac4jSecurityDeps = Seq(
  "org.pac4j" % "play-pac4j" % "4.0.0-SNAPSHOT" excludeAll ExclusionRule("org.pac4j", "pac4j-core") changing(),
  "org.pac4j" % "pac4j"  % pac4jVersion changing(),
  "com.typesafe.play" %% "play-cache" % playVersion,
  "org.pac4j" % "pac4j-core" % pac4jVersion changing(),
  //   "org.pac4j" % "pac4j-sql" % "2.1.0",
  "org.pac4j" % "pac4j-http" % pac4jVersion changing(),
  // needed for auth session storage
  ehcache
)
libraryDependencies += ehcache

even more weird with play 2.6.5 - it logs out after a few visits.
weird enough, downgrading to play 2.6.2 - seems to work so far. at least I didn't notice issues yet over ~20 visits.
does it have anything to do with how play-pac4j is built ?

same issue here - play 2.6.5, after successful login, one request isAuthenticated true, all after that all next requests got false, session killed, no profiles retrieved from session. Easy to replicate, just need to upgrade play framework with basic/default dependencies and configuration.

also can confirm:
play 2.6.2 - seems working
play 2.6.3 - timeoutexception
play 2.6.5 - session killed after first request after authentication

OK. Very strange that a minor upgrade of the Play framework breaks things so strongly. Will do some tests.

Even stranger, I cannot reproduce the issue with both demos (Java and Scala). I updated them to Play 2.6.5 with success: @vidma @aleksandrmelnyk can you confirm you have the issue with at least one of the two demos?

Demos: https://github.com/pac4j/play-pac4j-scala-demo and https://github.com/pac4j/play-pac4j-java-demo

weird, but with the scala demo could not replicate on 2.6.5. Will debug later more.

@aleksandrmelnyk Thanks. Weird indeed, but at least, it's a clue to find out the cause of the issue.

Does it depend what session storage is being used?

@millross I don't think so, as we all use EhCache (as defined in the dependencies)

@leleuj to replicate on 2.6.3 you need to visit the page which reads the profile from session (profileManager.get(true), expecting timeoutexception ).
tried 2.6.5 and 2.6.3 demo, however unable to replicate so far (but had seen the issue on our app). I have no time to dig this deeper now.

maybe it depends on how/where is the session accessed in the controller or is the anonymous client enabled (we had only FormClient, and used URL-based security filter rules).
P.S. I also used
@Singleton SomeController @Inject()(..., cc: ControllerComponents)
  extends AbstractController(cc) with I18nSupport {
  ...
}

instead of more limiting extends Security[CommonProfile].

@leleuj Actually I just noticed that you didn't upgrade the scala demo project. Please, in project/plugins.sbt, change
addSbtPlugin("com.typesafe.play" % "sbt-plugin" % "2.6.2")
to
addSbtPlugin("com.typesafe.play" % "sbt-plugin" % "2.6.5")

Good catch! I get the errors now. I will investigate further...

With Play 2.6.3, I encounter the TimeouException, it seems that the problem comes from the Play cache implementation. I read several comments about that and found: https://github.com/playframework/playframework/pull/7802
@gmethvin is this really fixed in Play 2.6.5?
With Play 2.6.5, the authentication works but the profile does not seem to be kept in the cache more than a few milliseconds.
Has something changed with the timeout definition?

OK. I debugged into the cache and indeed, the timeout has changed from seconds to milliseconds between 2.6.2 and 2.6.5. This explains the fact the profile is not saved long enough in the cache and is expired at the second call...
I will certainly change the default timeout in play-pac4j!

authors: aleksandrmelnyk leleuj millross vidma


text:
Move blobs to objects, rather than using pointers

My understanding is that, when writing files into PFS, we write to a randomly-named "blob" in the object store, and compute the data's hash as we stream it in. Once the stream is fully written, and the final hash computed, we write an "object" in the object store with the name of that hash, that points to the relevant blob.
This means that, on retrieval, we have to perform two fetches (object, then blob) each of which is relatively high (and of variable) latency. Is there any reason we can't just move* the blob to the a location corresponding to it's hash after the initial write is complete and the hash calculated?
*: Technically S3, at least, doesn't have a "move" as a first-class operation, but it's docs suggest using an atomic copy followed by a delete achieves the same thing

We should totally do this. It looks like s3, GCS and Azure all have workable atomic-copy APIs. I legit didn't know they existed. This can make a bunch of things much easier and more efficient.

This is no longer relevant as using object storage's namespace for dedupe lookups is way too slow. Still good to know that copy semantics are available in object storage.

authors: gabrielgrant jdoliner

repo: pachyderm/pachyderm


text:
add enterprise activation event to collected metrics

alternative to #2763 ?

We've implemented #2763 which I think was the better solution to this because if you we just report the activation metric we'll have to correlate it with cluster ids.


text:
Glob patterns

Adds glob patterns doc
fixes a few links in fundamentals section
update glob pattern references in other sections

@dwhitena please edit for everything -- spelling, grammar, format. :)

@dwhitena Changes made.

LGTM.  Did you render and check the links?  Just a reminder.

authors: JoeyZwicker dwhitena


text:
Research Packit as a Fedora dist-git CI

Research:

possible implementation options
technical issues to resolve
design user perspective

and discuss with the team and create follow-up cards and add to #2453

One extra thing to cover might be "FedoraOnGitlab" concept -- we can reuse the OSCI's *OnGitLab tooling to sync a dist-git repo with a GitLab repository. (We can check if this can help us anyhow and if this is not a deal breaker for more mass onboarding.)

repo: packit/packit-service


text:
Packwiz not identifying server properly

I am running packwiz-installer-bootstrap via java -jar packwiz-installer-bootstrap.jar -g https://path/to/pack.toml and I have client mods side = "client" and both sides mods but yet, I see the server is downloading the client side mods as well, is this expected behavior (if so what is the point of settings the side)? And if not, what determines if the machine is a server or a client? If it is unreliable perhaps there should be a flag added to manually identify the machine as a server or a client? I am running packwiz inside a docker container and am running it through pterodactyl panel (Java 8 image ghcr.io/pterodactyl/yolks:java_8).

-g only disables the GUI. You want the -s server flag, to tell packwiz-installer that you're using a server (it defaults to client).

Oh, the -s flag was not defined as an option when using --help so I didn't know about the flag but I guess it has probably been added in the 3 years since last github release, but also looks like the latest github release doesn't support -s
link.infra.packwiz.installer.deps.commons-cli.MissingArgumentException: Missing argument for option: s
        at link.infra.packwiz.installer.deps.commons-cli.DefaultParser.checkRequiredArgs(SourceFile:231)
        at link.infra.packwiz.installer.deps.commons-cli.DefaultParser.handleOption(SourceFile:394)
        at link.infra.packwiz.installer.deps.commons-cli.DefaultParser.handleShortAndLongOption(SourceFile:467)
        at link.infra.packwiz.installer.deps.commons-cli.DefaultParser.handleToken(SourceFile:542)
        at link.infra.packwiz.installer.deps.commons-cli.DefaultParser.parse(SourceFile:712)
        at link.infra.packwiz.installer.deps.commons-cli.DefaultParser.parse(SourceFile:679)
        at link.infra.packwiz.installer.deps.commons-cli.DefaultParser.parse(SourceFile:660)
        at link.infra.packwiz.installer.Main.startup(SourceFile:38)
        at link.infra.packwiz.installer.Main.<init>(SourceFile:154)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
        at link.infra.packwiz.installer.bootstrap.LoadJAR.start(LoadJAR.java:51)
        at link.infra.packwiz.installer.bootstrap.Main.<init>(Main.java:91)
        at link.infra.packwiz.installer.bootstrap.Main.main(Main.java:46)

and it is not mentioned on the wiki but I assume a wiki entry may be made once the latest stable release includes the -s flag

Ah, I didn't see the -s setting in the --help, will it be added in the future or maybe already has but not made it into a release yet, or perhaps a wiki entry could be made for how to get packwiz working for server and mention the -s setting, but although it does work and does recognize a size change, I still see it is downloading the client side mods?

The bootstrap isn't what handles installing the pack, it just updates packwiz-installer. That error is just telling you it's missing the server part - you need both -s and server after each other (-s server). It is in the docs, though there definitely ought to be a reference page for it: https://packwiz.infra.link/tutorials/installing/packwiz-installer/#using-a-modpack-with-a-server.
The --help command is broken at the moment, I'm working on fixing it 😅

The bootstrap isn't what handles installing the pack, it just updates packwiz-installer. That error is just telling you it's missing the server part - you need both -s and server after each other (-s server).
Yeah, sorry, noticed my error and deleted the first message

It is in the docs, though there definitely ought to be a reference page for it: https://packwiz.infra.link/tutorials/installing/packwiz-installer/#using-a-modpack-with-a-server.
I can't believe I missed that, I went through all the pages, guess I skimmed too fast and missed it, sorry about that

The --help command is broken at the moment, I'm working on fixing it sweat_smile
Thank you for your work :)

Also for this

although it does work and does recognize a size change, I still see it is downloading the client side mods?
As you said
The bootstrap isn't what handles installing the pack, it just updates packwiz-installer.
I should actually be reporting this to the packwiz-installer repo rather than the bootstrap repo?

I should actually be reporting this to the packwiz-installer repo rather than the bootstrap repo?

Yeah, I'll transfer it now.

although it does work and does recognize a size change, I still see it is downloading the client side mods?

Hmmm, could you send the .pw.toml of one of the files that doesn't work? Also try deleting packwiz.json.

repo: packwiz/packwiz-installer-bootstrap


text:
Missing opcode "img"

Hi I used before the guacamole npm-package from @illgrenoble (https://www.npmjs.com/package/@illgrenoble/guacamole-common-js) and decided to try out yours now to get the newer version of guacamole. But I run into some errors with your version  ( and if i should address this problem with the npm here).
However after I compared the both packages I noticed that in your version the "instructionHandlers" which handels new opcodes by a Guacamole protocol client, is missing the "img" case which leads to an error.
If i add this case from @illgrenoble versions it workes fine.
`        "img": function(parameters) {
        var stream_index = parseInt(parameters[0]);
        var channelMask = parseInt(parameters[1]);
        var layer = getLayer(parseInt(parameters[2]));
        var mimetype = parameters[3];
        var x = parseInt(parameters[4]);
        var y = parseInt(parameters[5]);

        // Create stream

        var stream = streams[stream_index] = new Guacamole.InputStream(guac_client, stream_index);
        var reader = new Guacamole.DataURIReader(stream, mimetype);

        // Draw image when stream is complete
        reader.onend = function drawImageBlob() {
            display.setChannelMask(layer, channelMask);
            display.draw(layer, x, y, reader.getURI());
        };
    },`

Can it be that here is something missing from your packages side or is this "img"-opcode just not available anymore and i should update the client?

The img handler is still present in the current code:
https://github.com/padarom/guacamole-common-js/blob/6c456d68cb24bc5867c4a6512ea45564c1764da2/guacamole-common-js/src/main/webapp/modules/Client.js#L1312-L1328
@illgrenoble/guacamole-common-js only imported the upstream guacamole-common-js library once 5 years ago and then never again. This might match https://github.com/glyptodon/guacamole-client/tree/18136d5146ee98374df60a3b8dfbb1c411d5dd6b, but I'm not certain on that. At that point Guacamole was at version 0.9.14, now it is at version 1.4.0. It is very likely that some breaking changes were introduced when upstream bumped their major version to 1, so it could just be that the remaining code is somewhat incompatible as well.

authors: cedricbieder padarom

repo: padarom/guacamole-common-js


text:
feat(app): emotion 기반으로 공용 푸터 로직을 변경합니다.

📌 이슈 링크

close https://github.com/pagers-org/react-world/issues/47

📖 작업 배경

앞서 네비바를 emotion 기반으로 리팩토링했고, 다음으로 푸터도 리팩토링합니다.

🛠 구현 내용

공용 푸터 내부를 styled component 베이스로 작성합니다.
main.css 파일에서 제거 가능해 보이는 스타일 코드를 제거합니다.

💡 참고사항

Footer.styled.ts 로 스타일 부분을 따로 빼보았습니다.

🖼 스크린샷
기존과 동일하게 스타일이 잘 표시되고 있는 상태

Container 부분 외에는 반영 완료해서 머지하겠습니다! 해당 부분은 추후 개선점을 찾아보려고 합ㄴ디ㅏ.

repo: pagers-org/react-world


text:
google-analytics

I'm kinda new to github, I'm trying to make a webpage at rastamanjohn.github.io. I saw in the README.md i can add a analytics tracking ID in the _config.yml, but I imagine that I shouldn't push the file with my ID. So how do I have it on my page without making it available to everyone?

Google Analytics tracking IDs are public, not secret. The worst a malicious user could do is spoof traffic to your site, which you can counter, if you're concerned by specifying the domain.

Ok, didn't know that, thank you!

authors: benbalter rastamanjohn

repo: pages-themes/cayman


text:
IMN-191 - Agreement unit tests setup + createAgreement tests

Closes IMN-191
Strategy

I wrote a first test for the simplest happy path
I started writing tests for all possible error cases
Whenever I encountered a new, more specific, happy path case - I added another corresponding happy path test
No more cases -->  done ✅

Closing this - we agreed to have only integration tests.

#176 converts the work done in this PR into integration tests
They would anyways be removed by #186

repo: pagopa/interop-be-monorepo


text:
document allowedOrigins values in README

fixes #41
related to #42 since it mentions that the values are passed through as init params.

:+1:

// tagging @bschimpf since it was his original issue, waiting for his +1

Hey, I'm pretty sure this is incorrect -- it's not truly a regex, it's a regex except that "." is replaced with "." and "" is replaced with "." (so that *.example.com works as expected).

+1 will be fixing this

@jmcampanini can you fix this or close?

authors: bschimpf jmcampanini qinfchen tomshen

repo: palantir/dropwizard-web-security


text:
Update to support cslint 1.0.0

The csslint error report format changed in v1 which this fixes.
I'm getting an eslint error on the first line despite not changing anything there. Since this is such an old version I'm not sure what the correct rule settings are to fix it. Probably best to just update the dependencies at this point.

Thanks for your interest in palantir/gulp-csslint-less-reporter, @xt0rted! Before we can accept your pull request, you need to sign our contributor license agreement - just visit https://cla.palantir.com/ and follow the instructions. Once you sign, I'll automatically update this pull request.

Just tried to sign the cla but when I authorized with github I got a 400 error on https://cla.palantir.com/api/auth/github/token

let us know if there are any more issues. tagging @bluekeyes for SA, just in case

PR lgtm 👍

Any chance of a new release to npm?

sorry for the delay @xt0rted. just published 0.2.0 to NPM.

authors: adidahiya jmcampanini palantirtech xt0rted

repo: palantir/gulp-csslint-less-reporter


text:
Fix typo in typedRule.ts

PR checklist

[ ] Addresses an existing issue: #0000
[x] New feature, bugfix, or enhancement

[ ] Includes tests

[ ] Documentation update

Overview of change:
Is there anything you'd like reviewers to focus on?

CHANGELOG.md entry:

Thanks for your interest in palantir/tslint, @garbles! Before we can accept your pull request, you need to sign our contributor license agreement - just visit https://cla.palantir.com/ and follow the instructions. Once you sign, I'll automatically update this pull request.

Thanks @garbles! Looks like this PR was the same as yours, so fixed now.

authors: JKillian garbles palantirtech

repo: palantir/tslint


text:
Enabled strict-type-predicates internally

As per the TODO list in tslint.json

The PR queue is still pretty huge and this is low priority; closing for housekeeping.


text:
Hero module updates

These commits make the hero module more flexible and easier to use.
It now handles inherited styles, text alignment, and many other situations with less friction.
The official example has been hacked to work with the new module as well, though it could be simplified greatly.

This is really great! The hero module know looks much more robust :+1:

Happy to help out!

@paldepind Do you have a plan for when you're going to push a new release to npm?  I'd like to be able to use the updated hero module without copying it to my project.
Alternatively, have you thought of splitting the modules into their own repos which can be published separately?  With npm namespacing (ex:  @cycle/core, @cycle/http, etc), it would be easy to find them all.  It could make it easier to update the module examples too, since you could put in the Browserify/webpack configs.

I've just pushed a new release to npm with the updated hero module.
I don't think the modules are large or numerous enough that keeping them in separate repositories is warranted.

You may have one repo but many packages...

@paldepind I'm still seeing v0.2.8 in NPM.  Can you try releasing v0.3 again?

I just published to npm. I probably forgot the actual npm publish the first time around.

authors: SkaterDad kuraga paldepind

repo: paldepind/snabbdom


text:
default (sub)command for Group

I've a shameless support  question or request for enhancement.
We'd like to make a command the default for a group of commands, so basically Group(invoke_without_command=True), plus somehow invoking a command as if it would have been invoked via Command.main().
Currently it turns out that somewhere deep in click the args parsing results in a no such command found error if I use any (positional) arguments.
import click

@click.group(invoke_without_command=True)
@click.pass_context
def cli(ctx):
    if ctx.invoked_subcommand is None:
        click.echo('I was invoked without subcommand')
        a.main()
    else:
        click.echo('I am about to invoke %s' % ctx.invoked_subcommand)

@cli.command()
@click.option('--test')
def a(test):
    click.echo(test)

@cli.command()
def sync():
    click.echo('The subcommand')

cli()

Thanks!

Replace this:
a.main()

with:
ctx.invoke(a)

No go :)
pas@stranger:~/tmp/t$ python i.py --test a
Error: no such option: --test

Oh, and this is python 3.5.0. (No that it likely matters, but just to be sure.)

Then ctx.forward might do the job.
I'd recommend against conflating parameters and subcommands like that though.

Thanks, but no luck with that either.
Sure, we might have to separate this "default" behavior (a task queue runner daemon) from the "run this and this task with such and such parameters" executable.

It's probably barely implementable, but I guess it's worth a discussion at least.

I wanted the same behavior.  Here's how I implemented an implicit sub command: https://github.com/what-studio/profiling/blob/e6894bcfb975c723b00d764682a785df71c10b70/profiling/main.py#L87

https://github.com/sublee/click-default-group
I made separate repository for default subcommand.

@sublee thanks for your example.  I wound up using something similar but with a slightly different interface:
class DefaultGroup(click.Group):

    ignore_unknown_options = True

    def __init__(self, *args, **kwargs):
        default_command = kwargs.pop('default_command', None)
        super(DefaultGroup, self).__init__(*args, **kwargs)
        if default_command is not None:
            self.set_default_command(default_command)

    def set_default_command(self, command):
        if isinstance(command, basestring):
            cmd_name = command
        else:
            cmd_name = command.name
            self.add_command(command)
        self.default_cmd_name = cmd_name

    def parse_args(self, ctx, args):
        return super(DefaultGroup, self).parse_args(ctx, args)

    def get_command(self, ctx, cmd_name):
        if cmd_name not in self.commands:
            ctx.args0 = cmd_name
            cmd_name = self.default_cmd_name
        return super(DefaultGroup, self).get_command(ctx, cmd_name)

    def resolve_command(self, ctx, args):
        cmd_name, cmd, args = super(DefaultGroup, self).resolve_command(ctx, args)
        args0 = getattr(ctx, 'args0', None)
        if args0 is not None:
            args.insert(0, args0)
        return cmd_name, cmd, args

This has the additional benefit that I can call group.add_command(command) with a command decorated with the vanilla click.command decorator, rather than requiring that I use the special decorator.

To elaborate on the last point, heres two different ways to get the same thing:
@click.group(cls=DefaultGroup, default_command='a')
def cli():
    pass

@cli.command()
@click.option('--test')
def a(test):
    click.echo(test)

@cli.command()
def sync():
    click.echo('The subcommand')

cli()

@click.group(cls=DefaultGroup)
def cli():
    pass

@click.command()
@click.option('--test')
def a(test):
    click.echo(test)

@click.command()
def sync():
    click.echo('The subcommand')

cli.add_command(a)
cli.add_command(sync)
cli.set_default_command(a)
cli()

Because click-default-group exists, may we close this?
BTW @sublee your project would be a good fit for https://github.com/click-contrib

Yeah, that's fine.  My interface is different enough that it would require a breaking change for him to incorporate the changes, so I figured it's probably not worth the effort (especially since he's already pushed it to pypi).  The snippet is short so I figured I'd just comment here in case anyone else is looking for similar functionality.
If/when we add this to click-contrib we can discuss further there.

Cool

@llchan Your approach looks better than mine.  Can I borrow the approach on click-default-group?

Yeah, of course!  Btw, you should enable issues on your repo so we can move the discussion outside of this core click repo.

@sublee Please enable issues in your repo @ https://github.com/sublee/click-default-group

@tony Oh, I didn't know.  I've just enabled.

@sublee You should actually consider moving click-default-group to click-contrib as proposed by @untitaker. The project really looks interesting, but I only found it by chance. It would be a lot more visible in click-contrib!

@glehmann @sublee
Agreed. Is there any other things that get shared? Pypi/readthedocs needed to be added?

@glehmann I just transferred click-default-group to click-contrib.  Check it out!

Using @click.group(cls=DefaultGroup, default='shell', default_if_no_args=True) breaks the auto-completition from https://github.com/click-contrib/click-repl
Why is it preferred versus the following anyway (which works, and does not break click-repl?
@click.group(invoke_without_command=True)
@click.option(
    '--profile',
    help='profile to use',
    default=u'default'
)
@click.pass_context
def cli(ctx, profile):
    ctx.obj = Config(_app, profile)
    if ctx.invoked_subcommand is None:
        ctx.invoke(cmd_shell)

I think this discussion should be continued in a new issue on click-default-group, not in this old thread.

authors: PAStheLoD glehmann llchan oberstet sublee tony untitaker

repo: pallets/click


text:
examples for some blueprint uses in docs

Adding examples for the usage of Blueprints as templates & subdomains. #3675
Link to any relevant issues or pull requests.

Thanks for working on this, but I don't think I'm going to merge these. The two examples are fairly large code blocks, but don't really show off the feature they're about and have no explanation. The first example isn't very useful either, you would use a variable part, not multiple hard coded prefixes.

repo: pallets/flask


text:
jinja2 2.8 environment cache retrieves wrong template, worked in jinja2 2.7

Some code that used to work in jinja2 2.7.2 (I think) is failing in 2.8. The code makes a template loader by deriving from FIleSystemLoader. The code stores multiple templates in one file using its own syntax to parse out separate template, ie, the template file may look like
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::::template:::: A
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
hi from A
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

::::template:::: B
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
hi from B

The code uses syntax like:
ji_env.get_template('templatefile.tmpl?A')
to load templates, so the loader treats the ? character special, and looks for special strings in the template file.
With version 2.8, when caching is on in the environment (the default), it seems that jinja2 is not caching templates via the whole name. If I load template A and then template B, when I try to render template B, I am getting template A - that is I think the caching is broken somehow - once I load template A from that file, I can't load any of the other templates..
Here is a small example of the problem - the file jinja_bug.py:
import sys
import os
import re
import jinja2 as ji

class TemplateLoader(ji.FileSystemLoader):
    def __init__(self):
        ji.FileSystemLoader.__init__(self, ['.'])

    def get_source(self, environment, template):
        fname, template = template.split('?')
        source, path, helper = ji.FileSystemLoader.get_source(self, environment, fname)

        # iterate over lines, find a template
        tmpl = []
        collect = False
        for line in source.splitlines(True):
            words = line.split()
            if words and words[0] == "::::template::::":
                if words[1] == template:
                    collect = True
                else:
                    collect = False
            elif line and line[0] == ':':
                pass
            elif collect:
                tmpl.append(line)
        print ''.join(tmpl)
        print path
        print helper
        return ''.join(tmpl), path, helper

_jenv = ji.Environment(loader=TemplateLoader(),
                       trim_blocks=True,
                       line_statement_prefix='$', line_comment_prefix='$$')

def _TEMPL(template):
    return _jenv.get_template('templates.tmpl?'+template)

tmp = _TEMPL('enum_decl')
tmp = _TEMPL('ctor_decl_inline')
print tmp.render()

and here is the templates.tmpl file that it loads templates from:
:
:  Lines starting with colon are comments, except for special '::::template::::'
:
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::::template:::: enum_decl
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:
:
{% if enum.comment %}

  /** {{enum.comment}} */
{% endif %}
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::::template:::: ctor_decl_inline
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:
:
  {{classname}}({{arglist|join(", ")}})
$ if initlist:
    : {{initlist|join(", ")}}
$ endif

What should happen is that I render ctor_decl_inline. What in fact happens is that I get an error that  enum is not defined. If I don't first load the enum_decl template, then it works. This suggests that the ctor_decl_inline template is never loaded for its rendering.

Thank you for looking at this, I don't know jinjai well enough to answer the question. I am working around the issue by creating the _jenv variable as follows:
jiEnv = ji.Environment(loader=loader,
	                           cache_size=0,
	                           trim_blocks=True,
	                           line_statement_prefix='$',
	                           line_comment_prefix='$$')

so perhaps I am turning off all caching?
The bug I reported is in code I did not develop myself, and it was developed a number of years ago. I think the pattern used, to derive from the FileSystemLoader, is an unusual thing to do today, however when I tried to redo it in a more straightforward way, I still got the same problem. It seems to me that even though the code uses names like
filename?templateA
filename?templateB

to distinguish templates, somehow jinja2 2.8 is not caching on those full names, just on the filename, whereas 2.7 worked.
This was a really big issue for us. Back in Oct of 2015, I ran into this issue: https://jira.slac.stanford.edu/browse/PSRT-71, I upgraded jinja to 2.8, but a week later we ran into the bug and had to work fast to repair things. I put effort into unraveling our code (a complicated code generation package) to isolate the problem and gave up. A bigger effort more recently allowed me to isolate the problem. Anyways, thanks again for looking at this.  Would you like me to make a more straightforward example, without deriving from FileSystemLoader?

Are you still experiencing this bug? I was thinking about looking into it 😃 but when I copied your code snippets, I couldn't reproduce the error

Given the age of this ticket, the fact that the example is complex and admittedly not standard, and the fact that it's not reproducible, I'm going to close this. If this is still an issue, please open a new issue with a minimal example that demonstrates the issue with as simple an example as possible.

authors: amy-lei davidism davidslac

repo: pallets/jinja


text:
Fix dict interop regression for MultiDicts.

This issue was originally raised by @pgjones in https://github.com/pallets/werkzeug/pull/2042/commits/9b5e0d357e6ffe202c62f97c2de93d45e8a9afd7. I believe that the proposed fix in #2042 conflates the real issue, which is the __iter__ implementation, by getting keys() and generators involved, which muddies the waters, and is not necessary to fix this. The explanation there also does not seem correct ("I think the PEP 448 implementation assumes that if the keys method is the standard dict method it can take an optimised code path that skips the overriden values/items methods"):

This PR demonstrates that MultiDict.keys can continue to resolve to dict.keys without triggering this behavior; this PR only makes MultiDict.__iter__ resolve to its own implementation, rather than directly to dict's.
That said, since this new MultiDict.__iter__ implementation just ends up calling dict’s __iter__ implementation, it does seem plausible that merely the resolution of MultiDict.__iter__ to its own implementation rather than directly to dict's is defeating some attempt to take an optimized code path that ends up causing incorrect results. This really seems like a gotcha (if not an outright bug?) in the language. It seems like an object’s behavior should remain exactly the same when a subclass implements a method that merely delegates to super()’s implementation. Fast-path optimizations should not cause entirely different results.

Added dedicated unit tests just for this, since it's super subtle and error-prone.

It occurs to me that Werkzeug’s various mapping data structures seem particularly vulnerable to this sort of issue because they subclass dict. (Implementation inheritance is error-prone; using interfaces (e.g. collections.abc.Mapping) and composition is preferable.) Maybe the decision to subclass dict predates the availability of collections.abc on all supported Python versions, and it’s time to revisit this design?

What's wrong with the current behavior? Is it that iter is only supposed to be returning the first key/value, not the list?

Yes. Phil showed the regression compared to Werkzeug v1 in https://github.com/pallets/werkzeug/pull/2042#discussion_r575696481

The datastructure code is very old, some from the very beginning ~13 years ago. I have a vague todo task for "refactor datastructures", but it's not a high priority yet.

I'm happy with this (save for the super usage).

I have started a discussion about this here: https://discuss.python.org/t/dict-copy-optimization-causes-surprising-behavior-for-subclasses/7201/4?u=jab

authors: davidism jab pgjones

repo: pallets/werkzeug


text:
expected: paloma-test-15, got: paloma-testnet-15

after starting the  last update with v1..0.0 testnet , I encounter this problem on paloma-logs :
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe systemd[1]: Started Paloma Node.
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]: I[2023-05-16|06:17:19.720] starting node with ABCI Tendermint in-process module=server
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]: I[2023-05-16|06:17:19.822] service start                                module=proxy msg="Starting multiAppConn service" impl=multiAppConn
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]: I[2023-05-16|06:17:19.822] service start                                module=abci-client connection=query msg="Starting localClient service" impl=localClient
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]: I[2023-05-16|06:17:19.822] service start                                module=abci-client connection=snapshot msg="Starting localClient service" impl=localClient
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]: I[2023-05-16|06:17:19.822] service start                                module=abci-client connection=mempool msg="Starting localClient service" impl=localClient
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]: I[2023-05-16|06:17:19.822] service start                                module=abci-client connection=consensus msg="Starting localClient service" impl=localClient
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]: I[2023-05-16|06:17:19.822] service start                                module=events msg="Starting EventBus service" impl=EventBus
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]: I[2023-05-16|06:17:19.822] service start                                module=pubsub msg="Starting PubSub service" impl=PubSub
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]: I[2023-05-16|06:17:19.880] service start                                module=txindex msg="Starting IndexerService service" impl=IndexerService
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]: I[2023-05-16|06:17:19.880] ABCI Handshake App Info                      module=consensus height=1765025 hash=B0EACECC7730FA1D7076FADC44602228564496B27BF03AB3B58E783DF6FF170A software-version=1.0.0-beta2 protocol-version=0
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]: I[2023-05-16|06:17:19.880] ABCI Replay Blocks                           module=consensus appHeight=1765025 storeHeight=1765026 stateHeight=1765025
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]: I[2023-05-16|06:17:19.880] Replay last block using real app             module=consensus
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]: panic: invalid chain-id on BeginBlock; expected: paloma-test-15, got: paloma-testnet-15
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]: goroutine 11 [running]:
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]: github.com/cosmos/cosmos-sdk/baseapp.(*BaseApp).BeginBlock(, {{0xc0011d5dc0, 0x20, 0x20}, {{0xb, 0x0}, {0xc001449728, 0x11}, 0x1aeea2, {0x1739bbe1, ...}, ...}, ...})
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]:         /root/go/pkg/mod/github.com/cosmos/cosmos-sdk@v0.47.1/baseapp/abci.go:154 +0xb28
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]: github.com/cometbft/cometbft/abci/client.(*localClient).BeginBlockSync(, {{0xc0011d5dc0, 0x20, 0x20}, {{0xb, 0x0}, {0xc001449728, 0x11}, 0x1aeea2, {0x1739bbe1, ...}, ...}, ...})
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]:         /root/go/pkg/mod/github.com/cometbft/cometbft@v0.37.0/abci/client/local_client.go:283 +0x118
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]: github.com/cometbft/cometbft/proxy.(*appConnConsensus).BeginBlockSync(, {{0xc0011d5dc0, 0x20, 0x20}, {{0xb, 0x0}, {0xc001449728, 0x11}, 0x1aeea2, {0x1739bbe1, ...}, ...}, ...})
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]:         /root/go/pkg/mod/github.com/cometbft/cometbft@v0.37.0/proxy/app_conn.go:101 +0x135
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]: github.com/cometbft/cometbft/state.execBlockOnProxyApp({0x361b8e0?, 0xc0001a64e0}, {0x362cfc0, 0xc00034e3d8}, 0xc000b870e0, {0x36321c0, 0xc000136fc0}, 0x1aeea1?)
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]:         /root/go/pkg/mod/github.com/cometbft/cometbft@v0.37.0/state/execution.go:363 +0x3e3
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]: github.com/cometbft/cometbft/state.(*BlockExecutor).ApplyBlock(, {{{0xb, 0x0}, {0xc002e16820, 0x7}}, {0xc001449098, 0x11}, 0x1, 0x1aeea1, {{0xc001188480, ...}, ...}, ...}, ...)
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]:         /root/go/pkg/mod/github.com/cometbft/cometbft@v0.37.0/state/execution.go:197 +0x151
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]: github.com/cometbft/cometbft/consensus.(*Handshaker).replayBlock(, {{{0xb, 0x0}, {0xc002e16820, 0x7}}, {0xc001449098, 0x11}, 0x1, 0x1aeea1, {{0xc001188480, ...}, ...}, ...}, ...)
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]:         /root/go/pkg/mod/github.com/cometbft/cometbft@v0.37.0/consensus/replay.go:503 +0x217
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]: github.com/cometbft/cometbft/consensus.(*Handshaker).ReplayBlocks(, {{{0xb, 0x0}, {0xc002e16820, 0x7}}, {0xc001449098, 0x11}, 0x1, 0x1aeea1, {{0xc001188480, ...}, ...}, ...}, ...)
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]:         /root/go/pkg/mod/github.com/cometbft/cometbft@v0.37.0/consensus/replay.go:416 +0x713
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]: github.com/cometbft/cometbft/consensus.(*Handshaker).Handshake(0xc00066bdb0, {0x36348a0, 0xc0004e2700})
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]:         /root/go/pkg/mod/github.com/cometbft/cometbft@v0.37.0/consensus/replay.go:268 +0x3ca
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]: github.com/cometbft/cometbft/node.doHandshake({_, }, {{{0xb, 0x0}, {0xc002e16820, 0x7}}, {0xc001449098, 0x11}, 0x1, 0x1aeea1, ...}, ...)
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]:         /root/go/pkg/mod/github.com/cometbft/cometbft@v0.37.0/node/node.go:328 +0x198
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]: github.com/cometbft/cometbft/node.NewNode(0xc000bd1340, {0x36039f0, 0xc000bac780}, 0xc000f095a0, {0x35f37a0, 0xc001208d38}, 0x1?, 0x4ca8a98?, 0xc000f09790, {0x361b8e0, ...}, ...)
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]:         /root/go/pkg/mod/github.com/cometbft/cometbft@v0.37.0/node/node.go:778 +0x56d
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]: github.com/cosmos/cosmos-sdk/server.startInProcess(, {{0x0, 0x0, 0x0}, {0x3632dc0, 0xc000c18bd0}, 0x0, {0xc00041deb0, 0xe}, {0x363dc00, ...}, ...}, ...)
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]:         /root/go/pkg/mod/github.com/cosmos/cosmos-sdk@v0.47.1/server/start.go:315 +0x76f
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]: github.com/cosmos/cosmos-sdk/server.StartCmd.func2.2()
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]:         /root/go/pkg/mod/github.com/cosmos/cosmos-sdk@v0.47.1/server/start.go:151 +0x58
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]: github.com/cosmos/cosmos-sdk/server.wrapCPUProfile.func2()
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]:         /root/go/pkg/mod/github.com/cosmos/cosmos-sdk@v0.47.1/server/start.go:551 +0x29
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]: created by github.com/cosmos/cosmos-sdk/server.wrapCPUProfile
May 16 06:17:19 Ubuntu-2004-focal-64-minimal-hwe palomad[15850]:         /root/go/pkg/mod/github.com/cosmos/cosmos-sdk@v0.47.1/server/start.go:550 +0x24a

@alipostaci2001 replace your genesis with a valid one:
wget -O ~/.paloma/config/genesis.json https://raw.githubusercontent.com/palomachain/testnet/master/paloma-testnet-15/genesis.json

Closing for now as related to old genesis issue.

authors: alipostaci2001 kinrokinro taariq

repo: palomachain/paloma


text:
Log when hostname is not resolvable

Need to log an error when the --check-host value is not resolvable

This should probably log any error actually

repo: palworldlol/check-port-api