Exact Change

Challenge Name

https://www.freecodecamp.com/challenges/exact-change
Issue Description

It's impossible (so far as I know) to actually get the results requested in the instructions. For example:
checkCashRegister(3.26, 100.00, [["PENNY", 1.01], ["NICKEL", 2.05], ["DIME", 3.10], ["QUARTER", 4.25], ["ONE", 90.00], ["FIVE", 55.00], ["TEN", 20.00], ["TWENTY", 60.00], ["ONE HUNDRED", 100.00]]) should return [["TWENTY", 60.00], ["TEN", 20.00], ["FIVE", 15.00], ["ONE", 1.00], ["QUARTER", 0.50], ["DIME", 0.20], ["PENNY", 0.04]]
The output it's looking for is actually:
[ [ 'TWENTY', 60 ],  [ 'TEN', 20 ],  [ 'FIVE', 15 ],  [ 'ONE', 1 ],  [ 'QUARTER', 0.5 ],  [ 'DIME', 0.2 ],  [ 'PENNY', .04 ] ]
If you attempt to format it with toFixed() the strings(which look more like the requested answers) will be rejected.
`
Browser Information

Browser Name, Version:
Operating System:
Mobile, Desktop, or Tablet:

Your Code

Screenshot

I want to agree 100%. I was looking at the expected test case output, and having a fixed decimal number such as 55.00 is impossible in JS to my knowledge unless it is a string. I actually has the same concern as this is misleading.

@rrandrews @breakpoint25 Please use   room for help regarding the challenge before filing an issue.
@breakpoint25 you don't need the number to be 55.00. Just 55 will pass the test :white_check_mark:
But it has to be a number value (and not a string value).

I still think it is a flawed description of the test case. It is impossible to output 55.00 as a number in an Array

@breakpoint25 It's written 55.00 just for the sake of readability and nothing more.
Campers just need to make sure the output array has a number value as the second element.

then a note should be added describing the output of the test case described is incorrect in order for better readability. As you can see more than one person have been confused by it.

Same issue here,
I get:
checkCashRegister(19.50, 20.00, [["PENNY", 1.01], ["NICKEL", 2.05], ["DIME", 3.10], ["QUARTER", 4.25], ["ONE", 90.00], ["FIVE", 55.00], ["TEN", 20.00], ["TWENTY", 60.00], ["ONE HUNDRED", 100.00]]) should return [["QUARTER", 0.50]].
But I am returning:
[["QUARTER", 0.5]]
My solution in case you want to run it:
function checkCashRegister(price, cash, cid) {
    //Calculate cash due
    var change = cash - price;
    //Check if cash is drawer is less than the change due
    if (getTotal(cid) < change) {
        return 'Insufficient Funds';
    }
    //Check if cash in drawer is equal to change due
    else if (getTotal(cid) == change) {
        return 'Closed';
    }
    //If more cash in drawer than change due
    else {
        console.log(returnChange(change, cid));
    }
}

//Get total cash in register
function getTotal(register) {
    var total = 0;
    for (var note in register) {
        total += register[note][1];
    }
    return total;
}

function returnChange(change, cid) {
    var requiredChange = change;
    var returnChange = [];
    //Flip cid array
    cid.reverse();
    //For every note in drawer
    for (var note in cid) {
        //Check the size of the note
        switch (cid[note][0]) {
            //100
            case "ONE HUNDRED":
                //Check how many notes you have
                var noteCount = cid[note][1] / 100;
                //If we need $100 notes
                if (requiredChange >= 100) {
                    //Check how many notes we need
                    var requiredNotes = Math.floor(requiredChange) / 100;
                    //If we don't have enough notes
                    if (noteCount <= requiredNotes) {
                        //Return them all
                        returnChange.push(cid[note]);
                        //Substract the returned notes from required change
                        requiredChange -= cid[note][1];
                        //If we have more than required notes
                    } else if (noteCount > requiredNotes) {
                        var returnNotes = ["ONE HUNDRED", 0];
                        //For every note
                        for (var x = 0; x < requiredNotes; x++) {
                            if (requiredChange >= 100) {
                                returnNotes[1] += 100;
                                requiredChange -= 100;
                            }
                        }
                        returnChange.push(returnNotes);
                    }
                }
                break;
            //20
            case "TWENTY":
                var noteCount = cid[note][1] / 20;
                if (requiredChange >= 20) {
                    var requiredNotes = Math.floor(requiredChange) / 20;
                    if (noteCount <= requiredNotes) {
                        returnChange.push(cid[note]);
                        requiredChange -= cid[note][1];
                    } else if (noteCount > requiredNotes) {
                        var returnNotes = ["TWENTY", 0];
                        for (var x = 0; x < requiredNotes; x++) {
                            if (requiredChange >= 20) {
                                returnNotes[1] += 20;
                                requiredChange -= 20;
                            }
                        }
                        returnChange.push(returnNotes);
                    }
                }
                break;
            //10
            case "TEN":
                var noteCount = cid[note][1] / 10;
                if (requiredChange >= 10) {
                    var requiredNotes = Math.floor(requiredChange) / 10;
                    if (noteCount <= requiredNotes) {
                        returnChange.push(cid[note]);
                        requiredChange -= cid[note][1];
                    } else if (noteCount > requiredNotes) {
                        var returnNotes = ["TEN", 0];
                        for (var x = 0; x < requiredNotes; x++) {
                            if (requiredChange >= 10) {
                                returnNotes[1] += 10;
                                requiredChange -= 10;
                            }
                        }
                        returnChange.push(returnNotes);
                    }
                }
                break;
            //5
            case "FIVE":
                var noteCount = cid[note][1] / 5;
                if (requiredChange >= 5) {
                    var requiredNotes = Math.floor(requiredChange) / 5;
                    if (noteCount <= requiredNotes) {
                        returnChange.push(cid[note]);
                        requiredChange -= cid[note][1];
                    } else if (noteCount > requiredNotes) {
                        var returnNotes = ["FIVE", 0];
                        for (var x = 0; x < requiredNotes; x++) {
                            if (requiredChange >= 5) {
                                returnNotes[1] += 5;
                                requiredChange -= 5;
                            }
                        }
                        returnChange.push(returnNotes);
                    }
                }
                break;
            //1
            case "ONE":
                var noteCount = cid[note][1] / 1;
                if (requiredChange >= 1) {
                    var requiredNotes = Math.floor(requiredChange) / 1;
                    if (noteCount <= requiredNotes) {
                        returnChange.push(cid[note]);
                        requiredChange -= cid[note][1];
                    } else if (noteCount > requiredNotes) {
                        var returnNotes = ["ONE", 0];
                        for (var x = 0; x < requiredNotes; x++) {
                            if (requiredChange >= 1) {
                                returnNotes[1] += 1;
                                requiredChange -= 1;
                            }
                        }
                        returnChange.push(returnNotes);
                    }
                }
                break;
            //0.25
            case "QUARTER":
                var noteCount = cid[note][1] / 0.25;
                if (requiredChange >= 0.25) {
                    var requiredNotes = requiredChange / 0.25;
                    if (noteCount <= requiredNotes) {
                        returnChange.push(cid[note]);
                        requiredChange -= cid[note][1];
                    } else if (noteCount > requiredNotes) {
                        var returnNotes = ["QUARTER", 0];
                        for (var x = 0; x < requiredNotes; x++) {
                            if (requiredChange >= 0.250) {
                                returnNotes[1] += 0.250;
                                requiredChange -= 0.250;
                            }
                        }
                        returnChange.push(returnNotes);
                    }
                }
                break;
            //0.10
            case "DIME":
                var noteCount = cid[note][1] / 0.1;
                if (requiredChange >= 0.1) {
                    var requiredNotes = requiredChange / 0.1;
                    if (noteCount <= requiredNotes) {
                        returnChange.push(cid[note]);
                        requiredChange -= cid[note][1];
                    } else if (noteCount > requiredNotes) {
                        var returnNotes = ["DIME", 0];
                        for (var x = 0; x < requiredNotes; x++) {
                            if (requiredChange >= 0.10) {
                                returnNotes[1] += 0.10;
                                requiredChange -= 0.10;
                            }
                        }
                        returnChange.push(returnNotes);
                    }
                }
                break;
            //0.05
            case "NICKEL":
                var noteCount = cid[note][1] / 0.05;
                if (requiredChange >= 0.05) {
                    var requiredNotes = requiredChange / 0.05;
                    if (noteCount <= requiredNotes) {
                        returnChange.push(cid[note]);
                        requiredChange -= cid[note][1];
                    } else if (noteCount > requiredNotes) {
                        var returnNotes = ["NICKEL", 0];
                        for (var x = 0; x < requiredNotes; x++) {
                            if (requiredChange >= 0.05) {
                                returnNotes[1] += 0.05;
                                requiredChange -= 0.05;
                            }
                        }
                        returnChange.push(returnNotes);
                    }
                }
                break;
            //0.05
            case "PENNY":
                var noteCount = cid[note][1] / 0.01;
                if (requiredChange >= 0.01) {
                    var requiredNotes = requiredChange / 0.01;
                    if (noteCount <= requiredNotes) {
                        returnChange.push(cid[note]);
                        requiredChange -= cid[note][1];
                    } else if (noteCount > requiredNotes) {
                        var returnNotes = ["PENNY", 0];
                        for (var x = 0; x < requiredNotes; x++) {
                            if (requiredChange >= 0.01) {
                                returnNotes[1] += 0.01;
                                requiredChange -= 0.01;
                            }
                        }
                        returnChange.push(returnNotes);
                    }
                }
                break;
        }
    }
    return returnChange;
}

checkCashRegister(19.50, 20.00, [["PENNY", 1.01], ["NICKEL", 2.05], ["DIME", 3.10], ["QUARTER", 4.25], ["ONE", 90.00], ["FIVE", 55.00], ["TEN", 20.00], ["TWENTY", 60.00], ["ONE HUNDRED", 100.00]])

I believe you have a valid point here. the .00 doesn't really add much readability, but we now know it does add confusion. The tests are actually looking for the .00, but it seems Javascript removes it automatically Because of the confusion, I would be in favor of removing the the extra zero's. @abhisekp What do you think?

@systimotic i agree :white_check_mark:
All tests should reflect the exact value for the exact change :wink: (both in message and assertion)

I'll get started on this and submit a PR shortly.

@damon-myers, awesome! Checkout our Contributing Guide and feel free to let us know in the Contributors chat room if you need any help!

@atjonathan Thanks for the support!


Consolidate cost computation in a single executable

Move hashing cost computation out of ContractSpec into
contract-cost executbale
Move exe to hydra-node because of dependencies

There's probably more refactoring to do in that direction:

Add CBOR encoding cost computation?
Factor out common code handling execution costs

OK, build is failing because of missing GHC flags because of Plutus compiler...


Update Ubiquity Plugin

Rancher Version: 1.0
Docker Version: 1.10.0
OS: Any
Steps to Reproduce: Create a Ubiquity Host
Results: "connection was shut down"
"Unexpected EOF"
Expected: "Success!"
The plugin is compiled for docker machine 0.5.x and we use docker machine 0.6.x in our setup. We need to ask packet to update this.

Not reproducible with 1.0.0 GA.


Fix groupBy on double dimensions.

In master they throw exceptions due to some missing code paths.

👍

👍


ListBox does not render items when testing

🐛 Bug Report

I'm working on writing tests with react-testing-library for a component using ListBox. However, when it renders, none of the items are present. This issue only exists in the tests. Rendering in a browser works fine.
🤔 Expected Behavior

When rendered, I expect to a ListBox with multiple items within it.
😯 Current Behavior

When rendered, I get a ListBox with an empty presentation div inside it.
💁 Possible Solution

It works fine in a live example, so I'm wondering if this is just pebkac on my end.
🔦 Context

I'm currently unable to write tests for a vital component of my plugin since the testing behavior differs from the real world behavior.
💻 Code Sample

In the following test case, the test will fail.
import { defaultTheme, Item, ListBox, Provider } from '@adobe/react-spectrum'
import { render } from '@testing-library/react'

test('Should render provided items', () => {
  const items = [{ name: 'Item 1' }, { name: 'Item 2' }]
  const component = render(
    <Provider theme={defaultTheme}>
      <ListBox aria-label="Testing" selectionMode="single" items={items}>
        {(item: any) => {
          return <Item key={item.name}>{item.name}</Item>
        }}
      </ListBox>
    </Provider>
  )
  component.debug()
  expect(component.queryByText('Item 1')).toBeInTheDocument()
})

The logged debug output is:
<body>
  <div>
    <div
      class="spectrum_b37d53 spectrum_2a241c spectrum--light_a40724 spectrum--large_c40598 spectrum_9e130c spectrum--medium_9e130c spectrum--large_9e130c spectrum--darkest_9e130c spectrum--dark_9e130c spectrum--light_9e130c spectrum--lightest_9e130c"
      dir="ltr"
      lang="en-US"
      style="isolation: isolate; color-scheme: light;"
    >
      <div
        aria-label="Testing"
        class="spectrum-Menu_7ea47c"
        id="react-aria7424150742-1"
        role="listbox"
        style="padding: 0px; overflow-y: auto; overflow-x: hidden;"
        tabindex="0"
      >
        <div
          role="presentation"
          style="width: 0px; height: 0px; pointer-events: auto; position: relative;"
        />
      </div>
    </div>
  </div>
</body>

Note the lack of items inside the ListBox div.
🌍 Your Environment

Software
Version(s)

react-spectrum
3.16.5

Browser
Node (testing via Jest)

Operating System
MacOS

🧢 Your Company/Team

🕷 Tracking Issue (optional)

Hey! Thanks for the issue. Definitely frustrating that you can't get your tests working. Have you looked at the tests we've written? https://github.com/adobe/react-spectrum/blob/main/packages/%40react-spectrum/listbox/test/ListBox.test.js
That may shed light on what you need to do.
My guess is you need to mock/return some widths/heights. This is a virtualized component, so it needs to know the space it has available to render in. Unfortunately, most testing doms actually skip all of the layout calculations in order to make faster tests, so you need to "pretend" as though layout did happen and provide appropriate values for anything that needs it.

That does indeed make my items show up as expected. Pebkac it is. Thanks for the quick reply and the help, @snowystinger.


feat: prototype for extracting teamProject from initial request

Jira Ticket: VADC-715
New Features

Prototype "team project" parser: (1) parses a "team project" from URL params, (2) validates access rights to this "team project" agains Arborist, (3) removes old roles and assigns this "team project" as a user role in the current session

Deployment changes

to enable this feature, set security.ohdsi.custom.authorization.mode="teamproject". See also https://github.com/uc-cdis/cloud-automation/pull/2363/files#diff-cb0c295d87b61830238fff60027f14634f05e8252b52552790ab681231e29c47R29

taken up in https://github.com/vinci-ohdsi/WebAPI/pull/4


Allow changing step attribute using $scope variable

The rz-slider-step attribute is static and does not change, as do the min and max. See #78, which was closed without a working solution.

oops

The oops is because you closed it by mistake or because you found a solution?


Performance problem with small chunks

Writing many small (and similar) chunks takes an enormeous amount of time, far longer than processing all the data in one big chunk.  This should not be the case.
In this branch I'm exposing the bug in a test case as a first step towards a solution.  I don't know yet what a proper solution to this issue should look like.  Haven't found my way around the native code yet.  So this merge request here is currently more like a bug report ticket, but since I think the test cases may be useful in addressing this, I'm posting it as a merge request.

Coverage decreased (-0.06%) to 84.92% when pulling 41c6972fa42dd600f9311eef7dc23e558e0b71f0 on gagern:smallChunksPerformance into 764dad127927a80f542e640a4fae068be61f2f55 on addaleax:master.

Interesting: Travis builds indicate that my test case doesn't fail on node 0.10 but does fail on 0.12. Many iojs runs are still pending, but the others failed as well.
We probably should have a closer look at what changed in the internal stream implementation between 0.10 and 0.12. Or should the readable-stream dependency isolate us from such differences? If so, what else could cause this change for the worse?

I think I found a solution: combining chunks in _writev does the job for me.
I'm not sure whether this is just working around a symptom instead of fixing the root cause. After all, calls to native code shouldn't be that expensive, so we're probably wasting some performance somewhere in there, and the old code exposed that problem while this version makes it far less pronounced. So if you want to investigate the core problem, do so without this fix, e.g. on 764dad127927a80f542e640a4fae068be61f2f55.

Coverage decreased (-0.12%) to 84.87% when pulling 1565121fe1d15f199747e682c2159b6382c45727 on gagern:smallChunksPerformance into 764dad127927a80f542e640a4fae068be61f2f55 on addaleax:master.

I'd say the problems reported by Travis CI are not related to my changes. Apparently there's a race condition somewhere. Perhaps it would be nice to have all streams in memory, so that we can avoid all file system access? And apparently builds fail for current iojs. Do you want to file that as a separate issue?

So, first of all – thanks for your interest and for looking into this! Right now, I do not really have the time to do much profiling here in order to look what exactly the cause of the performance problem might be. My best guess right now is that the underlying C library does not expect to receive many calls with small chunks of data, but I currently don’t know enough about the liblzma internals to say how accurate this is.
I don’t really see any disadvantages in merging your commits, so I will do that as soon as the Travis builds are done (which seem to be stalled for now).
And yes, there is some kind of race condition with regard to the test files. I definitely agree that it would best to restrict the file system access during tests to reading of static files (like the hamlet.txt.xz) regardless of the race condition – I don’t really feel like creating temporary test output inside the base directory is such a good idea in general.
For io.js, I just updated the version of the nan dependency and removed the builds using C++98, which I would expect to resolve the build problems there.
And finally: If you are interested in looking into these problems here in more detail, I can add you as a collaborator if you want. In that case, I’d just need your npm username :)

Merged your commits. Do you want some things added to that? If not, I’ll publish an updated version soon

I'll try to switch to in-memory streams tonight (CEST). If you don't hear back from me, don't wait too long. I don't have an npm account yet, will see about that when I find the time.

Ah, great. Feel free to add a devDependency for some library that provides streams based on memory buffers, I’m sure there’s plenty out there

bl comes to mind

Yeah, bl looks good – go ahead with that if you want (I’m sure I’d find the time to do that at some point, so don’t feel obligated to do anything)

Committed a change to do tests in memory, and Travis seems happy with it. Feel free to make a new release with this.

Just published 0.2.12 :) Thank you for your help!


on-boarding

Description
Fixes # (issue)
Type of change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Change Status

[ ] Complete, tested, ready to review and merge
[ ] Complete, but not tested (may need new tests)
[x] Incomplete/work-in-progress, PR is for discussion/feedback

How Has This Been Tested?

[ ] Test A
[ ] Test B

Checklist

[x] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] My code has been reviewed by at least one peer
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[x] There are no merge conflicts

David, will you add a summary of the work you are doing to the description. (You can copy/paste from trello card)

The work on this branch has been pulled and integrated into the firebase-auth branch.


RGB Script which alternates exactly between two halfs

Splits a Matrix in half and alternates between both halfs, vertically or horizontally.

Can this already be achieved by setting the blocksize in the alternate.js script? Would it make sense to extend that one or is it reflecting another use-case?

I also saw the alternate.js script, but the block size is limited to 16, as far as I see it. This script here would simply divide a matrix in two halfs, regardless of size. Also at least I use it for live shows where I choose the effects from the RGB-effect widget thingy and setups change frequently, so I won't have to worry about any parameters I would have to set to adapt.

To be honest I would extend the alternate.js script with a new parameter like "divide in halves"
Too many scripts with similar purposes would create confusion

Addressed by #1414


Reorg tutorials sto 7163

Harness Developer Pull Request
Thanks for helping us make the Developer Hub better. The PR will be looked at
by the CODEOWNERS.
What Type of PR is This?

[ ] Issue
[ ] Feature
[ ] Maintenance/Chore

If tied to an Issue, list the Issue(s) here:

Issue(s)

House Keeping
Some items to keep track of. Screen shots of changes are optional but would help the maintainers review quicker.

[ ] Tested Locally
[ ] Optional Screenshot.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://65d7c255e0c71a4ef32ce8bd--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://65df9b2428fe67693ab2ef1a--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://65dfa0ba125a316e84823161--harness-developer.netlify.app


Create automated builds integrated with GitHub hooks

Create VM ts-ci in CS1 cluster.
Install Jenkins and integrate it with GitHub hooks for Repository (currently only master branch)
To deploy successful builds to Maven Central

Created with hourly build and snapshot deployment.


Invoice payment in limbo for several days, listed as pending_htlcs, what is going on?

Here is the senario, someone requested that I pay an invoice. Like this:
lnbc81400n1pd6fcckpp5m8vqd290m0xs84c42aukt98hrdv4tr55yzjq3hlpultswl78lrwqdpqd35kw6r5de5kuemnd3hhgmtpvd5xjmn9cqzyskytzntl3q3tzlg8jl9qqac0a437lmzxcpemmrve8t0wxsshrrefslmde95vjyujnk6h8gldhenl2n36wupzzzcnpwke6c72fyjwvfuqpvvht4u
decoded:
{
    "destination": "0294f37ee9e26f9107a16414b691978033efd4e0f0e3aa99d309c4be3f3003124f",
    "payment_hash": "d9d806a8afdbcd03d71557796594f71b59558e9420a408dfe1e7d7077fc7f8dc",
    "num_satoshis": "8140",
    "timestamp": "1537532694",
    "expiry": "3600",
    "description": "lightningslotmachine",
    "description_hash": "",
    "fallback_addr": "",
    "cltv_expiry": "144",
    "route_hints": [
    ]
}

I attempt to pay the invoice, but nothing happens, no response from lnd. Since this payout is automated I have to return a 404 error to the user. Not great.
Then I get a complaint that the money never arrived, not so strange, so I take a look and I find the payment here:
        {
            "active": true,
            "remote_pubkey": "0232e20e7b68b9b673fb25f48322b151a93186bffe4550045040673797ceca43cf",
            "channel_point": "5934bf3804b4cc4e42ac730ea285fb148e05d96ccb042532c1b2dace56dc61f7:1",
            "chan_id": "596172796792995841",
            "capacity": "809335",
            "local_balance": "121065",
            "remote_balance": "678989",
            "commit_fee": "1140",
            "commit_weight": "896",
            "fee_per_kw": "1272",
            "unsettled_balance": "0",
            "total_satoshis_sent": "678989",
            "total_satoshis_received": "0",
            "num_updates": "75",
            "pending_htlcs": [
                {
                    "incoming": false,
                    "amount": "8141",
                    "hash_lock": "2dgGqK/bzQPXFVd5ZZT3G1lVjpQgpAjf4efXB3/H+Nw=",
                    "expiration_height": 542817
                }
            ],
            "csv_delay": 144,
            "private": false
        },

This is already two days ago, but still it's 261 blocks until the expiration_height. What does this mean? I can't cancel this can I? I just have to wait for another 43 hours and see? maybe the transaction goes through, maybe it fails?
Can I prevent this in the future by adding a smaller time frame for the payment to be routed? I really don't want to risk having to wait for several days for transactions to go through. Can I pay an invoice and say, if it does not succeed within 60 seconds, cancel it?
PS. I think lightning is great, I have already processed several hundred transactions and 90% of the time it's instant. So great to job!
Your environment

version of lnd

"version": "0.5.0-beta commit=3b2c807288b1b7f40d609533c1e96a510ac5fa6d"

which operating system (uname -a on *Nix)

Linux RaspiBolt 4.14.52-v7+ #1123 SMP Wed Jun 27 17:35:49 BST 2018 armv7l GNU/Linux

version of btcd, bitcoind, or other backend

bitcoind version": 160300

Your HTLC is in the time out process. This can happen if the receiving side holds onto the HTLC for w/e reason, or somewhere in the middle of the route a node is down/faulty/crashed, etc and they never cancel back the HTLC. Each additional hop adds a time lock, as the route gets longer the time lock gets longer. Atm, the default setting of lnd is on the high-ish side as an initial precautionary measure. In the future, we'll lower this value to somewhere in the 10-20s of blocks. '

Can I prevent this in the future by adding a smaller time frame for the payment to be routed?

In the future, you can add a constraint of the max delay that any payment will incur.

Can I pay an invoice and say, if it does not succeed within 60 seconds, cancel it?

This can be done in-between routing attempts. However, at this early stage of the network, not all nodes are yet up to the level of reliability that will be required in the future. So until we add a bit more intelligence  and passive routing probing, if an HTLC goes through a faulty node, then it may become suspended. In this case, the node should have already went to chain for the HTLC and cancelled it back. The fact that it hasn't done this yet, indicates that it's faulty.


yarn fails with 404

Expected outcome
Running yarn should successfully install dependencies.
Actual outcome

Click to expand
> yarn
yarn install v1.22.19
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
warning " ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>|| 16 || 17".
warning "@blueprintjs/core ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning " ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>|| 16 || 17".
warning " ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>|| 16 || 17".
warning " ><EMAIL_ADDRESS>has incorrect peer dependency<EMAIL_ADDRESS>warning " ><EMAIL_ADDRESS>has incorrect peer dependency<EMAIL_ADDRESS>[4/4] 🔨  Building fresh packages...
[1/3] ⠈ fsevents
[3/3] ⠈ electron
error /Users/username/share/src/extension-geodetic-registry/node_modules/electron: Command failed.
Exit code: 1
Command: node install.js
Arguments:
Directory: /Users/username/share/src/extension-geodetic-registry/node_modules/electron
Output:
HTTPError: Response code 404 (Not Found) for https://github.com/electron/electron/releases/download/v10.1.2/electron-v10.1.2-darwin-arm64.zip
    at EventEmitter.<anonymous> (/Users/username/share/src/extension-geodetic-registry/node_modules/got/source/as-stream.js:35:24)
    at EventEmitter.emit (node:events:520:28)
    at module.exports (/Users/username/share/src/extension-geodetic-registry/node_modules/got/source/get-response.js:22:10)
    at ClientRequest.handleResponse (/Users/username/share/src/extension-geodetic-registry/node_modules/got/source/request-as-event-emitter.js:155:5)
    at Object.onceWrapper (node:events:640:26)
    at ClientRequest.emit (node:events:532:35)
    at ClientRequest.origin.emit (/Users/username/share/src/extension-geodetic-registry/node_modules/@szmarczak/http-timer/source/index.js:37:11)
    at HTTPParser.parserOnIncomingClient [as onIncoming] (node:_http_client:618:27)
    at HTTPParser.parserOnHeadersComplete (node:_http_common:128:17)

Not reproducible now.  Closing.


BUG: Modin on HDK fails during apply call

Please refer to https://github.com/modin-project/modin/issues/5803 for details.
@alexbaden @ienkovich @Egor-Krivov

apply is not supported by HDK backend in Modin, so the problem is on Modin side which is supposed to fallback to Pandas in this case.

I just checked and I suspect this is using an old version of HDK. The provided script executes without errors for me:
UserWarning: Distributing <class 'dict'> object. This may take some time.
UserWarning: <function DataFrame.to_numpy> is not currently supported by ExperimentalHdkOnNative, defaulting to pandas implementation.
Please refer to https://modin.readthedocs.io/en/stable/supported_apis/defaulting_to_pandas.html for explanation.
UserWarning: <function DataFrame.applymap> is not currently supported by ExperimentalHdkOnNative, defaulting to pandas implementation.
                         user  new_id
0        HcbGLZEMQnUUOFqdUdOd       0
1        tUSyoVWHpmEeRfjVCupV       1
2        bqmvOSOuJIDnPHHMsjFS       2
3        wIuWfUiOyvBpEvPKfYcC       3
4        REsDBDZavrUblFPStSIG       4
...                       ...     ...
9999995  PEWxuBGSyHVViCRRusRG  999995
9999996  ddntHBhYKqjThPSzodLd  999996
9999997  kzTpMZwkYnDHfzqciXul  999997
9999998  GEUWxFvNJhZdaROcntHW  999998
9999999  iYpAXCwCBFMQPXhciqqX  999999

[10000000 rows x 2 columns]

I think that looks reasonable?

also works for me having
modin-hdk                 0.19.0
pyhdk                     0.4.0
so probably the problem was in using old versions. I think we can close it


Friday bootstrap portfolio code review

The GitHub Issue is open for revisit my code:
😃 Thank you!

Hi @norbiboy1   👋,
STATUS: APPROVED 🕺🥳
Congratulations🍾🥳!! Your project is ready! There is nothing else to say other than... it's time to merge it :shipit:

Good luck! 🎉
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.

As described in the Code reviews limits policy  you have a limited number of reviews per project (check the exact number in your Dashboard). If you think that the code review was not fair, you can request a second opinion using this form.

Hi Mr @norbiboy1,
Good job so far! 👏. Your Code is Awesome! 💪
There are a few issues 🐛 that you still need to work 🔧 on but you are almost there! 🏃
Don't Worry 🙏
It's ok to have bugs in your code 🐛. Especially if that's your first project 1⃣ in Bootstrap.
I am going to guide you on how to fix them down below. 🤓
For the mobile version: 👍
Kindly add a class for the responsive website.
example: expand-lg
✅ Thank you for distributing your project.
You did a really good job 😄

Hi @norbiboy1  , 👍
APPROVED 💯 🥇
Your project is amazing!  There is nothing else to say other than Congratulations! 🎉

Optional suggestions

It will be best if you implement the design for the mobile version. 💯

Cheers and Happy coding!👏👏👏

Thanks for the comments: @Obimbo07, @tajulafreen, @Pi1998 ! :feelsgood:
I will implement the mobile version today.
Happy coding my friends! 👨💻 👩💻.
Wish you all the best for all of you!!! 😄 💯


Cannot read property '_id' of null

Using Brave browser i get "Cannot read property '_id' of null" on
https://sydsvenskan.se
https://github.com/gab-ai-inc/gab-dissenter-extension/issues/new

Thanks for submitting an issue. This has been fixed: https://twitter.com/getongab/status/1101871346441568257


Add a biome selector to the map generation dialog

Requires https://github.com/FAForever/Neroxis-Map-Generator/pull/382 to be merged and released to actually be able to load the biomes list

Now that the text for random style and biome is the same, should the two constants GENERATOR_RANDOM_STYLE and GENERATOR_RANDOM_BIOME be consolidated into one?


spec: investigate if we can remove (most or all) needs for the concept of a core type

The original generics proposal (#43651) and accompanying detailed design doc didn't specify the notion of a core type.
The spec introduced core types to determine whether an operation is permitted on a generic operand (i.e., an operand with a type containing a type parameter). Core types are also used to explain type inference involving constraints. This was mostly to have a somewhat manageable implementation and specification path from the code before generics to the code with generics, while not being too restrictive in practice.
On the other hand, the original proposal essentially just said that an operation is permitted if it is permitted for all types in the type set defined by the constraint. That is a more general approach and it may also be easier to understand (though not easier to implement).
We should investigate if we can avoid the use of core types more widely. We already do avoid them for some operations, such as indexing. If we can avoid them everywhere, we should be able to enable some desired features (such as #48522) w/o extra rules but as a matter of course.
Umbrella issue for changes related to this.

cc: @ianlancetaylor

Also CC @findleyr.

Thanks for filing this.
As a general rule, I think wherever we can avoid referring to core types the spec gets lighter and the generics implementation gets more useful. However, this benefit is not uniformly distributed. For example, while I think it would be very nice to remove restrictions on struct field access, it is less useful to avoid restrictions on e.g. range statements (do we really need to be able to range over []int|map[string]bool?).
So I think it is a good goal to avoid referencing core types. It would be quite an achievement to avoid all references, but that's probably not strictly necessary. (Also, if we can narrow it down to a just handful of references, perhaps we can phrase restrictions without needing to reference a "core type" abstraction).

@findleyr, I agree that not being able to range over []int|map[string]bool is not a big deal, but I think core types are problematic even for range statements.
For example, I would expect to be able to range over map[string]bool|map[string]struct{}, even though IIUC such a constraint does not have a core type today.

@bcmills I think that's an example of where some restrictions may still be required, but need not be expressed in terms of a "core type" abstraction. For example, we can insist that the key and/or value types be well-defined.

Does the Go team is waiting to release other Generics features or any Core types refactor that should be part of this investigation at some point?
If not, could we add this investigation to a release milestone?
I am trying to understand if there is any current or short-term work that would be preventing this investigation to happen sooner, thanks.

We are all busy and must prioritize among many different issues.  Assigning a release milestone won't affect how quickly we focus on this issue.  What would matter instead is reasons in favor of, or against, working on this issue.  Thanks.

I'm following issue https://github.com/golang/go/issues/48522 -
While getters and setters will work, this seems like a workaround. The big con to this approach is having to use a method pointer which means creating garbage for the collector and increasing pauses. If using Generics along a critical path, this is a major side effect and could result in a substantial amount of garbage being created.

Yup and since struct fields are addressable, it should allow for some code that is currently not possible to write, when someone needs to access those field addresses in a generic function. (I at least have such use-case and no true workaround so it seems legitimate to me for now).
Re. Core types, I think they should probably be subsumed by another concept. At the implementation level, it's okay to keep them but I'm not sure that they are enough to explain all behaviors.
For instance and as noted by others above, if we want rangeability over a union of map types, it would be necessary and probably sufficient to attach a map-rangeable predicate to map types/constructors.
(there are different type of rangeability, slice-rangeable would be different, just as chan-rangeable would also be its own rangeability, etc...).
The difference is illustrated in the LHS of range statements.
If such a predicate/proposition holds for every member of a union interface, it should be accessible in the body of the generic function.
That might require some addition to the  *type.Type struct (as a map of predicates/propositions?) amongst other things?
I think that's also closer to the initial idea described in the proposal.

I believe that this functionality would be really beneficial for anyone writing business logic in Go. I at least routinely revisit this issue to check on the progress.
There are plenty of good examples in this issue https://github.com/golang/go/issues/48522, but to summarize, I think it boils down to the difficulty of writing code based on what something is rather than what it does. For example, adding getter/setter-style functions to an interface feels like a code smell because it's not really behavior it's state. Embedding for state feels wrong too, and sometimes you're not even allowed to modify the structs.
Therefore, I often find myself in situations where it feels like I'm stuck between a rock and a hard place: either I sprinkle my code with tiny interfaces that essentially just contain getter methods, or I duplicate parts of the functions for every struct. Regardless of the choice, I think a generic function that could access the fields of the structs without any indirection would greatly reduce the amount of code I have to write to achieve this, without making the code more complex or harder to read.

@creativecreature To be clear, this issue has, AIUI, zero impact on what kind of Go code you can write or how you would write it. AIUI this is simply about a spec change, to codify the same language, without having to refer to "core types".

@creativecreature To be clear, this issue has, AIUI, zero impact on what kind of Go code you can write or how you would write it. AIUI this is simply about a spec change, to codify the same language, without having to refer to "core types".

Not really.
In the initial text of the proposal:

If we can avoid them everywhere, we should be able to enable some desired features (such as #48522)

@Merovius It says that it's an umbrella issue, and the issue I was referring to was closed in favour of this: https://github.com/golang/go/issues/48522#issuecomment-1811289701

#48522

"either I sprinkle my code with tiny interfaces"
Why is that a problem?  You've admitted they are tiny.  So what's the big deal?  You want to complicate the language with syntax that adds no real capabilities so you can avoid "tiny" interfaces.  I don't see the point.

Therefore, I often find myself in situations where it feels like I'm stuck between a rock and a hard place: either I sprinkle my code with tiny interfaces

Why is that a problem? You've admitted they are tiny. So what's the big deal? You want to complicate the language with syntax that adds no real capability to the language so you can avoid "tiny" interfaces. I don't see the point.  The net gain is negative.

@seancfoley

Why is that a problem? You've admitted they are tiny. So what's the big deal? You want to complicate the language with syntax that adds no real capability to the language so you can avoid writing a tiny one-line interface. I don't see the point. The net gain is negative.

I think the net gain from adding generics to the language is negative if you can't do something like this:
type Point struct {
	X, Y int
}

type Rect struct {
	X, Y, W, H int
}

type Elli struct {
	X, Y, W, H int
}

func GetX[P interface { Point | Rect | Elli }] (p P) int {
	return p.X
}

Do you believe that to be more complex than this?
type Point struct {
	X, Y int
}

func (p Point) GetX() int {
	return p.X
}

type Rect struct {
	X, Y, W, H int
}

func (r Rect) GetX() int {
	return r.X
}

type Elli struct {
	X, Y, W, H int
}

func (e Elli) GetX() int {
	return e.X
}

type GetXer interface {
	GetX() int
}

func GetX(x GetXer) int {
	return x.GetX()
}

@creativecreature What you're suggesting isn't as simple as it seems. For instance, would/should the following work? Unclear.
type Point struct {
	Y, X int
}

type Rect struct {
	X, foo, Y, W, H int
}

type Elli struct {
	X, Y, W, H int
}

func GetX[P interface { Point | Rect | Elli }] (p P) int {
	return p.X
}

@jub0bs

What you're suggesting isn't as simple as it seems. For instance, would/should the following work?

Hmm, what is the big difference compared to this in your opinion?
package main

type Point struct {
	X, Y int
}

func (p Point) GetX() int {
	return p.X
}

type Rect struct {
	Point
	X, Y, W, H int
}

func (r Rect) GetX() int {
	return r.X
}

type Elli struct {
	Rect
	X, Y, W, H int
}

func (e Elli) GetX() int {
	return e.X
}

type GetXer interface {
	GetX() int
}

func GetX(x GetXer) int {
	return x.GetX()
}

@jub0bs

What you're suggesting isn't as simple as it seems. For instance, would/should the following work?

Hmm, what is the big difference compared to this in your opinion?
type Point struct {
	X, Y int
}

func (p Point) GetX() int {
	return p.X
}

type Rect struct {
	X, Y, W, H int
}

func (r Rect) GetX() int {
	return r.X
}

type Elli struct {
	Y, W, H int
	Foo
}

type Foo struct {
	X int
}

func (f Foo) GetX() int {
	return f.X
}

type GetXer interface {
	GetX() int
}

func GetX(x GetXer) int {
	return x.GetX()
}

func main() {
	e := Elli{1, 2, 3, Foo{4}}
	GetX(e)
}

@creativecreature Isn't this the same code snippet as in your earlier comment? I don't think we're going to make much progress in this discussion if you answer my simple question by another question. 😅
Allow me to clarify. I'm not sure what interface { Point | Rect | Elli } means or should mean. In particular,

Does the order of the fields in the various struct declarations matter? Or should field X be first in all those declarations?

What if field X comes from an embedded struct? Does that count?
type Elli struct {
	Y, W, H int
	Foo
}

type Foo struct {
	X int
}

@jub0bs would probably fail to compile sunce we have Elli.Foo.X and not Elli.X
Fields are not promoted I think.

@atdiar Both methods and fields get promoted via struct embedding; see https://go.dev/play/p/64XgN0ucshE

@jub0bs I would expect these to work the same:
type Point struct {
	Y, X int
}

type Rect struct {
	X, Z, Y, W, H int
}

type Elli struct {
	Y, W, H int
	Foo
}

type Foo struct {
	X int
}

func GetX[P interface{ Point | Rect | Elli }](p P) int {
	return p.X
}

func GetElliX(e Elli) int {
	return e.X
}

@atdiar Both methods and fields get promoted to the embedded type to the outer struct; see https://go.dev/play/p/64XgN0ucshE

Woop. I stand corrected. :)

@creativecreature
What would happen here?
type Point struct {
	Y, X int64
}

type Rect struct {
	X, Z, Y, W, H uint
}

type Elli struct {
	Y, W, H int
	Foo
}

type Foo struct {
	X int
}

func GetX[P interface { Point | Rect | Elli }] (p P) int {
	return p.X
}

That's when it starts to get more complicated than what we have today.  Today, using interface methods, we can say what we want to happen in this case.  But with your proposal, if the field names do match up exactly, or if the types do not match up exactly, then the language construct is useless, and there is no way to reconcile this.
And then suppose in my code I have
type Box struct {
	X1, X2 float
}

But I cannot combine my type with your solution, without renaming all uses of X1 and float.
So then we end up spending inordinate amounts of time obsessing over whether we use int64 or int, and what field names we choose, instead of spending that time building our programs.

TBQH I don't believe there really is significant difficulty about deciding what to do - if anything, there is difficulty in how to spec it and maybe how to implement it. But in that last example by @seancfoley the correct answers seems pretty clearly "it should not compile, because p.X does not evaluate to int for all types in the type set of the type parameter". After all, the result of p.X must definitely be assignable to int for that code to be valid, and none of int64 or uint are.
A more interesting question might be about something like fmt.Printf("%T", p.X), or x := p.X. But even there "it should fail to compile, as p.X is, in a meaningful sense, not »the same operation« for all types in the type set" seems like a reasonable answer.
The reason #48522 has not been accepted and implemented is, AIUI, little to do with how to spec or implement that and more to do with "do we really want that and how useful is it?" and - most importantly - with the fact that it definitely interacts with this issue and so doing #48522 before this issue has been addressed is not really sensible.
So FWIW I still do not believe that the speculation about #48522 in this issue are really useful. This issue is, at the end of the day, still not about whether or not (and how) it should be possible to refer to a common field of all types in the type set of a type parameter. It's about whether or not we can get rid of the concept of a core type. If we can, #48522 might follow - if we can't, we might do #48522 in a different way (and then we can re-start talking about that specifically). But until we (and in this case "we" pretty much means the Go team) have investigated the question of core types in general, talking about struct fields specifically is, in my opinion, wasted effort.

@Merovius

TBQH I don't believe there really is significant difficulty about deciding what to do - if anything, there is difficulty in how to spec it and maybe (though I don't think so) how to implement it. But in that last example by @seancfoley the correct answer seems pretty clearly "it should not compile, because p.X does not evaluate to int for all types in the type set of the type parameter". After all, the result of p.X must definitely be assignable to int for that code to be valid, and none of int64 or uint are.

I agree with this. I don't see a reason why it would compile either. The compiler wouldn't be able to generate an identical function for each type in the type constraint (monomorphization/stenciling).

I agree with this. I don't see a reason why it would compile either. The compiler wouldn't be able to generate an identical function for each type in the type constraint (monomorphization/stenciling).

Completely missing the point.

Let's keep it genial :)
The explanation is that the field definition that builds the type set should include the type.
The example above seems to mix several for the definition of .X
But yes, I'm starting to think that @creativecreature is not wrong in that: speaking about this one issue here is not very practical.
Here should be more generally about core types.

Let's keep it genial :)

It's perfectly genial to tell someone that they've missed the point you were making.  I have no idea why you think otherwise, but it's perfectly congenial to say so, and I don't appreciate your insinuations otherwise.

@atdiar

Let's keep it genial :)

It's perfectly genial to tell someone that they've missed the point you were making.  I have no idea why you think otherwise, but it's perfectly congenial to tell someone they've missed the point that was being made, and I don't appreciate your insinuations otherwise.

If it was in good faith, you could simply explain. Anyway, let's keep it at that.

@seancfoley I also sensed a bit of unfriendliness, which made me hesitant to engage in a discussion with you. However, I understand that written communication can sometimes come across differently than intended. Let's try to ensure that this thread remains constructive and positive!

What would happen here?
type Point struct {
Y, X int64
}
type Rect struct {
X, Z, Y, W, H uint
}
type Elli struct {
Y, W, H int
Foo
}
type Foo struct {
X int
}
func GetX[P interface { Point | Rect | Elli }] (p P) int {
return p.X
}

I agree with @Merovius here. I don't think this should compile, and I don't think anyone is advocating for it either. I think a good mental model of stenciling is that GetX should be used as a stencil to stamp out the same function for each of the instantiated types. I understand that this isn't exactly the case since Go does uses a hybrid approach and does it for each GC shape (rather than full monomorphization) but it seems obvious to me that the property names and types would still need to be the same.

And then suppose in my code I have
type Box struct {
	X1, X2 float
}

But I cannot combine my type with your types when using this language construct, without renaming all uses of X1 and float.
And then we must embark on a grand naming convention and type usage convention so that we all choose the same names for the same things and use the same types for the same things, and if we do not, then your new language construct is useless when sharing code with other people.

So then we end up spending inordinate amounts of time obsessing over whether we use int64 or int, and what field names we choose, instead of spending that time building our programs.
That is why the proposal needlessly complicates the language - it breaks down in the most simple cases, and any attempt to reconcile that would result in ridiculous complexity. All to do something that we can already do today with a little more typing.

This function:
func GetX[P interface { Point | Rect | Elli }] (p P) int {
	return p.X
}

Defines a type constraint, so you won't be able to pass your Box regardless. Hence, I don't see why you would need to embark on a grand naming convention journey. We're not saying "for any type return X"; we're saying "for one of these three types, which all have X defined as an int, return it," so that I don't have to create an interface and three separate getter functions. All of this is already in the language, except for the possibility to access X. Having to create an abstraction and use an interface for something that isn't behavior but state feels wrong in a language that has generics. You also have to align names and return types with interfaces, so I don't see why that would lead to "ridiculous complexity" regardless.
I'm advocating for this change because I don't think it would significantly impact the way we write Go code, and quite frankly, I believe this code:
type Point struct {
	X, Y int
}

type Rect struct {
	X, Y, W, H int
}

type Elli struct {
	X, Y, W, H int
}

func GetX[P interface { Point | Rect | Elli }] (p P) int {
	return p.X
}

To be much simpler than this:
type Point struct {
	X, Y int
}

func (p Point) GetX() int {
	return p.X
}

type Rect struct {
	X, Y, W, H int
}

func (r Rect) GetX() int {
	return r.X
}

type Elli struct {
	X, Y, W, H int
}

func (e Elli) GetX() int {
	return e.X
}

type GetXer interface {
	GetX() int
}

func GetX(x GetXer) int {
	return x.GetX()
}

Go generics are too limited for my needs seem to rank really high on the latest developer survey too:

I also think that this example might be too simple to fully illustrate the point, but in a large codebase that handles a lot of business logic, I've seen it result in significant amounts of extra boilerplate.

I suppose this is also related to the fact that this currently doesn't work with integer ranges:
func PrintNums[T constraints.Integer](stop T) {
	// cannot range over stop (variable of type T
	// constrained by constraints.Integer): no core type
	for i := range stop {
		fmt.Println(i)
	}
}

Though it does feel a bit silly that the above fails while this works perfectly fine:
func PrintNums[T constraints.Integer](stop T) {
	for i := T(0); i < stop; i++ {
		fmt.Println(i)
	}
}

Maybe special casing it for integer ranges would be straightforward enough to warrant its own issue? (I did have a look around and couldn't find anything, but maybe I missed one.)

@arvidfm Thanks for the example. I agree that this should be addressed.

Closing this issue in favor of the concrete proposal #70128.


Introduce new page type for top-level section pages ("How-to", "Tutorial", "References")

@thibaudcolas  Draft PR, see: https://github.com/wagtail/guide/pull/260


Tests are failing with PyLS 0.23+

@steff456, please check what new changes were introduced in PyLS 0.23 that are breaking our tests and most probably code completion as well.

@steff456, I think the comment below should help you to solve the problems we're having with the latest versions of PyLS (i.e. PyLS > 0.23)
https://github.com/palantir/python-language-server/issues/512#issuecomment-467016798
So the idea is to add a new entry inside the jedi_completion section of our PyLS configuration:
https://github.com/spyder-ide/spyder/blob/master/spyder/config/main.py#L726
with the following
'include_params': False


make it obvious how to name the custom concept keyword

sks is the default string (keyword?) that represents the trained concept. Is there an input parameter to the model that can be set to customize this keyword?
cc @chenxwh

refer to the README on https://replicate.com/replicate/dreambooth maybe?

https://replicate.com/blog/dreambooth-api covers it pretty well.

a [identifier] [class noun], where identifier is some rare token. In the example above we're using cjw, but you can use any string you like. For best results, use an identifier containing 3 Unicode characters, without spaces.

Resolved by https://github.com/replicate/dreambooth/blob/88ef90b6bcda8e2a501b365f49fc04c3e7263695/predictor.py#L63


Add CabGen configuration

New version of CabGen release to support configurations.
Configured to publish only the "WindowsServer2022-ps" moniker and exclude the following:

docset/winserver2022-ps/Microsoft.DiagnosticDataViewer
docset/winserver2022-ps/windowsdiagnosticdata
docset/winserver2022-ps/hyperv

Docs Build status updates of commit c9e77c3:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

.openpublishing.publish.config.json
:white_check_mark:Succeeded

docset/mapping/cabgenConfig.json
:white_check_mark:Succeeded

docset/winserver2022-ps/hyper-v/Hyper-V.md
:white_check_mark:Succeeded
View (WindowsServer2022-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


RenderingDevice: Fix getting cubemap layer data

I've noticed this while working on #94600.
The code for retrieving cubemap layer data would multiply the layer count by 6, even though each cube face was already considered a separate layer. Due to this, the DEV_ASSERT below would get triggered due to mismatched data sizes.

This might need more careful testing, the same code is in texture_update and texture_copy. In all cases they are reading from the tex->layers property which is set at creation time

After looking at the code, the layer_count variable appears to only be used for ensuring the provided index doesn't reach outside of the layers array.

After looking at the code, the layer_count variable appears to only be used for ensuring the provided index doesn't reach outside of the layers array.

Very interesting. So it should be easy to validate then. I imagine the fix you did here would apply in those places too.


Add sort.InvertSlice()

Golang should have an InvertSlice() function in some module (preferably sort), which essentially reverses all slice elements. This would allow some neat features like string reversal.
This is easy to implement and will not break code. Please consider the proposal.

@gsbhasin123 you missed my previous comment.

@networkimprov a bot auto created it. I don't know to close the gerrit CL, but PR is closed.

Assuming InvertSlice existed, would this be a good strings.Reverse implementation?
func Reverse(s string) string {
	return string([]rune(s))
}

Or, if someone didn't want to create a function:
string([]rune("some string"))

See https://github.com/golang/go/issues/36887#issuecomment-580514147

string(sort.InvertSlice([]rune(str)).([]rune))
Looks like mine, but why .([]rune)?

This thread has a lot of noise unrelated to the proposal, making it hard to digest. For questions about Go see the docs, or post to https://groups.google.com/forum/#!forum/golang-nuts

I still can't tell whether this issue is about strings.Reverse or slices.Reverse (meaning reverse the slice from its current order) or sort.ReverseSlice (meaning sort the slice in reverse order).
strings.Reverse is a duplicate of #14777. It remains not needed often enough to merit inclusion in the standard library. The existence of the proposal process does not require revisiting every decision we have made in the past.
slices.Reverse and slices.Copy are both likely candidates for a slices package once we have generics. We don't need an issue tracking those - wait until the package exists and doesn't have what you want.
sort.Slice is a helper that essentially requires writing an inline func to work. If you want to sort in the reverse order, you replace < with > in the func you write. We don't need a general reverser for that API.
Even though I can't tell which one of these three is being proposed, none of them seems to need an open issue.

Based on the discussion above, this seems like a likely decline (even though I still don't know exactly what is being proposed).

No change in consensus, so declined.


TOC / Outline

Would it be possible to add a floating TOC/outline similar to RStudio?

REditorSupport/vscode-R#1320


PMID:28476936

terms from @JackyVH  for PMID:28476936
abolished growth during meiotic cell cycle arrest at G2/M1
cellular phenotype where cells enter the meiotic cell cycle and become arrested at the G2/M1 transition. In this situation cells down regulate cellular growth even in the presence of nutrients. This contrasts with a mitotic G2/M arrest where cells continue to grow
elongated cells during meiotic G2/M1 arrest
cellular phenotype where cells arrested at the meiotic G2/M transition are able to over come growth arrest and form elongated cells
increased transcription during meiotic G1/M1 arrest
Cellular phenotype where cells blocked in meiosis at the G2/M1 transition have an increased rate of transcription with an increase in total RNA /cell

abolished growth during meiotic cell cycle arrest at G2/M1

The suggested text def kinda sorta suggests that it's "normal" for cells to stop growing if they happen to arrest at G2/MI. Is that correct? If so, it would probably make more sense to use just "meiotic cell cycle arrest at G2/MI transition" as the term name, and put the part about not growing in synonyms (and the def). On the other hand, if this is a difference from wild type, I'll adjust the def wording to make that clearer.

increased transcription during meiotic G2/M1 arrest

Similarly, is this more transcription than in wild-type cells that somehow get arrested at G2/MI (if that can even happen) or is this a typical feature of cells arrested at that point?

For the first one yes,
"meiotic cell cycle arrest at G2/MI transition"
sounds right.
I will report back on the other one tomorrow, I didn't read that far.

increased transcription during meiotic G2/M1 arrest

Similarly, is this more transcription than in wild-type cells that somehow get arrested at G2/MI (if that can even happen) or is this a typical feature of cells arrested at that point?

my understanding here that it is  really looking at
increased transcription during meiotic
In meiotic arrest, the transcription rate was greater in Sck2-
overexpressing cells than in the control strain (Fig. 4A), indicating
that transcription is more active in the Sck2-overexpressing
strain. Transcription rate normally varies with cell size and
Zhurinsky et al. (2010) reported that cells within a 2-fold sizerange
of the wild type maintain similar transcription rates per μg
protein (Zhurinsky et al., 2010). Sck2-overexpressing cells were
43% larger than control cells at 34°C (Fig. 4B), but the transcription
rate was elevated 5-fold (Fig. 4C).
(The G2 arrest is more a consequence of the background, a condition to observe increased growth where it would not normally exist, but the experiment is aiming only to establish whether transcription is increased compared to WT when Sck2 is overexpressed)

abnormal cell cycle arrest at meiotic G2/MI transition FYPO:0007785
elongated cell with cell cycle arrest at meiotic G2/MI transition FYPO:0007786
increased transcription during cell cycle arrest at meiotic G2/MI transition FYPO:0007787

Can I get back to you tomorrow about this . The important thing is that growth is arrested at the G2/M1 block so I think this needs to be mentioned somewhere  because the rest of the paper identifies genes which when over expressed can overcome the growth arrest
Jacky
Sent from my iPhone
On 7 Jun 2021, at 16:34, Midori Harris @.***> wrote:

External Sender: Use caution.
Closed #4008https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpombase%2Ffypo%2Fissues%2F4008&data=04|01||d6836062dd0a441a6fc108d929c9cd66|4eed7807ebad415aa7a99170947f4eae|0|0|637586768975866014|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=ClXH6XoMyCglKU9kfQ8VQD212V6PMEh4AoZDSHeX%2F5g%3D&reserved=0 via e9ea1c1https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpombase%2Ffypo%2Fcommit%2Fe9ea1c18a69768820f5627f7dc6c64b4a0b98689&data=04|01||d6836062dd0a441a6fc108d929c9cd66|4eed7807ebad415aa7a99170947f4eae|0|0|637586768975866014|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=NJdUSqcueVa3zkJ%2FK68G6epAoV3dYyMw9XKA2FpLznU%3D&reserved=0.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpombase%2Ffypo%2Fissues%2F4008%23event-4852856916&data=04|01||d6836062dd0a441a6fc108d929c9cd66|4eed7807ebad415aa7a99170947f4eae|0|0|637586768975875645|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=0GJFA7W7o2UsYWXuC%2Ba9X80RZEp0h9%2B8ndeJMcH4L3M%3D&reserved=0, or unsubscribehttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FADKVK2DAWXCWS35ETY3AHRDTRTRJ5ANCNFSM45HIDM6A&data=04|01||d6836062dd0a441a6fc108d929c9cd66|4eed7807ebad415aa7a99170947f4eae|0|0|637586768975885637|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=3ls5zEEv8Nvu2S4UJOfoh%2Fvafv%2FTOwP0Q9RQXdBkAg0%3D&reserved=0.
The Francis Crick Institute Limited is a registered charity in England and Wales no. 1140062 and a company registered in England and Wales no. 06885462, with its registered office at 1 Midland Road London NW1 1AT


[LLVM] Fix generation of LLVM intrinsics

The type list in the call to llvm::Intrinsic::getDeclaration is not the intrinsic's signature, it's the list of overloaded types. Without this fix, the updated unit test would cause the following error:
TVMError: LLVM module verification failed with the following errors:
Intrinsic name not mangled correctly for type arguments! Should be: llvm.ctlz.i32
i32 (i32, i1)* @llvm.ctlz.i32.i1

cc @kparzysz-quic please look into the CI problem

Yes, I'm working on it.

I guess I didn't get everything...

The entire tests/python/unittest/test_target_codegen_llvm.py passes for me, I don't know what's going on.  I'll look into it tomorrow.

The CI error was due to a flaky problem which is fixed now

Same failure again: https://ci.tvm.ai/blue/organizations/jenkins/tvm/detail/PR-5282/9/pipeline/152...

OK https://github.com/apache/incubator-tvm/pull/5297 temporary disabled the crt test


InternalError at okhttp3.internal.http2.Http2Connection$ReaderRunnable.applyAndAckSettings

Jul 31, 6:54 PM on app version 73
Xiaomi MI6 (sagit), 6144MB RAM, Android 7.1
Report 1 of 1
java.lang.InternalError:
  at java.lang.Thread.nativeCreate (Native Method)
  at java.lang.Thread.start (Thread.java:730)
  at java.util.concurrent.ThreadPoolExecutor.addWorker (ThreadPoolExecutor.java:941)
  at java.util.concurrent.ThreadPoolExecutor.execute (ThreadPoolExecutor.java:1359)
  at okhttp3.internal.http2.Http2Connection$ReaderRunnable.applyAndAckSettings (Http2Connection.java:693)
  at okhttp3.internal.http2.Http2Connection$ReaderRunnable.settings (Http2Connection.java:665)
  at okhttp3.internal.http2.Http2Reader.readSettings (Http2Reader.java:287)
  at okhttp3.internal.http2.Http2Reader.nextFrame (Http2Reader.java:141)
  at okhttp3.internal.http2.Http2Reader.readConnectionPreface (Http2Reader.java:80)
  at okhttp3.internal.http2.Http2Connection$ReaderRunnable.execute (Http2Connection.java:565)
  at okhttp3.internal.NamedRunnable.run (NamedRunnable.java:32)
  at java.lang.Thread.run (Thread.java:761)

Unless someone else has already taken care of this, I will have a look into this.

Go for it, @Bluesir9 :)

@nicolas-raoul Do we have more details about the issue. The stack trace doesn't lead to any source in the commons app so debugging it won't be feasible.

Any pointers to where it happens would help.

@maskaravivek Sorry I don't have more info, I took this crash from Google Play's crash reports page.
If it is not usable then I guess we can close it, if someone gets the same issue a Google search might lead them to this page anyway. Anyone having this problem, please explain how you get it, with what version of the Commons app, thanks!

okhttp3.internal.http2.Http2Connection$ReaderRunnable.applyAndAckSettings (Http2Connection.java:739)
okhttp3.internal.http2.Http2Connection$ReaderRunnable.settings (Http2Connection.java:711)
okhttp3.internal.http2.Http2Reader.readSettings (Http2Reader.java:289)
okhttp3.internal.http2.Http2Reader.nextFrame (Http2Reader.java:141)
okhttp3.internal.http2.Http2Reader.readConnectionPreface (Http2Reader.java:80)
okhttp3.internal.http2.Http2Connection$ReaderRunnable.execute (Http2Connection.java:609)
okhttp3.internal.NamedRunnable.run (NamedRunnable.java:32)


Develop

@probuse
@millymelisa97
@anyric
@cnagadya
#Whats this PR do?
static web pages for recipes app
Please review my repo

Great work.


Include Notebook API into lite kernel deployment

why do we need to rebuild the extension and install from source? IIRC i downloaded the artifact from previous step and install the whls directly

Ah indeed I could install the whl directly, but that's not what's being done currently

Ah indeed I could install the whl directly, but that's not what's being done currently

it is done here https://github.com/jupytercad/jupytercad/blob/aaf0e39e9ce0e67877ee0c073d32dca808d6811d/.github/workflows/build.yml#L224 ?

The only impact of this will be the installation of the labextensions in the build environment, then JupyterLite will pick up automatically those labextensions and include them in the lite build.
But it will not install the Python package in the kernel runtime.

This is just me trying things, I believe the notebook API should be able to open document shared models as we're going through comms with ypywidgets and not using server component. But let's try!

Closing as it's apparently not possible to make this work unless the tokens for collaboration are on.

For the record, this is what I get:

There is no error in the console whatsoever.

there is no 3d view in notebook?

Yep, I'm not sure where it's blocking here:

you might need to set up a dev version of yjs-widgets to debug it.


samples: adds samples for commit stats

Adds samples for commit stats.

We need to wait for the snippets BOM to be updated to the version that contains the commit stats changes (>= 4.0.0) before we can merge this PR.


Unit test our dependencies

...because they clearly aren't doing it themselves.

cf ionspin/kotlin-multiplatform-bignum#291 and ionspin/kotlin-multiplatform-bignum#292

ship it


Adapter crashes (locs is not iterable)

Describe the bug
After several days (or sometimes hours), the adapter crashes many times in a row and iobroker shuts it down due to too many failures. It happens without any user or script interaction.
Expected behavior
Either locate and fix the cause or implement a delay so that problems on the API endpoint won't cause a deactivation of the instance.
Screenshots & Logfiles
`

host.iobroker
2022-10-16 00:51:15.840
error
instance system.adapter.ring.0 terminated with code 6 (UNCAUGHT_EXCEPTION)

ring.0
2022-10-16 00:51:15.165
warn
Terminated (UNCAUGHT_EXCEPTION): Without reason

ring.0
2022-10-16 00:51:15.155
error
locs is not iterable

ring.0
2022-10-16 00:51:15.154
error
TypeError: locs is not iterable at RingApiClient.retrieveLocations (/opt/iobroker/node_modules/iobroker.ring/build/lib/ringApiClient.js:110:27) at processTicksAndRejections (node:internal/process/task_queues:96:5) at async RingApiClient.refreshAll (/opt/iobroker/node_modules/iobroker.ring/build/lib/ringApiClient.js:67:9) at async RingApiClient.init (/opt/iobroker/node_modules/iobroker.ring/build/lib/ringApiClient.js:54:9) at async RingAdapter.onReady (/opt/iobroker/node_modules/iobroker.ring/build/main.js:80:9)

ring.0
2022-10-16 00:51:15.153
error
unhandled promise rejection: locs is not iterable

ring.0
2022-10-16 00:51:15.153
error
Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().

ring.0
2022-10-16 00:51:15.147
error
Api Call failed

host.iobroker
2022-10-16 00:51:10.898
error
instance system.adapter.ring.0 terminated with code 6 (UNCAUGHT_EXCEPTION)

ring.0
2022-10-16 00:51:10.284
warn
Terminated (UNCAUGHT_EXCEPTION): Without reason

`
Versions:

Adapter version: 3.1.3
JS-Controller version: 6.2.23
Node version: 16.17.1
Operating system: Ubuntu

Additional context
I'm using three stick up cameras and one v1 doorbell.

exactly the same issue.
<EMAIL_ADDRESS><EMAIL_ADDRESS>Operating system: rasbian (debian bullseye)
iobroker in docker container: iobroker/iobroker:v7.0.0-arm32v7
iobroker.info:
Plattform: docker
Betriebssystem: linux
Architektur: arm
CPUs: 4
Geschwindigkeit: 600 MHz
Modell: ARMv7 Processor rev 4 (v7l)
RAM: 922.1 MB
System-Betriebszeit: 15:33:26
Node.js: v16.17.0
time:<PHONE_NUMBER>466
timeOffset: -120
Adapter-Anzahl: 443
NPM: 8.15.0
Datenträgergröße: 58.2 GB
Freier Festplattenspeicher: 47.0 GB
Betriebszeit: 15:19:18
Aktive Instanzen: 9
Pfad: /opt/iobroker/

Might be due to https://github.com/dgreif/ring/issues/1071
I changed the code, to retry reconnecting after 5 Minutes in case the initial connection on adapter start was successful


Fix less-than-helpful link to installing Python bindings

The download-python-bindings.md macro used in integrations like /integrations/doc/hg on /integrations doesn't link to the Python version of the bindings
@YagoGG this is a pretty important issue.

@zulipbot claim.

@alexanderon1 I added the "help wanted" label, feel free to claim.

@eeshangarg this may be a great small project for you; I think basically we want to have  templates/zerver/help/include/download-python-bindings.md link to instead /api/installation-instructions#python , and then fix the JS to have that actually show the "Python" tab.


chore(sqllab): Typescript for SqlEditor component

SUMMARY
This commit migrates SqlEditor jsx to tsx along with all associated type updates.
TESTING INSTRUCTIONS
npm run type
ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Required feature flags:
[ ] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

@michael-s-molina could you review the update again?


Add metadata to the wallet

right now there is no metadata functionality in the wallet

pending mockup / integration flow design

There are three types of metadata: accountMetadata, masaicMetadata, and nameSpaceMetadata.
Metadata as tags can be distributed among the modules of account, masaic, and mamespace, but the meaning of doing so is not obvious. So centralize it in one place for easy management.
The user can create metadata and may accept metadata from various accounts, which I incorporate into a table and want to complete filter with targetaddress.
The interaction design model is as follows：

Main page and program entry

2.View the specific data for each metadata by key

3.Metadata operation forms

look forward to more coments.
thank you

Thanks, @jabo38 for reporting this, Note that the latest release has metadata for Account / Mosaic / Namespace.


Data Analysis

I plotted the the data for resident and citizen status emigrants on the world map and also plotted a graph showing the relationship between GDP of the origin countries and number of emigrants from those countries from 2014-2019. Also deleted the unwanted dataset copies.

Maybe change the plot into a bubble plot, the plot of the Gdp and the number of emigrants

I have updated the code. Added a scatterplot with bubbles.

Missing country names.


QoL: OOT Fast Armos Statue Pushing

What it says in the title. OOT has some Armos statues that players use for some tricks and casual players may appreciate the instances they need to move the Armos statue (such as in Dodongo's Cavern for the switch on 2F). This recently got a PR in OOTR that is probably being merged: https://github.com/OoTRandomizer/OoT-Randomizer/pull/1981

Closed in #439


[SPARK-8563] [MLlib] Fixed a bug so that IndexedRowMatrix.computeSVD().U.numCols = k

I'm sorry that I made https://github.com/apache/spark/pull/6949 closed by mistake.
I pushed codes again.
And, I added a test code.

There is a bug that U.numCols() = self.nCols in IndexedRowMatrix.computeSVD()
It should have been U.numCols() = k = svd.U.numCols()

self = U * sigma * V.transpose
(m x n) = (m x n) * (k x k) * (k x n) //ASIS
-->
(m x n) = (m x k) * (k x k) * (k x n) //TOBE

Can one of the admins verify this patch?

@lee19 Thanks for the PR!  Those 2 issues should be quick to fix.  But please run the tests locally before updating to make sure the update works.

OK to test

LGTM

Test build #963 has started for   PR 6953 at commit 4b9803b.

Test build #963 has finished for   PR 6953 at commit 4b9803b.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

I'm very sorry for build errors. :flushed: I should have spent time on it at least.
And, I'm sorry again for the failure of unit test this time.
I can't run unit tests locally, yet, because
spark/mlib$ ../build/mvn test is being stuck at LogisticRegressionClusterSuite because of OutOfMemoryError.
Let me tell you after I finish it.

@lee19 can you update this per the comment about nRows? I am not sure why your test failed since it looks correct, as does your change. Yes maybe you can run just that test locally to figure out what's going on.

I just confirmed spark$ build/mvn -pl mllib -Pyarn -Phadoop.version=2.4 -DwildcardSuites=org.apache.spark.mllib.linalg.distributed.IndexedRowMatrixSuite test passed locally.
I don't know, neither, why the test build 963 of SparkQA failed few days ago.
@mengxr Thanks for the suggestion!

Test build #985 has started for   PR 6953 at commit c1812a0.

Test build #985 has finished for   PR 6953 at commit c1812a0.

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

LGTM. Merged into master and all branches since 1.0. Thanks!!


Docs: NetworkTransform

https://github.com/vis2k/Mirror/blob/master/docs/Components/NetworkTransform.md
This page needs rewritten with new screen shots for the changes made to NetworkTransform.

@vis2k This is all you, mate!

done


controllers: enforce host NW configuration on CSI controller plugin pods

when using a dedicated network for ocs, storage client enforce host network configuration on csi controller plugins

RHSTOR-6363


Move to dots

For a while, I have wanted to clean up my dotfiles. dots seemed like the appropriate avenue and it still does.
https://github.com/Ceasar/dots

We've more/less landed on a system that works for us. i.e. Treating this as a reference where we symlink some pieces, but everything else is more of a documentation runbook


AB#38712 Check user resource ownership

Overview
Using the user's passed in Graph delegated token, I retrieved the tenantId and user id from the token. The purpose of this PR is to use the token and the user id to make a graph call to check if the resource (teams or chat) that the client is trying to make a request on is owned by the user.
Testing Instructions
NOTE: Alot of overhead is required to test this PR. to make it easier, ping me on Teams for a ClientId and ClientSecret to avoid registering an app and installing a Teams app on a test tenant with the same ClientId.

Open the file appsettings.json
In ClientId, paste the clientId of your app registration
In ClientSecret, paste the client secret of your app registration
Head over to Graph Explorer
Go to Access token and copy the access token
Run the branch locally and open Postman
Add your access token that was copied from GE into the Authorization tab as a 'Bearer Token'
Make a call to the API using the endpoint /graphproxy/{ADD YOUR GRAPH QUERY HERE}. Example: /v1.0/teams/{team-id}/channels
Make sure its a Graph call on a Teams resource (Team or Chat) that you are a owner of and have the GE Teams app (with the same client Id as the you pasted in appsettings.json) installed on (in order for the Graph request to work)

@gracet9182 That is also expected behaviour, From the screenshot the call was done using Graph v1.0 and currently RSC permissions for chats (correct me if I am wrong) are mostly in beta. So this 403 error you are receiving is directly from Graph.

Talked to Omer about my error. The solution was to input a random guid into appsettings for tenantId - might be something that can be fixed as a bug later but this seems to work!


Redirect the user to the signup page in the welcome message flow

Remove unwanted flow steps and rename the button to Signup instead of Contact us. Also welcome message translation for other languages should be updated.
our-city-app/oca-backend#283
Related (should be merged first):

our-city-app/oca-backend#307

The functionalities page might have a bit more margin, to match the spaces in the design
Enable hover event on the orange "you still need to publish" info buttons
The login page doesn't allow me to use my (already existing) 5-characters long password


Update the license and Name field to generate the docs

cc @lilyclemson

It's ready to merge. Can you please review? @ghalliday


Replace Microsoft Soundscape logo/name on first-launch tutorial

Fixes #18

Given the intention to use the Soundscape for Everyone logos, we probably should not merge this PR. But at least we now know where the logos were hiding.


minChars

hi everyone,
There is a minChars options ?
Thanks
Federico

@federicolucca there isn't but I used the beforeItemAdd event to disallow any tag with less than 3 characters:
$('#tagsInput').on('beforeItemAdd', function(event) {
    if (event.item.length < 3) {
        event.cancel = true;
    }
});

@rswhite7 where is put it in code

@rswhite7  where is to put it ?


1.65.01 and 1.65 on maven central

Hello,
we've noticed that there are 1.65.01 and 1.65 on maven central.
https://search.maven.org/artifact/org.bouncycastle/bcprov-jdk15on
releases page here (https://github.com/bcgit/bc-java/releases) only shows 1.65
Is 1.65.01 a different release?

It's a patch release on 1.65 fixing a regression detailed in https://github.com/bcgit/bc-java/issues/682
If it's not an issue for you I would wait for 1.66, which will be coming out in July.

ok, thanks for the information!


set PATH environment variable for Windows

Windows uses Path instead of PATH which causes a notice for the about and download command.

@sstok thanks for this improvement. It looks totally safe to merge it, but since I'm not a Windows user, I prefer to wait until any Symfony developer with Windows experience (e.g. @stof or @WouterJ) confirms it. Thanks for your patience.

I personally use Windows 7 as my dev environments, and it has never caused me any problem... :confused:

I personally use Windows 7 as my dev environments, and it has never caused me any problem... :confused:

@javiereguiluz I can confirm that this PR is correct (@sstok and me actually created this PR when helping a windows users with this error)
@Pierstoval the path env is only used by the command in the help message (if you run symfony) or if there was an error during the download. That might explain why you didn't see this message.

@WouterJ thanks for reviewing this change and thanks again to @sstok for improving the installer


Link session and protocol

Whie #71 failed, I sill not gave up with idea to do something with long too handler method definitions. What about linking protocol and session together? They are having one lifecycle, and very similar. Protocol instance not used in handlers, and I have no idea why it may be used in handlers. But I want to have all data be accessable from handlers, so, may be good idea is hide protocol object (dont know why it is called "server") and put it on session as a field. That will make handlers definitions more compact and free from useless variables.

@kozzztik Sorry, but this branch has drifted pretty far out of date now.  I'm still not entirely convinced these should be linked.  But if you still feel strongly about it, please do reopen, resolve conflicts, and/or propose a new PR.


Add Czech holidays

There seems to be problem with encoding in pest's snapshot. Same problem is in Austria's snapshot (main branch) or pull requests from other countries, so I am creating a pull request anyway.

Thanks!


BN Fixes

There are some subtle issues with how BatchNorm is handled in the PyTorch version of the code. Currently, workload.model_fn has an update_batch_norm parameter, which in theory should allow the submission to control whether the batch-norm statistics are updated during a forward pass. The issues are the following:

The update_batch_norm_fn function stores the old momentum parameter for each batchnorm layer in a momentum_backup  variable, so it can be restored later, before zeroing the parameter. However, if it is called with update_batch_norm=False twice in a row, it overwrites the momentum_backup with 0 on the second call, so momentum then remains zero for the remainder of training.
In PyTorch's bultin BatchNorm, 0 indicates that the momentum buffer shouldn't be updated. This is the opposite of how EMA momentum is usually done (i.e. in Adam), where 1 would indicate that it shouldn't be updated, and 0 means it's set to the latest value at every step. The custom BatchNorm modules used in the two librispeech workloads follows this second, more standard convention instead. However, the update_batch_norm_fn sets the momentum to zero for all three layer types, resulting in incorrect behavior for the librispeech workloads.
The update_batch_norm_fn sets the BN layers to eval mode. This doesn't make sense as it prevents the use-case where you use batch-computed statistics (train mode) without also updating the running statistics. The BN layers can bet set to eval mode separately by passing in ForwardPassMode.EVAL to the forward pass, so removing this .eval() call doesn't prevent the submission from using eval mode during a forward pass.

This PR changes switch the custom BN code to follow the BN convention so that momentum=0 doesn't update the running buffers. It also fixes the issues in the update_batch_norm_fn function mentioned above.

Thanks for spotting all these issues. I agree, we should incorporate these fixes.
I spotted one more subtle issue in our JAX code similar to 3 here.
  def __call__(self,
               x: spec.Tensor,
               update_batch_norm: bool = True) -> spec.Tensor:
    conv = functools.partial(nn.Conv, use_bias=False, dtype=self.dtype)
    norm = functools.partial(
        nn.BatchNorm,
        use_running_average=not update_batch_norm,
        momentum=0.9,
        epsilon=1e-5,
        dtype=self.dtype)

This prevents the use case  where you want to use the running average in train mode but not update the batch_norm. Maybe we need an extra arg in the call functions to distinguish between train and eval mode instead of inferring them from the update_batch_norm arg?

recheck


Provide a mechanism and/or pattern for easy pagination

Update the sample to demonstrate with a list containing a few thousand items.

Any progress in pagination?
Can I use pagination with current sqlbrite?

@rafaelekol SqlBrite allows you to use raw SQL -> you can use LIMIT limit_value OFFSET offset_value feature of SELECT in SQLite.
Or you want to use pagination via Observable emission: for example emission0(LIMIT 100 OFFSET 0), emission1(LIMIT 100 OFFSET 100), emission2(LIMIT 100 OFFSET 200), etc?

OK noted,
thanks Artem

We have an endless scroll list in our app. Can we use SQLBrite for such scrollList?

@artem-zinnatullin have you used that 'emission' pattern for backing an Adapter?
did you have any problems with multiple Subscriptions + multiple simultaneously opened Cursors?

@adelnizamutdinov no, I don't see problems with multiple Subscriptions and multiple simultaneously opened Cursors.
Notice: I don't use SqlBrite, so I can make some mistakes.
I see two ways of implementing endless scroll list with RxJava and SqlBrite.
First variant: Reactive Pull, but SqlBrite actually not very helpful here, you can use plain SQLiteDatabase.query() or rawQuery() for that.
// pseudo code
Observable.create(subscriber -> {
  int offset = 0;
  Cursor cursor;

  do {
    cursor = sqlBrite
      .createQuery("SELECT * FROM tweets LIMIT 100 OFFSET ?", offset)
      .map(query -> query.run())
      .toBlocking();
      // You can use flatMap and call subscriber.onNext(query.run()) from it
      // But you should use serial Scheduler to guarantee order of emission.
      // To simplify the solution, I'll use imperative way instead of functional.

    offset += cursor.getCount();

    subscriber.onNext(cursor);
  } while (cursor.getCount > 0);

  subscriber.onCompleted();
})
.subscribeOn(io())
.observeOn(mainThread())
.subscribe(new Subscriber() { // yes, you need to use Subscriber.
  @Override public void onStart() {
    request(1); // Reactive Pull: Requesting only one item.
  }

  @Override public void onNext(Cursor cursor) {
    adapter.addCursor(cursor);
    // next call to request(1) should happen when list is near to the end
  }
});

But:

You can not subscribe to changes of tables directly in the paginated query with this solution, because notifications can blow order and content of emissions , so you'll have to monitor it externally and re-execute this Observable.
You should keep in mind that this implementation won't make your Observable lazy, it'll execute all queries when Subscriber will subscribe to it and Subscriber's Provider would store all emissions in Queue and pass it to you as you request, so it won't be as much faster and resource cheaper than one request without pagination.

Second variant: Pagination without Reactive Pull
// pseudo code

// Fragment/Activity/Presenter
class SomeUiController {

  void onNearToEndOfList() {
    loadMoreData(list.getItemsCount())
      .observeOn(mainThread())
      .subscribe(cursor -> adapter.addCursor(cursor));
  }

  @NonNull
  public Observable<Cursor> loadMoreData(int offset) {
    return sqlBrite
      .createQuery("SELECT * FROM tweets LIMIT 100 OFFSET ?", offset)
      .map(query -> query.run())
      .subscribeOn(Schedulers.io());
  }
}

And Adapter implementation:
// pseudo code
class EndlessAdapter extends RecyclerView.Adapter {

  @NonNull
  private final List<Cursor> cursors = new ArrayList<>();

  public void addCursor(@NonNull Cursor cursor) {
    cursors.add(cursor);
    notifyDataSetChanged();
  }

  public void removeCursor(@NonNull Cursor cursor) {
    cursors.remove(cursor);
  }

  @Override
  public int getItemsCount() {
    int totalCount = 0;

    for (int i = 0, count = cursors.size(); i < count; i++) {
      totalCount += cursors.get(i).size();
    }

    return totalCount;
  }

  // I am not sure that implementation is 100% correct, please add tests.
  @NonNull
  Cursor getCursorByItemPosition(int itemPosition) {
    int offset = 0;

    for (int i = 0, count = cursors.size(); i < count; i++) {
      final Cursor cursor = cursors.get(i);

      if (itemPosition >= offset && itemPosition < offset + cursor.getCount()) {
        cursor.move(offset - itemPosition);
        return cursor;
      }

      offset += cursor.getCount();
    }

    throw new IllegalArgumentException("Can not find cursor for requested item position: " + itemPosition);
  }

  public void onBindViewHolder(@NonNull ViewHolder viewHolder, int position) {
    final Cursor cursor = getCursorByItemPosition(position);

    // display the data from cursor.
  }
}

Notice: you MUST update cursors in the adapter if data in the db was changed, otherwise pagination can produce problems with displaying one item several times in case when data was added or not displaying item in case when date was removed:
Item was added:
Time0: Data in db: (item0, item1, item2, item3, ..., item100)
Ui:
Time1: Limit 4, Offset 0, Data in list (item0, item1, item2, item3)
Time2: Data update (item2' was added between item2 and item3)
Time3: List scrolled down, loading more…
Time4: Limit 4, Offset 4, Data in list (item0, item1, item2, item3, item3, item4, item5, item6)
// item2' won't be displayed!
// item3 will be displayed twice!
Item was removed:
Time0: Data in db: (item0, item1, item2, item3, ..., item100)
Ui:
Time1: Limit 4, Offset 0, Data in list (item0, item1, item2, item3)
Time2: Data update (data3 was removed)
Time3: List scrolled down, loading more…
Time4: Limit 4, Offset 4, Data in list (item0, item1, item2, item3, item5, item6, item7, item8)
// item3 won't be removed from the list!
// item4 won't be displayed!
As you can see, I am not a big fan of pagination -> it requires too much code and can produce hard-debuggable bugs.
When data set is really huge (for example several thousands of items), you can make one request to load all ids of the items and then load each item's data synchronously or asynchronously in the adapter's bindViewHolder()/getView(), but yes, sometimes pagination is really required.
I don't see how to integrate observing changes in tables with pagination in one Observable.

Any update on this please ?

+1, thanks

Isn't a simple Cursor sufficient for this?, i.e., a SQLite based cursor using something like 'SELECT * FROM  ORDER BY  DESC"? and then use something similar to a CursorAdapter which will be updated on  notifications to the subscriber?
since cursor doesn't retrieve all the data into memory at once, this would scale well for thousands of items, no?

this is not SQLBrite specific but i think this should do https://gist.github.com/mttkay/24881a0ce986f6ec4b4d

Google is releasing a thing for this. No action to take.