Try out performance with LevelDB (and goleveldb)

Some experimentation with the storage backend would be worthwhile.

According to the bleve docs, this will result in better performance. It should also result in a much lower storage footprint -- something approaching practical.
However this will require a more complex build, and possibly a Makefile. It requires that the user have leveldb available as a dynamic library on the build machine.
The build process could go something like this:

include explicit instructions for building and installing leveldb. This is a useful, albeit simple, reference. https://gist.github.com/dustismo/6203329
assuming this is installed, then pass -tags leveldb to the build process. It's yet to be determined if this can be passed to the Ekanite build, or needs to be passed explicitly to bleve.

Ekanite code also needs patching to use the LevelDB engine. Something as simple as this should work:
$ git diff
diff --git a/index.go b/index.go
index 66ca222..9d5b2ad 100644
--- a/index.go
+++ b/index.go
@@ -351,7 +351,7 @@ func (s *Shard) Open() error {
                if err != nil {
                        return err
                }
-               s.b, err = bleve.New(s.path, mapping)
+               s.b, err = bleve.NewUsing(s.path, mapping, bleve.Config.DefaultIndexType, "leveldb", map[string]interface{}{})
                if err != nil {
                        return fmt.Errorf("bleve new: %s", err.Error())
                }

The choice of engines could be optional, BoltDB by default. But this would mean a system that consumes too much disk space by default.
A final important reference: http://www.blevesearch.com/docs/Building/

A bullet-proof makefile needs to ensure snappy is installed, as well and the GCC toolchain.


9092 fix

Sets the last child to float to global left. Fixes #9092

Closing this - will do a new PR as I messed this one up some how...


Replaced usage of ApplicationException with Exception

Summary
Changed the thrown exception type to be Exception instead of ApplicationException which gives off a warning as per #21865
Fixes #21865

That's a pretty unexpected build error.
I assume the files in questions were never build with this particular build process so this was never figured out before?
Is there anything I can do about this?

That's a pretty unexpected build error.
I assume the files in questions were never build with this particular build process so this was never figured out before?
Is there anything I can do about this?

That's a pretty unexpected build error.
I assume the files in question were never built with this particular build process so this was never figured out before?
Is there anything I can do about this?

@TheEskhaton Yes, the CI build system for code files is pretty new in this repository. The fix is simply to add a csproj and vbproj files.

That's a pretty unexpected build error.
I assume the files in question were never built with this particular build process so this was never figured out before?
Is there anything I can do about this?

@TheEskhaton Yes, the CI build system for code files is pretty new in this repository. The fix is simply to add a csproj and vbproj files.

Thanks for putting this together @TheEskhaton
I agree with both comments from @Youssef1313. Thanks for adding the csproj and vbproj files. That helps us improve.
Can you also accept the suggestion to change the type of exception being thrown?
Background on the CI process:
When our samples were migrated from an internal system, the build artifacts were not included. The samples previously used an internal build tool.  Because of that situation, our CI script ensures that code changes result in a project being built. That way, whenever code is changed, any missing projects are flagged for updates. It's a trigger that helps us improve.

Thanks for putting this together @TheEskhaton
I agree with both comments from @Youssef1313. Thanks for adding the csproj and vbproj files. That helps us improve.
Can you also accept the suggestion to change the type of exception being thrown?
Background on the CI process:
When our samples were migrated from an internal system, the build artifacts were not included. The samples previously used an internal build tool.  Because of that situation, our CI script ensures that code changes result in a project being built. That way, whenever code is changed, any missing projects are flagged for updates. It's a trigger that helps us improve.

@TheEskhaton
The most recent build failure indicates that these samples must be built on Windows. To fix this, add a file named snippets.5000.json in the project directory. The file should have the following contents:
{
    "host": "visualstudio"
}

Then, our CI build will use Visual Studio instead of the .NET CLI.

@TheEskhaton
The most recent build failure indicates that these samples must be built on Windows. To fix this, add a file named snippets.5000.json in the project directory. The file should have the following contents:
{
    "host": "visualstudio"
}

Then, our CI build will use Visual Studio instead of the .NET CLI.

@BillWagner
I've managed to fix the build issue by making the projects target net48 and added a reference to the System.Windows.Forms assembly into the project files.
Is this sufficient or do you want to have them target net5.0 and include the _snippets.5000.json _ as you've mentioned?
The Exception type has been changed to ArgumentException.

@BillWagner
I've managed to fix the build issue by making the projects target net48 and added a reference to the System.Windows.Forms assembly into the project files.
Is this sufficient or do you want to have them target net5.0 and include the _snippets.5000.json _ as you've mentioned?
The Exception type has been changed to ArgumentException.

@TheEskhaton

Is this sufficient or do you want to have them target net5.0 and include the snippets.5000.json as you've mentioned?

That's fine as well. Thank you.

@TheEskhaton

Is this sufficient or do you want to have them target net5.0 and include the snippets.5000.json as you've mentioned?

That's fine as well. Thank you.

Thanks! Then this is ready for a merge as far as I'm concerned.

Thanks! Then this is ready for a merge as far as I'm concerned.


Please tell how can I modify TabExpansion2 to complete in lowercase

How can I modify TabExpansion2 to complete in lowercase.
# Now
ls . -Force -Directory

# Wanted
ls . -force -directory

Thanks!

Let me think a little bit. I have tried some straightforward conversion and it did not work (not sure why..).

We can transform the final ${*}.result before returning it:
for($i = 0; $i -lt ${*}.result.CompletionMatches.Count; ++$i) {
    $r = ${*}.result.CompletionMatches[$i]
    ${*}.result.CompletionMatches[$i] = New-Object System.Management.Automation.CompletionResult @(
        $r.CompletionText.ToLower()
        $r.ListItemText
        $r.ResultType
        $r.ToolTip
    )
}
${*}.result

There are two places where we return it (actually 3, but one is special read-only).
You may create a function doing this conversion and call it.

@nightroman Wow, thanks a lot!


Multiple 401 when using Windows authentication on HTTP.sys

Describe the bug
The 401 WWW-Negotiate challenge happens for each request.
To Reproduce
Steps to reproduce the behavior:

Using this version of ASP.NET Core '2.2'
Set up HTTP.Sys with options.Authentication.Schemes = Microsoft.AspNetCore.Server.HttpSys.AuthenticationSchemes.Negotiate;
Run Fiddler to intercept requests
Use a client to perform a GET

Expected behavior
The 401 WWW-Negotiate challenge happens only the first time.
Additional context
It looks like when using IIS it is possible to configure authPersistNonNTLM=true to achieve this. See [https://blogs.msdn.microsoft.com/dsnotes/2014/02/11/iis-how-to-reduce-multiple-authentication-or-multiple-401-while-using-kerberos-for-authentication/](this link)
Side note
Performing the 401 challenge means more requests, more traffic, less performance.

authPersistNonNTLM is effectively enabled by default for HttpSys. Are you sure each request is arriving on the same connection?

@Tratcher I've checked with Wireshark and each request is opening a new TCP connection (so a total of 10). I guess the culrpit could be the HttpClient:
`var httpHandler = new HttpClientHandler
{
UseDefaultCredentials = true
};
        var client = new HttpClient(httpHandler);

        client.BaseAddress = new Uri("http://host:5000/");
        for (int i = 0; i < 10; i++)
        {
            try
            {
                HttpResponseMessage response = client.GetAsync("api/user").Result;
                response.EnsureSuccessStatusCode();
                string result = response.Content.ReadAsStringAsync().Result;
                Console.WriteLine("Result: " + result);
            }
            catch (System.Exception ex)
            {
                Console.WriteLine(ex);
            }
        }`

is there a way to force HttpClient to reuse the same connection?

Can you share the wireshark trace? We want to see who's closing the prior connection.

Also, is the client app also .NET Core 2.2 or something else? HttpClient has several implementations.

Client is .NET 4.5.2. I will upload the Wireshark trace as soon as possible.

Ah, for .NET 4.x you need to replace HttpClientHandler with WebRequestHandler and set UnsafeAuthenticatedConnectionSharing.

So I tried with:
var httpHandler = new WebRequestHandler
{
UseDefaultCredentials = true,
UnsafeAuthenticatedConnectionSharing = true
};
and the result is the same but using a single connection (both from Fiddler using the proxy and from Wireshark).

Using the same connection saves you  at least 50% of the costs 😀.
Are the client and server on the same or different machines?
Everything is controlled by this structure:
https://docs.microsoft.com/en-us/windows/win32/api/http/ns-http-http_server_authentication_info
On localhost it only uses NTLM which has caching enabled by default and we don't disable (DisableNTLMCredentialCaching). If they're on different machines it could end up using Kerberos which has caching disabled by default and we don't enable (HTTP_AUTH_EX_FLAG_ENABLE_KERBEROS_CREDENTIAL_CACHING).
https://github.com/aspnet/AspNetCore/blob/e0ee04237af2fa58a525dbd63888894f62195f0a/src/Servers/HttpSys/src/AuthenticationManager.cs#L66-L87

Different machines. You're saying it's a genuine bug?

Different machines, same domain, same domain user running the server and the client.
You're saying it's a genuine bug?

An un-exposed feature, yes.
There's a new alternative in 3.0 using Kestrel if that's an option for you. It does have the options available to enable/disable this kind of caching.
https://docs.microsoft.com/en-us/aspnet/core/security/authentication/windowsauth?view=aspnetcore-3.0&tabs=visual-studio#kestrel
https://github.com/aspnet/AspNetCore/blob/e0ee04237af2fa58a525dbd63888894f62195f0a/src/Security/Authentication/Negotiate/src/NegotiateOptions.cs

moving to 3.0 + Kestrel is not an option for us, until it's released and finalized.

moving to 3.0 + Kestrel is not an option for us, until it's released and finalized.

3.0 releases this month and already has go-live supported previews. Now is the time to try it to confirm it satisfies your scenarios.
https://github.com/dotnet/core/blob/master/roadmap.md
That's much sooner than this issue will be addressed in HttpSys.

To come at this from a different angle, shouldn't the use of UseDefaultCredentials tell HttpClient to send the credentials on the first attempt, thus preventing the 401 in the first place? Or is it supposed to still wait for the 401 first?
(I was helping with this question on Stack Overflow)

No, UseDefaultCredentials means to use the current WindowsIdentity if challenged for 401 Negotiate/NTLM/Kerberos. It means you don't have to give it the username and password manually.

We would accept a PR for this issue, but given our other priorities we're backlogging this for now.


Need to fix responsive issue of the site.

The web page shows a blue color space as shown below. It must be solved.
This may be due to the reason that a bootstrap row class is included unnecessarily somewhere.

I have fixed this in: #26


change: switch to uwsgi

Swaps gunicorn for uwsgi at around version ~2.0 (the "latest" documented version 😭😭😭).
The logs are more helpful now (still doesn't tell us when the workers are fully initialized though).
itwewina_1  | [uWSGI] getting INI configuration from uwsgi.ini
itwewina_1  | *** Starting uWSGI <IP_ADDRESS> (64bit) on [Thu Mar 11 19:26:45 2021] ***
itwewina_1  | compiled with version: 8.3.0 on 11 March 2021 19:05:16
itwewina_1  | os: Linux-4.19.121-linuxkit #1 SMP Tue Dec 1 17:50:32 UTC 2020
itwewina_1  | nodename: a1997ef5540c
itwewina_1  | machine: x86_64
itwewina_1  | clock source: unix
itwewina_1  | detected number of CPU cores: 2
itwewina_1  | current working directory: /app/CreeDictionary
itwewina_1  | detected binary path: /app/.venv/bin/uwsgi
itwewina_1  | !!! no internal routing support, rebuild with pcre support !!!
itwewina_1  | chdir() to /app/CreeDictionary
itwewina_1  | your memory page size is 4096 bytes
itwewina_1  | detected max file descriptor number: 1048576
itwewina_1  | lock engine: pthread robust mutexes
itwewina_1  | thunder lock: disabled (you can enable it with --thunder-lock)
itwewina_1  | uWSGI http bound on :8000 fd 4
itwewina_1  | uwsgi socket 0 bound to TCP address <IP_ADDRESS>:43465 (port auto-assigned) fd 3
itwewina_1  | Python version: 3.9.1 (default, Jan 12 2021, 16:56:42)  [GCC 8.3.0]
itwewina_1  | Python main interpreter initialized at 0x559a236811b0
itwewina_1  | python threads support enabled
itwewina_1  | your server socket listen backlog is limited to 100 connections
itwewina_1  | your mercy for graceful operations on workers is 60 seconds
itwewina_1  | mapped 416720 bytes (406 KB) for 8 cores
itwewina_1  | *** Operational MODE: preforking+threaded ***
itwewina_1  | WSGI app 0 (mountpoint='') ready in 2 seconds on interpreter 0x559a236811b0 pid: 7 (default app)
itwewina_1  | *** uWSGI is running in multiple interpreter mode ***
itwewina_1  | spawned uWSGI master process (pid: 7)
itwewina_1  | spawned uWSGI worker 1 (pid: 8, cores: 2)
itwewina_1  | spawned uWSGI worker 2 (pid: 10, cores: 2)
itwewina_1  | spawned uWSGI worker 3 (pid: 12, cores: 2)
itwewina_1  | spawned uWSGI worker 4 (pid: 14, cores: 2)
itwewina_1  | spawned uWSGI http 1 (pid: 15)

I'll continue tinkering with the config before I think this is ready.
EDIT: it ready
Fixes #684 (hopefully)

@andrewdotn I incorporated the suggestions and opened up a PR in the deploy documentation: (UAlbertaALTLab/deploy.altlab.dev#13). Let me know if there's anything else that should be done!


Update wrapper with recent nightly

This is the final step in bumping Kotlin to 1.9.10
Fixes #26087

@bot-gradle test and merge

I've triggered a build for you. Click here to see all failures if there's any.


Return an error if buffer is full

read_into_buf should return an error if the buffer is full and no additional bytes are read.

I don't think this would help anyone. The buffer will return Ok(0) if the buffer is full, as this is the expected behavior of Read::read() when given a zero-length slice (though I have an early return in Buffer::read_from() because hyper::server::Request doesn't like zero-sized reads).


Adjust to GitHub style changes

Fixes #18.
I haven't bumped the version because there still is a week to go before Github's new styles rolls around for everyone.
Also, this breaks backward compatibility with the old Github styles. There probably is a reliable way to differentiate between the old and new styles, but as the switch to the new styles is going to become mandatory soon, I decided not to spend time figuring it out.

Thank you :)


bug: why click the ion-back-button previous url query param is disappear?

Bug Report
Ionic version:

[x] 4.x
Current behavior:

example: previous url is localhost:8100/test?type=1,current url is localhost:8100/news,then click then ion-back-button navigates back previous url,but the url become localhost:8100/test,now the url query param is disappear.why?
Expected behavior:

i want to click back button navigates back prervious url query param is full
Steps to reproduce:

Related code:
page:localhost:8100/news

insert short code snippets here

Other information:

Ionic info:

insert the output from ionic info here

Thanks for the issue! This is a known issue, so I am going to close this as a duplicate of https://github.com/ionic-team/ionic/issues/16744.
Thanks for using Ionic!


fix: replaced .com with .org (Incorrect freeCodeCamp URL in some challenges)

refs: #56810
Checklist:

[x] I have read and followed the contribution guidelines.
[x] I have read and followed the how to open a pull request guide.
[x] My pull request targets the main branch of freeCodeCamp.
[x] I have tested these changes either locally on my machine, or GitPod.

Closes #56810

The issue is not open for contribution, only issues with the help wanted laber or first timers only label are open for contribution


connman: 1.35 -> 1.36

ver 1.36:
Fix issue with DNS short response on error handling.
Fix issue with handling incoming DNS requests.
Fix issue with handling empty timeserver list.
Fix issue with incorrect DHCP byte order.
Fix issue with AllowDomainnameUpdates handling.
Fix issue with IPv4 link-local IP conflict error.
Fix issue with handling WISPr over TLS connections.
Fix issue with WiFi background scanning handling.
Fix issue with WiFi disconnect+connect race condition.
Fix issue with WiFi scanning and tethering operation.
Fix issue with WiFi security change handling.
Fix issue with missing signal for WPS changes.
Fix issue with online check retry handling.
Add support for systemd-resolved backend.
Add support for mDNS configuration setup.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Success on x86_64-linux (full log)
Attempted: connman
Partial log (click to expand)
shrinking /nix/store/1194a10nnr2d92vqijkf09zlqznix5kl-connman-1.36/lib/connman/scripts/openconnect-script
shrinking /nix/store/1194a10nnr2d92vqijkf09zlqznix5kl-connman-1.36/lib/connman/scripts/openvpn-script
shrinking /nix/store/1194a10nnr2d92vqijkf09zlqznix5kl-connman-1.36/lib/connman/plugins-vpn/pptp.so
gzipping man pages under /nix/store/1194a10nnr2d92vqijkf09zlqznix5kl-connman-1.36/share/man/
strip is /nix/store/j75dgadrff2d1fyc4fczmcgqkid2imdx-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/1194a10nnr2d92vqijkf09zlqznix5kl-connman-1.36/lib  /nix/store/1194a10nnr2d92vqijkf09zlqznix5kl-connman-1.36/bin  /nix/store/1194a10nnr2d92vqijkf09zlqznix5kl-connman-1.36/sbin
patching script interpreter paths in /nix/store/1194a10nnr2d92vqijkf09zlqznix5kl-connman-1.36
checking for references to /build in /nix/store/1194a10nnr2d92vqijkf09zlqznix5kl-connman-1.36...
moving /nix/store/1194a10nnr2d92vqijkf09zlqznix5kl-connman-1.36/sbin/* to /nix/store/1194a10nnr2d92vqijkf09zlqznix5kl-connman-1.36/bin
/nix/store/1194a10nnr2d92vqijkf09zlqznix5kl-connman-1.36

Success on aarch64-linux (full log)
Attempted: connman
Partial log (click to expand)
shrinking /nix/store/af83ji4wljdwf0gl4vqkn3d0s858s4lj-connman-1.36/sbin/connmand-wait-online
shrinking /nix/store/af83ji4wljdwf0gl4vqkn3d0s858s4lj-connman-1.36/sbin/connmand
shrinking /nix/store/af83ji4wljdwf0gl4vqkn3d0s858s4lj-connman-1.36/bin/connmanctl
gzipping man pages under /nix/store/af83ji4wljdwf0gl4vqkn3d0s858s4lj-connman-1.36/share/man/
strip is /nix/store/jk6j4lh9v5mvjdbdc35sj0zffhhf6s56-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/af83ji4wljdwf0gl4vqkn3d0s858s4lj-connman-1.36/lib  /nix/store/af83ji4wljdwf0gl4vqkn3d0s858s4lj-connman-1.36/bin  /nix/store/af83ji4wljdwf0gl4vqkn3d0s858s4lj-connman-1.36/sbin
patching script interpreter paths in /nix/store/af83ji4wljdwf0gl4vqkn3d0s858s4lj-connman-1.36
checking for references to /build in /nix/store/af83ji4wljdwf0gl4vqkn3d0s858s4lj-connman-1.36...
moving /nix/store/af83ji4wljdwf0gl4vqkn3d0s858s4lj-connman-1.36/sbin/* to /nix/store/af83ji4wljdwf0gl4vqkn3d0s858s4lj-connman-1.36/bin
/nix/store/af83ji4wljdwf0gl4vqkn3d0s858s4lj-connman-1.36


Accessibility changes to make extending the Toolkit easier to maintain.

These changes will allow people to maintain their extensions to the Toolkit without having to change accessibility each time they grab a new build.
Whenever we update the toolkit we have to go back and make these accessibility changes so it would be nice to have them made into the core so that we and others like us do not need to continuously change the core code.
The one class that is more than an accessibility change is GazeManager.cs which I reverted the Ray.Origin back to maintaining a reference. The functionality should be the same for existing users but if there is concern I understand ditching this change.  The benefit of having it saved is that you can override the GazeOrigin for custom gaze interactions.  We do so when allow users to draw with the manipulation gesture.

I'm not sure how I feel about a lot of these changes.
If there's problems in the core kit, why not submit a PR to get them addressed?

The changes are fairly custom and specific to our use cases.  For example, in the focus manager we do custom raycasts to determine if the gaze is within our circular platform and if not it disables certain layers that are visually masked by custom shaders yet still contain colliders.
I guess its more of a matter of Microsoft wants people extending their toolkit or not.  I personally think allowing extension gives the toolkit more flexibility and usefulness but understand it can also lead to more breaking changes.
In our case, it would keep us more involved.  We've only cherry picked a few updates over the past year (auto-discovery fix, keyboard.prefab, and that may be about it) but otherwise mostly stayed away from keeping the toolkit up to date because we customize it so much that updates become an ordeal.  If we were able to update without breaking each time we could stay more involve and perhaps contribute some of our changes as you suggest.

I'm definitely agree. I was only asking because there are a lot of major breaking changes here.

How is it breaking?  I mean it can lead to breaking changes down the road if these virtual or protected properties are changed but I don't think this change in and of itself would break anything.  What am I missing?

@markgrossnickle yeah you're right, my bad.

I still don't understand why you can't just submit request changes for the changes you've had to make to the classes.

In some cases I think we can. In others they are pretty custom as mentioned above.  For now I just want to get the toolkit in a spot where we can stay up to date without it breaking us each time. Then I can start contributing.

@markgrossnickle could you update this to address the conflicts please?

Requests addressed here:  https://github.com/Microsoft/MixedRealityToolkit-Unity/pull/1557
Closing this request.


opcua-commander: init at 0.37.0

Description of changes

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

On darwin:
opcua-commander> Running phase: buildPhase
opcua-commander> ✘ [ERROR] No loader is configured for ".node" files: node_modules/fsevents/fsevents.node
opcua-commander>     node_modules/fsevents/fsevents.js:13:23:
opcua-commander>       13 │ const Native = require("./fsevents.node");
opcua-commander>          ╵                        ~~~~~~~~~~~~~~~~~
opcua-commander> 1 error

Unfortunately I don't have any macOS machine with which to test the darwin builds.
I've tried with nix-build -A opcua-commander --arg crossSystem '{ config = "aarch64-darwin"; }', but I get that nodejs is marked as broken (which seems a bit strange...). Any tips?
I could mark the package with platforms = ["x86_64-linux"], I have never used the application outside Linux (x86_64), I'm not sure if it is supported in other platforms.

Result of nixpkgs-review pr 298088 run on x86_64-linux 1

1 package built:

opcua-commander

@jonboh Thanks for contribution!


[Service Bus] Misc API changes from API review

https://apiview.dev/Assemblies/Review/6af850ed7eb04843a6897afbe13cdd28
Based on API review do the following:

Change from Instant to OffsetDateTime
Add viaTopicName in ServiceBusSenderClientBuilder
Remove ServiceBusReceiverClientBuilder.maxAutoLockRenewalDuration
Change from RuntimeInfo -> RuntimeProperties

Remove ScheduledMessageCount from the SubscriptionRuntimeProperties.
Add ScheduledMessageCount to the TopicRuntimeProperties

/azp run java - servicebus - tests

/check-enforcer reset


vendor_assets not copied during build

When trying to use Glyphicons they do not appear, and I see this in the console:
GET file:///{path to build}/build/fonts/glyphicons-halflings-regular.woff net::ERR_FILE_NOT_FOUND

So I am trying to copy Glyphicons font assets from vendor/bootrap/dist/fonts to build/vendor/bootstrap/dist/fonts.  So I updated build.config.js to:
 vendor_files: {
    js: [
      'vendor/angular/angular.js',
      'vendor/angular-bootstrap/ui-bootstrap-tpls.min.js',
      'vendor/placeholders/angular-placeholders-0.0.1-SNAPSHOT.min.js',
      'vendor/angular-ui-router/release/angular-ui-router.js',
      'vendor/angular-ui-utils/modules/route/route.js'
    ],
    css: [
    ],
   // add glyhpicons font paths here
    assets: [
      'vendor/boostrap/dist/fonts/glyphicons-halflings-regular.eot',
      'vendor/boostrap/dist/fonts/glyphicons-halflings-regular.svg',
      'vendor/boostrap/dist/fonts/glyphicons-halflings-regular.ttf',
      'vendor/boostrap/dist/fonts/glyphicons-halflings-regular.woff'
    ]
  }

However output from grunt watch shows the task does nothing:
Running "copy:build_vendor_assets" (copy) task

Running "copy:build_appjs" (copy) task
Copied 4 files

If this were to work I would then have added the path override to variables.less as:
 @icon-font-path: "../vendor/bootstrap/dist/fonts/";

So this is not working as expected, please advise if I am not understanding the usage correctly.

@RoboSparrow's fix worked great for me.


L7 policy breaks connectivity to hostport services

When Cilium (v1.8.2) is configured with a hostport service with an ingress L7 policy applied, then a pod on a remote node attempts to access the hostport, the connection is dropped.
From recollection it's the reply packet that fails to reach the node which originates the connection.
If two proxies are involved, then the first will end up sending a 503 error to the client because the egress proxy upstream connection is subject to this issue. If one proxy is involved (at the destination), the traffic will simply be dropped.
PR #12599 introduces a new (currently quarantined) connectivity check to reproduce this failure case.
Tasks:

[ ] Investigate issue with kube-proxy
[ ] Investigate issue with kube-proxy-replacement

Possible lead for follow-up:
https://github.com/cilium/cilium/blob/3996e5a1a36e60674585173a2cadaa973ab93b9f/bpf/bpf_lxc.c#L1118-L1129
This redirection back to the egress proxy is occuring prior to hitting the rev_nat logic.


Pick could reorder

Hi, if I use .pick() on schema it could reorder fields by order given in the pick call not by original order.

@mariusrak Have you checked to see whether other pick functions such as lodash preserve the order?
Also, JavaScript prior to ES2015 doesn't guarantee object key iteration order for any objects, and even with ES2015 it is not 100% guaranteed. So I generally wouldn't not rely on it.
That being said, a few aspects of SimpleSchema do act differently depending on key order, and in general I believe a schema object would always have a guaranteed key iteration order with ES2015.
I am not sure whether I think this should be "fixed", though. If pick were updated to keep the same order, it would be impossible to pick keys in a different order. Right now, you can pick in the same order or a new order by choosing how you order the key names in the array. So maybe this just needs to be documented but not changed?

I'm not sure whether I understand. I wanted to pick keys in different order, but even when I provided keys in order different than in original schema, they were ordered by original schema not by new order.

Oh I see.

Well originally I thought it is a feature request. But you wrote

Right now, you can pick in the same order or a new order by choosing how you order the key names in the array. So maybe this just needs to be documented but not changed?

So I'm not sure how it should work. Maybe I'm just using it wrong. I use the simple-schema with uniforms package. I have schema from fields e.g.
{field1: String, field2: String, field3: String}

and I do
schema.pick('field3', 'field1')

I expect to see form with field3 first and field1 second. But they are ordered as was originally defined. This contradicts your claim. So I guess we did not understood each other?

@mariusrak No I wrote that from memory without checking. It does preserve the original order. I think the best solution to avoid any breaking changes would be to keep pick as is and add a pickInNewOrder (or whatever name people like) method that does what you are asking for.
In the meantime, you could write your own with something like this:
function pickInNewOrder(schema, ...fields) {
  const newSchema = {};

  for (const field of fields) {
    for (const key of this._schemaKeys) {
      if (key === field || key.indexOf(`${field}.`) === 0) {
        newSchema[key] = this._schema[key];
      }
    }
  }

  return schema._copyWithSchema(newSchema);
}

And call it like:
const newSchema = pickInNewOrder(schema, 'field3', 'field1')


merge package from arlac77/npm-package-template

package.json

chore(package<EMAIL_ADDRESS>
.travis.yml

chore(travis): remove node versions 10.10.0
chore(travis): add node versions 10.11

Codecov Report

Merging #361 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #361   +/-   ##
=======================================
  Coverage   83.33%   83.33%
=======================================
  Files           1        1
  Lines           6        6
=======================================
  Hits            5        5
  Misses          1        1

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ec05533...bcec618. Read the comment docs.

Coverage remained the same at 83.333% when pulling bcec618186befccdfd5aa8cbb1bb12bf9c345238 on template-sync-1 into ec05533239b56afc3d78485e5d6ceb00a1844039 on master.

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Upgrading devices to iOS 17 (official)

When iOS 17 is released (probably September), we'll want to upgrade at least one device to iOS 17.
iOS 17 physical iOS devices have an entirely new device connectively stack and therefore we had to build https://github.com/flutter/flutter/pull/131865 for it.
I'm not sure how many devices we should upgrade, but at least one.

This is not a ticket queue bug. Routing to devicelab.

/cc @yusuf-goog

@yusuf-goog @kentnguyen99 feel free to reprioritize this.

CL to move mac-40 from staging to prod: https://chrome-internal-review.googlesource.com/c/infradata/config/+/6934900

all listed devices have been upgraded.

Everything is looking good. Closing.


error message improvement

On the first check:
 PURL1: Persistent URL

Description
    This check verifies if the ontology has a persistent URL (w3id, purl, DOI, or a W3C URL)
Explanation
    Ontology URI is not using a persistent id. We checked w3id, purl, DOI and W3C

The explanation is making a strong statement.
Better: the ontology URI is not part of a known register of URIs. We checked w3id, purl, DOI and W3C
And by the way the persistency cannot be determined only by the domain. Both purl and DOI and w3id are redirection services and therefore do not care the persistency. That is the real url owner.

Thanks for your suggestions!
I agree in that we can improve the wording of the check.
However, purl and w3id do care about the persistence of the URL. It's the
only thing that they ensure (purl stands for permanent urls, if I am not
wrong). They do not check that the URI being redirected to is persistent,
or that it resolves (is there something truly persistent on the web?). But
the URL they provide does not change, hence we consider it persistent, and
a good practice.
A separate check addresses whether the URI resolves in fact to a semantic
artefact.
El mar., 17 oct. 2023 3:47 p. m., Bert Van Nuffelen <
@.***> escribió:

On the first check:
PURL1: Persistent URL
Description
This check verifies if the ontology has a persistent URL (w3id, purl, DOI, or a W3C URL)
Explanation
Ontology URI is not using a persistent id. We checked w3id, purl, DOI and W3C
The explanation is making a strong statement.
Better: the ontology URI is not part of a known register of URIs. We
checked w3id, purl, DOI and W3C
And by the way the persistency cannot be determined only by the domain.
Both purl and DOI and w3id are redirection services and therefore do not
care the persistency. That is the real url owner.
—
Reply to this email directly, view it on GitHub
https://github.com/oeg-upm/fair_ontologies/issues/106, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AALTIGT7IC444MCLDXXJ3TDX72EARAVCNFSM6AAAAAA6D4KZNOVHI2DSMVQWIX3LMV43ASLTON2WKOZRHE2DONBYGA4TGOI
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

I agree that these namespaces have the intention and objective of persistence as basis.
My annoyance is that this is not necessary the ambition of those who publishes on those domains.
It occurs too much that the development behind the URI is stalled and restarted on a different place with different persistent URI's.
And that breaks the whole idea of persistency.
I know no test can proof that this is the case, and that this implemented test (with the additional tests you refer to) are a necessary check to drive towards persistency.
Therefore as an additional suggestion to promote the efforts of organisations that put long term efforts to maintain persistent URIs I would suggest you also collect these namespaces and include that in your validations. Within the EU there are many public administrations putting a lot of effort into it. By including these in the list you create also an acknowledgement of the effort spend by these organisations.
To name a few:

Publications Office of EU: http://publications.europa.eu/resource
EU wide: https://data.europa.eu/URI.html
Regional efforts: https://data.vlaanderen.be

Thanks, I think you make a fair point. We can expand the list pointing to these efforts as well. There is another issue to include governmental URLs from a data service in Australia. I am going to have a look at these resources and see how to incorporate them


Guide data/Manual Recording issue with padding less than show length

Not positive this is just my setup or an issue with V<IP_ADDRESS>6 but do not have this issue with V<IP_ADDRESS>6
Reference: https://forums.sagetv.com/forums/showthread.php?t=67158
Steps to recreate issue:
Find 3x 1 hr shows back to back on same channel
Manual record the second show starting 1 min later and ending 1 min early
Manual record the first show starting 1 min early and ending 1 min later
Manual record the third show starting 1 min early and ending 1 min later
All looked well until it was time for the second show to record.
The Guide then had blank for the 2nd show (could not even get focus there) and the first show just continued recording but looks like end time was null.
Saw the following in the logs:
Fri 3/17 21:01:00.824 [Scheduler@1cabdc1] Removing from schedule cause expired FA[stationID=16374 Tucker Carlson Tonight time=Fri 3/17 20:00:00.000 dur=1:01:00]
Fri 3/17 21:01:02.121 [Timer-4@10e6617] Added:ManualRecord[A[65203366,65203365,"Tucker Carlson Tonight",16374@0317.20:00,61,T V] time=Fri 3/17 20:00:00.000 dur=1:01:00]
Fri 3/17 21:01:02.121 [Timer-4@10e6617] Modified EPG data linkage for existing manual record: ManualRecord[A[65203366,65203365,"Tucker Carlson Tonight",16374@0317.20:00,61,T V] time=Fri 3/17 20:00:00.000 dur=1:01:00] overlapAir=A[65203366,65203365,"Tucker Carlson Tonight",16374@0317.20:00,61,T V]
Fri 3/17 21:01:02.122 [Timer-4@10e6617] Updating metadata w/ new Airing for existing recording from: MediaFile[id=65203316 A[65123791,65123718,"Tucker Carlson Tonight",16374@0317.20:00,60,T] mask=TV host=HTPC-BR encodedBy=Hauppauge WinTV 418 Video Capture DVD Standard Play format=MPEG2-PS 0:00:00 0 kbps [#0 Video[MPEG2-Video 29.97 fps 720x480 4:3 6400 kbps interlaced]#1 Audio[MP2 48000 Hz 2 channels 384 kbps]{SeriesInfoID=2551749, DefaultBackground=null}] C:\SageTV32bit\SageTV\Video\TuckerCarlsonTonight-65123791-0.mpg, Seg0[Fri 3/17 20:00:00.001-Fri 3/17 21:01:00.001]] to be A[65203366,65203365,"Tucker Carlson Tonight",16374@0317.20:00,61,T V]
Fri 3/17 21:01:04.671 [Seeker@1dc1ac1] Enforcing keep at most limits for the files...
Fri 3/17 21:01:04.677 [Scheduler@1cabdc1] # Airs=9708

I doubt a bug like this would have crept in during that time period. My first guess would be that the EPG data for this program was getting updated close in time to when the recording was occurring...and the re-creation of the linked manual records was causing some issue.
Easiest thing to try to fix this is to set repair_epg_manual_record_mismatches=false in the Sage.properties file. Then the logic from what you see in the logs won't get executed (that logic was never bulletproof...but was supposed to help some types of schedule changes that can occur).

Thanks
I'll set repair_epg_manual_record_mismatches=false
FYI this did happen multiple times during the week I had V<IP_ADDRESS>6 running but do not see the issue with V9.2.1 which I have on other SageTV Servers.

Yeah, I'd need to see a complete log file from when it had the issue to determine if it had to do with correlation in time to an EPG update or if it's something else I'm not aware of.

here is the log file
sagetv_7.zip

The only thing I could see with a quick review that could possibly even be related is this change:
https://github.com/google/sagetv/commit/620916f07cd0fd4e50b774ac944f2ce8e74f5771
It involves fast mux switching when transcoding.  Graywolf, are you transcoding with your setup?

Let me explain what some of those logs mean.
This first one is when the Scheduler detects it is past the end of it's program (i.e. expired), which is correct since this one ended at 21:01.
Fri 3/17 21:01:00.824 [Scheduler@1cabdc1] Removing from schedule cause expired FA[stationID=16374 Tucker Carlson Tonight time=Fri 3/17 20:00:00.000 dur=1:01:00]
This is the database indicating a new ManualRecord was added (can happen from a lot of callsites).
Fri 3/17 21:01:02.121 [Timer-4@10e6617] Added:ManualRecord[A[65203366,65203365,"Tucker Carlson Tonight",16374@0317.20:00,61,T V] time=Fri 3/17 20:00:00.000 dur=1:01:00]
This is a very unique entry. This is when AddAiring in the database is invoked and that new Airing will modify the start/stop times of a program (which causes existing Airing objects that overlap w/ it to be removed..the database will not allow overlapping Airing on a Channel). It then deletes existing ManualRecords attached to that Airing and recreates them attached to the new Airing.
Fri 3/17 21:01:02.121 [Timer-4@10e6617] Modified EPG data linkage for existing manual record: ManualRecord[A[65203366,65203365,"Tucker Carlson Tonight",16374@0317.20:00,61,T V] time=Fri 3/17 20:00:00.000 dur=1:01:00] overlapAir=A[65203366,65203365,"Tucker Carlson Tonight",16374@0317.20:00,61,T V]
So this would only occur if something called AddAiring for the program "Tucker Carlson Tonight" with a 61 minute duration at 8pm.  There's only 3 ways that AddAiring can get invoked.

EPG updates (but your log shows no CPU usage on the EPG thread during the error, so this can be ruled out)
MediaFile imports; but these never attach themselves to Channel objects unless they are linking to an already existing Airing, and this one has a Channel.
The SageTV API call for AddAiring which is never used by SageTV's STV...but is used by various plugins/extensions.

Because of that..my guess is #3, which means I don't know anything about that code. :)
This is also running on a Thread called "Timer-X"..which I know I'd never use a Timer in SageTV for something like this...but it's something that would definitely happen in a plugin in order to update some information in the database at a specific time (like when a recording ended).
I know you went to a different version and had the problem...went back and it went away...but I'm guessing it was just coincidence with it occurring.
ALSO, PLEASE DON'T SET repair_epg_manual_record_mismatches=false...as after I've looked at the code more that means it'll just delete ManualRecords when Airings change...which will DEFINITELY reduce the WAF.

Thanks for additional information and I have reverted to repair_epg_manual_record_mismatches=true

The only thing I could see with a quick review that could possibly even be related is this change: 620916f
It involves fast mux switching when transcoding. Graywolf, are you transcoding with your setup?

No transcoding.


Everyone injection

If you ping everyone or any other role that you are not supposed to be pinging in your original message, the bot will ping it when reuploading.

Good evening.
Thanks for noting this problem. I've fixed the issue and now the bot won't resend role mentions and everyone pings but you can still ping channels and individual users.
The commit for this fix is: 303aa2800913d38e8645f08ccbbb4fa6aa55966c


Document and index HAS

The problem
It's not even mentioned. Seen in this StackOverflow answer
Suggestions
Investigate it and add something in the NativeCall page or independently.

Yeah I keep forgetting about it, think I can't implement something and put it aside, then remember again when I don't have time.

Well, you don't need to do it yourself... We'll just leave it there for
now.

A source of inspiration from another ticket: https://stackoverflow.com/questions/50723156/how-to-declare-native-array-of-fixed-size-in-perl-6/50745483#50745483


Stresstesting data-collection

Stress Test 03 (2020-03-13)
Setup
Computer: Lenovo U31-70 (Intel Core i5-5200U, 8GB RAM, 256GB SSD, NVIDIA GeForce 920 A)
OS: Ubuntu 19.04 LTS
Environment: Docker with 4 worker
Commit: 61f8fe8a7218145add55a0d627cd18e59665ddda
Projects: projects-test.csv
General Statistics
A total of 196 projects were processed with a total App execution time of 644.476 minutes.
142191 refactoring instances were found in total.
169260 stable instances were found in total.

103097 stablecommit instances were found for threshold 15
37194 stablecommit instances were found for threshold 20
13253 stablecommit instances were found for threshold 25
8013 stablecommit instances were found for threshold 30
4117 stablecommit instances were found for threshold 35
1841 stablecommit instances were found for threshold 40
1045 stablecommit instances were found for threshold 45
700 stablecommit instances were found for threshold 50

Exceptions
24 exceptions occurred during runtime, 4 of these exceptions were unique.

4 java.lang.RuntimeException: occurred during runtime.
17 java.util.concurrent.TimeoutException: occurred during runtime. #132
1 javax.persistence.PersistenceException: occurred during runtime.  #127
2 org.hibernate.TransactionException: occurred during runtime.  #127

Errors
489 errors occurred during runtime, 11 of these errors were at unique places.

3 errors at java.lang.OutOfMemoryError: occurred during runtime.
335 errors at App:209 occurred during runtime.
1 errors at App:219 occurred during runtime.  #127
17 errors at CKUtils:36 occurred during runtime.  #132
5 errors at RefactoringAnalyzer:129 occurred during runtime.
12 errors at RefactoringAnalyzer:195 occurred during runtime.
4 errors at RefactoringAnalyzer:81 occurred during runtime.
4 errors at RefactoringAnalyzer:82 occurred during runtime.
106 errors at RefactoringAnalyzer:94 occurred during runtime. (#133)
1 errors at RunQueue:101 occurred during runtime. #127
2 errors at SqlExceptionHelper:142 occurred during runtime.  #127

Detailed Statistics
In total 87053 commits were processed in 37714584 milliseconds, thus the average time is 433 milliseconds.
The fastest commit was processed in ** 1  millisecond(s)** with id(s):

e7bb7b33348d7f5522ff326137d422fd5130bc2b
9b5168bae1a13b5500acdbbed1ae8b6d47568f8a
6fb882e41a372e56aed45a0d87f2efdb4dd93605
4ff5046565b6c54afd93528974be723315e215d6
df7c71257224a2a827fbb78066848a8175a236cb
4349bae6a3efe26804fe1eb3130fae7feef460ba
0b3ba883732965928b4700b16d26b8d9d8d71672
762e9db2e819e64981ae6b26ced88fa207a2d3c5
2b80a990a8bc77b8fa093800094ceb0640c58673
a9d4579adfbef4431742b7ac577d2c3bc21182f2
e64fb49ff5b238c5baec4fc856a26b9948fbd865
eb37b2fb8ce3b2747a31d42c495b5c500b63b7f0
534dbe4b43a01dacd29bdefa1f5edceddc22f7b8
3a61b46a4473064aabf03b1bc33d04daca072d07
9ea6b3ed7a290df7c7ced61e80fa2d51ad52e194
9024d31161c152c6b407336dd1307008eb35c10b
5cd061ad8577d040a2dd30cdc0c9661ff69732fe
d0ab9026c2a32e8ed2c4243eda20d7cddfeb11bc
fac3f490d42f3a2e05feb4211e0da3b77ca28800
a546721792b70e9fa3184c170204602b9412bead
9778ff6392aa90ed5b866ed3092854392f936d8a
70f3efdc8d05c5a99b4ca17cd226687271d29a6e
d38a0e327b932e784b00e6a955595e3e51809d76
3f9d60308731fc43bbed774842e6774a1462f004
6b2090fefbb3283d1d8b27d68899d2f8b2e06735
ff45088f0e00e3029227867ebccc2db47a58848c
5b811e41f601b421f503f46c7b5cc8b1ad207ce2
0ad0c40d5c269fe8096059a5cf99c477b5bd0143
7850890ec7c8ed7340b5d9857c7a38f6b24fb544
3745b3f95f5a931090edec56ebbfdc494c958118
fd31f4fe3d84c17970459f5665cbc16c37c9df91
f250ee1411c220d6518e1a3c0cd54dac65864763
ac5fd2637a6406ccd81fd2e5421cf1bd17a2a54b
9bffa2d84d129f2595b8f2bd77fec9d5115559a0
0c63adc6d2249dc5a34b1f7f54b5f506618e799c
8906429fbf6237aa502d93c894975f8a97c1c11c
816c3f20cc8b56ccf68ca0dc796c053a54f32f96
aa4d4c57d6687b3101fd7ee94d9f9fc0500d53bb
12700aba8256882f82c4997d0745954daf21a5cb
93ff8936541460dd7f3bdb34e0d7a8b972ff4e80
83aae7263ff6b5bc59bcee5442aba8295890305e
b0f4c1450cc89abefb8e6434079cc43889efc538
566ca1f930f81b7635956e07eae31aa681b7d8d1
8db3cfef81994ebd549a68e7f97712470e61fbdd
aa264f5a4dcb66bf5cc458e423fa52ac504ceea7
4eee2d43e68d0a951b51ba4124653c4be9d79d0d
b32c467031b2be3b148f98d6d72f5bc8ee584cbf
fd8720cd316c0c7a4226ed52e825825de0fe7277
1439e8e4a5a966ba3fa38c2771d5c5bc3c46ba31
a309ee7fd0626cc23032e9794e494a1e7241a446
a74e1fbe49512e6c29d435f840a638300fa7282e
6d48f5f75739afd222667da62caf79c13125d97f
ae701dda44cb7bdeea47a0aa7752df1964f55af0
b4fee6e645c412abc57a272522b219167fbe788a
b9cc12ad36dfceefaa6a00e6c0d7f56162e4817e
f80bc4700abc5639751c6bd3defbdb99dcd16f47
352eb7aef56b46d9474d8bc1ab452bab05ea104c
0d744ae7dfa091c3f70d6b686a728d220fbdce8b
6abff6393082881c5f2f917938d435b6b20c4163
a17c5d1604d4ada1bc38b327c7bcac07573ca035
4a57535bb336066b5f808df9831b6e318334f7ef
40883f7f0b1f29eb5c13a56d9eab43e84900829f
The slowest commit was processed in ** 166220  milliseconds** with id(s):

7130065fcd39fc3ff9723f98481bcd4e31c5b58b

Log Files
stresstest_03_logs.zip
Stress Test 02 (2020-03-12)
Setup
Computer: Lenovo U31-70 (Intel Core i5-5200U, 8GB RAM, 256GB SSD, NVIDIA GeForce 920 A)
OS: Ubuntu 19.04 LTS
Environment: Docker with 3 worker
Commit: d35661afcf4ef646ebf3b742ca64b724fa850e1d
General Statistics
A total of 196 projects were processed with a total App execution time of 611.741 minutes.
141616 refactoring instances were found in total.
141048 stable instances were found in total.

89377 stablecommit instances were found for threshold 15
31538 stablecommit instances were found for threshold 20
9459 stablecommit instances were found for threshold 25
5337 stablecommit instances were found for threshold 30
2716 stablecommit instances were found for threshold 35
1221 stablecommit instances were found for threshold 40
700 stablecommit instances were found for threshold 45
700 stablecommit instances were found for threshold 50

Exceptions
245 exceptions occurred during runtime, 4 of these exceptions were unique

239 java.lang.NullPointerException: occured during runtime.  #119
4 java.lang.RuntimeException: occured during runtime.
1 javax.persistence.PersistenceException: occured during runtime.
1 org.hibernate.TransactionException: occured during runtime. #127

Errors
1243 errors occurred during runtime, 12 of these errors were at unique places

3 Errors at java.lang.OutOfMemoryError: occured during runtime.
314 Errors at App:169 occured during runtime.
5 Errors at App:179 occured during runtime.
239 Errors at ProcessMetricsCollector:165 occured during runtime. #119
18 Errors at ProcessMetricsCollector:36 occured during runtime.
395 Errors at RefactoringAnalyzer:193 occured during runtime.
4 Errors at RefactoringAnalyzer:81 occured during runtime.
4 Errors at RefactoringAnalyzer:82 occured during runtime.
106 Errors at RefactoringAnalyzer:94 occured during runtime.
153 Errors at RunQueue:67 occured during runtime. #124
1 Errors at RunQueue:89 occured during runtime.
2 Errors at SqlExceptionHelper:142 occured during runtime.

Detailed Statistics
In total 86695 commits were processed in 35638469 milliseconds, thus the average time is 411 milliseconds.
The fastest commit was processed in  1  millisecond(s) with id(s):

e303ef6e3c75db61d634d20ee72b6d5fd14f699b
e7bb7b33348d7f5522ff326137d422fd5130bc2b
4a52ff2f36ed5a6e9f4b2b16bd60adf3957c7bfa
9b5168bae1a13b5500acdbbed1ae8b6d47568f8a
81b4b8745958324a808d92c806b01bd054cce99e
713e59b038b168ffc04b5984fe053767a58e4ab2
8b929e413da25b5cc9b94af2a53dda2462a8f895
3c488e922f56cb093b626b553d587b99f497666f
f57ec6572e71354c4fc2744342a9448b877a42a9
df7c71257224a2a827fbb78066848a8175a236cb
fc82a0cc136e52bd45526556b7921ef4e6d385d5
98cedaa00402d50dccbcc2562b1978e7b0351e6b
798731230a1427c43892f34c99208284c232c0f1
c778b78960b761bc3eef685a66991b2ca7c58593
e64fb49ff5b238c5baec4fc856a26b9948fbd865
eb37b2fb8ce3b2747a31d42c495b5c500b63b7f0
5cd061ad8577d040a2dd30cdc0c9661ff69732fe
9024d31161c152c6b407336dd1307008eb35c10b
0d78aafec222c97e86b96b562649232263edc585
90dd6a083436415ea94592a726fd810aff15a035
5e39d9a8fb5816b1b71fb79e4b5c8c9db43b94ac
d0ab9026c2a32e8ed2c4243eda20d7cddfeb11bc
fac3f490d42f3a2e05feb4211e0da3b77ca28800
58270dcd9a58a0f5ecf680c6878731e4e83f0708
dd06c24e49b316b3234f2898fec58238791188db
3e1a1583b70b7a8d07fa90b323682360689fb2c1
70f3efdc8d05c5a99b4ca17cd226687271d29a6e
6dd59754ebf1f88bf43e509c3dfe989c1a9ff8fa
cfc24bfc0f8ca17ba070241f045f36e789e859a4
a4ee3bf20afd6405dbc286e8dd017ab37f2ad244
ce58036cb257a256dcb992437068b4f0199ae82a
5a47e04b52fac3f975f2e7912afde6eae3e6c904
7669e92657eaef2b73e8f0e97de9171ee123e41e
c6cdac1a7acfa697f00b434a2179b1fb777d79f8
a74e1fbe49512e6c29d435f840a638300fa7282e
1e144a4ad9b526ec2358140059ca6724f0fa1bd5
76ec0da273975cfe54ae51ff25d0daa9436804ee
17f6220a90d64acee00757b6f8d0dc7f9b1db40d
aff49008d7e569a89ed27b363005f5dc4d0990c8
b4fee6e645c412abc57a272522b219167fbe788a
352eb7aef56b46d9474d8bc1ab452bab05ea104c
2e7c9e946f1b203c5ec9c8f78d35a80de6bbdb1e
a3fa7b6f01f47b62a664f5980037dcf593257ccc
a7e1dbab009d0502119fb03d23122470e7101651
4a57535bb336066b5f808df9831b6e318334f7ef
0d744ae7dfa091c3f70d6b686a728d220fbdce8b
bb6c6fd8528a9de45278455b026201959693ba24
f4a87e144aef5359732e3880a0c2e56886c08239

The slowest commit was processed in  176844  milliseconds with id(s):

7130065fcd39fc3ff9723f98481bcd4e31c5b58b

Exceptions
245 exceptions occurred during runtime, 4 of these exceptions were unique

239 java.lang.NullPointerException: occured during runtime.
4 java.lang.RuntimeException: occured during runtime.
1 javax.persistence.PersistenceException: occured during runtime.
1 org.hibernate.TransactionException: occured during runtime.

Errors
1243 errors occurred during runtime, 12 of these errors were at unique places

3 Errors at java.lang.OutOfMemoryError: occured during runtime.
314 Errors at App:169 occured during runtime.
5 Errors at App:179 occured during runtime.
239 Errors at ProcessMetricsCollector:165 occured during runtime.
18 Errors at ProcessMetricsCollector:36 occured during runtime.
395 Errors at RefactoringAnalyzer:193 occured during runtime.
4 Errors at RefactoringAnalyzer:81 occured during runtime.
4 Errors at RefactoringAnalyzer:82 occured during runtime.
106 Errors at RefactoringAnalyzer:94 occured during runtime.
153 Errors at RunQueue:67 occured during runtime.
1 Errors at RunQueue:89 occured during runtime.
2 Errors at SqlExceptionHelper:142 occured during runtime.

Log Files
logs_stresstest_02.zip
Stress Test 01 (2020-03-06)
I ran a first larger-scale test with 200 projects.
Setup
Computer: Lenovo U31-70 (Intel Core i5-5200U, 8GB RAM, 256GB SSD, NVIDIA GeForce 920 A)
OS: Ubuntu 19.04 LTS
Environment: Docker with 4 worker
Commit: 077a97778cbf3c26d75705529ad4aa28649c058f
Projects: projects-test.csv
Log Files
data-collection_INFO.log
data-collection_ERROR.log
incomplete terminal.log
Statistics

183 of 200 projects were finished
213052 refactoring instances
525 stable instances found
Total time of the run App of all four workers: 508.9 minutes

Exceptions

3 java.lang.RuntimeExceptions #96
1132 org.hibernate.exception.GenericJDBCException #97
31 JavaParserProblemExceptions #94
566 javax.persistence.PersistenceException
882 java.lang.IllegalArgumentException: Project already in the database #98
50 java.lang.IllegalArgumentException: No path found #93
1975 cases in which CK could find the file #92

Other

At one point I noticed that for one project the worker ran out of memory and thus the miner for it
crashed.

18 Errors at ProcessMetricsCollector:36 occured during runtime.

I don't understand which log is referenced here:
2020-03-12 12:36:36 ERROR ProcessMetricsCollector:36 CK failed to calculate metrics for /tmp/1584016576724-0/ on the commit 9051a6153e8905e6bb7e61ca07719b83753330b1 in the project: https://www.github.com/greenaddress/GreenBits.git with a timeout of 20 seconds.

5 Errors at App:179 occured during runtime.
4 Errors at RefactoringAnalyzer:81 occured during runtime.
4 Errors at RefactoringAnalyzer:82 occured during runtime.

These three errors are linked:
2020-03-12 10:35:50 ERROR App:179 Exception when collecting commit data:
java.lang.RuntimeException: RefactoringMiner finds a refactoring for class 'com.readystatesoftware.mapviewballoons.BalloonItemizedOverlay', but we can't find it in DiffEntry: 'MOVE_SOURCE_FOLDER'. Check RefactoringAnalyzer.java for reasons why this can happen.
	at refactoringml.RefactoringAnalyzer.collectCommitData(RefactoringAnalyzer.java:83) ~[refactoring-analyzer-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
	at refactoringml.App.run(App.java:163) [refactoring-analyzer-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
	at refactoringml.RunQueue.processRepository(RunQueue.java:86) [refactoring-analyzer-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
	at refactoringml.RunQueue.run(RunQueue.java:59) [refactoring-analyzer-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
	at refactoringml.RunQueue.main(RunQueue.java:42) [refactoring-analyzer-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]

Line 36 is the constructor! Makes no sense for the exception to be there. CKUtils.java is using the wrong class to declare log4j!! Just fixed it: https://github.com/refactoring-ai/predicting-refactoring-ml/commit/397100f3007f51b8a176c96475dfee9b4a8ad139
So, probably the first line of the exception trace is wrong (it's CKUtils:36)

153 Errors at RunQueue:67 occured during runtime.
please see issue #124

Great that the number of exceptions is going down!

Great that the number of exceptions is going down!

I am very happy about that, right now I am running another test with 1000 projects on my laptop to see if we can scale it up.

Oh give me a sec and I can push my PR that resolved the dB issues!! I’m
running one more test but it looks fine!
On Sat, 14 Mar 2020 at 13:05, Jan Gerling<EMAIL_ADDRESS>wrote:

Great that the number of exceptions is going down!
I am very happy about that, right now I am running another test with 1000
projects on my laptop to see if we can scale it up.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/refactoring-ai/predicting-refactoring-ml/issues/95#issuecomment-599048706,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAYTTGRP3EHL2ISQFBBDZDRHNXJRANCNFSM4LDJV7KA
.

--
Maurício Aniche
Delft University of Technology
http://www.mauricioaniche.com

Oh give me a sec and I can push my PR that resolved the dB issues!! I’m running one more test but it looks fine!
On Sat, 14 Mar 2020 at 13:05, Jan Gerling @.***> wrote: Great that the number of exceptions is going down! I am very happy about that, right now I am running another test with 1000 projects on my laptop to see if we can scale it up. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#95 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAYTTGRP3EHL2ISQFBBDZDRHNXJRANCNFSM4LDJV7KA .
-- -- Maurício Aniche Delft University of Technology http://www.mauricioaniche.com

I started it last night already... After some minor bug fixes.

Stress Test 03 (2020-03-13)
Setup
Computer: Lenovo U31-70 (Intel Core i5-5200U, 8GB RAM, 256GB SSD, NVIDIA GeForce 920 A)
OS: Ubuntu 19.04 LTS
Environment: Docker with 4 worker
Commit: 61f8fe8a7218145add55a0d627cd18e59665ddda
Projects: projects-test.csv
General Statistics
A total of 196 projects were processed with a total App execution time of 644.476 minutes.
142191 refactoring instances were found in total.
169260 stable instances were found in total.

103097 stablecommit instances were found for threshold 15
37194 stablecommit instances were found for threshold 20
13253 stablecommit instances were found for threshold 25
8013 stablecommit instances were found for threshold 30
4117 stablecommit instances were found for threshold 35
1841 stablecommit instances were found for threshold 40
1045 stablecommit instances were found for threshold 45
700 stablecommit instances were found for threshold 50

Exceptions
24 exceptions occurred during runtime, 4 of these exceptions were unique.

4 java.lang.RuntimeException: occurred during runtime.
17 java.util.concurrent.TimeoutException: occurred during runtime. #132
1 javax.persistence.PersistenceException: occurred during runtime.  #127
2 org.hibernate.TransactionException: occurred during runtime.  #127

Errors
489 errors occurred during runtime, 11 of these errors were at unique places.

3 errors at java.lang.OutOfMemoryError: occurred during runtime.
335 errors at App:209 occurred during runtime.
1 errors at App:219 occurred during runtime.  #127
17 errors at CKUtils:36 occurred during runtime.  #132
5 errors at RefactoringAnalyzer:129 occurred during runtime.
12 errors at RefactoringAnalyzer:195 occurred during runtime.
4 errors at RefactoringAnalyzer:81 occurred during runtime.
4 errors at RefactoringAnalyzer:82 occurred during runtime.
106 errors at RefactoringAnalyzer:94 occurred during runtime. (#133)
1 errors at RunQueue:101 occurred during runtime. #127
2 errors at SqlExceptionHelper:142 occurred during runtime.  #127

Detailed Statistics
In total 87053 commits were processed in 37714584 milliseconds, thus the average time is 433 milliseconds.
The fastest commit was processed in ** 1  millisecond(s)** with id(s):

e7bb7b33348d7f5522ff326137d422fd5130bc2b
9b5168bae1a13b5500acdbbed1ae8b6d47568f8a
6fb882e41a372e56aed45a0d87f2efdb4dd93605
4ff5046565b6c54afd93528974be723315e215d6
df7c71257224a2a827fbb78066848a8175a236cb
4349bae6a3efe26804fe1eb3130fae7feef460ba
0b3ba883732965928b4700b16d26b8d9d8d71672
762e9db2e819e64981ae6b26ced88fa207a2d3c5
2b80a990a8bc77b8fa093800094ceb0640c58673
a9d4579adfbef4431742b7ac577d2c3bc21182f2
e64fb49ff5b238c5baec4fc856a26b9948fbd865
eb37b2fb8ce3b2747a31d42c495b5c500b63b7f0
534dbe4b43a01dacd29bdefa1f5edceddc22f7b8
3a61b46a4473064aabf03b1bc33d04daca072d07
9ea6b3ed7a290df7c7ced61e80fa2d51ad52e194
9024d31161c152c6b407336dd1307008eb35c10b
5cd061ad8577d040a2dd30cdc0c9661ff69732fe
d0ab9026c2a32e8ed2c4243eda20d7cddfeb11bc
fac3f490d42f3a2e05feb4211e0da3b77ca28800
a546721792b70e9fa3184c170204602b9412bead
9778ff6392aa90ed5b866ed3092854392f936d8a
70f3efdc8d05c5a99b4ca17cd226687271d29a6e
d38a0e327b932e784b00e6a955595e3e51809d76
3f9d60308731fc43bbed774842e6774a1462f004
6b2090fefbb3283d1d8b27d68899d2f8b2e06735
ff45088f0e00e3029227867ebccc2db47a58848c
5b811e41f601b421f503f46c7b5cc8b1ad207ce2
0ad0c40d5c269fe8096059a5cf99c477b5bd0143
7850890ec7c8ed7340b5d9857c7a38f6b24fb544
3745b3f95f5a931090edec56ebbfdc494c958118
fd31f4fe3d84c17970459f5665cbc16c37c9df91
f250ee1411c220d6518e1a3c0cd54dac65864763
ac5fd2637a6406ccd81fd2e5421cf1bd17a2a54b
9bffa2d84d129f2595b8f2bd77fec9d5115559a0
0c63adc6d2249dc5a34b1f7f54b5f506618e799c
8906429fbf6237aa502d93c894975f8a97c1c11c
816c3f20cc8b56ccf68ca0dc796c053a54f32f96
aa4d4c57d6687b3101fd7ee94d9f9fc0500d53bb
12700aba8256882f82c4997d0745954daf21a5cb
93ff8936541460dd7f3bdb34e0d7a8b972ff4e80
83aae7263ff6b5bc59bcee5442aba8295890305e
b0f4c1450cc89abefb8e6434079cc43889efc538
566ca1f930f81b7635956e07eae31aa681b7d8d1
8db3cfef81994ebd549a68e7f97712470e61fbdd
aa264f5a4dcb66bf5cc458e423fa52ac504ceea7
4eee2d43e68d0a951b51ba4124653c4be9d79d0d
b32c467031b2be3b148f98d6d72f5bc8ee584cbf
fd8720cd316c0c7a4226ed52e825825de0fe7277
1439e8e4a5a966ba3fa38c2771d5c5bc3c46ba31
a309ee7fd0626cc23032e9794e494a1e7241a446
a74e1fbe49512e6c29d435f840a638300fa7282e
6d48f5f75739afd222667da62caf79c13125d97f
ae701dda44cb7bdeea47a0aa7752df1964f55af0
b4fee6e645c412abc57a272522b219167fbe788a
b9cc12ad36dfceefaa6a00e6c0d7f56162e4817e
f80bc4700abc5639751c6bd3defbdb99dcd16f47
352eb7aef56b46d9474d8bc1ab452bab05ea104c
0d744ae7dfa091c3f70d6b686a728d220fbdce8b
6abff6393082881c5f2f917938d435b6b20c4163
a17c5d1604d4ada1bc38b327c7bcac07573ca035
4a57535bb336066b5f808df9831b6e318334f7ef
40883f7f0b1f29eb5c13a56d9eab43e84900829f
The slowest commit was processed in ** 166220  milliseconds** with id(s):

7130065fcd39fc3ff9723f98481bcd4e31c5b58b

Log Files
stresstest_03_logs.zip
Stress Test 02 (2020-03-12)
Setup
Computer: Lenovo U31-70 (Intel Core i5-5200U, 8GB RAM, 256GB SSD, NVIDIA GeForce 920 A)
OS: Ubuntu 19.04 LTS
Environment: Docker with 3 worker
Commit: d35661afcf4ef646ebf3b742ca64b724fa850e1d
General Statistics
A total of 196 projects were processed with a total App execution time of 611.741 minutes.
141616 refactoring instances were found in total.
141048 stable instances were found in total.

89377 stablecommit instances were found for threshold 15
31538 stablecommit instances were found for threshold 20
9459 stablecommit instances were found for threshold 25
5337 stablecommit instances were found for threshold 30
2716 stablecommit instances were found for threshold 35
1221 stablecommit instances were found for threshold 40
700 stablecommit instances were found for threshold 45
700 stablecommit instances were found for threshold 50

Exceptions
245 exceptions occurred during runtime, 4 of these exceptions were unique

239 java.lang.NullPointerException: occured during runtime.  #119
4 java.lang.RuntimeException: occured during runtime.
1 javax.persistence.PersistenceException: occured during runtime.
1 org.hibernate.TransactionException: occured during runtime. #127

Errors
1243 errors occurred during runtime, 12 of these errors were at unique places

3 Errors at java.lang.OutOfMemoryError: occured during runtime.
314 Errors at App:169 occured during runtime.
5 Errors at App:179 occured during runtime.
239 Errors at ProcessMetricsCollector:165 occured during runtime. #119
18 Errors at ProcessMetricsCollector:36 occured during runtime.
395 Errors at RefactoringAnalyzer:193 occured during runtime.
4 Errors at RefactoringAnalyzer:81 occured during runtime.
4 Errors at RefactoringAnalyzer:82 occured during runtime.
106 Errors at RefactoringAnalyzer:94 occured during runtime.
153 Errors at RunQueue:67 occured during runtime. #124
1 Errors at RunQueue:89 occured during runtime.
2 Errors at SqlExceptionHelper:142 occured during runtime.

Detailed Statistics
In total 86695 commits were processed in 35638469 milliseconds, thus the average time is 411 milliseconds.
The fastest commit was processed in  1  millisecond(s) with id(s):

e303ef6e3c75db61d634d20ee72b6d5fd14f699b
e7bb7b33348d7f5522ff326137d422fd5130bc2b
4a52ff2f36ed5a6e9f4b2b16bd60adf3957c7bfa
9b5168bae1a13b5500acdbbed1ae8b6d47568f8a
81b4b8745958324a808d92c806b01bd054cce99e
713e59b038b168ffc04b5984fe053767a58e4ab2
8b929e413da25b5cc9b94af2a53dda2462a8f895
3c488e922f56cb093b626b553d587b99f497666f
f57ec6572e71354c4fc2744342a9448b877a42a9
df7c71257224a2a827fbb78066848a8175a236cb
fc82a0cc136e52bd45526556b7921ef4e6d385d5
98cedaa00402d50dccbcc2562b1978e7b0351e6b
798731230a1427c43892f34c99208284c232c0f1
c778b78960b761bc3eef685a66991b2ca7c58593
e64fb49ff5b238c5baec4fc856a26b9948fbd865
eb37b2fb8ce3b2747a31d42c495b5c500b63b7f0
5cd061ad8577d040a2dd30cdc0c9661ff69732fe
9024d31161c152c6b407336dd1307008eb35c10b
0d78aafec222c97e86b96b562649232263edc585
90dd6a083436415ea94592a726fd810aff15a035
5e39d9a8fb5816b1b71fb79e4b5c8c9db43b94ac
d0ab9026c2a32e8ed2c4243eda20d7cddfeb11bc
fac3f490d42f3a2e05feb4211e0da3b77ca28800
58270dcd9a58a0f5ecf680c6878731e4e83f0708
dd06c24e49b316b3234f2898fec58238791188db
3e1a1583b70b7a8d07fa90b323682360689fb2c1
70f3efdc8d05c5a99b4ca17cd226687271d29a6e
6dd59754ebf1f88bf43e509c3dfe989c1a9ff8fa
cfc24bfc0f8ca17ba070241f045f36e789e859a4
a4ee3bf20afd6405dbc286e8dd017ab37f2ad244
ce58036cb257a256dcb992437068b4f0199ae82a
5a47e04b52fac3f975f2e7912afde6eae3e6c904
7669e92657eaef2b73e8f0e97de9171ee123e41e
c6cdac1a7acfa697f00b434a2179b1fb777d79f8
a74e1fbe49512e6c29d435f840a638300fa7282e
1e144a4ad9b526ec2358140059ca6724f0fa1bd5
76ec0da273975cfe54ae51ff25d0daa9436804ee
17f6220a90d64acee00757b6f8d0dc7f9b1db40d
aff49008d7e569a89ed27b363005f5dc4d0990c8
b4fee6e645c412abc57a272522b219167fbe788a
352eb7aef56b46d9474d8bc1ab452bab05ea104c
2e7c9e946f1b203c5ec9c8f78d35a80de6bbdb1e
a3fa7b6f01f47b62a664f5980037dcf593257ccc
a7e1dbab009d0502119fb03d23122470e7101651
4a57535bb336066b5f808df9831b6e318334f7ef
0d744ae7dfa091c3f70d6b686a728d220fbdce8b
bb6c6fd8528a9de45278455b026201959693ba24
f4a87e144aef5359732e3880a0c2e56886c08239

The slowest commit was processed in  176844  milliseconds with id(s):

7130065fcd39fc3ff9723f98481bcd4e31c5b58b

Exceptions
245 exceptions occurred during runtime, 4 of these exceptions were unique

239 java.lang.NullPointerException: occured during runtime.
4 java.lang.RuntimeException: occured during runtime.
1 javax.persistence.PersistenceException: occured during runtime.
1 org.hibernate.TransactionException: occured during runtime.

Errors
1243 errors occurred during runtime, 12 of these errors were at unique places

3 Errors at java.lang.OutOfMemoryError: occured during runtime.
314 Errors at App:169 occured during runtime.
5 Errors at App:179 occured during runtime.
239 Errors at ProcessMetricsCollector:165 occured during runtime.
18 Errors at ProcessMetricsCollector:36 occured during runtime.
395 Errors at RefactoringAnalyzer:193 occured during runtime.
4 Errors at RefactoringAnalyzer:81 occured during runtime.
4 Errors at RefactoringAnalyzer:82 occured during runtime.
106 Errors at RefactoringAnalyzer:94 occured during runtime.
153 Errors at RunQueue:67 occured during runtime.
1 Errors at RunQueue:89 occured during runtime.
2 Errors at SqlExceptionHelper:142 occured during runtime.

Log Files
logs_stresstest_02.zip
Stress Test 01 (2020-03-06)
I ran a first larger-scale test with 200 projects.
Setup
Computer: Lenovo U31-70 (Intel Core i5-5200U, 8GB RAM, 256GB SSD, NVIDIA GeForce 920 A)
OS: Ubuntu 19.04 LTS
Environment: Docker with 4 worker
Commit: 077a97778cbf3c26d75705529ad4aa28649c058f
Projects: projects-test.csv
Log Files
data-collection_INFO.log
data-collection_ERROR.log
incomplete terminal.log
Statistics

183 of 200 projects were finished
213052 refactoring instances
525 stable instances found
Total time of the run App of all four workers: 508.9 minutes

Exceptions

3 java.lang.RuntimeExceptions #96
1132 org.hibernate.exception.GenericJDBCException #97
31 JavaParserProblemExceptions #94
566 javax.persistence.PersistenceException
882 java.lang.IllegalArgumentException: Project already in the database #98
50 java.lang.IllegalArgumentException: No path found #93
1975 cases in which CK could find the file #92

Other

At one point I noticed that for one project the worker ran out of memory and thus the miner for it
crashed.

Interesting new canary projects:

https://github.com/MirakelX/mirakel-android

many timeouts of RefactoringMiner for commits
some methods were not found by CK, but by Refactoringminer

Stress Test 04 (2020-03-14)
Setup
Computer: Lenovo U31-70 (Intel Core i5-5200U, 8GB RAM, 256GB SSD, NVIDIA GeForce 920 A)
OS: Ubuntu 19.04 LTS
Environment: Docker with 4 worker
Commit: f9b3c2533529a7b507dcbf6f4335f4f244af86c4
Projects: projects-test.csv
General Statistics
A total of 970 projects were processed with a total App execution time of 4870.77 minutes.
880021 refactoring instances were found in total.
694369 stable instances were found in total.

stablecommit instances were found for threshold 15
476135 stablecommit instances were found for threshold 20
stablecommit instances were found for threshold 25
138877 stablecommit instances were found for threshold 30
stablecommit instances were found for threshold 35
51894 stablecommit instances were found for threshold 40
stablecommit instances were found for threshold 45
27463 stablecommit instances were found for threshold 50

Exceptions
174 exceptions occurred during runtime, 9 of these exceptions were unique.

9 java.lang.IllegalArgumentException: occurred during runtime.
2 java.lang.NullPointerException: occurred during runtime.
10 java.lang.RuntimeException: occurred during runtime.
4 java.lang.StringIndexOutOfBoundsException: occurred during runtime.
45 java.util.concurrent.TimeoutException: occurred during runtime.
32 javax.persistence.PersistenceException: occurred during runtime.
5 org.eclipse.jgit.api.errors.TransportException: occurred during runtime. (Note: private or removed repositories )
35 org.hibernate.exception.GenericJDBCException: occurred during runtime.
64 org.hibernate.TransactionException: occurred during runtime.

Errors
4135 errors occurred during runtime, 15 of these errors were at unique places.

22 errors at java.lang.OutOfMemoryError: occurred during runtime.
3155 errors at App:209 occurred during runtime.
32 errors at App:219 occurred during runtime.
6 errors at App:255 occurred during runtime.
45 errors at CKUtils:36 occurred during runtime.
32 errors at Database:129 occurred during runtime.
32 errors at Database:135 occurred during runtime.
9 errors at ProcessMetricsCollector:161 occurred during runtime.
42 errors at RefactoringAnalyzer:129 occurred during runtime.
35 errors at RefactoringAnalyzer:195 occurred during runtime.
10 errors at RefactoringAnalyzer:81 occurred during runtime.
10 errors at RefactoringAnalyzer:82 occurred during runtime.
662 errors at RefactoringAnalyzer:94 occurred during runtime.
8 errors at RunQueue:113 occurred during runtime.
70 errors at SqlExceptionHelper:142 occurred during runtime.

Detailed Statistics from Project Statistics
In total 698242 commits were processed with an average time of .00697 minutes.
A total of 137080 production files and a total of 38013 test files with a total of 16359460 LOC were processed.
Detailed Statistics from Debug Logs
I noticed these statistics are incorrect #138.
In total 76258 commits were processed in 53421040 milliseconds, thus the average time is 700 milliseconds.
The fastest commit was processed in  1  millisecond(s) with id(s):

f0823ea56a3ea2b254a8182650d04650d171070e
37cb3e1fcb72e2aa21cfc0626f907e46bd719a4b
96dbb537ee14f992459a8359a113a78414addf9d
d0621c009512e7e3d2bb80eef5f3dc8e9013d156
153f2da408dd5244e78921387e03ee51f794e73d
15fd1760b18f6c20a7d5b432bca7bc70320ba626
b6b7458cd162a3e2fdab405d04e8c427f591c5fa
a525bc306e5bd68b44c9152c6e81186b82e4659d
3dc4af5c8a7647210ef121c0b9a8d893e81e8df7
abedb435628d5b090522680fd7976fdf29f8e7ef
53f8b98f06e1086895795c993e3c04c77e6c1f61
The slowest commit was processed in  380540  milliseconds with id(s):

b391600dcece42b77ae73cb6cb48c5ab56849c72

Logs
logs_stresstest_04.zip

Stress Test 05 (2020-03-16)
Logs
logs.zip
debug logs_1.zip
debug logs_2.zip
debug logs_3.zip
Setup
Computer: Lenovo U31-70 (Intel Core i5-5200U, 8GB RAM, 256GB SSD, NVIDIA GeForce 920 A)
OS: Ubuntu 19.04 LTS
Environment: Docker with 3 worker
Commit: bbe5f92e87325dc6c2acfaa21df1825648c686b2
Projects: projects-test.csv
Config:

500 projects
stable commit sizes: 15,20,25,30,35,40,45,50
timeout time for RMIner: 40 seconds
timeout for CK: 5 minutes

General Statistics
A total of 492 projects were processed with a total App execution time of 2949.54 minutes.
414184 refactoring instances were found in total.
472835 stable instances were found in total.

273897 stablecommit instances were found for threshold 15
109993 stablecommit instances were found for threshold 20
48797 stablecommit instances were found for threshold 25
19549 stablecommit instances were found for threshold 30
9519 stablecommit instances were found for threshold 35
5238 stablecommit instances were found for threshold 40
3704 stablecommit instances were found for threshold 45
2138 stablecommit instances were found for threshold 50

Exceptions
381 exceptions occurred during runtime, 3 of these exceptions were unique.

379 java.lang.IllegalArgumentException: occurred during runtime. #144 #148
1 java.lang.NullPointerException: occurred during runtime. (Bug in RMiner?)
1 org.eclipse.jgit.api.errors.TransportException: occurred during runtime. #145

Errors
898 errors occurred during runtime, 7 of these errors were at unique places.

5 errors at java.lang.OutOfMemoryError: occurred during runtime.
488 errors at App:212 occurred during runtime.
1 errors at App:260 occurred during runtime. (fatal?)
2 errors at ProcessMetricsCollector:161 occurred during runtime. #144
24 errors at RefactoringAnalyzer:163 occurred during runtime. #142
375 errors at RefactoringAnalyzer:76 occurred during runtime. #144
3 errors at RunQueue:113 occurred during runtime. (fatal) #148 #147

Detailed Statistics from Project Statistics
In total 282702 commits were processed with an average time of 625.80000 milliseconds. (lossy conversion)
A total of 66627 production files and a total of 15798 test files with a total of 7034989 LOC were processed.
Detailed Statistics from Debug Logs
In total 233654 commits were processed in 162051455 milliseconds, thus the average time is 693 milliseconds.
The fastest commit was processed in ** 1  millisecond(s) **
The slowest commit was processed in ** 39896360  milliseconds **
Analysis:


Consents purpose at authentication is not working

Describe the issue:
Consent purpose during authentication is not displayed.
How to reproduce:

Configure Consent purposes in carbon console
add an application with ask consents enabled and claims needed (optional or mandatory)

only the traditional oidc scope consent screen is displayed.
Expected behavior:
Display the consent screen with purposes for the user to be compliant with GDPR, CCPA, etc.
Environment information (Please complete the following information; remove  any unnecessary fields) :
IS 5.10.0, IS 5.11.0-alpha3

Optional Fields
Related issues:
N/A
Suggested labels:
N/A

Hi @geve82
The consent purposes defined from carbon console are for consent capturing during user registration scenarios. Identity server currently do not have the support for managing application-side consent requirement. If this is to be implemented at the identity server side, it will require customizing the authentication flow. You also have the option to handle it at the application side and can use the product's rest API to manage application side consents


SqfliteDatabaseException when calling insertOnConflictUpdate

When calling insertOnConflictUpdate i am getting the error below:
Not sure the reason for this error?
 Exception has occurred. SqfliteDatabaseException (DatabaseException(near "ON": syntax error (code 1 SQLITE_ERROR): ,  while compiling: INSERT INTO categories (id, category, colour) VALUES (?, ?, ?) ON CONFLICT(id) DO UPDATE SET id = ?,  category = ?, colour = ?) sql 'INSERT INTO categories (id, category, colour) VALUES (?, ?, ?)  ON CONFLICT(id) DO UPDATE SET id = ?, category = ?, colour = ?' args [1, Shoes, #5b426c, 1, Shoes, #5b426c]})
This only happens when there is a conflicting row in the database?
This is the method I am calling:
  Future insertCategory(Insertable<Category> category) =>  into(categories).insertOnConflictUpdate(category);
Libraries and versions:

moor: ^3.0.2
moor_ffi: ^0.5.0
moor_flutter: ^3.0.0`

What OS/Version? See https://github.com/simolus3/moor/issues/549#issuecomment-625246229

What OS/Version? See #549 (comment)

This is running on Android 10. I have not tested on iOS yet?

moor_flutter: ^3.0.0

You need to get rid of that dependency, see the issue I linked.

Yes, remove the moor_flutter dependency and use a VmDatabase instead of a FlutterQueryExecutor. That one uses the latest sqlite version on Android. Let me know if you run into any issues with that approach, thanks!

iam workin with sqflite: ^2.2.8+4
i have erro in near "ON": syntax error
E/flutter ( 9325): [ERROR:flutter/runtime/dart_vm_initializer.cc(41)] Unhandled Exception: DatabaseException(near "ON": syntax error (code 1): , while compiling: INSERT OR REPLACE INTO paycode
pleass hellp me!!!!


argument correction

Thank you for the excellent workshop last week.  When I tried to use workshop_colab.ipynb today, I found that EmbedAlignConstrainedScore() returned error messages.
I think this error was caused by the recent modification about the random seed settings. When I changed  the argument of ConstrainedEmbedMultipleConfs from randomSeed=randomseed to randomseed=randomseed, it seems to work well again.
I hope this would be helpful.

Hi @magattaca
Yes, this unfortunately broke due to a new PR that I pushed today, sorry! I just pushed a hotfix a few minutes ago before seeing your PR - so this is already fixed, but thank you very much for reporting and for taking the time to write a PR!


setting up environment variable

I followed the guide provided, Using ros-melodic-desktop-full, and gurobi both are working fine.
after "wstool merge .........." command I entered "wstool update" but after that no errors showed.
my workspace is in home directory but i can not find "/devel/setup.bash" in there.
so I got error
bash: /home/mrp/ws/devel/setup.bash: No such file or directory
Can you please tell me PATH_TO_YOUR_WS should appear after compiled right? or it will be in any other location?
(I searched devel/setup.bash every folder under /home/mrp/ws.)
Apart from that for the final simulation, NVIDIA GEFORCE 920M is enough?

Hi @Ganeshgng,
Did you compile the workspace? The devel folder will only appear once you compile the workspace using catkin build.
So the commands would be something like:
cd /home/mrp/ws/
catkin build
And then you should be able to do source /home/mrp/ws/devel/setup.bash in the bashrc
And yes,  NVIDIA GEFORCE 920M should be enough
Hope this helps!

Thanks for the reply, @jtorde
yeah I figured out and its working, built success, no errors.
Eventhough I added "source /home/mrp/ws/devel/setup.bash" not working. showed errors.
so I added "source /home/mrp/ws/devel/setup.bash" in the all five terminals before run the roslaunch, and it works.
gazebo.desktop is not responding at the end, taking too much time.
So I can not see the simulation,
I have Core i7 6th Gen, 8 GB RAM, 920M NVIDIA GEFORCE.
But I am trying with virtual machine gave 6GB RAM for VM, and assigned GPU as well.
So it might be the issue I guess.
Please close this issue.

Hi, @jtorde
Can you share what is the exact PC requirments(You tested) for Software Simulation? (Processor, RAM, GPU)
I am able to run the FASTER with an aerial robot and FASTER with a ground robot. But its loading too much.
My simulation is way slower than your simulation(https://youtu.be/L13k44-krcc).
Is there any settings I should change to get faster simulation??
May I please know how to change gazebo worlds? Now I am only testing with Forest environment.

Dear @jtorde,
I am trying to reproduce the results produced and evaluate your great work.
I am new to this, I tried several plots on gazebo plotting utility, and exploring the FASTER.
How can I get the logs of FASTER STATS?, Is this option available in your code?
can you suggest a way how you got the statistics results for Faster given in the research paper.
I will be grateful if you can share me this information


Operator SDK installs resources in the same namespace as the operator instead of the CRD namespace.

When deploying a Kubernetes operator using the Operator SDK, resources such as services and deployments are installed in the namespace of the operator (system namespace), rather than in the namespace specified for the CRD. This behavior occurs specifically when the CRD is installed via a Kubernetes deployment.
Expected Behavior:
Resources created by the operator, such as services and deployments, should be installed in the same namespace as the CRD, as specified during its deployment.

helm release is deployed in test ns but the resources are getting dpeloyed in system namespace. Technically resources should also be deployed in test namespace as CRD and helm release.
Additional Information:

This issue does not occur when running the operator directly on a system and connecting to the Kubernetes cluster, as resources are deployed in the respective namespace as the CRD.
The discrepancy in namespace deployment may lead to operational challenges and misconfiguration, especially in multi-tenant environments where namespace isolation is crucial.

Type of question
General operator-related help
Environment
Operator type:
golang
Kubernetes cluster type:
docker kubernetes
$ operator-sdk version
operator-sdk version: "v1.34.1", commit: "edaed1e5057db0349568e0b02df3743051b54e68", kubernetes version: "1.28.0", go version: "go1.21.7", GOOS: "darwin", GOARCH: "amd64"
$ go version (if language is Go)
go version go1.22.1 darwin/amd64
$ kubectl version
Client Version: v1.29.1
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.29.1
Any help would be highly appreciated

closing this ticket it an issue with helm and not operator SDK. https://github.com/helm/helm/issues/12931


Extract the RLP and remove go-ethereum dependency

Closes: #221
Description
This PR extracts the RLP implementation of the go-etheruem package.
It uses git subtree to include the repository and allow updates with the upstream branch. The contents were modified to only include the RLP implementation and remove all the unnecessary files.
I was trying to use git submodule but I had problems due to the fact that it only referenced a whole subrepo as a commit reference, but that commit wasn't really pushed to the ethereum repo for obvious reasons.
DOD:

[ ] Implemented
[ ] Released

For contributor use:

[x] Targeted PR against master branch
[x] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[x] Code follows the standards mentioned here.
[x] Updated relevant documentation
[x] Re-reviewed Files changed in the Github PR explorer
[x] Added appropriate labels

@sideninja you mind if I take it over and finish it ?)

this looks like done pretty much though )

@nozim it's pretty much done, but I wanted to make sure everything was correct but just then didn't have time. I would say making sure this way is the right way.

Sure @sideninja . Any suggestions are mosr welcome.  I'll add prometheus metrics in following PR.

I think cutting dependency while keeping same functionality is already good for this scope. So should be good to merge :)


[#6741] Update projects to .Net 8

Addresses #6741
#minor
Description
This PR updates the test projects, the test bots, and the CI pipelines to target .NET 8.
All these changes need to be done in one PR for the build checks to pass.
We divided the changes into three commits to ease the review:

Updated test projects (7c65b52b127903bd74e0871c781d3dc551230646)
Updated test bots (405c6fdccaa455007f68ce29fa82321257a9e0dd)
Updated CI yamls (ebbbf5d0433e58343d26acdeef3f2ca3c7cf5b8d)

Note: The FunctionalTests pipelines and the generators will be updated in separate PRs.
Specific Changes

For the test projects:

Update projects to target net8.0 as well as net6.0.
Removed any conditions considering frameworks lower than .NET5.
Fixed CS8981 issue in Microsoft.Bot.Builder.Dialogs.Adaptive.Tests/ConditionalsTests

For the bots projects:

Updated all the bots to target .NET8 instead of .NET6.

For the CI pipelines yamls:

Added steps to build and test targeting .NET8.
Removed steps to build and test targeting netcoreapp3.1.

Testing
This image shows the TestBot bots working as expected after the update.

Here we can see the CI pipeline working after the changes.

Pull Request Test Coverage Report for Build 386054
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.06%) to 78.246%

Totals

Change from base Build 385929:
0.06%

Covered Lines:
26200

Relevant Lines:
33484

💛  - Coveralls

:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Integration.AspNet.Core.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.TemplateManager.dll

@ceciliaavila If it doesn't cause any issues, lets retain the 3.1 support in the packages.

@ceciliaavila If it doesn't cause any issues, lets retain the 3.1 support in the packages.

Sure, we'll update the projects to keep supporting netcoreapp 3.1.

@ceciliaavila @sw-joelmut Were the changes to retain 3.1 support (if possible) made?

[like]  Tracy Boehrer reacted to your message:

From: Joel Mut @.>
Sent: Friday, April 19, 2024 1:40:41 PM
To: microsoft/botbuilder-dotnet @.>
Cc: Tracy Boehrer @.>; Review requested @.>
Subject: Re: [microsoft/botbuilder-dotnet] [#6741] Update projects to .Net 8 (PR #6760)
Hi @tracyhttps://github.com/tracy, we prioritized other issues over this, but we can address it next week.
—
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/botbuilder-dotnet/pull/6760#issuecomment-2066615132, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAH2HBV72KPUATVSI36I2N3Y6ENFTAVCNFSM6AAAAABEQNLLY2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRWGYYTKMJTGI.
You are receiving this because your review was requested.Message ID: @.***>

:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Integration.AspNet.Core.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.TemplateManager.dll

Hi @tracyboehrer, the changes to maintain support for Net Core 3.1 are ready in the PR.


add nacos-client metadata

What does this PR do?
add nacos-client metadata
Checklist before merging

[X] I have considered including reachability metadata directly in the library or the framework (see this)
[X] I have properly formatted metadata files (see this)
[X] I have added thorough tests (see this)

@yuluo-yx since this PR requires docker image that we didn't allow previously, please close this PR.

@yuluo-yx由于此 PR需要我们之前不允许的docker 镜像，请关闭此 PR。

got i

@yuluo-yx since this PR requires docker image that we didn't allow previously, please close this PR.

got it. close now.


Bump crossbeam-utils from 0.8.3 to 0.8.4

Bumps crossbeam-utils from 0.8.3 to 0.8.4.

Release notes

bors r+


yarn disallows SVG's in the README

When running yarn build with yarn version 1.22.15, I get the following error:

ERROR  SVGs are restricted in README.md; please use other file image formats, such as PNG: https://daffodil.apache.org/assets/themes/apache/img/apache-daffodil-logo.svg

Should we create a png version of the logo on our website that this README can reference?
The README also has links to github workflow badges that are svg. I can't find a way to get png badges instead, but yarn doesn't seem to care about them, so maybe we can ignore them? Alternatively, shields.io (which we use for the Daffodil readme) does seem to have a way to use pngs, although they do not recommend it.

@stevedlawrence There is already a PNG of the logo out there so that is an easy fix. I have the updates for these latest issues locally I just had one question. Is it okay that I leave the badges for CI? As these SVGs don't cause issues with the build only the logo image did.


DNS driver for digitalocean and other minor Node driver updates

This includes common.digitalocean with the Node driver using the DigitalOceanBaseDriver
DigitalOceanBaseDriver ( and NodeDriver ) will handle v1 and v2 credentials properly
DigitalOceanNodeDriver ( for v1 ) implements ( 4 of the ) KeyPair Management instead of using ex_ssh_*
DigitalOceanDNSDriver implemented, only with v2 credentials, as v1 will at some point be deprecated so it was not implemented
DigitalOceanDNSDriver tests have been created
Modified FixtureRoots to include common so that tests for common could use it

I'v run through the DigitalOcean files ( for common, node and dns ) with flake8, and with the exception of 2 tests files, ( with long strings that I don't know how to break up to pass the test AND land within 79 chars ) everything is clean.
I would like to note that the documentation on the KeyPair management may need to be updated to include return types that are consistent with the other components of libcloud. This could be setup in an issue, but at the same time, this could be arbitrarily added without breaking anything before accepting this merge.

KeyPair include a delete(self) function that calls driver.delete_key_pair(self)
create_key_pair()  comment setup a rtype of KeyPair to make explicit that create_key_pair() returns a KeyPair instance ( like create_node returns a Node )

I'm wondering if the hack is what is causing the provider feature matrix build to fail.
https://github.com/jcastillo2nd/libcloud/blob/trunk/contrib/generate_provider_feature_matrix_table.py#L224
Should this also include a check if this is node driver vs dns driver?

Great, thanks!
I will have a look asap.

I'm thinking the hack can be removed entirely since the DigitalOceanNodeDriver can handle both cases with just passing of the secret or key only:
>>> from libcloud.compute.drivers.digitalocean import DigitalOceanNodeDriver
>>> n1 = DigitalOceanNodeDriver('v1_secrete', 'v1_key')
>>> n2 = DigitalOceanNodeDriver('v2_secret')
>>> n1.__class__
<class 'libcloud.compute.drivers.digitalocean.DigitalOcean_v1_NodeDriver'>
>>> n2.__class__
<class 'libcloud.compute.drivers.digitalocean.DigitalOcean_v2_NodeDriver'>

Also, I'm pulling the ex_ssh functions back into the v1 driver to live alongside the key pair functions so it doesn't break existing functionality. Poor foresight on my part.

Looks like removing the hack worked as it handles the tests properly for both v1 and v2 cases in DigitalOceanNodeDriver, also the old ex_ssh_* functions have been restored to v1, but with warnings.warn regarding deprecation.
This looks good from a working build perspective, let me know if there is anything else needed on this.

I've added some comments.
Overall the PR looks good, but there are some small things which need to be addressed so we can get it merged.

@jcastillo2nd Sorry for the delay and please ping me when those comments are addressed - I would love to get this change included in the next release.

@Kami Hopefully I've clarified the issues with the current code and moved things in the right direction. Let me know what your thoughts are on the pending issues.

@Kami I've got some time over the next couple of weeks to work on anything else that may come up on this. If there are still any issues keeping this from being merged, I will hopefully be able to resolve them before the next release is established.

I restored a slightly modified hack to make the table generation script work again<PHONE_NUMBER>5b3b758657588c282b2cb80ccbf19e) and merged changes into trunk.
Thanks.


Add half notes, quarter notes, etc...

Looking at the README, I could not find any references to setting notes to different lengths. Is there currently a way to do this, or does this feature need to be added in?

The way to do that is a bit tricky. We do have a way out currently by a param called noteLength. So look at this default setting:
var clip = scribble.clip({
    notes: 'c4',
    pattern: 'x'.repeat(16)
});

As you can imagine, that ll through out a bar of sixteenth notes. To play thirtysecondth notes, we need to bump the HDR speed in the MIDI itself. In Scribbletune you can set the noteLength param for this:
var clip = scribble.clip({
    notes: 'c4',
    pattern: 'x'.repeat(32),
    noteLength: 1/32
});

This will subdivide the bar into 32 beats instead.
Another way of looking at it is, and coming back to the default example (where it 1/16 by default):
var clip = scribble.clip({
    notes: 'c4',
    pattern: 'x_'.repeat(8)
});

In ^ there I ve added an underscore to the x. This acts as a sustain of sorts. In this case it ll sustain it for twice an x. So x_ acts as an eighth note. Similarly x___ acts as a quarter note. The same can be done by messing with the noteLength as well:
var clip = scribble.clip({
    notes: 'c4',
    pattern: 'x'.repeat(4),
    noteLength: 1/4
});

Lemme know if that made sense :)

@walmik Thank you for the explanation on the note length! That does make a lot of sense.