fixes issue #4785

output (errors striped for radability)
+--------- introduction/third_party.rst changed ---------------------------------
| Running Sphinx v1.3.3
| loading translations [en]... done
| loading pickled environment... not yet created
| loading intersphinx inventory from http://docs.python.org/3/objects.inv...
| loading intersphinx inventory from http://readthedocs.org/docs/django-classy-tags/en/latest/objects.inv...
| loading intersphinx inventory from http://readthedocs.org/docs/django-sekizai/en/latest/objects.inv...
| loading intersphinx inventory from http://readthedocs.org/docs/django/en/latest/objects.inv...
| building [mo]: targets for 0 po files that are out of date
| building [html]: targets for 88 source files that are out of date
| updating environment: 88 added, 0 changed, 0 removed
| reading sources... [  1%] contributing/code                                                          reading sources... [100%] user/tutorial/structure-content-modes
| looking for now-outdated files... none found
| pickling environment... done
| checking consistency... done
| preparing documents... done
/Users/finalangel/Sites/django-cms/docs/how_to/apphooks.rst:100: WARNING: py:class reference target not found: Category
/Users/finalangel/Sites/django-cms/docs/how_to/apphooks.rst:158: WARNING: py:class reference target not found: MyAppMenu
...
| generating indices... genindex py-modindex
| writing additional pages... search
| copying images... [  2%] user/tutorial/images/create.png                                             copying images... [100%] images/structure-content.pngre-content.png
| copying static files... done
| copying extra files... done
| dumping search index in English (code: en) ... done
| dumping object inventory... done
| build succeeded, 162 warnings.
+--------------------------------------------------------------------------------

Looks good to me.


Load - apply Look with template builder

In GitLab by @support-bot on Apr 21, 2023, 11:05

From...

The template builder make it seam possible that we can load / apply look to asset but unfortunately, it's not doable
Some fonctionality seam there, like the 'order' for exemple, and look family choice
We want to be able to load the published look for the assets linked to the shot/entity (if they exist)
by template builder and apply them with template builder
With this, we could have a lighting shot totally built ready to light

Softwares concerned
Maya, Fix

Possible implementation (to be discuss)  :
If there is no further information supply, apply the defaut subset defined here :

specific look subset can be define on the rig set for exemple, in animation or layout scene  :

so that we know for each specific character can_rigMain 01 / 03 /05 what's the correct look subset to load at the lighting stage.
That mean that for each animation exported we also have a kind of .json that export the wanted subset look
A dropdown to get all the published look subset for a specific asset would be icing on the cake

we can maybe have 2 phases :
one that can be done faster where we have the defaut subset applied automaticly (that would already be a huge step forward) ,
then another time, have more granularity, and have a kind of look 'casting'


Huge memory consumption fixed for buffers and glyphs

This is a great project. I was thinking for creating a tiny game for myself and found this. It's cool how performant it works (unlike .NET's default console). But I noticed some huge memory consumption, it turns out you use a reference type in a case where struct would perfectly fit.
I'm not familiar with your project well (and I don't see tests to run), but hope it will work (it worked for me and hugely decreases the memory consumption ; without this fix, it will consume gigabytes in a few seconds on an empty game with .Construct(40, 40, 20, 20, FramerateMode.Unlimited)).

Looks good. Thank you for the contribution. Such a sane and minimal change, super nice! I'm merging this!


"Măieruș" commune is listed in the drop-down menu

Description:
The commune is listed in the drop-down menu according to the law
Preconditions: the website (https://peviitor-ro.github.io/ui.orase/) is up and runing.
After every step delete the text you typed from the search bar.

Step 1
Type "Măieruș" in the search bar.
Expected results
The location is listed in the drop-down menu as "Măieruș, Brașov"


Can it support in Windows10 + pytorch1.2? THX!

Can it support in Windows10 + pytorch1.2? THX!

I've been porting this to pytorch lately.


fix: minor fixes across components

consistent return statements and logging in all CSI Component reconcile units
use default values for socket paths from topolvm project
deviceClass name validation at CRD level to be able to use that in storage class name

had been split into #46, #47, #48


\g pipe is not well implemented

When I use \g | then I expect so usql will be in backround and should not to read from /dev/tty. But it is not true.
You can check - "select * from pg_class \g | pspg" is working from psql, but don't work from usql (the usql still read the data from /dev/tty).

@okbob thanks. We'll try to get this fixed before the 1.0 release. Bare with us as usql is built solely by volunteers, and the good folks in the PostgreSQL community have roughly 2 decades on us in terms of being able to work out the bugs/kinks.

pá 30. 4. 2021 v 12:40 odesílatel Kenneth Shaw @.***>
napsal:

@okbob https://github.com/okbob thanks. We'll try to get this fixed
before the 1.0 release. Bare with us as usql is built solely by
volunteers, and the good folks in the PostgreSQL community have roughly 2
decades on us in terms of being able to work out the bugs/kinks.

sure :)
Pavel
If I remember well, the details about correct implementation of input,
output streams were long. The related code in psql is very short, but this
is a little bit dark zone of POSIX API, and for expected behaviour some
signal's handling should be enabled, disabled. Try to read related psql
code.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/xo/usql/issues/249#issuecomment-830006896, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEFO424JE3KCBSJFWC5VDTTLKCLHANCNFSM4336CR6Q
.


Shell script that can publish the new Release to Chocolatey

there are 3 steps that need to be met before we can publish on Chocolatey

we need to build the new git-Phlow release
we need to test that the package was build correct and that everything is complaint with the Choco guidelines
we need to publish the package if step 2 was successful

We have chosen to go with Scoop for now, Because it fits our purpose more than doing Chocolatey. We might do a Chocolatey release in the future, but for now this issue will be in the backlog.

fixed in #231


Proguard Config

What is the proguard config?

This library doesn't use any additional library, you can use your standard pro guard configuration


Migrating to catkin build

I sent some PR to fix the build errors of the OP3 packages with catkin build. catkin build is a very common tool which is widely used in the ROS community, so I think we need to make some migration process for our OP3 packages.
Read "Migration Troubleshooting".
http://catkin-tools.readthedocs.io/en/latest/migration.html

 유지보수 - Github Issue / Migrating from catkin_make to catkin build

This issue will be closed since there were no actions for a while. You can reopen this issue to show this issue to the users whenever. Thank you for your consideration and supports.


[Feature Request]: Add Drawing Board to Explore Section

Is there an existing issue for this?

[X] I have searched the existing issues

Feature Description
I would like to add a drawing board feature to the Explore section. This drawing board will provide a fun and interactive way for kids to practice what they've learned as well as explore their creativity through drawing and doodling.
Use Case
How This Feature Would Enhance My Use of the Project

Increased Engagement: Kids will enjoy using the app more with the fun drawing tool.
Reinforced Learning: Provides a hands-on way for kids to practice alphabets and numbers.
Boosted Creativity: Encourages creative expression and fine motor skill development.
Versatile Learning: Can be used for multiple educational activities like drawing shapes or practicing writing.
Improved User Experience: Adds an enjoyable and educational feature, enhancing the overall app experience.

Benefits

Learning: Kids can practice writing and drawing, which helps reinforce their learning.
Creativity: Encourages kids to be creative and improves their fine motor skills.
Fun: Makes the app more enjoyable with a fun activity.
Versatility: Can be used for various educational activities, like drawing the solar system or practicing writing.

Add ScreenShots
No response
Priority
High
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[X] I have starred the repository

Please assign me this issue for GSSoc'24.

I'll give level label after first PR.

I'll give level label after first PR.

ok

#155


v3.14 component can use in v4

Hi
I want to know v3.14 components can used in v4, and how use?

Hi @huiqiangyang
No. Version 4 is a major release with a ton of breaking changes. We have no migration guide for it.
Similar issue: #463


Attribute sent via 'sendAttributeData' shows as both Client Attribute and Server Attributes within Thingsboard

When using sendAttributeData(char const * key, T const & value)  the attribute is showing up as both a Client Attribute and a Server Attribute within Thingsboard.
I had a look though ThingsBoartHttp.h and see where we differentiate between telemetry and attribute, but not between different types of attributes:
https://github.com/thingsboard/thingsboard-client-sdk/blob/44076f3dbf087cfe1637609390bc70ea51ccf31b/src/ThingsBoardHttp.h#L360
There is 3 different kinds of attributes.
https://thingsboard.io/docs/user-guide/attributes/
While this isn't a huge deal it is unexpected for me, I only expected to see the client only sending client and shared attributes, I have no idea why Thingsboard is showing a duplicate as a server attribute.
I can delete the server attribute from the server but they do come back upon updating them from the client.

This cannot be from this library or the code. Because it is not possible to send anything else than Client-Side Attributes from the device to the server.
Even shared attributes can not be sent from the client and server attributes can not be interacted with from the client device in any shape or form.
Therefore the only possible way this can occur is if this attribute has been created on the Cloud itself. This is possible if for example the Rule Chain has been changed and is now misconfigured, as to also now save all sent client attributes as server attributes.
To help debug further I would require a screenshot of the applied rule chain of the Test Device. But I can guarantee this can not be an issue with this library itself.

I was thinking the same thing but I wasn't seeing anything obvious so I excluded that information, I'm quite willing to be wrong though :)
I am pretty sure I'm just using slightly modified versions of example root chains, I just stripped the most of my modifications out and it's still happening. I can provide any additional information as requested as well, I appreciate you assisting!.

Can you show the Save Client Attributes Node and it's setting and the Update Server Attribute script would be interesting as well.

Hmmmmm - reading this more closely I think you're on to something... though the script should only be running if the metadata has a cs_curretnFwVer value shouldn't it?

Exactly, I hope that has solved your issue. In the future in general if there is some error regarding especially Server Attributes, the chance that it occurs in the rulechain is 99%.

I found it strange it was happening at all, I knew I had previously used client attributes without issues but I go sometimes months between looking at this project and my devices. I started to try to implement the built-in OTA capabilities too long ago and have apparently forgotten some of the things I have done in order to try to diagnose.
Thank-you VERY MUCH for your assistance!


[MINOR] Fix broken gradle build because of older shadow plugin version incompatible w/ gradle 5

This fixes issue w/ broken Gradle build due to quite older version of shadow plugin which is incompatible w/ Gradle 5 so that when we
./gradlew clean build
we get
FAILURE: Build failed with an exception.
* What went wrong:
Method com/github/jengelman/gradle/plugins/shadow/internal/DependencyFileCollection.getBuildDependencies()Lorg/gradle/api/tasks/TaskDependency; is abstract

LGTM.
Are there any incompatible changes between shadow-2 and shadow-4 that could affect us here?
I think we are currently not doing any testing with shaded artifacts, and I'm not sure whether there's an easy way to do this, but just calling it out if @rdblue knows a way.

Why not use the latest version? Isn't that 5.0.0?

@rdblue testing 5.0.0

@rdblue pushed to released version 5.0.0 build was successful

@rdsr that's a very good point, reading some release notes at https://github.com/johnrengelman/shadow/releases I see a lot of breaking changes being called out so probably some things may not work as expected across two years worth of development :|

We've not had any problems with upgrading versions of this plugin. It's behavior is fairly stable and well-defined.


Support air-gap / mirror registry with simple signing.

The simple signing signature identity by default verifies that the image reference in the signature matches the refeference specified in the kubernetes resource in full. This means that if the image is phisically moved to another location it is considered to be no longer the same logical image.
We need to allow for physical transport to be separated from the logical identity in order that air-gap and mirror architectures are supported.

It is possible to support moved images using for example "matchExactRepository" identity requirement but more or less one policy per image is required.
We could build some image name mangling in to Portieris and creating the policy dynamically for the container/image verifier to handle, perhaps better would be additional identity options in the "container/image" library.
Ref: https://github.com/containers/image/issues/807


Shortcut for run selection(fn+F9) not working on mac

Description of your problem
What steps will reproduce the problem?

Open Spyder, fn+F9 not working
Go to preferences, reset keyboard shortcuts to default, fn+F9 start working
Close Spyder and open it again, fn+F9 still not working. So every time when I open Spyder, I have to reset the keyboard shortcuts.

What is the expected output? What do you see instead?
Please provide any additional information below
Versions and main components

Spyder Version: 3.2.4(I have this problem since 3.2.2)
Python Version: 3.6.3(I have this problem since 3.6.2)
Qt Version: 5.6.2
PyQt Version: 5.6.0
Operating system: macOS high sierra 10.13

Dependencies
Please go to the menu entry Help > Optional Dependencies (or
Help > Dependencies), press the button Copy to clipboard
and paste the contents below:
IPython >=4.0 : 6.1.0 (OK)
cython >=0.21 : 0.26.1 (OK)
jedi >=0.9.0 : 0.10.2 (OK)
nbconvert >=4.0 : 5.3.1 (OK)
numpy >=1.7 : 1.13.3 (OK)
pandas >=0.13.1 : 0.20.3 (OK)
psutil >=0.3 : 5.3.1 (OK)
pycodestyle >=2.3: 2.3.1 (OK)
pyflakes >=0.6.0 : 1.6.0 (OK)
pygments >=2.0 : 2.2.0 (OK)
pylint >=0.25 : 1.7.4 (OK)
qtconsole >=4.2.0: 4.3.1 (OK)
rope >=0.9.4 : 0.10.5 (OK)
sphinx >=0.6.6 : 1.6.3 (OK)
sympy >=0.7.3 : 1.1.1 (OK)

Thank you for reporting. Did you have this issue before running high sierra or didn't you use spyder on sierra?

@Jeroendevr I cannot remember exactly when did this happen, but I think it happened a few days after I upgraded to high sierra. Thank you for asking, do you think it is due to high sierra?

Yes, it's quite possible. I think this problem will be solved once Anaconda Inc. updates Qt, the graphical toolkit upon which Spyder is built.

Sorry but this is not an error we can solve in Spyder itself.

@ccordoba12 Sure, I have already raised the issue on anaconda-issues: https://github.com/ContinuumIO/anaconda-issues/issues/6803

Have the same problem

Having the same problem. Pressing F9 in Spyder doesn't run the selected codes. However, if you try to modify the keyboard shortcut in preference > keyboard shortcut, it can detect F9 properly. So F9 work but Spyder didn't run the selected codes.
Spyder version: 3.3.0
MacOS version: 10.13.6
Python version: 3.6.5
Qt version: 5.9.3
PyQt5 version: 5.9.2

Please avoid pip when installing binaries.

Why not pip? On the official website of PyQt5, pip is the installation method they suggested.

Because conda and pip do not interpretate perfectly.

Oh, OK. I am only using pip no conda.


Weird behavior on long vertical images and swiping up/down

Describe the bug
When viewing a tall vertical image, and zoomed in, trying to swipe up and down to scroll often results in closing the image. It seems to depend on how fast the swiping movement is, how much zoom is applied, and whether the finger is lifted after swiping.
To Reproduce
Steps to reproduce the behavior:

Open tall vertical image.
Zoom in in some area in the middle, eg. by double tapping.
Swipe up/down in order to do a rolling scroll, ie. after swiping, lift finger so the image keeps moving, decelerating until stopping. (If you zoom after a certain point, the behavior of Aves changes and it doesn't exit the image anymore, behaving as expected)
Aves understand this swipe action as a closing swipe movement and closes image.

Expected behavior
Swiping up/down in a long tall image while zoomed in does not close image.

In Aves v1.8.0, I "improved" gesture handling for this issue:

#316

But it messed up other aspects, like the one you've described. Other issues are:

scaling out often closes the item,
flinging through images sometimes go backwards.

I've just fixed this and intend to release a new version soon.


Fix build after Cell dive PR

After PR #3, tests are failing. I think somehow the new tests that were added while that PR was out are conflicting... but the merge from main should have caught that? Anyway, just needs to be fixed.
When I checkout the last commit in that branch, 9687ea5, tests fail for me?! 15 failed, 4 passed

Sorry about this @mccalluc!  It also seemed like things were working so not sure what happened here...

Fixed by #23


Error running unit tests - failed to initialize client proxy

Moving from dotnet/cli#5672 on behalf of @JamesNK

Steps to reproduce
Source code: https://github.com/JamesNK/Newtonsoft.Json/tree/vs2017
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\msbuild.exe" Newtonsoft.Json.Tests.Roslyn.csproj /t:restore
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\msbuild.exe" Newtonsoft.Json.Tests.Roslyn.csproj /t:build
dotnet test Newtonsoft.Json.Tests.Roslyn.csproj -f netcoreapp1.0

Expected  behavior
Tests execute
Actual behavior
C:\Development\Source\Newtonsoft.Json\Src\Newtonsoft.Json.Tests>dotnet test Newtonsoft.Json.Tests.Roslyn.csproj -f netcoreapp1.0
Build started, please wait...
C:\Program Files\dotnet\sdk\1.0.0-rc4-004771\Microsoft.Common.CurrentVersion.targets(1956,5): warning MSB3277: Found conflicts between different versi
ons of the same dependent assembly that could not be resolved.  These reference conflicts are listed in the build log when log verbosity is set to det
ailed. [C:\Development\Source\Newtonsoft.Json\Src\Newtonsoft.Json.Tests\Newtonsoft.Json.Tests.Roslyn.csproj]
Build completed.

Test run for C:\Development\Source\Newtonsoft.Json\Src\Newtonsoft.Json.Tests\bin\Debug\netcoreapp1.0\Newtonsoft.Json.Tests.dll(.NETCoreApp,Version=v1.0)
Microsoft (R) Test Execution Command Line Tool Version <IP_ADDRESS>
Copyright (c) Microsoft Corporation.  All rights reserved.

Starting test execution, please wait...
Error: Failed to initialize client proxy: could not connect to test process.

Environment data
C:\Development\Source\Newtonsoft.Json\Src\Newtonsoft.Json.Tests>dotnet --info
.NET Command Line Tools (1.0.0-rc4-004771)

Product Information:
 Version:            1.0.0-rc4-004771
 Commit SHA-1 hash:  4228198f0e

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\1.0.0-rc4-004771

@JamesNK This could be due to missing shared runtime. Here are the troubleshooting steps:

Run dotnet test -d:log.txt
In the log.txt file generated, find the command line of dotnet exe invocation (search for exec  or `dotnet)
Copy the command line and run it directly in command prompt
You will see an error message on which shared runtime version is missing. Install it from https://www.microsoft.com/net/download/core#/runtime

Related to #281.

I run this:
C:\Development\Source\Newtonsoft.Json\Src\Newtonsoft.Json.Tests>dotnet exec --runtimeconfig "C:\Development\Source\Newtonsoft.Json\Src\Newtonsoft.Json.Tests\bin\Debug\netcoreapp1.0\Newtonsoft.Json.Tests.runtimeconfig.json" --depsfile "C:\Development\Source\Newtonsoft.Json\Src\Newtonsoft.Json.Tests\bin\Debug\netcoreapp1.0\Newtonsoft.Json.Tests.deps.json" "C:\Users\James\.nuget\packages\microsoft.testplatform.testhost/15.0.0-preview-20170210-02\lib
/netstandard1.5/testhost.dll" --port 3066 --parentprocessid 13476 --diag log.host.17-02-11_17-09-59_17962_5.txt

And I didn't get any output in the console.
I did take a look inside the log.host.date.txt file and saw this:
TpTrace Error: 0 : 10324, 1, 2017/02/11, 17:12:37.460,<PHONE_NUMBER>89, testhost.dll, TestHost: Error occured during initialization of TestHost : System.IO.FileLoadException: Could not load file or assembly 'Newtonsoft.Json, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'Newtonsoft.Json, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'
   at Microsoft.VisualStudio.TestPlatform.CommunicationUtilities.JsonDataSerializer..ctor()
   at Microsoft.VisualStudio.TestPlatform.CommunicationUtilities.JsonDataSerializer.get_Instance()
   at Microsoft.VisualStudio.TestPlatform.CommunicationUtilities.TestRequestHandler..ctor()
   at Microsoft.VisualStudio.TestPlatform.TestHost.DefaultEngineInvoker.Invoke(IDictionary`2 argsDictionary)
   at Microsoft.VisualStudio.TestPlatform.TestHost.Program.Main(String[] args)
TpTrace Error: 0 : 14948, 1, 2017/02/11, 17:12:59.982,<PHONE_NUMBER>40, testhost.dll, TestHost: Error occured during initialization of TestHost : System.IO.FileLoadException: Could not load file or assembly 'Newtonsoft.Json, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'Newtonsoft.Json, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'
   at Microsoft.VisualStudio.TestPlatform.CommunicationUtilities.JsonDataSerializer..ctor()
   at Microsoft.VisualStudio.TestPlatform.CommunicationUtilities.JsonDataSerializer.get_Instance()
   at Microsoft.VisualStudio.TestPlatform.CommunicationUtilities.TestRequestHandler..ctor()
   at Microsoft.VisualStudio.TestPlatform.TestHost.DefaultEngineInvoker.Invoke(IDictionary`2 argsDictionary)
   at Microsoft.VisualStudio.TestPlatform.TestHost.Program.Main(String[] args)

The assembly I'm testing also happens to be Newtonsoft.Json.

What's the version of json.net under test? If it's a higher version, the dependency closure should ensure it always picks the highest version.
Testhost requires 9.0.1. Can you please share C:\Development\Source\Newtonsoft.Json\Src\Newtonsoft.Json.Tests\bin\Debug\netcoreapp1.0\Newtonsoft.Json.Tests.deps.json?

Ah success. Increasing the version number to be higher than 9.0.1 worked.
FYI for future trouble shooting: deps.json only shows package versions, not assembly versions, which is what mattered here.


support for secrets

https://github.com/kubernetes/kubernetes/pull/63826 got merged in main k/k.
What's the best way to implement/support this? provisioner/csi/flex-volume?

/cc


Allow PUT without If-Match in control-http API.  Also allow HEAD.

Fixes #218

:+1: looks good!

:+1: this looks fine to me, although it would probably be good to switch to the finagle-http constants as opposed to the hard-coded strings here


fix: allow setting storage class

We need to set the storage class for vantage to not use the default storage class. This enables that.

FYI: @macb

thanks @icco, your change is available in chart version 1.0.23

Thanks!


[6.x] Fix model restoring right after soft deleting it

Relates to #31527
When we soft delete a model it becomes dirty, so if we try to restore it after deletion, the deleted_at column is not cleared. We need to sync the model, setting dirty to false, then the restore works.

Hey there, could you send this to the 7.x branch? Thanks.

Nevermind.


Collaborate with apollo-accounts

Hi @gadicc, I've been working on a similar set of packages https://github.com/apollo-accounts/. After seeing your packages it got me thinking that maybe we should combine our efforts rather than having two different implementations of accounts systems for apollo being published and maintained.
Let's go over each other's work so far and see what ideas comes up? I'm also willing to setup a video call or slack (I'm in the apollostack slack) if you want to discuss in real time.

Hey!  Wow, wish we came across each others work sooner.  Definitely makes sense to work together.
How far along are you?  Is the apollo-accounts-example working and up to date?  From my side, I was actually just about to announce this.  There is 100% test coverage on all core packages (apollo-passport, local, rethinkdb, mongodb, but not for react yet) and starter kits for saturn and Meteor.  Notably missing currently is the Meteor style accounts-ui config, and email support (for verification and email recovery).
I'm actually quite over time budget with this, and the earliest I'll be able to take a proper look at things again is only next week.  I did have a quick look over the apollo-account repos though.  Great work so far!  (and a lot of it).  Between the two, there is both overlap but also fairly extensive work in different directions.  I'm not quite sure the best way yet on how to combine efforts.  But yes, would probably be a good idea to go over all the different aspects comparing the different approaches we've both taken, to discuss.  Will get to this as soon as I can.

To answer your first question, apollo-accounts-example is not up to date.
I think the largest distinction between our projects is that you're using Passport whereas I'm using Grant. I tried a Passport implementation originally and found myself wrestling with finding integration points into Passport. Plus In my opinion I found Grant's codebase to smaller and simpler to understand than Passport's.
It looks like we had similar ideas creating database specific packages which must implement the api.
You've done significantly more work on the GraphQL portion that I have (I especially like the discover functionality). It looks like you also have integration with Redux.
On my end I've still got to finish the middleware for verifying access and refresh tokens and setting the logged in user's id. Then implement the GraphQL for local login, signup and password recovery. However the core functionality of logging in with an outh service, having user records created, and tokens issued is functioning.
I think between our projects you've done more in terms of functionality but I'm finding mine to have a simpler design (granted I'm operating under a bias having written that code).
In case it helps, this is what the initialization code looks like on the server. It's very similar to yours.
That's all I've got so far, need to dig into your codebase a bit more.
import Accounts from 'apollo-accounts-knexjs'

const config = {
   server : {
      secret,
   }
   github: {
      key,
      secret
  }
}

const accounts = new Accounts(config, connector);

// Middleware to setup callback routes
// Verify the tokens sent in the header
// Decode token and set user id
app.use(accountsExpress(accounts));

app.use('/graphql', apolloExpress((req) => {
  const userId = req.userId;

  return {
    schema: [executableRootSchema],
    context: {
      accounts,
      userId,
    },
  };
}));

@gadicc Gentle reminder about this issue 😄

Hey @TimMikeladze, thanks for your patience!  I promise I didn't forget about this, was just quite a crazy week.  (Bold / italic use below is more to make this long reply easier to scan through, rather than overly emphasize the actual statements)
On that note, I do want to be up front about my time.  As I mentioned before, I was about to stop working on apollo-passport for a while, now that it's usable - aside from smaller, more incremental improvements as needed (I wanted mainly to invite others to get involved).  Merging projects (this is the goal here, right?) is, I agree, the right thing to do, but obviously will involve a fairly big time investment from both of us, and I just want to be honest that my time is fairly limited atm.
Did you have any ideas of how to best integrate the two projects?  From my side, it's preferable to use apollo-passport as the base, simply because there's already 100% coverage on all core packages, automated testing is all in place, PRs will report coverage changes, contributing guidelines are all in place, basic functionality is all working and there are starter kits for meteor & saturn.  It would be great to never move backwards in that we know that every merge keeps everything working, although this does give apollo-passport a big initial advantage (discussion on specific parts follows below).
Regarding Grant vs Passport, I definitely agree with you.  Passport is not ideal but I decided to go with it because it's so well known and so many people are already using it.  Notably:

PassportGrant
Strategies300+150+
Github Stars8k1k

This was my motivation for the extra pain in dealing with it.  I believe I've solved everything except getting detailed error text for some cases, I need to look at it again.  But if I have a working Passport implementation, and you have one for Grant, it makes me wonder if we can (or should?) support both.
The other thing I wanted to ask you about here was your use of extractors.  Do we need to build one for every strategy?  This is possibly another advantage of Passport; it makes these requests for you and also normalizes the output to common field names used by all the plugins (you still have access to the raw fields though).  The only "extra" things we'd need to add are the instructions to register (a la accounts-ui) and service icon.
Name wise, apollo-accounts, of course, is a lot more descriptive.  The only other thought I had here was that there isn't too much about the project that is apollo specific, and I had wondered about having apollo/graphql as just one type of transport, essentially making this is an authentication microframework that could also impact adoption.  Of course that's a more long term thought.
Database packages, yes, I don't think there's any other way to do it :>  It's a nice model that's easy for others to emulate, e.g. @tomitrescak made a MongoDB driver before I even had a working release ready :>  Perhaps agreeing on the API would be a great first step moving forward.  On that note, however:
Meteor compatibility was important for me, I really wanted to be able to repeatedly swap between Meteor accounts and apollo-passport, to ease developer pain and allow for incremental adoption.  This is the one of the reasons I used the same schema (the other being that it's quite sensible), and also let's us use a single, familiar User object format everywhere (including in end-user code or other potential packages).  To that end, it was my intention for any SQL database connectors to split up the data amongst their respective tables as needed.
Re GraphQL, this all works but is a bit of a pain mostly due to https://github.com/apollostack/graphql-tools/issues/110.  I'm currently merging the typeDefs with regexs as an interim workaround, but as soon as I have time I want to try @tomitrescak's apollo-modules.
Re Redux, it was a design goal to make this optional.  It's very easy to integrate and super comfortable to use as expected with Redux, but the react package includes a Provider and  connect-like function for those not using Redux.  On that note, besides for that, this is my least favourite package (with no tests); it does all work though.  It looks like your material design package is much better structured, but of course, has a requirement on material-ui, which may preclude it's use for a lot of devs.  In general I'd like to aim for any react implementation to use react-storybook for design.
Re design, things did start off simpler but did get a lot more complicated as the project developed, especially working around Passport, as you noticed.  I'll be happy to take suggestions to simplify the code.  I care more though about how simple the end-user API is which must remain a priority.
I'm also behind on refreshing tokens but the local package is all done, except for emailing (verification / password reset; you can change passwords though if you know your old one).  (And then as mentioned earlier, a setup wizard like accounts-ui isn't done yet)
I also wonder if we should invite others to get involved in this discussion to hear outside input on some of these issues, what do you think?

I hear you on the time. Mines limited but I can dedicate enough time to keep the project moving. The majority of my projects require an accounts system so I'd prefer to have a proper solution than hacking together something every time.
Passport vs Grant
My concern with Passport is that compared to Grant it appears to be larger and more complex then it needs to be.
The different strategies are split up across packages whereas in Grant they are all colocated into a single JSON config file. On the other hand Passport does standardize the user profile response. This is what my extractors are doing in order to obtain a unique identifier for the user from the service. You're right in saying that an individual extractor is need per service however I think there's a common pattern here which we can use. It's a matter of knowing which endpoint(s) supplies profile information. A possible implementation is specifying them in Grant's ouath.json file.
Passport is also limited to just Express whereas Grant supports Koa and Hapi as well, as does Apollo Server.
Passport is more popular than Grant but also consider the issue counts, 170 vs 0. Passport does have an advantage on number of strategies supported however I think it would be easier to add more strategies to Grant than it would to Passport (create separate strategy package vs adding to a single json config).
In short, I have more confidence in Grant, especially if it comes down to sending PRs if there are issues. Whether Passport or Grant, the package we choose provides a core functionality of this project which is why I think it's important to make this decision carefully before moving forward.
UI
I spent more time on the material design package because it was the fastest for me to build. I agree that material-ui cannot be a requirement. I have fallen in ❤  with React Storybook in the past month and definitely want to use it for React components in this project.
I'm thinking there should be individual packages for unstyled, material, bootstrap, etc Account UIs. They could be strictly presentational and be consumed by higher order components which enhance them with additional functionality like GraphQL usingreact-apollo or connecting them to a Redux store.
Transport and Naming
Having GraphQL as just a type of transport rather than the only one is a great idea. We could certainly achieve this. In fact in my packages the only usages of Apollo/GraphQL are for local account mutations (login, signup, recover) and the client network interface middleware to send the tokens in the header.
You're right, Apollo Accounts is more descriptive but if Apollo/GraphQL are just a transport then perhaps a more generic name would be more suitable like JS Accounts or Node Accounts?
Meteor and API
Meteor's end user API for Accounts is great and I think trying to emulate it is a step in the right direction. Especially for compatibility purposes if you're swapping out Meteor Accounts with this set of packages.
Moving forward
We should definitely involve more people in the discussions, Apollo's Slack would be a good place to start. Perhaps @tomitrescak and @davidyaha have some ideas since they both have packages in similar veins.

[ ] Move all the repos under a single organization and get the documentation and issues ready for consumption by other contributors.
[ ] Decide upon the end user API.
[ ] Evaluate and improve the implementations of database specific packages.
[ ] Passport vs Grant, choosing the latter will involve rewriting some code (on my part all the server side packages have tests).
[ ] UI packages

Especially for compatibility purposes if you're swapping out Meteor Accounts with this set of packages.

I think the big decision here is - how much compatibility do we want with Meteor accounts? I think it's not a huge deal personally as long as it's possible for people to write a shim that makes the two work together.
We've been thinking about possibly porting Meteor accounts to work with GraphQL, but I don't think there's anything in there that can't be replaced by the approach talked about here.

You're right, Apollo Accounts is more descriptive but if Apollo/GraphQL are just a transport then perhaps a more generic name would be more suitable like JS Accounts or Node Accounts?

I think the way to win here is to focus on a specific community at first, and the Node/JS community seems way too large as a starting point.
IMO branding it as "GraphQL accounts", and having Apollo tie in closely with it, could be a great idea. So you can rely on a specific GraphQL schema for the accounts data, but the client you use to access it is up to you.

@TimMikeladze, I'm in the same boat.  Accounts is critical for my current and most likely all future apps :)
@stubailo, great to see you here :>

Passport vs Grant - I'm convinced :)

UI - we're on the same page.

Meteor compat - oh, I actually just meant the DB, not API compatibility.  But yeah a shim for the API would probably be appreciated by a lot of people; might be a while before we can offer all the same features though.  The main thing for me is that existing users can still log in after switching systems (in both directions).

Name and transport - yes, I definitely want to focus exclusively on Apollo in the beginning.  It's more about forward planning (structure, API, name).  It's a bit petty but I'd love a shorter name to be able to prefix the package types, like blah-db-mongodb etc :>  apollo-passport-db-mongodb seemed a pain, but I guess Babel does it for plugins and presets.  Btw, looks like there is another node accounts WIP, we should give the author a heads up as things start to take shape here.

Moving Forward
Ok, I'll move everything over to apollo-accounts, please give me access.  Would like to clarify a few more housekeeping matters first though.

Can you take a look at my CONTRIBUTING.md and see if you agree with everything?  The bit about PRs even with a commit bit is more long term; obviously I don't mean for the initial active development.

Testing.  I have a big preference for keeping tests in the same directory as the code - over many projects, I just find this pattern has better results.  100% coverage or near 100% coverage is important to me (and with coveralls we'll get a coverage diff in PRs).  Happy you're also with mocha+chai.  I prefer should() format, but if we don't allow both I'll switch to expect().

Callbacks vs promises.  Maybe premature to bring this up, but I prefer the latter (especially with await/async) wherever possible.  Looks like you agree though :)

Not a biggie, but, might be easier to keep client/server code in a single package, since they'll usually need to be kept in sync, and this would make it easier both on us for publishing and devs for updating.

Redux.  Did you agree on this being both supported but optional, with alternative Provider/connect functions for those who don't want it.

I'm still not 100% sure where to begin.  The database packages are indeed a good start.  But from there, to where?  Are we going to try merge one project into the other?  Do this package by package to decide which to be the base?  Start fresh and merge in pieces feature by feature?  What are your thoughts?

@gadicc you've been added to the organization. I left an issue for @Mitica on that node accounts project.

Contributing looks good.
I've started keeping tests in the same directory lately and prefer it over having a dedicated test folder. I've only used expect but am cool with should.
Client and server in the same directory sounds fine. I haven't had any problems keeping them separated though.
Redux, supported but optional, so yes.

Where to begin? I think the cleanest approach would be to start fresh and pull in reusable code from our packages. Let's start at the database side. If we use my database code there needs to be some small tweaks made to align the database schema with Meteor's.

Thanks for squeezing in a quick reply!  And for the org invite.  I wonder though, if we're starting fresh, if it might be better to start a new org then, so it's clearer what's going on?  Rather than potentially having 3 repos (your old, my old, our new) for each component?  Or I could add you to and rename apollo-passport, and we could keep legacy code in there?
I'm happy to create a new repo template, with circle-ci and coveralls etc.  Though the database connectors we could probably move over as is and adjust from there.
See what you think of the apollo-passport DB, particularly the API, since there's already full jsdocs with tests, my rethinkdb one and tomitrescak's mongodb one.  I don't think you need to worry about Meteor compatibility, since there's no way to run current accounts on a non-MongoDB.  But internally (in apollo-passport in general) I used Meteor user object format { emails: { address: "..." }, services: { facebook: { .... }, password: { ... } } - we can talk about this, but it's quite a convenient "standardized" way to pass everything around.  It means for SQL we'd need to store the data in separate tables and reassemble it on load.

@gadicc the api looks good, it's pretty similar to what I have going on. Here's the base class https://github.com/apollo-accounts/apollo-accounts-server/blob/master/src/Accounts.js and here's the Sql adaptor for it https://github.com/apollo-accounts/apollo-accounts-knexjs/blob/master/src/index.js
If a repo is already created just move the existing code to a new branch and start a fresh on master.  Getting coveralls setup would be great. I have CI configured to run the tests and linting, plus there's also a webpack dev server setup as well. That code might be useful.

Ok great!  I can also add coveralls, etc to any existing repo of course.
This might seem like a trivial issue, but have you had any more thoughts about naming?  I just ask because it's a bit of a pain updating circle-ci, coveralls, etc afterwards.  For now I think we're sticking with apollo-accounts, right?  I spent sometime thinking about other names but anything cool was already taken :>
Btw, you're only waiting on me for a package skeleton, right?  If I understood correctly, you're currently working on adapting apollo-accounts-knexjs to use the same API as the mongodb/rethinkdb packages?  After that, I think, most of the server code will come from you (grant integration) and I could guess a lot of the client from me (self state management with optional redux adaptor).  For react we said we'd use the same approach I used (supporting both redux and not) - for that, obviously the provider/connect I'll copy across, and then we can separate state management from one of the packages and get my basic react meteor theme working with it and your material-ui one.
I guess this will be a lot easier once we have final repos for each package and can open individual issues and assign them as needed.

On the topic of naming, there was a discussion here https://github.com/apollostack/apollo-server/issues/163 that can be applicable here.  Maybegraphql-accounts or graphql-server-accounts?
Yes waiting on you for a package skeleton. That sounds like a plan. I'm planning on dedicated a chunk of time towards this effort over the weekend.

Argh, can't believe there's another name change :D  Thanks for the ref and the quick reply.  I guess graphql-accounts is the way to go then, except we use apollo-client :confused:  I prefer without -server because we're a fullstack solution.
Ok great, yeah, I'm a bit behind but will get moving; also have more time coming up, probably only after the weekend though.

It's true that we're using apollo-client but I could see a case where we support any graphql client.

Hey @TimMikeladze, looks like a lot of great work going on there :D  I'm moving the passport stuff back to the original org for clarity (as per #10).  Please let me know when you want me to look at anything or feel free to just assign stuff to me on github.

Thanks dude. Good call on moving the passport stuff. I'll be deleting my apollo-* repos as well.
I'll start assigning or mentioning you. Also been marking issues with the low hanging fruit label for quick stuff to pick up.


Update codecov-action version

This does NOT solve the problem because codecov appears to be using a very old commit as the BASE:
https://app.codecov.io/gh/google/go-github/commit/2b8c7fa86fcd1cb4a89a44c8e7b5a49fe4be8a45
After more investigation, I found this thread:
https://community.codecov.com/t/incorrect-base-commit-of-pull-request/1779/2
However, its "solution" was solved in a private conversation. I'll try adding to the thread.

According to this: https://github.com/codecov/feedback/issues/123
It may be that the codecov token being used is out-of-date?!?

This issue also mentions the codecov token: https://github.com/codecov/feedback/issues/144

@google-admin - when you get a chance can you please make sure that this repo's CODECOV secret repo token is up-to-date?
According to all the similar issues I could find (linked above), they say that an old CODECOV token could be the cause of it choosing very old (6-months ago) BASE commits to compare against.
Thank you!

@google-admin - when you get a chance can you please make sure that this repo's CODECOV secret repo token is up-to-date?
According to all the similar issues I could find (linked above), they say that an old CODECOV token could be the cause of it choosing very old (6-months ago) BASE commits to compare against.
Thank you!


tapis executable not in PATH

Describe the bug
pip install --user --local .

runs successfully, but the tapis command does not get added to the $PATH variable, and it can be hard to find where it got installed (not in the printout after the pip install)
To Reproduce
Steps to reproduce the behavior:
docker run --rm -it jurrutia/cli-test:022020
git clone https://github.com/TACC-Cloud/tapis-cli-ng.git
cd tapis-cli-ng
pip3 install --upgrade --user .
tapis --help

Expected behavior
tapis added to the PATH, or print out the location of the install (or both)
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: iOS and
Ubuntu 16.04.4 LTS (Xenial Xerus)

Additional context
Add any other context about the problem here.

leaving off the --user on the pip install fixes this and installs the executable under:
/usr/local/bin/tapis

This should be resolved for general usage when we move to installing the CLI from pip


Only show URL for issue update

Current dependencies on/for this PR:

main

PR #62   👈

This comment was auto-generated by Graphite.


Google login not working

Hello @Panshak
Seems like Google Auth is not working. The user is being redirected to the Google login screen, selects an email, the Auth tab closes but googleSuccess in /components/Login/Login is not being called.
I forked your project and started working on Bulkit. Thanks for the great setup!

The problem is likely from your Google auth configuration.
Please make sure that it looks like this (screenshots) but with your own domain.

I meant Auth is not working for www.arcinvoice.com on Brave.
I now tried with Safari and it worked


Update Thrift bindings for 4.6

The Thrift bindings were re-factored in 4.6, regenerate the Python bindings just to ensure everything in sync.

Note that for this, need to ensure that unnecessary imports removed, to avoid reintroducing issue arising in past where unneeded imports caused issues when trying to use reticulate from R

Also beware that a few things were split out and rearranged a couple days ago in master, so you might need to handle a new common module.

Closed by #228


[service-bus] Make our stress tests easier to run in containers

Make a Dockerfile to hold the files
Make a script (runcontainer.js) which allows you to easily build, push and create an ACI to run the stress test
Updated the tests against the GA version of Service Bus (they were still using preview.8, aka Service Bus "classic")

cc @mikeharder

cc @mikeharder


Email button showing up on Search page

On the Change search page the email button is currently appearing. This should only show up when a change record is open

Resolved with last code drop


Release v2.1.0

TODO:

[x] Confirm a hyp3-test burst job succeeds: https://hyp3-test-api.asf.alaska.edu/jobs/8a598bce-a0aa-444d-84dd-bb02c309394b
[x] Run these three commands locally on develop to validate insar_tops_burst
[ ] Do we need to validate insar_tops and insar_stripmap?

We should continue to support insar_tops but I'm fine with not taking on the responsibility of insar_stripmap until we know that we have users actually using it.
I've opened a small PR fixing insar_tops and confirmed that the command below runs as expected.
insar_tops \
--reference S1A_IW_SLC__1SDV_20200604T022251_20200604T022318_032861_03CE65_7C85 \
--secondary S1A_IW_SLC__1SDV_20200616T022252_20200616T022319_033036_03D3A3_5D11 \
--polarization VV \
--looks 20x4

Golden tests have passed


[SPARK-28784][SS] Use CheckpointFileManager in StreamExecution/StreamingQueryManager for checkpoint dirs

What changes were proposed in this pull request?
After SPARK-23966 Refactoring all checkpoint file writing logic in a common CheckpointFileManager interface, the CheckpointFileManager interface was created to handle all structured streaming checkpointing operations and helps users to choose how they wish to write checkpointing files atomically.
StreamExecution and StreamingQueryManager still uses some FileSystem operations without using the CheckpointFileManager.
For instance,

https://github.com/apache/spark/blob/master/sql/core/src/main/scala/org/apache/spark/sql/execution/streaming/StreamExecution.scala#L137
https://github.com/apache/spark/blob/master/sql/core/src/main/scala/org/apache/spark/sql/execution/streaming/StreamExecution.scala#L392

Instead, StreamExecution and StreamingQueryManager should use CheckpointFileManager for these operations.
Why are the changes needed?
This change will allow users to use CheckpointFileManager for structured streaming checkpointing files without need for a separate FileSystem implementation for the same.
Does this PR introduce any user-facing change?
No
How was this patch tested?
Existing tests

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Test build #109428 has started for PR 25514 at commit 97bcf5b.

@tdas Could you please take a look at this PR ?

Test build #109428 has finished for PR 25514 at commit 97bcf5b.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/109428/
Test FAILed.

Thank you for your first contribution, @shrutig .
Could you add a unit test case for your contribution? That will protect your contribution from the accidental future regressions.

Retest this please.

Test build #109519 has started for PR 25514 at commit 97bcf5b.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/14576/
Test PASSed.

Test build #109528 has started for PR 25514 at commit 9a92b5e.

Updated DataStreamReaderWriterSuite tests which were relying on resolvedCheckpointRoot variable in StreamExecution to use the checkpointFileManager method.
Plus, there is another test "should resolve the checkpoint path" already existing in StreamSuite file.

Test build #109519 has finished for PR 25514 at commit 97bcf5b.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/109519/
Test FAILed.

Checking the tests. The tests seemed to have passed on my local machine

Test build #109528 has finished for PR 25514 at commit 9a92b5e.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/109528/
Test FAILed.

Hi, @shrutig . Did you run the unit test locally? Does this PR pass in your environment?

Please don't change the existing UTs.
Please add a new UT which fails in the master branch without your patch.
Run the UTs locally in order to make it sure that your PR is valid.

IMO, it's not worth to switch to CheckpointFileManager considering we just found some issues in FileContext's checksum. See https://issues.apache.org/jira/browse/SPARK-28025.

Retest this please.

Test build #109960 has started for PR 25514 at commit 73ff29b.

Hi, @zsxwing .
If this PR makes these consistently, isn't it easier for us to change this together later without leaving something behind?

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/14983/
Test PASSed.

IMO, I don't feel comfortable to move to a known broken API when the existing codes work.

I got it. Thank you for the guide, @zsxwing .
In this case, @shrutig . We had better close this PR. I know your intention, but we cannot merge this according to the above advice. Could you close this?

Isn't the issues @zsxwing refers to fixed in https://github.com/apache/spark/pull/25488 ? Also if this is still broken then maybe we should revert all uses of CheckPointManager? It seems that whichever we do we should do consistently.

Test build #109960 has finished for PR 25514 at commit 73ff29b.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/109960/
Test PASSed.

The issue not yet fixed, it may happen in https://issues.apache.org/jira/browse/HADOOP-16255.

I want to clear up some concerns which were mentioned here:

CheckpointFileManager is an API which was added in https://issues.apache.org/jira/browse/SPARK-23966 (https://github.com/apache/spark/pull/21048) to enable users to plug in their custom implementation for the createAtomic, delete, exists, etc functions (https://github.com/apache/spark/blob/master/sql/core/src/main/scala/org/apache/spark/sql/execution/streaming/CheckpointFileManager.scala#L48) . This API is today already widely used in HDFSBackedStateStoreProvider for checkpoint operations.

The default implementation of the CheckpointFileManager api is FileContextCheckpointFileManager which has a bug in the createAtomic function, leading to file leaks. This JIRA elaborates the same : https://issues.apache.org/jira/browse/SPARK-28025 .

The change I am proposing in this PR does not add any usage of createAtomic method. I am aware of no bugs in the delete, mkdirs and exists functions of default CheckpointFileManager implementation. So, this PR should not be adding to the problem of leaving file leaks. @zsxwing @gaborgsomogyi  Can you please elaborate on your concerns and mention any known issues with the  delete, mkdirs and exists functions of default CheckpointFileManager implementation ?

cc @tdas

It also looks like the default implementation issue has been fixed in https://issues.apache.org/jira/browse/HADOOP-16255
Since the FileContextCheckpointFileManager doesn't have any known issues with these code paths that are being added, unifying access to the same data is probably better, and from the original PR (cbb41a0c5b01579c85f06ef42cc0585fbef216c5) adding the CheckpointFileManager it sounds like the goal is to make this plug-gable which only works if it is used consistently inside of Spark (although @tdas can correct me on that point).

Can one of the admins verify this patch?

Jenkins ok to test.

@dongjoon-hyun it looks like you aren't asking for any specific change anymore, is that correct?

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/16117/
Test PASSed.

Test build #111021 has started for PR 25514 at commit 73ff29b.

Test build #111021 has finished for PR 25514 at commit 73ff29b.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/111021/
Test PASSed.

Retest this please.

Test build #114916 has started for PR 25514 at commit 73ff29b.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/19738/
Test PASSed.

Test build #114916 has finished for PR 25514 at commit 73ff29b.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/114916/
Test PASSed.


Adding new product summary

Codifying the goals for the project on the homepage. Added a deployment
diagram.

We can roll this back if there's deep disagreement. Given the current marketing problems we're trying to address. I think selling the project goals is a good use of the homepage. Feel free to disagree @jglovier @tracicakes @jkleinsc. Otherwise, I'd like to merge this.


Add workaround for PoET Round 3

Motivation
Closes #4967
Changes

For PoET round 3 / publish epoch 4 PoET 111 will be added to the local state to fetch proofs from if the node registered to PoET 110 for that round.

Test Plan

Added tests to ensure workaround works for the correct epoch / round

TODO

[x] Explain motivation or link existing issue(s)
[x] Test changes and document test plan
[x] Update documentation as needed
[x] Update changelog as needed

bors merge

bors merge


Add font licenses

Include licenses with each font.

This also added the Source Sans font (which I forgot to add previously).


Implement a more secure way to store the domain mapping of curved meshes

The current way of storing the domain mapping is to save the code of the definition of the mapping as a string, and load the mapping after a restart using eval.
This is a security issue, since malicious code in a HDF5 file can be executed.
We should use a different approach to store the mapping, for example storing an interpolation (of a higher degree than the polydeg of the solver, such that a simulation can be restarted with a higher polydeg), and showing a warning to the user if a simulation gets restarted with a higher polydeg than the degree of the interpolation of the geometry.

IMHO there's no need to store anything at a higher polydeg for now. Just store it for the current polydeg and if somebody needs Tha ability to restart at a higher order, they can add the functionality then

We need to remember to search for
TODO: `@eval` is evil

when fixing this


Refactoring Cassandra visibility persistence manager for NoSQL support

What changed?

Create NoSQL interface for shard operation
Extract the logic of Cassandra to implement the interface
Replace visibiltyStore with NoSQL plugin db style

Why?
For https://github.com/uber/cadence/issues/3514

How did you test it?
existing tests

Potential risks
Low risks

Release notes
No

Documentation Changes
No

close in favor of https://github.com/uber/cadence/pull/4223


Replace old expired license with a new one

On master there is a demo-licence-8.lic. What is the idea of this file? Should I replace that too?

I think we can delete the licence on master!


VM is tests with generics

From the specifications:
16.34 Type Test

[...]

Evaluation of the is-expression e is T proceeds as follows:
The expression e is evaluated to a value v. Then, if T is a malformed or
deferred type (19.1), a dynamic error occurs. Otherwise, if the interface of the
class of v is a subtype of T, the is-expression evaluates to true. Otherwise it
evaluates to false.

So if I have something like types.dart:
f<A>(int x) {
  print(x is A);
}

class C<A> {
  p(int x) {
    print(x is A);
  }
}

main() {
  print("Through functions:");
  print("");

  print("int is int:");
  f<int>(42);

  print("int is String:");
  f<String>(42);

  print("int is string:");
  f<string>(42);

  print("");
  print("Through classes:");
  print("");

  C c = new C<int>();
  print("int is int:");
  c.p(42);

  c = new C<String>();
  print("int is String");
  c.p(42);

  c = new C<string>();
  print("int is string");
  c.p(42);

  print("");
  print("Directly:");
  print("");

  print("int is int");
  print(42 is int);

  print("int is String");
  print(42 is String);

  print("int is string");
  print(42 is string);
}

I wouldn't expect to get (I ran with '--reify_generic_functions'):
Through functions:

int is int:
true
int is String:
false
int is string:
true

Through classes:

int is int:
true
int is String
false
int is string
true

Directly:

int is int
true
int is String
false
int is string
Unhandled exception:
'[...]/types.dart': malformed type: line 51 pos 15: cannot resolve class 'string' from '::'
  print(42 is string);
              ^

#0      _TypeError._throwNew (dart:core-patch/errors_patch.dart:82)
#1      main ([...]/types.dart:51:15)
#2      _startIsolate.<anonymous closure> (dart:isolate-patch/isolate_patch.dart:265)
#3      _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:151)

(notice that 'string' is with lowercase 's').
So the last one - without generics - is what the specs seems to want.
But what's happening with
int is string
true

?
@sjindel-google (who ran into this).

This is working as intended: The invocation f<string>(42); will pass dynamic as the type argument, because string is a name which is undefined in the given context, and 42 is T will return true when the value of T is dynamic. A similar thing happens for c.p(42);.

Is this behavior correct for strong mode as well?

No, in strong mode, the type argument is actually passed and used, and Dart 2 will do that too.
Dart 1 does not have generic functions, but we have added the syntax so code can choose to support strong mode Dart anyway and be prepared for the future.

In this particular case the type arguments were actually passed (for the class because that's always the case, and in the generic function due to '--reify_generic_functions').
But in strong mode (and in the upcoming Dart 2) there can't be any surprising behavior at run time, because the expressions f<string>(42); and new C<string>(); are compile-time errors.

Even with strong mode enabled in the VM via "-c", the check returns "true" without any errors or warnings.


webdriver_update does not update IE

The line
webdriver_update.bind(null, ["ie", "chrome"])

does not get executed. Upon calling webdriver_update only the selenium .jar and the chromedriver .zip are downloaded/checked if latest.
My current workaround is
var webdriverUpdate = gulpProtractor.webdriver_update_specific({
    browsers: ['chrome', 'ie']
});

I saw this issue as well, and can confirm the workaround worked for me.

Hi, will the above code download iedriverserver.exe file of 64bit? if yes, can you please let me know how to download 32 bit version of iedriverserver.exe?

Have you tried using below one, if it does not work let me know.
var webdriverUpdate = gulpProtractor.webdriver_update_specific({
    browsers: ['chrome', 'ie32']
});


[Visual Issue] File selector overflows its bounding box

In the add service record screen, the file selector overflows its bounding box

what web browser is this? I cannot re-produce this in Chrome.

Oh right, that's an important bit of information. I'm on Firefox

This is fixed.


Getting grpc errors in corporate network - "Failed to connect to remote host: FD shutdown"

We are using firebase firestore in our mobile app, which uses grpc.  On iOS devices only, and on our corporate network only, we cannot connect to firestore.   We have turned on grpc logging, and see some errors:
"Failed to connect to remote host: FD shutdown"
Here is our corresponding firestore issue which gives the full logs.
https://github.com/firebase/firebase-ios-sdk/issues/3817

From the gRPC log it shows the TCP connection to <IP_ADDRESS>:443 was attempted and timed out after 30s. If that is a correct IP address hosting your service, I would suspect it's something in the network that's blocking the connection. Do you have any corporate proxy/firewall in the middle?


Add human_reference_atlas subset

I cant judge this! You are saying "subset", but you created a component.. I also don't see the related changes to the Makefile!

@matentzn wrote:

I cant judge this! You are saying "subset", but you created a component.. I also don't see the related changes to the Makefile!

This file is created from a robot template via a build job on https://github.com/hubmapconsortium/ccf-validation-tools. (template is not cached).  It contains only subset and present_in_taxon axioms (to Homo sapiens).  I think it makes sense as a component as it needs to be present in the editors file and available for all release files.  RE:Makefile - i thought it would be sufficient to have an import statement on the editor's file, or does the component need to be explicitly named in the Makefile?

Same concerns as uberon, otherwise fine

Looking good.  Is this ready to merge?


Issues with js-minifier?

Since you're using class name as key, it can get pretty messed up going through a JS minifier, am I right? I got a case where in dev it goes ok, then I published it for production and it got an errors where two handler classes ended up having the same name.

I'm working on a possible solution (see the className branch).
Can you provide a minimal example or you can try the dev branch?

Is there an update on this issue? I potentially have a similar bug where I expected handler X to be called, but instead handler Y was executed. I can't reproduce it in development, but it does occur in production.

I publish a beta version 1.3.0-beta.1 where you can specify a name for the className.

Thanks. It seems to be working. I'm not sure how to verify this, except that after minification, I can no longer reproduce the errors that I was having.
Is there an implicit way to implement this without having to explicitly define the unique ID in both the decorator and the request class?

Is there an implicit way to implement this without having to explicitly define the unique ID in both the decorator and the request class?

I'm open to suggestions ;-)

The v2 mediatr-ts have been released, there were breaking changes (interfaces and class has been renamed) see the README.
The code for add/get the request/notification was changed (code from beta1 was NOT ported), give it a try and send feedback about the issue.
If the problem persist you can try to remove className from minification.
For Webpack try this code.
module.exports = {
  mode: ...,
  resolve: ...,
  target: ...,
  optimization: {
    minimizer: [
      new TerserPlugin({
        terserOptions: {
          keep_classnames: true,
        },
      }),
    ],
  },
};

see this StackOverflow post


misspell

hi Habib
There is a extra "to" in your read me file before the url in this line :
"1-copy to https://github.com/kazemihabib/nativescript-FilePicker/tree/master/app/fonts to your app foloer"
Regards,
Mohammad :D
edit : i just notice that the spell of folder is also wrong :D

thanks, mohammad :)


⚠ gorzdrav.org has degraded performance

In 450d65b, gorzdrav.org (https://gorzdrav.org) experienced degraded performance:

HTTP code: 200
Response time: 3964 ms

Resolved: gorzdrav.org performance has improved in 72c1f0f.


openshift-ansible - use ansible evars vars.yaml for branch specific params

This PR is based on #1722
We are seeing release-3.9 jobs fail because they need infra nodes, which were removed in #1688. As all jobs in sjb use the same inventory, we can use this method of passing evars linked to a vars file in the target repo.
This PR depends on openshift/openshift-ansible#11286

openshift-ansible pr has merged, please merge this asap

/lgtm


What’s the limitations?

Are there any limitations on LLaMA 2 models I can run in the browser? Like, if I have a ~4 GB model (7B), can I run it on my iPhone/Mac through WASM?

I haven't tested but it might be too buggy (and slow) to run more than 2GB models with llm.js. This directly leverages the CPU w/WASM engine on the browser without any WebGPU acceleration. Also due to 32bit memory address limitations on the browser side, this library will not work (yet).
I'd highly recommend checking out these 2 projects if you are looking to run models over 4GB:

https://github.com/mlc-ai/web-llm
https://huggingface.co/docs/transformers.js


error while importing easygems.healpix

I was trying to import easygems.healpix on my computer and it is giving me an error saying ImportError: cannot import name 'trapz' from 'scipy.integrate'. My kernel is using python 3.12.4 and I could see that scipy version 1.14.0 is present in it.

Apparently scipy 1.14.0 removed the (deprecated) trapz function in favor of the new name trapezoid. This function is used by healpy and thus by easygems. Healpy fixed this problem last week, but there is not yet a new release of healpy available.
For now, the best workaround likely is to downgrade scipy to <1.14.0 until there's a new release of healpy. We may or may not draft a new release of easygems requiring this.
Once the fix in healpy is merged, we should add a dependency to the newest version of healpy.

Thank you! :) Switching to version 1.13.1 worked.

Should we require scipy<1.14.0 and release a new minor release for now?

Should we require scipy<1.14.0 and release a new minor release for now?

Or we are fast with #11 and circumvent the issue ;)

Should we require scipy<1.14.0 and release a new minor release for now?

Yes, I'd vote for this. Probably healpy will still take a few moments to make a new release and #11 at the moment seems to to be a little more involved than initially expected.

Ok, there's now easygems 0.0.8 which includes the temporary scipy restriction.

Do we consider the temporary fix as sufficient to close this issue? Or do we keep it as reminder to undo the fix when a new healpy is released?


Why the delay?

I have noticed that this project isn't updated regularly, don't you think some new features should be added, anexplorer is too good to be abandoned like this. My suggestion is to add an inbuilt IMAGE VIEWER, AUDIO and VIDEO PLAYER and one more important feature that's missing is ENCRYPTION, I guess with that, we should really standout different from the rest of other file managers, I also think we need Anexplorer to popup as an option when a user clicks on a ZIP or RAR file from a different application on his/her (I think making an intent or something for this should do the work just fine). What do you think? @1hakr

Hey @enwokoma just been busy. But the best part of why we opensource projects is the community and people like you can contribute aswell. I would love to build new things but i would love more to see community take it forward.

Sure! However I can help, I would try my best to make that possible! Do
have a nice day.
Now u can close the issue, just used it to get your attention 😉
On Aug 19, 2017 09:31, "Hari Krishna Dulipudi"<EMAIL_ADDRESS>wrote:

Hey @enwokoma https://github.com/enwokoma just been busy. But the best
part of why we opensource projects is the community and people like you can
contribute aswell. I would love to build new things but i would love more
to see community take it forward.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/1hakr/AnExplorer/issues/69#issuecomment-323509616,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AY9OJRhj7oHFczyZg0WbzVIHS2cPxKgjks5sZp1UgaJpZM4O8PTG
.

Sure mate!


(RSFB-929) REGEXP_LIKE function fix

Please check one test case is failing in ReltoSqlConverterTest
testFunctionsWithRegexOperands

Please check one test case is failing in ReltoSqlConverterTest testFunctionsWithRegexOperands

i have changed that please have a look

Please check one test case is failing in ReltoSqlConverterTest testFunctionsWithRegexOperands

i have changed that please have a look

Okay LGTM


Visualizations: Enable first iterate of faceting

The following features comprise the first iterate of faceting:

One facet var - always column facet
Max var values allowed is 8
Thumbnail image shows 2 panels
No data always plotted in the last column
Fullscreen/enlarging one panel (extra - could be dropped if time does not allow)

There is a web-components component to this feature, which is already under development.
Subtasks

[x] merge https://github.com/VEuPathDB/web-components/pull/162
[x] finish wiring/sorting (solves 4.) for all visualizations https://github.com/VEuPathDB/web-eda/pull/640 , #658, #659, #660
[x] fully implement FacetedPlot https://github.com/VEuPathDB/web-components/issues/240
[x] thumbnail image capture https://github.com/VEuPathDB/web-components/issues/241
[x] custom legend https://github.com/VEuPathDB/web-components/pull/237
[x] placement/layout of legend/side plots/controls for faceted and unfaceted plots in EDA https://github.com/VEuPathDB/web-eda/issues/648
[x] y-axis scaling for Boxplot https://github.com/VEuPathDB/web-eda/issues/650
[x] handle empty facets appropriately - wiring done, just finalising some styling here: https://github.com/VEuPathDB/web-components/pull/262
[x] finalise mosaic layout #725

ETA: here is a mock-up

@jtlong3rd has agreed to work on the thumbnail and layout issues.

Closing manually.  All subtasks done :tada:

Moving to complete. Steph is still qa'ing https://github.com/VEuPathDB/web-eda/issues/648, but that can be reopened or a new ticket made if needed


bug fix

fix a bug in previous PR. uncovered in sanity testing with new changes.

/approve

/approve

/lgtm

/lgtm


RE: Compiling and UPM

Hello,
This seems to be an error on my side but I cannot be completely sure.
will change in GCC 7.1

I am compiling every module in python, python3, c, and c++ for now w/ make.
I am on an ARM board w/ a 32-bit processor, e.g. am335x from TI.com.
Seth
P.S. I looked through many of my errors during compilation. I am seeing a python 2.7.13 issue and the highlighted section in this post from above, gives me ideas that the GCC version is out of date on my board. Do you think I am on the right track so far to correct this issue? I have gcc/g++ 6.x.x.

Hello,
I know have this version of gcc:
8.3.0

I am having severe issues w/ make.
See here:
make[2]: ***[src/2jciebu01_usb/CMakeFiles/jsupm_2jciebu01_usb.dir/build.make:63:src/2jciebu01_usb/CMakeFiles/jsupm_2jciebu01_usb.dir/CMakeFiles/jsupm_2jciebu01_usb.dir/2jciebu 01_usbJAVASCRIPT_wrap.cxx.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:869: src/2jciebu01_usb/CMakeFiles/jsupm_2jciebu01_usb.dir/all] Error 2
make: *** [Makefile:130: all] Error 2

Hello,
I think I figured it out. Thank you for the repo. to list the issue.
Seth

@Propanu yeah lets turn of JS builds...

@tingleby ,
Also, JAVA for debian 10 is on the fritz from what I remember. I put in a bug report a while back but the people might have already been aware of this bug I spent time filling out.
Just using default-jdk w/ apt install or default-jre gives errors on armhf boards on debian 10.
Seth


Create a README on Credential Precedence

Lately, there has been some confusion on the order of reading credentials from CLI/manifest/deployment/.wskprops/whisk.properties.
Refer to issue #471 and create a readme file with simple usage and examples.

Please review the document I am working on in my private repo. and is part of WIP PR https://github.com/apache/incubator-openwhisk-wskdeploy/pull/489

fixed in 489


[Question] send json serialize to client.post().body()

what is the best way to pass serialize struct to body
extern crate serde;
extern crate serde_json;

pub fn post<P: serde::Serialize>(&self, path: &str, body: P) -> String {
        let mut body_response = String::new();
        let serialized = serde_json::to_string(&body);
        let url = get_url(path);
        self.client.post(&url)
                .headers(self.get_headers())
                .body(serialized)
                .send()
                .unwrap()
                .read_to_string(&mut body_response)
                .unwrap();
        return body_response;
    }

error
.body(serialized)
   |                  ^^^^ the trait `std::convert::From<std::result::Result<std::string::String, serde_json::Error>>` is not implemented for `hyper::client::Body<'_>`
   |
   = help: the following implementations were found:
             <hyper::client::Body<'a> as std::convert::From<&'a mut R>>
   = note: required because of the requirements on the impl of `std::convert::Into<hyper::client::Body<'_>>` for `std::result::Result<std::string::String, serde_json::Error>`

Hello! If you look at the error message, you'll see that you're trying to pass a Result<String, serde_json::Error> as the body. You need to handle that the serde_json::to_string could have had an error.
However, I'd definitely recommend looking at the reqwest crate, it has code to do exactly this and more, already written for you.
Closing as this is a usage question, not an issue with hyper.

@seanmonstar thanks! I fixed it =D


Kernel keeps running out of memory

Kernel runs out of memory
WARNING:root:kernel <x> restarted
ihaskell: out of memory (requested 2097152 bytes)

This is with the docker image

What are you doing in order to trigger this?

Not sure happened randomly. I stopped using docker once I got the native install working. I was just running simple haskell programs. I ran them again after restarting and they worked.

Got it. I can't currently reproduce this so I am closing this but if I encounter it (or anyone can help me reproduce it) please re-open.
I'll be adding a benchmark which might help diagnose memory issues as well.


Targeting an object changes the font size of the entire UI

Description
When you target a planet, the entire UI's font size changes.
System Information
This was tested on my laptop with a 3200x1800 display while the game was running in 1920x1080 windowed.
Steps to Reproduce

Target a planet.
Untarget while watching the UI.

Actual Results
All the text shifts around and becomes larger when the object is targeted.
Expected Results
Everything should stay the same size.

A short-term fix could be using pushStyle() and popStyle(), although this is will no longer be an issue once we rework the overlay/menu system.

Yep, that's what I was thinking. Not sure what the performance cost is on those, but I doubt it's expensive. I'll give it a shot tomorrow.

I'm trying to reproduce / pin down what's happening. Let me know if you figure out the cause, and I'll also look for a clean way to fix this for now. Performance should be negligible as long as it's only happening a few times per frame.

This might be related to display density. It only seems to happen when I run the game at higher resolutions (>1080p).

This might be related to display density. It only seems to happen when I run the game at higher resolutions (>1080p).


Installation

Coverage increased (+0.3%) to 59.164% when pulling f83f4e74df7d65f75db44397a1596751d8ac39d4 on installation into 9b594a0642195c132f8aa5efad12d6d5459a6300 on master.


semantic tokens are not yet supported in gitpod

This line causes an error - registerDocumentSemanticTokensProvider is not a function - in theia, the vscode-like editor used in gitpod. They have not yet updated to the newest monaco system.
https://github.com/zigtools/zls-vscode/blob/115e0929d52080fd0fe3a8dbbfb21d7aef2bef6e/src/extension.ts#L41
Could you be so kind as to put some kind of error trap around this line so that it does not fail to start in this environment?
Thanks,
Mark

Sorry, this alone will not address the problem.


CPUID mappings for Core i5-7600K (Kaby Lake)

On my new computer, I found that OpenBLAS didn't recognize the CPU.  This was because it was getting an exfamily of 9, instead of the 8 that mapped to Kaby Lake in the existing OpenBLAS source.  This patch fixes that and adds in a few new CPUID mappings as best I could from the sandpile table.  Please verify that I interpreted the sandpile webpage correctly, there was some ambiguity with regards to huge pages and I just did my best to guess and choose the most reasonable choices.  With this patch, the tests all pass on my local machine.

Honestly I cannot comment on the validity of the cacheinfo data - I never saw this updated nor was asked to provide updates when I or others added cpuids. What will be needed though is a similar update of the code in driver/others/dynamic.c that does the runtime cpu type detection for the DYNAMIC_ARCH builds. (Exfamily 8 btw is what the first wave of low-power dualcore KabyLakes for notebook identifies as)

Ah, yes.  Thank you.  I've added that as well now, I'm verifying this works by calling openblas_get_config().  Here's the output, (invoked from Julia) in case you're interested:
julia> unsafe_string(ccall((:openblas_get_config64_, Base.libblas_name), Ptr{UInt8}, ()))
"USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell"


Post Details - Recent Weeks shows dates before post date

In this example the post was made in August yet in Recent Weeks its showing weeks before the post was made. I believe this is an API issue.

Closing issue and migrating to new repo.


Unable to start server

Local server cannot be launch, neither with python command nor Docker.
With wandb python command:
$ wandb local -p 18080
wandb: W&B local started at http://localhost:18080 🚀
wandb: You can stop the server by running `docker stop wandb-local`
wandb: You can find your API key in your browser here: http://localhost:18080/authorize
wandb: Paste an API key from your profile and hit enter:

Browsing http://localhost:18080/authorize shows connection refused.
Executing docker ps show no container named wandb-local.

Traceback (most recent call last):
  File "/sbin/my_init", line 430, in <module>
    main(args)
  File "/sbin/my_init", line 341, in main
    export_envvars()
  File "/sbin/my_init", line 116, in export_envvars
    with open("/etc/container_environment/" + name, "w") as f:
PermissionError: [Errno 13] Permission denied: '/etc/container_environment/PATH'

This is because the file system inside of your docker container is read only.  You either need to run the container as root, or configure your docker daemon to mount read / write filesystems.  How did you install Docker?

I tried on several Linux servers  and the same error was reproduced:

Docker 18.06.1 on Ubuntu 14.04
Docker 18.09.7 on Ubuntu 16.04
Docker 19.03.8 on Ubuntu 16.04

The Docker were install by someone else. Based on the apt configuration, I guess they were installed using instructions provided on the Docker web site.
On the other hand, there isn't such error when the same command is run on Docker Desktop for Mac.
Per your advice, the server is started normally on Linux when the container is launched as root with docker run -u root .... Please close the issue if this is an expected usage.

Please update the documentation...

@cmsax what command worked for you?  Did you run sudo docker run or docker run -u root?

wandb local & docker run & sudo docker run neither, docker run -u root worked for me too.

For anyone else finding this, the appropriate way to start the container when the default user / file permissions aren't working is:
docker run --user "100000:0" ...
Running the container as root is generally a bad idea and anything on our file system that needs to be written to has a gid of 0.


Replace LinkInterceptor with LinkClickObserver

Follow-up to https://github.com/hotwired/turbo/pull/382

In the same style as hotwired/turbo#382, replace instances of
LinkInterceptor with LinkClickObserver, making the necessary
interface changes in classes that used to extend
LinkInterceptorDelegate.
Conditional logic that was once covered in the LinkInterceptor is
moved into the predicate methods of the delegates (for example, the
FrameController.willFollowLinkToLocation and
FrameRedirector.willFollowLinkToLocation).

Same re: rebase and 7.2.0.


inline photos in article position doesn't work

i think this should be checking for 3 and not 4 https://github.com/cocoztho000/Sams-Blog/blob/master/read_blog.php#L114


sqlite: 3.41.2 -> 3.42.0

Changelog: https://www.sqlite.org/releaselog/3_42_0.html
Description of changes

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

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

[x] Fits CONTRIBUTING.md.

20/38 tracker:fts / fts                               FAIL             0.79s   killed by signal 5 SIGTRAP

looks like it breaks a tracker test.

20/38 tracker:fts / fts                               FAIL             0.79s   killed by signal 5 SIGTRAP

looks like it breaks a tracker test.

cc @trofi

Filed upstream report as https://gitlab.gnome.org/GNOME/tracker/-/issues/405

Thank you @trofi.


Jasminegraph crash when run the 'adgr' command

I'm experiencing an error when attempting to run the jasminegraph Docker image on a Windows WSL2 system. The command I'm using is:
docker run -v "/var/run/docker.sock:/var/run/docker.sock " -v "/root/.ssh:/home/user/.ssh"  -v "/tmp:/tmp"  -v "/var/tmp/jasminegraph-localstore:/var/tmp/jasminegraph-localstore"  -v "/var/tmp/jasminegraph-aggregate:/var/tmp/jasminegraph-aggregate"  -v "/home/ubuntu/jasminegraph/metadb:/home/ubuntu/software/jasminegraph/metadb"  -v "/home/ubuntu/jasminegraph/performancedb:/home/ubuntu/software/jasminegraph/performancedb"  -p 7776:7776 -p 7777:7777 -p 7778:7778 -p 8888:8888  jasminegraph-enhanced  --MODE 1  --MASTERIP  <IP_ADDRESS>  --WORKERS 2  --WORKERIP  <IP_ADDRESS>  --ENABLE_NMON false
the log as follow:
[1723563680686] [info] [MASTER : 7:139674464908864] Connection successful from <IP_ADDRESS>  [1723563680686] [info] [MASTER : 7:139674464908864] Frontend Listening  [1723563692157] [info] [MASTER : 7:139674481734848] Trying to connect to [0]: <IP_ADDRESS>:7780  [1723563694161] [info] [MASTER : 7:139674481734848] Trying to connect to [1]: <IP_ADDRESS>:7780  [1723563698161] [info] [MASTER : 7:139674481734848] Trying to connect to [2]: <IP_ADDRESS>:7780  [1723563702441] [info] [MASTER : 7:139674431338048] Command received: adgr  [1723563704162] [info] [MASTER : 7:139674481734848] Trying to connect to [3]: <IP_ADDRESS>:7780  [1723563712163] [info] [MASTER : 7:139674481734848] Trying to connect to [4]: <IP_ADDRESS>:7780  [1723563712163] [error] [MASTER : 7:139674481734848] Error connecting to <IP_ADDRESS>:7780  [1723563712163] [info] [MASTER : 7:139674481734848] Trying to connect to [0]: <IP_ADDRESS>:7782  [1723563714164] [info] [MASTER : 7:139674481734848] Trying to connect to [1]: <IP_ADDRESS>:7782  [1723563718165] [info] [MASTER : 7:139674481734848] Trying to connect to [2]: <IP_ADDRESS>:7782  [1723563724162] [info] [MASTER : 7:139674481734848] Trying to connect to [3]: <IP_ADDRESS>:7782  [1723563732163] [info] [MASTER : 7:139674481734848] Trying to connect to [4]: <IP_ADDRESS>:7782  [1723563732163] [error] [MASTER : 7:139674481734848] Error connecting to <IP_ADDRESS>:7782 free(): double free detected in tcache 2 /home/ubuntu/software/jasminegraph/run-docker.sh: line 94:     7 Aborted                 ./JasmineGraph $PROFILE $MODE $MASTERIP $WORKERS $WORKERIP $ENABLE_NMON
telent connection:
root@SL-L174-49DJLQ2:~# telnet localhost 7777 Trying <IP_ADDRESS>... Connected to localhost. Escape character is '^]'. adgr send powergrid|powerConnection closed by foreign host.
Environment

Operating System: Windows WSL2
Docker version: 4.29.0 (145265)

Fixed by PR 251


Update riscv dependency version

This updates riscv dependency version and resolves bare-metal conflict when building for stm32:
error: failed to select a version for `bare-metal`.
    ... required by package `stm32f4xx-hal v0.8.0`
    ... which is depended on by `gimbal-ctrl v0.1.0 (C:\Users\User\Documents\Dev\gimbal-ctrl)`
versions that meet the requirements `^0.2.5` are: 0.2.5

all possible versions conflict with previously selected packages.

  previously selected package `bare-metal v0.2.1`
    ... which is depended on by `riscv v0.5.6`
    ... which is depended on by `async-embedded v0.0.0-alpha.0 (https://github.com/rust-embedded-community/async-on-embedded?rev=5609a9d#5609a9d2)`
    ... which is depended on by `gimbal-ctrl v0.1.0 (C:\Users\User\Documents\Dev\gimbal-ctrl)`

failed to select a version for `bare-metal` which could resolve this conflict

This is a problem because cargo selects versions with all cfg(...) macros evaluated to true, so even if not building for riscv arch, it fails to select proper bare-metal version.

I've also hit another similar problem where memchr fails to build because riscv has it as a build dependency and forces std feature flag. This can be resolved with an unstable cargo feature https://github.com/rust-lang/cargo/issues/7915 which isolates regular and build dependency feature flags.


FIX: [Core-Registry-CADT] Mirrors are being launched at IP address, not referencing config.yaml values for file server URL

Core-registry-cadt is not creating proper mirrors. It should be referencing config.yaml value for file_server_url but it is not.

Check if fixed


Set the current version when marking the stack as fixed.

To support this we would just need to

get the latest version info from elastic and set it in the stack controller
Update the CheckForRegressions pipeline method to look at the events version and compare it to the stacks fixed in version.

I want a dialog to be shown that lets you pick the version the stack was fixed in. It would have the following options:

Current Version (we would get the current version and show it)
Next Release (we would put some sort of special marker on it that says the next time we detect a new version, set the fixed version on this stack to that)
Pick a version. (Maybe the fix isn't scheduled to go out yet and won't go out in the next deployment)

I'd like to add my interest to this request. It would be very convenient to not get stacks marked as Regressed when they show up in older versions.

I'm adding this to the 4.0 release. I'd like to do it even sooner as it would really help out in other areas. If your willing to take a shot at this in a pull request that would be greatly appreciated.

I very much agree with @HankDitko. It would be nice to not get stacks marked as Regressed when they show up in older versions. We have our software installed in different versions with different clients, so it would be very helpful to only get the Regression status on the exception when it makes sence. Version can be determined from the assembly version of course.

This is a great idea.

I like @ejsmith idea of also setting the version it was fixed in.  Some users are slow to upgrade and could be multiple versions behind.  Consider a bug that is present in v1 and v2.  Customer A is running old v1 and is the first to report the exception.  I mark it as fixed, and that fix will be in next release which is v3.  Customer B is running v2 and hits the same exception for the first time.  It's a newer version than the one where it was originally marked as fixed, but should not be considered regressed since it's still earlier than the version actually containing the fix.
At a minimum, don't consider it regressed if the version of the exception matches a previous exception where it was marked as fixed.  I can always mark it fixed again if reported in subsequent versions and, eventually, have all the offending versions marked as fixed.
Ideally, setting the fixed version in the beginning will save that extra work and reduce the "noise" of exceptions that do not require attention.

Also consider versions, apart from having one version. We could do a hotfix 1.2.0 -> 1.2.1 and 2.3.2 -> 2.3.3. In that case you have multiple "current" versions

I definitely want this feature as well. My only concern is how to keep it simple to mark things fixed. Don't really want to force the user to manually enter a version number. We can auto populate a list, but that list could get huge and we the version that it's fixed in might not even be released yet so you wouldn't even be able to list the correct version.

Well, we could query for all the versions and pick the latest stable one that the error occurred on and set as the one where the exception occurred in. then any future stable version (no version suffix) we reopen it).

@sander wouldn't you have different projects for multiple different versions? I'd like to keep it simple with one version but we do have our spa app and server app in the same project

This is deploying and will be incrementally worked on. We have support for specifying a fixed in version but we don't yet have a public api for listing all the unique versions. That will be coming once we refactor the stats api to support returning complex types.
@srijken right now, were only going to support one fixed in version. So you'd need to pick the highest version.


backend crash after running 12 hours

This is all of the stack traces in the buffer:
https://gist.github.com/andrewarrow/75c082801efac7ad6820a73079c3af41
when I look in
bitclout/MAINNET/backend.bitclout.aa.log/global/ERROR
or other log files I don't find the smoking gun of what caused the crash.
Is this normal? Should I just restart after crash and expect these from time to time?

ran this again with buffer screen buffer size:
fatal error: runtime: out of memory

runtime stack:
runtime.throw(0x11d902a, 0x16)
        /home/aa/go/src/runtime/panic.go:1117 +0x72
runtime.sysMap(0xc308000000, 0x40000000, 0x1f09cf0)
        /home/aa/go/src/runtime/mem_linux.go:169 +0xc6
runtime.(*mheap).sysAlloc(0x1ef0480, 0x40000000, 0x43b837, 0x1ef0488)
        /home/aa/go/src/runtime/malloc.go:729 +0x1e5
runtime.(*mheap).grow(0x1ef0480, 0x20000, 0x0)
        /home/aa/go/src/runtime/mheap.go:1346 +0x85
runtime.(*mheap).allocSpan(0x1ef0480, 0x20000, 0x1ed0100, 0x7ffd9cb01150)
        /home/aa/go/src/runtime/mheap.go:1173 +0x609
runtime.(*mheap).alloc.func1()
        /home/aa/go/src/runtime/mheap.go:910 +0x59
runtime.systemstack(0x47d9f4)
        /home/aa/go/src/runtime/asm_amd64.s:379 +0x66
runtime.mstart()
        /home/aa/go/src/runtime/proc.go:1246

I think I need a bigger boat...


🐛 Scrolling with touchpad does not work in the default file manager

branch
stable
Architecture
x86_64
Description
I can't use my touchpad to scroll in the default file manager (PCManFM). Dragging the scrollbar works fine. Using the touchpad to scroll in any other app works fine.
I don't know what logs would be relevant here, so please tell me what you need to debug this and I'll gladly update the issue.
Reproduction steps
Clean install of manjaro-sway. Open File Manager. Attempt a 2 finger scroll.

Screenshots
No response
Logs
No response

That seems to be an upstream issue in pcmanfm-gtk3: https://sourceforge.net/p/pcmanfm/bugs/1131/

Alternatively we could switch to the qt-version of pcmanfm. Sadly, the qt6 version is not yet in the repos and I wouldn't want to bake in support for qt5 anymore.

Alright, I've installed Thunar for now and it works perfectly fine.

I think now we could switch to pcmanfm-qt. Looking at the non-maintenance done at the regular pcmanfm, switching might be a good idea anyway.

Please install pcmanfm-qt after the next update. IMO it should fix the issue at hand.


Crash: SwapProviderAdapter.java line 66

I think this is caused by some build error - in the latest release, for some reason swap_providers_list.json was not found

OK.