chroot

Hello,
I have a problem with both nsd and unbound and I need direction on how to solve it. I need to respect standards, namely write the variable data under /var while keeping the read-only data and executables under /usr, where /usr is read-only in my case. Chroot seems to force non compliance: it works if I put everything under /var and it fails otherwise. Did any of you manage to have a compliant chroot?
Thank you

[/usr] "is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere. Large software packages must not use a direct subdirectory under the /usr hierarchy."
(Filesystem Hierarchy Standard, ver. 2.3, FHSG 2004)
"/usr may be remote"
(ISO 23360-1, a.k.a. "Linux Standard Base")

Hi, You seem to ask a question directed at other users. They can respond here, but we have a users mailing list for NSD and for Unbound, where people can share their experiences, and this may be what you are looking for.
https://lists.nlnetlabs.nl/mailman/listinfo/nsd-users https://lists.nlnetlabs.nl/mailman/listinfo/unbound-users
Most chroots are made in /etc or /var, I thought. So, /var/lib/unbound would be a usual location for the chroot directory.

Hi, You seem to ask a question directed at other users. They can respond here, but we have a users mailing list for NSD and for Unbound, where people can share their experiences, and this may be what you are looking for.
https://lists.nlnetlabs.nl/mailman/listinfo/nsd-users https://lists.nlnetlabs.nl/mailman/listinfo/unbound-users
Most chroots are made in /etc or /var, I thought. So, /var/lib/unbound would be a usual location for the chroot directory.

No, I asked the question to the developers.

Could you tell more what you are trying to do? You want some readonly data in the /usr system but a chroot as well? And for certain files, like the pid file, you need to be able to write?
It is possible on many systems to mount a directory in a location, say /var, and then that becomes accessible inside the chroot. For certain /dev and /log places. I guess also a /usr readonly directory with like data files could be made accessible in that manner? Perhaps something like mount --bind -n /usr/share/zonedata /var/lib/someplace/zonedata (or on BSD with devfs(8))?

Could you tell more what you are trying to do?

I am trying to have an ISO 23360-1 conformant chroot, where the variable data is written under /var, and the read-only data and executables are written under /usr, where /usr is read-only and offsite.

So, what pieces of data are you trying to have where? NSD would need access from its chroot to these pieces of data, so during the chroot, they need to be inside that chroot directory. What are valid, compliant, chroot places?
NSD allows you do configure the directories and paths, so, I guess it would likely be possible. But what needs to be where?
So I suggested the bind mount solution, that allows you to put data in the place where you want it, and then also have it appear inside the chroot directory, so it can be accessed during the server runtime. This makes 'everything under chroot' happen from the bind remount calls, but meanwhile the actual files live in the places where you want them, so it would work and you can also place the files where you want them. Perhaps with the bind mount you can have the data in both the places they need to be.

@hdatma, I'm assuming @wcawijngaards's suggestions allowed you to get everything working. Closing this issue. Be sure to reopen or open a new issue if you need more help.


Adding labels to MarkerClustererPlus

For a standard Google Maps marker, I can create a label below the marker with the following code:
var marker = new google.maps.Marker({
    label: {
        text: '$2.15m',
        color: 'black',
    }
    ... other markers attributes
})

The result looks like this.
However, when the marker gets rolled up into a markercluster, the label disappears.
Is there some way to display a label for each markercluster, customizable depending on the content of the markerclusterer (the markers inside the markercluster)?

You might be able to do this by using a custom calculator. You could certainly use a custom calculator to display a custom tooltip ("title") that appears when the mouse moves over a cluster.

@garylittleRLP
What is a custom calculator?  Is that a feature built in MarkerClustererPlus or..?
I would like to show a label without having to hover over the markercluster.
I am already displaying information when the user hovers over the cluster. The idea is to provide price info without having to interact with the cluster at all.
And thank you for the quick reply.


[Ballista] Fill functional gaps between datafusion and ballista

Is your feature request related to a problem or challenge? Please describe what you are trying to do.
Current Ballista implementation is more like standalone system that  able to run the Datafusion operators in a distributed way.
But threr are some gaps between them.
Currently we need fix:

[ ] https://github.com/apache/arrow-datafusion/issues/2032
[ ] https://github.com/apache/arrow-datafusion/issues/1984
[x] https://github.com/apache/arrow-datafusion/issues/2007
[x] https://github.com/apache/arrow-datafusion/issues/1985
[ ] https://github.com/apache/arrow-datafusion/issues/2092

Welcome to add missing part 😊!
Describe the solution you'd like
Describe alternatives you've considered
Maybe we can find a solution to find functions that are missed in the ballista but implemented in the datafusion automatically.

I've updated the list above with a substr item.


Update index.md

Proposed changes

Unreleased project version (optional)

Related issues (optional)

Yep, thank you @scjane 👍


Direct installation not working

I followed the direct installation steps, but it seems that the nodes were not installed correctly.
(Win10).

Yup, I'm unable to find these nodes in the node menu as well. Would appreciate any help from those who've made it work.

Claude was so nice to help me out here, the python replicate module has to be installed first!
Open a command prompt or terminal.
Navigate to your ComfyUI directory. Based on your error message, it should be:
CopyD:\Code\ComfyUI_windows_portable\ComfyUI
Activate the Python environment that ComfyUI is using. If you're using the portable version, there should be a script to activate the environment. Look for something like python_embeded\python.exe or a similar activation script.
Once the environment is activated, install the 'replicate' module using pip:
Copypip install replicate
After the installation is complete, try running ComfyUI again.


PDF preview window doesn't update after clicking the Undo/Redo button

Description:
PDF preview window doesn't update after clicking the Undo/Redo button
Steps to Recreate:

Open LaTex Studio
Open a document to edit
Make changes to the document
Click the undo button

Expected Result:
The PDF preview window must be identical on the text displayed or written in the text editor window after clicking the Undo/Redo button
Actual Result:
The PDF preview window isn't identical on the text displayed or written in the text editor window after clicking the Undo/Redo button
Affected Environment:
Windows 7
Linux - Ubuntu 14.04.2
Screenshot:
Use welcome.tex to demonstrate the functionality of the undo button and make changes to the word "Welcome"

Delete the "come" in "Welcome"

After clicking the undo button, the word "Wel" changed into "Welcome" which is the working as expected. While in the pdf preview window the word "Wel" didn't change

Fixed, please pull from my repository
@LloydBG @sebbrudzinski

@sebbrudzinski @Labelpm
Would I be able to test this if there is no pull request for this issue?

@LloydBG This was a part of the pull request that has been merged in. It did fix the issue, but it was not a proper way to do so (basically sending preview refresh requests all the time). If Labelpm fixes this, it will be in a brand new pull request.

@sebbrudzinski This is fixed. Undo/Redo buttons are working as expected

Thanks for testing this @LloydBG I've reviewed the code and tested the change. It looked good to me, so the pull request is now merged. Thanks for fixing this issue @Labelpm


Switch CppCodeGen to use dependency analysis framework for method code

Represent C++ MethodCode using DependencyNode. Data structures are not switched yet.
Related to #68

@MichalStrehovsky Could you please take a look?

LGTM


[Enhence] Remove the low_cpu_mem_usage parameter on CPUs to reduce the VRAM usage.

Type of Change
Enhence & cleancode
Description

[Enhence] Remove the low_cpu_mem_usage parameter on CPUs to reduce the VRAM usage.
cleancode

Expected Behavior & Potential Risk
N/A
How has this PR been tested?
Extension tests.
Dependency Change?
N/A

https://inteltf-jenk.sh.intel.com/job/neural_speed_extension/110/


fix: fsync after write to avoid too many dirty pages

related issue: https://github.com/slatedb/slatedb/issues/192#issuecomment-2346036581

Apparently object cache is also leaking memory and got Killed by OS. With block cache only, the throughput is 100-150 op/s and it can run for long time without memory leaks.

I guess it might be because the page cache did not get flushed in time during writes, making the dirty page cache accumulated too much. let me fix it

this pr add a fsync after the files were written to disk. this may help reduce the dirty pages floating in the system during many writes.

@flaneur2020 want to close this? Sounds like the issue is elsewhere based on the discussion in #192

yeah, i'll close this pr, still need some deeper investigation.


A TLS server that doesn't exit correctly causes a scoped application to thrash cpu

When we send the output of a scoped application to a TLS server, if that TLS server closes and does not complete a proper disconnect/shutdown sequence, our scoped application will thrash cpu. Maybe due to the TLS client trying to disconnect/shutdown in a tight loop.

@seanvaleo could be related to #416

Duplicate of 416. Tracking progress on issue 416.

Although similar, this is a different issue to 416.
In 416, we observed hangs/failures due to ssh closing our file descriptors.
This issue relates to our TLS shutdown implementation getting stuck in a tight loop, under the condition that the server closed the connection prematurely. I was able to observe this by modifying our tcpserver to exit without notifying the client that it was shutting down. The code in scope would return a -1 from ssl_read and we would loop indefinitely.
PR https://github.com/criblio/appscope/pull/428 fixes this by improving our shutdown procedure.


NoIndex meta data tag not working

Describe the bug
I am part of LinkedIn's Partner Engineering team.
I have added NoIndex metadata tag as shown below, to the top of the MS Docs markdown page.

title: abc
description: abc
ms.date: 11/20/2019
ms.topic: abc
ms.prod: abc
author: xyz
ROBOTS: NOINDEX
But even after adding this tag  "ROBOTS: NOINDEX"
The page is searchable. Is this the correct way to search ?

Couple of things to consider:

What search are you referring to? Google, Bing, Docs search, another site like Linked In search? each is plumbed differently.

Search indexes are not real time. The search reindex may crawl once a month or daily, depends on the algorithm and the popularity of the page. Could it be that the old indexed value is still there, but in the next crawl it will be removed.

If you have specific page and need to know more about the crawl information, there is an SEO champs team. CC: @Khairunj
Thanks, Jason

@aditya-hub see my last message here. Do you have additional context on the problem?


curlFull,curlHTTP3: unable to make HTTP3 requests, "installed libcurl version doesn't support this"

Describe the bug
HTTP3 support in curl appears to have regressed, and it is not possible to make HTTP3 requests on a standard curlFull or curlHTTP3 installation. It fails with:
curl -vk --http3 https://<IP_ADDRESS>:4433
curl: option --http3: the installed libcurl version doesn't support this
curl: try 'curl --help' for more information

Steps To Reproduce
Steps to reproduce the behavior:

Install curlFull or curlHTTP3
Run curl --http3 https://some.http3.site/ (in my case, it was curl -vk --http3 https://localhost:4433/)
Observe failure

Expected behavior
An HTTP3 request should be dispatched to the intended target.
Screenshots
All content that would be in screenshots was posted directly.
Additional context
I tried installing nghttp3 and ngtcp2 manually alongside curlFull and curlHTTP3, to no avail.
Notify maintainers
@lovek323
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.9.5, NixOS, 24.11 (Vicuna), 24.11pre641786.d603719ec6e2`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.2`
 - channels(root): `"home-manager, nixos"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Add a :+1: reaction to issues you find important.

Seems to be working fine for me, on d603719ec6e294f034936c0d0dc06f689d91b6c3:
flake on  staging [$!?⇕]
❯ nix build github:NixOS/nixpkgs/d603719ec6e294f034936c0d0dc06f689d91b6c3#curlHTTP3

flake on  staging [$!?⇕] took 27s
❯ result-bin/bin/curl --http3-only https://ny4.dev/
<!DOCTYPE html><html lang="en"><head>...

If I use nix-shell it works today (didn't work before) but having it be installed through my nixos config (which is using home-manager) doesn't work... odd (and no, I don't have another explicit curl installation)


Feat/dtfs2 7093/update readme

Introduction :pencil2:
remove changes to circumvent code duplication issue on 7093

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

Project coverage is 32.05%.  Consider uploading reports for the commit fe883a6 to get more accurate results

Additional details and impacted files
@@             Coverage Diff              @@
##           release-1.5    #3006   +/-   ##
============================================
  Coverage        32.05%   32.05%
============================================
  Files             1334     1334
  Lines            30631    30631
  Branches          4947     4947
============================================
  Hits              9820     9820
  Misses           18157    18157
  Partials          2654     2654

Flag
Coverage Δ

api-test
0.39% <0.00%> (ø)

unit-test
32.31% <0.00%> (ø)

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

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


mfu: always read full size blocks with O_DIRECT

When using O_DIRECT, different file systems have different requirements.  In general, one has to use aligned offsets within the file, aligned buffers in memory, and read/write counts that consist of an integral number of blocks.
The read count must always be an integral number of full blocks, even in the case where one knows that the file does not have that much data.  In this case, the read will simply return a short read.
Similarly when writing data, one may have to write past the end of a file by using a write count that exceeds the desired end of the file.  In that case, one must then truncate the file after it has been written.
To complicate matters further, one may be reading from a file system that requires one alignment block size but writing to a different file system that has a different block alignment.  Perhaps that could be solved by computing the minimum common multiple of the two block sizes?  That remains future work.
Signed-off-by: Adam Moody<EMAIL_ADDRESS>

I can try it,  but what about the EINTR case? Shouldn't we restart the read/write syscall in this case?

If the read hits an EINTR and then returns -1, the function should retry the read.
However, there is another case that I think is what you're asking about, where we end up with a short read because the read is interrupted but the return value from the read call is greater than 0 because it read some bytes but not everything.  In this case, we'd currently return the read as short.  In the case of O_DIRECT, the subsequent write would then not work as desired.
Is that what you are thinking?

However, there is another case that I think is what you're asking about, where we end up with a short read because the read is interrupted but the return value from the read call is greater than 0 because it read some bytes but not everything
Is that what you are thinking?

Yes, but my message above was a bit misleading, apologies.
If the process is interrupted by a signal, you will indeed get a short read/write, but not EINTR (that's only when no I/O was performed, and the return value is indeed -1).
This is tricky to detect/recover for the direct I/O case though, especially if you're unlucky enough that it happens on the last block and you end up with a short read/write smaller than the buffer size.
For instance, would this case be handled properly by the current logic?

Block size is 4096 bytes.
Last block is size 2000, but we need to do a write(2) of size 4096.
A signal interrupts the write(2) calls and it returns "1000" instead of "2000".

However, there is another case that I think is what you're asking about, where we end up with a short read because the read is interrupted but the return value from the read call is greater than 0 because it read some bytes but not everything
Is that what you are thinking?

Yes, but my message above was a bit misleading, apologies.
If the process is interrupted by a signal, you will indeed get a short read/write, but not EINTR (that's only when no I/O was performed, and the return value is indeed -1).
This is tricky to detect/recover for the direct I/O case though, especially if you're unlucky enough that it happens on the last block and you end up with a short read/write smaller than the buffer size.
For instance, would this case be handled properly by the current logic?
* Block size is 4096 bytes.

* Last block is size 2000, but we need to do a write(2) of size 4096.

* A signal interrupts the write(2) calls and it returns "1000" instead of "2000".

Yes, you're correct in that both the read and write paths need to be updated to account for short read/write operations with O_DIRECT.
Another problem that shows up in the current code is that the file pointer will have been moved.  We need to be sure to perform O_DIRECT read/write operations using aligned file offsets in addition to the aligned buffer and counts with full block sizes.  That means the pointer has to be lseek'd backwards before we retry the operation or perhaps we should track offsets manually and switch from read/write to use pread/pwrite instead.
Thanks for your careful review on this.

Sure, I will test this PR soon anyway, since this situation is quite low probability.

Close, but no cigar:
[pid 107454] read(16, "\264\245IU#\17\306\322j\256\205\320\216\391\235\222)\344U\215\2667\269\\\216\276\325Qb"..., 1048576) = 494700
[pid 107454] write(17, "\264\245IU#\17\306\322j\256\205\320\216\391\235\222)\344U\215\2667\269\\\216\276\325Qb"..., 1048576) = 1048576
[pid 107454] read(16, 0x55a75d100000, 1048576) = -1 EINVAL (Invalid argument)
[pid 107454] read(16, 0x55a75d100000, 1048576) = -1 EINVAL (Invalid argument)
[pid 107454] read(16, 0x55a75d100000, 1048576) = -1 EINVAL (Invalid argument)
[pid 107454] read(16, 0x55a75d100000, 1048576) = -1 EINVAL (Invalid argument)
[pid 107454] read(16, 0x55a75d100000, 1048576) = -1 EINVAL (Invalid argument)
[pid 107454] write(2, "ABORT: rank X on HOST: ", 23ABORT: rank X on HOST: ) = 23

Here we have total_bytes == length so it does one more iteration of the loop:
https://github.com/hpc/mpifileutils/blob/57a3578b68d8df0fa53a7662c33c6c21ce72400f/src/common/mfu_flist_copy.c#L1587
And then it tries one last read before exiting the loop:
https://github.com/hpc/mpifileutils/blob/57a3578b68d8df0fa53a7662c33c6c21ce72400f/src/common/mfu_flist_copy.c#L1596-L1601
But the read returns EINVAL, probably because the file pointer is now unaligned as you mentioned above. Or it's just a normal behavior when past EOF with direct I/O, not sure.

Ok thanks.  Yes, we're converging on a solution.  Checking the code, it should be safe to change the while loop condition from total_bytes <= (size_t)length to total_bytes < (size_t)length.  That would avoid that last read attempt at the end of the file.

@flx42 , just curious whether making that <= to < change in the while loop condition resolves the most recent issue with the final read using an unaligned file offset.
We'll to stamp a 0.10.1 bug fix release of mpiFileUtils next week.  I'll roll all of these fixes into that.  This should help address some common cases.
For a more complete fix, we need to rewrite this portion to ensure we're always using aligned offsets, memory buffers, and proper read/write counts, including when recovering from error situations.  That means rolling back file pointers with lseek or tracking them directly and switching to use pread/pwrite.  I think we need to also account for potential differences in alignment requirements between source and destination file systems.  For example, the O_DIRECT block size might be different between the source and destination, meaning we need a way to identify those values for each system and then compute a least common multiple.  That will require some more careful consideration, so we'll push this additional work to the next major release in v0.11.

Yes, when I tried changing the loop condition (a few days ago), it seemed to work fine.
But then it's a bit weird to still have the break in the loop, no?

Ok, good to know.  I'll go ahead and merge this in since we know it helps.
I'll keep the break statement in here for now and consider it again on the rewrite for v0.11.  I think the break is still useful so that we exit the loop in the case a file has been shortened after we got its size with stat() but before it the copy completes.

@flx42 , thanks for your help in testing this along the way!

@adammoody sure, glad to help.
Do you have an estimate for the release of v0.11 by the way?

@adammoody sure, glad to help.
Do you have an estimate for the release of v0.11 by the way?

Hoping to target a v0.11 release in 3 months on the short end, but I can imagine that might get stretched to 6 months.


Got NFT creator functional.

:tada: This PR is included in version 1.1.1 :tada:
Your semantic-release bot :package::rocket:


L530 Light Second handshake failed

Describe The Bug
2 out of 6 Tapo L530 lights not adding to Hobbs
Expected behavior
Lights to be configured and working once IP is added
Logs
log.txt
Plugin Config
{
"platform": "HomebridgeTPLinkTapo",
"name": "",
"email": ",
"password": "",
"addresses": [
"<IP_ADDRESS>",
"<IP_ADDRESS>",
"<IP_ADDRESS>"
]
}
Plugin Version
4.1.0
Homebridge Version
4.3.0 HOOBS
Node.js Version
16.20.2
NPM Version
Unknown
Operating System
Hoobs

Removed from Tapo App, then re-added. Seemed to solve the problem.


Is there a way to use Ruff version from PATH?

Hi,
currently we setup our pre-commit specifying a revision for Ruff.
repos:
- repo: https://github.com/astral-sh/ruff-pre-commit
  # Ruff version.
  rev: v0.8.0
  hooks:
    # Run the linter.
    - id: ruff
    # Run the formatter.
    - id: ruff-format

This installs Ruff with version 0.8.0 and works very well. However, every time we upgrade our dependencies, we have to maintain different places where the Ruff version is defined.
We would like for pre-commit to use Ruff as-is found via PATH (either installed via Shell, or if installed in an isolated venv like with uv tool install).

As I understand it, the main reason for using Ruff's pre-commit plugin is that it installs the specific Ruff version for you.
I'm not a pre-commit user myself, but could you try using the system plugin to run an arbitrary command, in this case, ruff?


No code completion for type names for try/on when there's already at least one "on" clause

When using try/on there's code completion for type names:

However when writing a second on, there's no completion:

In the bad case, on appears to be a SimpleIdentifier in the AST, whereas it's not in the good case.
Good:
┊   ┊   ┊   ┊   ┊   TryStatementImpl [95..107]
┊   ┊   ┊   ┊   ┊   ┊   BlockImpl [99..102]
┊   ┊   ┊   ┊   ┊   ┊   CatchClauseImpl [104..107]
┊   ┊   ┊   ┊   ┊   ┊   ┊   NamedTypeImpl [108..107] (synthetic)
┊   ┊   ┊   ┊   ┊   ┊   ┊   ┊        name =
┊   ┊   ┊   ┊   ┊   ┊   ┊   ┊        type = dynamic
┊   ┊   ┊   ┊   ┊   ┊   ┊   ┊   SimpleIdentifierImpl [108..107] (synthetic)
┊   ┊   ┊   ┊   ┊   ┊   ┊   ┊   ┊        name =
┊   ┊   ┊   ┊   ┊   ┊   ┊   BlockImpl [108..107]

Base:
┊   ┊   ┊   ┊   ┊   TryStatementImpl [95..139]
┊   ┊   ┊   ┊   ┊   ┊   BlockImpl [99..102]
┊   ┊   ┊   ┊   ┊   ┊   CatchClauseImpl [104..139]
┊   ┊   ┊   ┊   ┊   ┊   ┊   NamedTypeImpl [107..119]
┊   ┊   ┊   ┊   ┊   ┊   ┊   ┊        name = ArgumentError
┊   ┊   ┊   ┊   ┊   ┊   ┊   ┊        type = ArgumentError
┊   ┊   ┊   ┊   ┊   ┊   ┊   ┊   SimpleIdentifierImpl [107..119]
┊   ┊   ┊   ┊   ┊   ┊   ┊   ┊   ┊        name = ArgumentError
┊   ┊   ┊   ┊   ┊   ┊   ┊   ┊   ┊        static element = class ArgumentError extends Error
┊   ┊   ┊   ┊   ┊   ┊   ┊   CatchClauseParameterImpl [128..132]
┊   ┊   ┊   ┊   ┊   ┊   ┊   BlockImpl [135..139]
┊   ┊   ┊   ┊   ┊   ExpressionStatementImpl [141..144]
┊   ┊   ┊   ┊   ┊   ┊   SimpleIdentifierImpl [141..142]
┊   ┊   ┊   ┊   ┊   ┊   ┊        name = on
┊   ┊   ┊   ┊   ┊   ┊   ┊        static type = dynamic

Wow great catch.

@DanTup, can you still reproduce this at bleeding edge. I was not able to. See completions on not just the second on clause, but on subsequent on clauses too.

I can't repro on bleeding edge (or even Dart 3.3.0) today. I'm not sure why, but in my screenshot the word "on" being white also seems odd to me (suggests we didn't get any semantic token for it). Today, I get a dead code warning and not the red error I had in the screenshot above:

I'm not sure why this is (or what version of the SDK I was using when I took the screenshot above), but I suggest we close this until we see it happen again (at which point I should include a copy/pastable repro and the Dart version!).


chore(master): release 1.15.2

:robot: I have created a release beep boop
1.15.2 (2023-08-31)
Styling

工作台样式 (dd19348)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/KYX1234/Element-Admin/releases/tag/v1.15.2 :sunflower:


Fixed bug in ZipAESStream.ReadBufferedData.

copyCount was being computed but not passed to Array.Copy(), which caused an
exception to be thrown when enough bytes were read from an encrypted stream.
I certify that I own, and have sufficient rights to contribute, all source code and related material intended to be compiled or integrated with the source code for the SharpZipLib open source product (the "Contribution"). My Contribution is licensed under the MIT License.

My bad, I made some changes in that area to fix some issues with buffer sizes and apparently both missed that case and left a hole in the unit tests :-(
I've pushed a unit test change that reproes the issue as #466.


Migrate pylintrc to pyproject.toml

The configuration settings in pylintrc should be moved into pyproject.toml in order to adopt a consistent approach and also reduce the number of configuration files at the top level

Addressing this in 9290ccb1ea86f9536af9c47bf137fe29a6bf94f8 for !79

Closed due to #79


Add groups+groups users meta details

Solves some parts of #4883, in particular:
Organisation owner can:

[x] see datasets/maps count for each group
[x] see count/avatar previews of group members
[x] see datasets/maps count for each group user

@xavijam pretty please review?
cc @juanignaciosl

bump! :)

:+1:

:es:


[WIP] Prevent impossiblities

what is this?

@ConorOBrien-Foxx Oh hi. You know me from PPCG.
You see, according to the quote in five.js and several other sources from within this project,

The Law of Fives states simply that: All things happen in fives, or are divisible by or are multiples of five, or are somehow directly or indirectly appropriate to 5. The Law of Fives is never wrong.

But the code used a string. And the number three! What is this madness? The number three and strings don't exist!

@CrazyPython I like this one. You need to resolve conflicts though :D


Extend Config type

At the moment, Pylance, when in strict mode, report an error when trying to use app config.
The return type of app.config["KEY"] is Unknown
First time contribution to an open source project, i want to try and see if i can tell Flask to take into account changes made to App.config_class for type hints
Python 3.12

That's because config is a dict-like interface with arbitrary keys and values, so any one key is not known. You can probably write a class that uses attribute access or a TypedDict instead to specify the types of known keys, but that only covers the keys you know about, not the extra ones that extensions or applications may use, which is presumably the interesting ones. But subclassing Config to provide other type information shouldn't require anything from Flask itself. You're welcome to explore this, and if you discover that something in Flask is needed, then please open a specific issue about that.


I create "test_place.py"

I create "test_place.py" to add "place" module!
Short description of what this resolves:
Changes proposed in this pull request:

Fixes: #

Thank you for taking the time to contribute! This is sincerely appreciated. 😇
(Powered by GitMate.io)


Could you support documentation on how to use this project with

https://reactql.org/docs/
I tried from your example but it I got hung up on scalars and the different way you defined your schema, were using graphql.js and it's not to easy trying to shoe-horn your library in.

Please describe your question precisely.

I think it's a lot easier than it may seem; going off https://github.com/jaydenseric/apollo-upload-server/issues/42. Just import the GraphQLUpload scalar and use it, like any other scalar?
Happy to review a PR to explain this in the "Upload scalar" readme section, as use of graphql-tools is currently assumed. This project is named "apollo-upload-server" afterall 😛
To make this package more generic I have been considering dropping apollo from the name. Currently the middleware should work for both Apollo and the reference GraphQL server, although I have only ever used Apollo server.


Rft: Adapt the change of Server Registry Trait

assign @onewe

assign @onewe

I will complete this work as soon as possible during this week

Good work!


Dynamically creating properties

Coverage increased (+2.81%) to 100.0% when pulling 594dc8e89938e5f8463ece0f7a0058a3d015dcf5 on dynamic-props into fb2a6b73f604f67ba5607339eff0ce1378a459fd on master.

Coverage increased (+0.62%) to 97.81% when pulling 620efda9b1f3279373bacb4e242943a083df0685 on dynamic-props into fb2a6b73f604f67ba5607339eff0ce1378a459fd on master.

Coverage increased (+2.81%) to 100.0% when pulling 0e7e0230091261b7d5784a7fad2363aaeed5cf02 on dynamic-props into fb2a6b73f604f67ba5607339eff0ce1378a459fd on master.


Integration with helm-secrets

I would be interested in getting helmfile integrated with the helm-secrets project.  From looking at it, it might be possible to just change the helm binary that is called to the helm-secrets wrapper with a command line flag.
https://github.com/futuresimple/helm-secrets
How are others handling secrets?

What a conincidence!
As I have already adapted to helm-secrets for secret management, I'm definitely interested in having an integration for that, too.
I'd like to have a more general or user-friendly way than adhocly implementing an unintuitive flag like --helm-binary-path=/path/to/helm-secrets-command to helmfile. I just don't feel that it is the right way.
Thoughts?

@sstarcher Hi, I have been thinking about this for several days.
Overall, which types of secrets are you willing to manage in your project's Git repository?
For me, it wans't only values.yaml but also kubeconfig containing keys and envvars used in our CI builds. So, I started working on a more universal version of helm-secrets command so that I don't need to use separate tools for various secrets. PTAL if it helps your use-case, too.

I'm interested primarily in values files.  We require separate user authentication so we stear away from a shared kubeconfig and CI holds it's environment variables instead of being in github.
I was thinking a possible integration would be
  - name: grafana
    namespace: default
    chart: stable/grafana
    version: 0.8.1
    values:
      - helm/grafana/values.yaml
    secrets:
      - helm/grafana/secrets.yaml

@sstarcher Looks elegant and easy to implement while not introducing a tight-coupling to helm-secrets(it won't be called if you opted not to specify secrets:). Awesome 👍

@sstarcher Do you have any bandwidth to send a PR for it?

@mumoshu I could probably tackle it next week.


Submit talk proposal to ETHDenver 2025

What is it?
Applications are open now

Mine is here
https://docs.google.com/document/d/1mAXEsetITdxUjl4JgQvF0wWjSgqlEzlvtdAqYu7TadE/edit?tab=t.0


[RHCLOUD-17965] Refactor delete returning

This PR replaces the Delete methods from the DAOs so that they use SQL's RETURNING statement. That way we can spare the "does this resource exist?" query to the database.
Note: requires https://github.com/RedHatInsights/sources-api-go/pull/167 to be merged first.
Links
[RHCLOUD-17965]

I have been trying to use the "RETURNING" clause with Gorm, as specified in https://gorm.io/docs/delete.html#Returning-Data-From-Deleted-Rows, but it doesn't seem to work for me. I've tried specifying the individual columns just for the sake of testing, but it doesn't work either.
Also, as a test, I've tried using Raw and Exec statements along with Scan, to try to do it "manually" but then let Gorm do the mapping. With Raw it both doesn't get mapped and we don't get the RowsAffected metadata, although the query gets successfuly executed.
With Exec you can't run Scan since it seems to do a new SELECT query to get the just deleted resource —Gorm seems to interpret the Exec and Scan as two separate queries—, and it breaks if you just try to append the .Scan() code to the previous Exec() query.
I would vote for ruling out this refactor entirely since the only other way I see we could do this is by doing a Raw(), grabbing the rows somehow —which I haven't been able to neither— and mapping the resources manually, but it seems a lot of effort for very little gain.
What are you thoughts, @RedHatInsights/sources?

Rebased!


Can we set default facet selected ?

Description
I am trying to select a facet whenever a user comes with a query-based URL. For e.g: <--website url-->/programs/?program=Course. Currently, I am using ais configure with facetFilter and disjunctive-facets-refinements.camel to prefilter the catalog.
Expected Behavior
The expected behavior should be just the facet should be selected and the result should be filtered. It should work like when we visit the main catalog and select a filter manually.
Actual Behavior
What I am seeing is the catalog is filtering and the facet is getting selected but when I unselect the facet it does not go back to the default catalog. I tried removing the facet filter prop but now the disjunctive one works but it triggers once I start scrolling down(I have ais infinite scroll).

@KetanPansari Could you put together a minimal example in codesandbox that replicates the issue? I can then help debug from there.

i try to do the same thing, i want on a specific url to get a pre filtered facet by brand
http://local/brand=xxx
i don't have the facet selected, and don't have it in the current refinements list
how to do this ?

@ibasaw Here's a guide on how to manage URL routing with instantsearch.

yes i had founded it earlier :)


update to latest fds_template.xls

https://www2.gov.bc.ca/gov/content/environment/plants-animals-ecosystems/fish/fish-and-fish-habitat-data-information/fish-data-submission/submit-fish-data
FDS_Template2023-05-03.xls

Can import old and new with fpr_import_hab_con and compare column names  to see if order or clean_names changed. (Order may not matter actually)

newer template now populated in data/templates/FDS_Template2023-05-03.xls


Update zio, zio-stacktracer, zio-test, ... to 2.0.17

About this PR
📦 Updates

dev.zio:zio
dev.zio:zio-stacktracer
dev.zio:zio-test
dev.zio:zio-test-sbt

from 2.0.0 to 2.0.17
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

🔍 Files still referring to the old version number
The following files still refer to the old version number (2.0.0).
You might want to review and update them manually.
build.sbt

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "dev.zio" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "dev.zio" }
}]

labels: library-update, early-semver-patch, semver-spec-patch, old-version-remains, commit-count:1

Superseded by #260.


CUDA_VISIBLE_DEVICES=1执行vllm推理，显卡推理却是GPU0，lamafactory-cli train和lamafactory-cli chat都正常

Reminder

[X] I have read the README and searched the existing issues.

System Info
CUDA_VISIBLE_DEVICES=1 API_PORT=8000 llamafactory-cli api     --model_name_or_path /hdd/pingchuan/Qwen2.5-7B-Instruct     --adapter_name_or_path /hdd/pingchuan/lora/sft     --template qwen     --finetuning_type lora     --infer_backend vllm
我使用这个脚本进行vllm GPU1推理，显卡推理却使用GPU0推理
[rank0]: torch.OutOfMemoryError: CUDA out of memory. Tried to allocate 1.97 GiB. GPU 0 has a total capacity of 79.25 GiB of which 334.06 MiB is free. Process 627536 has 0 bytes memory in use. Process 627564 has 0 bytes memory in use. Process 308335 has 41.09 GiB memory in use. Including non-PyTorch memory, this process has 32.68 GiB memory in use. Of the allocated memory 32.16 GiB is allocated by PyTorch, and 24.73 MiB is reserved by PyTorch but unallocated. If reserved but unallocated memory is large try setting PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True to avoid fragmentation.  See documentation for Memory Management  (https://pytorch.org/docs/stable/notes/cuda.html#environment-variables)
vllm version：0.6.2
llamafactory是最新版本
Reproduction
CUDA_VISIBLE_DEVICES=1 API_PORT=8000 llamafactory-cli api     --model_name_or_path /hdd/pingchuan/Qwen2.5-7B-Instruct     --adapter_name_or_path /hdd/pingchuan/lora/sft     --template qwen     --finetuning_type lora     --infer_backend vllm
我使用这个脚本进行vllm GPU1推理，显卡推理却使用GPU0推理
[rank0]: torch.OutOfMemoryError: CUDA out of memory. Tried to allocate 1.97 GiB. GPU 0 has a total capacity of 79.25 GiB of which 334.06 MiB is free. Process 627536 has 0 bytes memory in use. Process 627564 has 0 bytes memory in use. Process 308335 has 41.09 GiB memory in use. Including non-PyTorch memory, this process has 32.68 GiB memory in use. Of the allocated memory 32.16 GiB is allocated by PyTorch, and 24.73 MiB is reserved by PyTorch but unallocated. If reserved but unallocated memory is large try setting PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True to avoid fragmentation.  See documentation for Memory Management  (https://pytorch.org/docs/stable/notes/cuda.html#environment-variables)
vllm version：0.6.2
llamafactory是最新版本
Expected behavior
No response
Others
No response

请问解决了吗？

请问解决了吗？
解决了，其实用的就是GPU1，显示GPU0


Sorbet does not statically check return types of lambda / proc arguments

Input
→ View on sorbet.run
# typed: true
T.let(-> {0}, T.proc.returns(String))

Observed output
No errors! Great job.

Expected behavior

The return lambda returns an Integer, but the type annotation declares that it should return a String, so Sorbet should report a type error statically.

I'm fine calling this bug closed after only solving the return type problem.
But note that checking argument types is trickier still:
→ View on sorbet.run
# typed: true
T.let(-> (x) {T.reveal_type(x)}, T.proc.params(x: Integer).void)

Observed output
editor.rb:2: Revealed type: T.untyped https://srb.help/7014
     2 |T.let(-> (x) {T.reveal_type(x)}, T.proc.params(x: Integer).void)
                      ^^^^^^^^^^^^^^^^
  Got T.untyped originating from:
    editor.rb:2:
     2 |T.let(-> (x) {T.reveal_type(x)}, T.proc.params(x: Integer).void)
                  ^
Errors: 1

In the CFG, Sorbet infers a type for the whole proc before it sees the Cast instruction which it could seemingly use to annotate the argument types when checking the body of the lambda.
Since it comes after, it picks T.untyped for the argument types when inferring a type for the the lambda.

This is the same issue as #4149. That one has more test cases, this one has better context.

Fixed in https://github.com/sorbet/sorbet/pull/8011 and https://github.com/sorbet/sorbet/pull/8023


ERROR: Unrecognized option: --python_path

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): No
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Mac OS X 10.12.6
TensorFlow installed from (source or binary): source
TensorFlow version (use command below): commit e5e03ef3148303b3dfed89a1492dedf92b45be25 (HEAD -> master, origin/master, origin/HEAD)
Python version:  Python 2.7.13
Bazel version (if compiling from source): 0.10.1
GCC/Compiler version (if compiling from source):  4.2.1
CUDA/cuDNN version:
GPU model and memory:
Exact command to reproduce: see log

Describe the problem
TF failed to build from source.
When building from source, Bazel does not recognize --python_path set during ./configure
Please see the log below.
Source code / logs
C02PK120FVH6:tensorflow neitan01$ ./configure
WARNING: current bazel installation is not a release version.
Make sure you are running at least bazel 0.5.4
Please specify the location of python. [Default is /usr/local/opt/python/bin/python2.7]:
Found possible Python library paths:
/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages
Please input the desired Python library path to use.  Default is [/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages]
Do you wish to build TensorFlow with Google Cloud Platform support? [Y/n]: y
Google Cloud Platform support will be enabled for TensorFlow.
Do you wish to build TensorFlow with Hadoop File System support? [Y/n]: n
No Hadoop File System support will be enabled for TensorFlow.
Do you wish to build TensorFlow with Amazon S3 File System support? [Y/n]: n
No Amazon S3 File System support will be enabled for TensorFlow.
Do you wish to build TensorFlow with Apache Kafka Platform support? [y/N]: n
No Apache Kafka Platform support will be enabled for TensorFlow.
Do you wish to build TensorFlow with XLA JIT support? [y/N]: y
XLA JIT support will be enabled for TensorFlow.
Do you wish to build TensorFlow with GDR support? [y/N]: y
GDR support will be enabled for TensorFlow.
Do you wish to build TensorFlow with VERBS support? [y/N]: y
VERBS support will be enabled for TensorFlow.
Do you wish to build TensorFlow with OpenCL SYCL support? [y/N]: n
No OpenCL SYCL support will be enabled for TensorFlow.
Do you wish to build TensorFlow with CUDA support? [y/N]: n
No CUDA support will be enabled for TensorFlow.
Do you wish to build TensorFlow with MPI support? [y/N]: n
No MPI support will be enabled for TensorFlow.
Please specify optimization flags to use during compilation when bazel option "--config=opt" is specified [Default is -march=native]:
Would you like to interactively configure ./WORKSPACE for Android builds? [y/N]: n
Not configuring the WORKSPACE for Android builds.
Preconfigured Bazel build configs. You can use any of the below by adding "--config=<>" to your build command. See tools/bazel.rc for more details.
--config=mkl         	# Build with MKL support.
--config=monolithic  	# Config for mostly static monolithic build.
Configuration finished
C02PK120FVH6:tensorflow neitan01$ bazel build -c opt --copt=-mavx --copt=-mavx2 --copt=-mfma --copt=-msse4.1 --copt=-msse4.2 -k //tensorflow/tools/pip_package:build_pip_package
Killed non-responsive server process (pid=1017)
.
INFO: Options provided by the client:
Inherited 'common' options: --isatty=1 --terminal_columns=181
INFO: Reading options for 'build' from /Users/neitan01/src/tensorflow/tools/bazel.rc:
'build' options: --define framework_shared_object=true --define=use_fast_cpp_protos=true --define=allow_oversize_protos=true --define=grpc_no_ares=true --spawn_strategy=standalone --genrule_strategy=standalone -c opt
INFO: Reading options for 'build' from /Users/neitan01/src/tensorflow/.tf_configure.bazelrc:
'build' options: --action_env PYTHON_BIN_PATH=/usr/local/opt/python/bin/python2.7 --action_env PYTHON_LIB_PATH=/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages --force_python=py2 --host_force_python=py2 --python_path=/usr/local/opt/python/bin/python2.7 --define with_gcp_support=true --define with_xla_support=true --define with_gdr_support=true --define with_verbs_support=true --action_env TF_NEED_OPENCL_SYCL=0 --action_env TF_NEED_CUDA=0 --define grpc_no_ares=true --copt=-DGEMMLOWP_ALLOW_SLOW_SCALAR_FALLBACK --host_copt=-DGEMMLOWP_ALLOW_SLOW_SCALAR_FALLBACK
ERROR: Unrecognized option: --python_path=/usr/local/opt/python/bin/python2.7
C02PK120FVH6:tensorflow neitan01$ bazel build --config=opt //tensorflow/tools/pip_package:build_pip_package
INFO: Options provided by the client:
Inherited 'common' options: --isatty=1 --terminal_columns=181
INFO: Reading options for 'build' from /Users/neitan01/src/tensorflow/tools/bazel.rc:
'build' options: --define framework_shared_object=true --define=use_fast_cpp_protos=true --define=allow_oversize_protos=true --define=grpc_no_ares=true --spawn_strategy=standalone --genrule_strategy=standalone -c opt
INFO: Reading options for 'build' from /Users/neitan01/src/tensorflow/.tf_configure.bazelrc:
'build' options: --action_env PYTHON_BIN_PATH=/usr/local/opt/python/bin/python2.7 --action_env PYTHON_LIB_PATH=/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages --force_python=py2 --host_force_python=py2 --python_path=/usr/local/opt/python/bin/python2.7 --define with_gcp_support=true --define with_xla_support=true --define with_gdr_support=true --define with_verbs_support=true --action_env TF_NEED_OPENCL_SYCL=0 --action_env TF_NEED_CUDA=0 --define grpc_no_ares=true --copt=-DGEMMLOWP_ALLOW_SLOW_SCALAR_FALLBACK --host_copt=-DGEMMLOWP_ALLOW_SLOW_SCALAR_FALLBACK
ERROR: Unrecognized option: --python_path=/usr/local/opt/python/bin/python2.7
C02PK120FVH6:tensorflow neitan01$ bazel version
Build target: bazel-out/local-fastbuild/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Thu Jan 01 00:00:00 1970 (0)
Build timestamp: Thu Jan 01 00:00:00 1970 (0)
Build timestamp as int: 0
C02PK120FVH6:tensorflow neitan01$ brew info bazel
bazel: stable 0.10.1 (bottled)
Google's own build tool
https://bazel.build/
/usr/local/Cellar/bazel/0.5.1 (10 files, 138.0MB)
Poured from bottle on 2017-06-16 at 16:45:38
/usr/local/Cellar/bazel/0.10.1 (12 files, 93.4MB) *
Poured from bottle on 2018-02-15 at 23:19:51
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/bazel.rb
==> Requirements
Required: java = 1.8 ✔, macOS >= 10.10 ✔
==> Caveats
Bash completion has been installed to:
/usr/local/etc/bash_completion.d
zsh completions have been installed to:
/usr/local/share/zsh/site-functions

My build-environment was setup incorrectly. The bazel command was taken from an old-version of binary in the user space.


prod/staging CLI confusion

Describe the issue
It is not clear how to we release binaries that point to production or staging, we should have better documentation about this!
We probably should also have a clearer message that indicates that folks are using staging (it's probably not what they want).
To Reproduce
Get a minder CLI from one of the following methods:

A package manager (e.g. brew)}
A GitHub release
Self-built with make build
Self-built with goreleaser
Self-built with go build

It's not clear which method will end up pointing where.
What version are you using?
main

@JAORMX Let me get assigned this one

Hi @JAORMX , I just wanted to get your thoughts on how to approach this. I was thinking of adding a PersistentPreRunE to the root command and in there do something like this
		PersistentPreRunE: func(cmd *cobra.Command, args []string) error {
			grpcHost := viper.GetString("grpc_server.host")
			log.Info().Msgf("GRPC HOST %s", grpcHost)
			return nil
		},

So, doing minder auth login would already yield the GRPC host. e.g.:
Waiting for token...

    You have successfully logged in.

 Here are your details:

+----------------------------------------------------+----------------------------------------------------+
|                        KEY                         |                       VALUE                        |
+----------------------------------------------------+----------------------------------------------------+
| Minder Server                                      | staging.stacklok.dev:443                           |
+----------------------------------------------------+----------------------------------------------------+
| Project                                            | jaormx /                                           |
|                                                    | <Project ID>               |
+----------------------------------------------------+----------------------------------------------------+
Your access credentials have been saved to ...

The main difference is that for staging, the host is staging.stacklok.dev. I'd say, we should probably print out a warning if it's staging, telling people that it's a test environment and not to expect a lot of stability. The production URI would instead be api.stacklok.com which is more stable. What do you think?

So, doing minder auth login would already yield the GRPC host. e.g.:
Waiting for token...

    You have successfully logged in.

 Here are your details:

+----------------------------------------------------+----------------------------------------------------+
|                        KEY                         |                       VALUE                        |
+----------------------------------------------------+----------------------------------------------------+
| Minder Server                                      | staging.stacklok.dev:443                           |
+----------------------------------------------------+----------------------------------------------------+
| Project                                            | jaormx /                                           |
|                                                    | <Project ID>               |
+----------------------------------------------------+----------------------------------------------------+
Your access credentials have been saved to ...

The main difference is that for staging, the host is staging.stacklok.dev. I'd say, we should probably print out a warning if it's staging, telling people that it's a test environment and not to expect a lot of stability. The production URI would instead be api.stacklok.com which is more stable. What do you think?

Totally agree. I have implemented something here https://github.com/stacklok/minder/pull/2060 . Let me know if this is what you wanted.

@JAORMX - hey, I guess https://github.com/stacklok/minder/pull/2071 covered part of this issue, so what's left in order to complete it is to update the docs, right? cc: @AGMETEOR

@rdimitrov yep, it's ready and all needed is docs

@rdimitrov I can help update the docs if that’s ok? When I push a PR we can then review the wording.

@rdimitrov I can help update the docs if that’s ok? When I push a PR we can then review the wording.

Thanks! That would be awesome! 🙏

Just checking in... our docs are in https://github.com/stacklok/minder/tree/main/docs/docs; I'm not sure what documentation we were thinking of adding, though -- it seems like this is mostly a change to add output when certain config options are set?

I guess the idea is to mention which is our production API endpoint. So folks don't accidentally rely on staging.

After some discussion, we realized that with https://github.com/stacklok/minder/pull/2034 we could switch from using BUILDTAGS in our Makefiles to having users targeting staging by setting MINDER_CONFIG to point to a checked-in config file, and we could simply check in three of these.


Update PuTTY in Windows distro asap...LC client server has been crippled

Describe the bug
LC has updated protocols such that PuTTY in current Windows distro cannot connect. I've confirmed update PuTTY does work.
As an aside, do we need to create a modified PuTTY? I suspect we modify it in some ways to play well with our Qt login windows but is that essential? I am inclined to believe it would make things a bit easier to use vanilla PuTTY if this happens in future.
For reference, LLNL developers can view this Teams discussion
Desktop

OS and version: Windows
VisIt Version: all versions

I downloaded putty 0.78  on Windows and modified their CMake build system to only build plink, then verified that the generated plink.exe (renamed to qtssh.exe) could be used within VisIt 3.3.1 to connect to LC.  This gets us as far as @markcmiller86 workaround.
This is what is displayed in the plink terminal window when prompting for the password (and after the password is entered):
| Password:
- Keyboard-interactive authentication prompts from server: ------------------
-Access granted. Press Return to begin session.
- End of keyboard-interactive prompts from server ---------------------------
Running: vcl3.3.1 -dir /usr/gapps/visit -idle-timeout 480 -noloopback -sshtunneling -host localhost -port 20443

I am concerned about the need to 'Press Return to begin session'.  It may hamper attempts to modify plink to offer our standard password and change-username dialogs.  See this Putty FAQ.
The new plink source code is vastly different than the one we've modified in the past to allow our dialogs. Not sure the amount of effort it will take to make the modifications, but now that I think I know where to be looking I will begin investigation that.
@brugger1 any thoughts? IIRC, you've modified the plink code in the past.

It was probably 10 years ago that I last modified plink. I don't think I have any information to provide at this point.


Gap beetween dates

Describe the bug
The problem is connecting adjacent bars with difference date. What do I need to write to fix this?

Reproduction
https://nightvision.dev/guide/intro/10-basic-examples.html
Steps to reproduce
No response
Javascript Framework
no-framework (vanilla-js)
Logs
No response
Validations

[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a NightVision issue and not a framework-specific issue.
[X] The provided reproduction is a minimal reproducible example of the bug.

The only way
https://nightvision.dev/guide/intro/10-basic-examples.html#_5-displaying-stock-data


fix or ignore test cases

What changes were proposed in this pull request?
fix most test cases
ignore 2:
OapPlannerSuite - aggregations with group by test (Need further investigate)
OapSuite - Enable/disable using OAP index after the index is created already (Expected)
How was this patch tested?
all ut pass

@LinhongLiu
Have the new features in this branch been merged into the master?
Thanks


Save As dialog with a plain text file has 'Save as type' default to the wrong type

Issue Type: Bug
Steps to reproduce:

Make sure an untitled file is open and set to 'Plain Text' (Ctrl+N if necessary).
Open the Save As dialog using Ctrl+S.

Expected result: the 'Save as type' field should default to * or *.txt
Observed result: it defaults to the topmost non-'All files' type in the list, potentially hiding most files that shouldn't be hidden.
This issue occurs both on the release build and the Insiders build with extensions disabled.
VS Code version: Code - Insiders 1.54.0-insider (cd97629c4458c05b16a1fd444d21c61295ba2529, 2021-02-09T08:37:01.449Z)
OS version: Windows_NT x64 10.0.19042

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5 CPU         650  @ 3.20GHz (4 x 3192)

GPU Status
2d_canvas: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: enabledopengl: enabled_onprotected_video_decode: unavailable_offrasterization: enabledskia_renderer: enabled_onvideo_decode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
7.87GB (3.28GB free)

Process Argv
--disable-extensions --crash-reporter-id 2fa2b299-feb4-4e39-b908-4ae6c670137c

Screen Reader
no

VM
0%

This issue may be related, but is not a duplicate of that one.

Are you certain that you have the latest Insiders? I thought this problem had already been fixed.


Add gomod

With this PR I add the following changes:

support of go modules

@patrickmn could you please review this PR?

Found this fork: https://github.com/arp242/zcache


Pod version 2.6.3 doesn't have weak/unowned reference fix

Hey @tidwall
I'm using 2.6.3 version of the library via Cocoapods. I can see that master branch and swift/2.2 branch have this fix with weak/unowned reference. But the release with tag 2.6.3 still has unowned in the source.
You may download https://github.com/tidwall/SwiftWebSocket/releases/tag/2.6.3 directly and check that.

I guess you could just delete current 2.6.3 tag and create it again.

Darn it! Thanks for reporting. I'll work on a fix asap. Does pointing to the swift/2.2 branch work in the meantime?

Yep, I hardcoded swift/2.2 branch in my podfile.

OK.  I just pushed CocoaPods release with the unowned bug fix. Version 2.6.4 is now available and seems to be working. Let me know if this does not work for you and thanks a ton for you help.

Everything is ok now. Thanks a lot!


wrong editor cursor position when enter new line in split editor.

VSCode Version:1.25.1
OS Version:win10

Steps to Reproduce:

1.Split a editor.
2.Enter any content and show intelligent code completion dialog, and then don't click anywhere and don't close the suggest dialog.
3.Now enter new line in another editor. The cursor will jump back to old editor.

Does this issue occur when all extensions are disabled?: Yes

FWIW, I'm seeing the same thing on MacOS with the same version of VSCode.

I would expect the suggest list to close itself on focus loss.
@Zuolon Can you reproduce this when disabling all extensions?


ci: install gem under truffleruby

Trying to reproduce https://github.com/oracle/truffleruby/issues/2729

It should work with a rerun: https://github.com/oracle/truffleruby/issues/2729#issuecomment-1274679978
And thank you for adding truffleruby in CI :)


hotfix: delete previous code change for deleting last one loadbalancer in agent 2.0

Previous delete last one loadbalancer, the partition needs to be purged,
agent 2.0 has an approach to solve the problem by finding the last one lb in neutron DB.
However, we found another approach to solve the problem in agent 3.0 and
2.0.
I forget to delete the previous code change in f5 agent 2.0, and test. and it causes a bug.

Won't require this change.


battery: add reading of SoH register

Read State-of-Health register from Amber battery and send its value to Jetson.
fixes O-2426

I removed the last commit because it would spam error messages if the Orb is not supplied by a battery.


Swift 4 Support

Do you have a branch for Swift 4 and Xcode 9?

I've created a pull request for Swift 4 here:
https://github.com/tomvanzummeren/TZStackView/pull/93
Until it's merged, you can use my fork:
https://github.com/danielsaidi/TZStackView


Recipes!

recipes seem  to craft twice as normal...
1 log => 4 doors
1 log => 8 trapdoors
1 log => 4 fences
1 log => 4 fence gates
and so on...
Regards

Hey, that's normal behaviour!
From 1 log, you get 4 planks. wiht 2 planks you get two doors, with one plank 4 fences and so on.
So 1 log returns what a plank would return times 4. If a recipe needs two planks to craft, then it's divided by two.
e.g. door needs two planks to craft two doors, so 1 log = 4 planks = 4 doors

You my be mistaken... Taking the doors as example... vanilla minecraft from
6 planks you get 3 doors, so 2 planks you get 1 door... 1 log 4 doors...
On Sat, Jun 1, 2024, 22:09 NemoNotFound @.***> wrote:

Hey, that's normal behaviour!
From 1 log, you get 4 planks. wiht 2 planks you get two doors, with one
plank 4 fences and so on.
So 1 log returns what a plank would return times 4. If a recipe needs two
planks to craft, then it's divided by two.
e.g. door needs two planks to craft two doors, so 1 log = 4 planks = 4
doors
—
Reply to this email directly, view it on GitHub
https://github.com/NemoNotFound/NemosWoodcutter/issues/1#issuecomment-2143590438,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AELB3VKU4H52FQYCQII4YD3ZFIZ73AVCNFSM6AAAAABIUOHM3SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBTGU4TANBTHA
.
You are receiving this because you authored the thread.Message ID:
@.***>

The Woodcutter is there to be more efficient, exactly how the stonecutter works. There you also get 1 stair out of 1 stone, instead of 6 stones. Same here. You get two doors out of two planks, instead of 3 out of 6

Since this is expected behaviour and there was no new comment, I'll close this ticket


Group assignment and release notes stopped working

Our Fastlane script was auto assigning groups of users and adding some release notes but it stopped working a few days ago. Updated to latest plugin yesterday but still not working. Are you aware of any issues or changes in relation to this issue?

Hi olivierbrand! Thanks for reaching out.
A couple of questions to help us debug:

What is the exact failure case you are experiencing? Are there any error messages you are receiving? Or is the request succeeding, but something is not functioning as expected?
Could you send us your fastfile? Please be sure not to include anything sensitive

There are no errors as you can see below in our CI.

Also attaching the Fastfile.
Fastfile.zip

Thanks!
A couple of follow-up questions:

When was the last time that this worked successfully for you? And the first date and time it stopped working?
Can you describe the change in behavior you saw?

October 30th was the last time it worked. See image below

And build that failed was issued Nov 2nd:

Hi olivierbrand,
We recently made some changes in our backend that may have impacted this, but we reverted the change earlier this morning. Could you try again, and let us know if you still run into the same issue?
If it still doesn't work, another thing to try is to lowercase the group name to "development" instead of "Development". It looks like your fastfile is passing in the group name, instead of the group alias. The group alias can be found on the Testers & Group tab (see the screen shot below). The group alias should be used for cli tools

Using alias vs names did not help, result is the same.
Where do I need to add the debug flag? I have added it to:
firebase_app_distribution(     debug: true,
I do not get any additional info in my CI

Glad to hear @olivierbrand!

The issue is still actual. Re-installation of the plugin did not help me :(

The issue is still actual. Re-installation of the plugin did not help me :(

@tonybaroneee i was on version 0.2.0.  and debug is already set for true. Now will try to update for 0.2.4 and check. Thank you!

@tonybaroneee i was on version 0.2.0.  and debug is already set for true. Now will try to update for 0.2.4 and check. Thank you!

It helped me!
The updating of fastlane-plugin-firebase_app_distribution version to (0.2.4) helped me. Thank you!

It helped me!
The updating of fastlane-plugin-firebase_app_distribution version to (0.2.4) helped me. Thank you!

@Aisalkyn Glad to hear, you're welcome!

@Aisalkyn Glad to hear, you're welcome!


Xla and memory allocation

TensorFlow version 1.14
Python version: 2.7

I am defining this kind of graph:
product_list = [(5, 6), ...] # list of pairs of integers
data = tf.compat.v1.placeholder(dtype=tf.float64,
                                       name='input_tensor', shape=[1, 1000])
x_i = tf.gather(data, [i[0] for i in product_list], axis=1)
x_j = tf.gather(data, [i[1] for i in product_list], axis=1)
res = x_i * x_j

res = tf.concat([data, res], axis=-1)

and using AOT to compile an so.
Then calling the compiled function seems to take a lot of time.
So my question is : is there memory allocation at every call?
If yes, how can I avoid it by telling Tensorflow to pre-allocate the memory (as all the shapes are known in compile time)
For example are there any commands that result in a new memory allocation at every call? (tf.stack, tf.concat etc..)

@volvador, If you are using GPU, can you please try using GPU memory allocation mentioned in this link and let us know if the issue still persists. Thanks!

@gadagashwini I am using CPU

@volvador, Please provide the complete code to reproduce the reported issue. Thanks!

@volvador, Any update on the reproducible code. Thanks!

Automatically closing due to lack of recent activity. Please update the issue when new information becomes available, and we will reopen the issue. Thanks!


A nofari/luis sdk changes

Adding Luis App import/ export in .lu format
Adding Luis App import v2 app that enables to import an app that has entities with children of type "String"
Adding arm token header for azure account-related authentication

@KarishmaGhiya, Can you please check the reason for the build failures here?

@ramya-rao-a it's a node bug - https://github.com/nodejs/nodejs.org/issues/3075
We are seeing this across all our pipelines. Tagged you in Teams thread discussion

/azp run js - cognitiveservices - ci


ProgressChart | Display values bigger than 100%

Hey,
I'm currently working on a project and I have to visualise values in a Progress Chart, that can reach from 0 to literally infinity.
In the most cases the values are pending between 0 and 1 but sometimes I have to visualise values like 1.5.
Right now I'm just subtracting 1 until my value is between 0 and 1, but by using this way, I cant show my former value.
So:
Is there a way to visualise values more than 1? Or as an alternative can I change the background color of this one ring, so when displaying 1.5 I could fill the whole ring light red and then display .5 with a dark red color?
Thanks for helping
~ Hagen

https://www.youtube.com/watch?v=m8gyy7JItmU https://www.youtube.com/watch?v=1WZjeESH4a0


feat: add loki deck

Please also write a note in the documentation: https://getdeck.dev/docs/deckfile/wharf


WIP: Remove sector mode related code

This is a draft to get rid of sector mode. I think we haven't decided on removal yet, but we can keep the code change ready. I started with mechanical removal of related parts in code and doc.
Open question: what to do with parameter name useforfsdax. The functionality is still useful, as it allows to leave some part unused. (I assume we want to still keep this). But what do to with variable name now, should we keep it or change it to something else, like useforcsi ?
Or, should we drop this limiting functionality from pmem-csi altogether and move it elsewhere? (this relates to init stage functionality plans).
Also, with useforsector gone, the unit test part of that code does not do much, so should we remove it?

Olev Kartau<EMAIL_ADDRESS>writes:

Open question: what to do with parameter name useforfsdax. The
functionality is still useful, as it allows to leave some part
unused. (I assume we want to still keep this). But what do to with
variable name now, should we keep it or change it to something else,
like useforcsi ?

usefordax still makes sense to me as it's for a "fsdax" namespace.

Or, should we drop this limiting functionality from pmem-csi
altogether and move it elsewhere? (this relates to init stage
functionality plans).

Eventually yes, but not now.

Also, with useforsector gone, the unit test part of that code does
not do much, so should we remove it?

I'm not sure which test you mean, but yes, tests for code that no longer
exists should also be removed.

usefordax still makes sense

ok, good, lets keep it that way, less mods to API

I'm not sure which test you mean

I mean pkg/pmem-ns-init/main_test.go

tests for code that no longer exists should also be removed.

yes that's for sure (already done in PR), but I mean that after removal of irrelevant tests, the remaining part dilutes to be so small that it may seem silly to have it. In code supporting both modes, we have limits checking for both modes, plus limits combinations, totaling 9 cases. After removal of 2nd mode, we take away tests specific to that mode, but also combination-specifics, and what remains is just trivial bounds-checking for one mode, with 4 cases.

rebased, resolving merge conflict, and force-pushed. What do you think, does it make sense to keep unit test in pkg/pmem-ns-init/ after reduction by this PR, or is it now too trivial to have?

What do you think, does it make sense to keep unit test in pkg/pmem-ns-init/ after reduction by this PR, or is it now too trivial to have?

A test, no matter how trivial, is better than no test. Let's keep it.


Added AsyncSpider to init for cleaner import and example

Thank you for the PR, left some comments.

@j-mendez sorry, I don't see any comments in your review.

@j-mendez sorry, I don't see any comments in your review.

https://github.com/spider-rs/spider-clients/pull/20#discussion_r1677689176


VERDICT-289: Support Absolute DAL Cost Values

VERDICT-289: Support Absolute DAL Cost Values
Adding support for non-scalar cost modeling for defense definitions. Costs can now be declared as absolute values based on DAL. MonotonicCostModelTree validation ensures cost configurations are monotonic meaning all defense definitions (component, defense, dal couples) have greater or equal costs than predecessors (being lesser DALs or more general definitions).
Solves: VERDICT-289

Costs < 1 are no longer supported. All costs must be greater than the base scaling factor (1)
CostModel has been preserved, ICostModel created for future cost modeling


Incomplete tests: Metrics - StackDriver

@hklai commented on Mon Oct 09 2017
Context: production readiness proposal and plan
The feature “Metrics - StackDriver” is identified as incomplete test coverage. As a measure to reach Istio production quality in 0.3, this issue is opened to track the progress of providing sufficient test coverage for the feature in question.
This issue is initially assigned to the working group leads.
Recommendations:

Come up with a test plan for how the feature should be tested. Identify and document (in this issue, or a separate document this issue will link to) test cases and whether each will be covered by an integration test (with some level of mocking and/or starting up selected components in test environment), or end to end test (aka system test, which brings up the whole Istio to exercise the feature; currently live in the istio/istio repo).
If you expect the test plan is complex and controversial, consider having it formally reviewed.
State an ETA in the issue, and assign this to a developer who will execute the test plan.
Execute the test plan as the highest priority for 0.3.
For any bug or defect identified by the new test cases, file a new issue and link it from this one.
Close this issue only when the test plan is completely executed, and all additional issues identified in step 3 are fixed.

If you see a risk of not fixing this issue by end of 0.3, please contact<EMAIL_ADDRESS>as soon as possible. We will also periodically ping the issue for update.

@mandarjog commented on Wed Dec 13 2017
Stack driver is not on the list for 1.0

@bianpengyuan can you own developing the tests here as the Stackdriver story is more fleshed out?


Fix and normalize the Javascript HTTP and SDK styles of State Management

Description
Both the HTTP and SDK tutorials demonstrating State Management using JavaScript had many mistakes and inconsistencies making poor quality.
As mentioned in those issues there were numerous problems:

Not using async await
Not awaiting the sleep
Using function called start that didn't actually start anything
Creating a DaprClient every iteration of the loop instead of once and re-using
Attempting to use the return value of HTTP save request, but this returns void
Inconsistency in how data was access from axios response
Inconsistency in setup of DAPR_HOST and other variables

You can see both tutorials now function with the same output:

And most importantly. The purpose of having the HTTP and SDK folders was to show them doing the same thing and how a develop may choose to use the SDK or may HTTP directly.  The inconsistencies between the two samples codes meant that there were many other changes besides mearly using the SDK or not which distracts the user from recognizing this.
By removing all the inconsistencies, or normalizing the code and ONLY swapping HTTP for SDK it can be seen much more clearly:

Issue reference
We strive to have all PRs being opened based on an issue, where the problem or feature have been discussed prior to implementation.
Please reference the issue this PR will close:
Closes #2495
Closes #2494
Checklist
Please make sure you've completed the relevant tasks for this PR, out of the following list:

[x] The quickstart code compiles correctly
[x] You've tested new builds of the quickstart if you changed quickstart code
[x] You've updated the quickstart's README if necessary
[x] If you have changed the steps for a quickstart be sure that you have updated the automated validation accordingly. All of our quickstarts have annotations that allow them to be executed automatically as code. For more information see mechanical-markdown. For user guide with examples see Examples.

I would love @XavierGeerinck (js maintainer) and @amulyavarote (author) to review too.

I would love @XavierGeerinck (js maintainer) and @amulyavarote (author) to review too.

Added my review on it, thanks for flagging me in it! :) really nice PR

I would love @XavierGeerinck (js maintainer) and @amulyavarote (author) to review too.

Review looks good to me!

@mattmazzola Hi! Thanks for this contribution. Can you please take the latest changes, rebase and push the changes? We actually pushed few changes recently to fix the build issues. Pulling and rebasing the latest changes should fix your PR's build issues. Thanks!

Other changes look good to me!

Hi! Can you please fix state management workflows and also DCO?

Hi! Can you please fix state management workflows and also DCO?

No, I don't know what those terms mean.  I thought this would be a simple PR, but this ridiculous. I give up

@mattmazzola - @amulyavarote will work with you to resolve the above. This PR is too good to drop. We really welcome your contribution here and apologize if this is unclear. We will work to make the testing need to be simpler.


Allow for importing profiles

Is your feature request related to a problem?
When working with repos with dependencies on each other, both the terminals of a dependency often need to instantiate each other from within their own codebase. Currently, we do this via profiles. However, this means that the same/similar profile is redefined in multiple places.
e.g. suppose that:
A->B
C ->B
dependency exists. i.e. repo A needs the components from repo B to work, and similarly for C.
This usually means that the profile to deploy B is defined in both A and C.
Ideally, B would provide a profile e.g. -p with-B and that could be used by A, C and any other repo that has B as a dependency.
Which solution do you suggest?
Which alternative solutions exist?
Additional context

Have you tried importing profiles as it looks supported in our docs:https://www.devspace.sh/docs/configuration/imports/#import-sections


version history

Add version history for CsWinRT, WinAppSDK, .NET SDK and versioning requirements.

I believe WinAppSDK 1.0.2 also ships with CsWinRT 1.6.1.

@Marv51 - WinAppSDK 1.0.x hasn't updated to CsWinRT 1.6.1 yet. However, 1.1-preview2 is using CsWinRT 1.6.1.


Add FetchSM support to dechunking in non-streaming mode with new TS API TSFetchFlagSet

to enable TSFetchUrl to use HTTP/1.1
FetchSM supports dechunking of chunked response but only in
STREAM mode (ie headers first and body in stream). However,
we may need to use FetchSM for sideways calls with dechunked
body and non-stream mode ie headers and body together. Without
this, TSFetchUrl can only work with HTTP/1.0 which is limiting
as it doesn't allow us to enable keep alive and all 1.1 goodness
This PR fixes the problem by allowing to dechunk response even
when stream mode isn't specified

Email to dev@ announcing the new TS API
{code}
Fri, Mar 6 at 8:40 AM
Sorry, I just realized that TSFetchUrl() can be called directly without calling TSFetchCreate(). So, to preserve backward compatibility and to be able to set the fetch flags, I'm going to add a new TSFetchFlagSet API as below.
The API accepts a previously created FetchSM context and the flags to be set on it.
+void
+TSFetchFlagSet(TSFetchSM fetch_sm, int flags)
+{

sdk_assert(sdk_sanity_check_fetch_sm(fetch_sm) == TS_SUCCESS);

(reinterpret_cast<FetchSM *>(fetch_sm))->set_fetch_flags(flags);

+}

Since this is a new API, I'll wait for a few more days for the review.
On Friday, March 6, 2020, 08:03:03 AM PST, Sudheer Vinukonda<EMAIL_ADDRESS>wrote:

I'm going to call this in and make the change to the TSFetchUrl() API to remove setting TS_FETCH_FLAGS_DECHUNK flag by default.
After discussing with Leif over slack, it's worth explicitly clarifying that plugins that do want to still have TS_FETCH_FLAGS_DECHUNK set can do so by simply passing the flag during TSFetchCreate() explicitly (that is exactly what we are going to do in our plugins).
-- Sudheer
On Wednesday, March 4, 2020, 10:06:00 AM PST, Sudheer Vinukonda<EMAIL_ADDRESS>wrote:

We use TSFetchUrl() API in a bunch of our use cases to trigger sideways calls. The API by default sets TS_FETCH_FLAGS_DECHUNK,which implies the response returned is dechunked. There's another flag called 'TS_FETCH_FLAGS_STREAM' in FechSM, which is NOT set by default.
This makes TSFetchUrl API a bit conflating and contradictory since dechunking is only done when 'TS_FETCH_FLAGS_STREAM' is set ignoring the TS_FETCH_FLAGS_DECHUNK.
Our plugins can not handle chunked responses on their own and we don't want TS_FETCH_FLAGS_STREAM. We just want the entire response (headers + body) to be returned together set by the callback_options AFTER_BODY (similar to how esi plugin works).
The side-effect of all of this is that we can not use HTTP/1.1 to the Origins return chunked responses and the contradictory flags above mean that our plugins end up getting chunked body (with chunk sizes, trailers etc).
I'd like to change the default TSFetchUrl() API mode to not set TS_FETCH_FLAGS_DECHUNK anymore and let callers ask explicitly if they want dechunked body similar to how  'TS_FETCH_FLAGS_STREAM'  flag works.
The resultant behavior would be that a plugin would get chunked body only when it does not set 'TS_FETCH_FLAGS_STREAM' and TS_FETCH_FLAGS_DECHUNK explicitly. If it does either, it'd get dechunked body (streamed in the first case and non-streamed in the latter).
This will make the flags consistent and preserves the backward compatibility that esi plugin needs as it does not set TS_FETCH_FLAGS_STREAM (and TS_FETCH_FLAGS_DECHUNK) explicitly. We will update our plugins to explicitly ask for TS_FETCH_FLAGS_DECHUNK.
Let me know if there are any concerns/suggestions.
{code}

[approve ci autest]

[approve ci autest]

[approve ci Clang-Analyzer]

[approve ci autest]

@vmamidi @zwoop @SolidWallOfCode Can one (or all :) ) of you review this pls?


Updates Github action and replaces TravisCI badge

Updated Github actions to v3 and replaced TravisCI badge in readme with badge for Github action.

Thanks!
However what is the rationale for package-lock and hard-coding the node.js version?
It feels like that's just going to be another thing to keep up to date.

@gfwilliams
package-lock: The lock file allows to have the same versions of dependencies and sub-dependencies installed on every installation. This makes the code and issues reproducible. If you just install via npm i or npm install it is modifying the lock file and defeats the purpose. But installing dependencies with npm ci strictly installs the dependency version otherwise it throws an error. https://docs.npmjs.com/cli/v8/commands/npm-ci
hard-coded nodejs version: The version was already hard-coded before to version 16.x but it used the matrix notation, which just makes it harder to understand what's going on if it is not used for more than 1 node version, e.g.
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [12.x, 14.x, 16.x]
    steps:
      - uses: actions/checkout@v3
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v3
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm ci
      - run: npm run test

In this example, the flow is executed for 3 different node versions. Since the current test job is only linting, one node version is enough. If you run automated tests like in the example above you want to make sure the tests are passing for all supported node versions of the project.


rename context to environment

The concept is like this: If I have a type definition like
record A { ... }

I should have the following rules

context bind A : Type
check type value record { ... } is a type
environment bind A = record { ... }

The problem is, we have only type definition, and no term definition, and after check we didn't reuse the result. For example,
foo: func(x_i: A_i) -> B

we only check each A_i and B existed in environment, and no nothing more. To fix them all, and ensure later advanced plugin generator can work, we will have to introduce concept about type value. An evaluation function that reduce reference of type to a type value, and allow neutral value or not is another problem need to consider, should we assume each type can be expanded properly?

Hello, I am a code review bot on flows.network.
It could take a few minutes for me to analyze this PR. Relax, grab a cup of coffee and check back later. Thanks!


feat: Improvement of UI for Footer

Title and Issue number
Title : feat : Improvement of UI for Footer
Issue No. : #904
Code Stack : HTML and CSS
Close #904
Description
Added hover effect and border to the headings.
Changed color of sub headings.
Added hover effect on the clickable subheading.
Improved Layout of- Places You May Want to Visit, Social Media, Address, Reach Out To Us, Follow Us
Video/Screenshots (mandatory)
https://github.com/apu52/Travel_Website/assets/134837879/884efe1a-1e6b-4455-94df-28ab9abf0e29
Type of PR

[X] Feature enhancement

Checklist:

[X] I have performed a self-review of my code.
[X] I have commented my code, particularly in hard-to-understand areas.
[X] I have tested the changes thoroughly before submitting this pull request.
[X] I have provided relevant issue numbers, screenshots, and videos after making the changes.
[X] I have gone through the  contributing.md file before contributing

##Are you contributing under any Open-source program?

[X] I am contributing under GSSOC'24
[ ] I am contributing under VSOC'24

@apu52 I am not able to understand the mistake to generate this PR. Please help me regarding the same.

Don't worry I will solve the PR title checker problem. Please try to resolve the conflicts


Unable to support android

Please set the platform availability only IOS, don't just put at the bottom remarks, thank you
However, in iOS it works very well.

具体原因请查看 #26


'(not showing binary data)' when the content-type is text/html

Hi there!
I created a module to prepend on HttpLog and check the content of data that is passed to json_payload and data seems to be already formatted:
[17] pry(HttpLog)> data.keys
=> [:method, :url, :request_body, :request_headers, :response_code, :response_body, :response_headers, :benchmark, :encoding, :content_type, :mask_body]
[18] pry(HttpLog)> whereami

From: (pry):76 Gabriel::Gabriel#json_payload:

    75: def json_payload(data = {})
 => 76:   binding.pry
    77:   super
    78: end

The problem is that it is trying to check for data[:content_type] to decide wether or not to parse the response body.
=> ["/app/vendor/cache/ruby/3.1.0/gems/httplog-1.6.2/lib/httplog/http_log.rb:208:in `dump_json'",
 "/app/vendor/cache/ruby/3.1.0/gems/httplog-1.6.2/lib/httplog/http_log.rb:198:in `log_json'",
 "/app/vendor/cache/ruby/3.1.0/gems/httplog-1.6.2/lib/httplog/http_log.rb:35:in `call'",
 "/app/vendor/cache/ruby/3.1.0/gems/httplog-1.6.2/lib/httplog/adapters/ethon.rb:28:in `perform'",
 "/app/vendor/cache/ruby/3.1.0/gems/prometheus_http_logger-1.1.1/lib/prometheus_http_logger/adapters/ethon_adapter.rb:18:in `perform'",
 "/app/vendor/cache/ruby/3.1.0/gems/typhoeus-1.4.0/lib/typhoeus/request/operations.rb:16:in `run'",
 "/app/vendor/cache/ruby/3.1.0/gems/typhoeus-1.4.0/lib/typhoeus/request/cacheable.rb:18:in `run'",
 "/app/vendor/cache/ruby/3.1.0/gems/typhoeus-1.4.0/lib/typhoeus/request/block_connection.rb:31:in `run'",
 "/app/vendor/cache/ruby/3.1.0/gems/typhoeus-1.4.0/lib/typhoeus/request/stubbable.rb:25:in `run'",
 "/app/vendor/cache/ruby/3.1.0/gems/typhoeus-1.4.0/lib/typhoeus/request/before.rb:26:in `run'",
 "/app/vendor/cache/ruby/3.1.0/gems/scout_apm-5.3.5/lib/scout_apm/instruments/typhoeus.rb:61:in `run'",
 "/app/vendor/cache/ruby/3.1.0/gems/stor_edge_client-2.0.0/lib/stor_edge_client/requests/base_request.rb:58:in `execute'",
 "/app/vendor/cache/ruby/3.1.0/gems/stor_edge_client-2.0.0/lib/stor_edge_client/requests/base_request.rb:41:in `execute'",
 "/app/vendor/cache/ruby/3.1.0/gems/stor_edge_client-2.0.0/lib/stor_edge_client/client.rb:43:in `get_unit_groups'",
 "/app/vendor/cache/ruby/3.1.0/gems/httplog-1.6.2/lib/httplog/http_log.rb:116:in `parse_body'",
 "/app/vendor/cache/ruby/3.1.0/gems/httplog-1.6.2/lib/httplog/http_log.rb:231:in `json_payload'",
 "/app/vendor/cache/ruby/3.1.0/gems/httplog-1.6.2/lib/httplog/http_log.rb:208:in `dump_json'",
 "/app/vendor/cache/ruby/3.1.0/gems/httplog-1.6.2/lib/httplog/http_log.rb:198:in `log_json'",
 "/app/vendor/cache/ruby/3.1.0/gems/httplog-1.6.2/lib/httplog/http_log.rb:35:in `call'",
 "/app/vendor/cache/ruby/3.1.0/gems/httplog-1.6.2/lib/httplog/adapters/ethon.rb:28:in `perform'",
 "/app/vendor/cache/ruby/3.1.0/gems/prometheus_http_logger-1.1.1/lib/prometheus_http_logger/adapters/ethon_adapter.rb:18:in `perform'",
 "/app/vendor/cache/ruby/3.1.0/gems/typhoeus-1.4.0/lib/typhoeus/request/operations.rb:16:in `run'",
 "/app/vendor/cache/ruby/3.1.0/gems/typhoeus-1.4.0/lib/typhoeus/request/cacheable.rb:18:in `run'",
 "/app/vendor/cache/ruby/3.1.0/gems/typhoeus-1.4.0/lib/typhoeus/request/block_connection.rb:31:in `run'",
 "/app/vendor/cache/ruby/3.1.0/gems/typhoeus-1.4.0/lib/typhoeus/request/stubbable.rb:25:in `run'",
 "/app/vendor/cache/ruby/3.1.0/gems/typhoeus-1.4.0/lib/typhoeus/request/before.rb:26:in `run'",
 "/app/vendor/cache/ruby/3.1.0/gems/scout_apm-5.3.5/lib/scout_apm/instruments/typhoeus.rb:61:in `run'",

The request itself doesn't have anything special, it's a GET with text/html response and status is 200.

Found it:
[2] pry(#<Ethon::Easy>)> puts response_headers
HTTP/2 404
date: Mon, 22 Jan 2024 17:29:28 GMT
content-type: text/html

[6] pry(#<Ethon::Easy>)> response_headers.scan(/Content-Type: (\S+(; charset=\S+)?)/).flatten.first
=> nil
[7] pry(#<Ethon::Easy>)> response_headers.scan(/Content-Type: (\S+(; charset=\S+)?)/i).flatten.first
=> "text/html"

The response is on lowercase, I will monkey patch here and open a PR.


Dev

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@74bc049). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             master    #13   +/-   ##
=======================================
  Coverage          ?   100%
=======================================
  Files             ?      6
  Lines             ?    479
  Branches          ?      1
=======================================
  Hits              ?    479
  Misses            ?      0
  Partials          ?      0

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 74bc049...8be5d5a. Read the comment docs.


Question: Array of bitfields

I'm considering using this library ..
I'm needing to create large arrays of these.
What is the overhead as far as memory?  I am storing nibble sized structs with two enums.

Generally the modular bitfield structs should not impose overhead besides longer compilation times due to usage of proc. macros. This library was designed to not introduce overhead anywhere. Bitfield structs are aligned to byte sized portions since underlying we are using a [u8; N] array. If you are using an array of bitfield structs you are just using an array of an array underlying.


add alert message for send voice mail

Coverage remained the same at 39.648% when pulling 1f9b8d599b2649049e1d9dfcba50ffb0d3353158 on caffffe:send-voicemail-errorhandling into a209dbfe9c69718096de0f45f19a0e3b85b7c733 on ringcentral:master.

Coverage remained the same at 39.482% when pulling 65e05af2da4cbb75f88a3189f36220ed1ed316f9 on caffffe:send-voicemail-errorhandling into b0628b64d1c26e828bcae95b3ad8599179d71496 on ringcentral:master.


Installing i3 on Arch

https://briancaffey.github.io/2017/10/17/moving-from-gnome-to-i3-on-arch-linux.html/
sudo pacman -S i3 dmenu
Reference card: https://i3wm.org/docs/refcard.html

Not relevant anymore. Switched to NixOS.


[FLINK-4528] [rpc] Marks main thread execution methods in RpcEndpoint as protected

The main thread execution methods should not be exposed to the outside world of the RpcEndpoint, because they are internal methods.

I am not sure I agree with this change.
There are cases when another class logically belongs to the RPC endpoint (such as a connection utility). Being able to access the RPC execution context allows one to treat both together as a "one operation at a time" unit. I think that is pretty useful.

I think that the RpcEndpoint should keep the control over which components have access to its main thread and which not. Furthermore, limiting the access to protected does not prohibit other components to use the main thread execution context. The difference is simply that the TaskExecutor has to actively give the context to the component instead of the component taking it.

Okay, that makes sense.
This would need to be updated then such that the ResourceManager passes its MainThreadExecutionContext.

Yes, will do that.
On Wed, Aug 31, 2016 at 1:50 PM, Stephan Ewen<EMAIL_ADDRESS>wrote:

Okay, that makes sense.
This would need to be updated then such that the ResourceManager passes
its MainThreadExecutionContext.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/apache/flink/pull/2436#issuecomment-243740478, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFfXugFJNjWpXGbo-_WO-kkQtxJsKACgks5qlWqCgaJpZM4Jvgqw
.

After addressing the comments, I'll merge this PR.


Snippet variable $LINE_COMMENT is incorrect when inside JSX

VSCode Version: latest
OS Version: macOS latest

Steps to Reproduce:

Create a snippet with config{
  "TODO": {
    "prefix": "todo",
    "body": "$LINE_COMMENT TODO: "
  }
}

Inside JSX, run the snippet (place cursor after todo, open suggestions, then execute)

    todo
    hello, world!

Actual:

    // TODO:
    hello, world!

Expected:

    {/* TODO */}
    hello, world!

This is how the "add line comment" works, so I would expect the snippet variable to behave similarly.

Does this issue occur when all extensions are disabled?: Yes

In a .jsx file:

Sorry for the huge gif.  As you can see it works as you expected for me.  Are you doing anything differently than what I did?

@OliverJAsh Please retry without extensions enabled. Select 'Extensions View > ... > Disable all Installed Extensions' and try again. Thanks.

@ArturoDent @jrieken Sorry I got my expected/actual mixed up. I've updated the original issue description now to correct this, essentially by swapping expected/actual.

Can you run "F1 > Inspect Editor Tokens and Scopes" at the insert position and check what language is selected at the position? This usually depends on the grammar and is sometimes wrong

Roger. The problem is that the comments variables are resolved against the document language, not against the language at the current position.

I have pushed a change that makes sure we resolve variables against the language at the current position. However, the snippet you have shared won't work because the jsx-tags language doesn't define a line comment token

the jsx-tags language doesn't define a line comment token

Is this something which needs fixing separately?
I'm surprised it doesn't work because if I run the "add line comment" command at the same position, it does use the correct syntax. I would have thought the snippet would use the same mechanism as this command.

Is this something which needs fixing separately?

Yeah, that's a separate issue. Assuming line comment token exists in that language.

. I would have thought the snippet would use the same mechanism as this command.

I doesn't because it has much less context as snippet variables are resolved in-place

Yeah, that's a separate issue. Assuming line comment token exists in that language.

Should I file another bug?

I thought about filing another bug but the description would be identical to the one I posted here. Can we just re-open this until the expected behaviour is achieved?

https://github.com/microsoft/vscode/issues/102609


getChildren for the folder doesn't work

list<BoxItem.Info> children = folder.getChildren();
throws an exception
BoxJsonObject.BoxJsonObjectException: Json string passed to BoxJsonObject.parseJsonObjectArray was not valid json

Are You installed from Package Link ?
I also it got an error.
I was able to get the success the latest source code.

@m-akashi how did you deploy it? did you manually copy over all files?

I use Force.com IDE with eclipse.
You might want to create a unmanaged package in the Salesforce Developer Edition.

@m-akashi Thnx for the reply, I was able to resolve the issue by pulling down the latest version of the code and deploying to sandbox using Ant. Package link doesn't seem to have the latest version of the code.

The install link has been updated and documentation around merging commits now includes updating that package link for Box employees doing the push.


Javascript object literal string values are collapsed to string type

Bug Report
🔎 Search Terms
Javascript, object, literal, literal string, collapse
🕗 Version & Regression Information
4.9.3
⏯ Playground Link
Playground link with relevant code
💻 Code

// error
const foo = {
  type: 'GET',
  url: 'foo.com',
}

callThis( foo );

// no error
callThis( {
  type: 'GET',
  url: 'foo.com',
});

/**
 * @param {{type: 'GET'|'POST'; url: string}} foo
 */
function callThis( foo ) {

}

🙁 Actual behavior
JS object is collapsed with literal strings to string type
🙂 Expected behavior
Don't collapse literal strings in Javascript objects

This is working as intended, and changing this behaviour would be a massive breaking change.
You can get the behaviour you want by using a const-context. This is the intended way.
In TypeScript you'd just add as const, and in JavaScript you can use JSDoc for it:
const foo = /** @type {const} */ ({
  type: 'GET',
  url: 'foo.com',
})


[GEP-20] Remove support for HA alpha annotation

How to categorize this PR?

/area high-availability
/kind cleanup
What this PR does / why we need it:
This PR removes the support for the alpha.control-plane.shoot.gardener.cloud/high-availability annotation which had been used previously before shoot.spec.controlPlane.highAvailabillity was introduced. Gardener will automatically translate the annotation to the spec field for a while to not cause any disruptions for existing shoots that haven't been adjusted yet.
Which issue(s) this PR fixes:
Fixes parts of #6529
Release note:

The HA annotation `alpha.control-plane.shoot.gardener.cloud/high-availability` has been deprecated and is not respected anymore. We ask you to check your automation and to remove any usage of this annotation.
Gardener will automatically translate the annotation to the corresponding spec field for a few releases to not cause any disruptions for existing clusters that haven't been adjusted.

/assign


Add test for nested tuple access

Helps with #4470

pass cargo make test

Thank you for the PR @sasurau4 adding the tests! Be sure to review the additional comments (like https://github.com/rust-lang/rustfmt/issues/4470#issuecomment-719170245) on the linked issue that call out a minor code change we want to make as well

@calebcartwright Thanks for pointing out. I fixed!

Perfect thank you.
Changes LGTM, though would you mind doing me a favor and including the below snippets in the tests too? They'll be formatted fine here but since these uses cases were reported in #4543 I'd like to include them in the test suite to prevent any future regressions
let oid = oid!(1.2.840.1135<IP_ADDRESS>);
let oid2 = oid!(<IP_ADDRESS>);

@calebcartwright Thanks for your review. I added the test for issue-4543 :+1:

Thanks!