Tabula will not open

No error messages, the icon flashes like it is opening, but nothing happens, not in the dock, not anywhere. I am running OSX Yosemite, but I also tried on an older iMac running 10.6.  I tried the tabula-mac-0.9.7-large-experimental, but the same thing happened. Maybe it is something simple?

I have the same issue. I have Yosemite running and have installed Java 8 update 91. The tabula release notes say a Java 6 or 7 compatible environment is required. Do I need to install a Java 6 or 7 environment instead of 8? Asking first as the Oracle site recommends running the earlier environments. Thanks in advance.

@essjayarr: Java 8 is fine. You do not need to downgrade to a lower version.
@mtigas may be able to help you on the install question.


getAsFloat / LargeNumberMenuItem

Describe the bug
Documentation suggests you can get/set a float value on a LargeNumberMenuItem, see https://www.thecoderscorner.com/products/arduino-libraries/tc-menu/menu-item-types/largenum-menu-item/
mP_Ki = menuConfigurationPidI1.getAsFloat();
but
'class EditableLargeNumberMenuItem' has no member named 'getAsFloat'
Confirm that the bug is in the embedded library
lib or doc
To Reproduce
i can read with getLargeNumber() but not with getAsFloat(). Its a largeNumberMenuitem w. 4 decimals, 12 totals, default value 0 and allowed neg values
Device Specs
osx, platformio, arduino nano esp32, latest tcmenu lib

P.S chances are high the mistake is on my side ;)

Solved, user error ;)


WebJobs SDK tutorial should not use global DbContext

Hello,
I followed the WebJobs SDK tutorial and deployed the example project to Azure. However, I believe there is a pretty serious bug with the example code related to using a global DbContext in Program.cs.
When you create several new ads with images in rapid succession they get queued to the thumbnailrequest queue. The WebJob polls once in a minute for new queue messages. If it ever happens to dequeue several messages at once, the following exception immediately gets thrown:
System.Data.Entity.Core.EntityException: : System.Data.Entity.Core.EntityException: An error occurred while starting a transaction on the provider connection. See the inner exception for details. ---> System.InvalidOperationException: There is already an open DataReader associated with this Command which must be closed first.
   at System.Data.SqlClient.SqlInternalConnectionTds.ValidateConnectionForExecute(SqlCommand command)
   at System.Data.SqlClient.SqlInternalConnection.BeginSqlTransaction(IsolationLevel iso, String transactionName, Boolean shouldReconnect)
   at System.Data.SqlClient.SqlConnection.BeginTransaction(IsolationLevel iso, String transactionName)
   at System.Data.SqlClient.SqlConnection.BeginDbTransaction(IsolationLevel isolationLevel)
   at System.Data.Common.DbConnection.BeginTransaction(IsolationLevel isolationLevel)
   at System.Data.Entity.Infrastructure.Interception.DbConnectionDispatcher.<BeginTransaction>b__0(DbConnection t, BeginTransactionInterceptionContext c)
   at System.Data.Entity.Infrastructure.Interception.InternalDispatcher`1.Dispatch[TTarget,TInterceptionContext,TResult](TTarget target, Func`3 operation, TInterceptionContext interceptionContext, Action`3 executing, Action`3 executed)
   at System.Data.Entity.Infrastructure.Interception.DbConnectionDispatcher.BeginTransaction(DbConnection connection, BeginTransactionInterceptionContext interceptionContext)
   at System.Data.Entity.Core.EntityClient.EntityConnection.<>c__DisplayClassf.<BeginDbTransaction>b__d()
   at System.Data.Entity.SqlServer.DefaultSqlExecutionStrategy.Execute[TResult](Func`1 operation)
   at System.Data.Entity.Core.EntityClient.EntityConnection.BeginDbTransaction(IsolationLevel isolationLevel)
   --- End of inner exception stack trace ---
   at System.Data.Entity.Core.EntityClient.EntityConnection.BeginDbTransaction(IsolationLevel isolationLevel)
   at System.Data.Entity.Core.EntityClient.EntityConnection.BeginTransaction()
   at System.Data.Entity.Core.Objects.ObjectContext.ExecuteInTransaction[T](Func`1 func, IDbExecutionStrategy executionStrategy, Boolean startLocalTransaction, Boolean releaseConnectionOnSuccess)
   at System.Data.Entity.Core.Objects.ObjectContext.SaveChangesToStore(SaveOptions options, IDbExecutionStrategy executionStrategy, Boolean startLocalTransaction)
   at System.Data.Entity.Core.Objects.ObjectContext.<>c__DisplayClass2a.<SaveChangesInternal>b__27()
   at System.Data.Entity.SqlServer.DefaultSqlExecutionStrategy.Execute[TResult](Func`1 operation)
   at System.Data.Entity.Core.Objects.ObjectContext.SaveChangesInternal(SaveOptions options, Boolean executeInExistingTransaction)
   at System.Data.Entity.Core.Objects.ObjectContext.SaveChanges(SaveOptions options)
   at System.Data.Entity.Internal.InternalContext.SaveChanges()
   at System.Data.Entity.Internal.LazyInternalContext.SaveChanges()
   at System.Data.Entity.DbContext.SaveChanges()
   at ContosoAdsWebJob.Functions.GenerateThumbnail(BlobInformation blobInfo, Stream input, CloudBlockBlob outputBlob) in c:\Users\user\Documents\Visual Studio 2013\Projects\Simple Azure Website with WebJobs using the WebJobs SDK\C#\ContosoAdsWebJob\Functions.cs:line 36
   at lambda_method(Closure , Object[] )
   at Microsoft.Azure.WebJobs.Host.Executors.VoidInvoker.InvokeAsync(Object[] arguments)
   at Microsoft.Azure.WebJobs.Host.Executors.FunctionExecutor.<ExecuteWithWatchersAsync>d__23.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.Azure.WebJobs.Host.Executors.FunctionExecutor.<ExecuteWithOutputLogsAsync>d__1c.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
   at Microsoft.Azure.WebJobs.Host.Executors.FunctionExecutor.<ExecuteWithLogMessageAsync>d__c.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Microsoft.Azure.WebJobs.Host.Executors.FunctionExecutor.<ExecuteWithLogMessageAsync>d__c.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.Azure.WebJobs.Host.Executors.FunctionExecutor.<TryExecuteAsync>d__1.MoveNext()

This seems to be related to using a global ContosoAdsContext in ContosoAdsWebJob.Program. If one replaces this with a function-scoped using (ContosoAdsContex db = new ContosoAdsContex()) { ... } in ContosoAdsWebJob.Functions.GenerateThumbnail(), the problem is solved. As it stands, every invocation running in the same WebJob uses the same DbContext, which is bound to lead to a race condition in any production setup since DbContext is not thread-safe.

Pinging @tdykstra

Thanks for reporting that -- I'll fix it.

Download project is fixed.  Corresponding updates are in the private docs repo, should be live tomorrow.


error NETSDK1045: The current .NET SDK does not support targeting .NET Core 3.1

Getting this error when I run
docker build --tag <MY_DOCKER_ID>/azurefunctionsimage:v1.0.0 .

following the instructions here: https://docs.microsoft.com/en-us/azure/azure-functions/functions-create-function-linux-custom-image?tabs=bash%2Cportal&pivots=programming-language-csharp
Googling NETSDK1045 doesn't help much. Seems this error can happen in a lot of different situations. The docker build command is emitting the error. It's not my machine since
dotnet --list-sdks

shows that I have 3.0 and 3.1 and quite a few others in /user/local/share/dotnet/sdk. Looking at the dockerfile:
FROM mcr.microsoft.com/dotnet/core/sdk:3.0 AS installer-env

COPY . /src/dotnet-function-app
RUN cd /src/dotnet-function-app && \
    mkdir -p /home/site/wwwroot && \
    dotnet publish *.csproj --output /home/site/wwwroot

# To enable ssh & remote debugging on app service change the base image to the one below
# FROM mcr.microsoft.com/azure-functions/dotnet:3.0-appservice
FROM mcr.microsoft.com/azure-functions/dotnet:3.0
ENV AzureWebJobsScriptRoot=/home/site/wwwroot \
    AzureFunctionsJobHost__Logging__Console__IsEnabled=true

COPY --from=installer-env ["/home/site/wwwroot", "/home/site/wwwroot"]

Seems to suggest that it wants 3.0. This file was generated by
func --docker-only

to try to convert an existing function project to use a Linux docker image (my goal). Should I just change the dockerfile to point to 3.1 wherever it reads 3.0?

Ok yes, apparently just changing references from 3.0. to 3.1 makes the error go away.

Although now when I look at readme.md all of the versions listed are 3.0. Which version 3.0 of what? Should I be worried about this?

Ok looks like the way to fix this is to change my TargetFramework to 3.0 like this:
 <TargetFramework>netcoreapp3.0</TargetFramework>


HTML

#HTML
##User Story
As a bootcamp student
I want the prework notes to be structured on a website
so that I can easily find and read information
##Acceptance Criteria
GIVEN a Prework study guide website
WHEN i visit the website in my browser
THEN I see four boxes titled HTML ,CSS,Git and Javascipt with associated notes listed

CSS
As a boot camp student
I want the prework notes to be structured on a webpage
So that I can easily find and read the information
GIVEN a Prework Study Guide website
WHEN I view the study guide
THEN I see a dark blue header and footer, and four boxes with a shadow

JavaScript
As a boot camp student
I want the prework notes to be structured on a webpage
So that I can easily find and read the information
GIVEN a Prework Study Guide website
WHEN I view the study guide
THEN I can see the four topics I learned listed along with a suggestion on what I should study first

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

Deployment
As a boot camp student,
I want the prework notes to be structured on a webpage,
So that I can easily find and read the information.
GIVEN a Prework Study Guide website,
WHEN I visit the website using the URL,
THEN I can access my website from any browser


Out of range index error

Hi,
I think there is an "out of range IndexError" in the "bin_array" class inside coverage.py file: line 278:
self.nbins = -1 if len(nbins) == 0 else nbins[1]
I believe it should be nbins[0]. Please correct me if I'm missing something here.
Thanks

Good catch, Hodjat! You're correct about the index being incorrect. I've added a test to show the error, as well as a fix (2f6a5bd).

By the way, I'm very much open to PRs.


Error line:column positions are byte-based offsets, not character offsets

What version of Go are you using (go version)?

$  go version
go version go1.16.2 linux/amd64

Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (go env)?
n/a - playground
What did you do?
See https://play.golang.org/p/J8yaQkcVFxI
package main

func main() {
y := "😀" x
π 3
// "./prog.go:4:13: syntax error: unexpected x at end of statement"
// I would expect
// "./prog.go:4:10: syntax error: unexpected x at end of statement"
}

What did you expect to see?
./prog.go:4:10: syntax error: unexpected x at end of statement
./prog.go:5:3: syntax error: unexpected literal 3 at end of statement

I would expect syntax error positions to be rune/character offsets, not byte offsets.
As far as I can tell this is working as intended, but it's at odds with most text editors' behavior. Apologies if this is a duplicate.
What did you see instead?
./prog.go:4:13: syntax error: unexpected x at end of statement
./prog.go:5:4: syntax error: unexpected literal 3 at end of statement

See #10324 for the justification in making it a byte and not unicode code point offset

Thanks for the link. Feel free to close.
On Tue, Mar 23, 2021, 12:45 AM Sean Liao @.***> wrote:

See #10324 https://github.com/golang/go/issues/10324 for the
justification in making it a byte and not unicode code point offset
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/45169#issuecomment-804691036, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAUO54NQPDMUPMDFL6KL7TTFBBKLANCNFSM4ZUQZP4A
.


No sound during playback on Arch Linux

OS:
Arch Linux
google-play-music-desktop-player-git <IP_ADDRESS>.ge77e060-1
I installed via AUR (yaourt -S google-play-music-desktop-player-git)
Issue Descriptions:
I get no sound at all during playback.
Steps to Reproduce:
Start app, try to play a song, no sound.
I try changing  my audio device settings in (right click > audio device)
I made sure to toggle (line line) mute on/off from keyboard controls, and to slide the volume all bar in UI all the way up.
I can play the audio fine in both Chrome and Nuvola app (another standalone app).
Workaround
After debugging, I discovered the Pulse audio "sink" was muted.

Use 'pacmd list-sink-inputs' to list sinks. Find the corresponding one to google-play-music app.
Unmute the corresponding index using 'pacmd set-sink-input-mute  false

Hmmmm, doesn't sound like something the program can handle internally.  Can you add a bit to the bottom of the FAQ wiki.  Something like
No audio output on Arch?

Steps here to fix

Sure, I can do that. Also, mentioned it on https://aur.archlinux.org/packages/google-play-music-desktop-player-git/ in case it's a package/distro issue.


reported log lines are wrong

run:
s2i build https://github.com/openshift/nodejs-ex centos/nodejs-4-centos7  --loglevel=5
you will see in the output:
E0804 23:28:46.056805   28401 postexecutorstep.go:328] npm info it worked if it
ends with ok

but the output is actually being logged by:
https://github.com/openshift/source-to-image/blob/master/pkg/build/strategies/sti/sti.go#L587
(the postexecutorstep isn't being invoked at all because this isn't an extended build).
bafflingly, if you comment out the postexecutor step line, you'll see the log attributed to yet another incorrect location.  If you then comment out that location, the reporting is correct.
Also if you change the postexecutor code to instead log to info instead of err, the reported location changes.
So something very weird is going on w/ the stack frame attribution, possibly due to the presence of go routines, but it makes no sense to me that it's getting attributed to code that's not even being invoked in these flows (i added print statements to confirm that).

note that https://github.com/openshift/source-to-image/pull/557 will change this behavior slightly, but it will still not report the line number correctly.

@php-coder fyi, though i don't think this relates to your extended build work. but just in case you have a thought.

@bparees If you remember, I was suggesting to add a prefixes to the messages that came from scripts. It won't fix wrong lines but at least helps to quickly understand that errors came not from S2I code but from the one of user-provided scripts.

@php-coder yes but that's not my primary concern here, i'm worried about us trying to debug later and not understanding what code is actually executing (especially if this is not the only place where the misreporting is happening).
if we report the correct line numbers, it's easy to go to that line number and understand the output is coming from the container/script in the container.  if we report the wrong one, it can really send you down a bad debugging path.

@bparees This is a side effect of our glog wrapper. glog is an object when you use the wrapper and a package when you are not.
So when we are using the wrapper, glog.Info in
dockerpkg.StreamContainerIO(errReader, nil, glog.Info)
actually requires the creation of a closure. Go does this invisibly for us, but the result is apparently then shared by anyone needing an identical closure. The first module to create the closure winds up in the stack (which explains why when you commented things out, the file/line was changing).
In the example below, postexecutorstep.go:328 creates it -- which results in the seemingly nonsensical stack.
goroutine 55 [running]:
runtime/debug.Stack(0x0, 0x0, 0x0)
        /usr/lib/golang/src/runtime/debug/stack.go:24 +0x80
github.com/openshift/source-to-image/pkg/util/glog.(*FileLogger).writeln(0xc82000e260, 0x0, 0xc820380b70, 0x26)
        /home/jupierce/go/src/github.com/openshift/source-to-image/_output/local/go/src/github.com/openshift/source-to-image/pkg/util/glog/glog.go:135 +0x27f
github.com/openshift/source-to-image/pkg/util/glog.(*FileLogger).output(0xc82000e260, 0x0, 0xc82045e320, 0x1, 0x1)
        /home/jupierce/go/src/github.com/openshift/source-to-image/_output/local/go/src/github.com/openshift/source-to-image/pkg/util/glog/glog.go:156 +0x69
github.com/openshift/source-to-image/pkg/util/glog.(*FileLogger).Info(0xc82000e260, 0xc82045e320, 0x1, 0x1)
        /home/jupierce/go/src/github.com/openshift/source-to-image/_output/local/go/src/github.com/openshift/source-to-image/pkg/util/glog/glog.go:166 +0x47
github.com/openshift/source-to-image/pkg/util/glog.(Logger).Info-fm(0xc82045e320, 0x1, 0x1)
        /home/jupierce/go/src/github.com/openshift/source-to-image/_output/local/go/src/github.com/openshift/source-to-image/pkg/build/strategies/sti/postexecutorstep.go:328 +0x50
github.com/openshift/source-to-image/pkg/docker.StreamContainerIO(0x7f61879ee818, 0xc8200901f0, 0xc820247740, 0xc82026fc60)
        /home/jupierce/go/src/github.com/openshift/source-to-image/_output/local/go/src/github.com/openshift/source-to-image/pkg/docker/util.go:97 +0x4de
created by github.com/openshift/source-to-image/pkg/build/strategies/sti.(*STI).Execute
        /home/jupierce/go/src/github.com/openshift/source-to-image/_output/local/go/src/github.com/openshift/source-to-image/pkg/build/strategies/sti/sti.go:593 +0x120e

This is likely an optimization on go's part since the closure can be reused safely/efficiently, but I've opened an issue for their awareness.
We can improve our log output by creating the closures ourselves.
dockerpkg.StreamContainerIO(errReader, nil, func(a ...interface{}){ glog.Info(a...) })

Confirmed with gloang issue that the optimization is to prevent binary code bloat.

@jupierce do they consider this a bug or acceptable behavior?  I suppose the scenarios in which it impacts people are pretty rare, but i bet it confuses debuggers too.

They consider it an acceptable tradeoff : not ideal, but not something that cannot be addressed efficiently right now.

fair enough.  great find, regardless.


chore(main): release 1.1.0

:robot: I have created a release beep boop
1.1.0 (2023-04-07)
Features

Add parity to UartStmDma (#56) (e30d8d9)
Add release-please workflow (#65) (b39a848)
Add stm32f7discoveryFmcPins to SdRamStm (#78) (72df16b)
Apply clang-format (#58) (714d922)
Deregister-interrupt-handler-on-move-assign (#80) (095449d)
Merge upstream changes (#79) (8ec3afd)
osal: Add example (#82) (b1539ca)

Bug Fixes

Avoid using generator expressions for linking to targets (#92) (441abe5)
Correct dependencies of synchronous_stm32fxxx and ble_middleware (#85) (2ffaf23)
hal_st/stm32fxxx/UartStm & UartDma: Registers for stm32f407 (#59) (98ceaf3)
HALST_EXCLUDE_FROM_ALL for instantiations_lwip (#94) (f80f6ee)
Link stm32f0xx to correct std_periph (#93) (31cdcbb)
Set correct mcpu mfpu options for different target cpus (#75) (a799834)
UartStm: Use correct registers & fix overrun assert; enable FIFO (#68) (60efc65)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/philips-software/amp-hal-st/releases/tag/v1.1.0 :sunflower:


Change CI pytests to be more accurate

Similar to https://github.com/PennLINC/qsirecon/pull/177, change how pytests runs the workflows.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 43.81%. Comparing base (cb8b61e) to head (0c84e00).

Additional details and impacted files
@@             Coverage Diff             @@
##           master     #887       +/-   ##
===========================================
+ Coverage   28.48%   43.81%   +15.32%
===========================================
  Files          68       68
  Lines       10152    10152
  Branches     1146     1146
===========================================
+ Hits         2892     4448     +1556
+ Misses       7162     5481     -1681
- Partials       98      223      +125

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

🚨 Try these New Features:

Flaky Tests Detection - Detect and resolve failed and flaky tests


Can "UpdateLiveStats" be used to display account info too?

When we start up, there is an account info display, like level, xp to next level, how many potions, etc.
Can we include in "UpdateLiveStats" too?

#3975


Grouped updates did not upgrade everything

Is there an existing issue for this?

[X] I have searched the existing issues

Package ecosystem
bundler
Package manager version
2.4.10
Language version
Ruby 3.2.2
Manifest location and content before the Dependabot update
/Gemfile
dependabot.yml content
  - package-ecosystem: "bundler"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "tuesday"
      timezone: "Europe/Berlin"
      time: "19:45"
    groups:
      # Dependabot grouped updates:
      # Docs at https://gist.github.com/brrygrdn/0dac4e16c68898fda33d8fa81d575e1a
      # This is the name of your group, it will be used in PR titles and branch
      # names
      dependencies:
        patterns:
          - "*"

Updated dependency
No response
What you expected to see, versus what you actually saw
I'm evaluating Dependabot grouped updates. During this period, I have both Depfu and Dependabot generating PRs on my repo. This week, Dependabot generated a PR about 5 hours after the Depfu one (we hadn't merged Depfu in the meantime). I'd have expected the Dependabot PR to be the same as (or a superset of) the Depfu upgrades. However, the upgrades were a subset: some upgrades were missed.
Native package manager behavior
No response
Images of the diff or a link to the PR, issue, or logs
Here's a diff from the Dependabot PR to the Depfu one (added = Depfu had it, Dependabot didn't).
diff --git a/Gemfile.lock b/Gemfile.lock
index 998c7b39..a878b30b 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -154,7 +154,7 @@ GEM
       aws-partitions (~> 1, >= 1.651.0)
       aws-sigv4 (~> 1.5)
       jmespath (~> 1, >= 1.6.1)
-    aws-sdk-dynamodb (1.85.0)
+    aws-sdk-dynamodb (1.87.0)
       aws-sdk-core (~> 3, >= 3.174.0)
       aws-sigv4 (~> 1.1)
     aws-sdk-kms (1.67.0)
@@ -172,10 +172,10 @@ GEM
       aws-sdk-core (~> 3, >= 3.174.0)
       aws-sdk-kms (~> 1)
       aws-sigv4 (~> 1.4)
-    aws-sdk-ses (1.50.0)
+    aws-sdk-ses (1.51.0)
       aws-sdk-core (~> 3, >= 3.174.0)
       aws-sigv4 (~> 1.1)
-    aws-sdk-sesv2 (1.34.0)
+    aws-sdk-sesv2 (1.35.0)
       aws-sdk-core (~> 3, >= 3.174.0)
       aws-sigv4 (~> 1.1)
     aws-sdk-sqs (1.58.0)
@@ -265,9 +265,9 @@ GEM
       google-apis-core (>= 0.11.0, < 2.a)
     google-apis-gmail_v1 (0.29.0)
       google-apis-core (>= 0.11.0, < 2.a)
-    google-protobuf (3.23.2-arm64-darwin)
-    google-protobuf (3.23.2-x86_64-darwin)
-    google-protobuf (3.23.2-x86_64-linux)
+    google-protobuf (3.23.3-arm64-darwin)
+    google-protobuf (3.23.3-x86_64-darwin)
+    google-protobuf (3.23.3-x86_64-linux)
     googleapis-common-protos-types (1.6.0)
       google-protobuf (~> 3.14)
     googleauth (1.5.2)
@@ -331,7 +331,7 @@ GEM
     msgpack (1.7.1)
     multi_json (1.15.0)
     multi_xml (0.6.0)
-    net-imap (0.3.4)
+    net-imap (0.3.6)
       date
       net-protocol
     net-pop (0.1.2)
@@ -497,7 +497,7 @@ GEM
     opentelemetry-instrumentation-racecar (0.2.1)
       opentelemetry-api (~> 1.0)
       opentelemetry-instrumentation-base (~> 0.22.1)
-    opentelemetry-instrumentation-rack (0.23.1)
+    opentelemetry-instrumentation-rack (0.23.2)
       opentelemetry-api (~> 1.0)
       opentelemetry-common (~> 0.19.3)
       opentelemetry-instrumentation-base (~> 0.22.1)
@@ -543,7 +543,7 @@ GEM
       opentelemetry-api (~> 1.0)
       opentelemetry-instrumentation-base (~> 0.22.1)
       opentelemetry-semantic_conventions (>= 1.8.0)
-    opentelemetry-registry (0.2.0)
+    opentelemetry-registry (0.3.0)
       opentelemetry-api (~> 1.1)
     opentelemetry-sdk (1.2.1)
       opentelemetry-api (~> 1.1)
@@ -770,7 +770,7 @@ GEM
       unf_ext
     unf_ext (<IP_ADDRESS>)
     unicode-display_width (2.4.2)
-    unparser (0.6.7)
+    unparser (0.6.8)
       diff-lcs (~> 1.3)
       parser (>= 3.2.0)
     vcr (6.1.0)

Smallest manifest that reproduces the issue
No response

Here's the Dependabot logs. For security reasons, I'd prefer not to have the full BOM public, so let me know when you've received and saved the logs so I can delete it: https://gist.github.com/bmulholland/ab729d14f07f0dacf1dfb568607fa292
I note that there is no entry saying "Checking if xxx needs updating" for the missing packages.

It looks like these are all transitive dependencies...

Thanks for this report, we'll have a look at the job and figure out what is going on.
It looks like you have not specified an allow rule so we should be using the default strategy of all rather than direct and including transitive dependencies, so this seems like a bug in grouped behaviour.

Hi @bmulholland I started taking a look at this and since your repo is private, we will need to request access to it in order to investigate why the update did not upgrade everything.
If you are okay with this let me know and I can request access.
My initial suspicious is that there is some direct dependency that is locking these transitive dependencies from upgrading to the latest version. I do find it odd that some of the transitive dependencies were unable to upgrade to the latest patch version though, so there may be something else going on here.
If you would like to delete the gist I have downloaded the job logs.
Thanks!

Hi @Nishnha thanks for looking into this. I just got back from PTO. Sure, happy to grant you access to investigate. FYI, we have essentially zero pinned versions in our Gemfile.

Hi @bmulholland, I took a shot at recreating and debugging this issue.
Something that stood out to me is that in the original grouped update, Dependabot only attempted to update ~10 dependencies, and some dependencies were skipped altogether.
I noticed that in a more recent grouped update on your repository, Dependabot is attempting to update ~80 dependencies.
Have you updated your dependabot.yaml file or group configuration since then? I wonder if this was a temporary issue that may have been resolved by https://github.com/dependabot/dependabot-core/pull/7358 or another bug fix?

I did update my dependabot.yml, changing just the commit prefix. But I'm also not seeing the 80 updates you're talking about?

Today's weekly update included most updates that I see in the Depfu PR, but not all. It's missing e.g. aws-sdk-ses 1.53.0, which came out on the 6th.

I have a similar case.
Config
    groups:
      storybook:
        patterns:
          - "@storybook/*"
          - "storybook"
          - "eslint-plugin-storybook"

package.json in main
{
    "@storybook/addon-essentials": "^7.0.18",
    "@storybook/addon-interactions": "^7.0.26",
    "@storybook/addon-links": "^7.0.26",
    "@storybook/blocks": "^7.0.18",
    "@storybook/nextjs": "^7.0.18",
    "@storybook/react": "^7.0.18",
    "@storybook/testing-library": "^0.2.0",
    "storybook": "^7.0.26"
}

package.json in dependency PR
{
    "@storybook/addon-essentials": "^7.0.27",
    "@storybook/addon-interactions": "^7.0.27",
    "@storybook/addon-links": "^7.0.27",
    "@storybook/blocks": "^7.0.18",
    "@storybook/nextjs": "^7.0.27",
    "@storybook/react": "^7.0.18",
    "@storybook/testing-library": "^0.2.0",
    "storybook": "^7.0.27"
}

#### Log for failed updates

updater | 2023/07/12 16:20:22 INFO  Updating @storybook/addon-links from 7.0.26 to 7.0.27
updater | 2023/07/12 16:20:39 INFO  Checking if @storybook/blocks 7.0.27 needs updating
  proxy | 2023/07/12 16:20:39 [156] GET https://registry.npmjs.org:443/@storybook%2Fblocks
  proxy | 2023/07/12 16:20:39 [156] 200 https://registry.npmjs.org:443/@storybook%2Fblocks
  proxy | 2023/07/12 16:20:40 [158] GET<EMAIL_ADDRESS>  proxy | 2023/07/12 16:20:40 [158] 200<EMAIL_ADDRESS>updater | 2023/07/12 16:20:40 INFO  Latest version is 7.0.27
updater | 2023/07/12 16:20:40 INFO  No update needed for @storybook/blocks 7.0.27

updater | 2023/07/12 16:21:02 INFO  Requirements to unlock own
updater | 2023/07/12 16:21:02 INFO  Requirements update strategy bump_versions
updater | 2023/07/12 16:21:02 INFO  Updating @storybook/nextjs from 7.0.18 to 7.0.27
updater | 2023/07/12 16:21:22 INFO  Checking if @storybook/react 7.0.27 needs updating
  proxy | 2023/07/12 16:21:22 [368] GET https://registry.npmjs.org:443/@storybook%2Freact
  proxy | 2023/07/12 16:21:22 [368] 200 https://registry.npmjs.org:443/@storybook%2Freact
  proxy | 2023/07/12 16:21:23 [370] GET<EMAIL_ADDRESS>  proxy | 2023/07/12 16:21:23 [370] 200<EMAIL_ADDRESS>updater | 2023/07/12 16:21:23 INFO  Latest version is 7.0.27
updater | 2023/07/12 16:21:23 INFO  No update needed for @storybook/react 7.0.27

```

@jbergstroem I think that issue should be fixed by https://github.com/dependabot/dependabot-core/pull/7561. Open a new issue if it's still broken, I'd be happy to look into it more.
@bmulholland I may have addressed this issue in https://github.com/dependabot/dependabot-core/pull/7561 and https://github.com/dependabot/dependabot-core/pull/7621. Would you mind trying again and see if it's fixed?

@jbergstroem I think that issue should be fixed by https://github.com/dependabot/dependabot-core/pull/7561. Open a new issue if it's still broken, I'd be happy to look into it more.

Will monitor the coming days and comment if required.

@jakecoffman I just tried rebasing our weekly upgrade PRs from Depfu and Dependabot within a few minutes of each other. The one from Dependabot included all changes that were in Depfu, except two transitive dependencies. I checked the Dependabot logs and, notably, did not see a line that says "Checking if   needs updating" for those two. That seems to suggest that, for at least two packages, we'd never get updates.

Per https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#allow, you have to add an allow entry for dependency-type: all to get updates to transitive dependencies. That would explain why it didn't check it for updates.

This weeks updates have run, including my dependabot.yml which specifies allowing all, and all dependencies were correctly updated. I'd say that this is fixed -- thank you!


Support verbose flag for resin sync

Closes #355

Verbose flag implementation in resin sync is PR'ed here.

Released in v4.2.0.


yiisoft/mongodb SASL Authentication

I got an error
Caused by: MongoConnectionException
Failed to connect to: localhost:27017: SASL Authentication failed on database 'local': Authentication failed.
I explicitly declared the database name 'local' to be used for the connection.
I inserted the session component into the backend\config\main.php.
I tried to test the connection using MongoDB shell AdminUIs. The connection works and the database was accessed.

@xiandalisay, can you successfully connect to your database using plain PHP mongo extension?

Yes, I can connect to my database. I am using WAMP windows. and rockmongo for UI.

i used the following code. from the issue 5303 mongodb\Connection not understand dsn
'mongodb' => [
'class' => 'yii\mongodb\Connection',
'dsn'=> 'mongodb://localhost/database?connectTimeoutMS=300000',
'defaultDatabaseName' => 'database', // Avoid autodetection of default database name
],
it works now. But the code on the docs, for the dbconnection does not work. Why is that?

Issue about parameters in DSN has been resolved long ago: #5303
Which version of 'yii2-mongodb' you are using?

What exactly your problematic DSN is?

The issue is now solved. Thank you.

How do you solve？


Made the PulsarClusterMetadataTeardown deletes idempotent

Motivation
If some of the z-nodes are not there anymore, the cluster teardown operation should not fail.
Also changed the delete recursive operation to delete in parallel for children of same node, to speed up the overall execution time.

/pulsarbot run-failure-checks


Error: version `ZLIB_1.2.9' not found - conflict with node-canvas

I'm getting this error when running my program:
Error: /lib/x86_64-linux-gnu/libz.so.1: version 'ZLIB_1.2.9' not found ...
Any thoughts?

Hello, this is probably related to the order in which shared libraries are loaded. What other dependencies are you using? Ensure sharp is required before other dependencies that might load a system's zlib first.

I tried rearranging them but I'm getting the same error. I've decided to use a different library that isn't causing conflicts, so I'll close this issue.

Are you able to share the list of other dependencies to help others who may have a similar problem?

I pinpointed the library that was causing conflicts. It was node canvas.
https://github.com/Automattic/node-canvas

Thanks.
See #371, the summary of which is that if you're relying on a system-wide installation of cairo for node-canvas, then the safest option is to also rely on a system-wide install of libvips for sharp.

We have the same issue here.
How to change the setting to let sharp rely on system-wide libvips? Thanks.
@lovell

@kpman http://jcupitt.github.io/libvips/install.html then re-install sharp.

@lovell Thanks for the reply :)

Ran into the same issue with Electron as the only other dependency. I tried a normal npm install but I also tried deleting all my dependencies and manually installing sharp and then electron with a minimal main.js setup. Maybe Electron is loading zlib as part of its bundled Chromium dependency? Here's the quick start repo for Electron that I was trying to reconfigure after my own app wouldn't work: https://github.com/electron/electron-quick-start
Shoveling in the require before electron initiates anything in the main.js or renderer.js file doesn't help, which I kind of expected, but I don't see a clear way around it. Has anyone else worked this out?

@Apophenia Hello, it's interesting that Electron should trigger this also. Perhaps now that it uses node as a shared library rather than a static library then it is exporting zlib symbols? I guess as long as process.versions.zlib is >=1.2.9 then things should be OK.
The latest (beta?) version of Electron appears to use Node 7.9.0, which provides zlib 1.2.11.
$ node -v
v7.9.0
$ node -e "console.log(process.versions.zlib)"
1.2.11

Hi, thanks! I am using sharp 0.18.2, Node v7.9.0, and the Electron v1.7.5 beta and am getting the same console output. I still get the same error as soon as I try to require sharp. If I throw process.versions.zlib into the same place I'm trying to require sharp, it shows 1.2.11.
I'll try stripping down my boilerplate even more just in case I'm missing something obvious, but I seem to be getting the same stack trace whether or not process.noAsar is set to true, and similarly process.versions.zlib seems to equal 1.2.11 regardless of where I print it and what the noAsar setting is. (I have no idea how relevant the noAsar setting is, was just throwing things at the wall since it's in the stack trace.)
ELECTRON_ASAR.js:173 Uncaught Error: /lib/x86_64-linux-gnu/libz.so.1: version `ZLIB_1.2.9' not found (required by /home/lyndsey/electron-quick-start/node_modules/sharp/build/Release/../../vendor/lib/libpng16.so.16)
    at process.module.(anonymous function) [as dlopen] (ELECTRON_ASAR.js:173:20)
    at Object.Module._extensions..node (module.js:598:18)
    at Object.module.(anonymous function) [as .node] (ELECTRON_ASAR.js:173:20)
    at Module.load (module.js:488:32)
    at tryModuleLoad (module.js:447:12)
    at Function.Module._load (module.js:439:3)
    at Module.require (module.js:498:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/home/lyndsey/electron-quick-start/node_modules/sharp/lib/constructor.js:9:15)
    at Object.<anonymous> (/home/lyndsey/electron-quick-start/node_modules/sharp/lib/constructor.js:234:3)

@Apophenia Thanks for the update and extra info, I've created #892 to track this.

@manikmi Please see #892.


i need a hide() and a show() function to run when i scroll my screen

This lib doesn't have behavior support yet. You have to implement hide and show by yourself for now


Permission Denied when trying to enable Docker

Hi I have just installed today the playa-mesos on my computer and it works pretty well, but when I try to enable docker by using echo 'docker,mesos' > /etc/mesos-slave/containerizers, it throws me a Permission denied exception. And the same happens if I use the sudo command. Any idea of what I can do to enable Docker in this case?
Thank you so much.

Hello, sudo doesn't play well with shell redirection. You have too options: 1) Switch to the root user with su and run the command or 2) Run echo 'docker,mesos' > sudo dd of=/etc/mesos-slave/containerizers


Soft fail registry update

Fixes #142
Would this mark the job as failed even if steps succeeded afterwards?

According to ChatGPT this should work:
In GitHub Actions, if a step within a job is marked with continue-on-error: true and it fails, the job will continue executing the subsequent steps. Whether the job as a whole is marked as successful or not depends on the outcomes of the remaining steps.
Here's what happens:

Step with continue-on-error: true fails: This failure is ignored, and the job proceeds to the next steps.

Subsequent steps succeed: If all the subsequent steps succeed, then the overall job will be marked as successful, despite the earlier step failure. This is because the failure of a step with continue-on-error: true does not contribute to the final job status.

Subsequent steps fail: If any of the subsequent steps fail (and they are not marked with continue-on-error: true), then the job will be marked as failed.

In summary, a job can be marked as successful if a step with continue-on-error: true fails, as long as the steps that follow it succeed.

Successfully tested here
https://github.com/IanButterworth/PowerMonitor.jl/actions/runs/10644589690/job/29509494273#step:3:140


Training script for LAVA

Hi guys!
I am a big fan of your work and would like to ask if you have considered also providing the training script for LAVA. Especially the part about action and rgb normalization is currently not clear to me.
Thanks in advance :)

Bumping this

Hi @MaximilianToelle, I've just pushed a portion of the code for normalization which you can find in this commit: https://github.com/google-research/language-table/commit/2cabececffa3c1420345fd7df522a7664532b2c0
This contains the normalization code which you can take a look at, and I also added the jax BC implementation.
For the full train script and data code, that is a bit delayed since we are waiting on a new version release for one of the dependencies in our data pipeline. Apologies for the delay on this, but hopefully the above code is useful for now. Let me know if you have any questions.

Hi,
Thank you for the fantastic work! I really enjoy reading the paper and want to build something upon LAVA !
Could you anticipate a time that the full training / evaluation scripts will released?
Again, great work!

Thanks @ayzaan for parts of the training code! While looking through the code, some questions came to my mind. It would be awesome if you could provide some more insights :)

I don't quite understand the loss calculation. The per_example_loss seems to be a single value as jax.numpy.mean takes the mean over all elements. This in turn is used to form a mean value to generate the final loss. Shouldn't it be something like loss = jnp.mean(jnp.sum(jnp.square(predicted_actions - action), axis=1))
I've recognized that the MultiScaleResNet Encoder is set to train=False. Why is it nevertheless necessary to include batch_stats as a mutable during training?
Do you guys use the downloaded clip checkpoint to encode the instructions within the data pipeline and then use the "clip_in_obs" option during training?
Using your evaluation script, I have seen that the instructions are also provided as sequences. The embeddings within a sequence seem to always be the same as the instruction does not change within a single episode. Do you also filter out sequences of changing instructions in your data pipeline? Does training suffer if you would only provide a single instruction embedding instead of a sequence of identical ones?

The training code is available now!
The python dependency chain was a bit tricky, mainly because of a TF dependency on specific protouf versions. I've added a requirements_static.txt with pinned dependency versions that works on machines I've tested on.
python3 -m venv ./ltvenvtrain
source ./ltvenvtrain/bin/activate
pip install --no-deps -r ./requirements_static.txt
export PYTHONPATH=${PWD}:$PYTHONPATH

Also need to download the CLIP weights:
python language_table/train/download_clip_flax_ckpt.py --checkpoint_directory=/tmp/scenic_clip_ckpt

Running the training:
mkdir -p /tmp/language_table_train/
PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=python  python language_table/train/main.py --config=./language_table/train/configs/language_table_sim_local.py --workdir=/tmp/language_table_train/

The language_table_sim_local.py file is a config that should be good for testing locally. It has a smaller batch size and replay_capacity. Let me know if you have any questions!

@MaximilianToelle, to answer your questions:

Ah yes this is wrong and/or bad variable naming, since we're taking the mean it's not a per example loss. I'll fix this, or feel free to submit a PR yourself.
It's not necessary in this case, since we're freezing the ResNet here. For flexibility, we left it in since in other cases we may want to unfreeze the ResNet for finetuning, other implementations of networks may use batchnorm, etc.
In this training script we're tokenizing the CLIP instruction in the data pipeline and adding the frozen CLIP text encoder to the network. We've previously done an optimization where we run the CLIP text encoder offline to produce embeddings and bake it into the dataset to avoid the forward pass during training. However we released the public dataset with just raw text instructions rather than including the CLIP embeddings in, so we're not doing the optimization here.
Apologies, we do use the ViT-B/32 model during the CLIP finetuning procedure. Note that in this BC training setup we're only using the text encoder, so it doesn't really matter which we download. But for consistency with the paper I'll change it, thanks for pointing it out.
Yes the instruction doesn't change across the episode so passing the sequence of instructions is not necessary. We just arbitrarily take the first item in the sequence in the network: tokens = x["instruction_tokenized_clip"].astype(jnp.int32)[:, 0]. It shouldn't affect training at all. In the dataset, each episode will only have a single instruction, so we don't really have the case where there are sequences of changing instructions.

Thanks a lot for the full training code and your detailed answers @ayzaan, it really helped me to get forward! Some last questions came up and it would be awesome if you can once again answer them :)

In the paper you mention the use of "two Imagenet-pretrained ResNet layers". Though, I've recognized that the ResNet layers are being trained and not downloaded as with clip. What would be the correct way for training?
In the evaluation script, I've seen the comment "For PUSH we need to normalize RGB". In the config file, I've seen config.data_skip_normalize_keys=["rgb", "instruction"]. At the end, did you normalize the rgbs or not?

Yes the model we used in real used lava_image_encoder="resnet" with this config to freeze parameters:
config.agent.pretrained_checkpoints = [
      (
        "<clip checkpoint>",
        [("params/text", "params/encoder/TextEncoder_0")],
      ),
      ("<resnet imagenet checkpoint>",
       [("params", "params/encoder/ResNetVisualEncoder_0/MultiscaleResNet_0"),
        ("batch_stats",
         "batch_stats/encoder/ResNetVisualEncoder_0/MultiscaleResNet_0")])
  ]
  config.agent.freeze_keys = ["TextEncoder_0", "MultiscaleResNet"]

This requires a pretrained resnet checkpoint (we pretrained on imagenet classification). I'll see if I can provide this while addressing #9. Overall, the conv_maxpool image encoder has very similar performance in sim.
Re: normalization - Those comments were outdated from a non-related task, I removed them in 039dfa4b6b610b431e33ab1db44afa1a18643b54. In the data pipeline we scale to [0.0, 1.0] with image = tf.cast(image, tf.float32) / 255.0. For conv_maxpool no extra handling is done. For resnet, we want to normalize the image in the same way as was done during the pretraining, which is "standard" resnet normalization (https://github.com/google-research/language-table/blob/c617df4a4fa88e07b6c83cdac89a4d7eee25c2b8/language_table/train/networks/lava.py#L90). Since this normalization is done in the network, we don't need any special handling in policy.py when doing inference.


warning in make output

Following the README to build Soletta, I get a warning that sticks out like a sore thumb in the otherwise nice-and-clean output - but not indication if it is a problem or what to do about it :
$ make alldefconfig
...
$ make
...
./src/modules/flow/string/string.c:40:2: warning: #warning "You're building the string nodes module without i18n support -- some nodes will only act properly on pure ASCII input, not the intended utf-8 for Soletta" [-Wcpp]
 #warning "You're building the string nodes module without i18n support -- some nodes will only act properly on pure ASCII input, not the intended utf-8 for Soletta"
...

Good catch. Se should find a way to let users see important missing dependencies instead of silently disabling features that depend on it.
And after that we need to allow users forcing the features to be disabled. Like an "ACK, I know I miss that dependency" for missing dependencies. This would also work for systems that have a feature but it shouldn't be installed. I guess @glima had to remove icu to test the fallback path and that's not good.
@dorileo, would you come with a recommended way to do it and apply for icu, setlocale and newlocale?

Yeah, ideally this warning should be in the config menu. @dorileo, will you help on that? I can put in it my TODO if yours is already too big.

I'm looking at it...

I've talked to @glima and we found out that we really want to warn the user about the lacking of i18n support and so - since it considerably changes the overall module behavior. But we came up with a solution to better display this kind of warnings, I agree the #waning solution doesn't seem right and elegant, but we'll introduce something like obj-{mod}-warning to the build system, so we can properly display these messages to the user. I'm working on the solution.

from a user point of view, I'd be interested to know how to fix the problem...

Install ICU development packages.

hi @glima
I'll guess what @davidmaxwaterman  is mostly concerned about the message to be displayed, in that matter we can change the warning message to inform the user to install ICU dev packages...

Okay, fair. I'll add that.

@dorileo this warning shouldn't exist if the user disabled the support for some module. It's like the old autotools:

if want_XXX && !have_XXX: fail or warn;
if want_XXX && have_XXX: success;
if !want_XXX && (!have_XXX || have_XXX): success, no warnings.

Then the code and Makefiles will use "want_XXX" not "have_XXX" tests.
We should add the "have_XXX" as Kconfig always-visible items, then users will know they are missing some dependency and they can't enable a certain feature, such as "--- Use ICU", then go to its help and see "depends on HAVE_ICU".

absolutely...

The pull request #501 adds the basic infra for the warnings, we still need to adjust the configuration entries to comply with the "Use ICU" thing @barbieri  requested.

ping
I guess this is done in master.

Yes, closing.


Remove .with_current_subscriber() calls

Those calls were introduced in e5570956758503a8f0a7ed0ad1c649909f370a73,
with message:
Now, when the driver spawns a task to run a new future on it, that
future will use the same subscriber as the code that spawned the task in
the first place.

There is unfortunately no explanation about when it is necessary.
I don't see any problems after removing those - logs are still collected correctly using a tracing subscriber.
Those calls however have a harmful side-effect: they prevent usage of log loggers to listen to driver logs using log feature in tracing crate, which was reported in https://github.com/scylladb/scylla-rust-driver/issues/860 .
After reporting the problem to tracing crate (https://github.com/tokio-rs/tracing/issues/2913) one of maintainers said that using .with_current_subscriber() in a library is not necessary in general.
As I don't see any issue caused by removing these calls, but their existence cause an issue, they are removed in this PR.
The PR also introduces an example showing usage of the driver with env_logger and adjusts documentation about logging.
Fixes: #860
@piodul if you remember why those calls were added please explain, because I have no idea in which scenario they could be necessary.
Pre-review checklist

[x] I have split my patch into logically separate commits.
[x] All commit messages clearly explain what they change and why.
[ ] I added relevant tests for new features and bug fixes.
[x] All commits compile, pass static checks and pass test.
[x] PR description sums up the changes and reasons why they should be introduced.
[ ] I have provided docstrings for the public items that I want to introduce.
[x] I have adjusted the documentation in ./docs/source/.
[x] I added appropriate Fixes: annotations to PR description.

@piodul if you remember why those calls were added please explain, because I have no idea in which scenario they could be necessary.

I'm not entirely sure. I might have discussed the original problem long ago with Gor and/or @wprzytula. I think it might have been necessary for the cpp driver.
One explanation that comes to my mind is:

You spawn a task with a subscriber which is different than the global one,
You create a session in that task,
For me, it sounds reasonable that the tasks spawned internally by the session should inherit the tracing subscriber of the task that the session was created in. Without .with_current_subscriber(), that wouldn't be the case.

If I understand correctly this is not in issue when global default subscriber is used, because it is a default for all threads. This is what cpp-rust-driver currently does.
To make sure, I've partially updated cpp-rust-driver to use current rust driver and run examples/basic (with added cass_log_set_level(CASS_LOG_TRACE) at the beggining of main).
Logs are properly printed both with main and this PR.

Cargo.lock.msrv needs to be updated. Otherwise, looks acceptable to me, although I'm still reluctant to believe that cpp-rust-driver's logging really works without those calls; they really had some purpose and I feel that there is some trap that we forget about.

If there is something that I didn't notice I'd prefer to work around it in cpp-rust-driver (even if it's inconvenient or even requires a patched version of the driver) rather than break the experience for Rust Driver users.


Added custom variable toc-own-page

I have created a new custom variable toc-own-page to let the content begin on a new page after toc. I haven't found an existing option to make this possible.

A little note: You can always insert \pagebreak or \newpage in your markdown document directly. However, these commands would appear as plain text when converting to other formats.


add git init condition to prevent init inside an existing git repository

after fixing the git init condition for repo in #551 , I realized that now we'll git init, even inside an existing git repository.
So add a condition to prevent that - I suspect this would be the desired case for everyone.   If you're creating a standalone cookbook/etc you wouldn't be in a git repo.  If you're not, you would (or might)

The cookbook generator already does the right thing:
if context.have_git
  if !context.skip_git_init

Let's re-use that?

that sounds like a better idea for sure - didn't see it in use. :)
On Tue, Oct 6, 2015 at 2:16 PM, Dan DeLeo<EMAIL_ADDRESS>wrote:

The cookbook generator already does the right thing:
if context.have_git
if !context.skip_git_init
Let's re-use that?
—
Reply to this email directly or view it on GitHub
https://github.com/chef/chef-dk/pull/553#issuecomment-145951920.


⚠ Digital Ocean - https://status.digitalocean.com/ has degraded performance

In 8499c46, Digital Ocean - https://status.digitalocean.com/ (https://status.digitalocean.com/api/v2/status.json) experienced degraded performance:

HTTP code: 200
Response time: 130 ms

Resolved: Digital Ocean - https://status.digitalocean.com/ performance has improved in 150e3fe.


Added Italian Translation

Added complete Italian Translation for the module (Italian Native Speaker).
Ran the code into a spellcheck, shouldn't be any typos.
Feel free to comment if I missed anything ✌🏻 .

Codecov Report

Merging #254 (4ad4cf4) into develop (bca39bd) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           develop      #254   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           39        39
  Lines         5345      5345
  Branches      1243      1160   -83
=========================================
  Hits          5345      5345

Flag
Coverage Δ

unittests
100.00% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

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 bca39bd...4ad4cf4. Read the comment docs.


[#29] Add RCU-based node synchronization

Description

Added RCU mechanism to synchronize nodes to improve throughput for read-heavy workloads.
Related issue(s)
#29

:white_check_mark: Checklist for your Pull Request

Related changes (conditional)

Tests

[x] If I added new functionality, I added tests covering it.
[x] If I fixed a bug, I added a regression test to prevent the bug from
silently reappearing again.

Documentation

[ ] I checked whether I should update the docs and did so if necessary:

README

Public contracts

[x] My changes doesn't break project license.

Stylistic guide (mandatory)

[x] My code complies with the styles guide.

[x] My commit history is clean (only contains changes relating to my
issue/pull request and no reverted-my-earlier-commit changes) and commit
messages start with identifiers of related issues in square brackets.
Example: [#42] Short commit description
If necessary both of these can be achieved even after the commits have been
made/pushed using rebase and squash.

Before merging (mandatory)

[x] Check target  branch of PR is set correctly

RCU implementation benchmark results
reads=100%,writes=0%
BenchmarkCache/Zipf_Theine_reads=100%,writes=0%-8               10349106               112.6 ns/op         8884000 ops/s               0 B/op          0 allocs/op
BenchmarkCache/Zipf_Ristretto_reads=100%,writes=0%-8            49931085                23.92 ns/op       41810856 ops/s              16 B/op          1 allocs/op
BenchmarkCache/Zipf_Bigcache_reads=100%,writes=0%-8             28777293                38.36 ns/op       26065651 ops/s              96 B/op          2 allocs/op
BenchmarkCache/Zipf_Fastcache_reads=100%,writes=0%-8            39766262                30.36 ns/op       32937979 ops/s              47 B/op          0 allocs/op
BenchmarkCache/Zipf_Otter_reads=100%,writes=0%-8                235988992                4.341 ns/op     230386735 ops/s               0 B/op          0 allocs/op

reads=75%,writes=25%
BenchmarkCache/Zipf_Theine_reads=75%,writes=25%-8               11396006               110.0 ns/op         9086818 ops/s               0 B/op          0 allocs/op
BenchmarkCache/Zipf_Ristretto_reads=75%,writes=25%-8            26357984                43.93 ns/op       22764242 ops/s              27 B/op          1 allocs/op
BenchmarkCache/Zipf_Bigcache_reads=75%,writes=25%-8             17619958                61.52 ns/op       16255889 ops/s             106 B/op          1 allocs/op
BenchmarkCache/Zipf_Fastcache_reads=75%,writes=25%-8            20699691                53.26 ns/op       18777461 ops/s              43 B/op          0 allocs/op
BenchmarkCache/Zipf_Otter_reads=75%,writes=25%-8                175828222                6.885 ns/op     145241010 ops/s               2 B/op          0 allocs/op

reads=50%,writes=50%
BenchmarkCache/Zipf_Theine_reads=50%,writes=50%-8               13321800                88.12 ns/op       11347991 ops/s               0 B/op          0 allocs/op
BenchmarkCache/Zipf_Ristretto_reads=50%,writes=50%-8            24131536                46.66 ns/op       21430106 ops/s              34 B/op          1 allocs/op
BenchmarkCache/Zipf_Bigcache_reads=50%,writes=50%-8             15962000                64.46 ns/op       15513236 ops/s             111 B/op          1 allocs/op
BenchmarkCache/Zipf_Fastcache_reads=50%,writes=50%-8            22703031                52.41 ns/op       19081654 ops/s              39 B/op          0 allocs/op
BenchmarkCache/Zipf_Otter_reads=50%,writes=50%-8                98488806                12.23 ns/op       81767462 ops/s               6 B/op          0 allocs/op

reads=25%,writes=75%
BenchmarkCache/Zipf_Theine_reads=25%,writes=75%-8               13288441                93.63 ns/op       10680849 ops/s               0 B/op          0 allocs/op
BenchmarkCache/Zipf_Ristretto_reads=25%,writes=75%-8            18387763                60.40 ns/op       16555249 ops/s              58 B/op          1 allocs/op
BenchmarkCache/Zipf_Bigcache_reads=25%,writes=75%-8             15162562                68.59 ns/op       14578993 ops/s             196 B/op          0 allocs/op
BenchmarkCache/Zipf_Fastcache_reads=25%,writes=75%-8            26483512                47.32 ns/op       21130859 ops/s              23 B/op          0 allocs/op
BenchmarkCache/Zipf_Otter_reads=25%,writes=75%-8                52577490                21.35 ns/op       46847349 ops/s              10 B/op          0 allocs/op

reads=0%,writes=100%
BenchmarkCache/Zipf_Theine_reads=0%,writes=100%-8               29246624                40.11 ns/op       24930841 ops/s               0 B/op          0 allocs/op
BenchmarkCache/Zipf_Ristretto_reads=0%,writes=100%-8             9018708               130.6 ns/op         7656527 ops/s             122 B/op          3 allocs/op
BenchmarkCache/Zipf_Bigcache_reads=0%,writes=100%-8             13730578                81.44 ns/op       12279430 ops/s             262 B/op          0 allocs/op
BenchmarkCache/Zipf_Fastcache_reads=0%,writes=100%-8            24452991                47.78 ns/op       20928754 ops/s               0 B/op          0 allocs/op
BenchmarkCache/Zipf_Otter_reads=0%,writes=100%-8                10735712               121.4 ns/op         8236607 ops/s              64 B/op          1 allocs/op

Considering that cache loads are usually read-heavy, even reads=50%,writes=50% are rare, and otter starts degrading only under very heavy write load, the results are just great.


some packages not respecting VCPKG_TARGET_TRIPLET on macOS

Describe the bug
I am using a custom triplet to set the minimum macOS deployment target. In CMakeLists.txt, I have:
set(VCPKG_TARGET_TRIPLET "x64-osx-min10.14")

However some packages ignore this and revert to the default x64-osx triplet.
Environment

OS: macOS 10.15
Compiler: Apple Clang

To Reproduce
Steps to reproduce the behavior:

Create custom triplet
Set VCPKG_OVERLAY_TRIPLETS and VCPKG_TARGET_TRIPLET from CMakeLists.txt
Add zstd or qtbase to manifest

Expected behavior
VCPKG_TARGET_TRIPLET is used for all packages.
Failure logs
https://github.com/mixxxdj/mixxx/runs/3912521801?check_suite_focus=true#step:17:921

So any port with a host dependency will ignore VCPKG_TARGET_TRIPLET

No. The port will use the target triplet as expected.
The host dependency will use the host triplet.
In the zstd case, it is cheap. (Only some cmake files.)
In the qtbase case, it pulls in a lot of binary stuff. Some port will be builld both for host and target.

This issue hasn’t been updated in 3 month, if it is still an issue, please reopen this issue.


Migrate to nunit 4

This includes the changes necessary to make the unit tests compile against NUnit 4.0.
I converted one set of tests to the Constraint style, as an example.
The rest I simply switched to the ClassicAssert class, which is the new location of all of the old assert methods.
No functional changes were made to any tests.
This supersedes #252 opened by Dependabot.
This also includes the changes from #255, which I opened a little while ago (this branch is branched from that commit).

I went ahead and converted a few more tests, just to demonstrate more concepts in the somewhat more complex test cases in BorderColorTests, over properties of collections and such. 🤷♂

Great stuff, I will try and port this to the v2 branch too (for supporting Terminal.Gui 2.0.0)

v2 now has latest dependency too 505305bdd5f0b49cd126d076e45c0d1d081a23ee
I didn't merge directly since test cases have diverted in updating Terminal.Gui 1 to 2 version compatibility so am missing some of the Assert..That goodness (see v2.x Breaking Change Thread).  But I will start using that now in the v2 branch which is where I am focusing effort at the moment <3 .

Ah ok.
I just converted another test class in v1 on my same branch as was in the PR.
Don't bother with it, though. I'll branch from your v2 work and do future work in there instead. If the changes I made to that test class still apply in v2, I'll merge them over, but, if not, it was only like 15 minutes, so no biggie. :)
I had a feeling I probably should have focused on v2 from the start, but I didn't listen to myself, so my bad. 😅


Cairo 2 migration : library status

Starknetid.js ✅
Users need to use version 3.0.12of the package to be able to use starknetid.js on mainnet and testnet
In progress :

[x] Handle the difference between testnet and mainnet inside the package so users can use the latest version (in progress)
[x] Add Sepolia network support

On migration day :

[x] Update getAddressFromStarkName, getStarknetId and getProfileData

Starknet-react ✅
All good now, with the new version of starknet-react
Done :

[x] Handle the difference between testnet and mainnet inside useStarkProfile hooks so users can use the latest version
[x] Update useStarkAddress to fetch the contract instead of using starknet.js getAddressFromStarkName function
[x] Add Sepolia network support

On migration day :

[x] Update useStarkProfile
[x] When Starknet.js function getAddressFromStarkName is up to date, update useStarkAddress

Starknet.js ✅
Works with latest version of cairo contracts on both testnet and mainnet, starting with version 6.3.0 of starknet.js
Done:

[x] Handle the difference between testnet and mainnet inside the package so users can use the latest version (en cours) for getAddressFromStarkName and getStarkProfile functions
[x] Add Sepolia network support
[x] Update tests that our outdated
[x] Add getStarkProfile function

On migration day :

[x] Update getAddressFromStarkName and getStarkProfile functions

Closing this issue as all the libraries were updated after the cairo2 migration.


Potential Security Issue: Cross-Site Request Forgery (CWE-352)

✍ Description
Hi, there is a GET CSRF vulnerability that allow low priviledged users like authors to deactivate plugins.
In bl-kernel/admin/controllers/uninstall-plugin.php
/**/
checkRole(array('admin'));
/**/
$pluginClassName = $layout['parameters'];
deactivatePlugin($pluginClassName);
Redirect::page('plugins');

The server only checks if the request comes from an admin, and doesn't perfom CSRF checks.
🕵♂ Proof of Concept

Create an author user
Create a new post and embed this URL as an image http://<IP_ADDRESS>/bludit/admin/uninstall-plugin/pluginAbout to deactivate the About plugin for example
Login as the admin and visit the newly created post
Visit http://<IP_ADDRESS>/bludit/admin/plugins and see the plugin deactivated

💥 Impact
Pretty low impact, authors can just deactivate plugins and interfere with the functioning of the website
References
https://github.com/bludit/bludit/blob/aa1dee1d30f56a0e27c943ecfc39ceb5b56d5611/bl-kernel/admin/controllers/uninstall-plugin.php#L25

If you would like the security researcher who found this vulnerability to be rewarded for his work, please simply reply valid/invalid. Thank you for your time, and please let me help you with any questions!

Hello, with the new version of Bludit v4.0 rc1, I would like to close the old Github issues. If you feel that your issue is not resolved in the latest version, create a new ticket.

Help and Support use the Forum https://forum.bludit.org
Bugs and new requests here in Github https://github.com/bludit/bludit/issues


Fix S3FileLoader local file clobbering

Fixes #735; remove unnecessary call to storeFile(), a remnant from the aws-doc-sdk-examples transferOnStream.cpp example, where this function is used to verify the buffer's contents: https://github.com/awsdocs/aws-doc-sdk-examples/blob/main/cpp/example_code/transfer-manager/transferOnStream.cpp#L131
Changes

remove unnecessary call to storeFile()

Testing
Verified files are no longer clobbered through local testing

Based on the test failures, it seems like an extra file was added to the s3://ai2-public-datasets/ bucket... shall I go ahead and update 77->78 and 39->40?

Based on the test failures, it seems like an extra file was added to the s3://ai2-public-datasets/ bucket... shall I go ahead and update 77->78 and 39->40?

Yea. And, I personally think the test failures are unrelated to your PR. To guarantee the changes in this PR, let's wait until my PR is landed and rebase this PR to main branch afterwards. Thank you

@ringohoffman Do you mind rebasing your commits onto main branch?


Add test cases of autorest extension.

Description
Add test cases of autorest extension.
Test cases

datamodels-enums
extension-ms-*
directive-*

@dolauli
The test case has been completed. Include directives and extensions.


Provide the ability to give a timeout to adaptive auth script evaluation

Describe the improvement
As of now, during the adaptive authentication, we execute the provided script and wait for the completion. However, this may be problematic if,

Script is calling a slow endpoint and wait for response frequently
Script has infinite loops/recursions added mistakenly

Additional context
To fix this, we would need to setup a reasonable timeout for the script execution and terminate the execution forcefully after the timeout.

This issue is being closed due to extended inactivity. Please feel free to reopen it if further attention is needed. Thank you for helping us keep the issue list relevant and focused!


Create an abstract type for k-armed bandit stationary agents

These are defined in Section 2.1 of Sutton & Barto.  They can be deterministic, but importantly there can be noise, and arbitrary.  The chapter uses normal noise, but Rina Dechter in her slides uses a different distribution for each action.  This generality would be worth capturing.
After we have that, our Car should become the implementation of this interface, not of Agent or SimpleAgent.

The Car has been made statefull in the meantime, so moving it to the SimpleBandit hierarchy no longer makes sense.

closed in issue #101


production Level

which modules should we modify or pay attention to bring Peggy to the production level?
why do you mention that Peggy is not of production level, is it due to the lack of security or efficiency?
Basically, what are the functionalities that the Peggy currently lack and make it unsuitable for the production?

@yash-fb would love to speak to you about this.  Is there some sort of roadmap we can look at?
Me and a few friends are curious as to what needs to be done to make this happen. : )


Remove Gcloud.devserver

Remove convenience method and env vars for local devserver support.
The only way to specify a devserver is through DATASTORE_HOST.
Update CONTRIBUTING guide with demonstration of using DATASTORE_HOST.

LGTM -- I wonder if it would be useful to optionally provide the host as an argument to gcloud.datastore. Then you could write a unittest setUp method that forced a localhost. But totally up to you.

@pcostell I like the symmetry we have with datastore and storage and pubsub all taking the same parameters, project/dataset id and credentials/keyfile. In addition to setting the DATASTORE_HOST environment variable we could expose and support the http_host attribute on Dataset. Right now it isn't exposed on the public API.
dataset = Gcloud.datastore "test123", "path/to/keyfile.json"
dataset.http_host = "http://localhost:8080"
entity = dataset.find "Thing", 789

@blowmage Sounds fine to me.

Recording some additional thoughts here. What I don't like about that approach is that changing the host is mutable state and that could have some adverse consequences later. We could stretch to support the following signature:
dataset = Gcloud.datastore
dataset = Gcloud.datastore "test123"
dataset = Gcloud.datastore "test123", "path/to/keyfile.json"
dataset = Gcloud.datastore "test123", "path/to/keyfile.json", host: "http://localhost:8080"
dataset = Gcloud.datastore "test123", host: "http://localhost:8080"
dataset = Gcloud.datastore host: "http://localhost:8080"

I'm gonna accept this as-is. If we want to support more options for specifying the host beyond DATASTORE_HOST then we should treat that as a separate enhancement.


[event-hubs] Create a migration guide from EventHubs v2 To v5

EventHubs has changed enough that it'd be useful to have a migration guide.
We want to model it after this existing guide for storage:
https://github.com/Azure/azure-sdk-for-java/blob/master/sdk/storage/azure-storage-blob/migrationGuides/V10_V12.md
The core scenarios we want to cover:

[x] EventProcessHost -> EventHubConsumerClient.subscribe
[x] .send -> EventHubProducerClient
[x] .receive/.receiveBatch -> EventHubConsumerClient.subscribe

@richardpark-msft Yes please! Additionally is there a blog post or slack group where I could try and keep abreast of the evolution of the API through the 5.preview versions?

@hally9k  - no slack group but, of course, we do respond to issues on our github repo. :)
Since I've got you here - can you give me an idea of which classes you're using in the current eventhubs library? Want to make sure we're covering common use cases.

@richardpark-msft We are currently using 5.0.0.preview.6:
EventHubProducerClient,
EventHubConsumerClient,
ReceivedEventData,
PartitionContext,
PartitionCheckpointer,
Subscription,
EventPosition
I am gearing up to do the jump to preview.7 but there is a lot of movement in the API and I'm struggling to find a good understanding of this evolution path.

@hally9k
The previews have been a bit fast moving as of late - a large part of our
API reviews have uncovered some inconsistencies or areas that needed
improvement.
We don't have a guide for moving from preview to preview, unfortunately, but
I can give you a brief summary of the changes (and why):

We moved consumerGroupName and CheckpointStore to the constructor for EventHubConsumerClient, rather than being in the subscribe call.
The goal here was to make it so the consumer client a consistent launch point
for a set of subscriptions (using the same consumer group, same
checkpoint store). This makes it so if you subscribe() multiple times off the
same client they will be consistent with each other.

The PartitionManager's were all renamed to CheckpointStore to be a bit more
exact on what the class actually did. (PartitionManager seemed too generic).

The processError handler that you pass into subscribe via
your SubscriptionEventHandlers became mandatory.
Subscriptions tend to be long-lived which means that the errors that occur
might fly under the radar - for instance, if we have issues talking to your
backend storage account, etc.. So we wanted to make sure that users took
that into account and at least logged or tried to handle errors.

Some renames:

Anything date related (ie: enqueuedTime => enqueuedOn). This was
primarily for consistency with the other language SDKs.
PartitionContext.consumerGroupName => PartitionContext.consumerGroup


Fix bad cases of const sharing

Fixes #56306
By itself it mostly fixes the issue, but it depends on #56337 to fix it completely.

Hmm, it seems std::signbit is platform-specific.

Since https://github.com/godotengine/godot/pull/56337 is merged, what's the status on this? Can it be merged?

We discussed this briefly with @vnen and @cdemirer today, if we properly made const arrays/dictionaries read only (which is now possible with #61127), this problem might be fixed at least for those types.

As this is not urgent per se, I will set the milestone to 4.x, but I will add the PR to the list of PRs to review.

Possibly minimal tests:
assert(0.0 != -0.0)
assert(-0.0 != 0.0)
assert(0.0 == 0.0)
assert(-0.0 == -0.0)

var arr_1 : Array[Node2D] = []
var arr_2 : Array[Node3D] = []
var arr_3 : Array[Node2D] = []
assert(arr_1 != arr2)
assert(arr_1 == arr3)
assert (arr_2 != arr3)

var arr_1 : Array[Node2D] = []
var arr_2 : Array[Node3D] = []
var arr_3 : Array[Node2D] = []
assert(arr_1 != arr2)
assert(arr_1 == arr3)
assert (arr_2 != arr3)

I would add assert(not is_same(arr_1, arr_3)

Bumping to the next milestone as it seems a bit risky to do this change so close to 4.2 (especially as the PR doesn't pass tests right now).


Change metric name "linear" to "linreg_pearsonr"

Change metric name "linear" to "linreg_pearsonr" given that the linear metric consists of linear regression with pearson correlation. We want to be able to create benchmarks that use different evaluation metrics and hence need naming conventions to support this.
Changed this for the metric names, but did not change the Pereira Class name (_Pereira2018ExperimentLinear) and the ceiling identifier (identifier = f'Pereira2018.{experiment}-linear'). @mschrimpf do you want to change these too such that it matches this convention (I did not want to change it to not mess up loading of ceilings/data).

Changed this for the metric names, but did not change the Pereira Class name (_Pereira2018ExperimentLinear) and the ceiling identifier (identifier = f'Pereira2018.{experiment}-linear'). @mschrimpf do you want to change these too such that it matches this convention (I did not want to change it to not mess up loading of ceilings/data).

happy to change the ceiling name if you prefer! let me know.

Changed this for the metric names, but did not change the Pereira Class name (_Pereira2018ExperimentLinear) and the ceiling identifier (identifier = f'Pereira2018.{experiment}-linear'). @mschrimpf do you want to change these too such that it matches this convention (I did not want to change it to not mess up loading of ceilings/data).

happy to change the ceiling name if you prefer! let me know.

Ok, thanks -- yes, that'd be great.

Changed this for the metric names, but did not change the Pereira Class name (_Pereira2018ExperimentLinear) and the ceiling identifier (identifier = f'Pereira2018.{experiment}-linear'). @mschrimpf do you want to change these too such that it matches this convention (I did not want to change it to not mess up loading of ceilings/data).

happy to change the ceiling name if you prefer! let me know.

Ok, thanks -- yes, that'd be great. Also, do you want to change the class name too?

up to you, I'm happy to leave as-is, but if you're going to introduce linear non-pearson benchmarks on the same data, it should probably be changed

@gretatuckute any updates on this PR?

I thought this was all set and resolved, no? We have changed the linreg nomenclature in the branch where we update the Pereira benchmarks.

Unit tests are failing though, e.g. in brainscore_language/benchmarks/pereira2018/test.py:54 (TestBenchmark.test_dummy_bad): KeyError: 'Pereira2018.243sentences-linear' (from load_benchmark(f'Pereira2018.{experiment}sentences-linear'))

Sorry, this PR was closed after combining commit history. @gretatuckute can you please open a new PR?

Sorry, this PR was closed after combining commit history. @gretatuckute can you please open a new PR? I'm afraid the simplest solution is to 1. checkout the branch locally, 2. copy all files into a separate location, 3. checkout main, 4. update main, 5. create a new branch, 6. copy all files back again overwriting the files in main, 7. push and open a PR.

Hm, I think we might want to merge these edits with the "towards adding Pereira2018ROI as a benchmark #37" PR because that was the reason the units tests were failing.

I think most of these edits are already incorporated into the former PR #37 (although not specifically by way of the commits on this PR). So when that gets merged, they will automatically make their way. The alternative is we merge this into main independently and merge main into the former #37.
What do you think is preferable?


Update JS SDK snippet

#427 -> generate and update the snippet in the Azure Portal and README.html.

Hi, is this fix in? I still dont see unhandled exceptions being tracked.


Licencing is out of date

The section under the heading Link entities in Power Apps does not contain up to date licencing information.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 474d74d7-1c4b-310e-e381-c5ef6de14f65
Version Independent ID: d8532777-57e4-51b1-306f-29cd3178bfda
Content: Link entities between dataflows
Content Source: powerquery-docs/dataflows/linked-entities.md
Service: dataflows
GitHub Login: @bensack
Microsoft Alias: bensack

Sorry for the delay on this issue. It appears that the license bit says this. Is that the problem statement?

To be refreshed, linked entities require a Power BI Premium subscription. Linked entities are available in any dataflow on a workspace that's hosted on Power BI Premium capacity. There are no limitations on the source dataflow.

Please ignore (I'm using bot automation to add labels). #please-open

Hi @binnall
Sorry for the delay in getting to this feedback. The licensing information in this article was updated some time ago, and now contains a link to more up-to-date information about Power Apps licensing. This change has made this issue moot, so I'm closing the issue.


creditCardNumber() in search API only allows one of startsWith/endsWith

When using the search endpoint, creditCardNumber(https://developers.braintreepayments.com/reference/request/transaction/search/java#credit_card_number) should ideally support both startsWith and endsWith but the correct implementation only allows filtering by one of them

Thanks for the suggestion. We will look into this.

This should be fixed in version 2.79.0. It will take a little bit to distribute throughout Maven but should be available in a couple hours.


brew update is broken due to donation note

Please fill out the issue checklist below and provide all the requested information.

[ ] ran a brew command and reproduced the problem with multiple formulae? If it's a problem with a single, official formula (not cask) please file this issue at Linuxbrew/homebrew-core: https://github.com/Linuxbrew/homebrew-core/issues/new/choose. If it's a brew cask problem please file this issue at https://github.com/Homebrew/homebrew-cask/issues/new/choose. If it's a tap (e.g. Homebrew/homebrew-php) problem please file this issue at the tap.
[x] ran brew update and can still reproduce the problem?
[x] ran brew doctor, fixed all issues and can still reproduce the problem?
[x] ran brew config and brew doctor and included their output with your issue?

If the system git is too old, brew update will report the errors similar to the below.
 $ brew update
==> Linuxbrew is run entirely by unpaid volunteers. Please consider donating:
  https://github.com/Linuxbrew/brew#donations
error: unknown option `local'
usage: git config [options]

Config file location
    --global              use global config file
    --system              use system config file
    -f, --file <FILE>     use given config file

Action
    --get                 get value: name [value-regex]
    --get-all             get all values: key [value-regex]
    --get-regexp          get values for regexp: name-regex [value-regex]
    --replace-all         replace all matching variables: name value [value_regex]
    --add                 adds a new variable: name value
    --unset               removes a variable: name [value-regex]
    --unset-all           removes all matches: name [value-regex]
    --rename-section      rename section: old-name new-name
    --remove-section      remove a section: name
    -l, --list            list all
    -e, --edit            opens an editor
    --get-color <slot>    find the color configured: [default]
    --get-colorbool <slot>
                          find the color setting: [stdout-is-tty]

Type
    --bool                value is "true" or "false"
    --int                 value is decimal number
    --bool-or-int         value is --bool or --int
    --path                value is a path (file or directory name)

Other
    -z, --null            terminate values with NUL byte

Error: Failure while executing; `git config --local --replace-all homebrew.donationmessage true` exited with 129.

This will only happen if the system git is too old to support --local flag. Noted that due to the Homebrew path filtering, brew update-report cannot find the brew git.
To workaround the issue, one can set HOMEBREW_NO_ENV_FILTERING=1. As for the fix, I would suggest:

Turn safe_system to system, for the following codes:
https://github.com/Linuxbrew/brew/blob/c918fcc1d954078f54a3475dcacc99377ec9b745/Library/Homebrew/cmd/update-report.rb#L49-L50
https://github.com/Linuxbrew/brew/blob/c918fcc1d954078f54a3475dcacc99377ec9b745/Library/Homebrew/cmd/update-report.rb#L62
brew update-report or the whole homebrew code in general should use the git shim, which is specifically designed to search the proper git executable.

My brew config:
$ brew config
HOMEBREW_VERSION: 1.7.1-356-gc918fcc
ORIGIN: https://github.com/Linuxbrew/brew.git
HEAD: c918fcc1d954078f54a3475dcacc99377ec9b745
Last commit: 15 hours ago
Core tap ORIGIN: https://github.com/Linuxbrew/homebrew-core
Core tap HEAD: c82d598bc313e228592f283b88bf163635a9f215
Core tap last commit: 16 minutes ago
HOMEBREW_PREFIX: /home/comp/chengxu/usr
HOMEBREW_REPOSITORY: /home/comp/chengxu/usr
HOMEBREW_CELLAR: /home/comp/chengxu/usr/Cellar
HOMEBREW_CACHE: /tmp/chengxu/cache/homebrew
HOMEBREW_BOTTLE_DEFAULT_DOMAIN_LINUX: https://linuxbrew.bintray.com
HOMEBREW_BOTTLE_DEFAULT_DOMAIN_MACOS: https://homebrew.bintray.com
HOMEBREW_DEVELOPER: true
HOMEBREW_FORCE_VENDOR_RUBY: true
HOMEBREW_LOGS: /tmp/chengxu/cache/homebrew/logs
HOMEBREW_NO_ANALYTICS: true
HOMEBREW_NO_AUTO_UPDATE: true
HOMEBREW_SANDBOX: true
CPU: 24-core 64-bit westmere
Homebrew Ruby: 2.3.7 => /home/comp/chengxu/usr/Library/Homebrew/vendor/portable-ruby/2.3.7/bin/ruby
Clang: 6.0 build 601
Git: 2.18.0 => /home/comp/chengxu/usr/bin/git
Curl: 7.19.7 => /usr/bin/curl
Java: N/A
Kernel: Linux 2.6.32-754.el6.x86_64 x86_64 GNU/Linux
OS: CentOS release 6.10 (Final) (Final)
Host glibc: 2.14
/usr/bin/gcc: 4.4.7
glibc: 2.23
gcc: 5.5.0_4
xorg: 20170115

Thanks for the bug report! Here's a quick fix PR https://github.com/Linuxbrew/brew/pull/821 which removes --local. The better solution is as you say is to use shims/scm/git.

Thanks again for the fixing.

No worries. Thanks for the bug report!


Produce RHEL/Centos 9 Binaries

Hello,
The Pushpin RPM repo hosted on JFrog does not have any RHEL/Centos 9 binaries. Can the project start to produce these? A lot of people are moving off of RHEL 7 and 8, and moving to 9. Also, the RHEL 6 binaries can probably be dropped now since the last of Redhat support ended on 30 Jun 2024.

I did only a few very simple tests, but it looks like the centos 8 binary does work on centos 9.


Keep naming of columns similar to names in ontology

This just took me some time to figure out, and left me with quite some confusion, so maybe it would be good to change this:
The names of columns in the description of the tables (e.g. formTable) are linked to properties in the ontology in terms.rdf. For clarity, I would propose to use the ontology names as column names to avoid confusion.
For example, in formTable:

"name" = "Form" can simply be changed to "name" = "LexicalUnit"
"name" = "Segments" can simply be changed to "name" = "soundSequence"

As a general rule-of-thumb, we can keep _ID instead of Reference, so we use "name" = "Language_ID" instead of the literal copy from the ontology, which would be "name" = "languageReference".
Of course these are just names, and they have to be explicitly referenced in the meta-data of each dataset, so you can change it to whatever you want. However, in the description of the CLDF I think it is better to make this easier to grasp immediately.
If you agree, I'll make a pull request with such changes

Unfortunately, this is not a simple change of cldf, but it'll require to change the converter to PDF in Lingpy and a couple of other things. LexicalUnit is the term by GOLD as is SoundSequence. I think we may should retain the right to have better terms than GOLD has in those cases, and I'd say that both Segments and Form are better, and we had a lot of discussions in the past, on how to name those columns.

Generally, identification of columns relevant for CLDF goes by propertyUrl.
We may document the ontology somewhat better, to highlight that the
proposed column label is just one option. Using the local names of
properties in the ontology for columns may just lead to invalid shortcut
inferences - e.g. looking up names in the ontology instead of propertyUrls.
Am 26.11.2017 10:47 vorm. schrieb "Johann-Mattis List" <
<EMAIL_ADDRESS>Unfortunately, this is not a simple change of cldf, but it'll require to
change the converter to PDF in Lingpy and a couple of other things.
LexicalUnit is the term by GOLD as is SoundSequence. I think we may should
retain the right to have better terms than GOLD has in those cases, and I'd
say that both Segments and Form are better, and we had a lot of discussions
in the past, on how to name those columns.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/cldf/cldf/issues/53#issuecomment-346995959, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA1HKHNxkhVCR6D009dOPXsVZXKo-quKks5s6TOqgaJpZM4Qqtwp
.

OK, also fine with me.
However, the documentation should become clearer :-), and the Readme is already much too long.
Would you agree to a directory documentation in the CLDF? Then I'll put all lowercased .md documents from the top level in there (currently faq and wordlist), and make separate documents out of the current Readme. The new readme will then only be a short introduction with links to the various files in the documentation.
and I will add something about the column naming...

I kind of like the fact that the spec is just one page. (Faq is not core
part and wordlist is obsolete). A short introduction is the website
http://cldf.clld.org
So I'm quite happy with the status quo in terms of doc organisation. Better
wording is always welcome, though.
Am 26.11.2017 11:12 vorm. schrieb "Michael Cysouw"<EMAIL_ADDRESS>
:

OK, also fine with me.
However, the documentation should become clearer :-), and the Readme is
already much too long.
Would you agree to a directory documentation in the CLDF? Then I'll put
all lowercased .md documents from the top level in there (currently faq
and wordlist), and make separate documents out of the current Readme. The
new readme will then only be a short introduction with links to the various
files in the documentation.
and I will add something about the column naming...
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/cldf/cldf/issues/53#issuecomment-346997247, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA1HKFdWVHv0ctrC_o0OwA9idDur1LMpks5s6TmLgaJpZM4Qqtwp
.

OK, I'll send a proposal for an update to the readme


pull request for e2e test at 01/11/2017 04:45:14

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Known issues in Harbor portal of V1.1

The date format component block the datagrid view to display data on Safari of version < 10.

Proposed release note entry:

The date format component blocks the datagrid view to display data on Safari 10 and later. #2007

@steven-zou is this OK? Thanks!

Invalid now, close!


suggestions for website development

I don't have any serious problems. However, as a novice Dex user, I'm still a little confused when using it. maybe the dex website needs to be added with a question feature or given an example of how to use the dex.
and on adding liquidity, I think there needs to be a one-click feature to change from the first token on top and the second token on the bottom
and I think the background on the dex is still too plain, it needs to be redesigned to make it more attractive and look elegant
my address : 0x20365D5e968f570Ba800123531Be7FC08404862A

@bakoldungo Thank you for your suggestions, we've taken your request and noted it within our potential enhancement document list!


Agora not working in production mode on Android

I am testing to use the Agora package (https://pub.dev/packages/agora_rtc_engine) platform with the Callkeep package (https://pub.dev/packages/callkeep) ,to play a phone call.
I have created the function that generates the temporary token using node and hosting it in the Firebase cloud functions, I have tested it in development environment and the token is being generated, and I am getting the expected results in this environment.
After I build the APK, install it again and try to use the connection by APK, it does not show the same behavior and does not enter the now channel.
The token from the API:

is our example working?

were you able to fix this issue?


Modify calculation of Q to not need discretisation

See https://vknight.org/blog/posts/continuous-time-markov-chains/

done.


Add align-repository-header feature

Fixes https://github.com/sindresorhus/refined-github/issues/3280
Replaces and closes #3250
Instead of aligning both sides and limiting the available space for the tabs, this only aligns the left side

Looks like this has an adverse effect on gists
Before

After

Looks like this has an adverse effect on gists
Before

After

.repohead -> .repohead:not(.gisthead)

Looks like this breaks enterprise users: https://github.com/sindresorhus/refined-github/issues/3330

PR welcome to fix gists and #3332

How can I use this? I'm having 20.7.16 and I still see no difference...

@szmarczak Because it's broken now https://github.com/sindresorhus/refined-github/pull/3362#issuecomment-659955345


firebase-bigquery-export:schema-view Timestamps filtered out on "latest" view

[REQUIRED] Step 2: Describe your configuration

Extension name: firebase-bigquery-export/gen-schema-view
Extension version: 0.1.9

[REQUIRED] Step 3: Describe the problem
When generating a schema for the firebase bigquery export extension, Firebase Timestamp values do not show up in the latest schema but do in the changelog.
Looking in the code, there is a message that claims TIMESTAMP values can not be grouped, and are thus excluded. I feel like this may be a mistake. Here's the sample code in firestore-bigquery-export/scripts/gen-schema-view/src/schema.ts,
   // For "latest" data views, certain types of fields cannot be used in
    // "GROUP BY" clauses. We keep track of them so they can be explicitly
    // transformed into groupable types later.
    if (field.type === "array") {
      arrays.push(qualifyFieldName(prefix, field.name));
    }
    if (field.type === "geopoint") {
      geopoints.push(qualifyFieldName(prefix, field.name));
    }

     if (field.type === "timestamp") {
       timestamps.push(qualifyFieldName(prefix, field.name));
     }

I don't understand why this applies to timestamps (it's very possible I simply am ignorant on the subject -- I'm no SQL expert). When I comment out the timestamp clause, the schemas and resulting views work exactly as expected, with SQL Timestamp values where I had registered a timestamp in my schema.
Steps to reproduce:

Create a firestore collection with a timestamp field.
Create a schema.json file for this collection and register the timestamp field.
Run the generate-schema-view script
Notice the timestamp does not show up when you execute a select statement on the resulting _latest view.

My "fix"
Simply remove the if statement schema.ts that adds timestamp values to the exclusion array.

Hey @Neilpoulin, thanks for raising the issue. You're correct, I'll be making a PR that will allow the timestamp to come through in the appropriate column that was mapped in the schema for the "latest" View.


Depressing Pug Picture

So, after I put in a "pug me" command, one of the pictures I got back was this one:
http://29.media.tumblr.com/tumblr_lix7oiibrm1qbx3hwo1_500.jpg
It was a bit startling to see an abused, emaciated pug come up, and I was wondering if there was any way to maybe edit the pug picture base (wherever that is).

Unfortunately not something we have much control over: https://github.com/hubot-scripts/hubot-pugme/blob/master/src/pugme.coffee
@technicalpickles do you know anything about the Heroku app?

I've tried to track it down at different points, but either I've forgotten or never found it :sweat:  I think at best we can filter that URL in the pugme script though, but it's not something we can do in this repo.
cc @maddox as someone who might now about pugme.herokuapp.com?

:+1: Took care of it. No more sad pugs.


Wrong temperature conversation

Hi,
just updated to newest docker container and recognized it shows radiator temp of 157°C.
App tells me it's 15.70°C.
So I assume there is a need of division by 10.
I'm running a mirco. Is it the same for string?
Or do we need here a type dependent conversion?

Hi @geeks-r-us
It's very likely caused by the change implemented in this PR https://github.com/kbialek/deye-inverter-mqtt/pull/18/
@Antagor has suggested that the conversion shall be different for micro inverters. Now it turns out that it's not entirely true.

Hello,
@geeks-r-us : Have you updated your enviroment for the inverter-type ?
Which inverter do you have?
Can it be a problem of the firmware? that deye has changed the conversation of the temp?
Wich temp you had before our change? It couldn't be right as we have added an additional divisor for micro.
bye Antagor

Hi
@Antagor  yes I set it to micro.
I have the Deye SUN1300G3  it's on:

communication protocol: <IP_ADDRESS>
DC Master: <IP_ADDRESS>
DC Slave: <IP_ADDRESS>
AC: <IP_ADDRESS>

After a look in my influx bucket it seem temperature was not right before the update but haven't had it on my dashboard...

@geeks-r-us
Hey
Can you send a debug log. It makes no sense to me: we added an additional divisivor for micro, because I had the same problem. So the new version should divide by 100 for micro.
Do you have daily and total values for the panels? Otherwise you have an old image.
Antagor