DTWAIN_GetSourceAcquisitions() returning NULL

I've successfully set up my code to use the DTWAIN_AcquireBuffered() method so I can capture the strips and display the image as it's scanned. However, all attempts to get the final DIB are failing.
I'm using MODELESS, with a Callback.
At first I was trying to use the result of the DTWAIN_AcquireBuffered() method thinking that had the DTWAIN_ARRAY, and then I saw that I needed to wait for the DTWAIN_TN_ACQUIREDONE message.
Now when I get the DTWAIN_TN_ACQUIREDONE message I try and call DTWAIN_GetSourceAcquisitions() but it always returns NULL. If I step into the call p->GetAcquisitionArray() returns NULL. [m_aAcqAttempts == 0x00000000]
DTWAIN_ARRAY DLLENTRY_DEF DTWAIN_GetSourceAcquisitions(DTWAIN_SOURCE Source)
{
LOG_FUNC_ENTRY_PARAMS((Source))
CTL_TwainDLLHandle *pHandle = static_cast<CTL_TwainDLLHandle *>(GetDTWAINHandle_Internal());
// See if DLL Handle exists
DTWAIN_Check_Bad_Handle_Ex(pHandle, NULL, FUNC_MACRO);
CTL_ITwainSource *p = VerifySourceHandle(pHandle, Source);
if (!p)
    LOG_FUNC_EXIT_PARAMS(NULL)
DTWAIN_ARRAY Array = p->GetAcquisitionArray();
**if (!Array)
    LOG_FUNC_EXIT_PARAMS(NULL)**
LOG_FUNC_EXIT_PARAMS(Array)
CATCH_BLOCK(DTWAIN_ARRAY(0))

}
Stepping into AddDibsToAcquisition() shows that m_aAcqAttempts is NULL initially; aDibs has a valid address.
Am I missing something regarding initializing this array or retrieving the DIB(s) after an Acquire? I've tried using just DTWAIN_AcquireNative() as well.
POTENTIAL ISSUE/AREA OF THE PROBLEM (?):
If I put a break-point at line 281 in ctlsourceacquire.cpp -> SourceAcquireWorkerThread():
 if (DTWAIN_LLAcquireNative(opts) == -1L)

Then SET NEXT to line 323:
 pSource->ResetAcquisitionAttempts(aAcquisitionArray);

And execute that line so that m_aAcqAttempts is set, and then SET NEXT back up to line 281. At this point I can continue and the call to DTWAIN_GetSourceAcquisitions() works, returns a valid address, and the subsequent calls to DTWAIN_ArrayGetCount(), DTWAIN_GetNumAcquiredImages(), and DTWAIN_GetAcquiredImage() all appear to work as expected.
NOTE: In this 'hack' the m_PersistentArray in AddDibsToAcquisition() is still NULL.
Thanks.
Daniel

If I add another call to ResetAcquisitionAttempts() after the DTWAIN_ArrayCreate(), like below, it has the same effect as my 'hack' with the breakpoints above.
DTWAIN_ARRAY dynarithmic::SourceAcquireWorkerThread(SourceAcquireOptions& opts)
{
LOG_FUNC_ENTRY_PARAMS((opts))
DTWAIN_ARRAY Array = NULL;
DTWAIN_ARRAY aAcquisitionArray = NULL;
DTWAINArrayLL_RAII a1(Array);
DTWAINArrayLL_RAII aAcq(aAcquisitionArray);

CTL_ITwainSource *pSource = VerifySourceHandle(opts.getHandle(), opts.getSource());
pSource->ResetAcquisitionAttempts(NULL);
aAcquisitionArray = (DTWAIN_ARRAY)DTWAIN_ArrayCreate(DTWAIN_ArrayTypePTR, 0);
pSource->ResetAcquisitionAttempts(aAcquisitionArray);

pSource->m_pUserPtr = NULL;

Thnks, I will take a closer look and get back to you.

I believe I've found the root cause.  I ran a test program, and the issue seems to only appear when acquiring to files.  Acquiring to images in memory does not have these issues.
The issue seems to be in ctlacquirefile.cpp, in function
bool dynarithmic::AcquireFileHelper(SourceAcquireOptions& opts, LONG AcquireType)''
That function basically resets all the dibs to NULL, since for file retrieval, there are no DIBs to handle.  It still is broken however, for modeless processing and attempting to grab the images after the acquisition is done.
You can try the following changes:
bool dynarithmic::AcquireFileHelper(SourceAcquireOptions& opts, LONG AcquireType)
{
    LOG_FUNC_ENTRY_PARAMS((opts))
    DTWAIN_ARRAY aDibs = 0;
    CTL_ITwainSource *pSource = VerifySourceHandle(GetDTWAINHandle_Internal(), opts.getSource());

    // Check if file type requires a loaded DLL
    DumpArrayContents(opts.getFileList(), 0);
    opts.setAcquireType(AcquireType);
	opts.setDiscardDibs(true); // make sure we remove acquired dibs for file handling
    aDibs = SourceAcquire(opts);
    if (opts.getStatus() < 0 && !aDibs)
    {
        LOG_FUNC_EXIT_PARAMS(false)
    }

    bool bRetval = false;
    if (aDibs)
    {
        bRetval = TRUE;
        if (DTWAIN_GetTwainMode() == DTWAIN_MODAL)
        {
            auto vDibs = EnumeratorVectorPtr<LPVOID>(aDibs);
            if (vDibs)
                for_each(begin(*vDibs), end(*vDibs), EnumeratorFunctionImpl::EnumeratorDestroy);
            pSource->ResetAcquisitionAttempts(nullptr);
            if (EnumeratorFunctionImpl::EnumeratorIsValid(aDibs))
                EnumeratorFunctionImpl::EnumeratorDestroy(aDibs);
        }
    }
    if (DTWAIN_GetTwainMode() == DTWAIN_MODAL)
    {
        if (!aDibs)
            bRetval = false;
        else
        if (opts.getStatus() == DTWAIN_TN_ACQUIREDONE)
            bRetval = true;
    }
    else
    if (DTWAIN_GetTwainMode() == DTWAIN_MODELESS)
        pSource->m_pUserPtr = nullptr;

    LOG_FUNC_EXIT_PARAMS(bRetval)
    CATCH_BLOCK(false)
}

Now the issue is whether this will cause a leak of DIBs once the file retrieval is done.  I will need to debug further, but the above seems to be a workaround for now.

I'll try this a little later tonight, but if you think this only solves Acquire to file and Modal then it probably won't work. I'm using Modeless and AcquireNative() / AcquireBuffered().
The AcquireNative() was just for testing trying to resolve this issue.
Ideally I want to use AcquireBuffered() so that I can display the images as they are scanned and then save them out. Reading the docs I think in the end I'll use the AcquireBufferedEx() so I can save each image after it's scanned, but I haven't gotten that far yet.
After either AcquireNative/AcquireBuffered I can't get at the DIBs to save them without the workaround I mentioned earlier. With the workaround it looks like the DIBs are available, but I haven't gotten to writing the code to save them out yet (FreeImage or my existing code). Maybe I'll try that tonight as well.

The method you mentioned, AcquireFileHelper, isn't called in the AcquireNative() workflow.
Looks like you modified the declaration of the method, the code I have is:
static bool AcquireFileHelper(SourceAcquireOptions& opts)
So I'd need to know what else you changed (i.e., where is AcquireType set/etc,)

I ran a quick test for simple AcquireNative() using modeless mode, and I was able to call DTWAIN_GetSourceAcquisitions() on the DTWAIN_TN_ACQUIREDONE notification without an issue, where the handle being returned is not null.   The only issue was with using the file acquisition and calling DTWAIN_GetSourceAcquisitions(), from the test I ran.  That is what the code in the previous comment was related to.
Maybe you should put together a simple application, since I cannot duplicate the issue using DTWAIN_AcquireNative or similarly, DTWAIN_AcquireBuffered.

Around line 1056 in ctlwsrc.cpp, in function CTL_ITwainSource::ResetAcquisitionAttempts:
    if ( aNewAttempts != m_aAcqAttempts)
See what calls that line, and look at the arguments being passed.  The aNewAttempts should not be null on the final time this is called (it will be set to null to initialize, but should be called a second time to set the value).  If for some reason this function is called and somehow resets the m_aAcqAttempts back to null before the acquisition is completed, then take a look at the call stack and see which function is (re)setting the value to null.

It's pretty much what I said in my first post:
***NOTE: This is all using AcquireNative()
The first time ResetAcquisitionAttempts() is called aNewAttempts == NULL. It comes from SourcedAcquired() -> SourceAcquireWorkerThread()    [ctlsourceacquire.cpp - line 236]
The code then hits my breakpoint (after the scanner grabs the page) in AddDibsToAcquisition(). [ctlwsrc.cpp - line 1049] aDibs is a valid address; m_aAcqAttempts is null.  THIS IS THE PROBLEM, there's nowhere to place the DIBs   This comes from ctlwproc.cpp -> DTWAIN_WindowProc() line 517.
Then the DTWAIN_TN_ACQUIREDONE notification is sent. I handle this in my callback and call a method to try and get at the DIBs (which is NULL).
I have another breakpoint on ctlsourceacquire.cpp - line 319 (may be off by one because of the other line I added -- will talk about that in a minute).  ==> if (Array != NULL)  // This is an immediate return
The second time ResetAcquisitionAttempts() is call is from line 324 just after this breakpoint ==> pSource->ResetAcquisitionAttempts(aAcquisitionArray). This correctly sets the m_aAcqAttempts to the new attempt, but it's too late, nothing else tries to add the DIBs to this, so it remains DIB-less.
Process is done now.
If I add a line in ctlsourceacquire.cpp to call ResetAcquisitionAttempts() just after line 235 so it looks like this:
aAcquisitionArray = (DTWAIN_ARRAY)DTWAIN_ArrayCreate(DTWAIN_ArrayTypePTR, 0);
**pSource->ResetAcquisitionAttempts(aAcquisitionArray);**

Then when AddDibsToAcquisition(). [ctlwsrc.cpp - line 1049] is called the DIBs are correctly added to the current acquisition and I can access them after the DTWAIN_TN_ACQUIREDONE notification is sent.
So either something like this needs to happen, or the block below needs to be repositioned (?):
if (Array != NULL)  // This is an immediate return
{
    // turn off RAII here
    a1.Disconnect();
    aAcq.Disconnect();
    pSource->ResetAcquisitionAttempts(aAcquisitionArray);
    p->m_lLastAcqError = DTWAIN_TN_ACQUIRESTARTED;
    opts.setStatus(DTWAIN_TN_ACQUIRESTARTED);
    pSource->m_pUserPtr = Array;
    LOG_FUNC_EXIT_PARAMS(Array)
}

pSource->ResetAcquisitionAttempts(aAcquisitionArray);

When we solve this I'd like to pick your brains on the best way to save images to TIFF/etc. using the DTWAIN library (using the in-memory DIBs from the acquisition).

ok.  I will take a further look.  When you mention "callback", are you referring to using DTWAIN_SetCallback, DTWAIN_SetCallback64, or are you using the straight window procedure that is hooked?  If you are not using DTWAIN_SetCallback, use that and see if this gives different results.

I'm using the DTWAIN_SetCallback:
	DTWAIN_SetCallback(DTWAINCallbackProc, (LONG)(this));

The callback seems to be working as expected.

The following small program does not produce the results you're seeing.  This is running with the latest version, <IP_ADDRESS>.
The DTWAIN_TN_ACQUIREDONE does not assert.   Maybe there is something different in your program than in the sample below?
#include <dtwain.h>
#include <stdio.h>
#include <assert.h>

LRESULT CALLBACK MyCallback(WPARAM w, LPARAM lp, LONG lng)
{
    switch (w)
    {
        case DTWAIN_TN_ACQUIREDONE:
        {
            DTWAIN_ARRAY acq = DTWAIN_GetSourceAcquisitions((DTWAIN_SOURCE)lp);
            assert(acq != NULL);
            LONG num = DTWAIN_ArrayGetCount(acq);
            assert(num > 0);
            HANDLE h = DTWAIN_GetAcquiredImage(acq, 0, 0);
            assert(h != NULL);
        }
       break;
    }
    return 1;
}

int main()
{
    DTWAIN_HANDLE isInitialized = DTWAIN_SysInitialize();
    DTWAIN_SOURCE Source;
    if (!isInitialized)
    {
        printf("Could not initialize DTWAIN library");
        return -1;
    }
    DTWAIN_SetTwainMode(DTWAIN_MODELESS);
    DTWAIN_EnableMsgNotify(TRUE);
    DTWAIN_SetCallback(MyCallback, 0);
    Source = DTWAIN_SelectSource();
    if (Source)
        DTWAIN_AcquireNative(Source, DTWAIN_PT_BW, DTWAIN_MAXACQUIRE, TRUE, TRUE, NULL);

    /* Main message loop: */
    {
        MSG msg;
        while (GetMessage(&msg, NULL, 0, 0) && DTWAIN_IsSourceAcquiring(Source))
        {
            if (!DTWAIN_IsTwainMsg(&msg))  // send message to TWAIN if DTWAIN message
            {
                TranslateMessage(&msg);
                DispatchMessage(&msg);
            }
        }
    }
    DTWAIN_SysDestroy();
}

I had two things, slightly different:

When initializing TWAIN I had two calls to DTWAIN_SysInitialize() like this:
_dtwainHandle = DTWAIN_SysInitialize();
DTWAIN_SysInitialize();

In my "Scan" button code I had a call to DTWAIN_StartTwainSession() like this:
DTWAIN_BOOL twainSessionStarted = DTWAIN_StartTwainSession((HWND)this->winId(), NULL);
if (!twainSessionStarted)
{
LogError("Failed to start TWAIN session: " + GetDTWAINErrorString());
 QMessageBox::warning(this, "Scan Failed", "Failed to start TWAIN scan session. Canceling scan.", QMessageBox::Ok);
 return;

}

I was calling DTWAIN_StartTwainSession() because it sounded like I needed to in order to have progress windows/etc. be parented to the correct window (that doesn't seem to work... the page scan progress indication dialog isn't parented to the window).
When I comment out these two things I no longer need my workaround of the additional call to ResetAcquisitionAttempts().
Not that it should matter, but I should have stated earlier, I'm using Qt for this application.
I'm testing now to see which of the two differences above is responsible for the issue I was seeing.

Qt is fine.  I was able to use it for a demo I had done on my local machine.
The DTWAIN_SysInitialize should just kick back the original handle if called multiple times.  Check the return value and see if the same handle is returned.

The issue is caused by the call to DTWAIN_StartTwainSession().
I tried three tests:

Commenting out both differences noted above and skipping my extra line: WORKED
Commented out just the extra DTWAIN_SysInitialize() call and skipping my extra line: FAILED
Commented out just the DTWAIN_StartTwainSession() call and skipping my extra line: WORKED

So the extra DTWAIN_SysInitialize() has nothing to do with it.
FWIW, I'm not doing anything before the DTWAIN_StartTwainSession(). It would be equivalent to:
DTWAIN_SetTwainMode(DTWAIN_MODELESS);
DTWAIN_EnableMsgNotify(TRUE);
DTWAIN_SetCallback(MyCallback, 0);
DTWAIN_StartTwainSession(hWndToMainWindow, 0);
DTWAIN_BOOL twainSessionStarted = DTWAIN_StartTwainSession((HWND)this->winId(), NULL);
if (Source)
    DTWAIN_AcquireNative(Source, DTWAIN_PT_BW, DTWAIN_MAXACQUIRE, TRUE, TRUE, NULL);

ok.  It is probably an issue with subclassing the user-window, which I will have to investigate further.  In the meantime I suggest to use the DTWAIN_StartTwainSession() with a null window handle (or just remove the call), since you are using DTWAIN_SetCallBack anyway to get the notifications.

I'm going to experiment a little more with it tonight (sadly, day job wants me to work during the day. lol). If I figure out anything I'll update this thread.

ok.  I probably will change the subclassing method in the next version if there is a problem (just to let you know it may be a more extensive change than just a couple of lines).

The problem with calling DTWAIN_StartTWAINSession() has something to do with this section of code:
// do any prep work before we loop
pImpl->PrepareLoop();
switch (opts.getAcquireType())
{
    case ACQUIRENATIVE:
    case ACQUIRENATIVEEX:
        if (DTWAIN_LLAcquireNative(opts) == -1L)
        {
            opts.setStatus(DTWAIN_TN_ACQUIREFAILED);
            LOG_FUNC_EXIT_PARAMS((DTWAIN_ARRAY)NULL)
        }
        if (opts.getAcquireType() == ACQUIRENATIVEEX)
            pSource->SetUserAcquisitionArray(opts.getUserArray());
        break;

The line "if (opts.getAcquireType() == ACQUIRENATIVEEX)" returns false, using DTWAIN_AcquireNative() so it doesn't set the acq array. If I jump over the check and make the Set call the rest of the code works.
The same code appears in the AcquireBuffered section further down in the case, which is probably why that code didn't work for me originally.
Think it's safe to just remove the getAcquireType() check in those two cases? Or maybe add a check to see if the mode is MODELESS and then skip the check?
If I read the documentation right, in MODELESS mode you need to wait for the TN_ACQUIREDONE for both methods, so the UserAcqArray would have to be set here.
Let me know your thoughts and I can try it later tonight after my meeting.

The assumption of the library is that the array of DIBS is generated by DTWAIN for ACQUIREBUFFER and ACQUIRENATIVE modes, while for the EX modes, the user had to provide the array.   Any changes to this part of the code would have to be compatible with the simplest of situations, where a program simply calls DTWAIN_AcquireNative or DTWAIN_AcquireBuffered, with no notification callbacks, no call to DTWIAN_StartTwainSession, etc.  In addition, no memory leaks are introduced, no double-freeing of memory allocated, etc.

After a long hiatus/laziness I spent some time last night trying to reproduce my issue in a much smaller sample. I ended up creating a Qt Creator Console app and moved over my DTWAIN scanning code.
TLDR; I think I may be confused about the usage of DTWAIN_AcquireBuffered() and how/when to get the final image(s). Please see the questions at the end.
Previously I was having problems trying to get the images after acquisition using DTWAIN_AcquireBuffered(). The calls to the following weren't returning expected results:
 DTWAIN_GetSourceAcquisitions)
 DTWAIN_ArrayGetCount()
 DTWAIN_GetNumAcquiredImages()

When I ran my new sample, these calls all worked. Hmmm... what's different?
After reviewing my main app and comparing with the sample code I realized I hadn't copied over the calls to set the strip size:
DTWAIN_GetAcquireStripSizes(_selectedSource, &minSize, &maxSize, &prefSize);

hTheDibStrip = GlobalAlloc(GHND, minSize * 5); //DJC prefSize);

DTWAIN_SetAcquireStripBuffer(_selectedSource, hTheDibStrip);

When I added this code to the new sample and ran again it failed like it did previously.
I then went back to the DTWAIN documentation to see if I missed something regarding buffered transfers, strips, and getting the image(s).
To refresh, in my application I:

start a scan
capture the strip data
update the 'viewer' with the current image (so the user can see it 'build' as the data comes in)
when the transfer is done save out the image(s) [there is post-processing to convert to other formats, multi-page TIFF, etc. based on user settings]

Question/Clarification Needed:
I was assuming that DTWAIN was just giving me access to the strip data, but still maintaining the images internally. Re-reading the documentation it seems like if I turn on strips that it's completely up to me to handle the image data. So I shouldn't be using the DTWAIN_GetSourceAcquisitions() and other methods in this scenario. Is that correct?
Assuming I'm on the right path now, when I get the notification events I do the following:
 DTWAIN_TN_TRANSFERDONE => do any processing/save image/etc. for a single acquired image
 DTWAIN_TN_ACQUIREDONE => do any processing/etc. for all acquired images (post process to multi-page TIFF, convert format/etc.)

Does it sound like I'm understanding it correctly now?
Thanks.

After a long hiatus/laziness I spent some time last night trying to reproduce my issue in a much smaller sample. I ended up creating a Qt Creator Console app and moved over my DTWAIN scanning code.
TLDR; I think I may be confused about the usage of DTWAIN_AcquireBuffered() and how/when to get the final image(s). Please see the questions at the end.
Previously I was having problems trying to get the images after acquisition using DTWAIN_AcquireBuffered(). The calls to the following weren't returning expected results:
 DTWAIN_GetSourceAcquisitions)
 DTWAIN_ArrayGetCount()
 DTWAIN_GetNumAcquiredImages()

When I ran my new sample, these calls all worked. Hmmm... what's different?
After reviewing my main app and comparing with the sample code I realized I hadn't copied over the calls to set the strip size:
DTWAIN_GetAcquireStripSizes(_selectedSource, &minSize, &maxSize, &prefSize);

hTheDibStrip = GlobalAlloc(GHND, minSize * 5); //DJC prefSize);

DTWAIN_SetAcquireStripBuffer(_selectedSource, hTheDibStrip);

When I added this code to the new sample and ran again it failed like it did previously.
I then went back to the DTWAIN documentation to see if I missed something regarding buffered transfers, strips, and getting the image(s).
To refresh, in my application I:

start a scan
capture the strip data
update the 'viewer' with the current image (so the user can see it 'build' as the data comes in)
when the transfer is done save out the image(s) [there is post-processing to convert to other formats, multi-page TIFF, etc. based on user settings]

Question/Clarification Needed:
I was assuming that DTWAIN was just giving me access to the strip data, but still maintaining the images internally. Re-reading the documentation it seems like if I turn on strips that it's completely up to me to handle the image data. So I shouldn't be using the DTWAIN_GetSourceAcquisitions() and other methods in this scenario. Is that correct?
Assuming I'm on the right path now, when I get the notification events I do the following:
 DTWAIN_TN_TRANSFERDONE => do any processing/save image/etc. for a single acquired image
 DTWAIN_TN_ACQUIREDONE => do any processing/etc. for all acquired images (post process to multi-page TIFF, convert format/etc.)

Does it sound like I'm understanding it correctly now?
Thanks.

Yes, as soon as you turn on the processing of the strip data yourself, everything is up to your application to process the strips correctly.  In this mode, DTWAIN basically acts as a pass through (you get the notifications however).
The notifications you may want to look at are DTWAIN_TN_TRANSFERSTRIPREADY and DTWAIN_TN_TRANSFERSTRIPDONE.    The former is sent before the strip is transferred and the latter after the strip is transferred.
In addition, you can use DTWAIN_GetAcquireStripData() on the DTWAIN_TN_TRANSFERSTRIPDONE notification to get information on the acquired strip.

Yes, as soon as you turn on the processing of the strip data yourself, everything is up to your application to process the strips correctly.  In this mode, DTWAIN basically acts as a pass through (you get the notifications however).
The notifications you may want to look at are DTWAIN_TN_TRANSFERSTRIPREADY and DTWAIN_TN_TRANSFERSTRIPDONE.    The former is sent before the strip is transferred and the latter after the strip is transferred.
In addition, you can use DTWAIN_GetAcquireStripData() on the DTWAIN_TN_TRANSFERSTRIPDONE notification to get information on the acquired strip.

Thanks for the confirmation Paul.
I'm already using the other transfer strip calls; I can successfully display the image as it's transferred.
I guess I just didn't completely understand from my first reading of the documentation that I was responsible for everything once I turned on strip processing. Once that clicked last night as I was reading through the docs again it started to make sense.
I'm going to spend more time on it tonight and see if I can get my code to save out the images tonight (I did a quick test during a meeting and it looks like it will work now).
Thanks for your assistance and sorry for going down the wrong path previously. I'll close this issue now.

Thanks for the confirmation Paul.
I'm already using the other transfer strip calls; I can successfully display the image as it's transferred.
I guess I just didn't completely understand from my first reading of the documentation that I was responsible for everything once I turned on strip processing. Once that clicked last night as I was reading through the docs again it started to make sense.
I'm going to spend more time on it tonight and see if I can get my code to save out the images tonight (I did a quick test during a meeting and it looks like it will work now).
Thanks for your assistance and sorry for going down the wrong path previously. I'll close this issue now.


Get-Content -Raw should always return a string, and should therefore return the empty string for zero-byte (empty) files - scalars vs. arrays (collections)

This is a follow-up to #3866.
Note: Even if the conclusion will be that Get-Content's behavior mustn't change for the sake of backward compatibility, the underlying scalar-vs.-collection design question is worth getting clarity on, for future reference.
The reasoning for expecting Get-Content -Raw to always return a string scalar is:

-Raw explicitly asks for the file contents to be returned as a single string.

By contrast, without -Raw - irrespective of the -Encoding requested (including -Byte) - Get-Content inherently returns a collection of items (even though PowerShell unwraps a single-item collection to a scalar for convenience):

an array of lines - by default and with any -Encoding value other than Byte
an array of bytes with -Encoding Byte

Therefore, with an empty (zero-byte) file:

-Raw should return the empty string ('')
Not using -Raw should return a null collection ("nothing", which is technically the [System.Management.Automation.Internal.AutomationNull]::Value singleton).

Note: The competing viewpoint from the linked issue is to conceive of a zero-byte file that is read with neither -Raw nor -Encoding Byte as a special case of a one-line file and therefore return the empty string in that case, rather than a null collection.
Steps to reproduce
# Create empty (zero-byte) file.
New-Item -Type File zero.txt

# Read it as a collection of lines, and count the line.
Get-Content zero.txt | Measure-Object | % Count

# Read it as a single string, and count that string (i.e., test if there actually IS a string).
Get-Content -Raw zero.txt | Measure-Object | % Count

# Explicitly compare the single string read to ''
'' -eq (Get-Content -Raw zero.txt)

Expected behavior
0    # Get-Content zero.txt returns a null collection
1    # Get-Content -Raw zero.txt *should* return string scalar ''
True  # Get-Content -Raw zero.txt *should return ''

Actual behavior
0      # OK: Get-Content zero.txt returns a null collection
0      # !! Get-Content -Raw zero.txt also returns a null collection
False  # !! Get-Content -Raw zero.txt does NOT return ''

Environment data
PowerShell Core v6.0.0-beta (v6.0.0-beta.1)

By pulling this out into its own issue, you have discarded the idea that Get-Content without -Raw and without using -Encoding Byte should return an empty string if the file does not contain any characters. There are good arguments indicating that having Get-Content behave differently for empty files than it does for files with one line and differently than it does for files with more than one line is just confusing. That idea should not be discarded just because you don't agree with it. It should be included in this issue as a point of discussion, awaiting input from the PowerShell Team to determine what can/will be done, if anything, with this issue.

@KirkMunro
While I created this issue from the perspective of what makes sense to me:

I linked to the originating issue,

and let everyone know there that I had done so.

That idea should not be discarded

With your response it was just reintroduced, and that was precisely the point of creating this issue:  so we can have a focused discussion here.
Let the conversation continue -  feel free to copy previously made points by you or @rkeithhill to this thread.

@KirkMunro: I've added a paragraph to the initial post to represent your viewpoint. I hope it sums it up reasonably well. If you agree, let's just continue the conversation here.

having Get-Content behave differently for empty files than it does for files with one line and differently than it does for files with more than one line is just confusing.

The one-item collection case (one-line case here) is not specific to Get-Content at all: it is at the heart of PowerShell, as has been mentioned: a one-item collection is automatically unwrapped, by PowerShell itself, irrespective of what command produces it:

This behavior is very convenient on the one hand, but, prior to v3, was a constant source of confusion and bugs: Because people thought that a cmdlet returned a collection, they didn't anticipate not getting one if the cmdlet happened to return just a one-item collection that was automatically unwrapped.

v3 ingeniously resolved this to retain the best of both worlds: even a scalar can now be treated like a collection, which means that you can consistently use .Count to count the number of items returned  and [0] to get the 1st item - whether there's only one or not. In other words: we no longer need to worry about the special-casing of one-item results, and can live happily ever after in the collection mindset.

On a side note: foreach ($v in $null) { 'here' } not causing the loop to be entered strikes me as an inconsistency: a scalar $null - as opposed to a null collection  - should be treated as an object to iterate over, just as happens with $null | % { 'here' }

So, now that cmdlets (with the appropriate options) that return collections in principle can consistently be treated as collections in the one- and multi-item cases, why should the no-item case be any different?
Also note that with your proposal a file made up of just a newline would be treated the same as a zero-byte file.
With the collection approach, you'd get a null collection in the zero-byte file case, and an empty string in the just-a-newline case.

Here's a screenshot of a table showing a comparison of Get-Content calls with and without -Raw, and with and without -Encoding Byte, run against ASCII and UTF-8 files that are either empty, contain only LF, contain a single-line of text with no LF, contain a single-line of text with LF, contain multiple lines of text with no trailing LF, and contain multiple lines of text with a trailing LF.

What this shows is the following:

As Get-Content stands today, looking only at the output, you can accurately identify exactly what the file the output came from contains as long as you are using either -Raw or -Encoding Byte. If you are not using -Raw or -Encoding Byte, you can still identify what the file the output came from contains, with the exception of knowing what type of newlines were used and with the exception of knowing whether or not there was a trailing newline (unless the file did not have a BOM and contained nothing other than a newline, in which case you can tell the file contained exactly that).
If Get-Content were changed to return an empty string from an empty file when -Raw is used and when -Encoding is not Byte, you would still be able to make the same determination.
If Get-Content were changed to return an empty string from an empty file when -Raw is not used and when -Encoding is not Byte, you would not be able to determine from the content if the original file ended with a newline or not, but that doesn't matter much because with the exception of files that don't contain any content or files that contain only a newline, you already cannot identify whether or not a file ended with a newline by looking at the content when you invoke Get-Content this way.

Cc @PowerShell/area-language

@KirkMunro  Thank you for your thorough analysis.

I still suspect this falls under the "breaking change without enough tangible benefit or reason, therefore rejected" category.

That may well be the outcome, but I want us to have clarity on what the right solution would be if we didn't have to worry about backward compatibility, so we can apply that pattern in the future:

Any call that is designed to return a collection (array) of items in principle should return a null collection ([System.Management.Automation.Internal.AutomationNull]::Value) when no items are being returned.

In the case at hand, this applies to Get-Content _without -Raw, irrespective of what -Encoding value if any, and including Byte, is used.

Conversely, any call that by design returns a scalar should, if there's nothing to output, return the empty version of that scalar ('' in the case of [string]), as appropriate, falling back to (scalar) $null.

In the case at hand, this applies to Get-Content -Raw, which, incidentally, you shouldn't be able to to combine with -Encoding Byte, going by the current docs: #3932

I see arguments for both sides when it comes to not using -Raw

I see one historical argument for returning '' when not using -Raw: The historical ambiguity with respect to whether a newline is a separator or a terminator, and the fact that a trailing newline is in practice considered an optional terminator.
Therefore, you could argue that an empty file ('', when interpreted as a string) and a file containing just <newline> are both a collection of one, empty line, which PowerShell then unwraps to the empty-string scalar.
My personal preference is to not perpetuate this historical ambiguity with respect to a truly empty file, in favor of overall consistency, but I do realize that with non-empty files (ones with actual content, aside from an Unicode signature ("BOM")) it must be preserved.


Move some general paragraphs after the elements definition

"Terminating Elements" and "Guidelines for Updating Elements" should come after
"Considerations for Reading EBML Data".
There should still be a more general/less technical introduction at the beginning (#237)
Solves #239

Solves #239

I don't get it, CRC is still defined late, isn't it?

Updated to resolve conflicts. I kept the sections that @robUx4 moved before Security Considerations but just after the new Forward/Backward Compatibility section.


pre-commit Hook Maintenance and Update

🗣 Description
This PR:

Updates the repo URLs for four hooks to be accurate and consistent.
Adds two new hooks from the base pre-commit-hooks.
Has the results of running pre-commit autoupdate.

💭 Motivation and Context
I noticed that the prettier pre-commit hook that we switched to in #55 had been archived. Upon investigating, I saw that the repo handling that had changed, again, but this time to one of the pre-commit mirrors. Since I was already updating that hook, I thought I would audit the other hook URLs while I was making changes.
I also decided to add two new hooks and run an autoupdate to round out a hook maintenance PR.

🧪 Testing
Automated tests pass.

✅ Checklist

[x] This PR has an informative and human-readable title.
[x] Changes are limited to a single goal - eschew scope creep!
[x] All relevant type-of-change labels have been added.
[x] I have read the CONTRIBUTING document.
[x] These code changes follow cisagov code standards.
[x] All new and existing tests pass.

Do we want to put the "blocked" label on this PR to hold it until we are ready for the next Kraken release?

"Blocked" implies that another issue or pull request is blocking this one.  I suggest creating a new label ("Next Kraken"?) for this purpose.

Do we want to put the "blocked" label on this PR to hold it until we are ready for the next Kraken release?

"Blocked" implies that another issue or pull request is blocking this one. I suggest creating a new label ("Next Kraken"?) for this purpose.

I would honestly like some kind of "on hold" label to cover waiting for a deployment, a kraken, etc

Do we want to put the "blocked" label on this PR to hold it until we are ready for the next Kraken release?

"Blocked" implies that another issue or pull request is blocking this one. I suggest creating a new label ("Next Kraken"?) for this purpose.

I would honestly like some kind of "on hold" label to cover waiting for a deployment, a kraken, etc

I am fine with an "On Hold" label that is distinct from "Blocked".  Probably @felddy can add a phone receiver emoji as well.

@jsf9k Alerted me that the URL for the ansible-lint hook has changed, so I have updated it in keeping with the other changes in this PR. I also ran pre-commit autoupdate again, and will run it on Thursday of next week before the planned merge of this PR.


Property "falling" is not settable (water and lava)

Hey there,
with the current implementation, it is not possible to set the falling property for water/lava.
I think this is a bug :)
java.lang.IllegalArgumentException: Property falling is not valid for block minecraft:water{properties={level=>0}, nbt=null, handler=null} 	at net.minestom.server.instance.block.BlockImpl.withProperty(BlockImpl.java:139)
Kind regards
Andre

This property does not exist. Where did you see it?

My client says this is existing

They only have the level property. This should explain it and is from Spigot's JavaDocs:
In the case of water and lava blocks the levels have special meanings: a level of 0 corresponds to a source block, 1-7 regular fluid heights, and 8-15 to "falling" fluids. All falling fluids have the same behaviour, but the level corresponds to that of the block above them, equal to this.level - 8 Note that counterintuitively, an adjusted level of 1 is the highest level, whilst 7 is the lowest

Unrelated to block properties.


Table grouping

Description
In some cases it make sense to move column with repeating values to the group above rows, so we save horizontal space which it important on mobile.
I propose to add grouping to the table.
Before:

After:

Additional context
It will need to support sorting and other features.

This feature would be really awesome.

Vote !


Run Focal CI Job.

Merged, thanks @arpit551!  I think it's still worth spending some time on trying to make update-locked-requirements produce the same output on Python 3.8 if a small hack lets us achieve that, but this nicely sets us up to work more closely towards offering Focal support.

I don’t think we can expect that:
https://github.com/jazzband/pip-tools#should-i-commit-requirementsin-and-requirementstxt-to-source-control

@timabbott Yes, I think the best we can do is to restrict pip-tools version to 4.4.1

Sigh.  Aside from repo churn/change readability considerations, we don't have a reason not to use separate requirements files for each version.


[Feature]: Video NFT previews

Is there an existing issue for this?

[X] I have searched the existing issues

SUMMARY
Viewing NFT images on Oasis Explorer is amazing, but it only supports images. Videos (e.g. mp4 files) are becoming used more frequently but no preview is shown
DESCRIPTION
If we look at this example NFT:

https://explorer.oasis.io/mainnet/sapphire/token/oasis1qqn6h6mavvcc38z82q330drf3jjlx2zmlyzukqj9/instance/0

It shows 'No preview available'.
This is because the frontend will only show previews for images, this is implemented at:
https://github.com/oasisprotocol/explorer/blob/08e3a08c947d695173290af552d0201263927765/src/app/pages/NFTInstanceDashboardPage/InstanceImageCard.tsx#L104

Related to: https://app.clickup.com/t/8693gr0ua

Hey @CedarMist @buberdds ,
Please have a look over the pull request. I am attaching the screenshots of the updated outcome of this changes for Video NFTs preview.


0.10.0 bpftrace dependency

How to resolve the following dependency problems?

-- Looking for bpf_attach_kfunc - not found
-- Performing Test HAVE_BPF_PROG_TYPE_TRACING
-- Performing Test HAVE_BPF_PROG_TYPE_TRACING - Failed
-- Please install the libbpf development package (missing: LIBBPF_LIBRARIES LIBBPF_INCLUDE_DIRS)
unsafe uprobe: no
bpf_attach_kfunc: no
libbpf: no
libbpf btf dump: no
libbpf btf dump type decl: no
Kernel features
Instruction limit: -1
Loop support: no
btf: no
Probe types
kprobe: no
kfunc: no
bpftrace --info

System
OS: Linux 4.14.117-perf-gcb2425c #1 SMP PREEMPT Wed Jun 3 13:09:15 CST 2020
Arch: aarch64
Build
version: v0.10.0-155-ga34c
LLVM: 7
foreach_sym: yes
unsafe uprobe: no
bfd: yes
bpf_attach_kfunc: no
libbpf: no
libbpf btf dump: no
libbpf btf dump type decl: no
Kernel helpers
probe_read: yes
probe_read_str: yes
probe_read_user: yes
probe_read_user_str: yes
probe_read_kernel: yes
probe_read_kernel_str: yes
get_current_cgroup_id: yes
send_signal: yes
override_return: yes
Kernel features
Instruction limit: -1
Loop support: no
btf: no
Map types
hash: yes
percpu hash: yes
array: yes
percpu array: yes
stack_trace: yes
perf_event_array: yes
Probe types
kprobe: no
tracepoint: yes
perf_event: yes
kfunc: no

Kconfig.txt
@danobi  please help to check the Kconfig, very thanks!

kconfig looks reasonable. Not sure what it could be. Maybe selinux or lockdown?
Can you strace bpftrace --info execution and send results? Curious what the error codes are when bpftrace feature tests.

output.txt
@danobi  please help to check the strace output of bpftrace --info, very thanks!

It's showing EINVAL on trying to load progs that should be ok. My best guess is it has to do with your custom kernel.
I don't think there's much I can do to help you debug this without access to your system.


Update CONTRIBUTING.md

Remove 2/3 please per MS style guide:

Avoid please except in situations where the customer is asked to do something inconvenient or the application or site is to blame for the situation.
The last please meets that bar.

Add AspNetCore repo
Remove double blank lines
Edit

Filed https://github.com/aspnet/AspNetCore/issues/7626 to track the flaky test that was blocking this.


Uncaught Exception: Type NgxGalleryModule does not have 'emod' property - Angular 12.0.3

Need urgent help!
The project builds and compiles successfully but does not load in the browser. I get the following error in console:

Versions:

I'm afraid there's insufficient information provided to investigate this, however it might be helpful to know of the build is using AOT compilation or the JIT compiler.

AOT. When using JIT, I’m getting another error.
What other soecific info can I provide which would be helpful for the topic?
On Thu, Jun 3, 2021 at 5:41 PM Joost Koehoorn @.***>
wrote:

I'm afraid there's insufficient information provided to investigate this,
however it might be helpful to know of the build is using AOT compilation
or the JIT compiler.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/angular/angular-cli/issues/21043#issuecomment-854199619,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AF7RDWMYHZ7YMG4MEPI2RHDTQ7ZIFANCNFSM46BQRCCQ
.

--
Thank You,
Gargi Thakker
240-409-2669

A reproduction repo would be best, or at least the package.json file as it's not clear what dependencies are being used.

Ok. I will upload package.json and tscofig file shortly.
On Thu, Jun 3, 2021 at 5:59 PM Joost Koehoorn @.***>
wrote:

A reproduction repo would be best, or at least the package.json file as
it's not clear what dependencies are being used.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/angular/angular-cli/issues/21043#issuecomment-854212278,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AF7RDWI7T4ZVLD72SV47QRDTQ73MPANCNFSM46BQRCCQ
.

--
Thank You,
Gargi Thakker
240-409-2669

This appeared in another project recently, which I was able to debug. Here is the analysis of what was happening in that case:
The project was using a custom webpack configuration, and the @angular-devkit/build-webpack builder in the Angular CLI to generate bundled JavaScript files that could be lazily loaded at runtime.
Some of the files being built in this way depended upon Angular libraries at runtime.
The @angular-devkit/build-angular builder has integration with ngcc that ensures that such libraries are processed before being bundled. So ngcc was indeed being triggered for the libraries but the way that this integration is configured, the ngcc processed files were being placed in "new ivy entry-points", under the __iviy_ngcc__ directory, which are referenced from in the package.json using new properties such as "es2015_ivy_ngcc": "__ivy_ngcc__/fesm2015/lib.js".
But when bundling using the @angular-devkit/build-webpack builder, it is not aware of these new entry-points and so was pulling the un-processed files into the final bundle - hence the lack of emod properties on NgModule classes.
The fix was to run ngcc as a postinstall step before running the CLI without the --create-new-ivy-entry-points option to ensure that the files were processed in situ, so that the bundler included the correct files.

Thanks @petebacondarwin. Your input worked for me.
Closing the issue.


fixed setup os platform error

The license is giving a conflict when I'm uploading the packages to pypi because CC-BY-SA is not in the options they have. Here you can find a list of options available:
https://pypi.org/pypi?%3Aaction=list_classifiers


docs(Visibility|Ref): deprecate components

⚠ Deprecation notice
This PR marks Visibility and Ref components as deprecated. We will remove them in the next major release, i.e. 3.0.0.
Ref
Visibility
The main reason for deprecation and upcoming removal is performance that is far away from native APIs, even in our docs we use Intersection Observer API (#3985).
Migration
We suggest to use Intersection Observer API directly or via React wrappers, for example: react-intersection-observer.
As it's not a straightforward replacement that may cause issues with adoption we moved out Visibility component to a separate package (@semantic-ui-react/component-visibility). This means that you can use it already with v2 or upcoming v3:
-import { Visibility } from "semantic-ui-react";
+import Visibility from "@semantic-ui-react/component-visibility";

Note: @semantic-ui-react/component-visibility is considered as a deprecated package, we don't plan maintain it, so please consider migration anyway. It also will not receive fixes related to usage of deprecated APIs from React.

Codecov Report

Merging #4324 (6b3d3aa) into master (e500234) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #4324   +/-   ##
=======================================
  Coverage   99.75%   99.75%
=======================================
  Files         180      180
  Lines        3245     3245
=======================================
  Hits         3237     3237
  Misses          8        8

Impacted Files
Coverage Δ

src/behaviors/Visibility/Visibility.js
100.00% <ø> (ø)

Continue to review full report at Codecov.

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


latest release tag is wrong

When I'm trying to get the version of the latest release of this project by https://api.github.com/repos/objectionary/eo-hamcrest/releases/latest I've faced the wrong version. Right now latest tag shows us 0.2.10, but latest release version is 0.4.0

All we need to do is to say to rultor to avoid pre-releases. Like here: https://github.com/yegor256/bibcop/blob/master/.rultor.yml#L14


Wrong annotation of get_bandwidth

Wrong annotation of get_bandwidth returned value in async_tron.py
Pull request of its fix: https://github.com/andelf/tronpy/pull/132

@andelf, could you review?

Wrong ping. Merged, thanks!


Is it possible to drop the () from the end of every property access?

Maybe this is changed with the new RC, but I was wondering if it's possible to make fields getters instead of function calls? Atm I have this:
query('', (t) => [
  t.getPostById({ id: post1 }, (t) => [
    t.slug(),
    t.author((t) => [
      t.username(),
      t.avatar()
    ]),
  ]),
])

Any way it could be changed to this?
query('', (t) => [
  t.getPostById({ id: post1 }, (t) => [
    t.slug,
    t.author((t) => [
      t.username,
      t.avatar
    ]),
  ]),
])

And while I'm dreamcoding, how about this?
query('', t => {
  t.getPostById({id: post1}, [
    t.slug,
    t.author([
      t.username,
      t.avatar
    ])
  ])
})

I mean I have literally no idea how the typescript reflection stuff works but I thought I'd ask!

Getters are not in the RC but are definitely an API improvement I’ve been thinking about. Good reinforcement to see that someone else thought of it too :)
I don’t know of a way of accomplishing the second example exactly (at least with what JS/TS support today). We could support static arrays in place of selector callbacks. Not sure if that would be better though..part of the beauty of the callbacks is that they give you the appropriate selector object t from which to select from (w/o having to import a specific selector object separately).
Good feedback though, keep it coming!

Yeah once I'd sent that last one I realised my mistake with the t var.
FWIW on a second look, the getters-based one looks great to my eyes, makes the nested t.author(t => line stand out.
The only other improvement I thought of was using query.getPostById instead of query('', (t) => [   t.getPostById. That feels like a nice shorthand if you've only got one operation and you don't need to name it?
query.getPostById({ id: post1 }, (t) => [
  t.slug,
  t.author((t) => [
    t.username,
    t.avatar
  ]),
])

This really looks great to me, I could see myself writing that instead of string-based GQL tags pretty muche every time...
Oh and just because I'm a monster, would this ever be possible?
query
  .getPostById({ id: post1 }, (p) => p
    .slug
    .author((a) => a
      .username
      .avatar
    )
  )

I'm not suggesting it, more just curious. Prettier kinda obliterates anyway:
query.getPostById({ id: post1 }, (p) => p.slug.author((a) => a.username.avatar))

Now I wanna trawl TC39 proposals for any new syntax to make fancy new DSLs with :) I had a glance at the pipeline operator but I don't think that helps. Anyway, fun to explore :)

The only other improvement I thought of was using query.getPostById instead of query('', (t) => [ t.getPostById. That feels like a nice shorthand if you've only got one operation and you don't need to name it?

Totally agree. The 1.x RC removes the requirement for an operation name as the first argument. There's also an undocumented option in the pre-1.x version (e.g 0.8.0) to get a similar API if you want to try that (geared towards use-cases where you have a single operation you need to run as you mention).

Pass a --client <name> flag to the codegen CLI
Import the new client class and provide it an Executor (this API ties together query building and execution...hence the "client" name

import { Executor } from '@timkendall/tql'
import { MyClient } from './generated'

const client = new MyClient(new Executor({ uri: 'http://localhost:8080' }))

await client.query.getPostById({ id: post1 }, (t) => [
  t.slug,
  t.author((t) => [
    t.username,
    t.avatar
  ]),
])

Oh and just because I'm a monster, would this ever be possible?

Hmm so a combination between the callback and a more traditional builder API...I'll have to think about that. Not sure if it's cleaner IMO though.

Now I wanna trawl TC39 proposals for any new syntax to make fancy new DSLs with :)

Ha same! If JS/TypeScript offered an implicit this functionality we could make this DSL pretty ideal (take a look at what you can do in Kotlin and Ruby).

The getter syntax is such a great idea! It would totally become my number 1 preferred syntax over all the alternatives. 🤩


Cannot close App - Leaving application in progress...

Software Versions

Python: 3.9
OS: windows 10
Kivy: 2.0.0
Kivy installation method: pip

Describe the bug
on python 3.9 I noted that when I  close the app, clicking on the standard "X" icon on the top right corner of the window,
appears th text:
[INFO   ] [Base        ] Leaving application in progress...
but nothing happens, the window doesn't shut down.
If afterwards I click the "X" again, the app freezes.
The only way the close it right now is by closing the related tab of the pycharm IDE.
Expected behavior
The app should close.
To Reproduce
import kivy
from kivy.app import App
from kivy.uix.label import Label

class MyApp(App):

def build(self):
return Label(text='Hello world')

if __name__ == '__main__':
MyApp().run()

I'm afraid this is an annoying/surprising pycharm feature. Pycharm keeps the python process alive and drops into the debugger after the app finishes and that keeps kivy alive. Try running it outside pycharm and you'll see the issue goes away.
There is a pycharm option somewhere to turn this off, but I'm not sure where. I found it before though.

Python: 3.8
OS: macOS Monterey (M1)
Kivy: 2.1.0
Kivy installation method: conda

Facing the 100% exact same problem here and it's driving me nuts. I'm running on Spyder 5.1.5. If there's a fix for this, I'd be really grateful to know about it.


Allowed-Origin Fix

BEFORE SUBMITTING AN ISSUE CHECK THE FOLLOWING:

[X] I checked existing issues.
[X] This is not a support question (which can be answered on Slack).
[X] This issue is for the API / Game Engine code base (not Web Client, Lambda, or Bots)

ISSUE DESCRIPTION
Make sure to properly set the allowed-origin and do testing to make sure it's the minimal allowed.

This was addressed in PR #380


permit impls to map to private fields

The current RFC bars mapping public trait members to private fields. @petrochenkov questioned this, and I think rightly so. Basically, there is no major difference between:
impl Foo for Bar {
    f = self.g
}

and
impl Foo for Bar {
    fn f(&self) -> &G { &self.g }
}

Allowing private fields is very useful for use in the implementation of provided methods, but it could lead to unintentionally exposing private fields to users, potentially breaking invariants.
I believe this is a strong motivation for Private trait items.


NIFI-5578 Correct errors in EL Guide including Date Manipulation and …

…Escaping EL examples
Also fixed some formatting typos

+1, merging to master, thanks @andrewmlim


Add wallet support for Zcoin

Zcoin wallet can be configured by setting the wallet config as follows:
"Wallet": {
"Binary": "/Applications/Zcoin-Qt.app/Contents/MacOS/Zcoin-Qt",
"FeeAPI": "",
"HighFeeDefault": 160,
"LowFeeDefault": 20,
"MaxFee": 2000,
"MediumFeeDefault": 60,
"TrustedPeer": "",
"Type": "zcoind"
}

Coverage remained the same at 26.152% when pulling ca5672e0d6c21dab9cc08da82c9d064718a9c61d on t3rm1n4l:zcoin into ece8e7e17c6cbdf044f6768e9252ec03ebda5a93 on OpenBazaar:master.

Thanks for the quick feedback.
I looked at the qa tests and found that the current test framework tightly coupled with bitcoind. Looks like a regtest network is a requirement for the tests. Unfortunately, Zcoin does not have a regtest network. I was looking for an altcoin test for Zcash so that I could follow. At this point, I am not quite sure how to automate the tests for Zcoin.

@t3rm1n4l For lack of an integration test pattern, I would recommend unit tests around your behavior which proves they function as intended. A simple example might be to write a unit test around CheckEncode which offers some example inputs and verifies their expected outputs. The inputs should be significant enough to exercise as many branches in your function as is reasonable to prove newly added behavior
Upon closer inspection, it appears that the implementation requires the external Zerocash binary. Given our experience with this approach on ZCash we're hesitant to merge any non-SPV implementation. Does Zerocoin allow an SPV wallet implementation? If so, would you be willing to reimplement this as an SPV wallet?

I will try to rework the patch to add integration into https://github.com/OpenBazaar/spvwallet. Hope, that is the expectation.

@t3rm1n4l I think what we're leaning towards is to have only a few coins natively integrated to maximize maintainability.
However, we are going to work on a plugin architecture to make it easy to integrate new coins. It should work similar to this https://medium.com/learning-the-go-programming-language/writing-modular-go-programs-with-plugins-ec46381ee1a9
Basically your code would remain exactly the same. You would just compile a binary plugin file and drop it in a plugins folder and on next startup the coin would be available.
Soon we're going to be starting a large refactor to make the app work with multiple coins at the same time. At this time we will probably build in the plugin system.
Hope to start this in the next couple weeks and should be finished within a month or so.

Thanks. I will probably wait for the plugin refactoring and i will adapt the changes accordingly.

Cool. I don't think your code will need to change much. It will just need to be put in a separate package and compiled with a plugin flag.

@cpacia Any estimated timeline on the coin integration interface refactor ?

Are you guys planning to accept coin integrations ? Is there any update on the new integration model ?

3rd party integrations will be possible with a plugin interface that we are still working on. Developer updates are published to our youtube channel every two-ish weeks. Update from June 21 had some wallet-related discussion.

We can revisit once plugins are available


Total demand/production line in hourly charts disappear when clicked

When I click on the total demand or total production line in the legend of hourly graphs, this line disappears from both the legend and the hourly graph itself. There is no clear way to retrieve this line, other than refreshing the page or refreshing the graph.
This example shows the hourly graph for hydrogen production:

When I click on "Hydrogen demand" in the legend, the line disappears:

This seems like a bug to me. However, if the option to delete the line is a feature, then it could perhaps be made easier to retrieve the line as well.

It is a bug. I believe there was a desire to be able to toggle the total demand line by flagging it as "not visible". At some point we've changed the legend to only show series which are visible, and this has resulted in the legend item disappearing.
I might be able to rectify this during the (ongoing) flexibility charts projects.


User can add a bitcoin address

POST /v1/addresses
saves address to database and marks as unapproved

unrelated to this specific feature, but why the v1 prefix? seems silly in my opinion to bake a single version number into the api, if you want to version your api to consumers then in the production api it's possible to run an instance of every version of the api that you've published to npm (or tagged via git) plus a router in front that delegates based on a semver prefix. anyways, random thought you can feel free to ignore. :stuck_out_tongue_closed_eyes:

sold.

http signature specs you may find interesting. also rfc2617 (http auth) is very relevant.
i have a gut skepticism regarding the current nonce setup, two possible changes that come to mind are:

we stay with the current approach where the client initiates with their request and restrict the nonce to be an unsigned integer, to start at 0, and to increment by 1 (that way nonce overflow is well-defined). the server would have to store the last used nonce for every client, the client would either have to store their last used nonce or be able to ask the server.
we change the approach where the client first asks for a challenge from the server (which includes the nonce to use) that the client must use in their request.

@ahdinosaur I was just planning on using a timestamp for the nonce - it limits them to one request per second and to be on the same machine (or at least have their clocks synced) which would fit most use cases.
I think upgrading to a challenge handshake with the nonce provided is a nice to have for later on.

sweet, looks good. :+1:


[FAB-18171] Disregard certificate validity period in intra-orderer communication

This change set makes the orderer cluster authentication infrastructure
disregard validity periods when comparing certificates, and only regard public keys.
With this change, one can replace the TLS certificate of Raft,
by a certificate that has the same public key without issuing channel config updates.
This is to ensure that if a certificate of a consenter expired,
one can quickly renew it and start the orderer without performing
a config update per channel.
Change-Id: Id1b29e220d37aa33617b2143b702075bf5b01f6f
Signed-off-by: yacovm<EMAIL_ADDRESS>

@Mergifyio backport release-2.1


1.74.0 Unable to type in Chinese in integrated terminal

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

VS Code Version: 1.74.0
OS Version: macOS Catalina 10.15.7

Steps to Reproduce:

open terminal
Input some Chinese, display utf encoding

I refer to this issues, But the solution is outdated

/duplicate https://github.com/microsoft/vscode/issues/166936


v0.4 release candidate

@e-koch, @astrofrog: I'd like to push an 0.4 release today.  Any objections?

Coverage remained the same at 73.227% when pulling 57ee3721fcddf686cd1867f8b342529ba792e708 on keflavich:rc0.4 into 6649d1c29361e495a08f0de873a2d211a7fdf89f on radio-astro-tools:master.

:+1:


sc-controller: 0.4.3 -> 0.4.4

Motivation for this change
Fix #45144
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s)
[ ] Tested compilation of all pkgs that depend on this change
[x] Tested execution of all binary files
[x] Determined the impact on package closure size (x1.9 increase)
[x] Fits CONTRIBUTING.md.

I submitted to upstream this patch and it was confirmed to work on other systems as well as NixOS, it should be removed in the next release.

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: sc-controller
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Success on aarch64-linux (full log)
Attempted: sc-controller
Partial log (click to expand)
tests/test_parser/test_modifiers.py ...................                  [ 52%]
tests/test_parser/test_special_actions.py ............                   [ 60%]
tests/test_profile/test_actions.py ......................                [ 76%]
tests/test_profile/test_modeshift.py ..                                  [ 77%]
tests/test_profile/test_modifiers.py ..................                  [ 90%]
tests/test_profile/test_special_actions.py ............                  [ 99%]
tests/test_strings/test_modifiers.py .                                   [100%]

========================== 140 passed in 7.27 seconds ==========================
/nix/store/4ga9spwjpn0cqpmjwn35p39mz2a2s39x-sc-controller-0.4.4

Success on x86_64-linux (full log)
Attempted: sc-controller
Partial log (click to expand)
tests/test_parser/test_modifiers.py ...................                  [ 52%]
tests/test_parser/test_special_actions.py ............                   [ 60%]
tests/test_profile/test_actions.py ......................                [ 76%]
tests/test_profile/test_modeshift.py ..                                  [ 77%]
tests/test_profile/test_modifiers.py ..................                  [ 90%]
tests/test_profile/test_special_actions.py ............                  [ 99%]
tests/test_strings/test_modifiers.py .                                   [100%]

========================== 140 passed in 5.38 seconds ==========================
/nix/store/mh65ylri01d8m8rqb9gsd98469appjdr-sc-controller-0.4.4

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: sc-controller
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Success on aarch64-linux (full log)
Attempted: sc-controller
Partial log (click to expand)
/nix/store/4ga9spwjpn0cqpmjwn35p39mz2a2s39x-sc-controller-0.4.4

Success on x86_64-linux (full log)
Attempted: sc-controller
Partial log (click to expand)
/nix/store/mh65ylri01d8m8rqb9gsd98469appjdr-sc-controller-0.4.4


Container Insights are not working if Karpenter is used

The node role created by cdk-karpenter do not have the permission to push metrics and logs to CloudWatch. Hence, there will be no metrics or logs reflected in Container Insights.

Removed "cdk-karpenter" and created a Karpenter construct. Added a CloudWatch managed policy to the node role and fix the permission issue which prevent metrics and logs to be sent to CloudWatch for Container Insights.


Podman file & CI

podman is CLI and API compatible with docker in most instances. Important things of note for us:

podman doesn't prefer Docker Hub, and by default has no unqualified registries to search
podman can use Docker Hub for dependencies
podman prefers a Containerfile to a Dockerfile (although it would use both)

Docker and OCI images are almost identical, so we can use a lot of what was done in the Dockerfile for the Containerfile.
This PR:

Creates a Containerfile that is a duplicate of the Dockerfile with explicit registries for the JDK image
Adds a CI job that builds the Containerfile using podman (but doesn't test it - that seems superfluous at this stage)

Alternative approaches:

Don't have a Containerfile, and explicitly state the registries in the Dockerfile
Don't have a Containerfile, and use a buildah script instead

I have no experience with any of this, so my comments should be easily dismissed in favor of someone's that actually has familiarity with this.
Going with the 'more native' approach (Containerfile over Dockerfile) seems to make sense to me.
I have no idea of Buildah over Containerfile makes sense. From the Buildah readme:

Because of this and their underlying storage differences, you can not see Podman containers from within Buildah or vice versa.

Is this a full mutual exclusion? If so, does it make sense to provide both, rather than just one?

We should probably add documentation to the README for this.

As we discussed in our video call: buildah is probably not needed. It doesn't offer features for our end-users, and we can manage creating the images without buildah perfectly fine.

With the image temporarily building for PRs, I was able to get this locally:


Little additions to the project

Hi!
I‘ve found some plugins/addons to replicate Arc functions:

Boosts — Firemonkey solves almost everything, except the ui (sadly, it‘s closed-source);
Easels — this bookmarklet can be combined with in-url encoding for sharing;
Notes — unfortunately Notes by Firefox is discontinued, and remaining ones (Bookmark notes, Notefox) do not have syncing built-in.

NICE!! THANK YOU SOOOOOOOO MUCH. It actually helps a lot

Added this on the roadmap so i'm closing it :)


using emscripten fiber.h

Are there any examples of godot using emscripten fibers?
https://emscripten.org/docs/api_reference/fiber.h.html?highlight=emscripten_fiber_swap
I realize mono has async/await, but thought I might give fibers a try.

cc @Faless

Asyncify makes the code base much much bigger, causing significant drop in
performance, so I don't think it's a good idea.
On Sun, Aug 23, 2020, 22:23 Hugo Locurcio<EMAIL_ADDRESS>wrote:

cc @Faless https://github.com/Faless
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/41478#issuecomment-678826726,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAM4C3UE4PA4XOL6BVVUXCDSCGCEVANCNFSM4QI3Q7JA
.

Got it, thanks for the advice.  Just to be clear, if I did everything in c++ (ie no gdscript or mono), the c++ optimizer won't help shrink things?  On top of that, if I were to brotli compress everything, would I have a hope of getting something small? @Faless

In the spirit of exploration, where would I set the
-s ASYNCIFY
flag?  And one last question, has any thought been given to co_await support in c++20?
So far, this is the only place I've seen a co_await supporting implementation w/ tests ...
https://github.com/chriskohlhoff/asio/search?q=co_await&unscoped_q=co_await

Got it, thanks for the advice. Just to be clear, if I did everything in c++ (ie no gdscript or mono), the c++ optimizer won't help shrink things?

See: https://emscripten.org/docs/porting/asyncify.html#optimizing

In the spirit of exploration, where would I set the
-s ASYNCIFY

In platform/javascript/detect.py to both LINKFLAGS and CCFLAGS

And one last question, has any thought been given to co_await support in c++20?

No, we don't support C++20, we don't plan to in the short term, and I'm not sure it would even work with emscripten


Create cli interface

Create a cli interface, which makes the following actions possible:

Backup directory
Backup Archive name

Add cli interface with commit 0e9887b24f71f40bf479d34a6e1039c7dbaa6516


Sparse Array - Explicit zeros after slicing

Hi,
When I use explicit zeros in scipy sparse arrays (CSR) everything works as expected - the zero values are in the sparse array's data attribute.
When I do a row slice of the CSR sparse array the explicit zeros are no longer in the data attribute.
I think when scipy reconstructs the sparse array from the slice it drops the zeros assuming they are the same as the implicit zeros.
Scipy/Numpy/Python version information:
0.19.0 1.12.1 sys.version_info(major=3, minor=5, micro=3, releaselevel='final', serial=0)

Could you provide a short, runnable example of the behavior you're seeing?

Apologies for the late reply. In trying to find an example that replicated
it I've worked out it only happens when you use a numpy array as an index.
No issues if you do a normal slice. Only occurs when explicit value is 0,
does not occur on other values.
import scipy.sparse
import numpy as np
a = scipy.sparse.csr_matrix((100,100))
print(a.data)  #Expect [] got []
a[50,50] = 0
0 is explicit in it's unsliced form.
print(a.data) #Expect [0] got [0]
#0 becomes implicit when you slice with a numpy array
b = a[np.array([10,20,30,40,50,60,70])]
print(b.data) #Expect [0] got []
#0 is explicit when you do a vanilla slice
c = a[50]
print(c.data) #Expect [0] got [0]
#No issues when you set the value to 1
a[50,50] = 1
b = a[np.array([10,20,30,40,50,60,70])]
print(b.data) #Expect [1] got [1]
Thanks,
Simeon
On Tue, Jun 27, 2017 at 12:00 AM, CJ Carey<EMAIL_ADDRESS>wrote:

Could you provide a short, runnable example of the behavior you're seeing?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/scipy/scipy/issues/7531#issuecomment-311067789, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AULNSAXm8WQaxTqgsLjpdYpiggjgDYtSks5sH7mPgaJpZM4OFV7l
.

Thanks! This is due to an implementation detail of how we handle "fancy" indexing for CSR/CSC sparse matrices: in many cases (including your example), we generate an "extractor" matrix P such that P.dot(a) returns the result of the slice.
You can see this in action using numpy arrays:
a = np.arange(12).reshape((4, 3))
array([[ 0,  1,  2],
       [ 3,  4,  5],
       [ 6,  7,  8],
       [ 9, 10, 11]])

a[[1,3],:]
array([[ 3,  4,  5],
       [ 9, 10, 11]])

P = np.array([[0,1,0,0],[0,0,0,1]])
array([[0, 1, 0, 0],
       [0, 0, 0, 1]])

P.dot(a)
array([[ 3,  4,  5],
       [ 9, 10, 11]])

All this means that, unintuitively, fancying indexing results in a sparse matrix multiply, which is one of the operations that does not preserve explicit zeros. See gh-3343 for an old (but still relevant) discussion of explicit-zero handling.
I think the right solution here is to find a better way to implement fancy indexing that doesn't defer to matrix multiplication and respects explicit zeros.

This will be fixed by gh-7827.

Bumping the milestone because the cognate PR was also bumped, but it is looking optimistic for an eventual merge there.

PR is merged, Code sample now produces expected result


Handling Transactions

Currently it is impossible to determine or control whether the sink will enlist in an already open transaction scope or not .. and there is no way to control this, since writing the logs happen asynchronously in batches.
I would appreciate adding an option to configure the transaction enlisting behaviour of the used connection?

Hi Bishoy! The current design of the sink - async/batched - pretty much rules this out through a simple change, but it seems like a reasonable idea for an alternative implementation/fork if you want to give one a shot? Cheers!

Hey Nick, Sure .. I'll fork and give it a try. would you like a PR when done? or better leave it in a separate sink project?

I'm not sure TBH - it seems like it'd be a bit of a niche case (never getting logs when transactions roll back, I assume?) - so from that angle a separate package makes sense. Do you think it's something that would get used a lot in general?
Thanks!

Hi Bishoy, let me know how this goes. Closing as there's no action for us to take on this ticket for the time being. Cheers!

@nblumhardt, would you consider a PR that sets "Enlist=false" in the connectionstring unless the enlist option is already specified? It should be a simple  change so that logging cannot be accidentally disabled by transactionscope (and with an easy opt in by setting enlist to true).
Currently the sinks can enlist in transactions in some specific cases such as when flushin or if creating sink with transaction active (unsure about audit mode?) I ran into this in some specific usages such as when writing tests and creating sinks lazily (I have a multitenant scenario with different databases).

@Daniel-Svensson If that would solve the problem at hand, i'd be happy to accept a PR. Could you create a small sample app (or even better an integration test) that proves the fix?

I will probably look into it some time, but it is currently not at the top of my priority list.
When I get to it I would really like to also update the Microsoft.Data dependency to a more modern version  which coexists better with System.Data.
Would the latest version be fine or do you for some reason prefer an older version like 3.0 ?
If upgrading to 3 or 4  I would suggest to depreciate the built in code since for Azure Ad authentication (UseAzureManagedIdentity
AzureServiceTokenProviderResource
AzureTenantId) since the provider has good built in support for Azure AD authentication https://docs.microsoft.com/en-us/sql/connect/ado-net/sql/azure-active-directory-authentication?view=sql-server-ver15
What is your thoughts on the microsoft.data part @ckadluba ?

Anything that would improve compatibility between frameworks would be much appreciated. One thing we have to keep in mind though is to maximize compatibility with existing applications depending on the sink. This sometimes stops us from updating target framework, language and sometimes also our own dependencies to the latest and greatest. For instance the sink still uses C# language version 7.3 (lacking some cool features) but we cannot update it because we still support .NET Framework which sticks to C# 7.3.

Similar restrictions apply for some of the libraries we use.

Thank you for reviewing your change. Not breaking dependent code is always an important goal when developing the library (except we make a new major version which is not planned at the moment).
Regarding the C# version I think it is not only dependent on the studio/compiler version that is used. Some language features (async/await, nullable ref types, etc.) rely on APIs which are not present in older versions of the framework. This is also documented here: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/configure-language-version
Quote:
C# 8.0 is supported only on .NET Core 3.x and newer versions. Many of the newest features require library and runtime features introduced in .NET Core 3.x:
...
C# 9 is supported only on .NET 5 and newer versions.
C# 10 is supported only on .NET 6 and newer versions.
The sink still supports frameworks lower than .NET Core 3.x and until that is the case we stick to C# 7.3.


Enable wrapping for elements in modal-footer

Fixes #24800.

We can now use the negative margin utility classes to fix this, but then still the 2 universal selectors (.modal-footer > :not(:first-child) & .modal-footer > :not(:last-child)) will remain, so it might be better to use the * here so that we only have one poorly performing selector instead of two. I've added a warning about the universal selector usage in this PR.
@mdo, your call if we continue with this.

@twbs/css-review, this one is an older PR from me, but I think it's still relevant so I've added it to the v4.4.0 project

Sorry @MartijnCuppens! Looking at this again, my concern here is that this could cause unintended side effects for folks who have put other items in their .modal-footer (like text, custom elements, etc).
Should we instead limit the selector to > .btn?

No problem, @mdo! We did already target all elements (not only .btn) with > :not(:first-child) and > :not(:last-child), so in this case it might be safer to use the *.

Sorry for resurrecting the dead but I was just wondering if anyone had thought about how to handle different multiple paddings with this fix?

customizations.scss
$modal-inner-padding: 5px 4px; // This will break the style as the resulting css will be concatenated

@karlsve, that won't be possible with the current implementation, but could be fixed by splitting the variable into $modal-inner-padding-x and $modal-inner-padding-y variables. You may open a PR for this.

As the $modal-inner-padding is only used by the .modal-body to actually define all its paddings, shouldn't this be using different variables anyways if there are calculations done?
This would cause developers to define the same value five times in the worst case, which isn't good either.
Another way would be to somehow force the calculation to be done on all elements of a list of values. I have to admit that I am not sure if SASS / SCSS supports this in any way.
It also seems to me like more people should be experiencing this issue as my team cannot be the only one which set the $modal-inner-padding like this in bootstrap 4.3.x.


std::unorderd_map cannot be used as ObjectType

The following code does not compile:
using json = nlohmann::basic_json<std::unordered_map, std::vector, std::string, bool, int64_t, double, std::allocator>;

The reason for this seems to be that the definition of object_t seems to rely on specifics of std::map:
using object_t = ObjectType<StringType,
      basic_json,
      std::less<StringType>,
      AllocatorType<std::pair<const StringType,
      basic_json>>>;

I've been looking at this for a bit, and a 1st run solution isn't that bad.  Just doing SFINAE/enable_if to switch based on unordered_map vs map is pretty easy using is_same or is_base_of.
However, I'm still trying to figure out a way to not break existing code that specializes the ObjectType parameter to a non-std::map container (such as a custom map that has object_t compatible template args).
The difference between map and unordered_map is 2 fold:
1- Different NUMBER of arguments
2- Different types of arguments.  Essentially, the 3rd template param for std::map is a Comparer, whereas in unordered_map this is replaced by a HashFun and KeyEqualityFun.
Optimally, the object_t would be defined entirely based on the ObjectType signature, though I'm currently having a tough time coming up with anything.

I think one can check via enable_if whether the container has a function hash_function() to differentiate between std::map (false) and std::unordered_map (true). It's not perfect this way, but it could be a first step.

Alright, sounds acceptable.  I'm not a HUGE fan of doing it by anything but signature, since the result is overly dependent on the std::map vs std::unordered_map types, but I'll put a pull request together for sdoing it that way in a few hours.  Thanks!

I've made an attempt that is ALMOST working.  I differentiate between the two types via SFINAE based on key_comparer and hasher, which makes object_t do exactly what we need it to.
See the commit here: https://github.com/erichkeane/json/commit/90ab92ade1df8d32ea52e7ad302b41c47b783dce
One might think that type-test-validity would work the same way I'm doing it without having to dive into the member types, however unordered_map will go through resolution successfully with only the 4 template arguments, so it would otherwise be ambiguous.
The calls to void_converter are done with ObjectType<char,char>::... since the Value type is incomplete at the time.
HOWEVER, you'll note if you attempt to build this that this won't compile with an unordered_map due a number of lines requiring object_t::key_type/value_type, which requires the unordered_map to be fully fleshed out, yet basic_json is still incomplete.
The only solution to the problem that I could find is to convert all object_t::key_type to StringType and value_type to std::pair<StringType,basic_json>.
See the commit here: https://github.com/erichkeane/json/commit/16e8d999671e13a2272390acc5b38cd2198e23d6
I'll do a pull request, but I wanted a better explanation here.  Also, if there is a nicer solution to the second commit, I'd REALLY love to see it.

Hi @erichkeane, thanks for your effort! What do you think of @palacaze 's proposal? It may be more verbose, but it could help to approach issue #161 as well.

Hi @erichkeane, thanks for your effort! What do you think of @palacaze 's proposal? It may be more verbose, but it could help to approach issue #161 as well.

I really like his proposal, it would definitely save on a whole bunch of future specializations, and make sure that we are properly abstracted.  My concern was solely that since this is a 1.0.0 product, that changing APIs at all would be prohibitive.
I also like the allocation work that he wishes to do, it doesn't seem like it would be that bad!
My question for @palacaze: How do you see the two working together?  If we no longer make basic_json use an allocator parameter (here), how do we get #161 to work as well?  Would we want to make the custom object type be something like:
template<typename K, typename V, template<typename> class Alloc>
using cust_obj_type = std::map<K,V, std::hash<K>, std::equal_to<K>, Alloc>;

?
Or  is the idea that the custom array/object types would be configured with their OWN allocators that didn't match the rest of the basic_json type?

I really like his proposal, it would definitely save on a whole bunch of future specializations, and make sure that we are properly abstracted.  My concern was solely that since this is a 1.0.0 product, that changing APIs at all would be prohibitive.
I also like the allocation work that he wishes to do, it doesn't seem like it would be that bad!
My question for @palacaze: How do you see the two working together?  If we no longer make basic_json use an allocator parameter (here), how do we get #161 to work as well?  Would we want to make the custom object type be something like:
template<typename K, typename V, template<typename> class Alloc>
using cust_obj_type = std::map<K,V, std::hash<K>, std::equal_to<K>, Alloc>;

?
Or  is the idea that the custom array/object types would be configured with their OWN allocators that didn't match the rest of the basic_json type?

Ok so I looked into it and I won't be that easy.
I will mention both #161 and this bug here, first in reply to @erichkeane how do I make basic_json allocator-aware in relation to my previous idea?
I think a judgement call is needed flexibility-wise, it is difficult to get the best of both worlds.
First of all, we need to consider the potential uses of an allocator. It may be used for basic_json internal nodes (through the create() helper) and for data of each container: object, array and string ; so I count 4 cases. (The lexer may also benefit from it).
The use of the user-provided allocator for internal nodes is a no-brainer, this is what is expected and easy to do by supplying the reference to she unique_ptr constructor.
On the other hand, propagating the allocator to every container-type is trickier because it implies that the (possibly custom) containers can use the user-supplied allocator. Allocators have no obligation of being generic in the sense that they may be tailored specially for only one specific data-type. For example we may want to use an allocator optimized for fixed-sized data types. It would perhaps work well with std::list and fail to work at-all for std::vector. How do we fix that ?
(My example is far-fetched because std::list rebinds the allocator in order to allocate internal data nodes.)

We can either enforce some rules, maybe declare that basic_json supports custom and stateful allocators but only if they are generic enough to support internal allocation as well as the container types,
Or maybe we can state that user supplied allocators are supported but it is up to the user to make sure that the containers can use them and that we give no provision over whether it will be used or not. The trick would be to decide at compile-time if either the supplied allocator should be passed to the containers or not,
At last — this one seems crazy — we could leverage std::scoped_allocator_adaptor in order to supply one outer allocator for node-allocation and up to 3 inner allocators, one per container. Well in fact std::scoped_allocator_adaptor is for purely nested containers, here we have a 2-level hierarchy and different container types on the second level, so a now container-manager helper class would be needed, one able to store up to 4 allocator references. I wont expand on this idea because I would not expect people to use this stuff.

So how would I make this work in practise? The first two ideas are quite similar API-wise and mostly differ by their behaviour. Well we provide constructors with an optional allocator parameter.
The pull request #170 is a "somehow-it-compiles" kind of proof of concept implementing the first idea. All the current unit tests but the one checking for standard layout pass, as I added a reference to an allocator. This is seriously untested, I did not even try out with a custom allocator. So this is sort of good news for #161 but as you can see also an quite intrusive change. This is why I am not persuaded basic_json should be made allocator-aware c++11 style.
Unfortunately, I got also some bad news. The array_t and object_t types as defined currently use incomplete template parameter types, and this is not really supported by the STL. In fact using unordered_map does not even compile. @erichkeane met the same problem and got around it by avoiding the use of object_t. The problem is has the potential to be undefined behaviour stuff. Here is a SO thread mentioning this.
The obvious fix would be to store pointers in the map and vector, but it implies a big overhaul of the code. Another would be to introduce your own containers allowing incomplete types. The Boost libraries have them.

Reading about all the problems, I am also getting unsure whether it is a good idea to make the class allocator-aware. It was not a design goal in the first place, but (in my limited understanding - which is also wrong as we see in #161) at some point it seems to be an easy addition.
That said, I have limited understanding of the values of a user-provided allocator, so I cannot really judge whether the effort is actually adding value in the end.

The fix for this issue is in #209, and the issue with undefined behavior due to incomplete types in std::unordered_map is present again.


Version 0.4

Let's get this thing going.

No, I mean that as a user one does not know what should be in the mat-file
such that the importer works. What objects have to be there in Matlab? How
should they be named? Their dimensions? Their datatype? In general: what is
the exakt file format description for the files your importer imports?
Sankalp Pawar<EMAIL_ADDRESS>schrieb am Do., 6. Feb. 2020,
16:52:

@StellarSankalp commented on this pull request.
In eadf/importers.py
https://github.com/EMS-TU-Ilmenau/EADF/pull/34#discussion_r375918497:

This format defines angular data over uniformly sampled

ele, azi, elem, pol, and freq. Using the importer it is possible to choose
the number of ports to derive the EADF by supplying the numPor value.

by this did you mean that the details about the measurement method itself
are lacking?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/EMS-TU-Ilmenau/EADF/pull/34?email_source=notifications&email_token=AAINSRUTOU3NAGDECGJWCA3RBQW5BA5CNFSM4KL6LYZ2YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCURC2EA#discussion_r375918497,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAINSRRJRNFDHEZ3ZAXR7O3RBQW5BANCNFSM4KL6LYZQ
.


Development meeting 2022-10-17

ACCESS-NRI Development Meeting 17/10/2022
Agenda
What other regular meetings do we need?
Coupled model update
NUOPC update
JaC update
Make all current open source code visible on ACCESS-NRI GitHub Organisation
Proposers: @aidanheerdegen
Outcome: Quantify what components need to be worked ok, agree on who is going to do this, how we go about it
The ACCESS-CM2 and ACCESS-ESM-1.5 models have open source model components that reside in subversion repositories that are not publicly accessible. These need to be migrated to dedicated branches on repos in the NRI GitHub organisation.
Possible existing work?
https://github.com/aidanheerdegen/mom/commits/esm-harmonised
https://github.com/aidanheerdegen/cice5/commits/cm2
Notes

Need system for hosting input files for all models. Also need capacity to publish via THREDDs, which has licensing issues.

Can we put coupled model Configs in GitHub in public repos?

ACCESS-ESM-1.5 uses an older version of CICE (CICE4)
https://www.publish.csiro.au/es/pdf/ES19035
Consequently have made a CICE4 repository and an issue to push the code https://github.com/ACCESS-NRI/CICE4/issues/1

Harmonising run tools is a longer term problem. Will have to support payu and rose/cylc for this release cycle, but need to consider the longer term future of run tools.
Made an issue to track this for ACCESS-OM.

Has decision been made to use CMEPS? It uses a hub and spoke model, so need to confirm we don't need to do model mediated coupling like in ACCESS-OM2, where ocean fields are passed through ice model.


Why all parameters in examples called parms

I’m learning FHE with SEAL, and found it weird that all parameters in native/examples called parms, e.g.:
EncryptionParameters parms(scheme_type::ckks);

maybe we should correct it to params？

"Parameters" are sometimes shortened to "parms".


Force the solver to assign node i to vehicle j

Hello,
Still haven't found the right method to pre-assign node i with vehicle j. Say that I have nodes [0, 1, 2, 3, 4, 5, 6] and 2 vehicles [0, 1]. I want to pre-assign nodes [0, 2, 4] to vehicle_0 and [1, 3, 5] to vehicle_1. For simplicity, assume that node #6 is assignable for either vehicle_0 or vehicle_1. I've succeeded assigning [0,..,5] but not node 6. For my model, pre-assigned node is a hard constraint in the sense that a valid assignment is an assignment that contains all preassigned nodes and assigns them to the right vehicles.
Solutions as in https://github.com/google/or-tools/issues/847 and https://github.com/google/or-tools/issues/1202 miss locations although full assignment is feasible.

I do not see the problem with this, except that you cannot use depot,
start and end nodes in your pre-assigned nodes.
index_0 = manager.NodeToIndex(0)
routing.VehicleVar(index_0).SetValues([0])
Laurent Perron | Operations Research |<EMAIL_ADDRESS>| (33) 1 42 68 53
00
Le mar. 15 oct. 2019 à 13:30, amih77<EMAIL_ADDRESS>a écrit :

Hello,
Still haven't found the right method to pre-assign node i with vehicle j.
Say that I have nodes [0, 1, 2, 3, 4, 5, 6] and 2 vehicles [0, 1]. I want
to pre-assign nodes [0, 2, 4] to vehicle_0 and [1, 3, 5] to vehicle_1.
For simplicity, assume that node #6
https://github.com/google/or-tools/pull/6 is assignable for either
vehicle_0 or vehicle_1. I've succeeded assigning [0,..,5] but not node 6.
For my model, pre-assigned node is a hard constraint in the sense that a
valid assignment is an assignment that contains all preassigned nodes and
assigns them to the right vehicles.
Solutions as in #847 https://github.com/google/or-tools/issues/847 and
#1202 https://github.com/google/or-tools/issues/1202 miss locations
although full assignment is feasible.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/google/or-tools/issues/1647?email_source=notifications&email_token=ACUPL3KVADYMJOYCAPXY7F3QOWSUBA5CNFSM4JA3E4MKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HR3AEZQ,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACUPL3JYDXDTO27TAGPUEMTQOWSUBANCNFSM4JA3E4MA
.

I have a feasible problem with a set of 3 nodes [0, 1, 2], and 2 vehicles. Running it without preassigned nodes yields the assignment {'vehicle_1':[0, 1, 2]} (so in particular, it will be feasible with preassigning any subset of nodes).
Now, running it with:
index_0 = self.manager.NodeToIndex(0)
self.routing.VehicleVar(index_0).SetValues([0])

index_1 = self.manager.NodeToIndex(1)
self.routing.VehicleVar(index_1).SetValues([1])

outputs:
{'vehicle_0':[0], 'vehicle_1':[1]}, with no node 2.

and you have no depot ?
Laurent Perron | Operations Research |<EMAIL_ADDRESS>| (33) 1 42 68 53
00
Le mar. 15 oct. 2019 à 13:52, amih77<EMAIL_ADDRESS>a écrit :

I have a feasible problem with a set of 3 nodes [0, 1, 2], and 2
vehicles. Running it without preassigned nodes yields the assignment {'vehicle_1':[0,
1, 2]} (so in particular, it will be feasible with preassigning any
subset of nodes).
Now, running it with:
index_0 = self.manager.NodeToIndex(0)
self.routing.VehicleVar(index_0).SetValues([0])
index_1 = self.manager.NodeToIndex(1)
self.routing.VehicleVar(index_1).SetValues([1])
outputs:
{'vehicle_0':[0], 'vehicle_1':[1]}, with no node 2.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/google/or-tools/issues/1647?email_source=notifications&email_token=ACUPL3KJQQJ5PTVCAGIEJCLQOWVHLA5CNFSM4JA3E4MKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBIOXKA#issuecomment-542174120,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACUPL3NZK3KUB3ZK5D52A6LQOWVHLANCNFSM4JA3E4MA
.

I do, but they are in indices [3, 4, 5, 6].

Sorry - it was a bug on my part, I didn't sort the locations list in the right time, which caused a problem in the durations matrix. This method seems to work perfectly for me.


port verifyToken from koa-shopify-auth

verify-tokens.ts
I want to use it like this.
if (!Shopify.Auth.verifyToken(req, res, "online") {
  return res.redirect(`/auth?${req.query.shop}`);
}

Hey @kato-takaomi-ams, thanks for your suggestion, but I'm not sure it would be worth porting that function over as it is. In essence, all it does is:
const session = await Shopify.Utils.loadCurrentSession(req, res, mode === 'online');
if (
  session &&
  Shopify.Context.SCOPES.equals(session.scope) &&
  session.accessToken &&
  (!session.expires || session.expires >= new Date())
) {
  // Session is OK!
} else {
  // Session is stale!
}

You could write a middleware that does that and it would have the same behaviour.
In writing this however, I realize that one possible improvement we could make in the future would be to add a isActive() method to Session, so this code would become:
const session = await Shopify.Utils.loadCurrentSession(req, res, mode === 'online');
if (session && session.isActive()) {
  // Session is OK!
} else {
  // Session is stale!
}

That would make this check nice and clean, and allow us to more easily evolve this behaviour.

@paulomarg Thank you for your reply. I think session.isActive() is very good.
To verify scope, I need Shopify.Context.SCOPES. So maybe better to have a method like Shopify.Auth.verifySession(session).

@paulomarg Hello, do you know why Shopify.Utils.loadCurrentSession half the time returns undefined in "/"? This makes it impossible for me to compare the expiration date and scopes in order to decide whether I need to redirect the merchant to "/auth" or the app.


bigint: should be avilable in safari TP

Safari TP 106 enabled bigint as documented here:
https://developer.apple.com/safari/technology-preview/release-notes/

Thanks!

Thanks for merging, looks like it got reverted though https://github.com/Fyrd/caniuse/commit/7d9b3edddf49ca292e8d845858d6a0d8a34e3c07

Sorry about that, fixed now!


Only grab the signature once in eval_call

Description
This runs one step to get the signature at the beginning of eval_call.
Benchmarks like:
> def foo [] { 10 }; benchmark { 1..100000 | each { $it + (foo) } | length }

Are roughly 10% faster now.
Tests
Make sure you've run and fixed any issues with these commands:

[x] cargo fmt --all -- --check to check standard code formatting (cargo fmt --all applies these changes)
[x] cargo clippy --all --all-features -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect to check that you're using the standard code style
[x] cargo build; cargo test --all --all-features to check that all the tests pass

What in the world. This also makes gradient slower now(??!) even though in theory it should be noticeably faster also.
Will switch to draft so we don't land before we can dig in further.

Closing - need to measure before I optimise.


"Select all" on the notifications page is slower than normal

Description
Without RG
https://github.com/refined-github/refined-github/assets/1402241/d31b744d-1c07-4a74-8a06-e32d834126c6
Using RG
https://github.com/refined-github/refined-github/assets/1402241/e42cc6af-2d5e-4996-b48b-39e3b749d7a9
How to replicate the issue + URL
https://github.com/notifications
Extension version
23.12.1
Browser(s) used
Safari

I don't have that issue on Firefox, could it be a Safari bug?

Can repro without Refined GitHub now. It seems to be due to calls in lazy-define but my guess is that it's a CSS performance issue similar to what we had for

#5797


[python-package] fix mypy error about eval result tuples

Contributes to https://github.com/microsoft/LightGBM/issues/3756.
Contributes to https://github.com/microsoft/LightGBM/issues/3867.
Resolves the following error from mypy:
callback.py:167: error: Tuple index out of range  [misc]

That's raised in code that works with eval result tuples, which can be either 4 or 5 elements. Per the discussion in https://github.com/python/mypy/issues/1178, mypy can't use branches like if len(tup) to figure out which element of a union type it must be working with.

Getting closer! We're going to be enforcing mypy --strict by the end of 2023, that's my goal 🤞🏻


Update index.md with Plugfest registration info

I have included a sentence below the "File systems filter driver developer resources" header to include a link to the Plugfest link.
Added a link to the Plugfest website in the learn more tab at the bottom
Also fixed typo -> gude to guide

Hi @sameersaiya, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, MSBOT;