throwing InvalidOperationException in Read() and Frame documentation discrepancies

On UWP, with the demo app, I call discover nodes and end up with an erroneous exception from SerialDeviceStream.cs.  (I'm using a 900HP radio in API mode with escapes).
public override int Read(byte[] buffer, int offset, int count)
{
     throw new InvalidOperationException();
}

Anyone know how on earth am I getting here?  I can't find the code path which calls this method - there isn't one in this repo...  Seems like an Async bug in the BinarySerializer library.
The console output looks like this - many of the pieces of the message are coming in correctly:
D-End: Value (65534) @ 10
D-End: ShortAddress (FFFE) @ 10
D-Start: LongAddress @ 10
D-Start: Value @ 10
Rx Trace - 0013a20041828c51
D-End: Value<PHONE_NUMBER>276817) @ 18
D-End: LongAddress (0013A20041828C51) @ 18
D-Start: ReceivedSignalStrengthIndicator @ 18
D-Start: SignalLoss @ 18
Rx Trace - 50
D-End: SignalLoss (80) @ 19
D-End: ReceivedSignalStrengthIndicator (Low) @ 19
D-Start: Name @ 19
Exception thrown: 'System.InvalidOperationException' in System.Private.CoreLib.dll
It just blows up on the Name field every time.
Here's the call stack that got me there, but I don't understand who is calling the method!

XBee.Core.dll!XBee.SerialDeviceStream.Read(byte[] buffer, int offset, int count) Line 57	C#
BinarySerializer.dll!BinarySerialization.BoundedStream.ReadByteAligned(byte[] buffer, int length)	Unknown
BinarySerializer.dll!BinarySerialization.BoundedStream.ReadImpl(byte[] buffer, BinarySerialization.FieldLength length)	Unknown
BinarySerializer.dll!BinarySerialization.BoundedStream.ReadImpl(byte[] buffer, BinarySerialization.FieldLength length)	Unknown
BinarySerializer.dll!BinarySerialization.BoundedStream.ReadImpl(byte[] buffer, BinarySerialization.FieldLength length)	Unknown
BinarySerializer.dll!BinarySerialization.BoundedStream.ReadImpl(byte[] buffer, BinarySerialization.FieldLength length)	Unknown
BinarySerializer.dll!BinarySerialization.BoundedStream.Read(byte[] buffer, int offset, int count)	Unknown
BinarySerializer.dll!BinarySerialization.TapStream.ReadByteAligned(byte[] buffer, int length)	Unknown

@jefffhaynes If you have a minute let me know what you think.  I'd really like to use this library!!

Little more legwork here.  I pulled in the source for BinarySerializer.
In BoundedStream.cs, there exception originates from like 555:
protected virtual int ReadByteAligned(byte[] buffer, int length)
{
    return Source.Read(buffer, 0, length);
}

And Source is an XBee.SerialDeviceStream.  So there's the issue.  Not we just need to understand why SerialDeviceStream doesn't support the non-async read.  Or why the BoundedStream makes this call.
I think the call in BoundedStream is needed because it's used quite a bit, but in most cases the Source is a Payload object and supports the non-async Read call...  So why does XBee.SerialDeviceStream not support this non-async Read call?

Ok so I got to the bottom of this after about 5 hours...  In the end, Digi International is dropping the ball.  Not surprised.
The 900HP radio firmware version 8075 has apparently changed the format of both of these structures:
NetworkDiscoveryResponseData
NetworkDiscoveryResponseDataExtendedInfo
In the former, ReceivedSignalStrengthIndicator (DB) is missing.  Which causes the Name to not parse correctly!
When the receive message is missing bytes for ReceivedSignalStrengthIndicator, somehow the non-async Read() function does get called.  This seems like a bug still either way.  But it makes sense why we might not have seen it - when the frame is corrected, and ReceivedSignalStrengthIndicator is removed from NetworkDiscoveryResponseData the BinarySerializer works correctly and I get my data back.
Also note, with my radio's firmware, there are issues with NetworkDiscoveryResponseDataExtendedInfo structure.  However,  again the issues are not with this library!  There are errors in the Digi International documentation!  Wtf...  The latest online documentation for the SB3 radio has it wrong!  Here's a link to their API documentation for the frame in question for my radio:
SB3 900HP Docs
For example, using XCTU a request of (API mode 1):
7E 00 04 08 01 4E 44 64
Responds erroneously with (in my case another node with the name "pva"):
7E 00 1B 88 01 4E 44 00 FF FE 00 13 A2 00 41 63 BF A3 70 76 61 00 FF FE 01 00 C1 05 10 1E F3
Looking closely one will see that we've missed the bytes for signal strength "DB."  There is a missing byte between A3 (end of address SL) and 70 (which is "p" - the first char of my NI field).
The we then fall further off the rails - there seems to be no bytes for DEVICE_TYPE or STATUS_RESERVED.
The corrected data structure looks like this:
namespace XBee.Frames.AtCommands
{
    internal class NetworkDiscoveryResponseDataExtendedInfo
    {
        //This works for XBee Pro (SB3) 900HP with Firmware version 8075 in DigiMesh mode.
        //Seems they have changed the response!
        [FieldOrder(0)]
        public ushort ProfileId { get; set; }

        [FieldOrder(1)]
        public ushort ManufactureId { get; set; }

        [FieldOrder(2)]
        public byte[] OptionalData { get; set; }
    }
}

And yes, the last 4 bytes of "OptionalData" in the frame are totally undocumented because my NO value is 0!
Digi... ya' killing me over here.
@jefffhaynes let me know if the following PR is correct or worth while per the bug described above - in my testing it does correctly deal with senario where the response is missing ReceivedSignalStrengthIndicator but you might want to check into why BinarySerializer calls Read() in the first place.

I closed the above PR because I'm not sure how to fix it exactly.  I found more S3B documentation that shows the frame data differently and it seems to align with the response I get more accurately.
Perhaps an older manual, but it starts the ND response with the MY parameter (which is what I've seen in newer manuals).  I don't see the MY value on my radio, but everything else after that looks accurate.
Sparkfun HP900 datasheet
The above info in this thread is accurate, however I think we need more thought / testing put into the [SerializeWhen] attributes.
I'm going to yield to @jefffhaynes for now and possibly file a support ticket with Digi.

Sorry, just catching up on this. I’ll try to get into it as soon as possible. I will say the serial device support in UWP is a nightmare, although it sounds like that isn’t the problem.

From: Andy Gikling<EMAIL_ADDRESS>Sent: Sunday, November 3, 2019 10:06 AM
To: jefffhaynes/XBee
Cc: Jeff Haynes; Mention
Subject: Re: [jefffhaynes/XBee] throwing InvalidOperationException in Read() (#62)
I closed the above PR because I'm not sure how to fix it exactly. I found more S3B documentation that shows the frame data differently and it seems to align with the response I get more accurately.
Perhaps an older manual, but it starts the ND response with the MY parameter (which is what I've seen in newer manuals). I don't see the MY value on my radio, but everything else after that looks accurate.
Sparkfun HP900 datasheethttps://cdn.sparkfun.com/datasheets/Wireless/Zigbee/90002173_N.pdf
The above info in this thread is accurate, however I think we need more thought / testing put into the [SerializeWhen] attributes.
I'm going to yield to @jefffhayneshttps://github.com/jefffhaynes for now and possibly file a support ticket with Digi.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/jefffhaynes/XBee/issues/62?email_source=notifications&email_token=ACKIURYFJ5XZUFMAZ5Y3PYDQR3LIBA5CNFSM4JIBKXXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC5UYYQ#issuecomment-549145698, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACKIUR2QL3RVDWNGSWFTC43QR3LIBANCNFSM4JIBKXXA.

I am encountering this issue as well.
Looking into BinarySerializer, it looks like the AsyncBinaryReader switches from async to sync when it tries to read a char (code below), and this seems to propagate through to the sync read method in SerialDeviceStream.
public Task<char> ReadCharAsync(CancellationToken cancellationToken)
{
    return Task.FromResult(base.ReadChar());
}

( @jefffhaynes Thanks for creating this library. It's Great! )

Ah, thanks for tracking that down. I'll try to get a fix into the serializer soon.

Should be fixed in XBee.Core 1.6.6.  Please let me know if you have any problems with it.


[Bug] SQLCache have no effect

Search before asking

[X] I had searched in the issues and found no similar issues.

Version
2.0.2
What's Wrong?
set enable_sql_cache=true;
set enable_partition_cache=true;
then execute query twice, the execute time almost not reduce，
from the fe metrics ：

the query profile :

fe config :

What You Expected?
how two use SQLCache
How to Reproduce?
No response
Anything Else?
No response
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Let me take a look

doris 2.0.2, 主键模型跟聚合模型遇到一样的问题

这个有解决方案吗？
还有一个问题，partitaion cache的数量和命中率 该怎么监控呢？

有没有试过直接在fe.conf中增加?
cache_enable_sql_mode=true
cache_enable_partition_mode=true
我加了之后sql_cache开启了，但是partition_cache一直没有监控数据。


COMPRESS-540: Implement TarFile to allow random access to tar files

Basic idea behind the implementation is to read all headers at instantiation and save the position to the entry data. This will then be accessed as a random access file when reading the entry.
I tried to touch as less exisiting code as possible and only did refactor existing code were I felt it was really needed.
I have the following TODOs left in the code where I think your opinion is needed

TarArchiveInputStream#canReadEntryData: as noted in the TODO sparse entries are now supported. I see no need for this function any longer and would not include it in the TarFile api. Also we should update the implementation to reflect the now supported sparse entries.

In the SparseFilesTest extracting of sparsefile-0.1 in pax_gnu_sparse.tar is skipped because of problems with tar on Ubuntu 16.04. I tested this on Ubuntu 18.04 and everything worked fine. Should we reenable extracting of the file?

[x] Incorporate fix for COMPRESS-544

Coverage increased (+0.03%) to 87.316% when pulling 01ea7d3d9fbb629c35f0a20407b8e3975cd07157 on theobisproject:random-access-tar into f41756f8024930384a60c5c57eb9eb2913ce1ae0 on apache:master.

From the sidelines here... I am wondering if the introduction of utility streams would not best be done by depending on Apache Commons IO which already contains a bounded stream for example. What's missing in Commons IO could be added there if general enough.

Hi.
suggestions:
for BoundedSeekableByteChannelInputStream, please tell users if it is thread-safe in its javadoc.
for BoundedNIOInputStream , please tell users if it is thread-safe in its javadoc.
for BoundedNIOInputStream , please tell users if it is thread-safe in its javadoc.
for TarArchiveSparseZeroInputStream, maybe this class should be added to commons-io instead.

I am wondering if the introduction of utility streams would not best be done by depending on Apache Commons IO which already contains a bounded stream for example

As I understood commons-compress does purposefully not depend on Commons IO. This is something which I cannot decide to change.

for BoundedSeekableByteChannelInputStream, please tell users if it is thread-safe in its javadoc.
for BoundedNIOInputStream , please tell users if it is thread-safe in its javadoc.

I will add the information if the general design is accepted from the maintainers.

for TarArchiveSparseZeroInputStream, maybe this class should be added to commons-io instead.

In my opinion this adds no value for Commons IO and should not be used outside of the tar implementation. I only moved this class to reuse it in both implementations and made it package protected so nobody outside the tar package will use it.

In my opinion this adds no value for Commons IO and should not be used outside of the tar implementation.

+1. The TarArchiveSparseZeroInputStream will only return 0 if you are reading it. It's simple enough and I think this should be limited to tar in Commons Compress.

Unfortunately I've been unable to do a real review so far. $life is just setting different priorities right now. A few more or less unsorted thoughts:

I really wish Compress had abstractions that weren't so tightly bound to Java Streams, but we'll likely never find the energy and time to revamp it
I understand you want to get feedback on whether something like TarFile would be accepted rater than the concrete implementation. IMHO this would be a nice addition even though I don't expect many people to require random access to a raw tar archive. Most people likely deal with tar archives that have been compressed and so you'd need to decompress it to a temporary file (or memory) for random access.
we already have a bunch of things copied from commons-io and our very own BoundedInputStream may even predate the one of commons-io. I wouldn't want to add a new dependency to 1.x unless the reason was better than avoiding dupkiicating a few lines of code.
have you considered making TarArchiveEntry implement EntryStreamOffsets ?
I'd be in favour of moving stream implementations to the utils package, in particular if you copy code from the zip package
nitpicking: the methods you've moved to TarUtils probably don't need to be public.

I know you are working on this library in your free time. So I did expect this big change to take some time before it is integrated.

IMHO this would be a nice addition even though I don't expect many people to require random access to a raw tar archive. Most people likely deal with tar archives that have been compressed and so you'd need to decompress it to a temporary file (or memory) for random access.

As you pointed out this only brings better speed for some special cases e.g. random access or somthing like the TarLister where no content is read and therefore the stream needs to read and discard all data.
Specifially for compressed archives it can even take longer depending on the target where the file is decompressed to.

have you considered making TarArchiveEntry implement EntryStreamOffsets ?

Seems like I missed this interface. Since this exactly what I wanted to implement I will change the implementation to implement the EntryStreamOffsets interface.

I'd be in favour of moving stream implementations to the utils package, in particular if you copy code from the zip package

The code I moved out of the ZipFile class is already located in the utils package. Only the Tar specific streams I didn't create in the utils package because in my opinion nobody outside the library should access them and currently no other archive needs similar streams.

nitpicking: the methods you've moved to TarUtils probably don't need to be public.

I agree and will change the code which was moved to the TarUtils to be not public.

I rebased my changes and included a fix for COMPESS-544 in the TarFile implementation

IMO, it's OK to have a random access for Tar - even through it would be slower as we read the tar archive to get the positions of entries. But I think we should hear more voice from others about this idea, cause this is a big change and tar archives are not designed to have a random access.
@theobisproject And as you said, there are still some work(e.g. the refactor of the duplication) to do.

Is anybody able to give me an information how we will progress with this change?
As I currently understand you wanted to hear for more feedback about this changes. Since I will have to do quite some work with the removal of code duplication I'd like to know how long you are willing to wait for feedback.
Also it would be good to get a review of the current state of the changes to guide me into the right direction with the refactorings which need to be done.
I will keep backporting changes from master regarding the TarArchiveInputStream and fix bugs found in the implementation in the meantime since I would like to avoid heading into the wrong direction with any further changes.

Hi @theobisproject
I have started a thread in mailing list about this.

Since I will have to do quite some work with the removal of code duplication I'd like to know how long you are willing to wait for feedback.

I'm hoping to have this change dealed within version 1.21.
Thanks for your great work once again.

In the SparseFilesTest extracting of sparsefile-0.1 in pax_gnu_sparse.tar is skipped because of problems with tar on Ubuntu 16.04. I tested this on Ubuntu 18.04 and everything worked fine. Should we reenable extracting of the file?

+1, if that works with newer versions. Would be good to leave a NOTE/comment somewhere though, in case the test fails again. Even better if we were able to pinpoint what broke it in Ubuntu 16.04 (but can be done later :+1: )
To keep this PR simpler, we can leave as-is, and create a new JIRA to follow-up on this.

In the SparseFilesTest extracting of sparsefile-0.1 in pax_gnu_sparse.tar is skipped because of problems with tar on Ubuntu 16.04. I tested this on Ubuntu 18.04 and everything worked fine. Should we reenable extracting of the file?

Ah. I missed this in my last reviews. It's wired. :)
I tested it on Ubuntu 18.04 and it do works now. That test was failed on Ubuntu 16.04 but unfortunly I don't have a Ubuntu 16.04 now. Agree with @kinow that we can leave it as-is and have it in a separate PR.

@kinow Thank you for your feedback!

In the SparseFilesTest extracting of sparsefile-0.1 in pax_gnu_sparse.tar is skipped because of problems with tar on Ubuntu 16.04. I tested this on Ubuntu 18.04 and everything worked fine. Should we reenable extracting of the file?

+1, if that works with newer versions. Would be good to leave a NOTE/comment somewhere though, in case the test fails again. Even better if we were able to pinpoint what broke it in Ubuntu 16.04 (but can be done later 👍 )
To keep this PR simpler, we can leave as-is, and create a new JIRA to follow-up on this.

Ah. I missed this in my last reviews. It's weird. :)
I tested it on Ubuntu 18.04 and it do works now. That test was failed on Ubuntu 16.04 but unfortunly I don't have a Ubuntu 16.04 now. Agree with @kinow that we can leave it as-is and have it in a separate PR.

I can create a new JIRA and fix this on master next weekend if nothing get's in my way.

@theobisproject , @PeterAlfredLee , my only other comment is about the name TarFile. Is there any risk in using this class name, with a feature that is not part of the tar format (I don't know the format well enough, but I think you mentioned it in your e-mail to the mailing list Lee?)?
I mean, could it be that in the future we may need to create a TarFile, that doesn't/cannot support the random read, and in which case we would have to find another name?

I don't think there is any risk even that the random access is not supported by the format but emulated by the implementation. You still can use the TarFile class to read the content sequentially since the order of the entries is preserved. Also this naming would be consistent with the already exisiting ZipFile implementation.
From a performance point of view the overhead needed to allow the random access is as small as possible since only the headers of the entries are read (excluding some special cases with e.g. long filenames where the information is stored in a different entry) and all file data is jumped over by setting the position in the file to the start of the next header. My testing showed the TarFile and TarArchiveStream performance is equivalent for sequential access. The performance gain for accessing a single entry in the TarFile is huge because the TarArchiveStream needs to read and skip all data until it reaches the entry.
If you would like some numbers for some cases feel free to name them. I can create some benchmarks and share them with you.

My testing showed the TarFile and TarArchiveStream performance is equivalent for sequential access. The performance gain for accessing a single entry in the TarFile is huge because the TarArchiveStream needs to read and skip all data until it reaches the entry.

If you would like some numbers for some cases feel free to name them. I can create some benchmarks and share them with you.

That's interesting. Would you please upload the tests so I can have a look?

The benchmark was added to the https://github.com/bodewig/commons-compress-benchmarks repository for easier setup.
package de.samaflost.commons_compress.tar;

import org.apache.commons.compress.archivers.tar.TarArchiveEntry;
import org.apache.commons.compress.archivers.tar.TarArchiveInputStream;
import org.apache.commons.compress.archivers.tar.TarFile;
import org.apache.commons.compress.utils.IOUtils;
import org.openjdk.jmh.annotations.Benchmark;
import org.openjdk.jmh.annotations.Fork;
import org.openjdk.jmh.annotations.Measurement;
import org.openjdk.jmh.annotations.OutputTimeUnit;
import org.openjdk.jmh.annotations.Scope;
import org.openjdk.jmh.annotations.State;
import org.openjdk.jmh.annotations.Warmup;
import org.openjdk.jmh.util.NullOutputStream;

import java.io.IOException;
import java.io.InputStream;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;
import java.util.concurrent.TimeUnit;

@State(Scope.Benchmark)
@Fork(1)
@OutputTimeUnit(TimeUnit.SECONDS)
@Measurement(iterations = 10)
@Warmup(iterations = 10)
public class ReadLargeTarBenchmark {

    private InputStream getLargeTarStream() throws IOException {
        return Files.newInputStream(getLargeTarPath());
    }

    private Path getLargeTarPath() {
        return Paths.get("path-to-file");
    }

    private void readEntry(final InputStream inputStream) throws IOException {
        IOUtils.copy(inputStream, new NullOutputStream(), 8192);
    }

    @Benchmark
    public void readAllEntries_tarFile() throws IOException {
        try (TarFile tarFile = new TarFile(getLargeTarPath())) {
            for (TarArchiveEntry entry : tarFile.getEntries()) {
                try (InputStream entryInput = tarFile.getInputStream(entry)) {
                    readEntry(entryInput);
                }
            }
        }
    }

    @Benchmark
    public void readAllEntries_tarStream() throws IOException {
        try (TarArchiveInputStream tarIn = new TarArchiveInputStream(getLargeTarStream())) {
            TarArchiveEntry entry;
            while ((entry = tarIn.getNextTarEntry()) != null) {
                readEntry(tarIn);
            }
        }
    }

    @Benchmark
    public void readFirstEntry_tarFile() throws IOException {
        try (TarFile tarFile = new TarFile(getLargeTarPath())) {
            try (InputStream entryInput = tarFile.getInputStream(tarFile.getEntries().get(0))) {
                readEntry(entryInput);
            }
        }
    }

    @Benchmark
    public void readFirstEntry_tarStream() throws IOException {
        try (TarArchiveInputStream tarIn = new TarArchiveInputStream(getLargeTarStream())) {
            tarIn.getNextTarEntry();
            readEntry(tarIn);
        }
    }

    @Benchmark
    public void readSecondEntry_tarFile() throws IOException {
        try (TarFile tarFile = new TarFile(getLargeTarPath())) {
            try (InputStream entryInput = tarFile.getInputStream(tarFile.getEntries().get(1))) {
                readEntry(entryInput);
            }
        }
    }

    @Benchmark
    public void readSecondEntry_tarStream() throws IOException {
        try (TarArchiveInputStream tarIn = new TarArchiveInputStream(getLargeTarStream())) {
            tarIn.getNextTarEntry();
            tarIn.getNextTarEntry();
            readEntry(tarIn);
        }
    }

    @Benchmark
    public void readLastEntry_tarFile() throws IOException {
        try (TarFile tarFile = new TarFile(getLargeTarPath())) {
            try (InputStream entryInput = tarFile.getInputStream(tarFile.getEntries().get(tarFile.getEntries().size() - 1))) {
                readEntry(entryInput);
            }
        }
    }

    @Benchmark
    public void readLastEntry_tarStream() throws IOException {
        try (TarArchiveInputStream tarIn = new TarArchiveInputStream(getLargeTarStream())) {
            tarIn.getNextTarEntry();
            tarIn.getNextTarEntry();
            tarIn.getNextTarEntry();
            readEntry(tarIn);
        }
    }
}

This is the result on my machine (Windows 10, Java 11.0.9, File on SSD) with the testfile containing 3 times the Ubuntu 20.04 Desktop image.
Benchmark                                         Mode  Cnt  Score   Error  Units
ReadLargeTarBenchmark.readAllEntries_tarFile     thrpt   10  0,228 ± 0,003  ops/s
ReadLargeTarBenchmark.readAllEntries_tarStream   thrpt   10  0,256 ± 0,002  ops/s
ReadLargeTarBenchmark.readFirstEntry_tarFile     thrpt   10  0,680 ± 0,010  ops/s
ReadLargeTarBenchmark.readFirstEntry_tarStream   thrpt   10  0,766 ± 0,006  ops/s
ReadLargeTarBenchmark.readLastEntry_tarFile      thrpt   10  0,689 ± 0,006  ops/s
ReadLargeTarBenchmark.readLastEntry_tarStream    thrpt   10  0,127 ± 0,001  ops/s
ReadLargeTarBenchmark.readSecondEntry_tarFile    thrpt   10  0,690 ± 0,012  ops/s
ReadLargeTarBenchmark.readSecondEntry_tarStream  thrpt   10  0,218 ± 0,003  ops/s

I think this demonstrates the strength and weakness of the implementation.
Strength

Performance of random access is constant
Extracting all entries is near to the performance of the TarArchiveStream

Weakness

Only extracting the first entry is slower because of the extra work which is done for the random access

The performance gap should be smaller when the archive is smaller. Feel free to experiment with different tar contents and number of files and report back your result.

That's still a good approach for users that are aware of the weakness of the approach @theobisproject . Your performance test could be incorporated in commons-compress with JMH too, disabled by default. This way in case developers need to work on these classes, they may re-run the test to check for regressions.

I have tested using your bench on my computer and got this :
Benchmark                                        Mode  Cnt   Score    Error  Units
ReadLargeTarBenchmark.readAllEntries_tarFile     avgt   10   5.601 ±  0.061   s/op
ReadLargeTarBenchmark.readAllEntries_tarStream   avgt   10   6.728 ±  0.012   s/op
ReadLargeTarBenchmark.readFirstEntry_tarFile     avgt   10   2.279 ±  0.017   s/op
ReadLargeTarBenchmark.readFirstEntry_tarStream   avgt   10   0.001 ±  0.001   s/op
ReadLargeTarBenchmark.readLastEntry_tarFile      avgt   10   2.266 ±  0.020   s/op
ReadLargeTarBenchmark.readLastEntry_tarStream    avgt   10  13.068 ±  0.030   s/op
ReadLargeTarBenchmark.readSecondEntry_tarFile    avgt   10   2.257 ±  0.012   s/op
ReadLargeTarBenchmark.readSecondEntry_tarStream  avgt   10   0.001 ±  0.001   s/op

The score is average time by setting BenchmarkMode to Mode.AverageTime. I'm testing with linux-4.4.tar, which has a size of 618MB with 55708 entries. I'm testing on my machine : Windows10, SSD, Java 8.
The result is interesting. Seems the tarFile needs an extra 2.65s to read all entries. readAllEntries_tarStream is slower than readAllEntries_tarFile, and readLastEntry_tarStream is even slower than eithor. Will try to figure out what's going on here.

readLastEntry_tarStream is even slower than eithor

My guess would be that the performance characteristic of IOUtils.skip is quite different than the writing to the NullOutputStream in the benchmark.
If someone is only interested in the overhead of the TarFile implementation this benchmark can be added.
@Benchmark
public void tarFileOverhead() throws IOException {
    try (TarFile tarFile = new TarFile(getLargeTarPath())) {
        // Do nothing to only measure the overhead of reading all files header information
    }
}

Hey @theobisproject .
Finally I can carve out some time these days. :(
I'm thinking that we can make this PR merged within this Christmas. WDYT?

Hey @PeterAlfredLee I can invest some time starting from tomorrow. It would be good if you are able to go through the changes once again and comment on the TODOs I left in there.
Regarding the removal of the code duplication in my opinion this would require some major changes to the existing TarArchiveInputStream. So we should decide what we want to do about it in this PR.

So we should decide what we want to do about it in this PR.

Let's start with the easiest one : there are some conflicts now. Could you resolve them? :)
BTW : wish you a great christmas. :-)

So we should decide what we want to do about it in this PR.

Let's start with the easiest one : there are some conflicts now. Could you resolve them? :)

I resolved the conflicts. As far as I could see there where no additional issues fixed in the new commits for the TarArchiveInputStream 😀

BTW : wish you a great christmas. :-)

Also wish you a merry christmas 🎄

The coverage of TarFile looks good enough. Are there any other work left now? @theobisproject

And the japicmp report no BC breaking change.

I've gone through the changes once more and noticed the changes from COMPRESS-559 is missing for the sparse entry test with TarFile.

Are there any other work left now? @theobisproject

I'd like to hear your opinion about my TODO comments in the SparseFilesTest. I left out the canReadEntryData method which the TarArchiveInputStream has but kept the checks in my added tests. I don't think we need this method because the TarFile#getInputStream only takes an instance of TarArchiveEntry. Should I add this method or just remove the commented out code?

I don't think we need this method because the TarFile#getInputStream only takes an instance of TarArchiveEntry.

+1.
The canReadEntryData in TarArchiveInputStream was checking if the entry is a sparse entry or not - cause the sparse entries were not supported. The sparse entry was supported later but we could not remove the canReadEntryData because it's a  API breaking change.
I don't think we need it in TarFile any more.

I removed the code. Now everything I wanted to address is done.

I removed the code. Now everything I wanted to address is done.

Looks good. I will do some final checks these days.

I removed the code. Now everything I wanted to address is done.

Looks good. I will do some final checks these days.

Thanks @theobisproject for your hard work!

Thanks @theobisproject for your hard work!

Thank you all for taking the time to review this change!

Thank you all for taking the time to review this change!


Min / Max Together Break Calendar

When setting the min/max attributes individually, the calendar behaves correctly. When both values are provided, the calendar is blank. See the attached files.
Is there something I'm missing?

It's not the paper-date-picker which is broken, it is your function to get the Date. As far as I know, you can't just simply add a value to the Date() Object. You first need to convert the Date() String into the time in milliseconds and then add your time-value. All this is then wrapped in another new Date() - Function :) (It is called JavaScript :D)
Heres is an example to get the Date value seven days from now:
maxdate: {
    type: Date,
    value: function() {
        // 1000 milliseconds = 1 second
        // 1 second * 3600 = 1 hour * 24 = 1 day * 7 = 7 Days :D
        return new Date(new Date().getTime()+1000*3600*24*7);
    }
}

The lines causing this (reproducable) bug are the following:
If the min-date is greater than the first of the current month (while at the same time, max-date is in the same month as min-date), the function _withinValidRange() on line #653 will return false, because the validity check function _monthWithinValidRange on line #659 only checks the first and the last of each month if they're within min-date and max-date.
I didn't think of a solution yet, but I hope this helps someone who is able to solve this problem, because I am not that good of a programmer to be able to change this.

My project where I tried to use this component in this way was time sensitive, so I had to find a replacement. This does seem to be an important use case that should be worked out.

Is this still an issue for you @milleraundra?  If so I'll tag it and prioritize it with everything else for our next release into 2.0 since this is a pretty critical one if it's still around.

I am not working with Polymer at this time, so this is not an issue for me anymore. Thanks!


Count motifs in a set of sequences

Given a set of sequences, calculate the number of occurrences of all motifs within a range of length that occur in the input sequences. Return the results as a dictionary.

I would like to work on this issue :)

Go ahead!

I would join @stinea98 with this issue

Sure, added you @lukasheuberger, thanks!

I would like to work on this as well, if possible

This would be our suggestion for a docstring:
def count_motifs(input_sequences: list, min_motif_length: int, max_motif_length: int) -> dict
""" Function that calculates the occurrence of all possible motifs in one or multiple sequences and
returns a dictionary with all motifs within the specified length and their occurrence
Args:
input_sequences (list): list of sequences
min_motif_length (int): minimal length of motif
max_motif_length (int): maximal length of motif
Returns:
motif frequency (dict) with paired data {"motif_seq": frequency }
Raises:
ValueError: input_sequences contains non-standard (ACTG) characters
TypeError: input_sequences is not a list
"""
And this is how we think we'll proceed:

create all possible motifs with lengths in range [a,b], save as list motifs
idea for code:
nucleotides = ["A", "T", "G", "C"]
for i in range(a,b):
motifs = itertools.product(nucleotides, repeat=i)
already add these in a dict with all freq counters = 0

scan all sequences for all motifs and record frequencies
fastest method might be regex:
for motif in motifs:
if motif in sequence:
dict[motif] += 1
-> see https://stackoverflow.com/questions/4901523/whats-a-faster-operation-re-match-search-or-str-find

construct and output dictionary with motif sequences and corresponding frequencies

Hi Stine
The docstring looks good. Regarding the implementation, imagine what would happen if you got b = 20. You will have a much smaller number of motifs actually represented in the sequences than those that are possible for a given length. I would rather count the motifs that DO OCCUR in the sequences themselves. Another comment about non-[ACGT] characters, you may not want the program to quit unless the number of these characters is large. So you could either count them and give more information to the user as to what proportion of characters are not correct, or even do the counting with/without these characters.  Finally, you could take into account either DNA or RNA, in which case you would have to consider U's instead of T's.

Closing this for now as we chose to implement a brute force algorithm for 3' adapter extraction for the meantime.


Remove nodeInfo endpoint from kubelet

/nodeInfo endpoint is added for nodecontroller to pull node info from kubelet.  We need to evaluate if it's still necessary to keep it given this #6005
NodeInfo is also confusing in our api object
// NodeSystemInfo is a set of ids/uuids to uniquely identify the node.
type NodeSystemInfo struct {
...
}

// NodeStatus is information about the current status of a node.
type NodeStatus struct {
	NodeInfo NodeSystemInfo `json:"nodeInfo,omitempty"`
}

// NodeInfo is the information collected on the node.
type NodeInfo struct {
	NodeSystemInfo `json:",inline,omitempty"`
}

@davidopp @bgrant0607 @gmarek

The plan was to get rid of /nodeinfo.
I was also planning to rename type NodeSystemInfo to type NodeInfo, but maybe we should rename the field to NodeSystemInfo instead, since that seems slightly more informative to me.
As part of #2098, I think it would be useful for Kubelet to export its current value of Node - either a copy of the last state sent to apiserver or the most recently updated state that will be next sent to apiserver (or both).

Kubelet is also using the /nodeInfo endpoint:
https://github.com/GoogleCloudPlatform/kubernetes/blob/984bc8d5f6fd235229e8d2b0af029a5d2bf585c0/pkg/client/kubelet.go#L135

IIUC this means we can't get rid of it easily. Do you think it's still worth doing?

@davidopp  If I recall correctly, /nodeinfo endpoint is only used by nodecontroller now, the link is where kubelet expose the endpoint
@gmarek I don't expect much difficulty to remove it.  It's added here #5030 for node controller to fetch node info.  Once you remove the sync_status=true, it should be easy.
I'm not following the thread #2098, but @bgrant0607 are you suggesting we keep exposing node info even if node controller stops probing?  I'm fine with that, but if so, I want to clean up the types I mentioned above, it's really confusing.

No, I was suggesting that the Kubelet expose the same Node API as the apiserver, just for that Kubelet.

@davidopp @gmarek pkg/client/kubelet.go is the Kubelet client. Kubelet isn't using that, it's exporting that for the master.

ok.  @gmarek I'm assigning this to myself for load balance the work.

Yeah, sorry, what I saw was the definition, not another use. Looks like we can remove this.

cc @nikhiljindal re #5475

Closed by  #6702


[Bug] Extra whitespace between lines in DiffView when Show Hidden Symbols is enabled

reproduce patch:
diff --git a/README.md b/README.md
index 50d7525..60ab343 100644
--- a/README.md
+++ b/README.md
@@ -3,8 +3,12 @@
 Opensource Git GUI client.

 ## Highlights

+
+			}
+					}});
+			}
 * Supports Windows/macOS/Linux
 * Opensource/Free
 * Fast
 * English/German/Português/简体中文/繁體中文

I don't understand, did you mean this line?

yes, after disabled Show Hidden Symbols , it will work fine.

I think this is just a issue about layout rounding in Avaloina.

for example, after i move the window from a screen to anthor which has different UI scaling:

But for me, lines indented with tabs will be very noticeably offset, whereas lines indented with spaces or with hidden symbols turned off will not have this problem.

Try to change the monospace font to built-in JetBrains Mono?

Try to change the monospace font to built-in JetBrains Mono?

JetBrains Mono works fine, but others like Dejavu / Consolas / FreeMono all have this issue

I've pushed a commit 9f39a9b2951010634c6b43ab06a721a35bdc28a3 that try to solve this problem.

Although the spacing between the lines is still there, the effect looks good after the background color is filled.

ed7465def5 - enhance: render highlight background manually instead of using TextRunProperties.SetBackgroundBrush(IBrush)

ed7465d - enhance: render highlight background manually instead of using TextRunProperties.SetBackgroundBrush(IBrush)

The offset still exists, and I think it is acceptable not to fix the current effect.


Unicode test correction?

Dunno if this is intended but the test is wrong when compared to byond parity

This is intended. The difference exists here because our strings are encoded in UTF-16 instead of BYOND's UTF-8.
An explanation for this exists in our Differences Between OpenDream and BYOND wiki page.


Allow wildcard domains in SAN fields in certificate manager

This is a bug fix for #3733 (https://redmine.pfsense.org/issues/3733)
This fix now allows the administrator to specify additional wildcard domains in the subjectAlternativeName fields when issuing a new certificate.
This would normally have caused the error message
DNS subjectAltName values must be valid hostnames or FQDNs

although it is valid to place wildcard domains as the subjectAlternativeName extension.

@dachande I don't see an ICLA on file, if you haven't put one in, please do so here:
https://portal.pfsense.org/members/signup/ICLA
If you have, let me know what username it's under.
This no longer merges cleanly, could you please update and re-submit? Then I'll make sure we get it in for 2.3.

I've opened a new pull request @ https://github.com/pfsense/pfsense/pull/1902 on the base of the latest master because I had trouble merging my changes.


ci: move custom actions from personal repo to longhorn/bot

ci: move custom actions from personal repo to longhorn/bot
For https://github.com/longhorn/longhorn/issues/4159
Signed-off-by: Yang Chiu<EMAIL_ADDRESS>

I don't think we need node_modules to commit, but rather it's just for runtime.

The github action code flow will download the action repo and run it directly as a package/binary. It wouldn't execute npm install for you so the package dependencies needed to be committed too. Like https://docs.github.com/en/actions/creating-actions/creating-a-javascript-action#commit-tag-and-push-your-action-to-github mentioned.


[SPARK-31867][SQL][FOLLOWUP] Check result differences for datetime formatting

What changes were proposed in this pull request?

TBD
Why are the changes needed?

Does this PR introduce any user-facing change?

How was this patch tested?

Test build #123560 has started for PR 28736 at commit a8f7131.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/28183/
Test PASSed.

Test build #123560 has finished for PR 28736 at commit a8f7131.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/123560/
Test FAILed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/28185/
Test PASSed.

Test build #123562 has started for PR 28736 at commit 54e70b6.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/28186/
Test PASSed.

cc @cloud-fan @maropu @MaxGekk thanks

Test build #123562 has finished for PR 28736 at commit 54e70b6.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

thanks, merging to master/3.0!

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/123562/
Test PASSed.


Inventory Locks show up twice in Tinkers' Construct GUI

Describe the bug
When using certain Tinkers' Construct GUIs the locks will appear more than once (they are doubled):

After speaking with the Tinkers' dev, he suspects the locked slots are hardcoded location in all UIs, whether it has slots or not. If you iterate the player inventory slots instead of drawing at a constant location it should work. The GUIs in question are actually using 3 sets of inventory slots: left, middle, and right
To Reproduce
Steps to reproduce the behavior:

Open up Tinker's Station or Tinker's Anvil
Observe inventory slot locks are now doubled

Expected behavior
To show only 1 set of locked slots
Versions (please complete the following information):
I am currently using the mod in 1.18.2, but this has been an issue since 1.18.1 so you can use that version to test also.

Forge version: 40.0.45
Mod Version: 3.1.0

The slot positions are not hardcoded, and very much depends on the menu and positions obtained through the gui.
https://github.com/kirderf1/InventoryFree/blob/de4274a2fd57f8d354e5d0db4add04ffb77ba8c3/src/main/java/kirderf1/inventoryfree/client/LockOverlay.java#L70
The icons are drawn on through this widget component, which is added to every container screen on initialization.
It seems like tinkers screen is made modular with multiple screens combined into one. For some reason, they all get the same container, meaning that you'll find normal slots for all of them if you check screen.getMenu().
For example, when checking this out in debug mode, the overlay was drawn for TinkerStationScreen and TinkerStationButtonsScreen. I'd expect only the former to have a menu with slots, but instead both seem to have the same menu, so both were rendered.
My initial thought is that tinkers' construct should use some dummy container menu for their module screens such as TinkerStationButtonsScreen. However, I can't really say for sure without knowing the reason behind how they designed their screens.
@KnightMiner do you have any insight on this?

I have no idea the reason behind the screens honestly, all our UI code is pretty old and I am not the maintainer for it, so it really needs a rewrite.
That said, don't screens have a method to get slots so you don't have to get them from the container? Otherwise we would be rendering the inventory items in all our different components. I would suggest checking which slot list is used to print the inventory items in the base UI code and using the same list.

Nope, slots are gotten from the container as far as I can see. Rather, slots are handled in functions such as screen.render() and screen.mouseClicked(), and the parent screen for these module screens does not appear to call these functions anywhere.
Instead, it makes calls to functions defined in ModuleScreen. Some of these functions are overridden as is, while others redirect to screen functions such as to screen.renderBg() or screen.renderLabels(), but none to screen.render() or screen.mouseClicked().
In addition, widgets are normally rendered in the screen.render() function, which is why this issue didn't affect for example InfoPanelScreen, even if it has the same issue with its container. The reason that this issue shows up for TinkerStationButtonsScreen is that its superclass SideButtonsScreen overrides screen.renderBg() to draw all widgets in that function.
I'm now very much of the impression that these module screens need to be better integrated with regular screen functionality, in addition to using more representative containers. (if they even need to be container screens at all!)

I am in the process of making contributions to Tinkers' construct targeting 1.18.2, that should fix the issue.

I just want to let you know that this bug occurs in 1.16.5. I don't know if you're planning a fix for 1.16.5, but again, wanted to let you know.

The bug comes from an improper implementation of the gui side bars in tinkers construct. I'm in the process of undoing it for the latest version of tinkers construct (currently at a standstill as I'm waiting for feedback on https://github.com/SlimeKnights/TinkersConstruct/pull/4841). Because of this, I will not attempt to fix it for older minecraft versions.

Hey @kirderf1
Knightminer sent me the tcon jar file with the recent PR that you setup for them. Is that designed to be a complete fix or does it still require some more work to remove the extra locks in the inventory? Currently, the extra locks are still appearing for me:

Thanks for all the hard work you've put into this so far!

There are currently two PRs that you might be talking about, SlimeKnights/TinkersConstruct#4988 and SlimeKnights/TinkersConstruct#4990. Only the latter fixes this specific issue. Maybe the jar was made from the first of the two PRs?

Actually nevermind, it's not from the first of those two PRs. It was probably SlimeKnights/TinkersConstruct#4841. While this PR itself is not recent, it was merged recently.

The fix to this issue has now been merged into SlimeKnights/TinkersConstruct, and should be present in its next release.


Fix cutorch.getStream()

state->numUserStreams does not include the NULL stream, which is stored
in res->streams[i]

Thanks!


macOS filesystems can be case insensitive, editor should also warn like Windows on case mismatch

I found an irritating bug that took a long time to track down. I was able to make a minimal reproducible project. The project would work when launching in Godot but crash immediately when launching on the exported Mac app.
Suppose we have a script like this:
# res://base/Bar.gd

extends Node

and another file
# res://Foo.gd

extends 'res://Base/Bar.gd'

Notice the capitalization mistake? Neither did I. Godot, I guess, will ignore capitalization in directories. The project runs just fine. It throws no errors. But when exporting to Mac, it will not launch. Caused me a lot of frustration.
Suggestions for a fix: make Godot case-sensitive with directories. Or at least throw a warning when capitalization does not match.
Edit: these tests were done on macOS.

It's not Godot ignoring case, it's Windows (which is why our issue template asks you for your OS... please don't make us guess it).

Or at least throw a warning when capitalization does not match.

It should already do that normally.

My bad @akien-mga. I’m on macOS. Which is why it’s so bizarre that this works when running within Godot but crashes the exported app.
I got no sort of warning in the Godot debugger about capitalization. It works flawlessly.

Yeah the warning was only implemented for Windows, as macOS is supposed to be case sensitive. Is your macOS partition configured to be case insensitive?

@akien-mga So bizarre! Been using macOS for many years and have never noticed that the default configuration for APFS is case-insensitive. What I don't understand is why this would then not work on the exported app.
Considering that this is the case, I think the warning should also be implemented on macOS to avoid this sort of confusion.
Thanks!

"APFS [...] is available in case-sensitive and case-insensitive variants on macOS, with case-insensitive being the default." According to Apple's developer website

Indeed, something similar to this should be implemented in drivers/unix/file_access_unix.cpp (but only for #ifdef OSX_ENABLED):
https://github.com/godotengine/godot/blob/b902a2f2a7438810cdcb053568ed5c27089b1e8a/drivers/windows/file_access_windows.cpp#L90-L110

I implemented the warning, but I don't have a mac right now to check if it works properly. I will test on one this afternoon and make a PR if it works as intended.


小米笔记本pro，10.14.2触摸板不能用。

小米笔记本pro，10.14.2触摸板不能用。重启也无法解决。

Did you tried to execute sudo kextcache -i / and reboot after that? Helped me.

Did you tried to execute sudo kextcache -i / and reboot after that? Helped me.

谢谢你，解决啦。


Update 2.balance-syntax.md

expose BALANCE DATA RESET PLAN in balance syntax

triggered during https://github.com/vesoft-inc/nebula/issues/2997


Redundant paragraph.

In the following section:
https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-health-extension?tabs=rest-api#when-to-use-the-application-health-extension
two paragraphs that follow each other contain almost the same wording. The two paragraphs are:
The Application Health extension is deployed inside a Virtual Machine Scale Set instance and reports on VM health from inside the scale set instance. You can configure the extension to probe on an application endpoint and update the status of the application on that instance. This instance status is checked by Azure to determine whether an instance is eligible for upgrade operations.
The Application Health Extension is deployed inside a Virtual Machine Scale Set instance and reports on application health from inside the scale set instance. The extension probes on a local application endpoint and will update the health status based on TCP/HTTP(S) responses received from the application. This health status is used by Azure to initiate repairs on unhealthy instances and to determine if an instance is eligible for upgrade operations.

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

ID: 9f8c26a4-8b44-6254-3446-bb9df24550ea
Version Independent ID: a559b176-f581-38ab-92e7-a597d8c42f51
Content: Use Application Health extension with Azure Virtual Machine Scale Sets (preview) - Azure Virtual Machine Scale Sets
Content Source: articles/virtual-machine-scale-sets/virtual-machine-scale-sets-health-extension.md
Service: virtual-machine-scale-sets
Sub-service: extensions
GitHub Login: @ju-shim
Microsoft Alias: jushiman

@stypich
Thanks for your feedback! We will investigate and update as appropriate.

Hi @stypich
Yes, the two paragraphs are similar in meaning. The first paragraph provides a general overview of the Application Health extension and its purpose, while the second paragraph provides more specific details on how the extension works and what it is used for. The second paragraph also mentions the types of probes that the extension uses to update the health status of the application.
if there are any further questions regarding the documentation, please tag me in your reply and we will be happy to continue the conversation.


scales to fit the size of the editor

Tell me, is it possible to make it so that when you insert an image, it scales to fit the size of the editor?

Hi,
That's really a CKEditor-specific question so you should better ask it in a CKEditor forum, not in a django-ckeditor forum. Thanks.


mySampleDatabase?

Step.4 in Connect to the server as server admin
https://docs.microsoft.com/en-us/azure/sql-data-warehouse/load-data-wideworldimportersdw#connect-to-the-server-as-server-admin
It must be SampleDW?

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

ID: d26e70c3-2769-5b47-2bda-8a4a7f0239d0
Version Independent ID: 558a36bd-e151-1e4c-4427-fc52eb2d91e3
Content: Tutorial: Load data to Azure SQL Data Warehouse
Content Source: articles/sql-data-warehouse/load-data-wideworldimportersdw.md
Service: sql-data-warehouse
GitHub Login: @Ckarst
Microsoft Alias: cakarst

@kazshi Thanks for the feedback! I have assigned the issue to the content author to evaluate and update as appropriate.

@kazshi The tutorial uses a database name called "SampleDW" but if you happen to create an empty DW instance that is under a different name, you will need to update all subsequent steps where 'SampleDW' is used for the data loading steps, with the specific name that you happen to use. The important part is that you create an empty database so that the data load steps complete successfully.
An example, SampleDB will need to be changed to refelct the name you used when you created the DW instance. If you have any doubts, recreate the data warehouse instance using the naming convention used in the tutorial.

Thanks for your detailed explanation. I think I understand now - I thought the 'mySampleDatabase' is actual sample database name and just wondering why it's a different name from the tutorial.


card: use boolean to track enabled state

Replaces the capnp object for checking the enabled state of carControl with a boolean variable, as only the enabled state is needed for now. this change simplifies the code and improves readability.

Doesn't make any difference


Added autofocus and enter button support to HDFS proxy user modal

This JavaScript tweak gives focus to the text input after clicking on the "Change User" button in the HDFS Browser, so the user doesn't have to click in the box before typing.
Additionally, while the text input is focused, this change gives the Enter key the same behavior as clicking the submit button, so the user can simply type the proxy user name and press enter rather than having to click on the submit button.

Thanks for the pull request!
@kunkun-tang does it look good to you?

LGTM. Have you tested the change? @jackrjli

LGTM, could you please add a testing section to your change description?

I tested this change by pasting the modified script into the JavaScript console (both Firefox and Chrome) while on the HDFS browser page and verifying the changes manually. I added this info to the description above.


[CommonHTML/HTML-CSS] in a table, numerator/denominator with line-breaks are left-aligned

(From answering a MathJax User Group posting.)
Within a table, both numerator and denominator of a fraction are left-aligned if they have line-breaks. Only HTML outputs are affected -- the SVG output centers them.
Example:
<math xmlns="http://www.w3.org/1998/Math/MathML" display="block">
  <mtable>
    <mtr>
      <mtd>
        <mfrac>
        <mrow>
            <mrow>
              <mtext mathvariant="italic">aaa</mtext>
            </mrow>
          <mspace linebreak="newline" />
            <mrow >
              <mtext  mathvariant="italic">b</mtext>
            </mrow>
        </mrow>
          <mrow>
              <mrow>
                <mtext  mathvariant="italic">aa</mtext>
              </mrow>
            <mspace linebreak="newline" />
              <mrow>
                <mtext  mathvariant="italic">b</mtext>
              </mrow>
          </mrow>
        </mfrac>
      </mtd>
    </mtr>
  </mtable>
</math>

The issue1539 branch of my fork of MathJax resolves the issue.

==> Merged

==> In testsuite
MathMLToDisplay/Topics/LineBreak/issue1539.html


New category: Sustainability

As the creator of Beacon, it'd be brilliant to see more information about sustainability within these resources.
Happy to put a list together and add them but thought I'd check to make sure there's some demand for it first.

@ChrisButterworth, I'm a fan of the Beacon. Thank you for your efforts.
I like the idea and it would be great if you could help out.
Happy to see the list when it's ready. Thanks!


bug: sysupgrade from relative path doesn't work

repro:
upload thingino-jooan_a6m_atbm6012bx.bin to /tmp
ssh to device
# cd /tmp
tmp# sysupgrade thingino-jooan_a6m_atbm6012bx.bin
Upgrade from a local file
Cannot find file thingino-jooan_a6m_atbm6012bx.bin

this works, using full path:
tmp# sysupgrade /tmp/thingino-jooan_a6m_atbm6012bx.bin
Upgrade from a local file
Upgrading from a provided file
Stop services
...etc

this is how linux works. working directory is not a part of PATH. prefix file name with ./ to make it relative.

root@ing-jdpan01--4a32 mmcblk0p1# sysupgrade ./thingino-wyze_cp2-update.bin
Upgrade from a local file
Cannot find file ./thingino-wyze_cp2-update.bin

root@ing-wyze-c3-bdca ~# touch aaa
root@ing-wyze-c3-bdca ~# sysupgrade ./aaa
Upgrade from a local file
Cannot find file ./aaa in /tmp/sysupgrade

the script is copied to run from /tmp/sysupgrade/ but the fw file stays in its original directory hence ./ is not equal to pwd anymore. it works for full path but not for relative.

i've changed order of validation and isolation, made it move the original fw file to working directory prior to checking. also added upgrading of sysupgrade script from github. please test and report back.

root@ing-wyze-c3-bdca ~# touch aaa
root@ing-wyze-c3-bdca ~# sysupgrade ./aaa
Found working directory /tmp/sysupgrade
Upgrade from a local file
Switching to working directory /tmp/sysupgrade
/tmp/sysupgrade
Updating self.
curl -fL# -o /tmp/sysupgrade/sysupgrade "https://raw.githubusercontent.com/themactep/thingino-firmware/refs/heads/master/overlay/lower/usr/sbin/sysupgrade"
################################################################################################################# 100.0%
curl -fL# -o /tmp/sysupgrade/sysupgrade-stage2 "https://raw.githubusercontent.com/themactep/thingino-firmware/refs/heads/master/overlay/lower/usr/sbin/sysupgrade-stage2"
################################################################################################################# 100.0%
chmod: sysupgrade-stage2: No such file or directory
Found working directory /tmp/sysupgrade
Upgrade from a local file
Switching to working directory /tmp/sysupgrade
/tmp/sysupgrade
Running updated script.
Upgrading from a provided file
Unknown file

please test and confirm that it works now

tested, confirmed working with local path now, closing issue.


Remove calls to Dir.chdir

Your checklist for this pull request
🚨Please review the guidelines for contributing to this repository.

[x] Ensure all commits include DCO sign-off.
[x] Ensure that your contributions pass unit testing.
[x] Ensure that your contributions contain documentation if applicable.

Description
In multithreaded environment Dir.chdir changes current directory of all process' threads, so other threads might misbehave.
Base#chdir, Base#with_working and Base#with_temp_working were left intact, cause they are not used internally, so it's an explicit user decision to use them.
Fixes https://github.com/ruby-git/ruby-git/issues/355

cc @jcouball

@fxposter thank you very much for this PR and #675
This PR is still failing for JRuby on Windows. I faced the same problems when trying to solve these problems and more (#355, #363, #441, #495, #516, #574).
I almost have that solution over the finish line with #617. This is (to the best I can tell) only missing one JRuby issue which is tracked in ruby/jruby#7515.
I am wondering if you gave #617 a try? I would love feedback on that one.

I'll take a look, but do you really believe that you need to have "process execution" abstraction instead of using the existing ones? :)
PS. I'll get to a windows machine on the weekend, will try to check what is going on there, cause open3 specifically have code that should handle chdir/etc: https://github.com/ruby/open3/blob/master/lib/open3/jruby_windows.rb#L81

@jcouball can you review and run tests again?
I have found what was wrong with windows - due to the fact that tests use Dir.chdir themselves - when we passed chdir to open3 it didn't "inherit" it from the current Dir.chdir call that was done by tests:
# imagine that we run this script in dir /x

Dir.chdir('/y') {
  Dir.chdir('.') {
    Open3.capture2('ls') # will show files in /y
  }
}

Dir.chdir('/y') {
  Open3.capture2('ls', :chdir => '.') # will show files in /x
}

to avoid that I do :chdir => File.expand_path('.') which properly expands relative paths.

Also, before merging: I rewrote code like
Dir.chdir(dir) { files = Dir.glob('**/*').select { |f| File.file?(f) } }

to
files = Dir.glob('**/*', :base => dir).select { |f| File.file?(f) }

The end result is the same, but :base is only supported since ruby 2.5. If that is a problem - I can rewrite the code without using :base keyword argument.

Thanks @fxposter, we are getting very close! Only one error left in the Windows JRuby build.
I see that the failure is in test_tree_ops.rb in a with_index block.
My first comment is that I am not a fan of this tests in this file since it is just one big test case with a lot of state changing and asserts sprinkled through the method. An isolated, minimal, failing test case would be ideal but not necessary.
The first think I would try is to use Git::Base#with_temp_index instead of Git::Base#with_index. I see that there is code in that method to workaround some problem in JRuby when using Tempfile exactly the way the test does.
I honestly don't understand why the with_index block is being used in the first place. Maybe to use a "throw away" index?
Beyond that, maybe something related to the changes you are making might stick out to you.
I have changed the configuration of the GitHub actions for the CI build so that the build will run when you push changes. This way you won't have to wait for me or another contributor for feedback.

:(
I hoped that the last change fixes everything on jruby on windows. The tricky part here is that locally some tests are always failing for me on both Mac and Windows (while they pass in CI), so I assumed I fixed everything.
I'll try to focus on the failing one, as I have access to windows machine during the weekend.

Regarding your comments about which Ruby release should be supported, here is release information for some Ruby releases from the Ruby Maintenance Branches page:
Ruby 3.0
status: security maintenance
release date: 2020-12-25
normal maintenance until: 2023-04-01
EOL: 2024-03-31 (expected)

Ruby 2.7
status: eol
release date: 2019-12-25
normal maintenance until: 2022-04-01
EOL: 2023-03-31

Ruby 2.6
status: eol
release date: 2018-12-25
normal maintenance until: 2021-04-01
EOL: 2022-04-12

Ruby 2.5
status: eol
release date: 2017-12-25
normal maintenance until: 2020-04-01
EOL: 2021-04-05

I think for this PR we could change the required version of Ruby in the gemspec to 2.5.
I notice that the CI build only goes back to 2.7 so there should probably be a build added for MRI 2.5 on Linux at least.
It would be my intention to follow up with an explicit policy that this gem follows for supported Ruby version in a separate PR. The policy could be something like "Support all non-EOL Ruby minor versions" (currently 3.0, 3.1, and 3.2). We could possibly include the latest EOL minor version as well (which would add 2.7 until 3.0 is EOL'd in March 2024).

The tricky part here is that locally some tests are always failing for me on both Mac and Windows (while they pass in CI)

Huh, that shouldn't be and is concerning. If the CI builds pass and the local build works for me (which it does), they I'd accept the pull request. If you want to share details of your failure(s) we can try to debug. I am on Mac so that is where I can be most helpful.

sure. this is what I get on my mac by default (probably it's related to my user git's config, but I didn't try to debug that yet, since it failed on master as well):
 $ rake
ruby bin/test
Loaded suite bin/test
Started
E
=====================================================================================================================================================================================================================================================
Error: test_push(TestRemotes):
  Git::FailedError: git '--git-dir=/private/var/folders/m3/lnm6c86s2m99_bx5n8c4j_ww0000gn/T/d20231118-67431-4pwmvb/local/.git' '--work-tree=/private/var/folders/m3/lnm6c86s2m99_bx5n8c4j_ww0000gn/T/d20231118-67431-4pwmvb/local' '-c' 'core.quotePath=true' '-c' 'color.ui=false' 'push' 'testrem'  2>&1
  status: pid 70744 exit 128
  output: "fatal: You are pushing to remote 'testrem', which is not the upstream of\nyour current branch 'master', without telling me what to push\nto update which remote branch.\n"
/Users/pavelf/Projects/github/ruby-git/lib/git/lib.rb:1234:in `command'
/Users/pavelf/Projects/github/ruby-git/lib/git/lib.rb:996:in `push'
/Users/pavelf/Projects/github/ruby-git/lib/git/base.rb:396:in `push'
/Users/pavelf/Projects/github/ruby-git/tests/units/test_remotes.rb:226:in `block in test_push'
     223:       assert(!rem.status['test-file1'])
     224:       assert(!rem.status['test-file3'])
     225:
  => 226:       loc.push('testrem')
     227:
     228:       assert(rem.status['test-file1'])
     229:       assert(!rem.status['test-file3'])
/Users/pavelf/Projects/github/ruby-git/tests/test_helper.rb:68:in `block in in_temp_dir'
/Users/pavelf/Projects/github/ruby-git/tests/test_helper.rb:67:in `chdir'
/Users/pavelf/Projects/github/ruby-git/tests/test_helper.rb:67:in `in_temp_dir'
/Users/pavelf/Projects/github/ruby-git/tests/units/test_remotes.rb:205:in `test_push'

@fxposter what is the output of
git --version && git config --list --show-origin

Looks like you might have push.default set to upstream. I'll prepare a PR to explicitly set the push.default for this test.

color.ui=auto
push.default=tracking
push.autosetupremote=true
branch.autosetuprebase=always
init.defaultbranch=master

and lots of others, probably unrelated

It looks like push.default=tracking gives the same result as push.default=upstream.

@fxposter if you rebase with master, test_push(TestRemotes) should pass now.


Wildcard search from the console works in a weird way...

Wildcard search from the console does not work as it should
scss-lint app/**/*.scss

says

No such file or directory - app/**/*.scss

The same if I include the filename in quotes.
If I remove the extension it works, but checks against all the files I have: js, html, whatsoever.
But if I specify the same in .scss-lint.yml it works fine, so the file with just the following
scss_files: 'app/**/*.scss'

works as it should.
MacOS 10.11.5 El Capitan
Ruby version: 2.0.0p648
scss_lint version: 0.49.0

Hey @smnbbrv,
This has nothing to do with SCSS-Lint (though I can appreciate this behavior is confusing). When you use a globs in your shell, it is expanded by your shell and then passed as arguments to the program you are executing.
It is likely that the shell you are using is not interpreting ** the way you expect. You can quickly test to see what a glob expands to by passing that pattern as an argument to the echo command:
> echo my/glob/pattern/*.scss
my/glob/pattern/one.scss my/glob/pattern/two.scss ...

Hope that helps!

I had a similar problem with the typescript:
tslint  -t verbose app/**/*.ts

Changing it to
tslint  -t verbose 'app/**/*.ts'

solved the problem. I am pretty sure that the problem is the same; but changing it to string did not help in the case of scss-lint. Could it maybe be implemented the way tslint does it?

SCSS-Lint doesn't treat * as a wildcard because it is a valid character in a file name.
While perhaps odd, you can totally have a file called *.scss, or a directory called ** (and thus a file path **/*.scss).
Therefore we leave glob expansion to the shell so that you can fully specify whether you want a wildcard or a literal string for the path.

but the wildcards work absolutely fine when I use them from the .yml file. There is definitely something different used there, although the meaning is the same. Shouldn't that be fixed?


Observable u in plotter and cleanup

This PR cleans up all lift(f::Function,vars) to @lift($var1 ... # do stuff ... $var2). Further, u becomes an Observable, which enables live plotting. Added a live plotting example in the ferrite-examples folder, its a bit cheated tho, since I sleep before every new timestep, because the workload is too small and without sleep the plot would just update all the time

.
implements one needed interface for  https://github.com/koehlerson/FerriteVis.jl/issues/2
Also did some quick and dirty interface for timeseries given as a Vector{Vector{T}} because I need this for myself :trollface:

Probably we should also provide a dispatch for solutionplot with a timeslider

Docs update

api reference
tutorial page: what should we include? I don't know what makes sense to show and what to cut out, since the page loading is too long currently
I included in the advanced topic section a gif, which is fairly large (2.7mb or so) don't know how to create such a gif on the fly (because the gif should stress the fact that the simulation is running while the plot updates)
updated the README, needs feeback

Observable u

prototype that will change later to observable fesolution
important aspect of Observables, they work with setindex! so plotter.u[] .= u_new does not trigger, while plotter.u[] = u_new does since the latter is an allocation shit show I did the workaround plotter.u[] .= u_new; notify(plotter.u)
live plotting examples

Time dependent plots

included a time slider for ferriteviewer if plotter and a Vector{Vector} is given
should solutionplot become a similar dispatch?

So I guess once we move the gif this one is ready? :)


Add eslint and fix issues

What issues does this issue refer to? :P

Ah, I suppose linting issues.

yup


feat: add ability to pass NestApplicationContextOptions to CommandFactoryRunOptions

Also made some changes in getOptions method for proper options parse.
Related to https://github.com/jmcdo29/nest-commander/issues/852

Okay, code looks good. Apologies for the delay on the review. Can you add a changeset as a patch (run pnpm changeset and follow the wizard) o that the automated deployment process can be kicked off?

Okay, code looks good. Apologies for the delay on the review. Can you add a changeset as a patch (run pnpm changeset and follow the wizard) o that the automated deployment process can be kicked off?

Looks like, i done this


feat: add serve-blocks

Should we rename serve-blocks to node-sync or something similar? Sync makes more sense for me than serve.


Add cargo upgrade

Problem
cargo-edit's cargo update is having problems lately.
It should be uplifted to cargo itself. It's a really useful feature
Proposed Solution
No response
Notes
If someone could mentor me I could try to tackle this.

Thanks for the suggestion. If I understand correctly, this is kinda a duplicate of https://github.com/rust-lang/cargo/issues/10498?

Sorry for the duplicate, there are a lot of issues! If this is currently being worked on that's fine, else I could work on this.

The reason I've not been focusing on cargo-upgrade is because that time would be better spent on that issue to merge its behavior.
Things keep coming up so I've not finished it yet. If you'd like to finish it, go ahead. The other issue has notes on the design the cargo team decided on. On our github wiki you can find office hours to talk to us, in addition to on issues/prs and zulip.

@epage on second thought this seems too daunting for a first contribution.


 I think that indicates that a previous test leaked a subprocess?
 Diffing the env from the previous build, the changes are
distributed      2.0.1 -> 2.11.0
msgpack-python   0.6.2 -> 1.0.0

Unfortunately, that jump in distributed is quite large :(
I haven't been able to reproduce locally yet, but I'm running the full test suite a few times with that 3.7 env to try.


Jpalvarezl/streaming deserialization encode

Description
Please add an informative description that covers that changes made by the pull request and link all relevant issues.
If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
All SDK Contribution checklist:

[ ] The pull request does not introduce [breaking changes]
[ ] CHANGELOG is updated for new features, bug fixes or other significant changes.
[ ] I have read the contribution guidelines.

General Guidelines and Best Practices

[ ] Title of the pull request is clear and informative.
[ ] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[ ] Pull request includes test coverage for the included changes.

Local change to tsp

I think this logic could be moved to typespec-java

Code in PR is generated by an older version of typespec-java, that having bugs.
Major one is lack of @Generated annotation on toJson and fromJson method, which causes it be interpretated as "customized method"
https://github.com/Azure/azure-sdk-for-java/blob/jpalvarezl/streaming_deserialization/sdk/openai/azure-ai-openai-assistants/src/main/java/com/azure/ai/openai/assistants/models/ThreadRun.java#L360
One need to either regen those from main branch, or manually add the @Generated annotation.

1 and 2 above would now have https://github.com/Azure/azure-sdk-for-java/pull/39661/commits/10db95987786b245a8c0c138ef530e18da77b95b

3
Codegen has a design issue on nullable. I need to check with Alan/Srikanta.
Current use a partial-update to mitigate https://github.com/Azure/azure-sdk-for-java/pull/39661/commits/abc5ea78391d1fcdb40fee23c8be3a2105354a51

@jpalvarezl
Note that the typespec-java version on your PR is old.
You'd better refresh main, and regen.

Note that tsp-location.yaml on main branch is already different from this PR.


(35) Add Coda finance report

This code will be used to generate a report for the CCS finance system, Coda. For now we have only a handful of submissions and will be running the report manually and passing it on to CCS, hence why it outputs the report as a string (makes it easier to run from the console and get the data out without having to worry about where to store it on the file system, etc). Some of the queries performed against the JSONB columns could also do with indexes, but given the low volume of data, and that we're expecting to change the way entries are stored in the next round of iterations, we can live without them for now.

Approving this so we can test what we have against production data. If changes need to happen, we'll do this later.


EasySass: could not generate CSS file. See Output panel for details.

I'm using Ionic2,,, when I write in .scss file and save changes I got thih error: EasySass: could not generate CSS file. See Output panel for details. and the system create file.css and file.min.css , and I can't apply css to buttons what should I do?

@alshimaa14 without minimum reproducible test repo is difficult to say what is wrong, thanks!

Closing due to inactivity. Please test with latest version and feel free to reopen if still regressions. Also please create minimum reproducible test repo. Thanks!


revert #1460

Revert https://github.com/expo/eas-cli/pull/1460 as this doesn't work with projects with older SDKs.
See https://exponent-internal.slack.com/archives/C017N0N99RA/p1666603376919699

/changelog-entry bugfix Revert using local CLI for expo export (#1460).

/changelog-entry bug-fix Revert using local CLI for expo export (#1460).


Pagination helper

It seems I am writing many boilerplate pagination loops. Maybe this package could provide a pagination helper to do this automatically?
It could help with #815, too, so that we could update pagination helper and users would automatically get benefits of keyset pagination when it is available.

Can you share an example of such boilerplate?

It is already in the repository. The only difference is that I am appending results into a slice and then returning it at the end (instead of printing them out).

Check... But looking at that code it looks like it would mean that each own endpoint (type) would need it's own custom function (loop). I'm not too excited (read not really open) to add that to this package as I try to keep the load on maintaining this package reasonable by limiting the functionality 1:1 to the GitLab API.
Maybe when generics have landed we can see if we can write a single function that can work for all of the list calls, but until then I don't want to add a helper function for each list call.

I just stumbled upon this closed issue and also tried to get rid of some boilerplate with generics.
The best method I came up with for now is with the following:
func getPaginated[I any, O gitlab.ListOptions](searchFunc func(pageNum int) ([]I, *gitlab.Response, error)) ([]I, *gitlab.Response, error) {
	items := []I{}
	pageNum := 1
	for {
		tempItems, response, err := searchFunc(pageNum)
		if err != nil {
			return nil, response, err
		}
		items = append(items, tempItems...)
		if response.NextPage == 0 {
			break
		}
		pageNum = response.NextPage
	}
	return items, nil, nil
}

The idea is that you basically use your existing method that needs pagination and you get the information which page you need and you need to add this as list option.
So for example:
gitlabBranches, _, err := getPaginated(func(pageNum int) ([]*gitlab.Branch, *gitlab.Response, error) {
	return git.Branches.ListBranches(myProjectId, &gitlab.ListBranchesOptions{
		ListOptions: gitlab.ListOptions{Page: pageNum},
	})
})

or
treeNodes, _, err := getPaginated(func(pageNum int) ([]*gitlab.TreeNode, *gitlab.Response, error) {
	return git.Repositories.ListTree(myProjectId, &gitlab.ListTreeOptions{
		Path:        gitlab.String(basePath),
		Recursive:   gitlab.Bool(false),
		ListOptions: gitlab.ListOptions{Page: pageNum},
	})
})

Yes, open to a PR but please do not create a utils.go file for it 😅 Would be open to either putting it in gitlab.go or I guess a file called pagination.go would also be fine...


RT PP Displayer does not run

edit: version 2.18.2

Nvm, wrong place and fixed it. I need to google before doing this.


RecordedFutureIdentity solution update

Required items, please complete
Change(s):

Fixed: Hardcoded subscriptionIDs
Fixed: Updated to Solution V3.
Added: releasenotes
Fixed: renamed playbooks to azuredeploy.json
Fixed: Renamed AAD, Azure AD and Azure Active Directory to Entra ID in names, parameters and readme.
Added custom connector and usage in RFI-lookup-and-save-user logic app.

Reason for Change(s):

Bugfix
Entra ID rename
Custom connector pulling more information from Recorded Future.

Version Updated:

Only logic apps

Testing Completed:

Yes

Checked that the validations are passing and have addressed any issues that are present:

See guidance below.

Hello @RecordedFutureOskbo, Thanks for marking this PR as ready for review state.
This PR will be investigated and we will update you about the same before 26 Jun, 2024
Thanks,
Prasad

Hello @RecordedFutureOskbo, Wanted to confirm are these playbook custom connector dependent

Hello @RecordedFutureOskbo, Wanted to confirm are these playbook custom connector dependent

Hello @RecordedFutureOskbo, Wanted to confirm are these playbook custom connector dependent

Hello, only the RFI-lookup-and-save-user use custom connector.

Ok Thanks,
We are still testing the Solution. Will update you once this is done.
Thanks.


Feat: show one hint at a time

Should not be merged before https://github.com/freeCodeCamp/freeCodeCamp/pull/39223
First commit is from https://github.com/freeCodeCamp/freeCodeCamp/pull/39178

@ojeytonwilliams Once you get the merge conflict ironed out, I will pull this down again and make sure everything is still good before approving/merging.

Tested locally with a few challenges and everything LGTM.


Improve TestPipeline AppName detection

Be sure to do all of the following to help us incorporate your contribution
quickly and easily:

[x] Make sure the PR title is formatted like:
[BEAM-<Jira issue #>] Description of pull request
[x] Make sure tests pass via mvn clean verify. (Even better, enable
Travis-CI on your fork and ensure the whole test matrix passes).
[x] Replace <Jira issue #> in the title with the actual Jira issue
number, if there is one.
[ ] If this contribution is large, please file an Apache
Individual Contributor License Agreement.

After encountering the TestPipeline portion of the stack, try to find
a method annotated with the org.junit.Test annotation. If such a method
is found, return it as the StackTraceElement of the calling class.
This improves TestPipeline name detection for RunnableOnService tests to
avoid duplication

R: @lukecwik

LGTM


emplace_back std::pair parameters rather than push_back

Instead of calling push_back with a temporary std::pair, use emplace_back with the arguments directly. This avoids an unnecessary std::pair object being creating along with the accompanying move.

Thanks for bringing this to my attention! In fact, I think the auto&& range for is also confusing, and it's simpler just to emplace_back and move the argument that is known safe to move. (That's what I get for tweaking slides/code late at night :)
Unless pair ever has a constructor that can deal with just one and not both of its arguments being an rvalue, there will still be a copy, but oh well. I've made a commit to be consistent with the tuple case as well, so I'm going to close this PR. Thanks.
https://github.com/elbeno/testinator/commit/89fe6d3917bc4d074e8e01064aec3b83e7ccd9e2

I was referring to the copy from the temporary std::pair being created by your initial push_back(std::make_pair()) calls, not to the copy of the possibly move-able parameters.  On that note, std::pair actually does have a templated constructor taking two arguments by forwarding reference that's SFINAE-d away if the two template types can't be converted to the respective pair types. So in the case of passing one of the values by rvalue-reference and not the other, the templated constructor taking U1&& and U2&& would be a better match than the constructor taking const T1&, const T2&, and would std::forward U1 and U2, thus getting the move and copy you desired. Check it out here
I also modified my original commit to remove the std::forward<decltype(e)>(e) from the loops because they failed your algorithmic complexity tests.. which is a bit strange to be honest. I'm not sure why you're testing the builds for performance measurements without compiling the code with optimization flags, it seems a bit pointless.

Understood. You're right about the std::pair constructor (and for that matter, make_pair), I was thinking about it as an rvalue reference and not a forwarding reference. So that's good.
My point was that I realised auto&& was wrong/confusing, and I think that a simple std::move with emplace_back is clearer.
Re optimization, one of the nice things about algorithmic complexity is that it should be independent of optimization. In fact it's more clearly elucidated without optimization; optimization wouldn't be a reliable measure when using a machine that's different from production hardware; and optimization only makes things better anyway. But it is strange that the forward caused a failure.
Thanks.


Problem with certificate verification

I have a problem with connecting to a TLS-encrypted irc server. To debug this I added a print before this line:
https://github.com/reactphp/socket-client/blob/master/src/StreamEncryption.php#L119
And i get this output:

SNI_server_name is deprecated in favor of peer_name
SNI_server_name is deprecated in favor of peer_name
stream_socket_enable_crypto(): SSL operation failed with code 1. OpenSSL Error messages:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

I put together this quick test
<?php
$context = stream_context_create(array(
    'ssl' => array(
        'verify_peer' => true,
        'verify_peer_name' => false
    )
));

stream_socket_client("tls://xx.xx.xx.xx:6697", $errno, $errstr, 10, STREAM_CLIENT_CONNECT, $context);
print $errno;
print $errstr;

With verify_peer = true i get the same verification error as from react. Setting verify_peer = false lets me connect without errors.
Is there any way for me to control this in react?

Hi @emil-nasso, looks like you're looking for https://github.com/reactphp/socket-client/issues/4.
There's a pending PR at https://github.com/reactphp/socket-client/pull/52 which is still awaiting review. This should allow you to pass the context parameters just as you've documented.


Improve user interface

Currently, users have to write their own integrand functions using this awkward boilerplate:
function integrand(ndim::Cint, xx::Ptr{Cdouble}, ncomp::Cint, ff::Ptr{Cdouble},
                   userdata::Ptr{Void})
    # Take arrays from "xx" and "ff" pointers.
    x = pointer_to_array(xx, (ndim,))
    f = pointer_to_array(ff, (ncomp,))
	# Do calculations on "f" here
	#   ...
    # Store back the results to "ff"
    ff = pointer_from_objref(f)
return Cint(0)::Cint
end

It would be better to let users directly call integrator functions with something like this:
Vegas( (x)-> cos(x), ndim[; keywords])

Commit https://github.com/giordano/Cuba.jl/commit/e61c7f10410471f6fc74ec6df83bf4f322efe598 in branch ui enables this feature, but that implementation (using eval) is really slow ever for simple integrand functions

You shouldn't need to use eval for this.   Just have a single integrand function:
function generic_integrand!(ndim::Cint, xx::Ptr{Cdouble}, ncomp::Cint, ff::Ptr{Cdouble}, func_::Ptr{Void})
    x = pointer_to_array(xx, (ndim,))
    f = pointer_to_array(ff, (ncomp,))
    func! = unsafe_pointer_to_objref(func_)::Function
    func!(f, x) # call the user's function to compute f = func(x), in-place
    return Cint(0)
end
const c_generic_integrand! = cfunction(generic_integrand!, Cint, (Cint, Ptr{Cdouble}, Cint, Ptr{Cdouble})

and then  call Cubu by passing c_generic_integrand! and the user's function as the Ptr{Void} pointer, as in the Passing closures via pass-through pointers on the Julia blog.
Note that Cint(0) already does a type-assertion in Julia 0.4, so Cint(0)::Cint should not be necessary.
Note also that ff = pointer_from_objref(f) does nothing.  (You are assigning to the pointer, not the contents of the pointer ... this is just changing the value of a formal parameter inside the function and is not visible to the caller.)  Nor is it necessary to do anything: by storing the result in f[i], you change the data that ff points to.
This requires's the user's function to act in-place on the output.   It would be more natural to just let the user return an iterable result (e.g. a single result for ncomp == 1 or a tuple for ncomp > 1).  You can do this by:
function generic_integrand!(ndim::Cint, xx::Ptr{Cdouble}, ncomp::Cint, ff::Ptr{Cdouble}, func_::Ptr{Void})
    x = pointer_to_array(xx, (ndim,))
    func = unsafe_pointer_to_objref(func_)::Function
    y = func(f, x)
    length(y) != ncomp && return Cint(1) # error
    for i = 1:length(y)
        unsafe_store!(ff, y[i], i)
    end
    return Cint(0)
end
const c_generic_integrand = cfunction(generic_integrand!, Cint, (Cint, Ptr{Cdouble}, Cint, Ptr{Cdouble})

Thanks for the suggestions!  Looking at Cubature.jl for vector-valued functions, I also thought about using a function that acts in-place on the output, but I didn't actually tried that yet.
I tested both solutions you suggested, and I found that while the second one is more natural, the first one is faster, and I prefer speed over ease of use, I think I'll go for the first way.  In addition, that would be exactly the same kind of functions required by Cubature.jl, so probably many users are accustomed to them.


Excerpt is not generated after editing a post

Repro:

Write a new post. Doesn't matter whether you write an excerpt or not.
Publish the post.
Edit the post and delete the excerpt.
Publish the post again.

Expected:
An excerpt is generated based on the body.
Actual:
Excerpt field is empty, as we left it after editing and publishing the post.

Fixed in PR #159


Update postinstall to only download if not already present

When using CI such as github actions, it is common to cache the node_modules folder in between runs unless there is a change to the package.json. Currently the postinstall script for geolite2 always downloads the dbs, which are quite large. In my case when on CI and restoring from cache, the dbs already exist. If we update the postinstall to only download if there are not files in the dbs folder, then we can avoid downloading these files on each run.

A pull request with this functionality will be much appreciated ;)

Solved via https://github.com/runk/node-geolite2/pull/41


同步更新

Pull request title

Clearly and concisely describes what it does
Refer to the issue that it solves, if available

Pull request description

Describes the main changes that come with the pull request
Any relevant additional information is provided

For detailed contributing instructions see https://github.com/iluwatar/java-design-patterns/wiki/01.-How-to-contribute

同步更新


Add image digest type to image id for commit

When outputting the newly created image ID from the commit process, prepend
the image digest type for compatibility with other container runtimes.
Resolves: #788
Signed-off-by: baude<EMAIL_ADDRESS>

Also, wait, isn't the image's digest a SHA256, while the ID is just a 256-bit random integer?

Why do images have non-digest IDs?  Can we replace random IDs with digests?  That gets you automatic deduping, cryptographically secure identifiers, which sound like pure upside vs. random IDs.

IDs and digests are indeed distinct, per https://github.com/containers/storage/blob/master/images.go#L26-L31
That does not that ID can be specified when the image is created, so it could theoretically be the sha256 digest as well? Don't want to assume that it is, though.
@nalind can probably answer the questions on why ID and digest are distinct better than I.
Regardless, I'm not really comfortable prefixing things with SHA256: if they're not actually SHA256 sums of something.

Regardless, I'm not really comfortable prefixing things with SHA256: if they're not actually SHA256 sums of something.

I agree, which is why I think we should drop our random IDs and return the digest here instead.  Could this PR get there just by switching to:
fmt.Println(newImage.Digest())

or would that break something else?

The digest is not (AFAICT) usable as input to podman run or inspect etc. Lots of tool chains do:
imgid=$(docker commit cid myimg)
docker run $imgid ...

It seems useful to preserve that docker behavior in podman.

imgid=$(docker commit cid myimg) docker run $imgid ...

Looks like Docker uses much shorter IDs.  But if you allow unique abbreviations of local digests (I do n't know if we do), I still don't see the point to a separate ID.

So, leaving aside the digest vs ID discussion... It's clear that we're returning an ID, which is definitely not a SHA256. As such, I do not think we should prepend the sha256 string to it, even if that's expected Docker behavior. If we do, people will expect that it is a hash, and be confused when it's not

I agree. @baude ok if I close this PR.


Fix indentation in transformer example

@zheng-ningxin @J-shang

will add fixes for some other issues related to the example


Add disclaimer about a breaking change in SystemContractsHelper library

What ❔
Very soon a breaking change will happen in the SystemContractsHelper library, which will stop returning current gasPerPubdataByte.
While the library was never endorsed in the official documentation and also it contained the warning that it should not be externally used, still adding the warning in case someone does try to use it
Why ❔

Checklist

[ ] PR title corresponds to the body of PR (we generate changelog entries from PRs).
[ ] Tests for the changes have been added / updated.
[ ] Documentation comments have been added / updated.

@StanislavBreadless Please fix CI and merge