Add more pie charts when using SummariseCommand

This pull request is an update to #81. Previously fabulously done by member @cwq2326, this pr acts as a follow-up to the changes requested by the said pr #81.
When the users input 'summarise', the window opened will have more pie charts, showing the breakdown of covid statuses in each block. This aids in providing even more visualisation purposes when dealing with raw data. Another pie chart that represents the breakdown of covid positive students in the hall by the faculty can aid hall leaders to figure out which faculty is the worst hit. This can help them determine if the virus was carried over from the faculty when students were out for lessons.
This is achieved when the MainWindow class was executed with a summarise command. The feedback message will be passed to this PieChartWindow class to decrypt the message and get the important numbers to chart out the pies using JavaFX.
The purpose of this PR is to help provide more representation of the data and request for comments and approval to be merged into the master branch.
It is part of a greater set of changes and is not dependent on any concurrent PR.
Other changes that still need to be made:

Update UG/ DG
Produce/ Update test cases
Throw an exception to check for number of faculties and its stats mismatch instead of using an assert

Codecov Report

Merging #86 (185f135) into master (33c7423) will decrease coverage by 0.54%.
The diff coverage is 35.21%.

@@             Coverage Diff              @@
##             master      #86      +/-   ##
============================================
- Coverage     71.44%   70.90%   -0.55%
- Complexity      487      495       +8
============================================
  Files            79       79
  Lines          1583     1629      +46
  Branches        166      169       +3
============================================
+ Hits           1131     1155      +24
- Misses          406      428      +22
  Partials         46       46

Impacted Files
Coverage Δ

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

...seedu/address/logic/commands/SummariseCommand.java
96.00% <100.00%> (+3.14%)
:arrow_up:

...c/main/java/seedu/address/model/person/Person.java
92.64% <100.00%> (+0.10%)
:arrow_up:

...rc/main/java/seedu/address/model/person/Block.java
91.66% <0.00%> (+4.16%)
:arrow_up:

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


clang build error

Hi there,
I got the build error data_tamer_cpp/include/data_tamer/channel.hpp:309:22: error: lambda capture 'this' is not used [-Werror,-Wunused-lambda-capture] followed by multiple successive errors in the same vain with using clang17. The self-reference could either be removed or the error suppressed.
Nice work by the way :grinning:

thanks, I will fix it


Add missing arg to _generate_unsampled_indices

Fixes #27
In sklearn 0.22 sklearn._forest._generate_unsampled_indices(random_state, n_samples) changed signature to sklearn._forest._generate_unsampled_indices(random_state, n_samples, n_samples_bootstrap).
I used the sklearn._forest._get_n_samples_bootstrap(n_samples, n_samples) with the same number of samples and passes to the new arg just to avoid raising the exception.

Heh, cool. i'm just worried this will then break it for people using less than 0.22.  is there a way to check versions?

You're right, I forgot about backward compatibility.
I've used the better ask forgiveness than ask for permission approach to this. A simple try exception that try the previous signature, and whenever failing try the new signature.

Probably easier than figuring out the versioning thing. :)  I just added a comment for you inline there...

@matheusccouto can you pull in my latest tweak to your PR and try again with sklearn 0.22.1? thanks!

Sure, I'll check it out.

i pushed to pip  :)


How do i change the width of the modal?

@sidney61498
Try adding a max-w-full and your width class


fix a bug

Welcome to Codecov :tada:
Once merged to your default branch, Codecov will compare your coverage reports and display the results in this comment.
Thanks for integrating Codecov - We've got you covered :open_umbrella:


fix: retry termination operation

Signed-off-by: qinyer<EMAIL_ADDRESS>
What type of PR is this?

/kind bug
What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for reviewers:

Does this PR introduced a user-facing change?

Additional documentation, usage docs, etc.:

Codecov Report

Merging #508 (589a870) into master (9b2ec18) will not change coverage.
The diff coverage is 0.00%.

@@           Coverage Diff           @@
##           master     #508   +/-   ##
=======================================
  Coverage   13.05%   13.05%
=======================================
  Files         121      121
  Lines       18969    18969
=======================================
  Hits         2476     2476
  Misses      16223    16223
  Partials      270      270

Impacted Files
Coverage Δ

pkg/apis/core/v1/handler.go
0.36% <0.00%> (ø)

pkg/clusteroperation/operation.go
0.00% <0.00%> (ø)

/lgtm
/approve


M2 gcs browser rename directory

This PR adds the functionality to rename a GCS directory, which will include renaming all files and subdirectories recursively. Because this will possibly involve many files the general progress dialog and operations queues are used to ensure that we perform as many moves in parallel as we can.
Fixes #647

PTAL

LGTM.


How can add watermark(logo) on video player ?

How can add watermark(logo) on video player ?

maybe you can just use stack and put image with opacity on to of it?
but you will lost it in full screen
you can maybe also try custom controllers with stack


swagger cleanup

A collection of swagger fixes:

add operationIds for /version and /status; this eliminates two messages during compile.
resolve all errors/warnings as reported by IntelliJ

Compilation warnings on this branch vs. main:

What about that MalformedUrl exception?  Any insight into what that is?  Can we fix that too while we're at it?

@calypsomatic the MalformedURLException is tricker and I don't have a good solution for it just yet - I'd like to clean that up but don't want to block this PR on it.


[Proposal] API Design for EtcdCluster resource

Here is a design proposal for EtcdCluster resource that will cover more cases of real usage. Requesting for comments
Inspired by https://docs.victoriametrics.com/operator/api/#vmstorage
Cover scope of #61
---
-apiVersion: etcd.aenix.io/v1alpha1
+apiVersion: etcd.aenix.io/v1alpha2
 kind: EtcdCluster
 metadata:
   name: test
   namespace: default
 spec:
   image: "quay.io/coreos/etcd:v3.5.12"
   replicas: 3
+  imagePullSecrets:  # core.v1.LocalObjectReference Ready k8s type
   - name: myregistrykey
+  serviceAccountName: default
+  podMetadata:
+    labels:
+      env: prod
+    annotations:
+      example.com/annotation: "true"
+  resources: # core.v1.ResourceRequirements Ready k8s type
+    requests:
+      cpu: 100m
+      memory: 100Mi
+    limits:
+      cpu: 200m
+      memory: 200Mi
+  affinity: {} # core.v1.Affinity Ready k8s type
+  nodeSelector: {} # map[string]string
+  tolerations: [] # core.v1.Toleration Ready k8s type
+  securityContext: {} # core.v1.PodSecurityContext Ready k8s type
+  priorityClassName: "low"
+  topologySpreadConstraints: [] # core.v1.TopologySpreadConstraint Ready k8s type
+  terminationGracePeriodSeconds: 30 # int64
+  schedulerName: "default-scheduler"
+  runtimeClassName: "legacy"
+  extraArgs: # map[string]string
+    arg1: "value1"
+    arg2: "value2"
+  extraEnvs: # []core.v1.EnvVar Ready k8s type
+    - name: MY_ENV
+      value: "my-value"
+  serviceSpec:
+    metadata:
+      labels:
+        env: prod
+      annotations:
+        example.com/annotation: "true"
+    spec: # core.v1.ServiceSpec Ready k8s type
+  podDisruptionBudget:
+    maxUnavailable: 1 # intstr.IntOrString
+    minAvailable: 2
+    selectorLabels: # If not set, the operator will use the labels from the EtcdCluster
+      env: prod
+  readinessGates: [] # core.v1.PodReadinessGate Ready k8s type
+  storage:
+    volumeClaimTemplate:
+      metadata:
+        labels:
+          env: prod
+        annotations:
+          example.com/annotation: "true"
+      spec: # core.v1.PersistentVolumeClaimSpec Ready k8s type
+        storageClassName: gp3
+        accessModes: [ "ReadWriteOnce" ]
+        resources:
+          requests:
+            storage: 10Gi
+    emptyDir: {} # core.v1.EmptyDirVolumeSource Ready k8s type
-  storage:
-    persistence: true # default: true, immutable
-    storageClass: local-path
-    size: 10Gi
 status:
   conditions:
   - lastProbeTime: null
   lastTransitionTime: "2024-03-06T18:39:45Z"
  	status: "True"
  	type: Ready

+  nodeSelector: {} # map[string]string
+  tolerations: [] # core.v1.Toleration Ready k8s type
+  securityContext: {} # core.v1.PodSecurityContext Ready k8s type
+  priorityClassName: "low"
+  topologySpreadConstraints: [] # core.v1.TopologySpreadConstraint Ready k8s type
+  terminationGracePeriodSeconds: 30 # int64
+  schedulerName: "default-scheduler"
+  runtimeClassName: "legacy"
+  extraArgs: # map[string]string
+    arg1: "value1"
+    arg2: "value2"

I'd prefer this to move to some additional key. Not to overwhelm the base spec key. Like podSpec: or something similar

+  storage:
+    volumeClaimTemplate:
+      metadata:
+        labels:
+          env: prod
+        annotations:
+          example.com/annotation: "true"
+      spec: # core.v1.PersistentVolumeClaimSpec Ready k8s type
+        storageClassName: gp3
+        accessModes: [ "ReadWriteOnce" ]
+        resources:
+          requests:
+            storage: 10Gi
+    emptyDir: {} # core.v1.EmptyDirVolumeSource Ready k8s type

need to discuss if we want to enable all possible types of volumes, or restrict them to some safe subset. Because in fact core.v1.PersistentVolumeClaimSpec is very complex for basic use.
+  podDisruptionBudget:
+    maxUnavailable: 1 # intstr.IntOrString
+    minAvailable: 2
+    selectorLabels: # If not set, the operator will use the labels from the EtcdCluster
+      env: prod

we need binary flag: deploy pdb or not. Not just to have the values in the spec, I think. Or podDisruptionBudget: nil would be enough for not deploying it?

+  serviceSpec:
+    metadata:
+      labels:
+        env: prod
+      annotations:
+        example.com/annotation: "true"
+    spec: # core.v1.ServiceSpec Ready k8s type

not enough as business logic supposes to have several type of services. Basic one - headless, and probably addiitonal one for clients? Should we give user option to choose if he wants the second? Or just deploy them both every time?

+  extraArgs: # map[string]string
+    arg1: "value1"
+    arg2: "value2"
+  extraEnvs: # []core.v1.EnvVar Ready k8s type
+    - name: MY_ENV
+      value: "my-value"

Should we have here some additional validation? Let's say that we pass --cluster-initial-state here which is already appended to spec by operator itself? It is where the abstraction leaks.

serviceAccountName: default

then you need to also disable / or enable creation of custom service account...

Also I want to have a good hierarchy:
---
-apiVersion: etcd.aenix.io/v1alpha1
+apiVersion: etcd.aenix.io/v1alpha2
 kind: EtcdCluster
 metadata:
   name: test
   namespace: default
 spec:
   image: "quay.io/coreos/etcd:v3.5.12"
   replicas: 3
   podSpec:
+    imagePullSecrets:  # core.v1.LocalObjectReference Ready k8s type
     - name: myregistrykey
+    serviceAccountName: default
+    podMetadata:
+      labels:
+       env: prod
+     annotations:
+       example.com/annotation: "true"
+    resources: # core.v1.ResourceRequirements Ready k8s type
+      requests:
+        cpu: 100m
+        memory: 100Mi
+      limits:
+        cpu: 200m
+        memory: 200Mi
+    affinity: {} # core.v1.Affinity Ready k8s type
+    nodeSelector: {} # map[string]string
+    tolerations: [] # core.v1.Toleration Ready k8s type
+    securityContext: {} # core.v1.PodSecurityContext Ready k8s type
+    priorityClassName: "low"
+    topologySpreadConstraints: [] # core.v1.TopologySpreadConstraint Ready k8s type
+    terminationGracePeriodSeconds: 30 # int64
+    schedulerName: "default-scheduler"
+    runtimeClassName: "legacy"
+  service-headless:
+    serviceSpec:
+      metadata:
+        labels:
+          env: prod
+        annotations:
+          example.com/annotation: "true"
+      spec: # core.v1.ServiceSpec Ready k8s type
+  service-main:
+    serviceSpec:
+      metadata:
+        labels:
+          env: prod
+        annotations:
+          example.com/annotation: "true"
+      spec: # core.v1.ServiceSpec Ready k8s type
+  storage:
+    volumeClaimTemplate:
+      metadata:
+        labels:
+          env: prod
+        annotations:
+          example.com/annotation: "true"
+      spec: # core.v1.PersistentVolumeClaimSpec Ready k8s type
+        storageClassName: gp3
+        accessModes: [ "ReadWriteOnce" ]
+        resources:
+          requests:
+            storage: 10Gi
+    emptyDir: {} # core.v1.EmptyDirVolumeSource Ready k8s type

something like this. Then in the editor I will be able to easily collapse / expand particular blocks with the technical details. I want to emphasize that I think that it is really great idea to separate the main business logic parameters (like number of replicas) from the deep technical things like service labels

Updated spec addressing all comments
---
apiVersion: etcd.aenix.io/v1alpha1
kind: EtcdCluster
metadata:
 name: test
 namespace: default
spec:
  image: "quay.io/coreos/etcd:v3.5.12"
  replicas: 3
+ podSpec:
+   imagePullPolicy: "Always" # core.v1.PullPolicy Ready k8s type
+   imagePullSecrets:  # core.v1.LocalObjectReference Ready k8s type
+   - name: myregistrykey
+   podMetadata:
+     labels:
+       env: prod
+     annotations:
+       example.com/annotation: "true"
+   resources: # core.v1.ResourceRequirements Ready k8s type
+     requests:
+       cpu: 100m
+       memory: 100Mi
+    limits:
+       cpu: 200m
+       memory: 200Mi
+   affinity: {} # core.v1.Affinity Ready k8s type
+   nodeSelector: {} # map[string]string
+   tolerations: [] # core.v1.Toleration Ready k8s type
+   securityContext: {} # core.v1.PodSecurityContext Ready k8s type
+   priorityClassName: "low"
+   topologySpreadConstraints: [] # core.v1.TopologySpreadConstraint Ready k8s type
+   terminationGracePeriodSeconds: 30 # int64
+   schedulerName: "default-scheduler"
+   runtimeClassName: "legacy"
+   extraArgs: # map[string]string
+     arg1: "value1"
+     arg2: "value2"
+   extraEnvs: # []core.v1.EnvVar Ready k8s type
+     - name: MY_ENV
+       value: "my-value"
+ serviceAccountSpec: # TBD. How to represent it? Do we need ability to specify existing service account?
+   create: true
+   metadata:
+     labels:
+       env: prod
+     annotations:
+       example.com/annotation: "true"
+ serviceSpec:
+   client:
+     metadata:
+       labels:
+         env: prod
+       annotations:
+        example.com/annotation: "true"
+    spec: # core.v1.ServiceSpec Ready k8s type
+   headless:
+     metadata:
+       labels:
+         env: prod
+       annotations:
+        example.com/annotation: "true"
+    spec: # core.v1.ServiceSpec Ready k8s type
+ podDisruptionBudget:
+   maxUnavailable: 1 # intstr.IntOrString
+   minAvailable: 2
+   selectorLabels: # If not set, the operator will use the labels from the EtcdCluster
+     env: prod
+ readinessGates: [] # core.v1.PodReadinessGate Ready k8s type
+ storage:       # Discussed separately
+   volumeClaimTemplate:
+     metadata:
+       labels:
+         env: prod
+       annotations:
+         example.com/annotation: "true"
+     spec: # core.v1.PersistentVolumeClaimSpec Ready k8s type
+       storageClassName: gp3
+       accessModes: [ "ReadWriteOnce" ]
+       resources:
+         requests:
+           storage: 10Gi
+   emptyDir: {} # core.v1.EmptyDirVolumeSource Ready k8s type
- storage:
-   persistence: true # default: true, immutable
-   storageClass: local-path
-   size: 10Gi
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2024-03-06T18:39:45Z"
    status: "True"
    type: Ready

Should we have here some additional validation? Let's say that we pass --cluster-initial-state here which is already appended to spec by operator itself? It is where the abstraction leaks.

I don't thins it's necessary. I guess user can make anytinng that he want here

As of PDB spec, I think user of etcd cluster does not need such complex spec. Operator can configure maxUnavailable according to the number of replicas in cluster, only labels and annotations can be useful

I guess it's better to have ability to configure all fields in PDB. For example my cluster has policy that check PDB and require percent value in minAvailable

#67 Implements storage spec from this proposal. All discussions about storage part can now be addressed here

@sergeyshevch

I don't thins it's necessary. I guess user can make anytinng that he want here

no way. Anything that does not break etcd cluster.

I guess it's better to have ability to configure all fields in PDB. For example my cluster has policy that check PDB and require percent value in minAvailable

yes, I agree. I never argued with it. I am pointing different thing.

@gecube Ok than we need to peform additional validation for extraArgs field. Added it to #69

I think we need image placed under podSpec.

@AlexGluck I don't think so, because it is much more important thing than affinity, tolerations etc. But let it be.

Updated spec after merge of #69. Other spec fields is implemented and removed from this diff
---
apiVersion: etcd.aenix.io/v1alpha1
kind: EtcdCluster
metadata:
 name: test
 namespace: default
spec:
  image: "quay.io/coreos/etcd:v3.5.12"
  replicas: 3
+ serviceAccountSpec: # TBD. How to represent it? Do we need ability to specify existing service account?
+   create: true
+   metadata:
+     labels:
+       env: prod
+     annotations:
+       example.com/annotation: "true"
+ serviceSpec:
+   client:
+     metadata:
+       labels:
+         env: prod
+       annotations:
+        example.com/annotation: "true"
+    spec: # core.v1.ServiceSpec Ready k8s type
+   headless:
+     metadata:
+       labels:
+         env: prod
+       annotations:
+        example.com/annotation: "true"
+    spec: # core.v1.ServiceSpec Ready k8s type
+ podDisruptionBudget:
+   maxUnavailable: 1 # intstr.IntOrString
+   minAvailable: 2
+   selectorLabels: # If not set, the operator will use the labels from the EtcdCluster
+     env: prod
+ readinessGates: [] # core.v1.PodReadinessGate Ready k8s type

I was taking a look at the specification, and noticed this:
https://github.com/aenix-io/etcd-operator/blob/755f6305b9d0b72884e769775276f3f76cd2ffb1/api/v1alpha1/etcdcluster_types.go#L28-L32
In the context of etcd an even number of instances is non-sense, wondering if we could take advantage of the +kubebuilder:validation:MultipleOf kubebuilder validation marker:

specifies that this field must have a numeric value that's a multiple of this one.

Hello! Thanks for the comment. I think that we don’t want to limit the
user. Also we could use this field during cluster auto scaling. For
instance we had 3 instances, and we want to scale to 5. It is logical to
change this field in operator and put in CR, right ? Another thing that if
you have 3 AZ, 5 or 7 instances won’t be a good choice for you, maybe 6?
On Sat, 30 Mar 2024 at 08:28, Dario Tranchitella @.***>
wrote:

I was taking a look at the specification, and noticed this:
https://github.com/aenix-io/etcd-operator/blob/755f6305b9d0b72884e769775276f3f76cd2ffb1/api/v1alpha1/etcdcluster_types.go#L28-L32
In the context of etcd an even number of instances is non-sense,
wondering if we could take advantage of the
+kubebuilder:validation:MultipleOf kubebuilder validation marker:
specifies that this field must have a numeric value that's a multiple of
this one.
—
Reply to this email directly, view it on GitHub
https://github.com/aenix-io/etcd-operator/issues/62#issuecomment-2027952931,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAWHDXAPAVGKLZEYNFOMNF3Y2ZLSFAVCNFSM6AAAAABFDBNP6SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRXHE2TEOJTGE
.
You are receiving this because you were mentioned.Message ID:
@.***>

Damn, you're right 😁
I thought we could use that for this kind of even/odd check 🤦🏻

Okay I'm going to close this proposal in favor #109.
Thank you for your design!


Rebuilding native modules directory naming issue

When rebuilding with the serialport module, it names the final directory as
electron-v0.34.1-darwin-x64

However, when ran with the executable, it is looking for
node-v46-darwin-x64

It seems like in main.js, the directory name and electron versioning is mixed.

Nothing we can do about this, file on serialport?

how come it is about the serialport module? doesn't electron-rebuild create the output directory?

Nope

As you can see, from npm it names the directory correctly. However, when ran with electron-build, the directory name changes.

electron-rebuild just asks node-gyp to build your project. As I said again, serialport controls this

I have exactly the same problem with sqlite3.
For information:
After having installed sqlite and electron-rebuild I did : ./node_modules/.bin/electron-rebuild and it created a .node file at node_modules/sqlite3/lib/binding/electron-v0.36-darwin-x64/node_sqlite3.node. But electron give this error "Uncaught Error: Cannot find module '/Users/me/dev/proj/node_modules/sqlite3/lib/binding/node-v47-darwin-x64/node_sqlite3.node'"
I renamed the folder to node-v47-darwin-x64 and it worked.
Note that in node_modules/sqlite3/build/config.gypi I have the right path
...
"module_path": "../lib/binding/node-v47-darwin-x64",
...

and node_modules/sqlite3/package.json
...
  "binary": {
    "module_name": "node_sqlite3",
    "module_path": "./lib/binding/{node_abi}-{platform}-{arch}",
    "host": "https://mapbox-node-binary.s3.amazonaws.com",
    "remote_path": "./{name}/v{version}/{toolset}/",
    "package_name": "{node_abi}-{platform}-{arch}.tar.gz"
  },
...

PS: This command work (because module_path hard coded): cd node_modules/sqlite3 && node-gyp rebuild --target=0.36.1 --arch=x64 --target_platform=darwin --runtime=electron --module_name=node_sqlite3 --module_path=../lib/binding/node-v47-darwin-x64

Had the same issue, resolution: https://github.com/mapbox/node-pre-gyp/issues/189#issuecomment-173426428

same problem here, only the resolution is none as the pull request is being ignored

This is now solved upstream by https://github.com/mapbox/node-pre-gyp/pull/187 - available in node-pre-gyp >= 0.6.25. So, the next step is to ensure that modules you are using that depend and bundle node-pre-gyp get re-tagged with the latest version.


rework eicu

[ ] rework eicu implementations to use the new conceptbase
[ ] include the full current set of variables into the pipeline

Add eicu to concepts

[ ] Dosages

[ ] Adrenaline_dosage
[ ] Dobutamine_dosage
[ ] Norepinephrine_dosage
[ ] Vancomycine_dosage
[ ] Vasopressine_dosage

[ ] Observations

[ ] AirwayPlateauPressure
[x] BodyWeight
[x] BreathingRate
[ ] Creatinine_absolute_serum
[ ] FiO2
[ ] PEEP
[x] SystolicBloodPressure
[ ] TidalVolume
[ ] UrineVolume


Introdution to GitHub Actions

https://quality-assurance-dao.gitbook.io/training-and-automation/automation/introduction-to-github-actions

Rationale etc


The number of rows/selected count text is overlapping the table scroll bar

I think it is good information but I didn't see this in the original design. In the 3.x app it was above the table on the right side near some of the tools. Thoughts on placement?

@chris-fox, related discussion #270 can be found

Discussing overlap here as well https://github.com/Esri/solutions-components/issues/270#issuecomment-1716736485


ManageIQ refuse to launch job on Ansible Automation when i fill service dialog

Hello,
I use ManageIQ with Ansible Automation to launch my backend jobs. Some of them have quesionnaie so I created a dialog box from these jobs to give the extra vars needed to launch the playbook.
The questions in the form of a list were displayed in a single line, I modified everything by hand except I got an error telling me that it was missing the manageiq and manageiq_connection extra vars, which I don't quite understand. Should I supply these variables to my ansible automation ? i got this error  "  Template Demande_VM_client launching failed. Reason: {"extra_vars":["Variables manageiq, manageiq_connection are not allowed on launch. Check the Prompt on Launch setting on the Workflow Job Template to include Extra Variables."]} (MiqException::MiqOrchestrationProvisionError) "

Can you provide more detail about the playbook you are trying to run?

Closing waiting for response. if this is still an issue, feel free to reopen


Powershell 6 resizing issues

Environment
Windows build number: Microsoft Windows 10.0.18363
Windows Terminal version (if applicable): 0.7.3451.0

Any other software?
PowerShell Core 6.2.3

Steps to reproduce
Run PowerShell Core 6.2.3 in Windows Terminal, resize the window in any manner.
Expected behavior
The terminal prompt and existing printed text will be resized (i.e. line wrapping) and realigned to put the active prompt at the bottom of the window or at the lowest line if there aren't enough history lines to fill up the window.
All profiles other than PS6 (WSL, CMD, original PowerShell, Azure Cloud Terminal) are working fine in this regard, as well as the default PS6 terminal (not running it in Windows Terminal).
Actual behavior
The text stays in the same place relative to the border dimensions that the terminal/tab was instantiated with.
When the window is enlarged, all visible text remains inside the smaller original borders.  See that in the 2nd image the output of the top command is cut off even though there is empty space below the last prompt line.  Prompt lines will never fill this empty space.

If a new tab is opened once the window is larger, these new dimensions are accurately rendered with the new terminal tab.  See how there is now no empty space below the last prompt.

When the window is made smaller, the printed text remains in the larger original borders making the current line (the cursor/new text) not visible as it remains outside the new smaller bounds.  In the first image below I've typed a bogus command into the prompt, but it is not visible as it is a few lines below the bottom of the resized window.  After hitting enter a few times, the 2nd image shows that the command ran, but was not visible in the terminal until enough new lines pushed it up into the view of the resized window.

Thanks for the detailed report! This seems like a /dupe of #1465


WordPress Importer

It would be great if we can have a tool to import Authors/Tags/Pages/Posts from WordPress. Don't have clear goal for this yet but hoping you guys can help :)

We can use this package to handle excel and XML file imports
https://github.com/Maatwebsite/Laravel-Excel

I started working on this feature, will share with you some details soon!

@diaafares need extra hand ?  let me know.

Thanks 👍

@themsaid @shellprog Here is the first proof of concept release, it has the main functionalities but of course it need many imporvements, please take a look guys:
https://github.com/diaafares/wink-wp-import

@diaafares
I was thinking of a GUI approach rather than a command line would be best
This is the controller I whip up, but I don't have much experience with Vue. if anyone can make the Post and Pages Import Vue and use my controller that be awesome. I will continue to improve the import controller.
https://gist.github.com/Reflow1319/6c28f99795c35bf0369f4cc3c545ce78

@diaafares ok, I understand about it being a separate package, but would it be possible for your package to include an XML import option? I feel this would make it more accessible to some WordPress users that would consider moving to wink.

@diaafares @themsaid what about using the WordPress JSON API? I could play around with something to see if that might be a more seamless experience for the user.
Would take out the export and upload steps.

@diaafares created diaafares/wink-wp-import which is the best solution available so this can be closed.

@Reflow1319 & @bearcodi Before I start the implementation of the package, I asked @themsaid which way he prefers, he told me that he prefer Command line approach with connecting directly to the database, but thank you all for your suggestions :)
@bearcodi There is no "export and upload steps" in my package, use just add your WB database config to connect directly to it, then the package read the data from WB database and insert it directly to Wink DB.
Please take a look at the repo:
https://github.com/diaafares/wink-wp-import

@diaafares @themsaid so maybe merge this into wink?


Reinstate Windows build

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

I think if this would've worked as-is without any changes, we would've been doing it in the first place. We publish a win amd64 wheel for VC14.1/VS2017 and can build from source on VC14 or VC14.1, if you want to fight with the conda build chain to get this working you have my support but I think it's a non trivial exercise.


How to add rustup targets?

Hello! How do I configure panamax to pull down additional compilation targets? That is, things that you would normally get with something along the lines of rustup target add aarch64-linux-android. I figured pinned_rust_versions was the closest option, but if it is I can't seem to find the right settings (stable-aarch64-linux-android doesn't seem to work, for instance).

Hello! I believe you would need to add that to platforms_unix.
pinned_rust_versions is more for e.g. pinning Rust 1.46 to make sure it doesn't get deleted when a newer stable version is released.

That does it, thanks!

Is it possible for this to work with ARM targets? putting them in "platforms_unix" or windows doesnt work. Neither did making a new "platforms_arm" (just in case :P)

@FauxPrada Apologies for the late response - this is because we have a hardcoded list of available platforms here and here. I believe thumbv7em-none-eabihf doesn't exist there either because I've missed it, or because it got added since the last time I modified that list.
That being said, having a hardcoded list restrict which platforms can be downloaded doesn't make a whole lot of sense, so I'm going to make sure other platforms can be added outside of that list.

Hi @k3d3, no problem, thanks for exaplining it! That sounds like a decent solution, for now I'm just copying the targets manually which is okay for our small development circle.
Look forward to the improvement :)


localhost is currently unable to handle this request.

I got error in browser on docker up

This page isn’t working
localhost is currently unable to handle this request.
HTTP ERROR 500

I am on linux mint 19, docker and docker-compose are both of latest version.
Please, help to figure this out.

Do you have an .env file in your application src directory? Was everything copied over to the src directory before running docker-compose up -d?
Do you have any output if you run docker-compose logs nginx or docker-compose logs php?


Remove ActiveSupport dependency

Verification

[X] This issue's title and/or description do not reference a single formula e.g. brew install wget. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.

Provide a detailed description of the proposed feature
Remove the activesupport gem dependency. For simple components with downstream dependencies, we can directly incorporate the monkey-patches. Other components should just be replaced with Ruby methods (much of the good stuff in ActiveSupport has been incorporated into recent Ruby releases anyway).
What is the motivation for the feature?
ActiveSupport has been a source of performance issues (as it's arguably intended for server lifecycles, not CLI tools). It lacks some type optimizations that sorbet knows about with core methods. Monkey-patches can make for subtle bugs, as libraries and Ruby core may disagree over which versions they consider canonical.
How will the feature be relevant to at least 90% of Homebrew users?
Maybe some tiny perf improvements (though possibly a less user-friendly interface at the edges as well).
What alternatives to the feature have been considered?
We could maintain the status quo, and be vigilant about keeping out the less performant components (e.g. inflections)

Remove the activesupport gem dependency. For simple components with downstream dependencies, we can directly incorporate the monkey-patches. Other components should just be replaced with Ruby methods (much of the good stuff in ActiveSupport has been incorporated into recent Ruby releases anyway).

Agreed, this makes sense to me. It might make sense to have a list of the stuff we're (still) using so we can discuss each one and whether it makes sense to:

keep it around and support it indefinitely as a Homebrew DSL/monkeypatch
keep it around for now but deprecate it as a Homebrew DSL/monkeypatch
remove it now because it's not used

@dduugg if you have the bandwidth and desire: would you be able to create such a list? 🙇🏻

@MikeMcQuaid yep, i can own this own this ticket, if you're ok with a slow rollout as bandwidth allows me (probably circa end-of-year)

@dduugg Works for me, thanks!

For any deprecations, it would be good to get those by mid-December (minor bump will ideally be before the holidays, but no earlier than the 11th). Not a blocker though, as we can instead punt the deprecations until April (minor bump for Ruby 3.2 maybe?).
Assuming it's still around by then, I'm also considering moving ActiveSupport to the mechanize-style gem vendoring instead of bundler vendoring it for Ruby 3.1. To do this however, we first need to remove our dependency on active_support/core_ext/object/blank, which depends on concurrent-ruby. We were planning on reimplementing this ourselves I think so we at least already had a plan for that one.

Assuming it's still around by then, I'm also considering moving what is left of ActiveSupport to the mechanize-style gem vendoring instead of bundler vendoring it for Ruby 3.1

I'd really rather keep everything in Bundler we can as it makes version management way easier.

We were planning on reimplementing this ourselves I think so we at least already had a plan for that one.

Yup 👍🏻
I'd think we can probably reimplement most other stuff by that timescale 🤞🏻

Assuming it's still around by then, I'm also considering moving what is left of ActiveSupport to the mechanize-style gem vendoring instead of bundler vendoring it for Ruby 3.1. To do this however, we first need to remove our dependency on active_support/core_ext/object/blank, which depends on concurrent-ruby. We were planning on reimplementing this ourselves I think so we at least already had a plan for that one.

Happy to take care of this separately from the refactoring of the rest of the ActiveSupport code. PR incoming.

4.2.0 changes are landing now. Let me know if there's anything here that should land with 4.2.0 and needs help with.

One question is what we do with rubocop-rails, given that has a ActiveSupport dependency on it's own. Going through what we have enabled:

Rails/ActiveSupportAliases - not needed if we remove ActiveSupport as these methods won't exist anymore and will be errors instead
Rails/Blank - only NilOrEmpty/NotNilAndNotEmpty is useful (only a few lines) - other bits can be replaced by Style/InverseMethods and Style/InvertibleUnlessCondition
Rails/CompactBlank - TBC if we're going to support this
Rails/DelegateAllowBlank - not needed, not supported
Rails/DurationArithmetic - no longer supported: https://github.com/Homebrew/brew/pull/14502
Rails/ExpandedDateRange - ditto, no longer supported
Rails/Inquiry - not needed if we remove ActiveSupport as these methods won't exist anymore and will be errors instead
Rails/NegateInclude - can be replaced by Style/InverseMethods
Rails/PluralizationGrammar - linked to time, no longer supported
Rails/Presence - probably the most useful one here
Rails/Present - only NilOrEmpty/NotNilAndNotEmpty is useful (only a few lines) - other bits can be replaced by Style/InverseMethods and Style/InvertibleUnlessCondition
Rails/RelativeDateConstant - linked to time, no longer supported
Rails/SafeNavigation - no longer supported: https://github.com/Homebrew/brew/pull/16184
Rails/SafeNavigationWithBlank - useful, extremely small (couple lines)
Rails/StripHeredoc - not needed if we remove ActiveSupport as these methods won't exist anymore and will be errors instead
Rails/ToFormattedS - will not be supported

One question is what we do with rubocop-rails, given that has a ActiveSupport dependency on its own.

Feels like by the time we end up vendoring ActiveSupport changes we should probably do the same with the specific cops that make sense. Has always been a bit of a cludge in here.
Agreed with your takes about what's useful/not.

I poked around for where we're still relying on ActiveSupport and came up with the table below. Since we mostly require these from global.rb, there's always the possibility that we have downstream dependencies in formulae (as i learned in https://github.com/Homebrew/brew/pull/16189).

ActiveSupport core_ext path
Method
Approx. # of uses in Library/Homebrew
Add'l comments

array/access.rb
Array#second
26
Trivial (one-line) implementation

Array#third
3
Trivial (one-line) implementation

Array#second_to_last
1
Trivial (one-line) implementation

enumerable.rb
Enumerable#index_by
2
both in formula_installer

Enumerable#exclude
<= 49
Trivial (one-line) implementation. Collides with String#exclude?, hence the upper bound

Enumerable#compact_blank
3
Trivial (one-line) implementation

file/atomic.rb
File.atomic_write
48

hash/deep_merge.rb
Hash#deep_merge
2
in dev-cmd/bottle.rb and dev-cmd/pr-upload.rb

hash/deep_transform_values.rb
Hash#deep_transform_values
1
Formulary.load_formula_from_api

Hash#deep_transform_values!
1
Formulary.load_formula_from_api

hash/keys.rb
Hash#assert_valid_keys
7
all in Library/Homebrew/cask, seems like we could replace with type checking

Hash#deep_transform_keys
1
Formulary.load_formula_from_api

Hash#deep_transform_keys!
1
Formulary.load_formula_from_api

Hash#deep_stringify_keys
1
GitHubPackages#validate_schema

Hash#deep_symbolize_keys
1
Cask::CaskLoader::FromAPILoader#load

object/deep_dup.rb
Object#deep_dup
1
Cask::Artifact::AbstractArtifact.new

object/duplicable.rb
Object#duplicable
0
Dependency of Object#deep_dup that we don't need

string/exclude.rb
String#exclude?
<= 49
Trivial (one-line) implementation. Collides with Array#exclude?, hence the upper bound

string/filters.rb
String#remove
1
Removed in https://github.com/Homebrew/brew/pull/16426

string/indent.rb
String#indent
8
test files & Utils::AST

I think this is useful for folks to identify which methods we want to vendor, and which we want to refactor away, but let me know if y'all were wanting other metrics in order to guide us from here.

Array#second et all

I've found these arbirtrary a bit but do get why they are sometimes used. I'd like to see alternatives to it. For example instead of .split("/").second we could do .partition("/").last, or instead of args.named.first and args.named.second do arg1, arg2, = args.named. "second" etc is a often non-descriptive of why it's special and you usually need to read more code to follow what's happening.
This is however used in homebrew-core and at least one third-party tap so should be considered public API and go through any relevant deprecation process.

In terms of the rest:

*#exclude? definitely considered public API at this point
File.atomic_write isn't used externally but our wrapper Pathname#atomic_write is public API
Enumerable#compact_blank used by the qt-creator cask and two third-party taps so while it is low usage it probably needs to be considered public API.
Hash#deep_stringify_keys and Hash#deep_symbolize_keys is used by Homebrew/bundle, but I'm not aware of any other usage externally.

Thanks @dduugg!

I think this is useful for folks to identify which methods we want to vendor, and which we want to refactor away, but let me know if y'all were wanting other metrics in order to guide us from here.

I think anything with a trivial one-line implementation and/or >=3 uses by us or any third-party tap usage should be vendored.
Also agreed with @Bo98's assessment of what should be considered public API/not.


kie-issues#650: increase timeout for default nightly

apache/incubator-kie-issues#650
Increasing job timeout for default variant of kogito-apps nightly build.
Didn't want to increase the default in seed config, not to increase also for kogito-runtimes, where the timeout is sufficient.

DSL test PR check is enough for this kind of PR, going to merge.

PR job #2 was: UNSTABLE
Possible explanation: This should be test failures

Reproducer
build-chain build full_downstream  -f 'https://raw.githubusercontent.com/${AUTHOR:apache}/incubator-kie-kogito-pipelines/${BRANCH:main}/.ci/buildchain-config-pr-cdb.yaml' -o 'bc' -p apache/incubator-kie-kogito-apps -u https://github.com/apache/incubator-kie-kogito-apps/pull/1904 --skipParallelCheckout
NOTE: To install the build-chain tool, please refer to https://github.com/kiegroup/github-action-build-chain#local-execution

Please look here: https://ci-builds.apache.org/job/KIE/job/kogito/job/main/job/pullrequest_jobs/job/kogito-apps-pr/job/PR-1904/2/display/redirect
Test results:

PASSED: 2805
FAILED: 4

Those are the test failures:

org.kie.kogito.index.oracle.ProcessDataIndexOracleHttpIT.testProcessInstanceEvents
java.util.concurrent.CompletionException: java.lang.RuntimeException: Unable to start Quarkus test resource class org.kie.kogito.index.test.quarkus.http.DataIndexOracleHttpQuarkusTestResource

org.kie.kogito.index.oracle.ProcessDataIndexOracleKafkaIT.testProcessInstanceEvents
java.util.concurrent.CompletionException: java.lang.RuntimeException: Unable to start Quarkus test resource class org.kie.kogito.index.test.quarkus.kafka.DataIndexOracleQuarkusKafkaTestResource

org.kie.kogito.index.ProcessDataIndexInfinispanIT.testProcessInstanceEvents
1 expectation failed.JSON path errors doesn't match.Expected: null  Actual: <[{message=Exception while fetching data (/UserTaskInstanceAttachmentUpdate) : Index 0 out of bounds for length 0, locations=[{line=1, column=12}], path=[UserTaskInstanceAttachmentUpdate], extensions={classification=DataFetchingException}}]>

org.kie.kogito.index.ProcessDataIndexOracleIT.testProcessInstanceEvents
Failed to load ApplicationContext


MUI5, Next.js 13 Visual bug after hard refresh

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Steps to reproduce 🕹
https://user-images.githubusercontent.com/33333844/216878946-e415cb0a-c63e-44e5-95bd-a695ffd6519f.mp4
Current behavior 😯
The video can clearly show what the issue is, and I think that the issue #33304 had exactly the same problem, somehow get fixed after the upgrade of Next.js version. While in my case, this issue still exists with the Next.js 13.
Expected behavior 🤔
No response
Context 🔦
No response
Your environment 🌎

npx @mui/envinfo
  System:
    OS: macOS 11.6.5
  Binaries:
    Node: 18.12.1 - ~/.nvm/versions/node/v18.12.1/bin/node
    Yarn: 3.3.0 - ~/.nvm/versions/node/v18.12.1/bin/yarn
    npm: 8.19.2 - ~/.nvm/versions/node/v18.12.1/bin/npm
  Browsers:
    Chrome: 109.0.5414.119
    Edge: Not Found
    Firefox: Not Found
    Safari: 15.4
  npmPackages:
    @emotion/react: latest => 11.10.5
    @emotion/styled: latest => 11.10.5
    @mui/base:  5.0.0-alpha.116
    @mui/core-downloads-tracker:  5.11.7
    @mui/icons-material: latest => 5.11.0
    @mui/material: latest => 5.11.7
    @mui/private-theming:  5.11.7
    @mui/styled-engine:  5.11.0
    @mui/system:  5.11.7
    @mui/types:  7.2.3
    @mui/utils:  5.11.7
    @types/react: ^18.0.26 => 18.0.27
    "next": "^13.1.1",
    react: ^18.2.0 => 18.2.0
    react-dom: ^18.2.0 => 18.2.0
    typescript: ^4.9.4 => 4.9.4

I am trying to use MUI5 with tailwind. After I comment out the {/*  */}, then it is working as expected while I cannot normally use tailwind.

I figured it out after reading the documentation carefully

I'm having the same problem. Can you tell me how you solved it?


New Port Goblin Dungeoneer

New Port for Goblin Dungeoneer
Game Information

Title: Goblin Dungeoneer
URL: https://crackedghostgames.itch.io/goblin-dungeoneer

Submission Requirements
CFW Tests
[X] AmberELEC
[X] ArkOS
[X] JELOS/ROCKNIX
[X] MuOS
Architecture
[X] armHF
[X] Panfrost (Mainline)
Resolution Tests
Test all major resolutions:
[X] 480x320
[X] 640x480
[X] 720x720 (RGB30)
[X] Higher resolutions (e.g., 1280x720
File Structure

Your port should have the following structure:

portname/

port.json
README.md
screenshot.jpg
cover.jpg
gameinfo.xml
Port Name.sh
portname/

Additional Resources
For an in-depth guide on creating a pull request, refer to: PortMaster Game Packaging Guide

Changes committed :)


Add notes on access conditions script

@all-contributors add @nlebovits for code, content, data, doc, funding finding, maintenance, project management, research


Graphics

As a player I want the game to look nice.

Closing while cleaning backlog; not specific.


Fix for Chromium-based browsers

Right now, the problem seems to be that storage logic is tied to the Firefox Sync API. Should probably be extracted in helper methods (in utils.js probably)

https://github.com/mozilla/webextension-polyfill


Glance wallpaper source

please add a glance wallpaper source

Muzei offers a plugin system that any app, including Glance, can implement. Feel free to send feedback to Glance with a link to the Muzei 3.0 API blog post, which has all of the details on how to build a Muzei source into their app. They can contact us at<EMAIL_ADDRESS>if they have any questions.


Replay data - 15M_VecEps_B78

Hi,
I'm trying to reproduce the work you did in "Decoupling Representation Learning from Reinforcement Learning". Can you kindly provide /data/adam/ul4rl/replays/20200608/15M_VecEps_B78/pong/run_0/replaybuffer.pkl so I can do so.
Thanks
Harry

@indrasweb Has your issue been resolved? I have encountered the same problem. While I tried to load data by creating an empty file, I encountered an error EOFError: Ran out of input when executing replay_buffer = pickle.load(fh).


consensus: investigate and define the relationship between timeouts

Consensus uses three timeouts, one per round step, to govern the operation of rounds of consensus when the "good" path or execution scenario is not observed: timeout_propose, timeout_prevote, and timeout_precommit.
Consensus timeouts are adaptive, meaning that their duration increase over rounds, with linear increments. So, the duration of a timeout for a round step (propose, prevote, or precommit) in a round r of consensus is given by:
timeout_<step>(r) = timeout_<step> + r * timeout_<step>_delta

The timeout_<step> parameters thus define the duration of timeouts adopted in round r = 0, while the timeout_<step>_delta parameters define the linear increment for the duration of timeouts over rounds, only relevant for rounds r > 0.
Liveness conditions
The consensus algorithm paper defines some conditions on the consensus timeouts so that the Termination property is observed. The termination of a consensus algorithm is a liveness property stated as: "All correct processes eventually decide on a value". Using CometBFT's nomenclature, the property translates into: "All correct nodes eventually commit a block".
The conditions on consensus timeouts, stated as part of Lemma 5 (page 10), requires that in a round r we have:
* timeout_propose(r) > 2∆ + timeout_precommit(r−1)
* timeout_prevote(r) > 2∆
* timeout_precommit(r) > 2∆

∆ is the upper bound on message delay, i.e., the maximum time it takes for a message sent by a correct node to be received by all correct nodes. This bound is only valid once the system reaches GST, the Global Stabilization Time. ∆ and GST are not necessarily known by the nodes, but they are assumed to be finite. These are assumptions of the partially synchronous system model adopted by the consensus algorithm. The progress of the algorithm is guaranteed when the system becomes ∆-timely, i.e., after GST.
Sufficient vs Required conditions
The above conditions on consensus timeouts are sufficient for ensuring liveness. In fact, the paper proves that if the configured timeouts  follow the above mentioned conditions, the Termination of the consensus algorithm is guaranteed.
The above conditions on consensus timeouts, however, are not necessarily required for ensuring liveness. This means that a less restrictive set conditions on consensus timeouts could possibly guarantee the Termination of the consensus algorithm as well.
We should investigate if there is a less restrictive set conditions on consensus timeouts that still guarantees liveness after GST.
Conditions to Parameters
What is the required relationship between timeout_<step> and timeout_<step>_delta parameters for different round steps, so that the consensus timeouts adopted by a node adhere to the minimum set of conditions required for ensuring progress?
Definition of Done

[ ] Investigate the required conditions on consensus timeouts for ensuring liveness
[ ] Define rules for configuring consensus timeout parameters so that the required conditions are observed

Probably a topic of another issue/investigation is the relationship between max block size and the timeouts, in particular timeout_propose. The bigger the proposal, the more time is required to process it and propagate it in the network.

This is true, although liveness is not affected, only performance. Namely, if the block is big and the timeout is small, since the timeouts increase over rounds, eventually they become large enough to encompass the transmission of the big block.


Separate build from execution & report generation

This is a mirror issue to another coverage tool https://github.com/xd009642/tarpaulin/issues/1352
Is it possible to build binaries, then move them to special environments (like docker images) and run coverage and reports there separately?

I don't know your exact use case, but show-env + report might work: https://github.com/taiki-e/cargo-llvm-cov?tab=readme-ov-file#get-coverage-of-external-tests

The exact use case would be building all of the test binaries together, with cache available, then separating them to:

unit tests, no special environment
integration tests, docker image, docker compose with specific services available
then combining all results through another tool

If you want to run the built binaries in containors you need to bind the target directory and map LLVM_PROFILE_FILE env var properly, but show-env should work.

Alright, I'll try it out and see how it goes.
Thank you :)

If you want to run the built binaries in containors you need to bind the target directory and map LLVM_PROFILE_FILE env var properly

I checked locally and something like the following worked:
source <(cargo llvm-cov show-env --export-prefix)

cargo build

docker run --rm -d -it \
  -v "$(pwd)":/workdir \
  --env LLVM_PROFILE_FILE="${LLVM_PROFILE_FILE/"$(pwd)"//workdir}" \
  ubuntu sh -c '/workdir/target/debug/<bin-name> --version'

cargo llvm-cov report --html

The assumption is that I provide all the test binaries paths, which requires build result parsing the build results.
I believe this is also different between cargo test and nextest

I did a setup with nextest, since it provides a better way to package test binaries, here's the attempt
https://github.com/nextest-rs/nextest/issues/1036

Closing -- this seems to be solved https://github.com/nextest-rs/nextest/issues/1036#issuecomment-1761676089


Pending is still pending

Problem
We compare the version on docker osm with our pending version
If we change directly into osm, the pending is not deleted, because the version compare is not right
Solution
Need to update logic to comparing it

already fixed


Add new tools to Awesome-Transit

This is a list of some cool community projects that should be added to Awesome-Transit
https://github.com/roughconsensusandrunningcode/TrainMonitor
https://github.com/fredlockheed/db-fv-gtfs
https://github.com/Arnie97/emu-log
https://github.com/mymro/oebb-api
https://github.com/juliuste/interrail
https://github.com/hasadna/OpenTrainCommunity
https://github.com/chaturadilan/Train-Schedule-Android-Application
https://github.com/keyone2693/IRTrainDotNet
https://github.com/fredlockheed/db-fv-gtfs
https://github.com/maxmouchet/locomotive

@Simha-Kalimipalli, thanks for this awesome list!
Would you be willing to open the PR to add them here? 🙂

they are a mix of gtfs/webscrapers/CLI apps/ and apis.  Im not sure where do add them specifically

It would be great for someone suggest where each would best fit.


prefer-conditional-expression: checks deeply nested else if

Bug Report

TSLint version: 5.7.0
TypeScript version: 2.5.1
Running TSLint via: CLI

TypeScript code being linted
if (length === 0) {
    result = "foo";
} else if (length === 1) {
    result = "bar";
} else if (length === 2) { // error on this line
    result = "something else";
} else {
    result = "unknown";
}

with tslint.json configuration:
"prefer-conditional-expression": true

Actual behavior
Error for the last if else nested inside if else if else. Note that the if else count needs to be even for this behavior to occur.
Expected behavior
No error, because "check-else-if" is not enabled.

let's try to get this in v5.9


[BUG]Missing Start Script ,

Description
Every project have a start script,  but unfortunally we haven't it,
To Reproduce
Steps to reproduce the behavior:

Go to 'package.json'
in Scripts 'write start and give it access of root file of project'

Expected behavior
in log should be print 'Serving on port 3000'
**Screenshots  of current facing error **

This can be solved by running npm install in the project after cloning the repo.After that run the
npm start command in the terminal.This should be in the root folder of the project


Rollup: replace config is wrong

Per https://github.com/rollup/plugins/tree/master/packages/replace
Our replace config should look like
    replace({
        delimiters: ["", ""],
        // replace dynamic checks with if (true) since this is for node only.
        // Allows rollup's dead code elimination to be more aggressive.
        "if (isNode)": "if (true)"
      }),

instead of
   replace({
        delimiters: ["", ""],
        values: {
          // replace dynamic checks with if (true) since this is for node only.
          // Allows rollup's dead code elimination to be more aggressive.
          "if (isNode)": "if (true)"
        }
      }),

Which doesn't replace anything anymore. Not sure if this changed since a previous plugin version, but tested it on core-http.
Not a big deal since we're not shipping browser bundles, but still seems like it should be cleaned up.

Fixed in #8909


add presevation evoker spell ids to awcSpells

current:
none of the big prevoker cooldowns are shown on the nameplates in the combat replay view
desired:
get prevoker spells into the combat replay view's nameplates
notes:
let me know if there is anything else I need to do.
it seems like I may need to re-generate the spells.json and related files via the generateSpellsData script, but I wasn't sure if that was a part of CI or something that PR contributors usually do.
happy to run the regeneration if needed :)
spells added:
    '363916', // obsidian scales
    '370553', // tip the scales
    '374348', // renewing blaze
    '363534', // rewind
    '357170', // time dilation
    '370960', // emerald communion

if there are any edits to this list that you'd like to see happy to change as well.
<3

prevoker CDs are there and handled properly. woo!


Pin old urllib3 version

gql[requests] uses an old version of requests-toolbelt which is incompatible with newer versions of urllib3 (but does not constrain its dependency on urllib3).
This adds a version constraint to ensure that urllib3 is compatible.

lgtm, but this seems like a problem for the future, no?

The way I think it will play out is that one of our deps will eventually require urllib3>=2 and version-solving will fail, and by then hopefully gql will allow for newer versions of requests-toolbelt that support urllib3.


Prevent electric-quotes in org src-blocks.

Fixes #5051
Added hook to prevent electric-quote-mode from converting quotes when point is inside an org src-block.
In the linked issue, I had tried using "org-in-src-block-p" as the inhibiting function. It worked, but only after rearranging the functions in post-self-insert-hook so the electric-quote function (electric-quote-post-self-insert-function) would run before the smartparens function (sp--post-self-insert-hook-handler).
Looking deeper into the problem, I found that "org-in-src-block-p" isn't always accurate, because it relies on the "src-block" property of the char at point. But that property is getting switched to nil by sp--post-self-insert-hook-handler (specifically, by the call to sp-insert-pair).
I think this might be caused by the "src-block" text property getting inherited from the quote that smartparens inserts in front of our own typed quote mark. Not sure.
Unlike "org-in-src-block-p", "org-in-block-p" doesn't rely on an abstracted text property. It examines the text surrounding point to determine if it's within a src-block. So it should more reliably prevent electric-quotes from sullying our src-blocks. (I appreciate any suggestions you might have.)

I think I could further improve this by having it run only when org-mode is active.
As-submitted, the extra text-processing only occurs with electric-quote-mode enabled and after a ', ", or ` has been typed.
But there's no reason for it to run at all outside of an org-mode buffer.

I'm currently trying to decide between this or the following:
;; in lang/org/config.el
(add-hook! 'org-mode-hook
  (add-hook 'electric-quote-inhibit-functions 'org-in-src-block-p nil t))

;; in core/core-editor.el, in `smartparens` use-package :config
;; Ensure sp--post-self-insert-hook-handler always runs last
(remove-hook 'post-self-insert-hook 'sp--post-self-insert-hook-handler)
(add-hook 'post-self-insert-hook 'sp--post-self-insert-hook-handler 100)

Trouble is, the numeric DEPTH argument for add-hook is a 27.x feature, and we still support 26.x (at least until the end of June).

I'm currently trying to decide between this or the following:
;; in lang/org/config.el, in `+org-init-hacks-h'
(add-hook! 'org-mode-hook
  (add-hook 'electric-quote-inhibit-functions 'org-in-src-block-p nil t))

;; in core/core-editor.el, in `smartparens' use-package block (in :config)
;; Ensure sp--post-self-insert-hook-handler always runs last
(remove-hook 'post-self-insert-hook 'sp--post-self-insert-hook-handler)
(add-hook 'post-self-insert-hook 'sp--post-self-insert-hook-handler 100)

Trouble is, the numeric DEPTH argument for add-hook is a 27.x feature, and we still support 26.x (at least until the end of June).

I think that's better, because it solves a potential problem going forward (should some other hook relies on a text property that smartparens indirectly changed).
The DEPTH argument replaces APPEND from 26.x which--since 100 is non-nil--would still put it at the end of the hook, no?

The DEPTH argument replaces APPEND from 26.x which--since 100 is non-nil--would still put it at the end of the hook, no?

They work a little differently. In 26.x, APPEND appends to the hook once at insertion. but DEPTH maintains order in perpetuity; i.e. add-hook resorts the hook on every insertion.
So if electric loads after smartparens, we're back to square 1.
Although... now that I test, electric is loaded immediately at startup so this may be a non-issue...

I think I finally solved it.
It must be obvious that I'm still learning git (and GitHub).  2fc0be6 is the one I was trying to submit. (Also, I'm not sure how to back out the first PR, which was a change to a different file.)
This goes at the end of  +org-init-hacks-h in lang/org/config.el.
;; Disable electric-quote-mode when inside of org-mode src-blocks.
(add-hook! 'org-mode-hook
    (add-hook
     'electric-quote-inhibit-functions
     (lambda () (unless (eobp)
                  (or
                   (eq (get-char-property (+ (point) 1) 'src-block) t)
                   (eq (get-char-property (- (point) 1) 'src-block) t)))) nil t))

It avoids needing to deal with the order of functions on post-self-insert-hook. Unlike org-in-block-p, it doesn't have to search for src-block fences. It does what I think is an inexpensive check of the char-properties at 2 positions.
Smartparens inserts a closing quotation mark and then moves point behind it. The extra quotation mark doesn't possess the src-block property at that moment. But since point moves behind it, org-in-src-block-p would use that char to decide whether it's in a src-block.
Instead, this checks 1 position forward and one position backward, and if we're at the end of the buffer it just returns nil to avoid an out-of-range error.

So we can also fix this for in-line src code. But I think before submitting this, I'll study how to update a pull request.
(add-hook! 'org-mode-hook
  (add-hook
   'electric-quote-inhibit-functions
   (lambda () (or
               (unless (eobp)
                 (or
                  (eq (get-char-property (+ (point) 1) 'src-block) t)
                  (eq (get-char-property (- (point) 1) 'src-block) t)))
               (looking-back ".*src_[-+a-zA-Z]*{[^}]*" (line-beginning-position)))) nil t))

Am I doing this right? I was hoping to consolidate everything into a single commit for your review, but after reviewing the git docs I'm still not sure how.
This last commit inhibits electric-quotes both inside of org-mode src-blocks and within org-mode's in-line source "snippets" (my own phrasing).
It no longer relies on hook ordering, so it should work for all supported Emacs versions.

Should we close this? The last couple commits fixed what we discussed, but I'm still not sure why there ended up being so many other commits added to it.
I can resubmit it as a single commit if you want.


Expose buildIdris to consumer flakes

I want to directly call buildIdris from nix, this pr exposes it.

Me questioning my design decisions, essentially.
I use callNix - that is, the standard nixpkgs callPackage, but with buildIdris - in packages/default.nix so we can separate the package list and the package descriptions. I'd also like to keep exports small, at least until there's a good way to enumerate what the different exports are.
Do you ever need to use buildIdris <spec> where callNix ({buildIdris}: buildIdris <spec>) wouldn't work?

Felt odd and not idiomatic to have to call callNix. Heavy weight when what I wanted to do is just call buildIdris. My use case is currently really simple though.


Remove logsoftmax

Addressing the issue  #511 by setting up the flag add_logsoftmax with a warning that the LogSoftmax as a final layer will be removed in the future. Proposed by @PierreGtch .

Thank you very much for your comments, @sliwy ! :smile:
I will reply to them one by one.

Hi @sliwy, thanks for your review! We discuss your comments with Sara and I will answer them individually

@Sara04 @PierreGtch based on this #513 (comment) I think that I may not understand well what the flow of logsoftmax is going to look like. For now, all models (or almost all) are created with softmax in the end. In the new flow if a user wants to have classification model would need to add softmax on their own?

Yes exactly, the user will have to add the softmax himself as this is standard practice. But in practice, you will not need to because if you use the nn.CrossEntropyLoss, it’s already integrated in the loss.

Can we merge this @Sara04, @PierreGtch and @sliwy? Looks okay for me.

Thank you @Sara04, @PierreGtch, @sliwy!

Thanks @PierreGtch , @sliwy , @bruAristimunha !


pass open file to Roo::Excelx so it works when filename has no extension or wrong extension

I'm trying to open an uploaded file, so name is kind of RackMultipart20160418-5180-seqzi, I know it's xlsx because I get extension from uploaded_file.original_filename, and Roo::Excelx.new(File.open(uploaded_file.path, 'rb')) works, but Workbook::Book.open(uploaded_file.path, 'xlsx') fails because it passes temp path to Roo::Excelx

Hi, thanks for the pull-request (and interesting work on the workbook-rails gem :) ), however, are you sure this solves your problem? Typically the Roo::Excelx reader takes a path in the form of a string to open a file, which is what I'm enforcing here...

Yes, it solves my problem, at least roo 2.3.2 support open file instead of path. Look at https://github.com/roo-rb/roo/blob/master/lib/roo/excelx.rb#L40, unless is_stream?, with path like /tmp/RackMultipart20160418-5180-seqzi it tests file extension with file_type_check method, and fails. And in line 48, process_zipfile is called and accepts stream
Reading changelog I found 2.0.1 accepts stream:
https://github.com/roo-rb/roo/blob/master/CHANGELOG.md#201---2015-06-01

I guess the answer would be to check whether we're passing an inputstream or just a regular file... I'll look into it later today.


Windows 10 support

1- Moving from jsdom to cheerio in order to support Windows 10. Also, Ch…eerio is leaner & cleaner.
2- Update WWW & CONFIG locations to add Win10 support

@nikhilkh to review

LGTM. It's the usual code formatting issues - looks like your editor needs some configuration changes.

@nikhilkh, formatting issues fixed.


Add 'Development' section

Add a section on how to:

Run tests?
Lint Code
Generate documentation

Fixed in 520b8b4712d9a7ab68e68fdae3a20f15ca48c40b


fix moduleClassNames attribute wiring in JSonDataFormat

moduleClassNames is not taken into account in <dataFormats><json moduleClassNames = "..."></dataFormats>
This commit fix this.
Please can you backport to 2.17 too ? thanks

Thanks for the PR it has been merged. Do you mind closing this?

Thanks


Button is not applying hover:bg-primary/90 effect

The default variant of the Button component is not applying the hover:bg-primary/90 effect defined in the button.jsx file.
globals.css
@tailwind base;
@tailwind components;
@tailwind utilities;
@layer base {
    :root {
        --background: 0 0% 100%;
        --foreground: 240, 6%, 10%;

        --card: 0 0% 100%;
        --card-foreground: 240 6% 10%;

        --popover: 0 0% 100%;
        --popover-foreground: 222.2 84% 4.9%;

        --primary: 201, 93%, 38%;
        --primary-foreground: 0, 0%, 100%;

        --secondary: 24, 66%, 57%;
        --secondary-foreground: 240, 6%, 10%;

        --muted: 240 4.8% 95.9%;
        --muted-foreground: 240, 0%, 55%;

        --accent: 210 40% 96.1%;
        --accent-foreground: 222.2 47.4% 11.2%;

        --destructive: 0, 71%, 56%;
        --destructive-foreground: 0, 0%, 100%;

        /*--hover: 201, 93%, 26%;*/

        --border: 240 5.9% 90%;
        --input: 240 5.9% 90%;
        --ring: 240 10% 3.9%;
        --radius: 1.0rem;
    }

    .dark {
        --background: 240 10% 3.9%;
        --foreground: 0 0% 98%;

        --card: 240 10% 3.9%;
        --card-foreground: 0 0% 98%;

        --popover: 240 10% 3.9%;
        --popover-foreground: 0 0% 98%;

        --primary: 201, 93%, 38%;
        --primary-foreground: 240 5.9% 10%;

        --secondary: 240 3.7% 15.9%;
        --secondary-foreground: 0 0% 98%;

        --muted: 240 3.7% 15.9%;
        --muted-foreground: 240 5% 64.9%;

        --accent: 240 3.7% 15.9%;
        --accent-foreground: 0 0% 98%;

        --destructive: 0 62.8% 30.6%;
        --destructive-foreground: 0 0% 98%;

        --border: 240 3.7% 15.9%;
        --input: 240 3.7% 15.9%;
        --ring: 240 4.9% 83.9%;
    }
}

@layer base {
    * {
        @apply border-border;
    }

    body {
        @apply bg-background text-foreground;
    }
}

button.jsx
import * as React from 'react';
import { Slot } from '@radix-ui/react-slot';
import { cva } from 'class-variance-authority';

import { cn } from '@/lib/utils';

const buttonVariants = cva(
    'inline-flex items-center justify-center whitespace-nowrap rounded-md text-sm font-medium ring-offset-background transition-colors focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-ring focus-visible:ring-offset-2 disabled:pointer-events-none disabled:opacity-50',
    {
        variants: {
            variant: {
                default:
                    'bg-primary text-primary-foreground hover:bg-primary/90',
                destructive:
                    'bg-destructive text-destructive-foreground hover:bg-destructive/90',
                outline:
                    'border border-input bg-background hover:bg-accent hover:text-accent-foreground',
                secondary:
                    'bg-secondary text-secondary-foreground hover:bg-secondary/80',
                ghost: 'hover:bg-accent hover:text-accent-foreground',
                link: 'text-primary underline-offset-4 hover:underline',
            },
            size: {
                default: 'h-10 px-4 py-2',
                sm: 'h-9 rounded-md px-3',
                lg: 'h-11 rounded-md px-8',
                icon: 'h-10 w-10',
            },
        },
        defaultVariants: {
            variant: 'default',
            size: 'default',
        },
    }
);

const Button = React.forwardRef(
    ({ className, variant, size, asChild = false, ...props }, ref) => {
        const Comp = asChild ? Slot : 'button';
        return (
            <Comp
                className={cn(buttonVariants({ variant, size, className }))}
                ref={ref}
                {...props}
            />
        );
    }
);
Button.displayName = 'Button';

export { Button, buttonVariants };

My page where I am using the Button component.
'use client';

import React from 'react';
import { useFormState } from 'react-dom';
import { handleLogin } from<EMAIL_ADDRESS>import { FontAwesomeIcon } from '@fortawesome/react-fontawesome';
import { faEye, faEyeSlash } from '@fortawesome/free-solid-svg-icons';
import { Button } from '@/components/ui/button';
import Link from 'next/link';
import { Label } from '@/components/ui/label';
import { Input } from '@/components/ui/input';
import { Checkbox } from '@/components/ui/checkbox';

function SigninPage() {
    const [errorMessage, dispatch] = useFormState(handleLogin, undefined);
    const [visible, setVisible] = React.useState(false);
    return (
        <form
            className="m-auto flex min-w-[400px] flex-col justify-center gap-2 p-12 align-middle"
            aria-label="Signin Form"
            action={dispatch}
        >

Sign in

Please enter your credentials to proceed

                Email
                <Input
                    type="email"
                    id="email"
                    name="email"
                    aria-label="Email"
                    placeholder="Email"
                />

                Password

                    <Input
                        type={visible ? 'text' : 'password'}
                        id="password"
                        name="password"
                        aria-label="Password"
                        placeholder="Password"
                        required
                    />
                    <FontAwesomeIcon
                        icon={visible ? faEye : faEyeSlash}
                        onClick={() => setVisible(!visible)}
                    />

                {errorMessage && <></>}

                    <Checkbox id="remember" aria-label="Remember Me" />
                    Remember me

                    Forgot password?

            <Button type="submit">Submit</Button>
            <Button variant="ghost">
                <Link href="/auth/signup-user">Apply for an account</Link>
            </Button>
        </form>
    );
}

export default SigninPage;

Is there anything I am doing wrong?

It seems to be working in my setup, even so, it's not a problem with shadcn, but more likely with tailwind css itself, which is not generating the class styles correctly. Have you tried restarting the project and reinstalling node_modules?

try using hsla(),

@davve5 it did not work. I have found a work around but it's not a clean solution.

you've added commas to the tokens in the css:
        --popover: 0 0% 100%;
        --popover-foreground: 222.2 84% 4.9%;

        --primary: 201, 93%, 38%;
        --primary-foreground: 0, 0%, 100%;

this will cause the hsl application of opacity to fail.  just remove the commas and it should work fine.  Should match how the popover values are input

@abdnafees did you figure it out? I'm stuck on the same problem.

@joffenhopland I don't remember how I fixed it and I am no longer working on the project.

@joffenhopland I had the same problem because I forgot to remove commas.

you've added commas to the tokens in the css:
        --popover: 0 0% 100%;
        --popover-foreground: 222.2 84% 4.9%;

        --primary: 201, 93%, 38%;
        --primary-foreground: 0, 0%, 100%;

this will cause the tailwind application of opacity to fail. just remove the commas and it should work fine. Should match how the popover values are input

can i use this effect with hex code ?

The short answer is no, you need to define your CSS variables as just the colour channels for HSL, RGB or RGBA.
There is a longer explanation in the tailwind docs that is helpful to understand why

there might be some system / browser compatibility issue for
try hover:opacity-90 instead.
for myself, I have a combined hex and hsl color as css variables in my global.css.
when I use bg-my-green hover:bg-my-green/90, the hover effect does not show.
if i revert the order, bg-my-green/90 hover:bg-my-green, which actually working fine.

I had the same problem and after reading the docs realized that I had to update the lightDarkVar function to include the alpha values just like in the docs @lloydrichards  function lightDarkVar(baseName) { 	return `var(--theme-light, hsl(var(--${baseName}) / <alpha-value>)) var(--theme-dark, hsl(var(--${baseName}-dark) / <alpha-value>))`; }

This issue has been automatically closed because it received no activity for a while. If you think it was closed by accident, please leave a comment. Thank you.


wip: new docker build logic

Please provide a description of this PR:

@howardjohn: PR needs rebase.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

/test all

LGTM! My only experience is hacking around in here and being confused. Deferring to Eric as the expert.


Add guideline for commit messages

What?
We want to add a guideline for writing commit messages. This will make our commit history more consistent.
It will be part of / added to a CONTRIBUTING file later.

Suggestions

we could use uses semantic commit messages, which can help in streamlining release processes (auto generating CHANGELOGs)

these could be used in combination with defined emojis to have a more visual effect (see e.g. https://github.com/folke/devmoji)

we establish rules based on How to Write a Git Commit Message

I like the guidelines under https://www.conventionalcommits.org/en/v1.0.0/

I also think that Conventional Commits is a good default and we should not try to reinvent the wheel. I would describe the commit type with text label instead of emojis. Emojis look nice in GitHub, but they are not as explicit with some text based tools.
Do you think we should repeat the (copy) the main points to the document or only refer to that external resource?

Sounds good to me! 👯
I would add the main points in our doc in form of a condensed bullet list which is fast to skim, while refer to the external resources for more details. That way, the contributors don't have to leave the source in most cases (if they don't want to read up more details), which I feel is a nice usability. At least for people that tend to be a bit impatient (or eager, which is a nicer way to put it 😅 ) like me.
I can make a PR for that.
❓  should I already make that a CONTRIBUTING file or should it be a temp commits.md until we have CONTRIBUTING and move it over?

Lets add the guide directly to CONTRIBUTING. I think it does not need to be complete from first commit as we have https://github.com/aiven/klaw/issues/99 that describes the desired state.

Thanks! Then I'll make a PR for that 🏃


replace ayj with ozevren as istioctl owner

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: ayj
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

istioctl/OWNERS [ayj]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/lgtm

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: ayj, ozevren
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

istioctl/OWNERS [ayj]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@ayj: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-dashboard.sh
75b89b19e6b3ad2b30b05778125e978f5bd5feb7
link
/test e2e-dashboard

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ayj: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-dashboard.sh
75b89b19e6b3ad2b30b05778125e978f5bd5feb7
link
/test e2e-dashboard

prow/e2e-simpleTests.sh
75b89b19e6b3ad2b30b05778125e978f5bd5feb7
link
/test e2e-simpleTests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ayj: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-dashboard.sh
75b89b19e6b3ad2b30b05778125e978f5bd5feb7
link
/test e2e-dashboard

prow/e2e-simpleTests.sh
75b89b19e6b3ad2b30b05778125e978f5bd5feb7
link
/test e2e-simpleTests

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
75b89b19e6b3ad2b30b05778125e978f5bd5feb7
link
/test istio-pilot-e2e-envoyv2-v1alpha3

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ayj: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-dashboard.sh
75b89b19e6b3ad2b30b05778125e978f5bd5feb7
link
/test e2e-dashboard

prow/e2e-simpleTests.sh
75b89b19e6b3ad2b30b05778125e978f5bd5feb7
link
/test e2e-simpleTests

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
75b89b19e6b3ad2b30b05778125e978f5bd5feb7
link
/test istio-pilot-e2e-envoyv2-v1alpha3

prow/e2e_pilotv2_auth_sds.sh
75b89b19e6b3ad2b30b05778125e978f5bd5feb7
link
/test istio_auth_sds_e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ayj: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-dashboard.sh
75b89b19e6b3ad2b30b05778125e978f5bd5feb7
link
/test e2e-dashboard

prow/e2e-simpleTests.sh
75b89b19e6b3ad2b30b05778125e978f5bd5feb7
link
/test e2e-simpleTests

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
75b89b19e6b3ad2b30b05778125e978f5bd5feb7
link
/test istio-pilot-e2e-envoyv2-v1alpha3

prow/e2e_pilotv2_auth_sds.sh
75b89b19e6b3ad2b30b05778125e978f5bd5feb7
link
/test istio_auth_sds_e2e

prow/e2e-mixer-no_auth.sh
75b89b19e6b3ad2b30b05778125e978f5bd5feb7
link
/test e2e-mixer-no_auth

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: ayj, nmittler, ozevren
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

istioctl/OWNERS [ayj,nmittler]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@ayj: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-dashboard.sh
75b89b19e6b3ad2b30b05778125e978f5bd5feb7
link
/test e2e-dashboard

prow/e2e-simpleTests.sh
75b89b19e6b3ad2b30b05778125e978f5bd5feb7
link
/test e2e-simpleTests

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
75b89b19e6b3ad2b30b05778125e978f5bd5feb7
link
/test istio-pilot-e2e-envoyv2-v1alpha3

prow/e2e_pilotv2_auth_sds.sh
75b89b19e6b3ad2b30b05778125e978f5bd5feb7
link
/test istio_auth_sds_e2e

prow/e2e-mixer-no_auth.sh
75b89b19e6b3ad2b30b05778125e978f5bd5feb7
link
/test e2e-mixer-no_auth

prow/istio-integ-k8s-tests.sh
75b89b19e6b3ad2b30b05778125e978f5bd5feb7
link
/test istio-integ-k8s-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

/retest


Cloud Storage Option

Hi
One feature that would be great is the ability to transfer files directly to cloud storage such as Mega, etc.
Some Services such as https://www.bytesloader.com give you this option. However, the site is not secure and riddled with ads. Would really appreciate this feature
Regards,
Kitty

The idea behind BTorrent is for it to be a decentralized P2P web app. Cloud storage is not in its plan.
Sorry Kitty


Added BLOB data support, rewrote argument binding

This pull request changes how arguments are bound for queries, allowing for Variant types like PoolByteArrays to be bound to BLOB-type columns. It also adds the ability to retrieve BLOB types from databases as a PoolByteArray.
The side effect of this is that any *_with_args command will only accept an Array containing the following Variant types:

Primitives (int, float, bool)
Strings
PoolByteArrays
null
Any other Variant types passed will cause the query to fail.

This pull request has been tested on Windows 10 64-bit, using Godot 3.1.1 stable.
Closes #41.

Do you know if khairul169 is still in the community?
Also, would it be better if this was a c++ module? I could do the work for it, but I don't think it'll get merged into master.

Khairul is still active on Github, but I haven't seen activity from them in the gdsqlite-native repository in a while. I may ask to take over as the maintainer of the repo if they're ok with it.
There was some talk about integrating SQLite into Godot's core, but the devs decided that it would be better handled as an optional community module.
I could bring back the engine module for platforms without proper working GDNative exports (iOS), but I'd want to integrate both module forms into a single repository. I don't want to copy changes from one repo into another.

I don't know to support both forms in the same repository.
Maybe you can have the main repository be the module and include the native machinery under it. The other way doesn't work.

By the way, I'm a part of https://github.com/godot-extended-libraries. Perhaps that would be helpful for advertising and pooling resources to put this gdsqlite-native library there?
@khairul169 Can you respond?


console messages

Hi nice work with this module.
The console messages like https://github.com/ijpiantanida/talkback/blob/master/src/tape-store.js#L42 don't play well with some test reporters I would like to have the option to disable those, could it be a configurable flag (verbose/debug) like summary? Or maybe use the debug module?

@evert0n thanks for the suggestion.
I added a silent option, as I want the messages to be printed by default.
Check 1.1.4.

@ijpiantanida Thanks


When scoring a revision, return the version of the model used

Something like this:
{
  "version": 12,
  "scores": {
    "123": {
      "reverted": { ... }
    },
    "456": {
      "reverted": { ... }
    }
}

or maybe
{
  "meta": { "version": 12, "timestamp": ..., "etc": ... },
  "scores": {
    "123": {
      "reverted": { ... }
    },
    "456": {
      "reverted": { ... }
    }
}

This might be useful when debugging user reports.

+1.  This will be critical for secondary caches to make use of too.  For example, the ORES extension for MediaWiki needs to store scores so they can by queried and filtered.  We need to provide a model version at least for that extension to do invalidation in a reasonable way.

The MediaWiki extension is not going to rely on this feature.  We'll run the "check model versions" job once an hour and use the most recent values like a global variable, so even in the worst-case scenario the only negative impact of not including the model version is that we've unnecessarily invalidated the previous hour of results.
Still, this seems like an important enhancement, and easy.  It does enable simple caching in any consuming application.

I like the "meta" version that Helder proposes, but we'd need to also be able to include the info in multi-model mode. Here's what I imagine:
/scores/enwiki?models=damaging|reverted&revids=123456788|123456789&model_info=version|trained|stats

{
  "model_info": {
    "damaging": {
      "version": "0.0.4",
      "trained":<PHONE_NUMBER>.00,
      "stats": {
         "auc": 0.8937382,
         "accuracy": 0.8892833
      }
    },
    "goodfaith": {
      "version": "0.0.4",
      "trained":<PHONE_NUMBER>.00,
      "stats": {
        "auc": 0.9201838,
        "accuracy": 0.756293
      }
    }
  },
  "scores": {
    "123456789": {
      "damaging": {
        "prediction": false, ...
     },
     "goodfaith": {
       "prediction": true, ...
     }
    },
    "123456788": {
      "damaging": {
        "prediction": true, ...
     },
     "goodfaith": {
       "prediction": true, ...
     }
    }
  }
}

I think that it would then make sense to include the "scores" sub-field in a simple request.  E.g.:
/scores/enwiki/damaging/123456788

{
  "scores": {
    "123456788": {
      "damaging": {
        "prediction": true, ...
     },
    }
  }
}

One thing I am struggling with is changing the output format for ORES.  If we do this, I'd like to do it once since we'll ask our users to update their code when we deploy.  It would also be nice if we could have a transition period.  I imagine implement a function that formats a scoring results based on a version number.  E.g. ?format=v2 and that the default would stay "v1" for some transition period.  This function would look like this:
def format_output(scorer_models, scores, model_info, version="v1"):
    """
    Formats a JSON blob of scores.

    :Parameters:
        scorer_models : `set`
            A set of scorer models used in generating the scores.
        scores : `dict`
            A JSONable dictionary of scores by revision ID and model.
        model_info : `set`
            A set of model information keys that should be includes (e.g. "version",
            "trained" and/or "stats")
        version : `str`
           An output format version to apply.  "v1" excludes any `model_info`.
           "v2" returns a more complex JSON document format that can
           contain `model_info`
    """
    ...

It would return a JSON blob ready for output.  If version is set to "v1", the response format could not contain the meta information.  If the version is set to "v2", the response format will look like the one above.

This was addressed in https://github.com/wiki-ai/ores/pull/121


Repository not downloadable by composer with Laravel 5.6

The I tried to install this repo with laravel 5.6 and it doesn't work ...

You know an error message or something would help?

@Skintillion It's says that I have to uninstall Laravel 5.6.
Found solution in another ticket but you've to check it again because Laravel 5.6 is stable now.
Thanks.


[#1244] feat(API, meta): Add basic API and metadata design for file catalog

What changes were proposed in this pull request?
This PR proposes to add the Fileset metadata support in Gravitino. Include the API, metadata design and implementation.
Why are the changes needed?
This is the first work of support file-based non-tabular data management in Gravitino.
Fix: #1244
Does this PR introduce any user-facing change?
Yes.
How was this patch tested?
Add some UTs to test metadata, API test will be added when the implementation is achieved.

I think we can corporate with OpenDAL community after we implemented a file catalog.  https://github.com/apache/incubator-opendal

In general,  we have three points to ensure.

Do we need the concept of directory? Do you need the api of directories?
For Hadoop compatible file apis, do we need the truncate api? Do we need to support soft-link? Do we need read/write api? It may be useful to record audit information for writing.
Do we need managed file system? If so, maybe we should support upload api. Databricks implement upload api. https://docs.databricks.com/api/workspace/dbfs/put

@coolderli Can you please take a review when you have time? Thanks.

Another discussion. Do we want to have some another data optimization in the file catalog? For example, we can transfer some cold data from the HDFS to S3. we can use more effective compression codec. We can clean some temporary files.

Another discussion. Do we want to have some another data optimization in the file catalog? For example, we can transfer some cold data from the HDFS to S3. we can use more effective compression codec. We can clean some temporary files.

This seems out of the scope of current file catalog. But I think it is doable with file catalog. What we need is to have several tools around file catalog.

@qqqttt123 @yuqi1129 @xloya @coolderli Can you please review again?

Overall looks nice to me, can not wait to see next pr :)

LGTM!

Another discussion. Do we want to have some another data optimization in the file catalog? For example, we can transfer some cold data from the HDFS to S3. we can use more effective compression codec. We can clean some temporary files.

This seems out of the scope of current file catalog. But I think it is doable with file catalog. What we need is to have several tools around file catalog.

Maybe later we can provide some services to govern tables and files on governance, for example, manage compaction、expire snapshots, etc.

Thanks all for your comments, greatly appreciated.


DCAC-47 - Fresh PR for handling POST request

@VaughanJackson123 @caismith-ch latest comments have been addressed in last commit 👍


implement the share command

currently, it just pins the post on the group. extend this functionality to allow sharing posts on other social media platforms, such as mastodon, instagram, ...
https://github.com/birlug/WiseAssBot/blob/482e12cb5abe3ac102308a1b7e86eb388e52575f/src/commands.rs#L6

Implemented here with another approach.


drop Mocha peer dep?

karma-mocha won't work without Mocha, of course.
But it won't work without Karma, either.
The idea behind peer dependencies is to help support "plugins".  karma-mocha is most certainly not a Mocha plugin.  So if anything, Karma should be the peer dependency, right?
But a peer dependency is just a static check, really.  I'm no big fan of them.  Instead of this, what if karma-mocha had a runtime check for a mocha package?  Maybe it already does?
Would you accept a PR that drops the peer dep and/or checks for Mocha at runtime?
(Backstory: Mocha is consuming Karma and karma-mocha to run its own tests.  Please see  mochajs/mocha#2487 for current state of affairs, and how we're trying to work around this.)

@boneskull karma should be in peer dependencies too like in karma-jasmine

But a peer dependency is just a static check, really.

Yes

I'm no big fan of them. Instead of this, what if karma-mocha had a runtime check for a mocha package?

Why? Why we should add additional code to karma-mocha if this already implemented in npm?

Why? Why we should add additional code to karma-mocha if this already implemented in npm?

Because the implementation of peer deps is problematic.  There's a reason npm v3 reduced unmet peer deps to a warning.  Users of npm v3 would have to npm install mocha anyway, so why not change the install instructions in README to something like npm install karma karma-mocha mocha?
FWIW, the code would amount to:
try {
  require('mocha');
} catch (err) {
  throw new Error('karma-mocha requires Mocha; install via "npm install mocha"`);
}

The point of this ticket is that I can't use karma-mocha to test Mocha itself without either a) forking karma-mocha or b) really lame workarounds.  Dropping the peer dep would solve this problem, at little cost to other users.

@boneskull thanks, now I understand your pain but how you will resolve problem with require.resolve('mocha')?

NODE_PATH=. karma start

@boneskull ok, I have no reason why we can not remove peer dependency.

@maksimr ping on #116


random crash

Description
it crasht in the background
Steps To Reproduce
idk
Requirements

eg. Fix crash that occurs when...

Files Version
<IP_ADDRESS> (github)
Windows Version
10.0.19045.2728
Log file
debug.log

I don't see anything specific in the log file, if it happens again, try to put together steps we can use to reproduce on our end and let us know.

This might be something to do with Windows since I've had Files close after about 10 minutes of being idle with no errors at all.

That shouldn't happen, I'll keep an eye out for similar reports.

idk i opened a folder then i left it in the background for about 20 seconds and then it crasht

and now it's making my pc lag


Removed false @Nonnull

Pull Request Etiquette

[x] I have checked the PRs for upcoming features/bug fixes.
[x] I have read the contributing guidelines.

Changes

[ ] Internal code
[x] Library interface (affecting end-user code)
[ ] Documentation
[ ] Other: _____

Description
Just removed a false @Nonnull annotation in the getEmoji() method of the Region Enum.

Why was this closed?

Mb


Generate pgbadger report while running something else

Usage:
./with-pgbadger make test

etc.

This seems like it'd be worth merging. Maybe with a couple of examples in the README so we don't forget that it exists and actually know what to do with it?

@lognaturel i've added inline docs (e.g. with-pg-badger --help)


no instructions on how to access ftps stored in config

how do i actually use this?

Hi,
there is a description in the Readme / index page of this repo.
https://github.com/NoxArt/SublimeText2-FTPSync
Also there are Wiki entries
https://github.com/NoxArt/SublimeText2-FTPSync/wiki
In Sublime, you can find individual actions and commands in:

Current file's context menu
Sidebar's context menu
Command pallete
Preferences > Key bindings

As for the most basic functionality:
If the connection is setup, saving the file is uploaded on saving the file (unless this is disabled).
To browse the FTP choose Browse from current file's context menu or command pallete.
Hope this clears it up

Thanks! I completely missed that. I'd like to suggest that you put a small notice in the main readme either pointing to the wiki page or even a copy/paste from there to get started quickly.


appveyor git lfs clone debugging

I can't find any official documentation indicating that appveyor supports git lfs, but this clone succeeds even after we remove the yaml lines that {install git lfs, and fetch the files} post-clone. It looks like appveyor now has native git lfs support.


Maven artifact

Would it be possible to publish lobo evolution as a maven artifact, so it can be used as a library dependency with standard build tools on the JVM?

Any news on this?

In the future i fix this issue

Add link for maven activity, sorry for notification
https://issues.sonatype.org/browse/OSSRH-50916
https://dzone.com/articles/publish-your-artifacts-to-maven-central

Hello @Sciss
you can add loboevolution at your maven project

com.github.oswetto
loboevolution
1.0


Support Python 3 in virtual envs

It's not porting terraform itself to Python 3. Terraform still runs with Python 2.7, but now supports -p flag to set Python version inside virtualenv. This simple change should be enough for people who need Python 3 support.

I fixed as many travis tests I could, but there are still some that are failing from master branch too. I wonder if there's value in keeping all these virtualenv minor versions in matrix. Maybe it's best to have only most recent in 1.x series and most recent in 15.x series? These seem to work fine.