Duplicated selectors in SASS

This is a...

[ ] Feature Request
[x] Bug Report

Problem:
There are duplicated selectors in SASS.
Proposed Solution:
Remove Duplicated selectors from SASS and CSS.
Page to Update:
n/a

/assign
/kind cleanup design

/remove-lifecycle stale


Filter Alignment

Probably goes into the same issue like her: #847
If there is no color box in front of the filter, the text should be leftaligned with the other elements:
Also the spacing between the elements (line height) should be optimized.

Still doesn't look aligned to me ;-) @bprusinowski

Should be fine on TEST now 🤞


Problems with emacsclient

I've cloned the repo, ran a normal emacs instance and everything was fine. But when I run emacs as daemon the theme font is not loaded correctly, the font size is different and the start screen is not shown, it goes directly to the scratch buffer.

Not sure on the font issue, but I believe I have fixed the issue showing the startup screen in emacsclient. Can you please pull the updates and try again.
For the font issue, how are you setting it? Are you setting it in your early-config.el file?
Thanks for the report!

Thank you for the prompt reply, I will test it. As for the font, I did not set it. I've just used the example-config of the repo, who uses load-theme from doom themes. Using the example-config alone there is a difference between the fonts and fonts sizes between emacs and emacsclient.

Thank you for the quick reply. The problem with the start screen was solved with the commit.
The problem with the fonts persists. I am using the default example-config. I've tried to move block
  (custom-set-variables
     '(rational-ui-default-font
       '(:font "JetBrains Mono" :weight light :height 185)))

to early-config (maybe, if this is the right way, the example-config should be changed as well), but even there I see two problems. In both emacs and emacsclient the height parameter is not respected. Aside from that, the font seem to be load correctly in the emacs regular instance, but don't load in the emacsclient.

Hm... not sure, I'll see if I can debug it. Maybe @jeastman could help with this also?
This is what I have in my early-config.el and I don't have a problem with the faces, heights, etc. but I'm not using the code from the example either.
;; Set the default font face before displaying the frame to avoid
;; resize issues.
(cond
 ((string-equal (symbol-name system-type) "windows-nt")
  ;; Windows does not have Anonymous Pro, use Courier New instead
  (custom-set-faces (backquote (default ((t (:family "Courier New" :height 140)))))
                    (backquote (fixed-pitch ((t (:height 140 :inherit (default))))))
                    (backquote (fixed-pitch-serif ((t (:height 140 :inherit (default))))))))
 ((string-equal (symbol-name system-type) "darwin")
  ;; MacOS does not have Anonymous Pro, use Monaco instead
  (custom-set-faces (backquote (default ((t (:family "Monaco" :height 180)))))
                    (backquote (fixed-pitch ((t (:height 180 :inherit (default))))))
                    (backquote (fixed-pitch-serif ((t (:height 180 :inherit (default))))))))
 (t
  ;; Linux systems, can easily install this font
  (custom-set-faces (backquote (default ((t (:family "Anonymous Pro" :height 180)))))
                    (backquote (fixed-pitch ((t (:height 180 :inherit (default))))))
                    (backquote (fixed-pitch-serif ((t (:height 180 :inherit (default)))))))))

Following that pattern, you could probably use something like this:
(custom-set-faces (backquote (default ((t (:family: "JetBrains Mono" :weight light :height 185))))))
The issue might be the :font keyword, I'm not sure that is a supported spec keyword in Emacs, but I'll have to do some research.

The :font keyword is allowed, however, the example file is incorrect. The correct usage of :font would be:
  (custom-set-variables
     '(rational-ui-default-font
       '(:font "JetBrains Mono Light 18")))

I am not seeing this font being set when I use a minimal configuration to only set the font (ie, no rational modules and I manually set the face in early-config.el) regardless if I run emacs or emacsclient.
Still working on it.

I've deleted the code block setting the rational font and added (add-to-list 'default-frame-alist '(font . "JetBrains Mono")) to my early-config.el and that solved the problem.
I did by blindly copying and pasting from stackoverflow. What was the problem or why this has solved the issue, I don't know.

Here is why that worked:
During startup, the early-init.el and subsequently (in our case) the early-config.el file is loaded.  This happens before any graphical elements are created. You modified the default-frame-alist which is the list of parameters for all frames launched by Emacs. The very first frame can have different parameters from the rest by modifying the initial-frame-alist.  The parameters in this list only affect the first frame (not the subsequent ones - those are controlled by the default-frame-alist).
The initial graphical frame is created with the initial (or when that is nil the default) parameters just before the init.el and subsequently in our case the config.el files are loaded. Your config.el file might load more configuration for the UI as well.
However, there is one more place to configure UI settings, that is the emacs-startup-hook.
Once the emacs-startup-hook is run, Emacs then runs the frame-notice-user-settings function to update the frame.
So, you can set the font as you did in the default-frame-alist, or you can add code like the following to your config.el which is maybe the slightly more recommended approach compared to others:
 (add-hook 'emacs-startup-hook
	  (lambda ()
	    (custom-set-faces
	     `(default ((t (:font "JetBrains Mono Light 12"))))
	     `(fixed-pitch-serif ((t (:inherit (default))))))))

I'll update the example as this method will also resolve the issue you were seeing.


COE Display - Allow Institution to Separate By Intensity

User Story
As an Institution user I want to be able to differentiate Full Time from Part Time COEs on the Dashboard so I can navigate the work required.
Current Behaviour
In the COE -> "Confirm Enrolment" dashboard, Student name is searchable and the following information is displayed about each pending application: Student Name (Sortable), Study dates, Application #, Disbursement date, Status (Sortable), Action (View button).

2 POSSIBLE Expected Outcomes
OPTION ONE
In the COE -> "Confirm Enrolment" dashboard the following information is displayed about each pending application: Student Name, Intensity, Study dates, Application #, Disbursement date, Status, Action (View button).

OPTION TWO
In the COE -> "Confirm Enrolment" dashboard the same information is displayed (Student Name (Sortable), Study dates, Application #, Disbursement date, Status (Sortable), Action (View button)) and the Institution user can filter by Intensity using a Select Box (Full Time, Part Time)

Acceptance Criteria
OPTION 1

[ ] Add column to display the intensity (Full Time or Part Time) of the application
[ ] Provide a sort button beside the Intensity column header that when clicked Sorts By Intensity and when clicked subsequent times changes the order (ASC->DESC / DESC->ASC)

OPTION 2

[ ] Add Select Box form item with label of "Filter By:" with options for Full Time and Part Time.
[ ] Change the applications visible based on the selection made by the user.

@HRAGANBC I suspect there will be more questions re development of the filter (Opt 2). Let me know if this aligns with your impression of what we talked about.

@CarlyCotton please tag to appropriate release when ready- thank you

May also need to implement in PIR

Should also review for other columns to be sortable / more columns to be added.


Remove minorVersion from handshake response

The master branch needs to be updated with the new information regarding the minorVersion field in the Handshake Response.
Let's remove the minorVersion from the handshake response, since we aren't using it yet (see comments below).

Triage decision: We aren't using minorVersion so let's actually remove the field. It was added in 3.0 so it's non-breaking to remove now. If we need to in the future we can add it back later or have the client send a version number like ASP.NET SignalR does today.

Acceptance checklist* (check one item)

[ ] We decided not to take this fix.
[ ] The fix is tests-only.
[X] The fix contains product changes (check all items below).

[X] Relevant XML documentation comments for new public APIs are present.
[X] Narrative docs (docs.microsoft.com) are updated. (check one item below)

[ ] The change requires a new article. An issue with an outline has been filed here: [ISSUE LINK]
[ ] The change requires a change to an existing article. A closed docs PR with these changes is linked here: [PR LINK]
[X] The change requires no docs changes.

[X] Verification has been completed. (check one item below)

[X] The change is in the shared framework and was verified against the following versions

SDK installer: [3.0.100-preview6-011846]
ASP.NET Core Runtime: [3.0.0-preview6-19260-04]
.NET Core Runtime: [3.0.0-preview6-27711-03]

[X] The change is in an OOB NuGet/NPM/JAR package and was verified against the following version of that package: [Microsoft.AspNetCore.SignalR.Common] [3.0.0-preview6-19260-01]


Added a node size value to the constructors of focusedNode.js and regionNode.js

I ran into this when I set layout: "ringCenter" on a renderer: "region" node.  It results in all the nodes being stacked in the center on top of each other.  The issue was that for the regionNode.js and focusedNode.js don't have a default node size, so in ringCenterLayout.js when recalcaluteOrbitSize was called nodeSize was undefined and orbitSize became NaN and everything went downhill from there.  Since ringCenter worked for renderer: "global" I just mimicked what was already in globalNode.js and dnsNode.js.  I arbitrarily picked a size after looking at the sizes set in globalNode.js and dnsNode.js.  At any rate, adding a default size fixed the issue of using the ringCenter layout with at least the region renderer.

Interesting.  Yeah, those node types are not used in the ringCenterLayout by us, so never thought about a default node size for those.  Looks like there isn't really a consistent pattern as far as node size is concerned. It would make sense to eventually normalize what node size does.
However, the different node views (DetailedNodeView and StandardNodeView) do something different with size and don't respect node.size so I'm not sure it makes sense to add a default size   to these node types. Since both those renderers can be used for one node, that would have to be refactored somehow.
One way to get around it would be to pass in size in the graph data itself.

I don't see where NodeViewStandard uses node size at all and DetailedNodeView looks to use it as to set radius, but I don't see where it manipulates it or such... I'm probably just not grasping it.  The ringCenter layout isn't even actually using the node size to modify the nodes.  It is just used as part of determining a new orbit size once all the nodes have an initial position set, so...
What do you think about just adding check for undefined in ringCenterLayout?  Either in recalculateOrbitSize or wrapped around the call to recalculateOrbitSize that sets a value if it is undefined.  That would fix the ringCenter layout and not imply some sort of standardized node size, usage of node size, etc.  That way if someone is poking around in the code like me and they won't see a uniform looking default node size and think it is significant.
Thoughts?

You are correct, they do not use node size at all.  You hit my concern in the second bit, I don't want to imply some sort of standardized node size. nodeViewDetailed uses node size to size the node view itself.
Although, after spending some more time looking at it, your approach works great, it was just confusing because of some cruft. I'll merge your changes, then make a few more changes to make it more consistent.
Thank you!

Just pushed my changes to master too, let me know how it works for you. If it works, I'll cut a new patch release.

Great! I just pushed the patch.
I don't have example JSON handy at the moment using focused, but it's intent is if you are using the Vizceral renderer for only one graph with a focused node.  It makes less sense in a drillable graph, which is why the example one uses focusedChild.
As fas the dns combination renderer/layout, yes, it's meant to be purely horizontal layers.  We use it for a small subset of our DNS infrastructure to show where the DNS records are pointed.  There's only 3-4 nodes per row in how we are using it.  Outside of that, probably not as much use for it.
You are welcome. Would love to see how you are using Vizceral when you get something together!


add zoom and pan

https://gist.github.com/ianhi/b638e09fa7a00764ea539940a0519af9
https://gist.github.com/ianhi/5f514c31f13cc28fbd167849867122b7

check how to credit the simp_zoom gist https://gist.github.com/tacaswell/3144287


array_contains returning unexpected values with column parameter

Describe the bug
The array_contains code seems to be overly-flattening input lists and in doing so is generating incorrect data when one of the parameters is a column of List-type.
To Reproduce
I've attached a parquet table containing a column with type List(String).
When use array_contains on this data, I get this result set:
❯ create external table t0 stored as parquet location '/Users/max/tmp/array_contains.parquet';
0 rows in set. Query took 0.017 seconds.
❯ select bid_node_ids from t0 where array_contains(bid_node_ids, ['z+CPVybgUuCXlAE3A3jqyg==']);
+----------------------------+
| bid_node_ids               |
+----------------------------+
| [okwzcOFM3yjUzNFbc/BYBQ==] |
| [DbNysJTF560NzR/HLbAa/Q==] |
| [ivO3+Z+WMRqwhivy85d6KA==] |
+----------------------------+
3 rows in set. Query took 0.076 seconds.
❯

Note that none of the resulting bid_node_ids values contain the queried-for value of z+CPVybgUuCXlAE3A3jqyg==
array_contains.parquet.zip
Expected behavior
I was expecting that there are 861 matching results in the result set, all of which contain the value z+CPVybgUuCXlAE3A3jqyg==
❯ select bid_node_ids from t0 where array_contains(bid_node_ids, ['z+CPVybgUuCXlAE3A3jqyg==']);
+--------------------------------------------------------------------------------+
| bid_node_ids                                                                   |
+--------------------------------------------------------------------------------+
| [wFEkOS2AFYxekv7SzPrkiQ==, z+CPVybgUuCXlAE3A3jqyg==]                           |
[....snip...]
| [O3GAOhhCbfxgXcZEwLI7aQ==, z+CPVybgUuCXlAE3A3jqyg==]                           |
| [O3GAOhhCbfxgXcZEwLI7aQ==, z+CPVybgUuCXlAE3A3jqyg==]                           |
| [z+CPVybgUuCXlAE3A3jqyg==]                                                     |
| [iTd7HyShRr0PqSKyqKT0+A==, z+CPVybgUuCXlAE3A3jqyg==]                           |
| [edSh3ZpG53UB+JMV875ipg==, z+CPVybgUuCXlAE3A3jqyg==]                           |
| [O3GAOhhCbfxgXcZEwLI7aQ==, z+CPVybgUuCXlAE3A3jqyg==]                           |
| [edSh3ZpG53UB+JMV875ipg==, z+CPVybgUuCXlAE3A3jqyg==]                           |
| [O3GAOhhCbfxgXcZEwLI7aQ==, z+CPVybgUuCXlAE3A3jqyg==]                           |
| [O3GAOhhCbfxgXcZEwLI7aQ==, z+CPVybgUuCXlAE3A3jqyg==]                           |
| [edSh3ZpG53UB+JMV875ipg==, z+CPVybgUuCXlAE3A3jqyg==]                           |
| [edSh3ZpG53UB+JMV875ipg==, z+CPVybgUuCXlAE3A3jqyg==]                           |
+--------------------------------------------------------------------------------+
861 rows in set. Query took 1.069 seconds.

Additional context
I've hacked together a change on our branch that gives us the changes we are expecting: https://github.com/urbanlogiq/arrow-datafusion/commit/a381f10257243b22375b42973d7701a3130c05e1 but I'm not sure if this fix is what is intended by the original author.

The issue can be closed since the task of array_has_all has been accomplished.

We've confirmed that array_has_all meets our needs. We can close this.


fix(curriculum): typo

Checklist:

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the main branch of freeCodeCamp.
[x] I have tested these changes either locally on my machine, or GitPod.

Closes #XXXXX
Fixed confusing typos [ "併爲" -> "並為" ]

Hey @llovvoll
Thank you for opening this pull request. We cannot accept here changes to languages other than English. Files in other languages can be changed using the translation workflow. You may read more about it in our guidelines for contributing,
Thank you and happy coding.


Updated Russian data

This is a complete scrape of Russian. When I ran remove_duplicates.sh it rearranged some entries in the new Welsh TSVs (which Kyle sorted on his computer). This is not too dissimilar from something I noticed earlier when I ran remove_duplicates.sh on a different computer and saw that it rearranged files that had already been sorted (and considered certain things duplicates that were not actually duplicates - which did not happen in this instance).
The suggestion at the time of using usr/bin/sort as opposed to just sort in remove_duplicates.sh did not change this behavior. Should I open a ticket regarding this?

The suggestion at the time of using usr/bin/sort as opposed to just sort in remove_duplicates.sh did not change this behavior. Should I open a ticket regarding this?

+1 for opening a ticket. It looks like the sorting changes in this PR treated the tab to be "less" than the letters, which seems right based on the ASCII table. I wonder if we are on different systems (e.g., MacOS vs Linux) where sort may behave differently by any chance? Not sure.

Does this mean we have to rerun Russian experiments on the new data?
-am
On Nov 30, 2019, 12:54 PM -0500, Kyle Gorman<EMAIL_ADDRESS>wrote:

Merged #115 into master.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

I didn't use Russian for the validation experiments for the simple reason
that it wasn't ready, so no we're good.
On Sat, Nov 30, 2019 at 1:12 PM Arya McCarthy<EMAIL_ADDRESS>wrote:

Does this mean we have to rerun Russian experiments on the new data?
-am
On Nov 30, 2019, 12:54 PM -0500, Kyle Gorman<EMAIL_ADDRESS>wrote:

Merged #115 into master.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/kylebgorman/wikipron/pull/115?email_source=notifications&email_token=AABG4OKT4YTMLYBVPMWLO4LQWKUH7A5CNFSM4JTHMYX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFQQR5Q#issuecomment-560007414,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABG4ONMIR5NNR7MUVUB67TQWKUH7ANCNFSM4JTHMYXQ
.


[SPARK-46582][R][INFRA] Upgrade R Tools version from 4.0.2 to 4.3.2 in AppVeyor

What changes were proposed in this pull request?
This PR proposes to upgrade R Tools version from 4.0.2 to 4.3.2 in AppVeyor
Why are the changes needed?
R Tools 4.3.X is for R 4.3.X. We did not upgrade because of the test failure previously.
Does this PR introduce any user-facing change?
No, test-only.
How was this patch tested?
Checking the CI in this PR.
Was this patch authored or co-authored using generative AI tooling?
No.

Merged to master.

hmm... the corresponding download link for rtools43 is: https://cloud.r-project.org/bin/windows/Rtools/rtools43/files/rtools43-5863-5818.exe, can the correct download link be generated by only changing the script.... @HyukjinKwon

I have tried to upgrade rtools before, and if I remember correctly, there were compilation failures of gcc at that time. Since I didn't see the specific test link for this pr, I want to confirm.

Oh, right. According to the log, it hits 404 error but the failure is ignored like the following.
[00:01:07] Start-FileDownloadInternal : Error downloading remote file: One or more errors occurred.
[00:01:07] Inner Exception: Remote server returned 404: Not Found
[00:01:07] At C:\Program Files\AppVeyor\BuildAgent\Modules\build-worker-api\build-worker-api.psm1:242 char:2
[00:01:07] +     Start-FileDownloadInternal -Url $Url -FileName $FileName -Timeout ...
[00:01:07] +     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[00:01:07]     + CategoryInfo          : NotSpecified: (:) [Start-FileDownloadInternal], Exception
[00:01:07]     + FullyQualifiedErrorId : System.Exception,Appveyor.BuildAgent.Api.Utils.StartFileDownloadInternalCmdlet
[00:01:07]
[00:01:07] Start-Process : This command cannot be run due to the error: %1 is not a valid Win32 application.
[00:01:07] At C:\projects\spark\dev\appveyor-install-dependencies.ps1:59 char:3
[00:01:07] +   Start-Process -FilePath .\Rtools-current.exe -ArgumentList /VERYSIL ...
[00:01:07] +   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[00:01:07]     + CategoryInfo          : InvalidOperation: (:) [Start-Process], InvalidOperationException
[00:01:07]     + FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand
[00:01:07]
[00:01:07] Rtools is now available on drive C:
[00:01:07]
[00:01:07]
[00:01:07]     Directory: C:\
[00:01:07]
[00:01:07]
[00:01:07] Mode                LastWriteTime         Length Name
[00:01:07] ----                -------------         ------ ----
[00:01:07] d-----         1/4/2024  12:25 AM                RLibrary

Maybe, do you want to revert this first, @HyukjinKwon ?

oh

reverting now.

Thank you for reverting, @HyukjinKwon !


skip on_serve if self.originalDocsDir is None

this is a simpler alternative to #69 that i'm only putting up in the interest of expediency as we want to push out backstage techdocs in our org and plan to recommend techdocs-cli (specifically serve w/ hotreload) for local development! we'd prefer not to force repos to include a nav mkdocs directive if it's only required due to a bug in this plugin
resolves https://github.com/backstage/backstage/issues/8110

closing in favor of #69


Update cylc to 6.5 on accessdev

keyword_TIWG resolution_fixed   |    by<EMAIL_ADDRESS>

Issue migrated from trac:199 at 2024-01-31 18:14:07 +1100

<EMAIL_ADDRESS>commented

Created a branch mrd599/cylc6p6 that installs cylc 6.6.0, rose 2015.08.0, fcm 2015.08.0.
Clean reboot of accessdev-test gives errors relating to pip
Notice: /Stage[main]/Pkg::Python::Pip/Package[python-pip]/ensure: created
Error: Could not update: Could not locate the pip command.
Error: /Stage[main]/Rose::Dependencies/Package[requests]/ensure: change from absent to 2.5.1 failed: Could not update: Could not locate the pip command.
Error: Could not set 'present' on ensure: Could not locate the pip command. at 11:/etc/puppet/modules/trac/manifests/packages.pp
Error: Could not set 'present' on ensure: Could not locate the pip command. at 11:/etc/puppet/modules/trac/manifests/packages.pp

etc

and many python packages don't get installed. Same error when running a puppet apply. However pip seems to be installed properly.
Boot command was
./tools/nova-boot --name accessdev-test.nci.org.au --ip <IP_ADDRESS> --repo git@repos.nci.org.au:p/access.dev/puppet --branch mrd599/cylc6p6 --install-updates   --  --image centos-6.7-20150816 --flavor m1.small.2 --key-name mrd599 --security-groups ssh,http,umui,ping

<EMAIL_ADDRESS>commented

Hilary's announcement https://groups.google.com/forum/#!topic/cylc-dev/wmKHcOztWmg says that 6.6 isn't far off so it might be better to wait.

<EMAIL_ADDRESS>changed owner from `` to mrd599

<EMAIL_ADDRESS>commented

For now just created a link by hand and everything gets installed properly.
Testing shows a cylc issue https://github.com/cylc/cylc/issues/1582

<EMAIL_ADDRESS>commented

This is due to a change in the pip package which means Puppet looks for the executable in the wrong place - https://tickets.puppetlabs.com/browse/PUP-3829
Try creating a resource like:
file { '/usr/bin/pip-python':
   ensure => 'link',
   target => '/usr/bin/pip',
   require => Package["python-pip"],
   before => Package<|provider=pip|>,
}

which should create a symlink to the file puppet's looking for

<EMAIL_ADDRESS>commented

Testing new version of fcm
7.3 standard job vabga
The UMUI generates a script with module load fcm/2014.06.0. Using the new fcm (2015.08.0) on accessdev-test and this module on raijin works ok. The bld.cfg and ext.cfg files created with current accessdev default (2014.11.0) and 2015.08.0 are identical.
Other testing
vn10.2 rose stem tests run ok with new utilities.

<EMAIL_ADDRESS>changed status from new to assigned

<EMAIL_ADDRESS>commented

Martin has tested updated rose, cylc & fcm, will install to accessdev proper

<EMAIL_ADDRESS>changed _comment0 which not transferred by tractive

<EMAIL_ADDRESS>commented

Cylc 6.7.1 fixes issue mentioned above.
rose 2015.10.1 and fcm 2015.10.0 have been released.

<EMAIL_ADDRESS>commented

Now also rose 2015.10.0 and fcm 2015.09.0.
Testing shows a new cylc bug, https://github.com/cylc/cylc/issues/1628
With this patched on raijin things work properly (see Guides/UpdatingRoseCylc" for testing description).

<EMAIL_ADDRESS>commented

cylc 6.7.0 has been released.
This includes a change that was supposed to make the remote command compatible with other shells, https://github.com/cylc/cylc/commit/c2c5adc4c5f9f6fd7e9a9c532ee3d857da7a7913.
Effectively this means that cylc on raijin now runs a command like
ssh<EMAIL_ADDRESS>env CYLC_VERSION=6.7.0 /usr/local/cylc/cylc-6.7.0/bin/cylc message "started"

whereas previously it was
ssh<EMAIL_ADDRESS>CYLC_VERSION=6.6.1 /usr/local/cylc/cylc-6.6.1/bin/cylc message "started"

The NCI remote-job-submission script rejects this because env isn't on the allowed list.
As a short-term fix, changing the raijin lib/cylc/remote.py to remove the extra env works. However it's also necessary to strip off the -dirty suffix that gets appended to the version string. git diff gives
diff --git a/lib/cylc/remote.py b/lib/cylc/remote.py
index 6669e4f..668ed86 100644
--- a/lib/cylc/remote.py
+++ b/lib/cylc/remote.py
@@ -109,7 +109,8 @@ class remrun(object):
                 "use login shell", self.host, self.owner)

         # Pass cylc version through.
-        command += ["env", "CYLC_VERSION=%s" % CYLC_VERSION]
+        # dirty suffix causes problems with the remote shell permissions
+        command += ["CYLC_VERSION=%s" % CYLC_VERSION.replace('-dirty','')]

         if ssh_login_shell:
             # A login shell will always source /etc/profile and the user's bash

<EMAIL_ADDRESS>changed resolution from `` to fixed

<EMAIL_ADDRESS>commented

Just when I thought this was finally done -
https://github.com/metomi/rose/issues/1737
For now I've changed /usr/local/rose/2015.10.1/bin/rosie-go to just print a message suggesting using the 2015.04.1 version.

<EMAIL_ADDRESS>commented

From the rose 2015.11.0 release notes
rose suite-hook: will no longer retrieve remote job logs by default, this can now be handled by cylc. If this functionality is still required for whatever reason, use the --retrieve-job-logs option.
For backwards compatibility added this option to rose-task-hook2.

<EMAIL_ADDRESS>changed status from assigned to closed

<EMAIL_ADDRESS>commented

Rose 2015.11.0 and cylc 6.7.2 installed (branch mrd599/cylc-6.7.2)
Also modified rose configuration to fix #254.

<EMAIL_ADDRESS>commented

All seems to be working ok. Currently running suites (excluding those that haven't done anything for a week)

Version
No. running

6.4.1
5

6.7.1
2

6.7.2
13

The Met Office vn10.3 release notes (https://code.metoffice.gov.uk/trac/um/wiki/ReleaseNotes10.3) say The rose-stem suite at UM 10.3 is intended for use with FCM 2015.05.0, Rose 2015.06.0 and Cylc 6.4.1 so we're actually ahead.
Closing the ticket before another new version gets released.


HHH-18033 Fix LimitHandler detect wrong statement end if sql contains quoted semicolon

https://hibernate.atlassian.net/browse/HHH-18033

@gavinking Please review.

I wonder if, since we're messing with this, we should also recognize line-ending comments of form -- text.

I don't think people will pass such sql to entityManager.createNativeQuery().

Probably not, but they definitely might if it's a named query, especially one declared in XML.

I don't think people will pass such sql to entityManager.createNativeQuery().

Probably not, but they definitely might if it's a named query, especially one declared in XML.

Same as spaces, we should strip comments before reaching here, and it should be handled in another PR.

I wonder if, since we're messing with this, we should also recognize line-ending comments of form -- text.

Thinking this through, it's probably impossible to distinguish a line-ending comment from a quoted string literal containing the character sequence -- without a proper scanner.
So forget this suggestion.

Oracle12LimitHandler fixed also.


systemd file doesnt work

systemd file exits with the following error
     Loaded: loaded (/etc/systemd/system/ytdlp2strm.service; enabled; vendor preset: enabled)
     Active: activating (auto-restart) (Result: exit-code) since Mon 2023-11-06 07:04:02 GMT; 1s ago
    Process: 228880 ExecStart=/usr/bin/python3 /opt/ytdlp2STRM/main.py (code=exited, status=1/FAILURE)
   Main PID: 228880 (code=exited, status=1/FAILURE)
        CPU: 352ms

could be with how you starting it i recommend specifying a user and using the following exec start
ExecStart=/bin/bash -c cd /opt/ytdlp2STRM/ && python3 main.py

can you paste here the full output. (you can check this with systemctl status ytdl2strm.service)
Tell me your OS version.
If you set this to root, you don't need to specify the user in the .service file

can you paste here the full output. (you can check this with systemctl status ytdl2strm.service) Tell me your OS version. If you configure ytdlp2strm as root, you don't need to specify the user in the .service file

it could be that then as i specifically don't run anything as root, not even my own code,

with chown youruser:yourgroup -R /opt/ytdl2strm may be works


Fix message too long

[x] All tests pass
[x] I have run npm run doc

Description

This PR try to solve the issue with the error "Message too long" when sending message larger than 4096 characters.
I think this is somthing that the library should handle and don't let the user deal with it.
References

Issue #223 https://github.com/yagop/node-telegram-bot-api/issues/223
Issue #19  https://github.com/yagop/node-telegram-bot-api/issues/19

I have generated the new doc because i have added some line to the documentation comment of the sendMessage() function. Let me know if it is ok.
Love your work!

Tbh this is outside the scope of NTBA. NTBA is meant to be a low level library. Such a feature should be handled by user level code  that guarantees order, retry and memory safety. Also async/await breaks the current code style of this library.
You can tag me on the Telegram group if you want to discuss more.


Don't patch d3-selection and d3-transition globally

We recently ran into a problem where we had the following scenario: Module A was using d3-jetpack and d3-selection, and it was also importing module B which was using d3-jetpack and d3-selection. But it turned out that if B is importing a different version of d3-selection than A, but both are using the same version of d3-jetpack, only one version of d3-selection got patched (the one B was using). So all the imports from d3-selection in A did not have the jetpack patch.
There is really no good way to fix this from the outside so I think we should fix this here. I see two possible strategies:

The consumer module passed the selection and transition objects (or their prototypes?) to a sort of initialize() method exported by d3-jetpack:

// module A
import { selection, select } from 'd3-selection';
import { transition } from 'd3-transition';
import { initJetpack, drawAxis } 'd3-jetpack';

initJetpack(selection, transition);

d3-jetpack exports the stuff from d3-selection and d3-transition:

// module A
import { drawAxis } from 'd3-jetpack';
import { select } from 'd3-jetpack/selection';

Since I am nowadays bundling all my code using rollup anyway I think I am leaning to option 2.

I could live with either. I think both will work fine with a script tag; we should check how awkward observablehq usage is.
Could we copy what d3-transition does? @Fil, I haven't looked closely at the implementation or what happens in a similar situation—any tips?
Do you want to switch to this and d3v6 in one breaking change?

transition attaches itself to selection here https://github.com/d3/d3-transition/blob/master/src/selection/index.js;
d3-selection is defined as a peer dependency in https://github.com/d3/d3-transition/blob/master/package.json#L44
’s all I can say.


Error: Cannot find module '@aws-sdk/property-provider'

We've been using this plugin for a couple of months now.
But suddenly, it stopped working with the following error message.
$ npx @datadog/datadog-ci dsyms upload /Users/runner/work/ios/redacted.dSYM.zip
[08:50:50]: ▸ npm WARN exec The following package was not found and will be installed<EMAIL_ADDRESS>[08:51:10]: ▸ Error: Cannot find module '@aws-sdk/property-provider'
[08:51:10]: ▸ Require stack:
[08:51:10]: ▸ -<EMAIL_ADDRESS>[08:51:10]: ▸ -<EMAIL_ADDRESS>[08:51:10]: ▸ -<EMAIL_ADDRESS>[08:51:10]: ▸ -<EMAIL_ADDRESS>[08:51:10]: ▸ at Module._resolveFilename (node:internal/modules/cjs/loader:1075:15)
[08:51:10]: ▸ at Module._load (node:internal/modules/cjs/loader:920:27)
[08:51:10]: ▸ at Module.require (node:internal/modules/cjs/loader:1141:19)
[08:51:10]: ▸ at require (node:internal/modules/cjs/helpers:110:18)
[08:51:10]: ▸ at Object.<anonymous> (/Users/runner/.npm/_npx/2c8d683be5ffbe89/node_modules/@datadog/datadog-ci/dist/commands/lambda/functions/commons.js:37:29)
[08:51:10]: ▸ at Module._compile (node:internal/modules/cjs/loader:1254:14)
[08:51:10]: ▸ at Module._extensions..js (node:internal/modules/cjs/loader:1308:10)
[08:51:10]: ▸ at Module.load (node:internal/modules/cjs/loader:1117:32)
[08:51:10]: ▸ at Module._load (node:internal/modules/cjs/loader:958:12)
[08:51:10]: ▸ at Module.require (node:internal/modules/cjs/loader:1141:19) {
[08:51:10]: ▸ code: 'MODULE_NOT_FOUND',
[08:51:10]: ▸ requireStack: [
[08:51:10]: ▸<EMAIL_ADDRESS>[08:51:10]: ▸<EMAIL_ADDRESS>[08:51:10]: ▸<EMAIL_ADDRESS>[08:51:10]: ▸<EMAIL_ADDRESS>[08:51:10]: ▸ ]
[08:51:10]: ▸ }

Is this something that you can address? Or can we do something about it?
Thanks!

Hey @msrutek-paylocity !
Looks like an issue from datadog-ci which this plugin is based of.
A fix has already been merged and it will be published very soon!

Thanks for the prompt response! We'll try this again in a bit.

@maxep  I can confirm that this has been fixed and we were able to upload our dSYMs. Thanks!
[09:51:41]: $ npx @datadog/datadog-ci dsyms upload /Users/runner/work/ios/redacted.app.dSYM.zip
[09:51:42]: ▸ npm WARN exec The following package was not found and will be installed<EMAIL_ADDRESS>[09:52:03]: ▸ Starting upload with concurrency 20.
[09:52:03]: ▸ Will look for dSYMs in /Users/runner/work/ios/redacted.app.dSYM.zip
[09:52:03]: ▸ Will use temporary intermediate directory: /var/folders/2p/6fxzqc0d64xbxvt_6n0252k40000gn/T/2995541548775187.5/datadog-ci/dsyms/intermediate
[09:52:03]: ▸ Will use temporary upload directory: /var/folders/2p/6fxzqc0d64xbxvt_6n0252k40000gn/T/2995541548775187.5/datadog-ci/dsyms/upload
...
...
...
[09:52:08]: ▸ Command summary:
[09:52:08]: ▸ ✅ Uploaded 1234560 dSYMs in 4.596 seconds.


Update feature flags to work on ALL routes

Currently feature flag gs only works on /collections/:id route, and doesn't work on homepage route /, because the collection page is the only page reading gs flag
We should update FE to detect feature flags on all routes, which means adding the related code in frontend/src/components/AppContainer/index.tsx
DoD:

Feature flags should be set on ALL routes, regardless of which page reads it. For example, homepage route /?gs=true should persist the feature flag in localStorage even though homepage doesn't use gs feature flag

There was a rationale to define separate feature flags for cc (Create Collection) and auth in the past. Moving forward, I would recommend that we merge released features to one feature flag such as curator=true.  (Or perhaps something slightly harder to guess) Features under development would still have an internal feature flag. When the feature is ready for release to curators, then the internal feature flag would be deprecated and replaced by curator.
For example:

?cc=true&auth=true -> ?curator=true
Gene sets in development -> ?curator=true&gs=true
Gene sets released to curators -> ?curator=true which now includes create collections, auth, gene sets
Revision in development -> ?curator=true&revision=true
Revision released to curators -> ?curator=true which now includes create collections, auth, gene sets, revise collections

@maniarathi and @tihuan - thoughts?

LGTM!

Thanks for the great idea @brianraymor ! Added that as a DoD item in the description 🔥

We may want to make the change once gene sets are ready for release. That way, we're sharing a new feature when we require the curators to make the change.


provider-azure-azure is an unwanted family member, which should not be published

What happened?
check the following Slack conversation: https://crossplane.slack.com/archives/CEG3T90A1/p1690827577071239
The provider-azure-azure is considered an unwanted family member and should not be made publicly available. We need to examine if it can be eliminated from previous releases and ensure that it is no longer published.
for other users, it is recommended to use "provider-family-azure"  instead of "provider-azure-azure."

How can we reproduce it?

$ kubectl get pkgrev
NAME                                                                            HEALTHY   REVISION   IMAGE                                                   STATE    DEP-FOUND   DEP-INSTALLED   AGE
[providerrevision.pkg.crossplane.io/provider-azure-azure-ad9309b97084](http://providerrevision.pkg.crossplane.io/provider-azure-azure-ad9309b97084)            False     1          [xpkg.upbound.io/upbound/provider-azure-azure:v0.34.0](http://xpkg.upbound.io/upbound/provider-azure-azure:v0.34.0)    Active   1           1               21m
[providerrevision.pkg.crossplane.io/upbound-provider-family-azure-27e36a76bbf6](http://providerrevision.pkg.crossplane.io/upbound-provider-family-azure-27e36a76bbf6)   True      1          [xpkg.upbound.io/upbound/provider-family-azure:v0.34.0](http://xpkg.upbound.io/upbound/provider-family-azure:v0.34.0)   Active                               21m
$

What environment did it happen in?

Crossplane Version:
Provider Version:
Kubernetes Version:
Kubernetes Distribution:

But available again in v0.36.0


Unexpected parse errors with analyzer in repo

I'm working on patterns support in dart format. So far I've been using the latest published analyzer version, 5.4.0. That's working fine.
I tried with the bleeding edge versions of analyzer and _fe_analyzer_shared directly from the Dart SDK repo today and I get a couple of parse errors:
  line 1, column 69 of .: The empty record literal is not supported as a constant pattern.
    ╷
  1 │ void foo() { if (obj case (longFieldName: const (first: 1, second: 2))) {;}
    │                                                                     ^
    ╵

  line 1, column 68 of .: The empty record literal is not supported as a constant pattern.
    ╷
  1 │ void foo() { if (obj case const (element, element, element, element)) {;}
    │                                                                    ^
    ╵

  line 1, column 72 of .: The empty record literal is not supported as a constant pattern.
    ╷
  1 │ void foo() { if (obj case Foo(longFieldName: const (first: 1, second: 2))) {;}
    │                                                                        ^
    ╵

As far as I can tell, the code is correct. I don't see any errors in these formatter tests when using analyzer 5.4.0.
cc @scheglov @bwilkerson @jensjoha

Update: I'm seeing these with analyzer 0.5.5 now too.

I believe these are coming from the parser, not from the analyzer itself.
Yes, I published analyzer 5.5.0 today, so the current state of the parser is what clients get now.

Should I reassign this to "area-front-end" then?

It is never quite clear to me, because _fe_analyzer_shared is neither, but probably yes.

I tested dart_style against the bleeding edge Dart SDK and this fixes the test failures I was seeing. Thanks!
Whenever a new analyzer version is published that contains this change, let me know and I'll update dart_style to use it.

analyzer 5.6.0 with the fix was published

Thanks!


Use v4 instead of v1 uuids

I'm a co-author of the uuid npm module which is being used in some places within the code base of this repository.
I'm currently trying to understand real-world use cases of time-based UUIDs ("v1 UUIDs").
I found several occurrences in the test suite where v1 UUIDs were being used instead of v4 UUIDs and I was wondering if any of these cases really require the semantically much more complex v1 UUIDs or whether we could live equally well with purely random v4 UUIDs? Please see my commit messages for more details.
I'd be really curious to understand the motivation for choosing v1 over v4 UUIDs in the first place, so any feedback on this would be highly appreciated!
@acesiddhu @ShreyasRmsft as far as I can tell from the git history it seems like you have introduced some usages of v1 UUIDs so I'd be particularly interested in your feedback.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: ctavan sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

There's like an infinitesimally small chance of collisions but that shouldn't matter here. This should be fine. Please do test out all the tasks once to ensure everything is working fine. Our E2E tests should also be doing this but i would have one manually pass if possible.
Thanks for taking time to contribute.

@ShreyasRmsft thanks for taking the time to review my patchset. I have reverted the change to the legacy test.

There's like an infinitesimally small chance of collisions but that shouldn't matter here. This should be fine.

I don't think that the changes really increase the chance of collisions. In fact collisions with v1 UUIDs as generated by the uuid npm module are also still possible although in practice similarly unlikely as with v4.

Please do test out all the tasks once to ensure everything is working fine. Our E2E tests should also be doing this but i would have one manually pass if possible.
Thanks for taking time to contribute.

To be honest I have not the slightest idea how to test this manually as I have never worked with Azure Pipelines (and I do not even have access to an Azure account at this moment).
I was hoping that the test suite would provide enough safety to ensure that my changes don't introduce any regressions.
Would there be any chance that one of the maintainers of this repo could run the updated code in their environments?
As I've stated in my report I'm an author of the uuid npm module and I'm mostly interested in understanding it's usage (and along the way trying to correct some places where I believe the module has not been used in the optimal way), I don't have a particular stake in getting an Azure Pipeline setup up and running for my own.

@ctavan no worries, I'll test these out and then complete the pull request.


Some spells crash servers, Evil Mages cast these spells randomly

Certain spells like Earth Launch(probably others) cause servers to crash. Evil Mages can use these spells randomly and can soft lock servers and hard lock single player games.
Please also provide a config file so if issues like this happen again Evil Mages' spell list and spawn rate (disable spawn mostly) can be altered by the user.
For anyone having this issue, the best way to currently solve it is to install Carpet mod on your server, use the /tick freeze command from your console (this stops all game activity entirely while letting you move around the world, place blocks, etc)
You can then login to use the command /kill @e[type=ace:evil_mage] command. I suggest setting this up in a command block with an observer clock to instakill mages until this bug is fixed. Which I hope is speedy and at least for 1.18.2.
 Maybe changing to peaceful in the files.

I thought I fixed all of those, but I was working on the fork RACE4ACE, not sure I ever built it however. If I get time, I will see what still needs to fix. please provide crashlogs.

also try 0.6 just released on modrinth

this issue appears to still be happening on 0.7.1


Copyedits 051217 - 52 cards

Fixed/added missing references
Added more visual design

headers and subheaders
moved sections for clarity (ortho topics)

Spelled out abbreviations
Typos fixes
Format fixes (bold, underline)
Fixed Pediatric Fever: 3 mo-2 yr card (wrong info about UA)

Will need help fixing Legionella card - not sure how to fix the table padding error

Codecov Report

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

@@           Coverage Diff           @@
##           master     #185   +/-   ##
=======================================
  Coverage   60.16%   60.16%
=======================================
  Files          16       16
  Lines         241      241
  Branches       50       50
=======================================
  Hits          145      145
  Misses         96       96

Continue to review full report at Codecov.

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


Sema: leak rather than corrupt memory

UnsafeMutableBufferPointer.allocate does not guarantee usage of malloc (and in fact guarantees the opposite due to alignment assumptions).  The memory allocated by that must be released by UnsafeMutableBufferPointer.deallocate only as that is guaranteed to correctly call the deallocation routine.  Leak memory rather than corrupting memory.

CC: @DougGregor @rintaro @bnbarham

This should be subsumed by https://github.com/apple/swift/pull/68271


Allow security policies per backend

This PR allows attach armor security policy to specific backend service of the loadbalancer, allows usage of different security policies on a single lb with multiple backends.

@vktr-brlv You need to build etc. It's all described in the contributing guide.

@morgante , it looks like tests don't work now in master. due to project-factory module doesn't support tf 0.13
Initializing modules...

Error: Unsupported Terraform Core version

  on .terraform/modules/project-ci-lb-http/terraform-google-project-factory-8.1.0/versions.tf line 18, in terraform:
  18:   required_version = "~> 0.12.6"

Module module.project-ci-lb-http (from
terraform-google-modules/project-factory/google) does not support Terraform
version 0.13.0. To proceed, either choose another supported Terraform version
or update this version constraint. Version constraints are normally set for
good reason, so updating the constraint may lead to other errors or unexpected
behavior.

@vktr-brlv Thanks for the contribution!