Issue with pyenv and vim plugin: E887: Sorry, this command is disabled

When opening a file in vim, sometimes I get this error message:
Error detected while processing /Users/ianks/.yadr/vim/bundle/AutoTag/plugin/autotag.vim:

E887: Sorry, this command is disabled, the Python's site module could not be loaded.

Python is not my main language, but I have never had this issue with system Python. Any clues as to why this is happening?

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/4306995-issue-with-pyenv-and-vim-plugin-e887-sorry-this-command-is-disabled?utm_campaign=plugin&utm_content=tracker%2F282009&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F282009&utm_medium=issues&utm_source=github).

you sure installed the python?
and must both 32bit  or  64bit,
otherwise meet the error

An actual solution, for those breaking vim/macvim after "brew cleanup".
This will work if the current python is not the one your current vim/gvim/mvim is not linked to, check your vim and macvim version info (these might be separate homebrew packages), also make sure you update our brew so you'd use the latest packages:
mvim --version
vim --version

You'd know what is the linked python library:
-L/usr/local/Cellar/python/2.7.10_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config

At this point that path is expected to be valid, hence the actual issue, In this case python 2.7.10_1 Cellar's is expected, now check your latest brew python package version:
brew info python

As you already confirmed the link path is valid (e.g. ls /usr/local/Cellar/python/), above command will show which is the active one, see top of output:
https://www.python.org
/usr/local/Cellar/python/2.7.10_2 (4943 files, 77M) *
...

Make sure python symlinks are fine:
brew unlink python && brew link --force python

And finally, re-build vim or macvim:
brew uninstall macvim && brew install macvim

Rebuilding is better than brew install --force, if you have the latest package, which I think is the case as that was the reason of a homebrew clean up.
Test your vim now
mvim --version
...
Compilation: ...
-L/usr/local/Cellar/python/2.7.10_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config

Now :python print "hello" should work on your mvim. Do the same for command line vim if required.

Feel free to reopen if there are still something need to be fixed in pyenv.

It is ok after reinstalling vim.


Handle undefined API method result

Closes: https://github.com/metarhia/impress/issues/1254

Landed in https://github.com/metarhia/impress/commit/8bafe277d21e9e344dee2373bf6f1bf0765a809a


Update ncRNA workflow

Hi @bgruening, I updated/checked the RNAz parameters. But I could not figure out, what you wrote about updating the Infernal version; it seems to me this is already ok, isn't it?

I fixed infernal, yes, just added the old version as well. So we have now two version.

So if you want to can add the new infernal version to the workflow as well. Just remove the old and add the new one from the left hand side of the menu.

Thanks!


Not work on webpack 1.12.2

Webpack 1.12.2
 building for production...(node:17289) UnhandledPromiseRejectionWarning: TypeError: compilation.dependencyFactories.keys is not a function
    at Compiler.pluginCompat.tap.compilation (/home/jilen/Workspace/wx-member/client/node_modules/hard-source-webpack-plugin/lib/hard-basic-dependency-plugin.js:380:60)

Same here :raised_hand:
Webpack version: 1.12.14

I am using the latest version from npm

Hard say what is going there... more information like your webpack config would help.

I'm getting the same error, in Webpack 4, for my project: https://github.com/Venryx/js-vextensions
[hard-source:core] HardSourceWebpackPlugin is writing to a new confighash path for the first time: C:\Root\Apps\<EMAIL_ADDRESS>  0% compile(node:2264) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): TypeError: compilation.dependencyFactories.keys is not a function

Try<EMAIL_ADDRESS>and after have dropped webpack 1 support.

0.7 will be dropping webpack 2 and node 6 support.


Property 'crypto' deosn't exist.

I can neither integrate Criipto in my Expo app or run the sample project.

Hi @lilstiffy
Try v1.1.10 please, downgraded a dependency that was relying on crypto being natively enabled.


c: bind_blob, value_blob, bind_varchar, appender

Just wanted to say beforehand, DuckDB is incredible: its performance is more than satisfactory for my use case. I'm building replication algorithms and have been experimenting with DuckDB as a backend. Tweeted a tiny artificial benchmark I did here: https://twitter.com/lithdew/status/1361700795645759489
I wanted to request some additional methods/changes to the C API:

duckdb_bind_blob(duckdb_prepared_statement, idx_t, const void *, int)
Binds a blob to a column within a prepared statement. Unlike duckdb_bind_varchar, it will not validate that the value only comprises of UTF-8 bytes. The last int argument represents the length of the value const void *.
const void *duckdb_value_blob(duckdb_result *result, idx_t col, idx_t row);
Fetches a blob from a result set column.
duckdb_bind_varchar(duckdb_prepared_statement, idx_t, const char *, int)
Binds a text value to a column within a prepared statement. The last int argument represents the length of the value const char *. This is a breaking change to allow for simpler language bindings where not all strings are suffixed with a null terminator.

Apart from these changes, I also wanted to ask about there being the possibility of exposing the Appender C++ API to the C bindings. From what I skimmed online, the rationale for not exposing the Appender to other languages is because of implicit memory allocations these languages require performing to prepare data before it gets batched into DuckDB.
Though in the case of C, the Appender interface should be suitable since allocations are left up to the user.

Glad to see you are enjoying DuckDB! I think all the changes you have proposed are more than sensible. Since I was doing something on the C API anyway I implemented the changes you suggested in #1408.
Exposing the Appender from the C API is certainly possible as well. Happy to review a PR if you want to have a go at it :) Otherwise we might get to it later on.

Moved the appender part to #1409 and closing here


Replace fully qualified keys to use a : between the module and objects.

The current format for fully qualified name is module.submodule.Class.module, it would be great to change to module.submodule:Class.method
In [1]: import importlib

In [2]: from matplotlib.tri import triplot as t1
   ...: import matplotlib.tri as tri
   ...: t2 = tri.triplot
   ...: from matplotlib.tri.triplot import triplot as t3
   ...: t4 = importlib.import_module('matplotlib.tri.triplot')
   ...:
   ...:

In [3]: t1, t2, t3, t4
Out[3]:
(<function matplotlib.tri.triplot.triplot(ax, *args, **kwargs)>,
 <function matplotlib.tri.triplot.triplot(ax, *args, **kwargs)>,
 <function matplotlib.tri.triplot.triplot(ax, *args, **kwargs)>,
 <module 'matplotlib.tri.triplot' from '/Users/bussonniermatthias/miniforge3/envs/arm64/lib/python3.11/site-packages/matplotlib/tri/triplot.py'>)

As you can guess as the qualname of  triplot is matplotlib.tri.triplot.triplot, but we can't  recursievly use getattr:  matplotlib.tri.triplot would already get the function. But if we have matplotlib.tri.triplot:triplot , we can split on : , use importlib on the first part and getattr on the second.

There should be two function in papyri : obj_from_qualname, and full_qual,
One goes from object to fully-qualified name, and vice versa. Those should be updated (maybe the names should also be tweaked). And there might be other place in the code that rely on . instead of :.
Maybe also add type annotation, like there is already a FullQual = NewType("FullQual", str) type defined we might be able to use.


Blacklight slide show does not allow you to switch pictures

In ScholarSphere on QA
When I click on slide show view
And I click on a picture
Then I see arrows to either side which I would think would advance the picture
Instead I just have to watch the show
The scroll bar is also not helpful

We should disable the slideshow for ScholarSphere.  I believe that is a configuration in CatalogController.


Add npm cache expiry

Use ttl based on npm response headers

Could be useful to use this: http://github.com/lukechilds/keyv


Issue connecting QListWidget.indexes_moved signal to slot

I have a QListWidget that I am looking to connect a signal from (the signal appears in the docs as coming from QListView via Deref). I implement a SlotOfQListOfQModelIndex  and attempt to connect them like so:
withpackage_ptr
                .indexes_moved()
                .connect(&form.withpackage_moved);

This compiles fine, but when launching the application, I get this error:
QObject::connect: No such signal QListWidget::indexesMoved(const QList< QModelIndex >&)
QObject::connect:  (sender name:   'WithsListWidget')

That definitely looks like the right C++ signature to me....
Update
I tried implementing this using the qlistview and the QStandardItemModel. I ran into the same issue.
My slot is defined like so:
SlotOfQListOfQModelIndex::new(
                    move |indexlist: Ref<QListOfQModelIndex>| {
                        println!("ohboy");
                    },

is it an issue with my slot?  I suspect there is a signature mismatch between the signal which is a const pointer and the slot, which is a const reference...
NB I also tried this with a RawSlotOfQListOFQModelIndex ....
Or...
The signal is not defined correctly in the library.
in QT, the signature of the method is :
void QListView::indexesMoved(const QModelIndexList &indexes)

but in rust-qt it is:
pub fn indexes_moved(&self) -> Signal<(*const QListOfQModelIndex,)>

shouldnt that be
pub fn indexes_moved(&self) -> Signal<(const QListOfQModelIndex&,)>

The issue is caused by the fact that these slots are declared using QModelIndexList which is a typedef for QList<QModelIndex>. ritual resolves and discards all typedefs, so it doesn't have information about QModelIndexList, but Qt for some reason doesn't want to recognize QList<QModelIndex> as a valid alias for QModelIndexList (although it's able to recognize some other type alises).
I've made a hacky fix of this issue (it simply replaces QList<QModelIndex> with QModelIndexList in all receiver IDs). I'll also need to create a way to test for successful connection so I can at least write a test for this hack. I hope there are no slots that use QList<QModelIndex> as their argument because that would make the issue much harder to fix.
I'll post here once the fix is published.

Thanks a bunch. This will make it possible to recognize drag and drop reordering.

Fixed in qt_widgets 0.5.0-alpha.1.


Video Optimizer discoverd 1 non-HTTPS connections.

Description
Video Optimizer discoverd 1 non-HTTPS connections.
<IP_ADDRESS> gstatic.com
Reproducing the issue
No response
Firebase SDK Version
10.13.0
Xcode Version
14.2
Installation Method
CocoaPods
Firebase Product(s)
Analytics, Crashlytics
Targeted Platforms
iOS
Relevant Log Output
No response
If using Swift Package Manager, the project's Package.resolved

Expand Package.resolved snippet

Replace this line with the contents of your Package.resolved.

If using CocoaPods, the project's Podfile.lock

Expand Podfile.lock snippet

Replace this line with the contents of your Podfile.lock!

Hi @wangsq157, based on the info you shared, the issue seems not related to Firebase. To have a better understanding, could you share the detailed steps to reproduce the issue as well as the error you encountered?

Hi @wangsq157, based on the info you shared, the issue doesn't seem related to Firebase. To have a better understanding, could you share the detailed steps to reproduce the issue as well as the error you encountered?

Thanks for your comments,  my app used Firebase， please onfirm that the gstatic.com has any non-HTTPS connections.

Where is the reference to gstatic.com?


feat: added the ability to dynamically fetch the Lacework account name

Summary
This PR adds the ability for the module to dynamically fetch the Lacework account name, or have it be manually assigned.  This PR is dependent on the release of the Terraform Provider that includes this change
How did you test this change?
Built the new provider locally on my machine and tested, but probably needs a few more 👀 on it.  (Validate it works with fra.lacework.net etc.)
Issue
N/A

@alannix-lw, @dmurray-lacework, while the TF might be correct, the test-compatibility pipeline fails due to now having an API token for the lacework_current_user. Is that fixable?

@alannix-lw, @dmurray-lacework, while the TF might be correct, the test-compatibility pipeline fails due to now having an API token for the lacework_current_user. Is that fixable?

This should be fixed and passing now. I had to set credentials as env vars on the codefresh pipeline.


Allow PHP 8

Q
A

Bug fix?
no

New feature?
yes

BC breaks?
no

Deprecations?
no

Related tickets

Documentation

License
MIT

What's in this PR?
Support PHP 8.0.

tagged a release https://github.com/php-http/stopwatch-plugin/releases/tag/1.4.0


Sometime getting unmodified buffer error

Describe the bug
Occasionally I am getting following error when I create Angular library or generate component
To Reproduce
Steps to reproduce the behavior:

Go to ':Telescope nx generators'
Search for Angular Component
Provide all the required field
Click Submit
Get following error (as shown in screenshot)

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots

Desktop (please complete the following information):

OS: Mac
Nvim: 0.9.0

Hi, I am a bit unsure how to replicate this. Could you link me your config?

Ive added a lot of logging to the plugin now, could you navigate to .local/share/nvim and delete the file called nx.log, then re open nvim, call Telescope nx generators, then upload the nx.log file here


Fb 2023.07.25

Re: the was/were changes, I believe both where referring to hypotheticals, in which case were (subjunctive) is correct


Pasta background Closes #14

Adds a pasta background, as proposed by issue #14

There are now merge conflicts. Could you update with the latest version from upstream?

@stevenaeola The fork has been updated from upstream, and the PR now shows no merge

A background pull request has already been accepted.


Handle top level exceptions

Related issue #116
This PR addressed the following issues:

Making sure that bubbled up exceptions are being handled properly in non-verbose modes:

Don't log the stack trace.
For OctoshiftCliException, log the exception message since it is a known exception and should already have a user friendly error message.
For other (unexpected) errors, mask the actual error message and show a generic one to the user and point them to the log files.

Returning 1 instead of 0 in case of an error.
Writing errors to std error instead of std out.
Add LogError(Exception ex) overloaded method to OctoLogger.
Add the new OctoshifeCliException to be thrown for all known/handled exceptions.

[x] Did you write/update appropriate tests
[x] Release notes updated (if appropriate)
[x] Appropriate logging output
[x] Issue linked

can you confirm that if you call the CLI and don't provide a required arg, that we still get the system.commandline generated error message a bout a missing arg. Just want to make sure that isn't replaced with "unexpected error see logs"

can you confirm that if you call the CLI and don't provide a required arg, that we still get the system.commandline generated error message a bout a missing arg. Just want to make sure that isn't replaced with "unexpected error see logs"

./ado2gh generate-script                                                                   ✔  6.0.101 
Option '--github-org' is required.

generate-script
  Generates a migration script. This provides you the ability to review the steps that this tool will take, and optionally modify the script if desired before running it.
  Note: Expects ADO_PAT env variable to be set.

Usage:
  ado2gh [options] generate-script

Options:
  --github-org <github-org> (REQUIRED)
  --ado-org <ado-org>
  --output <output>                     [default: ./migrate.ps1]
  --repos-only
  --skip-idp
  --ssh
  --verbose
  -?, -h, --help                        Show help and usage information


Plugin fails to compile

I added a blank C++ class to my project with the wizard in the Editor. My new blank class compiled opened in Visual Studio normally, I saved it and closed everything. Then I extracted UE4Cardboard to a new Plugins folder as described in the Readme. When I launch my project it asks to compile the dll, press yes and it ultimately fails. I found the error log (below). We are also discussing the issue in this forum thread.
My project name is Warehouse2:
Log file open, 02/18/16 22:36:43
LogInit:Display: Running engine for game: Warehouse2
LogInit:Warning: Incompatible or missing module: UE4Editor-UE4Cardboard.dll
Running D:/Program Files/Epic Games/4.7/Engine/Binaries/DotNET/UnrealBuildTool.exe Warehouse2 Development Win64 -project="D:/projects/unreal/Warehouse2/Warehouse2.uproject" -rocket -editorrecompile -progress
Performing 2 actions (4 in parallel)
SimpleHMD.cpp
d:\projects\unreal\warehouse2\plugins\ue4cardboard\source\simplehmd\private\SimpleHMD.h(27) : error C3668: 'FSimpleHMD::HasValidTrackingPosition' : method with override specifier 'override' did not override any base class methods
d:\projects\unreal\warehouse2\plugins\ue4cardboard\source\simplehmd\private\SimpleHMD.h(27) : warning C4263: 'bool FSimpleHMD::HasValidTrackingPosition(void)' : member function does not override any base class virtual member function
d:\projects\unreal\warehouse2\plugins\ue4cardboard\source\simplehmd\private\SimpleHMD.h(123) : warning C4264: 'bool IHeadMountedDisplay::HasValidTrackingPosition(void) const' : no override available for virtual member function from base 'IHeadMountedDisplay'; function is hidden
        D:\Program Files\Epic Games\4.7\Engine\Source\Runtime\HeadMountedDisplay\Public\IHeadMountedDisplay.h(93) : see declaration of 'IHeadMountedDisplay::HasValidTrackingPosition'
        D:\Program Files\Epic Games\4.7\Engine\Source\Runtime\HeadMountedDisplay\Public\IHeadMountedDisplay.h(29) : see declaration of 'IHeadMountedDisplay'
d:\projects\unreal\warehouse2\plugins\ue4cardboard\source\simplehmd\private\SimpleHMD.h(28) : error C3668: 'FSimpleHMD::GetPositionalTrackingCameraProperties' : method with override specifier 'override' did not override any base class methods
d:\projects\unreal\warehouse2\plugins\ue4cardboard\source\simplehmd\private\SimpleHMD.h(28) : warning C4263: 'void FSimpleHMD::GetPositionalTrackingCameraProperties(FVector &,FQuat &,float &,float &,float &,float &,float &) const' : member function does not override any base class virtual member function
d:\projects\unreal\warehouse2\plugins\ue4cardboard\source\simplehmd\private\SimpleHMD.h(123) : warning C4264: 'void IHeadMountedDisplay::GetPositionalTrackingCameraProperties(FVector &,FRotator &,float &,float &,float &,float &,float &) const' : no override available for virtual member function from base 'IHeadMountedDisplay'; function is hidden
        D:\Program Files\Epic Games\4.7\Engine\Source\Runtime\HeadMountedDisplay\Public\IHeadMountedDisplay.h(98) : see declaration of 'IHeadMountedDisplay::GetPositionalTrackingCameraProperties'
        D:\Program Files\Epic Games\4.7\Engine\Source\Runtime\HeadMountedDisplay\Public\IHeadMountedDisplay.h(29) : see declaration of 'IHeadMountedDisplay'
d:\projects\unreal\warehouse2\plugins\ue4cardboard\source\simplehmd\private\SimpleHMD.h(29) : error C3668: 'FSimpleHMD::RebaseObjectOrientationAndPosition' : method with override specifier 'override' did not override any base class methods
d:\projects\unreal\warehouse2\plugins\ue4cardboard\source\simplehmd\private\SimpleHMD.h(123) : error C2555: 'FSimpleHMD::GetViewExtension': overriding virtual function return type differs and is not covariant from 'IHeadMountedDisplay::GetViewExtension'
        D:\Program Files\Epic Games\4.7\Engine\Source\Runtime\HeadMountedDisplay\Public\IHeadMountedDisplay.h(114) : see declaration of 'IHeadMountedDisplay::GetViewExtension'
d:\projects\unreal\warehouse2\plugins\ue4cardboard\source\simplehmd\private\SimpleHMD.h(64) : error C3668: 'FSimpleHMD::DrawDistortionMesh_RenderThread' : method with override specifier 'override' did not override any base class methods
d:\projects\unreal\warehouse2\plugins\ue4cardboard\source\simplehmd\private\SimpleHMD.h(64) : warning C4263: 'void FSimpleHMD::DrawDistortionMesh_RenderThread(FRenderingCompositePassContext &,const FIntPoint &)' : member function does not override any base class virtual member function
d:\projects\unreal\warehouse2\plugins\ue4cardboard\source\simplehmd\private\SimpleHMD.h(123) : warning C4264: 'void IHeadMountedDisplay::DrawDistortionMesh_RenderThread(FRenderingCompositePassContext &,const FSceneView &,const FIntPoint &)' : no override available for virtual member function from base 'IHeadMountedDisplay'; function is hidden
        D:\Program Files\Epic Games\4.7\Engine\Source\Runtime\HeadMountedDisplay\Public\IHeadMountedDisplay.h(274) : see declaration of 'IHeadMountedDisplay::DrawDistortionMesh_RenderThread'
        D:\Program Files\Epic Games\4.7\Engine\Source\Runtime\HeadMountedDisplay\Public\IHeadMountedDisplay.h(29) : see declaration of 'IHeadMountedDisplay'
d:\projects\unreal\warehouse2\plugins\ue4cardboard\source\simplehmd\private\SimpleHMD.h(74) : error C3668: 'FSimpleHMD::GetEyeRenderParams_RenderThread' : method with override specifier 'override' did not override any base class methods
d:\projects\unreal\warehouse2\plugins\ue4cardboard\source\simplehmd\private\SimpleHMD.h(74) : warning C4263: 'void FSimpleHMD::GetEyeRenderParams_RenderThread(const FRenderingCompositePassContext &,FVector2D &,FVector2D &) const' : member function does not override any base class virtual member function
d:\projects\unreal\warehouse2\plugins\ue4cardboard\source\simplehmd\private\SimpleHMD.h(123) : warning C4264: 'void IStereoRendering::GetEyeRenderParams_RenderThread(EStereoscopicPass,FVector2D &,FVector2D &) const' : no override available for virtual member function from base 'IStereoRendering'; function is hidden
        D:\Program Files\Epic Games\4.7\Engine\Source\Runtime\Engine\Public\StereoRendering.h(58) : see declaration of 'IStereoRendering::GetEyeRenderParams_RenderThread'
        D:\Program Files\Epic Games\4.7\Engine\Source\Runtime\Engine\Public\StereoRendering.h(10) : see declaration of 'IStereoRendering'
d:\projects\unreal\warehouse2\plugins\ue4cardboard\source\simplehmd\private\SimpleHMD.h(77) : error C3668: 'FSimpleHMD::SetupViewFamily' : method with override specifier 'override' did not override any base class methods
d:\projects\unreal\warehouse2\plugins\ue4cardboard\source\simplehmd\private\SimpleHMD.h(80) : error C3668: 'FSimpleHMD::PreRenderView_RenderThread' : method with override specifier 'override' did not override any base class methods
d:\projects\unreal\warehouse2\plugins\ue4cardboard\source\simplehmd\private\SimpleHMD.h(80) : warning C4263: 'void FSimpleHMD::PreRenderView_RenderThread(FRHICommandListImmediate &,FSceneView &)' : member function does not override any base class virtual member function
d:\projects\unreal\warehouse2\plugins\ue4cardboard\source\simplehmd\private\SimpleHMD.h(123) : warning C4264: 'void ISceneViewExtension::PreRenderView_RenderThread(FSceneView &)' : no override available for virtual member function from base 'ISceneViewExtension'; function is hidden
        D:\Program Files\Epic Games\4.7\Engine\Source\Runtime\Engine\Public\SceneViewExtension.h(30) : see declaration of 'ISceneViewExtension::PreRenderView_RenderThread'
        D:\Program Files\Epic Games\4.7\Engine\Source\Runtime\Engine\Public\SceneViewExtension.h(10) : see declaration of 'ISceneViewExtension'
d:\projects\unreal\warehouse2\plugins\ue4cardboard\source\simplehmd\private\SimpleHMD.h(81) : error C3668: 'FSimpleHMD::PreRenderViewFamily_RenderThread' : method with override specifier 'override' did not override any base class methods
d:\projects\unreal\warehouse2\plugins\ue4cardboard\source\simplehmd\private\SimpleHMD.h(81) : warning C4263: 'void FSimpleHMD::PreRenderViewFamily_RenderThread(FRHICommandListImmediate &,FSceneViewFamily &)' : member function does not override any base class virtual member function
d:\projects\unreal\warehouse2\plugins\ue4cardboard\source\simplehmd\private\SimpleHMD.h(123) : warning C4264: 'void ISceneViewExtension::PreRenderViewFamily_RenderThread(FSceneViewFamily &)' : no override available for virtual member function from base 'ISceneViewExtension'; function is hidden
        D:\Program Files\Epic Games\4.7\Engine\Source\Runtime\Engine\Public\SceneViewExtension.h(25) : see declaration of 'ISceneViewExtension::PreRenderViewFamily_RenderThread'
        D:\Program Files\Epic Games\4.7\Engine\Source\Runtime\Engine\Public\SceneViewExtension.h(10) : see declaration of 'ISceneViewExtension'
D:\projects\unreal\Warehouse2\Plugins\UE4Cardboard\Source\SimpleHMD\Private\SimpleHMD.cpp(26) : error C2555: 'FSimpleHMDPlugin::CreateHeadMountedDisplay': overriding virtual function return type differs and is not covariant from 'IHeadMountedDisplayModule::CreateHeadMountedDisplay'
        D:\Program Files\Epic Games\4.7\Engine\Source\Runtime\HeadMountedDisplay\Public\IHeadMountedDisplayModule.h(65) : see declaration of 'IHeadMountedDisplayModule::CreateHeadMountedDisplay'
D:\projects\unreal\Warehouse2\Plugins\UE4Cardboard\Source\SimpleHMD\Private\SimpleHMD.cpp(32) : error C2259: 'FSimpleHMD' : cannot instantiate abstract class
        due to following members:
        'bool IHeadMountedDisplay::HasValidTrackingPosition(void) const' : is abstract
        D:\Program Files\Epic Games\4.7\Engine\Source\Runtime\HeadMountedDisplay\Public\IHeadMountedDisplay.h(93) : see declaration of 'IHeadMountedDisplay::HasValidTrackingPosition'
        'void IHeadMountedDisplay::GetPositionalTrackingCameraProperties(FVector &,FRotator &,float &,float &,float &,float &,float &) const' : is abstract
        D:\Program Files\Epic Games\4.7\Engine\Source\Runtime\HeadMountedDisplay\Public\IHeadMountedDisplay.h(98) : see declaration of 'IHeadMountedDisplay::GetPositionalTrackingCameraProperties'
        'void IHeadMountedDisplay::UpdateScreenSettings(const FViewport *)' : is abstract
        D:\Program Files\Epic Games\4.7\Engine\Source\Runtime\HeadMountedDisplay\Public\IHeadMountedDisplay.h(280) : see declaration of 'IHeadMountedDisplay::UpdateScreenSettings'
        'void IStereoRendering::PushViewportCanvas(EStereoscopicPass,FCanvas *,UCanvas *,FViewport *) const' : is abstract
        D:\Program Files\Epic Games\4.7\Engine\Source\Runtime\Engine\Public\StereoRendering.h(47) : see declaration of 'IStereoRendering::PushViewportCanvas'
        'void IStereoRendering::PushViewCanvas(EStereoscopicPass,FCanvas *,UCanvas *,FSceneView *) const' : is abstract
        D:\Program Files\Epic Games\4.7\Engine\Source\Runtime\Engine\Public\StereoRendering.h(53) : see declaration of 'IStereoRendering::PushViewCanvas'
        'void ISceneViewExtension::ModifyShowFlags(FEngineShowFlags &)' : is abstract
        D:\Program Files\Epic Games\4.7\Engine\Source\Runtime\Engine\Public\SceneViewExtension.h(15) : see declaration of 'ISceneViewExtension::ModifyShowFlags'
        'void ISceneViewExtension::PreRenderViewFamily_RenderThread(FSceneViewFamily &)' : is abstract
        D:\Program Files\Epic Games\4.7\Engine\Source\Runtime\Engine\Public\SceneViewExtension.h(25) : see declaration of 'ISceneViewExtension::PreRenderViewFamily_RenderThread'
        'void ISceneViewExtension::PreRenderView_RenderThread(FSceneView &)' : is abstract
        D:\Program Files\Epic Games\4.7\Engine\Source\Runtime\Engine\Public\SceneViewExtension.h(30) : see declaration of 'ISceneViewExtension::PreRenderView_RenderThread'
-------- End Detailed Actions Stats -----------------------------------------------------------
ERROR: UBT ERROR: Failed to produce item: D:\projects\unreal\Warehouse2\Plugins\UE4Cardboard\Binaries\Win64\UE4Editor-UE4Cardboard.dll
Cumulative action seconds (8 processors): 0.00 building projects, 4.05 compiling, 0.00 creating app bundles, 0.00 generating debug info, 0.00 linking, 0.00 other
UBT execution time: 5.99 seconds
LogExit: Preparing to exit.
 We'll try to find this out!

Hi IntegersOfK,
seems like you are using an outdated UE4 version (4.7 as seen from the log). We did not test the plugin on this particular version (4.10.x only) but by the looks of it it's not even supported on 4.7. Can you try a more recent version or is there a reason you stick with 4.7 ?

I updated to UE4 version 4.1, re-installed Visual Studio 2015 and sure enough it works when I launch my project on my Nexus 6P. Embarrassingly, I now notice the extended classes in my error log above were only introduced in this version of the engine and this is an obvious troubleshooting step I should have taken. Nevertheless, thank you for helping me solve this problem; I'm excited about VR and am now empowered to dive right in.


Judge, lest not ye be judged...

start your own hate free distro with @micahflee
https://micahflee.com/
https://web.archive.org/web/20230222112654/https://discourse.nixos.org/t/where-can-i-find-the-context-when-a-user-is-banned/25674

Judge, lest not ye be judged

yeah, i appreciate all kinds of feedback, and i would block people only for actual spam or abuse, similar to gab.com

start your own hate free distro

what? "hate free" is not my style. and nixos linux is good enough, so no reason to reinvent that wheel


Create a Parsec Rust Client

Repository name will be parsec-client-rust. The Rust client will provide different abstraction layers as modules, the lowest one simply exposing methods for all the operations in the interface with all the parameters.
A large part of the Rust client could be taken from the current test client.

If this client is to be used in the future as the base for the test client, it's important that the Rust client exposes all "intermediary" levels of access.
E.g. I believe the core/minimal client functionality would be at operation-level, allowing a user to send an operation by providing all parameters. However, for test we'd need to potentially send malformed requests, or just random bytes, to the socket. This shouldn't be something exposed by any client library inteded for users, though.

The repo has been created at this address: https://github.com/parallaxsecond/parsec-client-rust

Closing this as all issues pertaining to the client are in the repo mentioned by @hug-dev above.


App specific listeners for swoole events

[x] I was not able to find an open or closed issue matching what I'm seeing.
[x] This is not a question. (Questions should be asked on chat (Signup here) or our forums.)

Use swoole tick timer on the worker process to be able to use it as the event loop for guzzle.
PS: By default guzzle uses PHP shutdown handler but this does not work in a swoole environment. To be able to use async Guzzle callbacks within an swoole worker you have to run the task queue of Guzzle manually. This can simply be done using the SwooleServer::tick function of the worker process.
Code to reproduce the issue
// This does not work as "SwooleServer::on()" supports only one listener
// and there is already a listener in SwooleRequestHandlerRunner
$masterServer = $container->get(SwooleHttpServer::class);
$masterServer->on('workerstart', function (SwooleHttpServer $workerServer) {
    $queue = \GuzzleHttp\Promise\queue();
    $workerServer->tick(100, function () use ($queue) {
        $queue->run();
    });
});

// I had to extend SwooleRequestHandlerRunner
// and copy-past SwooleRequestHandlerRunnerFactory
// to use an own event manager to add application specific listeners to these events
$em = $container->get(EventManagerInterface::class);
$em->attach(WorkerStartEvent::class, function (WorkerStartEvent $event) {
    $queue = \GuzzleHttp\Promise\queue();
    $workerServer = $event->getServer();
    $workerServer->tick(1000, function () use ($queue) {
        $queue->run();
    });
});

Expected results
There should already be a way in zend-expressive-swoole to add application specific listeners to such events
Actual results
It's not possible without extending SwooleRequestHandlerRunner and copy-pasting SwooleRequestHandlerRunnerFactory.

This repository has been closed and moved to mezzio/mezzio-swoole; a new issue has been opened at https://github.com/mezzio/mezzio-swoole/issues/1.


Rename VSTeam to e.g. ADOPS?

"VSTeam" is IMHO not a good name anymore, now that everything has been renamed away from that brand.
Does it make sense to rename the project to something like "ADOPS" and all cmdlets to Get-ADO* / Set-ADO* etc. ?

I see you use "AzD" as short for Azure DevOps. Is this the official term? "VSTS" was so catchy :D

There is no official abbreviation. ADO already means something else in our industry. I have considered renaming the module but I don't think I will try and align with the product anymore. Have to think of a cool name not associated with the product name. I hesitate because renaming also means losing the download stats.


Update Flyway from v9 to v10

NOREF
Description

This Slack discussion from @StevenWadeOddball brought up that our flyway version is a bit out of date, and that newer versions of Postgres aren't supported on our current version (and we just upgraded from v14 to v16 of postgres in https://github.com/CMSgov/mint-app/pull/1200)
This PR just accomplishes 2 things:

Updates the few locations in the codebase where we define the version of Flyway to use
Based on some warnings that were showing up locally post-upgrade and based on the Flyway v9 to v10 migration guide, I updated the FLYWAY_LOCATIONS env var to point to a non-default location. This doesn't really accomplish much other than align with Flyway's expectations on not using a default location for the SQL that Flyway runs (as they claim it could be deprecated in a future release)
Replaces the flyway-action in our CI/CD pipeline by just running the Flyway docker container directly. This is because the action itself is now deprecated, and this is the recommended (per that link) way to run Flyway in GitHub Actions, now!

How to test this change

Run scripts/dev up, and ensure that the application spins up as expected, and the logs from the db-migrate container all look good!

TODO

[ ] Validate that the CI checks still work as expected

PR Author Checklist

[x] I have provided a detailed description of the changes in this PR.
[x] I have provided clear instructions on how to test the changes in this PR.
[x] I have updated tests or written new tests as appropriate in this PR.
[x] Updated the Postman Collection if necessary.

PR Reviewer Guidelines

It's best to pull the branch locally and test it, rather than just looking at the code online!
When approving a PR, provide a reason why you're approving it

e.g. "Approving because I tested it locally and all functionality works as expected"
e.g. "Approving because the change is simple and matches the Figma design"

Don't be afraid to leave comments or ask questions, especially if you don't understand why something was done! (This is often a great time to suggest code comments or documentation updates)
Check that all code is adequately covered by tests - if it isn't feel free to suggest the addition of tests.

Thanks @ClayBenson94 , I validated these changes locally and they work as expected. Are there any other changes that need to happen for changing the deployed versions?

@StevenWadeOddball Shouldn't! Changing the Dockerfile's FROM statement is all that's needed -- that will update the version of flyway that's built and pushed to AWS ECR. If we had to define any other env vars, we would need to update the ECS task, but since they're all hard-coded and baked into the Dockerfile's ENV statements, we're good! (famous last words...)

🚀🚀🚀🚀🚀


Upgrade go version to 1.20

Description
For #1243
To upgrade go version to 1.20.
Issue reference
Please reference the issue this PR will close: #1243
Checklist
Please make sure you've completed the relevant tasks for this PR, out of the following list:

[x] Code compiles correctly
[x] Created/updated tests
[x] Extended the documentation

@letmerecall can you run go mod tidy and fix the dependencies in CLI?

@mukundansundar  make modtidy does nothing. It looks like the dependencies are alright. However, looking into the workflow logs, it seems that the job is picking up GOVER: 1.2 and we might have to add patch version as well.

@mukundansundar  There's no apparent error in the logs of Build linux_amd64 binaries job but the runner received a shutdown signal. Should we try to re-run it?

@letmerecall The linting step is failing in workflow. You should be able to run locally make lint with current lint version( version: v1.49.0) and go version(1.20.1) and check failures.

@letmerecall The linting step is failing in workflow. You should be able to run locally make lint with current lint version( version: v1.49.0) and go version(1.20.1) and check failures.

It's strange that I'm not able to run make lint locally with current lint version( version: v1.49.0). The command consumes a ton of resources before exiting with this message:
golangci-lint run --timeout=20m
WARN [runner] The linter 'deadcode' is deprecated (since v1.49.0) due to: The owner seems to have abandoned the linter.  Replaced by unused.
WARN [runner] The linter 'ifshort' is deprecated (since v1.48.0) due to: The repository of the linter has been deprecated by the owner.
WARN [runner] The linter 'structcheck' is deprecated (since v1.49.0) due to: The owner seems to have abandoned the linter.  Replaced by unused.
WARN [runner] The linter 'varcheck' is deprecated (since v1.49.0) due to: The owner seems to have abandoned the linter.  Replaced by unused.
make: *** [lint] Killed: 9

It's strange that I'm not able to run make lint locally with current lint version( version: v1.49.0). The command consumes a ton of resources before exiting with this message:

We might need to upgrade golanglint to v1.51.0.  Related to this  -
https://github.com/golangci/golangci-lint/pull/3414
https://github.com/golangci/golangci-lint/commits/v1.51.0
FYI @mukundansundar

It's strange that I'm not able to run make lint locally with current lint version( version: v1.49.0). The command consumes a ton of resources before exiting with this message:

We might need to upgrade golanglint to v1.51.0.  Related to this  -
https://github.com/golangci/golangci-lint/pull/3414
https://github.com/golangci/golangci-lint/commits/v1.51.0
FYI @mukundansundar

Will create a PR to upgrade linter version.

It's strange that I'm not able to run make lint locally with current lint version( version: v1.49.0). The command consumes a ton of resources before exiting with this message:

We might need to upgrade golanglint to v1.51.0.  Related to this  -
golangci/golangci-lint#3414
https://github.com/golangci/golangci-lint/commits/v1.51.0
FYI @mukundansundar

Will create a PR to upgrade linter version.

will merge #1253 and then update this PR again.

@letmerecall can you please fix the conflicts

@letmerecall Please checkout the code first and then run go setup action

@letmerecall Please checkout the code first and then run go setup action since the change uses go.mod for version value

Oops, sorry.
I wonder if we have to clear the workflow cache as well? Last time setup-go@v3 action picked go version 1.2 instead of 1.20.1

@letmerecall Please checkout the code first and then run go setup action since the change uses go.mod for version value

Oops, sorry.
I wonder if we have to clear the workflow cache as well? Last time setup-go@v3 action picked go version 1.2 instead of 1.20

@letmerecall I will take a look at this tomorrow morning and will work on fixing and merging this PR.

@letmerecall Please checkout the code first and then run go setup action since the change uses go.mod for version value

Oops, sorry.
I wonder if we have to clear the workflow cache as well? Last time setup-go@v3 action picked go version 1.2 instead of 1.20

@letmerecall I will take a look at this tomorrow morning and will work on fixing and merging this PR.

@mukundansundar Cool! my last commit might fix the paths for 'go.mod'. Feel free to revert it if not.


CIP-1694 | SPO pre-defined voting options

Addition of language that allows for SPOs to delegate to pre-defined voting options. PR created by Adam Rusch and Johnny Kelly. Idea for achieving SPO pre-defined voting options came from Martin Lang of ATADA Stake Pool at the September 23, 2024 Ledger Working Group meeting.

Here is the ticket on the Ledger side that goes into some reasons and outlines more specifics of this change: https://github.com/IntersectMBO/cardano-ledger/issues/4645
Cross referencing it for anyone interested in following progress on implementation of this feature.

I second that PR by saying, 'That's about time!' 😅🥰👍

hello!
Thanks for the pull request @adamrusch and team, I am a fan of this.
Changing active CIPs once marked as active has proven to cause compatibly issues.
Tooling claiming to be CIP-1694 compliant will no longer be.
May I suggest that we change this to be instead its own proposal (I know it will be brief) but I feel this will make tracking compatibility much easier.

@Ryun1 I'd like to argue against your suggestion. Technically CIP-1694 is not yet fully active. It will only be active after the bootstrap phase is over with Chang+1 HF, which is exactly when the full CIP-1694 goes into affect. This feature that is being described in the PR is something that is currently being implemented for the Chang+1 HF in Ledger.
So, if we do this change in a separate CIP, technically then ledger will not be CIP-1694 compatible :wink:
We also discussed this on a call and @disassembler and @kevinhammond also made the same suggestion: just amend the existing CIP-1694.

I see that a separate CIP is not necessary, but I want to guard against inconsistencies with this change to CIP 1694.
Are you sure that the suggested changes cover all things that should change?
For example, is line 722 still correctly formulated?

Are you sure that the suggested changes cover all things that should change?
For example, is line 722 still correctly formulated?

This is something Insuggested in this comment:
https://github.com/cardano-foundation/CIPs/pull/916#discussion_r1774244552

Thank you, @Hornan7 :)
And for completeness, do you think we should add some line from this issue for context somewhere in the CIP?

And for completeness, do you think we should add some line from this issue for context somewhere in the CIP?

I think Johnny Kelly and Adam Rusch did a great job with this PR. It summarizes the changes to the ledger well in the CIP-1694, though I believe the part mentioned above could be slightly modified. 😇

@lehins
My main motivation for wanting this in its own proposal is for communication reasons
It is a lot simpler to communicate "heads up new Ledger CIP-????" rather than CIP-1694 is changing again
Having this change in its own proposal, gives the authors a chance to fully describe the motivation and rationale for this making communicating easier
Furthermore much tooling has considered itself CIP1694 compliant, having tested across different networks with and without bootstrapping
Changing CIP1694 will now mean these tools are not compliant, and it is a challenge to reach out to all these tools to let them know
Anyway, seems like the sentiment is against me on this one 😆
If this is to stay as a change to CIP1694, I must request a few changes

Please update the ChangeLog section
Please add the rationale for this change to the Rationale section

Capturing the motivation for this change I feel is really important
Currently the change is proposed but there is no description on WHY this is changing, and what problem this solves

cc @adamrusch

While I appreciate your perspective on the benefits of creating a separate CIP, I believe it is crucial to maintain and update CIP-1694 instead. This document serves as the official key reference for how Cardano's governance features operate at the protocol level and is integral to our governance framework.
CIP-1694 is referenced multiple times in the Interim Constitution:

Appendix 1 - Cardano Guardrails Introduction: This section states that implementing on-chain governance requires establishing guardrails based on CIP-1694 to ensure the Cardano Blockchain operates securely and sustainably.

Guardrail 2.5 - Governance Parameters: This section emphasizes that the goals of managing governance parameters include ensuring governance stability and maintaining a representative form of governance as outlined in CIP-1694.

Guardrail Script 9: CIP-1694 is cited multiple times within this section, reinforcing its role as a foundational document for governance practices during the Interim Period.

Given that CIP-1694 is already established as the main reference point in the Interim Constitution, creating a new CIP for these changes would imply significant modifications to the Constitution itself to incorporate this new reference. This could lead to confusion and misalignment within our governance framework.
As Alexei mentioned, since we are still in the bootstrap phase, which is why I also believe we should prioritize updates to CIP-1694 to ensure it accurately reflects our governance processes. 😃👍

I'm sorry for not contributing much so far beyond agreeing with the points everyone is making on both sides.  I can see how a trail of distinct CIPs documenting any changes to the baseline would be important as @Ryun1 is saying.  I also can see why it's necessary at this point to confine the sum of this behaviour to CIP-1694 alone, as a special case beyond this generally desirable process, because of CIP-1694's uniquely defined & comprehensive role.
I think what @Ryun1 offers in https://github.com/cardano-foundation/CIPs/pull/916#issuecomment-2395065281 would be an excellent compromise — to rationalise and record this update within CIP-1694 itself — and to follow this precedent for any similar updates until some evolutionary change might break that uniquely intimate relationship between CIP-1694 and the overall Governance process.

@adamrusch - consensus at CIP meeting today is that we only await https://github.com/cardano-foundation/CIPs/pull/916#issuecomment-2395307005 before double-checking & then hitting the merge button for this.

I believe it would be sufficient to add this pull request as an additional link in the "discussion" section of the header which can be accomplished via a separate housekeeping PR.


[Gally]: master <- dev

Automatically created by Git-Ally

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Increase memory request and limit for cluster-autoscaler addon

Contributes #210
Investigating CI failures on #225 I had a look at the test cluster, and the cluster-autoscaler pod was repeatedly restarting due to OOM errors.
The particular test failure was that the test workload pods wouldn't start in validateClusterAutoscaler (if the cluster-autoscaler pod was OOM then it would not be able to trigger scale-up).

CI is failing due to insufficient spot capacity on p2.xlarge

Launching a new EC2 instance. Status Reason: Could not launch Spot Instances. InsufficientInstanceCapacity - There is no Spot capacity available that matches your request. Launching EC2 instance failed.

This should succeed on a rerun when capacity is back, but another failure case for #210

Added p2.xlarge to  example gpu_node_group at 5dca2e2260f402ba189a61a7331d9994d8016277 to give more diversity to the ASG when testing an example GPU workload. This should give less chance of CI failing due to no spot availability

:+1: Change looks good, let's hope for some :green_circle: tests! :crossed_fingers:

We have 🟢  tests 🎉


HADOOP-16768: DO NOT MERGE Test x86 and arm fail tests

NOTICE
Please create an issue in ASF JIRA before opening a pull request,
and you need to set the title of the pull request which starts with
the corresponding JIRA issue number. (e.g. HADOOP-XXXXX. Fix a typo in YYY.)
For more details, please see https://cwiki.apache.org/confluence/display/HADOOP/How+To+Contribute

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 23s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s
The patch appears to include 4 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
1m  8s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
20m 52s
trunk passed

+1 :green_heart:
compile
18m 18s
trunk passed

+1 :green_heart:
checkstyle
2m 51s
trunk passed

+1 :green_heart:
mvnsite
1m 54s
trunk passed

+1 :green_heart:
shadedclient
19m 39s
branch has no errors when building and testing our client artifacts.

+1 :green_heart:
javadoc
1m 51s
trunk passed

+0 :ok:
spotbugs
0m 44s
Used deprecated FindBugs config; considering switching to SpotBugs.

+1 :green_heart:
findbugs
2m 51s
trunk passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 21s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
1m 10s
the patch passed

+1 :green_heart:
compile
17m 29s
the patch passed

+1 :green_heart:
javac
17m 29s
the patch passed

+1 :green_heart:
checkstyle
2m 52s
the patch passed

+1 :green_heart:
mvnsite
1m 53s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
shadedclient
14m  2s
patch has no errors when building and testing our client artifacts.

+1 :green_heart:
javadoc
1m 52s
the patch passed

+1 :green_heart:
findbugs
3m  5s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
9m 30s
hadoop-common in the patch passed.

-1 :x:
unit
21m 58s
hadoop-yarn-applications-distributedshell in the patch failed.

+1 :green_heart:
asflicense
0m 47s
The patch does not generate ASF License warnings.

145m 45s

Reason
Tests

Failed junit tests
hadoop.yarn.applications.distributedshell.TestDistributedShell

Subsystem
Report/Notes

Docker
Client=19.03.5 Server=19.03.5 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1767/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1767

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 1c3fa7ea84e7 4.15.0-70-generic #79-Ubuntu SMP Tue Nov 12 10:36:11 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 2408066

Default Java
1.8.0_222

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1767/1/artifact/out/patch-unit-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-applications_hadoop-yarn-applications-distributedshell.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1767/1/testReport/

Max. process+thread count
1716 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-applications-distributedshell U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1767/1/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
34m 25s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s
The patch appears to include 5 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
1m  6s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
23m 45s
trunk passed

+1 :green_heart:
compile
21m  9s
trunk passed

+1 :green_heart:
checkstyle
3m  4s
trunk passed

+1 :green_heart:
mvnsite
2m 37s
trunk passed

+1 :green_heart:
shadedclient
21m 13s
branch has no errors when building and testing our client artifacts.

+1 :green_heart:
javadoc
2m 22s
trunk passed

+0 :ok:
spotbugs
1m  5s
Used deprecated FindBugs config; considering switching to SpotBugs.

+1 :green_heart:
findbugs
3m 57s
trunk passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 22s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
1m 40s
the patch passed

+1 :green_heart:
compile
19m 14s
the patch passed

+1 :green_heart:
javac
19m 14s
the patch passed

+1 :green_heart:
checkstyle
2m 52s
the patch passed

+1 :green_heart:
mvnsite
2m 33s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
shadedclient
13m 46s
patch has no errors when building and testing our client artifacts.

+1 :green_heart:
javadoc
2m 22s
the patch passed

+1 :green_heart:
findbugs
4m 12s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
9m 29s
hadoop-common in the patch passed.

-1 :x:
unit
21m 59s
hadoop-yarn-applications-distributedshell in the patch failed.

+1 :green_heart:
unit
0m 45s
hadoop-yarn-csi in the patch passed.

+1 :green_heart:
asflicense
0m 45s
The patch does not generate ASF License warnings.

192m 55s

Reason
Tests

Failed junit tests
hadoop.yarn.applications.distributedshell.TestDistributedShell

Subsystem
Report/Notes

Docker
Client=19.03.5 Server=19.03.5 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1767/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1767

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 007ca9291fa0 4.15.0-70-generic #79-Ubuntu SMP Tue Nov 12 10:36:11 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 92c8962

Default Java
1.8.0_232

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1767/2/artifact/out/patch-unit-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-applications_hadoop-yarn-applications-distributedshell.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1767/2/testReport/

Max. process+thread count
1731 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-applications-distributedshell hadoop-yarn-project/hadoop-yarn/hadoop-yarn-csi U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1767/2/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 32s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s
The patch appears to include 7 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
0m 28s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
21m 47s
trunk passed

+1 :green_heart:
compile
22m 18s
trunk passed

+1 :green_heart:
checkstyle
3m  0s
trunk passed

+1 :green_heart:
mvnsite
2m 38s
trunk passed

+1 :green_heart:
shadedclient
20m 49s
branch has no errors when building and testing our client artifacts.

+1 :green_heart:
javadoc
2m 19s
trunk passed

+0 :ok:
spotbugs
1m  6s
Used deprecated FindBugs config; considering switching to SpotBugs.

+1 :green_heart:
findbugs
4m  3s
trunk passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 26s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
1m 50s
the patch passed

+1 :green_heart:
compile
19m 40s
the patch passed

+1 :green_heart:
javac
19m 40s
the patch passed

+1 :green_heart:
checkstyle
2m 50s
the patch passed

+1 :green_heart:
mvnsite
2m 33s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
shadedclient
13m 47s
patch has no errors when building and testing our client artifacts.

+1 :green_heart:
javadoc
2m 21s
the patch passed

+1 :green_heart:
findbugs
4m 13s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
9m 27s
hadoop-common in the patch passed.

-1 :x:
unit
22m 23s
hadoop-yarn-applications-distributedshell in the patch failed.

+1 :green_heart:
unit
0m 43s
hadoop-yarn-csi in the patch passed.

+1 :green_heart:
asflicense
0m 48s
The patch does not generate ASF License warnings.

159m  9s

Reason
Tests

Failed junit tests
hadoop.yarn.applications.distributedshell.TestDistributedShell

Subsystem
Report/Notes

Docker
Client=19.03.5 Server=19.03.5 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1767/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1767

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 2b1950dda83d 4.15.0-70-generic #79-Ubuntu SMP Tue Nov 12 10:36:11 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 7b93575

Default Java
1.8.0_232

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1767/3/artifact/out/patch-unit-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-applications_hadoop-yarn-applications-distributedshell.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1767/3/testReport/

Max. process+thread count
1606 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-applications-distributedshell hadoop-yarn-project/hadoop-yarn/hadoop-yarn-csi U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1767/3/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

This issue has been fixed by #2003. Closing.


chore(dev-server): upgrade fastify & related dependencies in

Summary
Upgrade fastify and related packages to v4 and v4 compatible.
Migration included changing from deprecated instance.listen() variadic function to currently supported one with configuration object.
This PR also fixes an issue where dev-server was only listening on only IPv4 or IPv6. Now, when running on localhost, both interfaces are being used for listening for connections.
Test plan

[x] - tested locally in TesterApp

Cool! Can you link the issues that this upgrade resolves?

not sure there are any open issues about that, I've discovered that some time ago - many issue simply say that the Android can't find the bundle so that will indirectly help limit those kind of questions :)


Update Getting Started docs to be a bit more brief

The Getting Started section of the docs includes a bunch of stuff which is not necessary any more.

Configure access to the dashboard can be slimmed down a bit to have docker run -it golang:1.17 go install<EMAIL_ADDRESS>&& echo -n "super secret password" | bcrypt-cli
Install Weave GitOps can be shortened to only push the commits once.

Is there a reason to separately generate the brcypt password and secret rather than using the helmchart to do it all?

see thread https://weaveworks.slack.com/archives/C03244W0C8H/p1649949498981179?thread_ts=1649949075.430179&cid=C03244W0C8H apparently it was decided

When I say it was decided, I was referring to the big disclaimers added in 6a4cf955b and 88ee41890 - @SamLR if that's not what you meant, then please clarify.

ah right. Those were written when I had a different understanding of what the admin user should do/was for.
I think there's a product decision here WRT how much risky behaviour/complexity to add to the getting started guide.
For 'quick poke about' / trial purposes having a bcrypt-hashed password in git is probably reasonable (my understanding of the algorithm is that it's very computationally expensive to try and reverse and not a likely attack vector) but for a production system we'd should steer people towards configuring their admin user creds via sops or some other secret mechanism which encrypts the hash itself.


CASET/RASET max value issue

I noticed this when comparing this ARM code to ST7789 code I wrote for an Atmel last year. (for the ST7789 240x240)
CASET/RASET sets the address window by coordinates. For a 240x240, this should be 0,0, 239, 239.
I fixed the issue by subtracting 1 from the CASET/RASET calls.
void st7789_set_cursor(uint16_t x, uint16_t y)
{
st7789_caset(x, st7789_width - 1);
st7789_raset(y, st7789_height - 1);
}

hi @benheck,
Thank you for bringing this up, do you have time to make a pull request for this change and provide a code snippet to validate the behaviour before and after the change.


New HTTP header validation rules introduce backward compatibility issues

Should the same validation rules be applied for both HTTP/1 and HTTP/2? This change introduces backward compatibility issues:
Originally posted by @valfirst in https://github.com/netty/netty/pull/12760#discussion_r1024140480

Header validation being too relaxed has been a liability on a few occasions. Those tests are trying to add invalid header values, and since the correct default approach for a low-level library like Netty is to follow the standards closely, you get validation errors. Stripping out invalid header value characters is something you can do on a higher level, or in a DefaultHttpHeaders subclass, so you are not locked in, but it's how Netty should behave by default.


NTR - chlorinated naphthalene

Curators at the Environmental Conditions, Treatments, and Exposures Ontology (ECTO) are interested in this term for use in our exposure patterns.
Term: chlorinated naphthalene
Parent: naphthalene (CHEBI:16482)
Definition: A naphthalene that has undergone a non-catalytic chlorination.
Reference: https://en.wikipedia.org/wiki/Naphthalene

Hi,
Are you interested in a particular chlorinated napthalene or do you just want me to create a class in ChEBI since chlorinated napthalenes are a group of compounds. There are 75 possible chlorinated napthalenes and alot of these may not exist in ChEBI.

Hi @amalik01 ,
At this time, our use case only requires a general term for 'chlorinated naphthalene', but not any specific one.

An entry has now been created (CHEBI:156062). It will be searchable on the ChEBI website by tomorrow.


<EMAIL_ADDRESS>package

Please describe the changes this PR makes and why it should be merged:
Migration of https://github.com/discordjs/discord.js/pull/6410 to package here.
This package offers typeguards for otherwise tedious manual typeguards.
Status and versioning classification:
Please move lines that apply to you out of the comment:

Code changes have been tested against the Discord API, or there are no code changes
I know how to update typings and have done so, or typings don't need updating

So I'm leaning towards renaming this module to type-utils, there are various reason for this:

This module only being for type guards feels a bit limited in scope.
Other utility functions such as #isEqual will offer a lot of utility and also fit under the type-utils category.
I eventually want to add support for all functions to accept discord-api-types variants as well as the d.js variants.

Other than naming, this PR won't change anything, but I wanna keep the door open for later changes.


Python int too large to convert to SQLite INTEGER When I use UUID for primary key

I have two models, one has UUID as primary key and in this one when I want to show the history OverFlowError appears and in the other it works fine.
1.0 alpha 1 is my django-auditlog version.
I installed using the following command
pip install django-auditlog==1.0a1

After reading back the documentation I found the following:

AuditlogHistoryField accepts an optional pk_indexable parameter, which is either True or False, this defaults to True. If your model has a custom primary key that is not an integer value, pk_indexable needs to be set to False

With that I solved the problem.
class Company(models.Model):
    history = AuditlogHistoryField(pk_indexable=False)
    ...

Sorry, I must have overlooked it when I first read the documentation.


ci: add editorconfig and prettier

Non-functional changes have been applied automatically via editorconfig and prettier, enforcing consistent indentation, line endings, and in some cases code cleanups.
Non-functional changes are:

Added package.json to ensure consistent prettier version is used between us
Added installation of prettier via npm install to make setup
Added prettier to make {fmt,lint}

This knocks off these meta issues for this repository:

https://github.com/textileio/meta/issues/4
https://github.com/textileio/meta/issues/3

@sanderpick once merged, you should add this plugin to your code editor:

https://plugins.jetbrains.com/plugin/10456-prettier

@carsonfarmer @asutula @andrewxhill for us VSCode users, make sure you have this plugin installed:

https://marketplace.visualstudio.com/items?itemName=EditorConfig.EditorConfig


Ye

Description
Added xdeepFM on movielens dataset, including pre-processing, evaluation and notebook .
three modes for pre-processing : regression, classification and top N recommendation
Related Issues

Checklist:

[ ] My code follows the code style of this project, as detailed in our contribution guidelines.
[x] I have added tests.
[ ] I have updated the documentation accordingly.

do you think we need a separate folder (pipeline_demo) for this? if so it would be good to make it a bit more explicit, maybe: azureml_pipeline ? and we should update the readme in 05_operationalize to give an overview description

there's an effort to update the current xDeepFM quickstart notebook which would drop the synthetic datataset and use the criteo data loaders that we have implemented. I think if we can finish this PR it would make an even better option for replacing the current xDeepFM quickstart notebook.
@yexing99 do you think you'll have time over the next week or two to work on this? do you need any support?

Yes for the next week, I am available to work on it
Get Outlook for Androidhttps://aka.ms/ghei36

From: Scott Graham<EMAIL_ADDRESS>Sent: Friday, May 31, 2019 9:44:15 AM
To: microsoft/recommenders
Cc: yexing99; Mention
Subject: Re: [microsoft/recommenders] Ye (#643)
there's an effort to update the current xDeepFM quickstart notebook which would drop the synthetic datataset and use the criteo data loaders that we have implemented. I think if we can finish this PR it would make an even better option for replacing the current xDeepFM quickstart notebook.
@yexing99https://github.com/yexing99 do you think you'll have time over the next week or two to work on this? do you need any support?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/recommenders/pull/643?email_source=notifications&email_token=AGCIWIFGEMATVUWN55366XTPYETS7A5CNFSM4G5O73J2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWVIECA#issuecomment-497713672, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGCIWIGMAVO6OXB4Y6UJVZ3PYETS7ANCNFSM4G5O73JQ.


add stdenv

Working towards implementing stdenv from nixpkgs decoupled from the rest of the repo
Edit:
Right now, the package structure is similar to nixpkgs by-name, with modification to allow for multiple versions, ie:
by-name
├── gd
│   ├── gd
│   │   ├── default.nix
│   │   └── packages.nix
│   └── gdbm
│       └── default.nix
...

In this case, package gdbm will be evaluated as gdbm = callPackage ./by-name/gdbm { }
Packages with a packages.nix file, such as gd will be imported as import "${path}/packages.nix" { inherit lib noSysDirs config overlays; } res self super. This idea allows for most (all?) packages and package sets to be placed in by-name.
Todo

[x] build stdenv
[x] build nix
[ ] clean up

Just checking in - how are we tracking on this PR? I'd like to start using some of this stuff in the JS repo once it's ready.

Been a bit busy irl so haven't had as much time to work on this as I'd like, but I think I've gotten past the bulk of the issues and now just have to rip all the necessary packages from nixpkgs. In the meantime, you can use the nixPackages output of this repo, and just switch it to auxPackages later on (although might cause friction in migration if packages used aren't in core yet). Regardless at least stdenv should be done sometime this week (hopefully)

Looking at the amount of changes happening here, I worry this is going to become impossible to review once it's ready. Would it be possible to split some of this work into smaller chunks?

Yeah, it's mostly copy-paste from nixpkgs with the (almost) bare minimum to build stdenv and nix (and lix). Right now that does include a lot of packages which can hopefully be reduced over time. I was hoping to build a starting point where we can test things on and allow for language-specific SIGs to start work.

Looking at the amount of changes happening here, I worry this is going to become impossible to review once it's ready. Would it be possible to split some of this work into smaller chunks?

Yeah, I don't think there's any good way around it given the web of dependencies. Most of the stuff tying everything together is in pkgs/top-level, and all of the packages are in pkgs/by-name. There's still a lot of commented-out stuff in top-level/all-packages.nix, but mostly build-support stuff that I'm hoping to move to a separate place, nowhere nearly as bad as the nixpkgs version.
For progress, as of the latest commit, both nix and lix can be built successfully. From putting together this proof of concept, I noticed a few things we'll need to decide upon:

How do we want to implement a testing infrastructure?
How do we want to implement alternative versions of core packages that depend on packages from another SIG?

Specifically, I noticed that cmake has a version that uses qt5Packages for its UI. Should cmakeWithGui be defined in a KDE/Qt SIG repo, or in top-level?

Some core language packages, such as rust and python3 are required to build some base utilities. How should this be managed? Under the direction of the core SIG, or the language-specific SIG? Either requires strong coordination between the two.

@vlinkz you have commited result into the pkgs directory.

Cool, I was planning on working on this today but you beat me to it.
I think there's some room to reduce the tree further, but that isn't necessarily a priority right now. For reference, this is all the files that appeared to be evaluated when I built lix on x86_64-linux, and this is every derivation.
I also did some work on separating lib out to its own repository, I'll try and make another PR stacked on top of this one in a bit.

I think there's some room to reduce the tree further, but that isn't necessarily a priority right now. For reference, this is all the files that appeared to be evaluated when I built lix on x86_64-linux, and this is every derivation.

Yes, there's definitely more packages than just that directly used it the build, mostly due to optional dependencies not used in the x86_64-linux version of the packages used. For example a lot of packages depend on darwin and it's set of packages, but that doesn't appear in the x86_64-linux evaluation. However without it, the build still fails with missing dependencies. Rather than heavily modify most of the packages to remove such dependencies, I packaged them given they will probably be necessary in the future.

While this isn't perfect yet, I've opened this for review so that once/if merged, it can be more straightforward for others to contribute, and so that other SIG repos can start work depending on the packages it exports (stdenv, etc). As mentioned before, given the volume of changes it'll be impossible to review all the changes at once. I'm proposing we use this as a starting point to bootstrap the core repo and we fix issues, clean up the organization, and make other changes along the way.

There seems to be a lot of dead nix code, I would comment on more of it but GitHub cannot handle changes of this size well.

There seems to be a lot of dead nix code, I would comment on more of it but GitHub cannot handle changes of this size well.

Yes, in addition to that there is a lot of commented out code such as in perl-packages.nix or python-packages.nix. I left the structure the same as its original nixpkgs form, but we will need to decide on what to keep and how to separate other parts into language-specific SIGs.
I also commented out a number of passthru and passthru.tests attributes that require extra test packages but are not used for package evaluation: libarchive/default.nix#L133-135. We'll need to decide upon how we want to format tests and if we even want to keep them within the package derivations.

I think the best way to go about this, is to merge this PR. And we can handle what we want to keep in another PR such that we can cleanly see the difference between this and nixpkgs. And also to something working into core.


Original file extension case should not be respected

Detailed description of the problem
When uploading an image to Lychee, the case of the file extension will be kept despite the rest of the image name being switched to lowercase. So if you upload, for example, "imAGe.PNG", it will become "hash.PNG" and "hash.png" will 404. It would be more standard to convert the file extension to lowercase automatically like most image hosts. This is because renaming the images to lowercase names manually is not an option on some clients like iOS, whose Photos app images will always be in the format "IMG_0000.EXT".
Steps to reproduce the issue
Upload any image with an uppercase file extension, grab the direct link, note the incorrect case.
Output of the diagnostics (Settings => Diagnostics)
Diagnostics
-----------
Warning: Dropbox import not working. No property for dropboxKey.
No critical problems found. Lychee should work without problems!

System Information
------------------
Lychee Version:  3.2.0
DB Version:      030102
System:          Linux
PHP Version:     7.1
MySQL Version:   50554
Imagick:         1
Imagick Active:  1
Imagick Version: 1655
GD Version:      2.2.3
Plugins:

Browser and system
All, tested on desktop Chrome, Edge, iOS Safari, etc.

This issue will be closed because I'm not actively working on Lychee anymore. The repository of Lychee will stay available, but the main development continues under the Lychee Organisation. A fork maintained by the community. Important issues have been migrated. Feel free to re-add your issue(s) when necessary.


update iao import #1700

Summary of the discussion
Based on #1700 and #1755 and #1756 and #1651 and #1695 and #1689

[x] remove OMO import since redundant
[x] update iao import based on https://github.com/OpenEnergyPlatform/oeo-tools/pull/4
[x] update domains and ranges of imported object properties

Type of change (CHANGELOG.md)
Add
http://purl.obolibrary.org/obo/IAO_0000582 # time stamped measurement datum
http://purl.obolibrary.org/obo/IAO_0000007 # action specification
http://purl.obolibrary.org/obo/IAO_0000098 # data format specification
http://purl.obolibrary.org/obo/IAO_0000005 # objective specification
http://purl.obolibrary.org/obo/OBI_0500000 # study design
http://purl.obolibrary.org/obo/IAO_0000594 # software application
http://purl.obolibrary.org/obo/IAO_0000593 # software library
http://purl.obolibrary.org/obo/IAO_0000591 # software method
http://purl.obolibrary.org/obo/IAO_0000592 # software module
http://purl.obolibrary.org/obo/IAO_0000595 # software script
http://purl.obolibrary.org/obo/IAO_0000314 # document part # subclasses requireds?
http://purl.obolibrary.org/obo/IAO_0000013 # journal article
http://purl.obolibrary.org/obo/IAO_0000129 # version number
http://purl.obolibrary.org/obo/IAO_0000400 # cartesian spatial coordinate datum
http://purl.obolibrary.org/obo/IAO_0000401 # one dimensional cartesian spatial coordinate datum
http://purl.obolibrary.org/obo/IAO_0000402 # two dimensional cartesian spatial coordinate datum
http://purl.obolibrary.org/obo/IAO_0000403 # three dimensional cartesian spatial coordinate datum
http://purl.obolibrary.org/obo/IAO_0000581 # has time stamp
Automation
Closes #1755, #1700
PR-Assignee

[ ] 🐙 Follow the Pull Request Workflow
[ ] 📝 Update the CHANGELOG.md
[ ] 📙 Add #'s to term tracker item

Reviewer

[ ] 🐙 Follow the Reviewer Guide
[ ] 🐙 Provided feedback and show sufficient appreciation for the work done

I just saw, the the newly imported journal article has two parents, report and puclication. How do we deal with that? I'd vote for removing either of them and comment in oeo-import-edits.

Todo:
clean oeo-import-edits. I'll do that in a separate issue once this PR is merged, for a better reviewability.

I just saw, the the newly imported journal article has two parents, report and pubclication. How do we deal with that? I'd vote for removing either of them and comment in oeo-import-edits.

Thanks for the review. Any opinion on this @l-emele ?

I just saw, the the newly imported journal article has two parents, report and pubclication. How do we deal with that? I'd vote for removing either of them and comment in oeo-import-edits.

Thanks for the review. Any opinion on this @l-emele ?

From todays oeo-dev-meeting: try to skip the import of publication and have only the already imported class report as parent

I could not reproduce the extraction process 1 to 1, did you do some manual changes after extracting or am I missing something?

I could not reproduce the extraction process 1 to 1, did you do some manual changes after extracting or am I missing something?

Did you update the shell-script? I ran the script pushed in this commit: https://github.com/OpenEnergyPlatform/oeo-tools/pull/4/commits/b1cd5d4ec6b61c69cd8eeb453270053ab11e1e69 All other changes have been done in oeo-import-edits.

I could not reproduce the extraction process 1 to 1, did you do some manual changes after extracting or am I missing something?

Can you specify the diffs? I ran the script pushed in this commit: OpenEnergyPlatform/oeo-tools@b1cd5d4 All other changes have been done in oeo-import-edits.

@areleu could you also review this PR https://github.com/OpenEnergyPlatform/oeo-tools/pull/4 please.

I could not reproduce the extraction process 1 to 1, did you do some manual changes after extracting or am I missing something?

Can you specify the diffs? I ran the script pushed in this commit: OpenEnergyPlatform/oeo-tools@b1cd5d4 All other changes have been done in oeo-import-edits.

Just checked it out, and I could reproduce the imports

I could not reproduce the extraction process 1 to 1, did you do some manual changes after extracting or am I missing something?

Can you specify the diffs? I ran the script pushed in this commit: OpenEnergyPlatform/oeo-tools@b1cd5d4 All other changes have been done in oeo-import-edits.

@areleu could you also review this PR OpenEnergyPlatform/oeo-tools#4 please.

I guess this check works as validation of this too.


drained: fix not restoring when charge threshold met

previously the assumption was that the "changing" event would be fired periodically when charging.
fixes #3625

App deployed here for testing

Thanks!


Crash when 'File Of' edges are selected (Windows EVTX)

I am experiencing an issue where if the 'file of' Edge Type is selected, and a 'File' is linked to a process node (in a Windows EVTX file), when I click on a 'timeline' or any of the edges do  display their info, the GUI for beagle will kick me out onto a completely blank page, and my progress on the chart gets completely wiped:

The CLI which is running the docker run command is not showing any errors.

Can you open up the chrome developer console and copy paste the javascript error?

Is the tool intended to be used with Chrome?
I'm currently running it on Firefox .

Chrome Error when going to 'timeline' after selecting the File Of Edge to be displayed
TypeError: Cannot use 'in' operator to search for 'timestamp' in null
at EventTimeline.tsx:29
at Array.filter ()
at EventTimeline.tsx:29
at Array.map ()
at t.getDerivedStateFromProps (EventTimeline.tsx:44)
at or (react-dom.production.min.js:2769)
at cr (react-dom.production.min.js:2852)
at Mo (react-dom.production.min.js:3759)
at Ao (react-dom.production.min.js:3960)
at Va (react-dom.production.min.js:5514)
da @ react-dom.production.min.js:4408
n.callback @ react-dom.production.min.js:4773
ra @ react-dom.production.min.js:4271
ia @ react-dom.production.min.js:4259
Wa @ react-dom.production.min.js:4999
Ya @ react-dom.production.min.js:5123
(anonymous) @ react-dom.production.min.js:5975
e.unstable_runWithPriority @ scheduler.production.min.js:274
Ps @ react-dom.production.min.js:5974
Ds @ react-dom.production.min.js:5958
Cs @ react-dom.production.min.js:5925
Rs @ react-dom.production.min.js:6020
En @ react-dom.production.min.js:1737
react-dom.production.min.js:5940 Uncaught TypeError: Cannot use 'in' operator to search for 'timestamp' in null
at EventTimeline.tsx:29
at Array.filter ()
at EventTimeline.tsx:29
at Array.map ()
at t.getDerivedStateFromProps (EventTimeline.tsx:44)
at or (react-dom.production.min.js:2769)
at cr (react-dom.production.min.js:2852)
at Mo (react-dom.production.min.js:3759)
at Ao (react-dom.production.min.js:3960)
at Va (react-dom.production.min.js:5514)
(anonymous) @ EventTimeline.tsx:29
(anonymous) @ EventTimeline.tsx:29
t.getDerivedStateFromProps @ EventTimeline.tsx:44
or @ react-dom.production.min.js:2769
cr @ react-dom.production.min.js:2852
Mo @ react-dom.production.min.js:3759
Ao @ react-dom.production.min.js:3960
Va @ react-dom.production.min.js:5514
qa @ react-dom.production.min.js:5536
Ds @ react-dom.production.min.js:5958
Cs @ react-dom.production.min.js:5925
Rs @ react-dom.production.min.js:6020
En @ react-dom.production.min.js:1737

When there's no underyling events the following table is now shown. Thanks for reporting the bug!

Fixed via #63, pull down the newest docker image in about 30 minutes

Hi @yampelo
It seems like hte issue was fixed when i Double click the edge node, however when I switch views from 'Graph' to Timeline or while I have the 'File of' selected, I still get redirected to a blank page and the following error occurs in chrome:
Failed to load resource: the server responded with a status of 404 (NOT FOUND)
3:8000/api/new:1 Failed to load resource: the server responded with a status of 500 (INTERNAL SERVER ERROR)
react-dom.production.min.js:4408 TypeError: Cannot use 'in' operator to search for 'timestamp' in null
at EventTimeline.tsx:29
at Array.filter ()
at EventTimeline.tsx:29
at Array.map ()
at t.getDerivedStateFromProps (EventTimeline.tsx:44)
at or (react-dom.production.min.js:2769)
at cr (react-dom.production.min.js:2852)
at Mo (react-dom.production.min.js:3759)
at Ao (react-dom.production.min.js:3960)
at Va (react-dom.production.min.js:5514)
da @ react-dom.production.min.js:4408
react-dom.production.min.js:5940 Uncaught TypeError: Cannot use 'in' operator to search for 'timestamp' in null
at EventTimeline.tsx:29
at Array.filter ()
at EventTimeline.tsx:29
at Array.map ()
at t.getDerivedStateFromProps (EventTimeline.tsx:44)
at or (react-dom.production.min.js:2769)
at cr (react-dom.production.min.js:2852)
at Mo (react-dom.production.min.js:3759)
at Ao (react-dom.production.min.js:3960)
at Va (react-dom.production.min.js:5514)


SAR 771: update node

Related Tickets

SAR-771

Other Repos' PR(s) Intended to Work With This PR
None.
How Things Worked (or Didn't) Before This PR
Node wasn't 18. Should be.
How Things Work Now (And How to Test)
yarn test, major changes in behavior are related to react-router-dom, authentication and axios
Readiness

[x] This PR passes all automated tests. (develop branch has broken tests, this didn't break anything new)
[x] This PR has no linting errors.
[x] This PR's changes to configuration files have been documented in all appropriate places (such as but not limited to README.md), if applicable.

ready to merge


[WIP]: Alert message not received by server

Here if message is not delivered to server a popup will show in 10s(just for testing purpose now). #3212

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

The message not delivered to server will be displayed in alert. If this is alright I am thinking of first deleting the message from the message list and then working on improving the undelivered notification scheme, I will try to go for something in the direction of displaying "Message not delivered" just beside the message. How does this sound?

@mahim97 !  Thanks for the follow up.  It looks like you have some build errors.  I also made some comments on Zulip chat.

@showell I have made syntax changes.

@showell How is this looking?

Updated:


Test XCode 7.3

iOS 7.3 was released this week. Has it been tested yet? Is it safe to install it?

I was using it yesterday without issue. Will check again to make sure and update docs.

Should be good to go :+1:


fix(router): make addRoute split list of routes into multiple routeco…

#509

@davismj I just noticed the "merge options" PR creeped in with this one. You want me to split them up or need something else done in order for this to be ready for mergin?


Add aliases for Base, BaseSepolia and BaseGoerli

Motivation
There are no aliases set for Base Mainnet, Sepolia and Goerli.

Solution
Add aliases for Base, BaseGoerli and BaseSepolia and related tests.

PR Checklist

[x] Added Tests
[ ] Added Documentation
[ ] Breaking changes

Hi @mattsse here's the new PR: https://github.com/alloy-rs/chains/pull/32


Capture exit code of executed scripts, pass failures out as git-hook …

…result
Which issues are addressed?
autohook.sh currently swallows exit codes of the scripts it executes, and generally terminates with exit code 0 (success). In turn, git hooks which are specified to abort on failures (exit code != 0) never will actually abort.
What's implemented?
If one or more of the scripts linked for a hook-type result in a negative (!= 0) exit code, that exit code will define the exit code of the whole hook (i.e. of the autohook.sh) invocation. By that way, a hook such as pre-commit is able to be aborted in case one of the sub-scripts defined via autohook fails.
Why this implementation?
Making sure to not swallow exit codes is crucial to maintain the basic functionality of git hooks, specifically for the pre-xxx hooks which should allow to act as a safeguard / prevent some operation.
Either way, with this implementation, all of the sub-scripts for a hook-type still get executed, even if one has already failed at start. It would be possible to already abort on first failure instead though - however, since some of the hooks aren't even supposed to abort (post-xxx), IMO it's more consistent to still execute them all and only determine an appropriate total exit status as global result.
Any caveats?
In case there are multiple scripts for a hook type which fail, only one of their exit codes (the last one) will be used as exit code.
Any additional notes?
Checklist

[ ] Everything works.
[ ] Test are present and pass.
[ ] Documentation has been updated.

This looks great! I think it'd be helpful to say which script failed. Maybe something like this:

      if [[ $script_exit_code != 0 ]]
      then
        hook_exit_code=$script_exit_code
        echo "FINISH $scriptname but with exit code: $script_exit_code"
      else
        echo "FINISH $scriptname"
      fi

This looks great! I think it'd be helpful to say which script failed. Maybe something like this:
      if [[ $script_exit_code != 0 ]]
      then
        hook_exit_code=$script_exit_code
        echo "FINISH $scriptname but with exit code: $script_exit_code"
      else
        echo "FINISH $scriptname"
      fi

This definitely looks useful for the current version, thanks!


Add a quote feature / better sanitize post HTML

See reply 168901. Lintamande copied a post (as a quote) into a reply, and currently classes are not stripped from divs.
Perhaps classes should be stripped from divs or the CSS around post-contents should be adjusted for such a scenario. Alternatively see the issue about a proper quotes system. Disabling 'paste with formatting' could also help here, especially if it can be restricted to remove everything but italics, bolding, underline and strikethrough.

Allow people to quote other replies because apparently this is used in a few places.

Let's restrict the .post-container formatting to be for .post-containers which are direct children of #content, how about.


Add support for distrobox assemble

About
While working on the volumes feature (still very WIP) I also noticed we have no support for distrobox assemble files.
Typically those are ini files containing one or more distrobox specifications.
An example could look like this:
[tumbleweed-test]
additional_packages=git bash-completion opi ffmpeg-6 gcc make cmake htop scout-command-not-found
image=tumbleweed:latest
init=true
start_now=false
nvidia=true
pull=true
root=false
replace=false
volume=/opt/datalake:/opt/datalake
volume=/etc/vulkan/:/etc/vulkan/

[rocky-test]
additional_packages=fuse fuse-libs alsa-lib apr apr-util fontconfig freetype libglvnd libglvnd-egl libglvnd-glx libglvnd-opengl libgomp librsvg2 libXcursor libXfixes libXi libXinerama libxkbcommon libxkbcommon-x11 libXrandr libXrender libXtst libXxf86vm mesa-libGLU mtdev pulseaudio-libs xcb-util xcb-util-image xcb-util-keysyms xcb-util-renderutil xcb-util-wm ocl-icd
image=quay.io/rockylinux/rockylinux:8
pull=true
replace=true
nvidia=true

[appimage-test]
additional_packages=fuse libfuse2 xcb libfontconfig1 libxcb-xkb1 libxkbcommon-x11-0 libXi6 libXrender1 libQt5WaylandClient5 libqt5-qtwayland libQt6WaylandClient6 kwayland qt6-wayland pipewire-alsa libfribidi0 libthai libXtst6
image=tumbleweed:latest
init=false
start_now=false
nvidia=true
pull=true
root=false
replace=true

With the command distrobox assemble --file /path/to/file distrobox can created one ore more distroboxes at once.
I added a new button to the header bar for the assemble feature instead of adding it to the new distrobox popup because I found the assemble feature rather different from the create feature.
This button will only show if host_access is true for flatpak users.

Clicking this button will open up a FileDialog with a file filter for the MIME-Types: text/plain, application/textedit and application/zz-winassoc-ini

Then a popup will shown with a status message and a spinner as long as distrobox is busy which will then auto close and trigger a re render of the main window to show the new boxes.

I did not yet provided any additional translations for this new feature as I plan on adding all missing translations later if more stuff was added.
Notice: The user would be able to create distrobox containers without nvidia integration this way!
But also I assume user to have those ini files do also know about the nvidia flag.
Kind regards,
V.

Wow, this is great, thank you!

That was fast. I was still reading my PR for spelling errors and wording issues 😆
Many thanks!

Was funny timing, I was just releasing 1.2.1 when this came in.
I'll release this as 1.3.0 soon, depending if I'm free tomorrow.


Use UTC times

The purpose of this PR is to set every date appearing in the app to UTC

We will use local time instead


Fix memory leaks by using shared_ptr<> almost everywhere

I think the "public" API should not have changed, but please double-check (our code worked out of the box). The python side seems to work (but I did not test in details).
We could consider a few API changes. For instance, the solver factory could return a shared_ptr instead of a pointer. There are also a few
We have to move to c++11 for std::shared_ptr (I also used a few auto, since we are in c++11...).
This should fix #110.

This project doesn't accept pull requests on master, please change the base branch of your pull request to devel.


dashboard.js split to multiple files + some improvements

tasks:

[x] use beforeSend, complete and spinners for making visible that something takes place in the background. This will help for any other async call that will occur without page reload
[x] change api_get/put/delete/post() functions to do exactly what their name says, no other UI task. Add callbacks to do the rest regarding the UI.
[x] add layers to maps to let the users choose what they want to see or not (Cells, UEs, Paths)
[x] try to avoid "stale" states by reloading data from each endpoint and refreshing the datatables (an idea here, might be to do this periodically and when no pop-up window is open)

[ ] try to avoid "stale" states by reloading data from each endpoint and refreshing the datatables (an idea here, might be to do this periodically and when no pop-up window is open)

Regarding this, periodic reloads are not implemented yet. It will complicate things and we will have to figure out how to not mess with user actions (e.g. having a modal open and editing something). It's doable to somehow introduce a "locking" mechanism and do the reloads when they will not cause problems, but let's see if we are ok for now.


ISPN-6046 Server Rolling Upgrade performance improvement

https://issues.jboss.org/browse/ISPN-6046
https://issues.jboss.org/browse/ISPN-6052
https://issues.jboss.org/browse/ISPN-6053
https://issues.jboss.org/browse/ISPN-6064
https://issues.jboss.org/browse/ISPN-6065
Perf
Before: Rolling upgrade from clusters 8.1.0.Final (2 members) -> 8.1.0.Final (2 members)
(times are the sum of time to dump keys plus the time to synchronize data)
After: Rolling upgrade from clusters 8.2.0-SNAPSHOT (2 members) -> 8.2.0-SNAPSHOT (2 members)
(no key dump is necessary if the source cluster is ispn >= 8.0)

Entries
Before  (avg)
After (avg)

50k
24s
5s

500k
3min10s
41s

2M
15min10s
2min30s

5M
Error during key dump (timeouts, OOME)
7min9s

benchmark hardware: 8Gb RAM, 4 vCPU, Fedora 22 on Openstack
Details
This PR makes use of the Remote Iterator to migrate data between clusters, the dumpKeys step is not necessary if the source cluster has version >= 8.0. If not, it will fallback to reading keys dumped.

@ttarrant Updated. I also had to change the architecture a little bit to maintain the "advertised" performance, since putAll cannot used anymore: now the data migrator is distributed, each node of the new cluster will load a portion of the data (a set of segments)

Good job, @gustavonalle . Merged

Brilliant work @gustavonalle :clap: