Cannot pay with PayPal with PrestaShop module

Description
Receiving
Error: Error: PayPal payment options are invalid. at Object._RECEIVE_MESSAGE_TYPE.(anonymous function) [as postrobot_message_response] (https://www.paypalobjects.com/api/checkout.js:3158:31) at receiveMessage (https://www.paypalobjects.com/api/checkout.js:3055:77) at messageListener (https://www.paypalobjects.com/api/checkout.js:3076:13)
when clicking Pay with PayPal button

PayPal 4.3.1 for PrestaShop installed from plugin manager
paypal.version = "4.0.178"
The exact browser version
A link to your page with the issue, if possible
Console logs

api.braintreegateway.com/merchants/ysycg43zmy28yyjg/client_api/v1/paypal_hermes/setup_billing_agreement Failed to load resource: the server responded with a status of 422 (Unprocessable Entity)
checkout.js:5070 ppxo_unhandled_error Objectcountry: "IT"env: "production"errtype: "[object Error]"host: "www.paypal.com"lang: "it"pageID: "335bd16825"path: "/webapps/hermes/button"prev_corr_ids: ""referer: "https://www.relevent.it"stack: "Error: PayPal payment options are invalid.
at Object._RECEIVE_MESSAGE_TYPE.(anonymous function) [as postrobot_message_response] (https://www.paypalobjects.com/api/checkout.js:3158:31)
at receiveMessage (https://www.paypalobjects.com/api/checkout.js:3055:77)
at messageListener (https://www.paypalobjects.com/api/checkout.js:3076:13)"timestamp:<PHONE_NUMBER>149uid: "b129622655_ge3dunbvhizdg"ver: "4.0.178"windowID: "ed5bd8e9bd"proto: Object
window.console.(anonymous function) @ checkout.js:5070
checkout.js:8825 Uncaught Error: PayPal payment options are invalid.
at Object._RECEIVE_MESSAGE_TYPE.(anonymous function) [as postrobot_message_response] (https://www.paypalobjects.com/api/checkout.js:3158:31)
at receiveMessage (https://www.paypalobjects.com/api/checkout.js:3055:77)
at messageListener (https://www.paypalobjects.com/api/checkout.js:3076:13)

The issue occurs consistently

Steps to reproduce
Register to https://relevent.it and put a product into the cart.
Go to checkout and fill your data.
Select PayPal as payment method
Click PayPal button
you get the error
Affected browsers

[X] Chrome
[X] Safari
[X] Firefox
[X] Edge
[X] IE
[X] Chrome Mobile/Tablet
[X] Safari Mobile/Tablet
[X] Web View / Safari ViewController
[X] Other

Can you please share your code?


[Bug] SchemaViolationException frequently

Describe the bug
Hello, I still encounter this occasional exception frequently. Every time it occurs, the execution result of the tool will lack many Results that should originally exist, and the number of the log [INFO ] Enhancement io.joern.console.scan.ScanPass completed in 4450 ms. 130  + 650 changes committed from 25 parts. changed.
To Reproduce
Here is a project that can be reproduced frequently (an average of 1 time in 4 executions), which can be tested based on this project.
https://github.com/Haptic-Apps/Slide
Steps to reproduce the behavior:

git clone

git clone https://github.com/Haptic-Apps/Slide

exec cmd

/data/test/joern-cli/joern-scan Slide/ --names=too-many-params --language=java --overwrite

Expected behavior
It is expected that no exception will be reported when running, and the number of execution results will be stable.
Screenshots
Caused by: overflowdb.SchemaViolationException: OUT edge with label AST to an adjacent METHOD_RETURN is mandatory, but not defined for this METHOD node with id=134
        at io.shiftleft.codepropertygraph.generated.nodes.MethodDb.methodReturn(Method.scala:660)
        at io.shiftleft.codepropertygraph.generated.nodes.Method.methodReturn(Method.scala:286)
        at io.joern.x2cpg.passes.controlflow.cfgcreation.CfgCreator.<init>(CfgCreator.scala:55)
        at io.joern.x2cpg.passes.controlflow.CfgCreationPass.runOnPart(CfgCreationPass.scala:23)
        at io.joern.x2cpg.passes.controlflow.CfgCreationPass.runOnPart(CfgCreationPass.scala:17)
        at io.shiftleft.passes.ConcurrentWriterCpgPass.$anonfun$createApplySerializeAndStore$2(ParallelCpgPass.scala:252)
        at scala.concurrent.Future$.$anonfun$apply$1(Future.scala:678)
        at scala.concurrent.impl.Promise$Transformation.run(Promise.scala:467)
        at java.base/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1426)
        at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
        at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
        at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
        at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
        at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
Caused by: java.util.NoSuchElementException: next on empty iterator
        at scala.collection.Iterator$$anon$19.next(Iterator.scala:966)
        at scala.collection.Iterator$$anon$19.next(Iterator.scala:964)
        at scala.collection.Iterator$$anon$7.next(Iterator.scala:528)
        at overflowdb.traversal.Traversal.next(Traversal.scala:22)
        at io.shiftleft.codepropertygraph.generated.nodes.MethodDb.methodReturn(Method.scala:655)
        ... 13 more

Desktop (please complete the following information):

OS
centos 7.9
Joern Version
commit id: https://github.com/joernio/joern/commit/55c51179490823638087e5614f6775b9c75e57ec
2023/10/20
Java version
openjdk version "17.0.7" 2023-04-21 LTS
OpenJDK Runtime Environment TencentKonaJDK (build 17.0.7+1-LTS)
OpenJDK 64-Bit Server VM TencentKonaJDK (build 17.0.7+1-LTS, mixed mode, sharing)

Additional context
Add any other context about the problem here.

Any reason why you are using that specific (quite old) joern version?
Could you try the latest joern and jdk 19?

Any reason why you are using that specific (quite old) joern version?
Could you try the latest joern and jdk 19?

I used the latest versions of joern v2.0.285 and jdk19 for testing, but the problem still exists. And there are many java.lang.ArrayIndexOutOfBoundsException and java.lang.NullPointerException exceptions.

Maybe @johannescoetzee can help.

@cyw3 Thanks for the report! I've managed to reproduce the issue and am looking into it now.

It looks like this might be a joern-scan bug instead of a javasrc2cpg one. As a test, I ran
./joern-scan --names=too-many-params --language=java ~/path/to/Slide --store --overwrite

which did throw all the errors mentioned above. I then opened the cpg in joern with
joern> open("Slide")
val res4: Option[io.joern.console.workspacehandling.Project] = Some(
  value = Project(
    projectFile = ProjectFile(inputPath = "/path/to/Slide", name = "Slide"),
    path = /path/to/joern/workspace/Slide,
    cpg = Some(value = Cpg (Graph [442599 nodes]))
  )

followed by
joern> import io.joern.scanners.c.Metrics

joern> import io.joern.console.scan.QueryWrapper

joern> val query = Metrics.tooManyParameters(4)
val query: io.joern.console.Query = Query(
  name = "too-many-params",
  author = "@fabsx00",
  title = "Number of parameters larger than 4",
  description = "This query identifies functions with more than 4 formal parameters",
  score = 1.0,
  traversal = io.joern.scanners.c.Metrics$$$Lambda/0x00007fa7688293f0@76e463d3,
  traversalAsString = """{ cpg =>
        cpg.method.internal.filter(_.parameter.size > n).nameNot("<global>")
      }""",
  tags = List("metrics"),
  language = "",
  codeExamples = CodeExamples(
    positive = List(
      """

int too_many_params(int a, int b, int c, int d, int e) {

}

"""
    ),
    negative = List(
      """

void good(int a, int b, int c, int d) {

}

"""
    )
  ),
  multiFileCodeExamples = MultiFileCodeExamples(positive = List(), negative = List())
)

joern> new QueryWrapper(query).apply(cpg).size
val res5: Int = 329

without throwing any errors. Thinking this might have just been a lookup from the pre-applied scan overlay, I tried the query on a fresh Slide cpg, but with the same result.

@fabsx00 do you have any ideas for what could be going on here?

This issues isn't limited to this specific project or query either. I got similar errors for the shiftleft-java-demo project and the too-high-complexity query

I guess the issue should be in the ScanPass then.
Also the log says: [INFO ] Enhancement io.joern.console.scan.ScanPass completed in 4450 ms. 130  + 650 changes committed from 25 parts.
Something in that pass results in a broken CPG here.

Hello,
I would like to report that I also encounter the issue of SchemaViolationExceptions but in a different context. It also occurs when I calculate Dataflows in C/C++. The program doesn't crash but I receive inconsistent flows. My query roughly looks like this:
implicit val resolver = NoResolve
val sources = cpg.call.where(_.callee.isExternal)
val sinks = cpg.call.where(_.callee.isExternal)
val flows = sinks.reachableByFlows(sources).l

This is my environment:

OS: ubuntu:23.10 (docker)
joern: v2.0.309
java: openjdk-19
scala: 3.3.0
test object: curl @ 81d135d67155c5295b1033679c606165d4e28f3f

I receive the following stack traces:
java.util.concurrent.ExecutionException: overflowdb.SchemaViolationException: IN edge with label AST to an adjacent METHOD is mandatory, but not defined for this METHOD_PARAMETER_IN node with id=11362
        at java.base/java.util.concurrent.ForkJoinTask.reportExecutionException(ForkJoinTask.java:581)
        at java.base/java.util.concurrent.ForkJoinTask.get(ForkJoinTask.java:993)
        at io.joern.dataflowengineoss.queryengine.Engine.runUntilAllTasksAreSolved$1$$anonfun$1(Engine.scala:99)
        at scala.util.Try$.apply(Try.scala:210)
        at io.joern.dataflowengineoss.queryengine.Engine.runUntilAllTasksAreSolved$1(Engine.scala:100)
        at io.joern.dataflowengineoss.queryengine.Engine.solveTasks(Engine.scala:114)
        at io.joern.dataflowengineoss.queryengine.Engine.backwards(Engine.scala:53)
        at io.joern.dataflowengineoss.language.ExtendedCfgNode$.io$joern$dataflowengineoss$language$ExtendedCfgNode$$$reachableByInternal$extension(ExtendedCfgNode.scala:81)
        at io.joern.dataflowengineoss.language.ExtendedCfgNode$.reachableByFlows$extension(ExtendedCfgNode.scala:45)
        at de.mlsec.ivan.strucky.DataFlow$.flowThrough(DataFlow.scala:57)
        at de.mlsec.ivan.strucky.Main$.main(Main.scala:62)
        at de.mlsec.ivan.strucky.Main.main(Main.scala)
Caused by: overflowdb.SchemaViolationException: IN edge with label AST to an adjacent METHOD is mandatory, but not defined for this METHOD_PARAMETER_IN node with id=11362
        at io.shiftleft.codepropertygraph.generated.nodes.MethodParameterInDb.method(MethodParameterIn.scala:437)
        at io.shiftleft.codepropertygraph.generated.nodes.MethodParameterIn.method(MethodParameterIn.scala:233)
        at io.joern.dataflowengineoss.queryengine.TaskCreator.paramToArgsOfCallers(TaskCreator.scala:92)
        at io.joern.dataflowengineoss.queryengine.TaskCreator.paramToArgs(TaskCreator.scala:80)
        at io.joern.dataflowengineoss.queryengine.TaskCreator.tasksForParams$$anonfun$1(TaskCreator.scala:64)
        at scala.collection.StrictOptimizedIterableOps.flatMap(StrictOptimizedIterableOps.scala:118)
        at scala.collection.StrictOptimizedIterableOps.flatMap$(StrictOptimizedIterableOps.scala:105)
        at scala.collection.immutable.Vector.flatMap(Vector.scala:113)
        at io.joern.dataflowengineoss.queryengine.TaskCreator.tasksForParams(TaskCreator.scala:67)
        at io.joern.dataflowengineoss.queryengine.TaskCreator.createFromResults(TaskCreator.scala:27)
        at io.joern.dataflowengineoss.queryengine.TaskSolver.call(TaskSolver.scala:43)
        at io.joern.dataflowengineoss.queryengine.TaskSolver.call(TaskSolver.scala:30)
        at java.base/java.util.concurrent.ForkJoinTask$AdaptedCallable.exec(ForkJoinTask.java:1456)
        at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:387)
        at java.base/java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:667)
        at java.base/java.util.concurrent.ForkJoinTask$AdaptedCallable.run(ForkJoinTask.java:1464)
        at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:577)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
        at java.base/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1423)
        at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:387)
        at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1311)
        at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1841)
        at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1806)
        at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177)

My current workaround is to disable parallel execution with JAVA_OPTS=-XX:ActiveProcessorCount=1 and parallelize my code on a different level but I thought it would be good to fix this issue anyway. As Fabian said in a similar issue, inconsistent results are a no-go.


Update README.md

added game development using python free certification course

you have to add in one pr only , I'm closing this pr , you can add in previous pr only


DateTimePicker Microsoft Edge Issue

What is the current behavior?
Time picker gets messed up with Microsoft Edge

Which versions of Angular, MD2, OS, browsers are affected?
Angular 4.2.4
MD2: 0.0.25
Win 10, Edge
Is there anything else we should know?
I've tried the time picker on different platforms and browsers, and it works great on all of them, except the mentioned browser on Win 10
Thanks

Is it related to angular https://github.com/angular/angular/issues/9524?


Invalid value "undefined" for header "X-Goog-Visitor-Id"

Hey. Today I'm getting this error message when I want to search in songs. Could anyone know what's wrong?

Seems like this project is been abandon; What do you think?

fixed at https://github.com/emresenyuva/youtube-music-api/commit/b52b2b0d3fd146face64d193ba333c948e857451

fixed at https://github.com/emresenyuva/youtube-music-api/commit/b52b2b0d3fd146face64d193ba333c948e857451


chore: proto unmarshal value string remove sync.Pool

There is no need to use sync.Pool here, we know that the string will no longer than 255 and make slice of bytes using constant size does not escape to the heap, it typically stays on stack. This remove the overheard of retrieving array and writing to the heap.
./value_unmarshal.go:245:13: make([]byte, 0, 255) does not escape

Simplify trimming null string terminator when unmarshal string value.

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

Project coverage is 100.00%. Comparing base (537102c) to head (5cd5b00).
Report is 1 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff            @@
##            master      #360   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           41        41
  Lines         3710      3707    -3
=========================================
- Hits          3710      3707    -3

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


LDAP: searchBeforeAuth, entryDN does not exist

I should preface this by saying that I have very little experience with LDAP, but have been playing around with dex and trying to authenticate users against my companies LDAP server.
As I was doing this I found that the entries that were being returned did not seem to have an entryDN (this line is returning an empty string), but if I modified the code to use sr.Entries[0].DN instead it would work. Is there any reason not to use sr.Entries[0].DN if there is no entryDN?
tagging @fnordahl as he wrote the connector from what I can tell.

@cgilling Thank you for your interest in dex and the LDAP connector. Could you tell me a little bit about what kind of LDAP server you are connecting to?

Its an ActiveDirectory setup. Don't really know much beyond that at the moment.

Thank you for finding and reporting the issue. You are quite right about just using sr.Entries[0].DN. I belive it should be fixed in PR #315 .

awesome, thanks for the quick reply and fix


Common: support bitpacking

What problem does this PR solve?
Issue Number: ref #8789
Problem Summary:
What is changed and how it works?
Using https://github.com/lemire/FastPFor to support Bit-Packing encoding. But it only supports 32bits and 64 bits, so most of the codes come from https://github.com/duckdb/duckdb/tree/main/third_party/fastpforlib
Part of https://github.com/pingcap/tiflash/pull/8903
Check List
Tests

[ ] Unit test
[ ] Integration test
[ ] Manual test (add detailed scripts or steps below)
[ ] No code

Side effects

[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[ ] Breaking backward compatibility

Documentation

[ ] Affects user behaviors
[ ] Contains syntax changes
[ ] Contains variable changes
[ ] Contains experimental features
[ ] Changes MySQL compatibility

Release note

None

/run-all-tests


Assembly is not signed

Please, sign it.

I would prefer not to.  See this discussion.
If your application demands this, you can always sign it yourself.


generate new question page: qset select dropdown

Qset select dropdown is now full-width and responsive. Fixes bug reported in https://trello.com/c/MIChp32g/530-mobile-qset-dropdown-on-new-question-page-is-too-wide-for-screen.
Our previous code wasn't using bootstrap forms quite right, so we weren't getting the responsive benefits of bootstrap's default behavior. This should fix it up so that the width of the dropdown is always commensurate with the width of the other fields and the containing box.
Reviewer is @lizamcpherson01.

Looks good! Thank you for providing such a clear description, and for adding the link to the bootstrap information so others know where to look if a similar problem presents itself again.


DG Documents

Codecov Report

Merging #150 (bd46e16) into master (e694731) will decrease coverage by 0.70%.
The diff coverage is 40.00%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@             Coverage Diff              @@
##             master     #150      +/-   ##
============================================
- Coverage     52.28%   51.59%   -0.70%
- Complexity      465      468       +3
============================================
  Files           101      103       +2
  Lines          2167     2227      +60
  Branches        220      224       +4
============================================
+ Hits           1133     1149      +16
- Misses          962     1006      +44
  Partials         72       72

Impacted Files
Coverage Δ

src/main/java/seedu/address/files/FileStorage.java
50.98% <0.00%> (-4.34%)
:arrow_down:

...rc/main/java/seedu/address/model/ModelManager.java
83.33% <ø> (-2.39%)
:arrow_down:

src/main/java/seedu/address/ui/MainWindow.java
0.00% <0.00%> (ø)

...rc/main/java/seedu/address/files/FilesManager.java
50.00% <61.53%> (+26.36%)
:arrow_up:

... and 9 files with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


PR Workflow Test (Issue)

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

Comparison is base (b9c9921) 87.23% compared to head (6795028) 87.23%.

Additional details and impacted files
@@                Coverage Diff                @@
##           release-1-cherry     #280   +/-   ##
=================================================
  Coverage             87.23%   87.23%
=================================================
  Files                     7        7
  Lines                    47       47
  Branches                 12       12
=================================================
  Hits                     41       41
  Misses                    6        6

Flag
Coverage Δ

html-ui
93.10% <ø> (ø)

react-ui
77.77% <ø> (ø)

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

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


Smoke Detector shows as 'Malfunction' in v0.2.0-beta.3

When v0.2.0-beta.3 is enabled and running, the Smoke Detector binary sensor shows as 'Malfunction'.

Logger: homeassistant.components.recorder
Source: components/recorder/__init__.py:910
Integration: Recorder (documentation, issues)
First occurred: 2:21:07 PM (3 occurrences)
Last logged: 3:14:45 PM

State is not JSON serializable: <state cover.overhead_door=closed; mac_address=, raw_state_text=None, mismatched_states=False, desired_state=DeviceState.CLOSED, device_class=garage, friendly_name=Overhead Door, supported_features=3 @ 2022-01-24T14:21:06.833809-06:00>
State is not JSON serializable: <state cover.overhead_door=closed; mac_address=, raw_state_text=None, mismatched_states=False, desired_state=DeviceState.CLOSED, device_class=garage, friendly_name=Overhead Door, supported_features=3 @ 2022-01-24T14:27:17.520001-06:00>
State is not JSON serializable: <state cover.overhead_door=closed; mac_address=, raw_state_text=None, mismatched_states=False, desired_state=DeviceState.CLOSED, device_class=garage, friendly_name=Overhead Door, supported_features=3 @ 2022-01-24T15:14:45.461177-06:00>

Logger: homeassistant.components.websocket_api.messages
Source: components/websocket_api/messages.py:82
Integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 2:21:06 PM (11 occurrences)
Last logged: 3:18:28 PM

Unable to serialize to JSON. Bad data found at $.event(Event: state_changed).data.new_state(State: cover.overhead_door).attributes.desired_state=DeviceState.CLOSED(<enum 'DeviceState'>
Unable to serialize to JSON. Bad data found at $.result[135](State: cover.overhead_door).attributes.desired_state=DeviceState.CLOSED(<enum 'DeviceState'>
Unable to serialize to JSON. Bad data found at $.event(Event: state_changed).data.old_state(State: cover.overhead_door).attributes.desired_state=DeviceState.CLOSED(<enum 'DeviceState'>

This has now been resolved in v0.2.0-beta.4.


CIF App Demo (internal) Preparation

Describe the task
We have scheduled a demo for the CIF Internal users on April 12 from 10:30am - 11:30am. The goal is to show the CIF team how to use the app, so that they actually start using it more.
To prepare we need to think about how to best provide an overview for them. Lindsay suggested Pierre could provide the demonstration, and perhaps Nan can be there to assist and answer questions. Up for team input.
Acceptance Criteria

[x] Schedule team prep meeting
[x] Create a shared document to plan what we will demo
[x] Practice the demo with a team member and fine-tune according to feedback.
[x] determine next steps for supporting the CIF team. Eg: Would office hours be helpful? Or simply a regular time each week for 30 mins to help them with anything?
[ ] Optional: Compile a list of resources or links that might be helpful for the CIF team (do we have documentation stored in cas-home that we could link to? do we have user guides anywhere?)

Additional context
This is the second part following a CIF team onboarding session provided on April 5, more about agile ways of working and collaboration across teams.

@nanyangpro and @pbastia I have added some AC to this card, but let me know if you need more info to get organized for the demo.

Thanks @Dianadec! Just dropping a few thoughts here which is related to the next steps in the AC: One of the goals we may be able to achieve from this is to understand what are the main reasons currently blocking the CIF team from fully adopting the CIF app. What is still missing? What is still confusing? What can we do to support the shift from spreadsheets? etc.

Yes, @nanyangpro great points. I wonder if it would be possible for someone on our team to take down notes/observations about the questions they ask during the demo. We can also reach out to the in advance of the demo to ask if they have specific areas they want to make sure we cover.

Hi @Dianadec & @pbastia - Here's the draft internal planning doc as we discussed. If the detailed meeting invite looks good, feel free to update it for CIF or let me know, I can send it no problem too.

Hi @pbastia - This ticket is ready for you to review and can be closed with:

#1601, #1602, #1603 created as requested for future enhancements
Next steps summarized and followed up by @Dianadec:

Ensuring all CIF team members have access to CIF test and prod
Planning a Metabase training session in a CIF-related context in May
Open communication in CIF Internal Users channel across teams for feedback, questions, and reporting bugs

Thank you for your time and effort on this, it was a pleasure!

thanks @nanyangpro !


Missing Key-mapping for default.notification.sender

Need to add key-mapping for the following properties in default.json file
"identity_mgt.events.schemes.\u0027default.notification.sender\u0027.subscriptions": [
    "TRIGGER_SMS_NOTIFICATION",
  ],

  "identity_mgt.events.schemes.\u0027default.notification.sender\u0027.properties.\u0027subscription.TRIGGER_SMS_NOTIFICATION.stream\u0027": "id_gov_sms_notify_stream:1.0.0",
  "identity_mgt.events.schemes.\u0027default.notification.sender\u0027.properties.\u0027subscription.TRIGGER_SMS_NOTIFICATION.claim.mobile\u0027": "http://wso2.org/claims/mobile",

If we want to add the configs to toml file for the above, then we have to add as below:
[identity_mgt.events.schemes.'default.notification.sender'.properties]
'subscription.TRIGGER_SMS_NOTIFICATION.stream' = "testDelete"

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!


feat(string): add RCString::operator(const char*) method

I messed up the PR and will open a new one.


Unroll and optimize

Fixes https://github.com/google/heir/issues/257

Still TODO:

Get an end-to-end example working with a loop nest that is unrolled and optimized
Print stats to the terminal
Figure out a heuristic for stopping

The merging of adjacent generics fails because the loop unrolling inserts affine.apply instructions between the generics
affine.for %arg2 = 0 to 10 step 2 {
  secret.generic ins(%arg0, %0 : !secret.secret<memref<10x10xi8>>, !secret.secret<memref<1xi8>>) {
  ^bb0(%arg3: memref<10x10xi8>, %arg4: memref<1xi8>):
    %2 = affine.load %arg3[%arg1, %arg2] : memref<10x10xi8>
    %3 = affine.load %arg4[0] : memref<1xi8>
    %4 = arith.addi %2, %3 : i8
    affine.store %4, %arg4[0] : memref<1xi8>
    secret.yield
  }
  %1 = affine.apply affine_map<(d0) -> (d0 + 1)>(%arg2)
  secret.generic ins(%arg0, %0 : !secret.secret<memref<10x10xi8>>, !secret.secret<memref<1xi8>>) {
  ^bb0(%arg3: memref<10x10xi8>, %arg4: memref<1xi8>):
    %2 = affine.load %arg3[%arg1, %1] : memref<10x10xi8>
    %3 = affine.load %arg4[0] : memref<1xi8>
    %4 = arith.addi %2, %3 : i8
    affine.store %4, %arg4[0] : memref<1xi8>
    secret.yield
  }
}

After rebasing, now it's complaining that Only functions with a single return type are supported, and so it can't emit metadata. Tomorrow I will have to think about how to bypass this, since in our case the arguments are memrefs that are written to as outparams.

Making incremental progress here:

Supporting zero return types in VerilogEmitter and EmitMetadata, because some of the generic bodies of the affine loops don't return anything (they just write to memrefs which are inputs).

Next step seems to be updating the post-yosys step convertOpOperands that adds a compatibility layer between the original input type and the yosys-converted input type. I think I may just expand the scope of secret.cast to cover memref conversions.

I ended up removing an assert that now results in the "compatibility layer" simply being secret.cast a secret<memref<5x4xi8>> to a secret<tensor<160xi1>> and back again, since I'm expecting @asraa to switch from tensor to memref in this code path anyway.
I also decided to expand affine.apply (which is inserted during loop unrolling) and replace it with standard arith ops, but now it runs into the problem that the inputs to the secret.generic are index type, and that is not supported in the VerilogEmitter. I was trying to remember how we handled this before... just pick a bit width and insert cast ops?

After a bit more progress, now I'm blocked on the fact that the design output by Yosys/ABC has this cell whose output write is the same as one of its input wires
  attribute \LUT 4'0110
  attribute \module_not_derived 1
  attribute \src "lib/Transforms/YosysOptimizer/yosys/map_lut_to_lut3.v:47.10-56.19"
  cell \lut3 \_1686_
    connect \A $abc$85582$new_n1096_
    connect \B \arg2 [0]
    connect \C 0
    connect \P0 1'0
    connect \P1 1'1
    connect \P2 1'1
    connect \P3 1'0
    connect \P4 0
    connect \P5 0
    connect \P6 0
    connect \P7 0
    connect \Y \arg2 [0]
  end

??? How is this possible?

OK, I've taken the approach of lifting the loads and stores out of the generic to optimize. Still TODO:

Support for > 1 return value in yosys optimizer
Finish the test I'm currently using to drive the feature work
Add new tests:

Make a loop for which, when you unroll it you can actually optimize better than if you don't
Make a loop which has per-iteration dependent values, and add a forward store to load pattern

It works!!! My god, I'm free.
@asraa this is currently branched off https://github.com/google/heir/pull/413, and after that goes in I'll rebase this and clean up the commits a bit.

Added a more complicated test that computes a cumulative sum of an array, however, the central generic op seems to be sometimes split into multiple, bypassing the joint optimization. So I will have to pick this up tomorrow on that thread.

This PR still needs to be rebased over https://github.com/google/heir/pull/413

Rebased and squashed: @asraa it should be ready for review!

Merged via f6472d488a8fc9b81e9e2a6a8e7848eebabd3088


feat: Add baseColor to Shadow3DDecorator

Description

The Shadow3DDecorator is very useful, but the shadow defaults to being pure black. While this is fine in most cases, sometimes a designer might request something a little bit different, so this change to allow the base color of the shadow to be changed if so desired.

Checklist

[x] I have followed the Contributor Guide when preparing my PR.
[x] I have updated/added tests for ALL new/updated/fixed functionality.
[ ] I have updated/added relevant documentation in docs and added dartdoc comments with ///.
[ ] I have updated/added relevant examples in examples or docs.

Breaking Change?

[ ] Yes, this PR is a breaking change.
[x] No, this PR is not a breaking change.

Related Issues

This screenshot is an example of a white baseColor.

We can probably update the dynamically change shadow properties test as well, I just wasn't sure how to recreate the golden image exactly.


Support the partitioned attribute in cookie settings

Google Chrome is in the process of phasing out third-party cookies.
There are a couple alternatives, one of the simplest being CHIPS: Cookies Having Independent Partitioned State which is triggered by the addition of a Partitioned attribute in the cookie header.
The documentation gives the following as an example compliant cookie:

Set-Cookie: __Host-name=value; Secure; Path=/; SameSite=None; Partitioned;

iron-session should support setting this attribute.

Actually, as I dig deeper, I find that the serialization of the cookie is handled by the cookies library which has support for partitioned as of the latest version.
For some reason the attribute doesn't work when specified in my cookieOptions when imported into Deno from<EMAIL_ADDRESS>even though it imports the most recent version of cookies.
I have gotten it to set though on the example app included with iron-session.


When creating secrets for a cluster's users, add a label indicating what kind of user it's for

I am hoping to be able to rely on label searches alone to identify the superuser vs owner secret for a given cluster. So I'm imagining a label similar to cnpg.io/user-role where the value would be one of superuser or owner.
That way, I could find the secret using the pair of cnpg.io/cluster and this new label without relying on the assumption that the secret's name will always be the cluster name appended with "-app".
What do you think?

Working on it.
A Pull Request will be there soon.


build with clang-cl on windows to get proper portable SHA256

Using latest BLST building with clang to workaround AMD K10 issues with portable

this should still land in main right?


Avoid keeping old golang installation files in GOROOT

this will fix the following issue: https://github.com/cloudfoundry/bosh-google-cpi-release/issues/288

Co-authored-by: Christopher Hunter<EMAIL_ADDRESS>

Thanks to both of you!


⚠ Bofrost.de has degraded performance

In 275eb0b, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1074 ms

Resolved: Bofrost.de performance has improved in 5be0f1f after 20 minutes.


enhancement - wallet - surface visibility of  mainnet / testnet

public static let mainnet: Network = Mainnet()
public static let testnet: Network = Testnet()

or show maybe just some way to control this flow from app developer without modifying Bitcoinkit.

@johndpope What do you mean? HDWallet accepts network type (mainnet or testnet) by a parameter. For Wallet, network type is determined by the key which is corresponded to it. You don't need to modify the library code.

Closing this.
I have use case where it just needs to be clear to end user which network they’re on. It’s doesnt need to switch but just be visible in wallet.

I think when I saw this code - it would be desirable to be able to change the bitcoinkit network without having to recompile code. as in - using it as a pod.
eg. want to be able to hot swap which network from appdelegate.

I don't understand what you are saying. I think that it can be achieved depending on how you implement the application. What kind of support is needed on the library side?

looking at the bread library - they have some ruby scripts to toggle flags from at project level - this might be a better way to switch things moving forward. will close this.
to be clear - the idea that this codebase can be imported by a cocoapod as a dependency as a kit - the developer who consumes library will need some way to override the init call to use either the testnet or mainnet. at the moment that code lives inside bitcoinkit.

You probably misunderstood the API. You can change the behavior just passing parameters in code. Do not need to override or else


Adding custom log levels to dynamic logging

Hi KjellKod
Thanks for your great logger.
There is one issue I don't find a way to solve: I have defined additional debug levels (e.g. LEVELS ERROR) and want to activate/deactivate them dynamically. But as far I can see one can only do it for the preconfigured log levels (INFO, WARNING etc.) because there seems to be no way to add custom LEVELS to g_log_level_status in loglevels.cpp.
Or am I overlooking something?!
Thanks

I just noticed you seem to have already done some work on this subject (commit). When do you think these changes will be merged to master or - even better - when will they become part of a new release?

With "setLogLevel" you can do exactly that. Please see my recent Pull Request(PR) -  feel free to comment on it.
https://github.com/KjellKod/g3log/pull/161
The purpose of the PR is to make it easier for coders to understand and use dynamic logging
I.e enabling/disabling/adding levels of their own choice without having to change the g3log source code.
All the modified and updated APIs have unit tests in the PR that showcase the usage

As soon as I've reviewed it and hopefully someone else have reviewed it I'll get it merged.

I'm planning on a release just before merging this since this release changes the scope from c++11 to c++14.
Since the logging level changes are quite important I might turn around and do a small release immediately after this and one more PR is merged

Thank you for the quick response!

Until it is merged you can still use the 'setLogLevel' function. If I remember correctly it'll add the level used as argument if it didn't exist already - that part of the API will stay the same

https://github.com/KjellKod/g3log/pull/161

The problem with setLogLevel is that it is only save to use it before initialization (as stated by the comment on the only_change_at_initialization namespace: "Only safe if done at initialization in a single-thread context"), but I will need be able to change the log level during runtime.
I solved the problem for now with an extra sink that delegates to the "real" sinks only if the respective log level of the message is active. This extra sink is the only one G3Logs reports to.

Thanks for the explanation. For the logging level to be synchronized for each message between threads it might need a different design.
Already it IS using an atomic value for the status but I've not verified that it is in fact thread safe but I believe it is on x86_64 platforms.
The "only at initialization" is my warning to developers as I haven't proven it'll work across platforms

(Deleted and remade this comment)
Thanks for the explanation.
That is correct.
Just to clarify:
If you add logging levels at a single thread context then once you have started up more threads you , can across threads,  safely disable and enable the individual logging level. These changes will be synchronized across threads.
It would certainly be interesting to make all of the logging level functionality (add, reset of levels) thread safe. At the moment I believe it may already be on some platforms but not on others.

I don't need to add custom log levels during runtime after the other threads are started, so what I want (enable/disable logging levels during runtime) should already work according to your explanation. But I find it weird to call something in the only_change_at_initialization namespace if this is exactly what I do not do ;-). It will be hard to comprehend for other developers when they stumble over this code later.

I hear you and I've thought alongside the same lines.
The way I am pondering doing this is the following:
only_change_at_initialization is kept for addLogLevel(...), reset(..) or any other function that changes the number of logging levels.
Potentially new functions that I am considering
changeLogLevel(LEVEL, bool),
enabledLogLevel(LEVEL),
disableLogLevel(LEVEL)
will be a new functions that changes the enabled/disabled status.  This will not be within the only_change_at_initialization namespace level but at g3 level.
setLogLevel will be removed since it was a SRP violation anyways and it is not thread safe to use it to add a new logging level in a multi threaded context environment.
I hope this would make the API clearer. The caveat to this is that it is a breaking change but hopefully very easy for developers to adopt to the improved API.
Does the outline above make sense?

This sounds great! I would really appreciate the new API (apart from the typo in enabledLogLevel: It probably should be enableLogLevel).
It would be a very tiny but useful breaking change. So I think not only me would appreciate it. I give you both thumbs up to it!

Cool.
I'll let you know once the PR is up so you can review it.
Cheers
Kjell

Contact Information
Kjell Hedström
Mobile:  +1 -<PHONE_NUMBER>
E-mail<EMAIL_ADDRESS>
On Fri, Mar 31, 2017 at 12:41 PM, Jawan81<EMAIL_ADDRESS>wrote:

This sounds great! I would really appreciate the new API (apart from the
typo in enabledLogLevel: It probably should be enableLogLevel).
It would be a very tiny but useful breaking change. So I think not only me
would appreciate it. I give you both thumbs up to it!
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/KjellKod/g3log/issues/162#issuecomment-290795436, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAUP3o8g089QCTTcN930DOmeCLB0n1Lfks5rrUjvgaJpZM4Ms1-_
.

Furthermore I would also appreciate if there was only 'one version' of g3log if you consider dynamic logging: Now you have have to choose during compile time of the library which version you want. If you choose the one without dynamic logging and you have custom log levels you must not use the access functions setLogLevel, addLogLevel etc., because they are not even compiled.
If you want to change to dynamic logging you have to recompile the library. If you don't do anything then, your custom log levels are suddenly ignored. You now have to use setLogLevel/addLogLevel if you don't want them to be ignored.
This is what I mean with two g3log versions: If you switch from one to another the behaviour is different concerning custom log levels.
From my point of view it would be better if dynamic logging was always active and you must call addLogLevel/setLogLevel anyway if you want to use a custom log level - whether or not you want to disable/enable it later during runtime.
This would have the following advantages:

Only one version of the library: you wouldn't need to switch back and forth by recompiling/reinstalling
Adding custom log levels would be the same whether or not you use dynamic logging as opposed to how it is now, where you either must or must not call the access functions

The only disadvantage would be the tiny table lookup time, which is negligible in my eyes, especially because it runs in a different thread than my application. But this is my subjective opinion and I don't know if other users really need to squeeze out every tiny bit of performance. To be sure one could  measure the time difference and if it is as tiny as I expect it to be it might hopefully be worth to harmonize the interface.

I don't think that will change for some time.
There are more #define change one can make with the library.
One option for you could be to install them in different locations. I don't
really understand the use case but you could install one to /usr/local/lib
and the other one to a custom /usr/local/debug/lib.
that way you could have both installed and depending on what version/linked
version of your software you are running it would use one or the other.
Of course if you linked to the wrong version you would get a link error so
you wouldn't risk using the wrong one.

Contact Information
Kjell Hedström
Mobile:  +1 -<PHONE_NUMBER>
E-mail<EMAIL_ADDRESS>
On Fri, Mar 31, 2017 at 1:59 PM, Jawan81<EMAIL_ADDRESS>wrote:

Furthermore I would also appreciate if there was only 'one version' of
g3log if you consider dynamic logging: Now you have have to choose during
compile time of the library which version you want. If you choose the one
without dynamic logging and you have custom log levels you must not use
the access functions setLogLevel, addLogLevel etc., because they are not
even compiled.
If you want to change to dynamic logging you have to recompile the
library. If you don't do anything then, your custom log levels are suddenly
ignored. You now have to use setLogLevel/addLogLevel if you don't want
them to be ignored.
This is what I mean with two g3log versions: If you switch from one to
another the behaviour is different concerning custom log levels.
From my point of view it would be better if dynamic logging was always
active and you must call addLogLevel/setLogLevel anyway if you want to
use a custom log level - whether or not you want to disable/enable it later
during runtime.
This would have the following advantages:

Only one version of the library: you wouldn't need to switch back
and forth by recompiling/reinstalling
Adding custom log levels would be the same whether or not you use
dynamic logging as opposed to how it is now, where you either must or must
not call the access functions

The only disadvantage would be the tiny table lookup time, which is
negligible in my eyes, especially because it runs in a different thread
than my application. But this is my subjective opinion and I don't know if
other users really need to squeeze out every tiny bit of performance. To be
sure one could measure the time difference and if it is as tiny as I expect
it to be it might hopefully be worth to harmonize the interface.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/KjellKod/g3log/issues/162#issuecomment-290814894, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAUP3mM4PgOxgNep0a8Pd9nvOpVpSeK-ks5rrVswgaJpZM4Ms1-_
.

Please see pull request: https://github.com/KjellKod/g3log/pull/168
It was late when I added it so I will re-review it myself to make sure I didn't mess up. Please review it and see if it conforms to what we talked about.
Thanks

solved in https://github.com/KjellKod/g3log/pull/170


Get all dynamoDB tables instead of just first 100.

The PR is to go along with issue #8. This is a simple fix that allow more than 100 dynamoDB tables in your AWS account.

Good catch! Thanks a lot for digging into this.


Add a specification document

If you disagree with some contents or have remarks, I can amend.

So, you mean we adverstise github<->gitlab sync ? I can amend doc for this.

Yes please, I think it's what is advertised in the README as well and it's the simplest thing to implement right now. We can address using local folders as sources with all the metadata issue in the future. For backup purposes, local clones are done anyway when replicating remote repositories.


Installs ruTorrent in wrong directory

When installing ruTorrent with ATK it places the folder in /var/www when by default the root directory is /var/www/html.
I modified my apache2 config to look at /var/www and it works but if people don't do this themselves your installer doesn't work "out of the box".
Regards

Hi,
Sorry I've not got back to you sooner.
I decided rightly or wrongly to go with nginx as the http server to use with this so it doesn't change the apache config and uses a custom /etc/nginx/sites-available/AtoMiC-ToolKit-configured-sites file to manage applications the toolkit installs. It should also disable the apache service on startup.
I didn't have any plans to change or add support for apache however i'm completely open to ideas how we can make it more compatible with both which won't break existing\future installs of applications. If you can help with this please don't hesitate to discuse on Gitter https://gitter.im/htpcBeginner/AtoMiC-ToolKit
Hope this makes sense I'm certainly no expert in this area!!
Tom

I'm closing this as i don't think there is anything that needs changing as I explained above.


[nginx] Can't use named ports with ingress.kubernetes.io/service-upstream: "true"

I am using the new annotation ingress.kubernetes.io/service-upstream: "true" and see that when I try to combine that with a named port in an ingress rule the ingress controller errors out with a message in the logs like:
Error: exit status 1
2017/10/02 19:50:03 [emerg] 58#58: invalid port in upstream "<IP_ADDRESS>:ui" in /tmp/nginx-cfg049697949:223
nginx: [emerg] invalid port in upstream "<IP_ADDRESS>:ui" in /tmp/nginx-cfg049697949:223
nginx: configuration file /tmp/nginx-cfg049697949 test failed

I'm using an ingress rule like this:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: redis-ui
  annotations:
    ingress.kubernetes.io/force-ssl-redirect: "true"
    ingress.kubernetes.io/service-upstream: "true"
spec:
  rules:
  - host: my.domain.com
    http:
      paths:
      - path: /
        backend:
          serviceName: myapp
          servicePort: ui

This is with gcr.io/google_containers/nginx-ingress-controller:0.9.0-beta.13 and Kubernetes 1.7.3.

ping @chrismoos

@jordanjennings I'll check this out, you might want to use the numerical port number in the ingress resource for now until it gets fixed.


Return Failure early in <* and *> too

Checklist:

HLint

[ ] I've changed the exposed interface (add new reexports, remove reexports, rename reexported things, etc.).

[ ] I've updated hlint.dhall accordingly to my changes (add new rules for the new imports, remove old ones, when they are outdated, etc.).
[ ] I've generated the new .hlint.yaml file (see this instructions).

General

[x] I've updated the CHANGELOG with the short description of my latest changes.
[x] All new and existing tests pass.
[x] I keep the code style used in the files I've changed (see style-guide for more details).
[x] I've used the stylish-haskell file.
[ ] My change requires the documentation updates.

[ ] I've updated the documentation accordingly.

[ ] I've added the [ci skip] text to the docs-only related commit's name.

I also added a unit test to ensure the short-circuiting works correctly, for all of the Applicative methods.

Consider this code:
case thisWillFail *> thisWillTakeALongTime of
  Failure _ -> print "It didn't work."
  Success _ -> print "It worked!"

Since we know that the whole expression will be a Failure after the LHS fails, we now emit Failure itself sooner, so that thisWillTakeALongTime doesn't need to be evaluated unless/until the argument to Failure is evaluated.

Sure, I do understand that, but I'm talking exactly about this PR. This feels like unchecked breaking change. @chshersh are you sure you would like to take such a risk? I'm personally using Validation in production, so I wouldn't hurry to get to the newer version of relude then.

Am I missing something? How is this a breaking change?

@vrom911 Agree with you here. I'm also using Validation in production and it works. We have a separate issue to implement tests for Validation. So let's not change the code yet if it's untested.

Actually, this is worse than just a performance problem; we're not a valid Applicative:

The other methods have the following default definitions, which may be overridden with equivalent specialized implementations:

u *> v = (id <$ u) <*> v
u <* v = liftA2 const u v

(emphasis mine) Ours aren't equivalent. If u = Failure ["foo"] and v = undefined, then the LHS of both of those evaluate to undefined, but the RHS of both evaluate to Failure undefined.

Now that #176 is fixed, is this ready to merge?

@josephcsible Well, since we have tests now, we actually can implement our own more optimised versions of these operators (like it how was done at first). Because now we have more guarantees that they will work. And we won't rely on the inliner too much as a pleasant consequence.

@chshersh Done.


Handle CORS requests

Fixes #5724

Codecov Report

Merging #6289 into master will decrease coverage by <.01%.
The diff coverage is 54.83%.

@@            Coverage Diff             @@
##           master    #6289      +/-   ##
==========================================
- Coverage   38.88%   38.87%   -0.01%
==========================================
  Files         359      360       +1
  Lines       51018    51049      +31
==========================================
+ Hits        19836    19845       +9
- Misses      28312    28334      +22
  Partials     2870     2870

Impacted Files
Coverage Δ

modules/setting/setting.go
47.11% <100%> (+0.09%)
:arrow_up:

modules/setting/cors.go
35.29% <35.29%> (ø)

routers/api/v1/api.go
73.97% <76.92%> (+0.07%)
:arrow_up:

models/unit.go
0% <0%> (-14.29%)
:arrow_down:

models/repo_list.go
66.84% <0%> (-1.06%)
:arrow_down:

routers/repo/view.go
41.08% <0%> (-1%)
:arrow_down:

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 8fffb06...e35c3a3. Read the comment docs.

@tamalsaha could you resolve git conflicts, update to use go modules, add tests, and update per feedback? If you do not have any available time to do so please let us know and I can take over this PR to make the required changes.

@techknowlogick, please feel free to make changes as you see fit. My bandwidth is tight for next few weeks. Thanks!

@techknowlogick , do you plan to make any more changes? I wonder when this will be merged.

@tamalsaha my changes are done, and only one other review is needed. Once a 2nd LG-TM is given then this can be merged.

Is there anything we can do to accelerate a 2nd LG-TM?

Please resolve the conflicts.

@lunny , I have fixed the conflicts. PTAL.


Support path analysis function

Feature request
problem describe
A set of real-time written log event data contains event numbers, event types, and event time, requires custom match rules (such as: 5 minutes, event type A occurrence 3 after the event type B occurs at least 2 times. Rule It will be changed dynamically.), The output alarm is satisfied.
Describe the solution
Using FlinkCep, it is necessary to deal with the dynamic changes of rules and require secondary development.
Describe alternatives you've considered
In real time through Flink data, it is stored in the clickhouse in real time, and whether to meet the rules through the path analysis function (sequencematch).
Additional context

There is a window funnel function WIP. https://github.com/StarRocks/starrocks/pull/4985 https://github.com/StarRocks/starrocks/pull/5290
Can you implement path analysis with funnel function?


Oauth2.php database config

I have the following scenario:
Two databases X_database, mysql.

X_database is used for OAuth
mysql is used for Other data

In the oauth2.php I've set the database = X_database so I'll get the OAuth data from there.
return [

    /*
    |--------------------------------------------------------------------------
    | Database Connection to use
    |--------------------------------------------------------------------------
    |
    | Set the default database connection to use for the repositories,
    | when set to default, it uses whatever connection you specified in your laravel db config.
    |
    */
    'database' => 'X_database',
...

OAuthentication goes through:
Route::post('oauth/access_token', function()
{
    Response::json(Authorizer::issueAccessToken());
});

The problem is that I want to read data from the X_database and not mysql, but for some reason when I try to access the route above, the database connection is overwritten with mysql database.
References
Database configuration:
return array(

	'fetch' => PDO::FETCH_CLASS,

	'default' => 'mysql',

	'connections' => array(

		'mysql' => [...]

		'X_database' => array(
			'driver'    => 'mysql',
			'host'      => 'localhost',
			'database'  => 'frimann',
			'username'  => 'root',
			'password'  => '',
			'charset'   => 'utf8',
			'collation' => 'utf8_unicode_ci',
			'prefix'    => '',
		),
...

This is weird, It shouldn't happen, I'll check the codebase and report back.

Thanks a lot.

Which version of Laravel are you on and which version o this package are you using?

Composer says:
Laravel Framework version 4.2.16

league/oauth2-server  4.0.2   A lightweight and powerful OAuth 2.0 authorization and resource server library with support for all the core specification grants.

lucadegasperi/oauth2-server-laravel 3.0.1   A Laravel 4 wrapper for the popular OAuth 2.0 Server package league/oauth2-server

Most likely the configuration isn't read properly. When running the artisan Repl and typing
Config::get('oauth2-server-laravel::oauth2.database'); what does it output?

it output the X_database, the correct one.
BTW: sorry for my late reply.

Was this ever resolved?  I am having the same problem as dud3.  I need to be able to use a separate database for oauth2.  Thanks!


Fractional power encoding

@mikeheddes this is very far from being a complete realization but it is working. It is more of a demonstration of intention to work with it as well as a call for discussing some of the design choices that would have to be made as FPEs are somewhat different from the encodings we have so far

A simple script that I used to visualise the similarity kernel of the resulting FPEs
import torch, torchhd
import torchhd.functional as functional
import matplotlib.pyplot as plt
torchhd.fractional_power_encoding(torch.arange(1, 4, 1.), 6, "sinc", 1.0, "FHRR")
dimensions = 2000
values = torch.arange(start=0.1, end=10., step=0.05)
Compute FPEs for different values of bandwidth
fpes, _ = torchhd.fractional_power_encoding(values, dimensions, kernel_shape = "sinc", bandwidth = 1.0, vsa = "FHRR")
dp_b_1 = fpes.dot_similarity(fpes)/dimensions
fpes, _ = torchhd.fractional_power_encoding(values, dimensions, kernel_shape = "sinc", bandwidth = 0.5, vsa = "FHRR")
dp_b_05 = fpes.dot_similarity(fpes)/dimensions
fpes, _ = torchhd.fractional_power_encoding(values, dimensions, kernel_shape = "sinc", bandwidth = 2.0, vsa = "FHRR")
dp_b_2 = fpes.dot_similarity(fpes)/dimensions
fpes, _ = torchhd.fractional_power_encoding(values, dimensions, kernel_shape = "sinc", bandwidth = 4.0, vsa = "FHRR")
dp_b_4 = fpes.dot_similarity(fpes)/dimensions
index of the value of interest
ind = ((values == 5.0).nonzero(as_tuple=True)[0])
Visualize the above similarity curves for a value at ind
ax = plt.subplot()
ax.plot(values,torch.sinc(values-5), color='k',linewidth=4, linestyle='solid', label='True sinc')
ax.plot(values,dp_b_05[:,ind], color='b',linewidth=2, linestyle='dotted', label='Bandwidth=0.5')
ax.plot(values,dp_b_1[:,ind], color='r',linewidth=2, linestyle='dashed', label='Bandwidth=1.0')
ax.plot(values,dp_b_2[:,ind], color='g',linewidth=2, linestyle='dashdot', label='Bandwidth=2.0')
ax.plot(values,dp_b_4[:,ind], color='m',linewidth=2, linestyle='solid', label='Bandwidth=4.0')
ax.set_xlabel('Values')
ax.set_ylabel('Similarity')
ax.axes.set_xbound(values.min(),values.max())
ax.axes.set_ybound(-0.3,1.01)
ax.legend()
plt.show()

Hi Denis, thanks for opening this PR! Great idea to add this functionality.
Here are some things to think about in the implementation:

How are we going to allow users to provide custom phase distributions? I think it would be great if you could provide your own distribution function so that you can get any custom shaped kernel. Maybe the function call excepts something like torch.distributions that we can sample from.
A note on efficiency, it is generally more performant to first multiply the angle by the input value and then convert to a complex number by taking the sin and cos because the power of a complex number is more expensive than a multiplication of floats.
Can we also support multi-dimensional input coordinates? Let's say I want to encode the point (1, 4) using 10000 dimensional hypervectors.
We should think about separating the generation of the holographic basis (the random vector for each "imaginary" dimension) and the fractional power encoding. That way you could encode multiple times with the same basis.
I am planning on implementing the sparse slot based VSA models that has been discussed a couple times at VSAONLINE and it would be good to think about if these functions could generalize to a discrete version (at least that is what the sparse slot VSA model is according to my current understanding).

Here is a usage example that takes some of my points into account:
uniform_dist = torchhd.get_distribution_by_shape("sinc")
kernel = torchhd.sample_kernel(2, 10000, uniform_dist)
x = kernel.fractional_power([1, 4])

This design is not perfect in any way but its something to think about.
I am a little busy the next three weeks but I will try to find time throughout to give feedback on the design changes.
Great work!

@mikeheddes, this revised code updates some of the above issues.

takes into account the efficiency note
supports multi-dimensional input coordinates
separates the generation of the basis and the fractional power encoding step.

For pre-defined kernels torch.distributions is used but it is not entirely clear at the moment how to use it to define own custom distributions

Great work @denkle, I really like the improved design!
It starts to look like it fits more naturally among the Embeddings modules since it takes in a coordinate (vector) from the input domain and then outputs a hypervector which is what all other Embeddings do. I have something like this in mind:
class FractionalPower(nn.Module):
    def __init__(self, in_features, out_features, distribution, vsa, requires_grad):
        self.distribution = distribution # if the distribution is a string use the presets
        # the weights store the sampled phases
        self.weight = nn.Parameter(torch.empty(out_features, in_features), requires_grad)
        self.reset_parameters()

    def reset_parameters():
        # sample the weights using the provided distribution

    def forward(self, input):
        phase = self.weight @ input
        return torch.complex(phase.cos(), phase.sin())

I don't think adding the bandwidth parameter is needed, I think people can easily change that in their own code. Also allows for having different bandwidth parameters for each input dimension. Something that I think would just add unnecessary complexity in the module, best to keep it simple.
For specifying a custom kernel shape I was thinking about something like this:
d = 10000

class MyDist(torch.distributions.Categorical):
    def sample(self, sample_shape=torch.Size()):
        return super().sample(sample_shape) / 4 * math.pi * 2 - math.pi

in_features = 8
p = torch.ones(in_features, 8)
dist = MyDist(p)
dist.sample((d,)).shape # (10000, 8) which are the weights

embed = FractionalPower(in_features, d, dist)

I am not sure if this is too much work for the user but it at least allows users to define any kind of kernel. We can provide some more common ones as part of the library like this discrete uniform example. Let me know if you think using torch.distributions makes sense or if it's too much overhead.
Great work once again!

@mikeheddes, thanks for the feedback. These are the great points and I agree with most of them!

I don't think adding the bandwidth parameter is needed, I think people can easily change that in their own code. Also allows for having different bandwidth parameters for each input dimension.

I am ambivalent here. Because, on the one hand, I agree that specifying separate bandwidth values for different dimensions is potentially a useful option (though, I have not seen it being needed yet). On the other hand, I believe that removing bandwidth form parameters might not be the best solution. This is because if anything bandwidth is the most important parameter in FPE (at least way more important than dimensionality of hypervectors) as it controls the similarity-preserving characteristics of the encoding (attached figure shows an example). So it is important to adjust it to the data at hand. But if we swipe it under the carpet, users might think that this parameter is not really useful, which would result in nor adjusting the kernel shape to the particular problem.

For specifying a custom kernel shape I was thinking about something like this:
d = 10000

class MyDist(torch.distributions.Categorical):
    def sample(self, sample_shape=torch.Size()):
        return super().sample(sample_shape) / self.probs.size(-1) * math.pi * 2 - math.pi

in_features = 8
p = torch.ones(in_features, 12)
dist = MyDist(p)
dist.sample((d,)).shape # (10000, 8) which are the weights

embed = FractionalPower(in_features, d, dist)

I am not sure if this is too much work for the user but it at least allows users to define any kind of kernel. We can provide some more common ones as part of the library like this discrete uniform example. Let me know if you think using torch.distributions makes sense or if it's too much overhead.

I like how it is done for the discrete sins kernel in your example and I think we could do it but to make it usable we would have to come with a good tutorial where a number of examples are demonstrated and visualised.

Another thing I keep using in the code is raising an error "Fractioncal Power Encoding for this HD/VSA model is not implemented or defined". I think to make a clear point why it is done this way I would at least need to implement FPE for HRR model. This is something I have on my ToDo but will not be able to prioritize this task in the nearest future.

I am ambivalent here. Because, on the one hand, I agree that specifying separate bandwidth values for different dimensions is potentially a useful option (though, I have not seen it being needed yet). On the other hand, I believe that removing bandwidth form parameters might not be the best solution. This is because if anything bandwidth is the most important parameter in FPE (at least way more important than dimensionality of hypervectors) as it controls the similarity-preserving characteristics of the encoding (attached figure shows an example). So it is important to adjust it to the data at hand. But if we swipe it under the carpet, users might think that this parameter is not really useful, which would result in nor adjusting the kernel shape to the particular problem.

That is a good point, I agree that adding it makes sense. If advanced users need to specify per dimension bandwidths they can still do it and leave the parameter as 1 so its not hurting advanced users in that sense.

I like how it is done for the discrete sins kernel in your example and I think we could do it but to make it usable we would have to come with a good tutorial where a number of examples are demonstrated and visualised.

That would be great indeed! With both the tutorial and providing the most common distributions out-of-the-box the user experience should be pretty good.

Another thing I keep using in the code is raising an error "Fractioncal Power Encoding for this HD/VSA model is not implemented or defined". I think to make a clear point why it is done this way I would at least need to implement FPE for HRR model. This is something I have on my ToDo but will not be able to prioritize this task in the nearest future.

This is fine, we can implement functionality incrementally. If someone really needs it they can open an issue so we know what to prioritize.

I like how it is done for the discrete sins kernel in your example and I think we could do it but to make it usable we would have to come with a good tutorial where a number of examples are demonstrated and visualised.

That would be great indeed! With both the tutorial and providing the most common distributions out-of-the-box the user experience should be pretty good.

I create a script show-casing both HRR and FHRR models as well as various kernels. We could extend further later with more examples.

@denkle I just pushed my changes, let me know what you think.

@mikeheddes, looks great. I only changed one line in the Jupyter notebook otherwise not all histograms were displayed properly.
One thing that was confusing me for a while was that I would get an error when trying to get FPEs for values = torch.arange(start=0.1, end=10., step=0.05), which has shape [198].  It turned out that the refactored code implicitly expects the shape to be [198, 1], which was causing the issue. If you are not in favour of keeping the code handling this situation, should it be mentioned somewhere explicitly in the description of methods?

I made it explicit that you are passing in n vectors of 1 d each thus requiring a shape of (n, 1). This is equivalent to the behavior of torch.nn.Linear. I updated the documentation to make this clear.


0.5.2: Unable to install wheel (cmsis_pack_manager/cmsis_pack_manager/init.py is not mentioned in RECORD)

Hi! When trying to package 0.5.2 for Arch Linux I ran into the following problem when trying to install the built wheel:
Traceback (most recent call last):
  File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/usr/lib/python3.10/site-packages/installer/__main__.py", line 98, in <module>
    _main(sys.argv[1:], "python -m installer")
  File "/usr/lib/python3.10/site-packages/installer/__main__.py", line 94, in _main
    installer.install(source, destination, {})
  File "/usr/lib/python3.10/site-packages/installer/_core.py", line 96, in install
    for record_elements, stream, is_executable in source.get_contents():
  File "/usr/lib/python3.10/site-packages/installer/sources.py", line 158, in get_contents
    assert record is not None, "In {}, {} is not mentioned in RECORD".format(
AssertionError: In target/wheels/cmsis_pack_manager-0.5.2-py3-none-manylinux_2_34_x86_64.whl, cmsis_pack_manager/cmsis_pack_manager/__init__.py is not mentioned in RECORD

This is how I build and install:
maturin build --release --strip
python -m installer --destdir="$pkgdir" target/wheels/*.whl

FWIW: This still works as intended with 0.5.1

@mbrossard this is still broken unfortunately.
The resulting wheel contains duplicate dirs (however that is even possible...):
  Length      Date    Time    Name
---------  ---------- -----   ----
     3688  2023-04-18 21:12   cmsis_pack_manager-0.5.2.dist-info/METADATA
       98  2023-04-18 21:12   cmsis_pack_manager-0.5.2.dist-info/WHEEL
    10173  2023-04-18 21:12   cmsis_pack_manager-0.5.2.dist-info/license_files/LICENSE
     8725  2023-04-18 21:12   cmsis_pack_manager/pack_manager.py
     2267  2023-04-18 21:12   cmsis_pack_manager/cmsis_pack_manager/ffi.py
      136  2023-04-18 21:12   cmsis_pack_manager/cmsis_pack_manager/__init__.py
    13517  2023-04-18 21:12   cmsis_pack_manager/__init__.py
      136  2023-04-18 21:12   cmsis_pack_manager/cmsis_pack_manager/__init__.py
     2267  2023-04-18 21:12   cmsis_pack_manager/cmsis_pack_manager/ffi.py
142395536  2023-04-18 21:12   cmsis_pack_manager/cmsis_pack_manager/native.so
     1053  2023-04-18 21:12   cmsis_pack_manager-0.5.2.dist-info/RECORD
---------                     -------
142437596                     11 files

@dvzrv Sorry I didn't notice this! 🙇🏽
0.5.2 changed the way CPM is built to move away from deprecated and unsupported milksnake. @mbrossard will have to look at this since he's the Rust dude. (Sadly, I haven't had time to learn it yet…)

We are now using auto-generated source tarballs (https://rfc.archlinux.page/0020-sources-for-python-packaging/).
However, this comes with other issues (https://github.com/pyocd/cmsis-pack-manager/issues/218 and https://github.com/pyocd/cmsis-pack-manager/issues/226).
Closing, as there has been no further need for us to use sdists.


[Request public procedure] Codeunit 8 AccSchedManagement, function SetGLAccGLEntryFilters

Hello,
we need to access the procedure SetGLAccGLEntryFilters from our extension app. Can you please make it public? Thank you in advance.
// - new
    // local procedure SetGLAccGLEntryFilters(var GLAcc: Record "G/L Account"; var GLEntry: Record "G/L Entry"; var AccSchedLine: Record "Acc. Schedule Line"; var ColumnLayout: Record "Column Layout"; UseBusUnitFilter: Boolean; UseDimFilter: Boolean)
    procedure SetGLAccGLEntryFilters(var GLAcc: Record "G/L Account"; var GLEntry: Record "G/L Entry"; var AccSchedLine: Record "Acc. Schedule Line"; var ColumnLayout: Record "Column Layout"; UseBusUnitFilter: Boolean; UseDimFilter: Boolean)
// + new

Already done for v.22


Fix AOT compilation on MacOS

After #2995, AOT stopped working properly on my arm MacOS:
[10:31:34:240 - 206309B40]: /Users/eloparco/dev/forks/wasm-micro-runtime/core/iwasm/common/wasm_runtime_common.c, line 1270, WASM module load failed
AOT module load failed: mmap memory failed

That's because, without #include <TargetConditionals.h>, TARGET_OS_OSX is undefined (since it's definition is in that header file).
I wanted to setup a step in CI for MacOS to avoid things to break again in the future, but in CI AOT seems to work even without (I guess because there we use an Intel MacOS node, not ARM).

I wanted to setup a step in CI for MacOS to avoid things to break again in the future, but in CI AOT seems to work even without (I guess because there we use an Intel MacOS node, not ARM).

there seems to be a runner with M1.
https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners#standard-github-hosted-runners-for-public-repositories

there seems to be a runner with M1.
https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners#standard-github-hosted-runners-for-public-repositories

macos-14? It seems to be in beta

there seems to be a runner with M1.
https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners#standard-github-hosted-runners-for-public-repositories

macos-14? It seems to be in beta

sure.
i have no idea about "beta" implications because i haven't used it.

i have no idea about "beta" implications because i haven't used it.

Me neither, it says: Warning: Beta and Deprecated Images are provided "as-is", "with all faults" and "as available" and are excluded from the service level agreement and warranty. I'll wait until it's stable and then I'll try to add it to CI.

@eloparco, @yamt should I merge the PR? Or wait for new update?

@eloparco, @yamt should I merge the PR? Or wait for new update?

no reason to block.

I'll open a PR to add the M1 node when I have time


[API] Payloads too large for the database schema cause errors 500

Description
While setuping a renovate bot to include release notes in its pull requests, i noticed that the gitea api was sometimes returning errors 500, causing the renovate job to fail.
The cause was a pull requests comment too large for the database schema, from what i get in the logs:
Mon, Apr 18 2022 2:04:24 pm | 2022/04/18 12:04:24 modules/web/route.go:70:func1() [I] [SQL] ROLLBACK [] - 224.592µs
Mon, Apr 18 2022 2:04:24 pm | 2022/04/18 12:04:24 .../api/v1/repo/pull.go:599:EditPullRequest() [E] UpdateIssueByAPI: Error 1406: Data too long for column 'content' at row 1
Mon, Apr 18 2022 2:04:24 pm | 2022/04/18 12:04:24 Completed PATCH /api/v1/repos/Valuya/embedded-webview/pulls/6 500 Internal Server Error in 40.601052ms

I think gitea should return a client error in the 4xx range in such cases, probably with a dedicated message.
That would be easier to handle by api consumers.
See also https://github.com/go-gitea/gitea/issues/18783 dealing with user input size limit in the UI
See also https://github.com/renovatebot/renovate/issues/15162 for the related renovate issue
Gitea Version
1.15.10
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
No response
How are you running Gitea?
Using the helm chart deployed on a kubernetes cluster
Database
PostgreSQL

Please use latest release, the field size of context has been fixed to correct value.

thx, sorry i hadn't checked that :/

Feel free to re-open if there is still a problem


Fix type annotation in Python < 3.8

During tests in Apache Airflow integration with 0.7.0rc2 (https://github.com/apache/airflow/issues/36897) I've got an error
Traceback (most recent call last):
  File "/usr/local/bin/airflow", line 8, in <module>
    sys.exit(main())
  File "/opt/airflow/airflow/__main__.py", line 57, in main
    args.func(args)
  File "/opt/airflow/airflow/cli/cli_config.py", line 49, in command
    return func(*args, **kwargs)
  File "/opt/airflow/airflow/utils/providers_configuration_loader.py", line 55, in wrapped_function
    return func(*args, **kwargs)
  File "/opt/airflow/airflow/cli/commands/db_command.py", line 63, in resetdb
    db.resetdb(skip_init=args.skip_init)
  File "/opt/airflow/airflow/utils/session.py", line 79, in wrapper
    return func(*args, session=session, **kwargs)
  File "/opt/airflow/airflow/utils/db.py", line 1656, in resetdb
    drop_airflow_models(connection)
  File "/opt/airflow/airflow/utils/db.py", line 1728, in drop_airflow_models
    db = _get_flask_db(connection.engine.url)
  File "/opt/airflow/airflow/utils/db.py", line 714, in _get_flask_db
    from airflow.www.session import AirflowDatabaseSessionInterface
  File "/opt/airflow/airflow/www/session.py", line 23, in <module>
    from flask_session.sqlalchemy import SqlAlchemySessionInterface
  File "/usr/local/lib/python3.8/site-packages/flask_session/sqlalchemy/__init__.py", line 1, in <module>
    from .sqlalchemy import SqlAlchemySession, SqlAlchemySessionInterface  # noqa: F401
  File "/usr/local/lib/python3.8/site-packages/flask_session/sqlalchemy/sqlalchemy.py", line 12, in <module>
    from ..base import ServerSideSession, ServerSideSessionInterface
  File "/usr/local/lib/python3.8/site-packages/flask_session/base.py", line 26, in <module>
    class ServerSideSession(CallbackDict, SessionMixin):
  File "/usr/local/lib/python3.8/site-packages/flask_session/base.py", line 56, in ServerSideSession
    initial: Optional[dict[str, Any]] = None,
TypeError: 'type' object is not subscriptable

dict[str, Any] available only Python 3.9+, it could be enabled in lower version by add in top of the imports
from __future__ import annotations

However since in flask-session do not use future annotations (https://docs.python.org/3/library/future.html#module-contents) I just use Dict from typing instead

cc: @Lxstr

Let me know if you need another rc. Or anything else I can do

Thanks, it is not required yet. I consider to install from the branch, e.g. flask-session @ git+https://github.com/pallets-eco/flask-session.git@development that is might speed up to check SA session


[PROPOSAL] combining input datasets in case of partitions

Problem:

end user gets n input dataset if the dataset is divided into partitions
This creates a disconnect between logical and physical representation:

Logically: User operates on a single dataset
Physically: OL event shows n separate datasets (one per partition)

This can potentially bloat the OL event if number of partitions are huge (potentially >thousands)

Cause:
when a user tries to read a table, like done in below spark code:
df_read = spark.read.format("parquet") \
    .load(f"s3://{bucket}/path/to/data/{source_table}/id=*")

it gives us n inputs in the OL event

In this case we have n=3, but potentially it can be a large number in practice.
Purpose:
Combine all the individual partitioned inputs into a single input.

This would make more sense for the end user interested in lineage info.
Lineage is captured at Data asset level and having an individual input object for each partition is redundant information for the end user.
each input object which is a partition of a table would contain duplicate information.
AWS Glue tables can have >10,000,000 partitions (AWS Documentation)
Current approach would generate an equal number of input entries

Proposed implementation

Dataset Representation:

Replace multiple partition-level entries with one table-level entry
Apply this even when reading specific partitions (e.g., id=1)

e.g., s3://{bucket}/path/to/data/{source_table}/id=1

the input dataset should show asset as source_table level instead of partition.

Partition Metadata:
Add new facets to preserve partition information if required:input[].facets: {
  "is_partitioned": boolean,
  "number_of_partitions": integer
}

Advantages:

Automatically reduces the size of OL event
better lineage experience for the end user

The approach described in the issue doesn't save data about exact partitions being read/written, it just mentions if table is partitioned or not.
IMHO, the Apache Gravitino approach can be used instead:
https://gravitino.apache.org/docs/0.7.0-incubating/manage-relational-metadata-using-gravitino#create-a-table
https://gravitino.apache.org/docs/0.7.0-incubating/manage-table-partition-using-gravitino/#add-partition

{
  input[].facets: {
    partitioning: {
      strategy: identity,
      fields: [
        {
          name: "country",
          type: "string",
        },
        {
          name: "event_date",
          type: "timestamp"
        }
      ],
      partitions: [
        {
          name: "country=xx/event_date=20240101",
          fieldValues: [
            {
              name: "country",
              value: "xx",
            },
            {
              name: "event_date",
              value: "20250101"
            }
          ]
        }
      ]
    }
  }
}

Related: #185

AWS Glue tables can have >10,000,000 partitions (AWS Documentation)

Is this limit something that can be actually found in the wild?
I think it's very important to establish whether we can emit information about every partition, whether for whole dataset, or just queried/written part, or it's foolish effort because the real metadata size can be extremely large?

Some time ago I put some thoughts about partitioning into the docs -> https://docs.google.com/document/d/1w4_3hVY5-BTnehiOGFk1wVSTD550seLlDVlR7RliKt4/edit?usp=sharing
Before going with the proposal in the doc, we could limit amount of inputs for this scenario. Without paritiioning support, this should be a single dataset which I thought is the behaviour we have implemented.

@pawel-big-lebowski I took a look at the partitioning doc, while it makes good proposal on partition facet, it does not include details on combining input partitions to display only single dataset.
Can we please include this in the roadmap for OL?

it does not include details on combining input partitions to display only single dataset.

Could you elaborate, please? If table have partitions [part=1, part=2, part=3], and Spark reads only [part=1, part=2], but exclude part=3, should OL event contain only information about [part=1, part=2]? If the entire table is read without filtering by partition columns at all, should OL event include all 3 partitions, or none of them?

@dolfinus, I think we have two separate issues here.

OL inputs array facet is sending over multiple inputs (1 for each partition read) for a single dataset. Ideally, this would only be one input regardless of the # of partitions.

OL doesn't support partition related metadata as a separate facet.

Issue 1 would take priority here as this can cause very large OL payloads if a dataset has 100s or more partitions. Also, according to @pawel-big-lebowski, this should already be default behavior and maybe is a bug (?):

Without paritiioning support, this should be a single dataset which I thought is the behaviour we have implemented.

As for issue 2, this would be a nice to have at some point in the future.

@dolfinus, I just ran a test with adding "basePath", and I am still seeing multiple inputs for the same {source_table} inside the OL event (OL version 1.24.2).

Well, this is expected. You've asked Spark to read multiple directories, so each one is a dataset, If you need to filter table content against partition column, use:
df_read = spark.read.format("parquet") \
    .load(f"s3://{bucket}/path/to/data/{source_table}")
    .where("id=123")

Right, but the proposal here is about how OpenLineage should define the dataset. A partition is a subset of a particular dataset, so the proposal is asking that OpenLineage represent all inputs at the "basePath" and not at the individual partition level.


Daily Disk Space Report Email

Any way to send daily disk space report using the nice color coded dbadash disk report via email?

I'm no longer maintaining it, but there are some legacy SSRS reports that you could maybe use as a starting point.  Maybe this one:
https://github.com/trimble-oss/dba-dash/blob/main/DBADashReports/Drives.rdl


Merge canvases

Make pen and text viewable at the same time!
Potential improvements/bugs for the future:

close keyboard when switching from text to pen mode
ink should be scrollable
ink features should not jump up when keyboard is open?
collapsible ink tools (so entire screen is free for inking)

looks good!


chore(main): release 1.1.0

:robot: I have created a release beep boop
1.1.0 (2024-10-16)
Features

add devbox uv scripts (ab9dac2)
add python + pip (bf88d72)
debian dockerfile (b778148)

Bug Fixes

.env location (0bf7094)
empty args (dbc29b9)
env vars change based on calling taskfile (0d459bc)
pre-commit (bdd6bcf)
squelch login warning (a3fe52b)
top-level directory (6b08c2c)
wrong operator in conditional (8e5ceb2)

Documentation

add pypi env vars (291c315)
fix formatting, add markdownlint exclusions (eaee84a)
update readme (a9e289d)
update README.md (f75559c)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v1.1.0
:sunflower:


More to come, just putting it out there so that I can get early feedback.
Potentially fixes #16

Thanks!  This is looking good.  One last thing... When you use the maybeBlah in a template it will .toString it which on an option will look like Some("foo") or None so we actually have to transform the option to a string.  I think in most cases this means doing something like: maybeFoo.getOrElse("") which unfortunately get's a bit tedious but that is the nature of optional values.  :)


Fix cli bug where spinner overwrites prompt

When running skpm publish <version> for the first time, and plugin is not on directory yet, it seems to be checking infinitely. This just a cosmetic issue, however: the spinner overwrites and hides the prompt in terminal.
This is fixed by moving the creation of the spinner instance into the print() function, allowing you to stop the spinner at any given point, clearing it, or even declaring it null. The print() function will always check if the spinner variable is truthy, and declare new Ora() with default settings and text passed into print and restart the spinner.
Closes: #208

Thanks! I was actually going to do that :)
Couple of notes but it looks good otherwise!


Validate Date field for new articles is for today or earlier

doesn't make sense to have cases in the future. This will eliminate some errors by editors. urrently there is no restriction on what date an editor can choose.

this validatioin is on production


fix: add missing include and adjust defines and exceptions for MSVC

It compiles with MSVC for the most parts now. Not yet with emio::format.

Codecov Report
Patch coverage: 100.00% and project coverage change: +0.02 :tada:

Comparison is base (099ffd6) 98.73% compared to head (af1d5d3) 98.75%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #28      +/-   ##
==========================================
+ Coverage   98.73%   98.75%   +0.02%
==========================================
  Files          43       43
  Lines        4516     4514       -2
==========================================
- Hits         4459     4458       -1
+ Misses         57       56       -1

Impacted Files
Coverage Δ

include/emio/detail/ct_vector.hpp
92.85% <ø> (ø)

include/emio/detail/format/parser.hpp
94.87% <ø> (ø)

include/emio/format.hpp
100.00% <ø> (ø)

include/emio/buffer.hpp
99.23% <100.00%> (ø)

include/emio/detail/conversion.hpp
95.65% <100.00%> (ø)

include/emio/result.hpp
94.26% <100.00%> (+0.71%)
:arrow_up:

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Add data size class adhering to the correct SI and IEC prefixes

The Size and SizeUnit classes in Dropwizard are using a common but incorrect definition of data size units, in which 1 kilobyte equals 1024 bytes.
The DataSize and DataSizeUnit classes are using the correct definitions according to SI and IEC, in which 1 kilobyte equals 1000 bytes and 1 kibibytes equals 1024 bytes.
Instead of modifying the existing Size and SizeUnit classes, this change set introduces a new set of classes, DataSize and DataSizeUnit, with the possibility to convert the old units into the new, correct units.
Example:
assertEquals(Size.parse("128 kb").toDataSize(), DataSize.kibibytes(128L));

This is a breaking change and has to be properly documented in the release notes and upgrade notes of Dropwizard.
Closes #2152
Closes #2154

It seems add a lot of code to workaround a problem that I find to be small, but I'm sure there are those out there who would be very appreciative of a seamless transition. Though I do have to wonder, if it involves a breaking change anyways, how much better is this approach?

It seems add a lot of code to workaround a problem that I find to be small

Good point. I'm also willing to change this PR so that it resembles #2154 more closely, if that's the consensus.

Though I do have to wonder, if it involves a breaking change anyways, how much better is this approach?

It's not much better, but I think it makes the breaking change more obvious by using a different type and it provides at least a manual migration path if people were using the Size and SizeUnit classes in their own implementations (and not only in configuration files).

Yeah sounds good, I'm ok with this.


Enhanced package upload workflow

Status: Reviewed
The NuGet package upload workflow is being enhanced as we introduce package validation. Let's use this issue to discuss the spec.
Enhanced package upload workflow

How does the CLI experience look like? Should the CLI experience on push give out the URL of the package to monitor?

The CLI says push succeeded. It doesn't say anything about publishing. It also gives out the URL.
Pushing myAwesomeLib.1.0.1.nupkg to 'https://www.nuget.org/api/v2/package'...
  PUT https://www.nuget.org/api/v2/package/
  Created https://www.nuget.org/api/v2/package/ 15028ms
Your package was pushed.

I think it should give out the URL of the package.

@karann-msft , @anangaur , can we close?

created this issue to track CLI feedback - https://github.com/NuGet/Home/issues/6333
Closing this issue.


"dired_index" is empty

Getting this error a lot:
"dired_index" is empty
that shouldn't happen ever, there is some bug

It's happened a lot of times in the past week or so that I've started using this plugin.
I can't pin point a pattern for exactly when or why it happens.
Here's the output from the console panel:
error: FileBrowser:

"dired_index" is empty,
that shouldn’t happen ever, there is some bug.
Traceback (most recent call last):
  File "dired_misc in C:\…\Sublime Text 3\Installed Packages\FileBrowser.sublime-package", line 311, in watch_threads
  File "dired_misc in C:\…\Sublime Text 3\Installed Packages\FileBrowser.sublime-package", line 374, in vcs_colorized
TypeError: zip argument #1 must support iteration

I'm using these settings currently, but I think the error happened when I was only using the defaults as well.
"dired_confirm_send2trash": false,
"dired_hijack_new_window": "dired",
"dired_width": 0.2,
"tab_size": 1,

Using it on Sublime 3 (3083) on Windows 10.

dired_index is a representation of items in a view, where first item of index is first line of view, second is second line, etc. If line is directory or file then in index it is represented as full path, e.g.
['⠤', 'C:\\Users\\vova\\.designer\\', 'C:\\Users\\vova\\.gstreamer-0.10\\', ...
dired_index is created/modified during refresh and expand/collapse.
So it may be empty 1) before refresh is finished, 2) if some error/exception occured during refresh.
I believe that plugin handle it all right, the latest version was two month ago, I use plugin regulary.
Taking these into account, plus traceback that doesn’t make sense to me in particular context TypeError: zip argument #1 must support iteration;
I recommend you,

remove plugin,
exit Sublime Text,
install plugin
exit Sublime Text

Hopefully, it’ll ‘fix’ the problem; if it won’t, then please come up with certain steps to reproduce the bug.

Hello, I have this exact same error whenever I open and close the sidebar quickly. To trigger the issue I only need to press the hotkey twice.
Same console output:
"dired_index" is empty,
that shouldn’t happen ever, there is some bug.
Traceback (most recent call last):
  File "dired_misc in /home/user/.config/sublime-text-3/Installed Packages/FileBrowser.sublime-package", line 311, in watch_threads
  File "dired_misc in /home/user/.config/sublime-text-3/Installed Packages/FileBrowser.sublime-package", line 374, in vcs_colorized
TypeError: zip argument #1 must support iteration

Hotkey is setup as recommended in the README:
	{
		"keys": ["f2"],
		"command": "dired",
		"args": { "immediate": true, "other_group": "left" }
	}

I just mash f2 until the error occurs..

Thank you @TiMBuS

I just mash f2 until the error occurs

It does produce the same bug for me, but only on 3083.
3095 and 2221 work fine though, so it is low priority for now.

Interesting, that despite updates, this issue is still reproducible in beta (3103), but not reproducible in dev (3104).
I think it happens because VCS thread keep running after the view was closed.
@laggingreflex @TiMBuS could you please check if following patch fix it for you and VCS integration still work? it seems right on my machine, but I’m not sure
--- dired_misc.py	Thu Feb 18 01:30:05 2016
+++ dired_misc.py	Thu Feb 18 01:30:11 2016
@@ -371,6 +371,8 @@

     def vcs_colorized(self, changed_items):
         '''called on main thread'''
+        if not self.view.settings().has('dired_index'):
+            return  # view was closed
         modified, untracked = [], []
         files_regions = dict((f, r) for f, r in zip(self.get_all(), self.view.split_by_newlines(Region(0, self.view.size()))))
         colorblind = self.view.settings().get('vcs_color_blind', False)

Pff, I had vcs disabled in 3104. In fact it is reproducible in any ST3.


ModalManager container causes incorrect layout when inside overflow

Issue Description

The container element that the ModalManager renders inside the modal has a few styles that aren't necessary to function and create issues in situations when the body element is overflowed.
The styles just need to be removed.
Issue Type

[ ] New Feature
[ ] Enhancement
[X] Bug
[ ] Other

Expected Behavior

The ModalManager presentation should not affect body scroll position.
Current Behavior

The ModalManager presentation causes the body to scroll to top and remains there even after closing the modal.

Resolved in #611