Chat - Errors appear after sending a message to the non existent user

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Create group chat with 2 non-existed users
Send some messages
Navigate to the one of the users 1:1 chat and send message

Expected Result:
The user should be able to send msg to the not existed email account without issues
Actual Result:
Can’t send message because of error, gray 1:1 chat in the LHN stays forever
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

Version Number: <IP_ADDRESS>
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://user-images.githubusercontent.com/93399543/234853547-f1d9073e-48bc-47ce-9c93-61ca34811cd0.mp4
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
View all open jobs on GitHub

Triggered auto assignment to @joekaufmanexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

Bug0 Triage Checklist (Main S/O)

[ ] This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
[ ] This bug is not a duplicate report (check E/App issues and #expensify-bugs)

If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead

[ ] This bug is reproducible using the reproduction steps in the OP. S/O

If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
If the reproduction steps aren't clear and you determine the correct steps, please update the OP.

[ ] This issue is filled out as thoroughly and clearly as possible

Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.

[ ] I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

@kbecciv I was unable to reproduce this on my end, per the below video. I was able to chat individually either of the two emails that I used in the DM (both of which are not real emails) without receiving an error.
Going to close this for now, since it doesn't appear to be reproducible, but feel free to re-open if you can still reproduce it in this/another account, and happy to have a second triager try to reproduce.
https://user-images.githubusercontent.com/54866469/235193995-3d0af263-109d-4b46-ab22-502c68738c44.mp4


Y Axis scale - of Single Bar chart

Expected Behavior
1.Its a simple bar chart ,Need to fix the y axis to min : 0 and max: [max value as per dataset]
2.Need to add % next to numerical on y-Axis
3.Some times need to convert huge numerical from 1000000 = 1M on Y-Axis
4.Can we display values inside the bars ?
Current Behavior
The single bar chart is considering the y axis as  min : min value of dataset  and max : max : min value of dataset

Possible Solution

Steps to Reproduce (for bugs)
https://github.com/navaneesh007/ChartJS/blob/master/Bar chart/bar.html
Context
Visualization and requirement is not met
Environment

Chart.js version:2.4.0
Browser name and version: chrome :55
Link to your project: https://github.com/navaneesh007/ChartJS/blob/master/Bar chart/bar.html

Question 1
You need to use the ticks.beginAtZero setting for the axis
new Chart(ctx, {
  type: 'line',
  data: data,
  options: {
    scales: {
      yAxes: [{
        ticks: {
          beginAtZero: true
        }
      }]
    }
  }
});

Question 2&3
The solution here is to add a callback function that does custom formatting
new Chart(ctx, {
  type: 'line',
  data: data,
  options: {
    scales: {
      yAxes: [{
        ticks: {
          callback: function(tickValue, index, ticks) {
            // return string here for tick value
          }
        }
      }]
    }
  }
});

Question 4
See https://github.com/chartjs/Chart.js/blob/master/samples/data_labelling.html

Thanks alot @etimberg for your support .Kindly guide me here
For Answer 4
https://github.com/chartjs/Chart.js/blob/master/samples/data_labelling.html
Values are displayed in one color .How to make them relative to there bar or line color ??

You need to change https://github.com/chartjs/Chart.js/blob/master/samples/data_labelling.html#L83 with something that looks up the colour.
If you're chart looks like
new chart(ctx, {
  type: 'line',
  data: {
    datasets: [{
      backgroundColor: 'red' // for example
    }]
  }
});

Then you could access that on the line I mentioned above as dataset.backgroundColor. You could easily add some custom properties to the datasets and use them for these labels


x/build: add LUCI openbsd-riscv64 builder

Please add a LUCI builder for openbsd/riscv64 with hostname openbsd-riscv64-jsing - note that this will be running on the same hardware as the current host-openbsd-riscv64-joelsing builder. This machine is unlikely to be capable of running both forms and will need to be hard migrated at some point in time. CSR for this builder is attached.
openbsd-riscv64-jsing.csr.txt

Here's the certificate: openbsd-riscv64-jsing-1715630475.cert.txt.
Please feel free to stop the old coordinator builder on your end whenever it's getting in the way of bringing up the new LUCI builder.

@dmitshur - thanks, this one should be up and running, although I have no idea how to confirm this (it logs nothing except for the occasional RPC error).

Thanks for setting it up! I see it at https://ci.chromium.org/ui/p/golang/builders/luci.golang.ci/gotip-openbsd-riscv64?limit=200 and https://chromium-swarm.appspot.com/bot?id=openbsd-riscv64-jsing. In a recent build like https://ci.chromium.org/b/8747215393872298177, I see it failed during cipd ensure on fetching the bootstrap toolchain. Sent CL 588356 for that.

Looking at the most recent builds, make.bash is now successfully completing but taking 1.1-1.2 hrs to do so. That seems quite long for make.bash alone—is it expected? It's then consistently timing out during the "upload prebuilt go" step, taking over 7 minutes. (This step should complete in under a minute with fast upload speeds, or at least within a few minutes.)

Looking at the most recent builds, make.bash is now successfully completing but taking 1.1-1.2 hrs to do so. That seems quite long for make.bash alone—is it expected?

@dmitshur - Yes, a make.bash run on this machine is around 45 minutes when nothing else is running.

It's then consistently timing out during the "upload prebuilt go" step, taking over 7 minutes. (This step should complete in under a minute with fast upload speeds, or at least within a few minutes.)

They are in a fairly network constrained environment - download speeds are acceptable, upload is severely limited (plus the RTT to the US is fairly high, which is where I presume it's trying to upload to). The existing builders do not upload snapshots for these reasons:
https://github.com/golang/build/blob/master/dashboard/builders.go#L2075

@4a6f656c You mentioned the hardware might not be capable of running both builder workloads at once, and the results above agree. Can you try stopping the old builder to see how the LUCI one works when it's the only one running?

It will make the builds slightly faster, however it will not help the upload issue...

@dmitshur what are the next steps here? How do we disable snapshot uploads for these builders?

That mechanism isn't currently available for LUCI builders.
Without snapshots, and with make.bash taking 45 minutes, it makes testing golang.org/x repos slower and use more resources, but I understand you're willing to accept that trade-off if the upload speed is a hard constraint that you don't have control over. I see that the old coordinator builder was configured to only test x/net and x/sys, and only at tip without any of the release branches (see here). Given the above, is that configuration something you'd need to be incorporated as well?
I added a note so we'll discuss this with the team next week.

@dmitshur I've installed a secondary Internet connection, which should provide sufficient upload bandwidth - a successful run appears to have occurred for x/sys, however everything since then has failed with a similar "CAS failed" error:
https://ci.chromium.org/ui/p/golang/builders/ci/gotip-openbsd-riscv64/b8744932690088854977/overview
https://logs.chromium.org/logs/golang/buildbucket/cr-buildbucket/8744932690088854977/+/u/step/6/log/2
No idea what that means or what would be causing that (overall this seems to be one of the more convoluted and opaque systems I've worked with... no mention of URLs or how to reproduce the issue to troubleshoot it):
[E2024-06-17T12:44:06.237606+10:00 57136 0 annotate.go:273] original error: retry budget exhausted (6 attempts): context deadline exceeded

goroutine 1:
#0 go.chromium.org/luci/client/cmd/cas/casimpl/download.go:515 - casimpl.(*downloadRun).doDownload()
  reason: failed to download files

#1 go.chromium.org/luci/client/cmd/cas/casimpl/download.go:574 - casimpl.(*downloadRun).Run()
#2 github.com/maruel/subcommands@v1.1.1/subcommands.go:395 - subcommands.Run()
#3 cas/main.go:95 - main.main()
#4 runtime/proc.go:271 - runtime.main()
#5 runtime/asm_riscv64.s:540 - runtime.goexit()
cas: failed to download files: retry budget exhausted (6 attempts): context deadline exceeded

Any suggestions?

In case you haven't already seen it, there is open source documentation for the Swarming Bot at https://chromium.googlesource.com/infra/luci/luci-py.git/+/main/appengine/swarming/doc/Bot.md.
The "original error: retry budget exhausted (6 attempts): context deadline exceeded" error reads to me that the time it has taken exceeded the deadline that was given. This is consistent with the task 6 min 40 sec, which is longer than the same task takes on most other builders. You mentioned only the uplink speed was increased, whereas the failed task was "fetch prebuilt go" whose speed would depend on the downlink speed.
We discussed this in a meeting and we're okay with maintaining support for disabling prebuilt toolchain uploads and downloads. I'm not sure how soon we can implement it ourselves, but it can happen sooner if you're willing to work on it. It'd be best to file a separate issue for it for tracking purposes. Also note that it's expected the x/ repo builds will be slowed by the 45 min toolchain build each time, but I understand that's a trade-off you're okay with. You can consider possibly caching prebuilt toolchains locally.

In case you haven't already seen it, there is open source documentation for the Swarming Bot at https://chromium.googlesource.com/infra/luci/luci-py.git/+/main/appengine/swarming/doc/Bot.md.

I wasn't aware of that, thanks.

The "original error: retry budget exhausted (6 attempts): context deadline exceeded" error reads to me that the time it has taken exceeded the deadline that was given. This is consistent with the task 6 min 40 sec, which is longer than the same task takes on most other builders. You mentioned only the uplink speed was increased, whereas the failed task was "fetch prebuilt go" whose speed would depend on the downlink speed.

Sure, but deadline exceeded to download what? If I knew what the URL was or a command to reproduce the download, it would have been much easier to troubleshoot further. The secondary Internet connection is faster on both downlink and uplink - given the above information, I've made some further network changes to increase the download capacity available to the builders:
...
Requesting https://dl.google.com/go/go1.22.4.linux-amd64.tar.gz
...
68964131 bytes received in 41.01 seconds (1.60 MB/s)

We discussed this in a meeting and we're okay with maintaining support for disabling prebuilt toolchain uploads and downloads. I'm not sure how soon we can implement it ourselves, but it can happen sooner if you're willing to work on it. It'd be best to file a separate issue for it for tracking purposes. Also note that it's expected the x/ repo builds will be slowed by the 45 min toolchain build each time, but I understand that's a trade-off you're okay with. In theory, it's possible for you to consider a mechanism to locally cache prebuilt toolchains as a means of speeding that up without needing to go over the internet.

Thanks, I'm hoping that with the secondary Internet connection this is no longer necessary. I'll start swarming again and see how much progress we make.

Sure, but deadline exceeded to download what? If I knew what the URL was or a command to reproduce the download, it would have been much easier to troubleshoot further.

Note that the exact "cas download ..." command with all command line flags and environment variables is shown here:
https://logs.chromium.org/logs/golang/buildbucket/cr-buildbucket/8744932690088854977/+/u/step/6/log/1
From this link:

The exact "cas download" invocation is constructed in golangbuild. The source for that is linked here. Here's where the "fetch prebuilt go" step is defined and the command it runs:
https://source.chromium.org/chromium/infra/infra/+/main:go/src/infra/experimental/golangbuild/prebuilt_go.go;l=160-197;drc=816bca63478e90d97e316b342c14bb6971b56848
That particular prebuilt toolchain seems to be around 265 MB, so at 1.6 MB/s it should complete in under 3 minutes, which should hopefully be quick enough not to timeout. (I'm also starting to think we could increase cas download timeout if needed.)

@dmitshur thanks for providing the additional pointers for troubleshooting.
After some further adjustments to the environment, it seems that we're now running reasonably stably for openbsd/riscv64 on LUCI:
https://ci.chromium.org/ui/p/golang/g/port-openbsd-riscv64/builders
Do we want to cut over the build dashboard?

Congrats on reaching this point!

Do we want to cut over the build dashboard?

Are you referring to removing the known issue for the builder at https://cs.opensource.google/go/x/build/+/luci-config:main.star;l=486 (similar to CL 596817)? Yes, sounds good, please feel free to send a CL.

Are you referring to removing the known issue for the builder at https://cs.opensource.google/go/x/build/+/luci-config:main.star;l=486 (similar to CL 596817)? Yes, sounds good, please feel free to send a CL.

I'm referring to the fact that the LUCI builder is not the one that shows up on https://build.golang.org/ (it's still the old builder, which is currently turned off). I can send a CL to remove the known issue for this builder - is that also going to result in it becoming visible on the dashboard?

Yes, LUCI builders with a known issue aren’t shown on the build.golang.org dashboard, so removing its know issue will make it visible. Thanks. You can also add an entry to a BuildersPortedToLUCI to hide the old builder from there.

@dmitshur - I think we're going to need to reduce the builds back to what they were previously (gotip, net and sys IIRC) - building and testing gotip takes ~2 hours, which means that by the time we add in Go 1.23, x_tools-gotip and x_tools-go1.23 (all around 2 hours each), we're already up to 8+ hours (that means less than three gotip builds make it to build.golang.org in a day).
How can we restore the previous build behaviour?

Checking in on the status here. Did the comment above resolve the need to make further changes, or would you still like to pursue that?
The builder appears to be missing now (https://ci.chromium.org/ui/p/golang/g/port-openbsd-riscv64/builders), and the last build was in September (https://ci.chromium.org/b/8735431351491753009). Are you able to take a look?


🐛 Logout Callback not working

When attempting to logout, I'm shown the logout callback page, but am not logged out :)
Logged in with: Google,
Browser: Chrome

https://github.com/dotnet/aspnetcore/issues/40046

@Hona https://github.com/dotnet/aspnetcore/issues/40046#issuecomment-1512344993


⚠ Bofrost.fr has degraded performance

In f037afe, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1700 ms

Resolved: Bofrost.fr performance has improved in 28021d6 after 6 minutes.


Bug: Unable to build AUR packages that depend on other AUR packages

When trying to build a package that has another AUR package as its dependency, a error message will be printed that is saying that pacman is unable to locate the package. I assume the backend calls pacman directly instead some AUR helper?

At the moment I first download the build-script from AUR and then use makepkg to build the package.
I don't have any dependency resolution from aur for now. So you would have to install the dependencies first and then the main package for version solving to work. (Thats why I have added localhost in the repos of the container)


Control which cursor is the reference for intellisense suggestions when there are multiple simultaneous cursors in a snippet

For brevity lets have a completely useless and dumb scenario:
class Constants {
  static final value1 = "value1";
  static final value2 = "value2";
}

I'd like to have a snippet for this, which is something like:
final $0 = Constants.$0;

Observed
I am getting suggestions for the first cursor

Desired
Get suggestions from here. And obviously have value1 as variable name as well upon selecting it

I also tried the snippet as
final ${0:$1} = Constants.$1;

and also tried applying a transformation to it, but it makes no difference.

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

:slightly_frowning_face: In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.
Happy Coding!


turnstile

I watched endless attempts to solve the turnstile on https://nopecha.com/demo/cloudflare. Before that everything worked like clockwork!
Version 1.3.20
Google Chrome 131.0.6778.204

Did you use a proxy?

Sure

is that rotated? that's should be the problem, i got the sam problem weeks ago even when i try it manually using VPN i still can't pass the  turnstile. I think they detect something related to IP?

is that rotated? that's should be the problem, i got the sam problem weeks ago even when i try it manually using VPN i still can't pass the  turnstile. I think they detect something related to IP?

Today it works!

It looks like the reason was await protectPage(page,{webRTCProtect:true});
https://www.npmjs.com/package/puppeteer-afp
It worked fine with protectPage until yesterday!

If remove webdriver from the code everything works fine!
https://github.com/pavlealeksic/puppeteer-afp/blob/master/src/index.js#L309

can you make a full test with the webdriver removed? if all test passed yo should make a PR for it

I have the same issue with Turnstile.
It was working fine few weeks ago (I don't use proxy at all)
Actually it still works fine when I am using headless: false
So it's just not working with headless: true
Here is an example on https://nopecha.com/demo/cloudflare
https://github.com/user-attachments/assets/f539d6ce-b0ae-4fbb-8099-aa74786e130e
I tried on other websites using Turnstile and I have the same issue, it's able to detect the headless mode. Also tried puppeteer-afp (with or without webdriver without any effect)


Nitrokey 3 v1.0.3 update not visible

We have received a report, that the latest update detected by nitropy is v1.0.2. To investigate.

Cannot reproduce:
$ nitropy nk3 fetch-update
Nitrokey tool for Nitrokey FIDO2, Nitrokey Start, Nitrokey 3 & NetHSM
Download v1.0.3: 100%|██████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 302k/302k [00:00<00:00, 5.41MB/s]
Successfully downloaded firmware release v1.0.3 to ./firmware-nk3xn-lpc55-v1.0.3.sb2
$ nitropy nk3 update
Nitrokey tool for Nitrokey FIDO2, Nitrokey Start, Nitrokey 3 & NetHSM
Current firmware version:  v1.0.3
Latest firmware version:   v1.0.3
You are already running the latest firmware release on the device.  Do you want to continue and download the firmware version v1.0.3 anyway? [y/N]

Can you please provide logs and the pynitrokey version?

Logs: log.zip
Version: 0.21

Could there be a HTTP proxy or cache involved?

And can you please check if manually querying the GitHub API works by providing the output of this command?
$ curl -s "https://api.github.com/repos/Nitrokey/nitrokey-3-firmware/releases/latest" | grep html_url

Works for me. I do not know about the original reporter. Perhaps logs are from before the release, and just processing the ticket took so long it passed the date. Again, we need more data in the log #222 .
  "html_url": "https://github.com/Nitrokey/nitrokey-3-firmware/releases/tag/v1.0.3",
    "html_url": "https://github.com/robin-nitrokey",
        "html_url": "https://github.com/robin-nitrokey",

No new related reports received. Closing as done.
Keep #222 in mind to avoid similar in the future.


Use the TextEncoder/TextDecoder or Buffer API if available

Recent browsers (Chrome, FF, Opera) provide an API (https://encoding.spec.whatwg.org/#api) for encoding/decoding strings, and Node.js provides new Buffer(), both of which are notably faster than a purely JS-based approach, so use these if available.

@nmrugg ping?

Yeah, sorry, I've been busy. I checked out the code pretty thoroughly though, and it looks good. I'll try to tackle these PRs soon.

I'll try to work on this over the weekend.
Sorry, I've been so slow. So much stuff going on.
Maybe I should setup a github organization for LZMA-JS and you could join that.

No problem, we all have other things to do besides maintaining cool OSS :)
Feel free setup a org (or add me as a collaborator here), and I’ll be glad to help where I can, but right now I don’t have any plans for more improvements here from my side :)


Add tests to /api/groups/:id/export endpoint

Hi @gruz0 I would like to work on this issue can you please describe what is to be done and what files will be target by this issue?


only convert non-numeric edge attributes to string when saving gpkg

Coverage decreased (-0.3%) to 92.434% when pulling 45afd4c50b6ae6c5d8ea139c52dbd94f3e29de99 on feature into 0f485b6886907a847e74c72ee6a5f9112fffc47a on master.


Feature/traffic sign real import updates

Update Katajanokka Traffic Sign import with following changes:

z (new field to datamodel) --> use Z-coordinate from the import
height --> null
condition --> null
size --> null
reflection_class --> null
surface_class --> null
color --> null
location_specifier --> null

Also update translations.
Refs #LIIK-67

Codecov Report

Merging #38 into master will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master      #38   +/-   ##
=======================================
  Coverage   95.34%   95.34%
=======================================
  Files          45       45
  Lines        3006     3008    +2
  Branches      105      105
=======================================
+ Hits         2866     2868    +2
  Misses        128      128
  Partials       12       12

Impacted Files
Coverage Δ

...ntrol/utils/send_traffic_sign_reals_katajanokka.py
0.00% <ø> (ø)

traffic_control/models/traffic_sign.py
98.44% <100.00%> (+0.02%)
:arrow_up:

Continue to review full report at Codecov.

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


finance.IRR causes "Cannot convert undefined or null to object" error

The example:
finance.IRR(-500000, 200000, 300000, 200000);
Result:
    Uncaught TypeError: Cannot convert undefined or null to object
    at slice (<anonymous>)
    at Finance.IRR (finance.self-e3a7ba8fd778d256a438ea068bd511733e341d18b95ce0cda6e89071e7a0edb2.js?body=1:51)
    at <anonymous>:1:9

Here:
    Finance.prototype.IRR = function(cfs) {
    var depth = cfs.depth;
    var args = cfs.cashFlow;
    var numberOfTries = 1;
    // Cash flow values must contain at least one positive value and one negative value
    var positive, negative;
    Array.prototype.slice.call(args).forEach(function (value) { // <<<<< Right here
        if (value > 0) positive = true;
        if (value < 0) negative = true;
    })

I'm having the same issue.

@SethConnell @noff The example in the README.md for IRR won't work. In the image of the IRR function that noff provided, you see that it wants an object with two keys named "depth" and "cashFlow".
For the sake of familiarity I'll use the numbers given in the readme.
Try finance.IRR({depth: 100, cashFlow:[-500000, 200000, 300000, 200000]}) which outputs (at least in my environment) 18.83 and NOT 18.82 as the example in the readme shows.
I'm not really sure what "depth" is, but from the code, its a limiter on how many times the internal NPV function is ran.
I haven't given this library a good looking at, but just from this function I'd either write your own or go somewhere else. When it comes to financing or other peoples money you want to be 100% accurate and understand what is happening.


Clicking Add Configuration doesn't prompt the Progress bar

When you click the + to add a Configuration, the Progress bar doesn't display so it doesn't look like anything is loading. This likely has always existed but it's more evident now since we have to scan the entire directory tree for projects.
https://github.com/user-attachments/assets/50b6f3f9-922b-46da-b7b1-22921388dd2a

Using the latest code off main and restarting VSCode and was unable to reproduce this.


Opinion: Focus on word and ignore Excel

I notice in your code there is the start of an implementation for Excel.  If you are not already aware there is excellent library for Excel already: https://spreadsheetlight.com/
However, I have not seen another open-source Word library.  I think efforts would be best focussed on that.  This looks really good already, but would great to have this fully fleshed out alongside SpreadsheetLight as complete solution for Word and Excel.
Just my opinion of course, feel free to do what you think is best.

Excel is just a playground for me. We may need some code to embed excel in Word - I've no plans to build on top of it unless I am forced to. I use https://github.com/ClosedXML/ClosedXML, I used to use EPPlus, but they changed their license, making it harder to use.


PHP Composer 2.X: Class does not comply with psr-0 autoloading standard.

I can not install PolyCrypto from Composer any more cause composer 2.x requires a stricter matching between class names and filenames.

Fixed in PolyCrypto v2.0.0.

Hello, I'm trying to use poly-crypto with composer v2.0.11 and the problem persists.
> composer require poly-crypto/poly-crypto
Using version ^2.0 for poly-crypto/poly-crypto
./composer.json has been updated
Running composer update poly-crypto/poly-crypto
Loading composer repositories with package information
Updating dependencies
Lock file operations: 1 install, 0 updates, 0 removals
  - Locking poly-crypto/poly-crypto (2.0.0)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
  - Downloading poly-crypto/poly-crypto (2.0.0)
  - Installing poly-crypto/poly-crypto (2.0.0): Extracting archive

Class PolyCrypto\PolyAES located in project/vendor/poly-crypto/poly-crypto/src\PolyAES.php does not comply with psr-0 autoloading standard. Skipping.
Class PolyCrypto\PolyBcrypt located in project/vendor/poly-crypto/poly-crypto/src\PolyBcrypt.php does not comply with psr-0 autoloading standard. Skipping.
Class PolyCrypto\PolyDigest located in project/vendor/poly-crypto/poly-crypto/src\PolyDigest.php does not comply with psr-0 autoloading standard. Skipping.
Class PolyCrypto\PolyRand located in project/vendor/poly-crypto/poly-crypto/src\PolyRand.php does not comply with psr-0 autoloading standard. Skipping.

Thanks


Typo ".Suo"→".suo"

https://docs.microsoft.com/en-us/visualstudio/extensibility/internals/solution-dot-sln-file?view=vs-2022
https://github.com/MicrosoftDocs/visualstudio-docs/blob/main/docs/extensibility/internals/solution-dot-sln-file.md
related #7982 (Typo ".Sln"→".sln")
#PingMSFTDocs

@hyoshioka0128 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@leslierichardson95
Can you review the proposed changes? IMPORTANT: When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"

#sign-off


How to instantiate ChangeSet?

So it can be used in rustyline::completion::Completer::update() ?

Currently, only rustyline can.
This change was introduced by #666

How does someone use rustyline::completion::Completer::update() then?

You can implement update.
But you are not supposed to use / call it!
Only rustyline should call it.

Resolved. Was migrating from v9 to v12.
v9 code:
completer.update(line_buffer, pos, &my_string);

v12 code:
line_buffer.set_pos(pos);
line_buffer.kill_buffer(listener);
line_buffer.insert_str(pos, &my_string, listener);
line_buffer.move_end();


Datum as EmbeddedDocuments stoopid?

With regards to how ours views look atm (well besides from the ”presenter” being part very bad and part not even used)
and how fickly it is to handle embedded documents I started question the reason for the current implementation.
The initial reasons for datum being embedded documents was that we hoped to be able to update them autonomously (which we can't) and that we wanted to be able to build up page types from dynamic building blocks (which we do but we still need to use the data in the views so we cannot change the data structure without changing the representation in the views).
So for the question: Why is the Datum class and classes inherited from it not implemented as "plain old ruby objects" with to_ / from_mongo methods and used as keys.
Then we could be specific in code when we define page types. I realize this goes against the idea of being able to build the page types in the interface but to be honest that does not really work atm anyhow.
What I havent thought much about is collections (and nested such) but it should not be much of a trouble as long as things know how to persist itself.
Am I making sense @arvida ? :beer:

and @lexi for that matter


Issue for version <IP_ADDRESS>, sometimes can not use the function

the newest version of ThreeFingerDragOnWindows <IP_ADDRESS> caused a problem:
Sometimes I can not use the function. i have to restart the app. but a few times it can not drag with three figures again, although i set up do nothing the the setting of window according.
Please fix it. now, i must return to the version <IP_ADDRESS>. so sad !

Do you think that this is a duplicate of #52 ?


Make FCM and InstanceID compatible with tvOS

A few more things I noticed trying to run in the branch:

GPB_USE_PROTOBUF_FRAMEWORK_IMPORTS needs to be added to the Preprocessor Macros setting similar to how it is for the iOS Tests target
The Test scheme should be marked shared and visible in the scheme editor and then the resulting file added to the repo
Some extra cruft got into the HEADER_SEARCH_PATHS setting. Make it the same as the iOS test target.

There's conflict in the file, should I keep adding IID tests and merge later or just submit this CL first?

The conflict needs to be solved before merging.  It looks feasible now after deintegrating.  At a quick glance, it looks like "Accepting Both" for the one conflict will do it.
Also, the new test targets should be added to the "All tvOS" Aggregate target scheme and then they'll be included in CI.

Do git merge origin/master and git mergetool

Done merging the conflicts.

It doesn't let me merge by running git merge origin/master
So I did the step 1 of comment line instructions and push the change to this PR.

Looks like we need to update the FirebaseInstanceID version on SpecsStaging for FirebaseMessaging to pass pod lib lint.
To be safe, let's hold off on this until the M44 release branch gets made.


Warning about method signature mismatch

Running tests gives the warning
Warning: Declaration of Keboola\DbExtractor\Tests\AbstractMSSQLTest::getPrivateKey(): string should be compatible with Keboola\DbExtractor\Test\ExtractorTest::getPrivateKey(string $driver): string in /code/tests/Keboola/DbExtractor/AbstractMSSQLTest.php on line 12

@pivnicek here https://github.com/keboola/db-extractor-mssql/pull/120 is fixed

@ondrajodas great!  I'll take a look there 👍


Update set-up-content-understanding.md

Made changes tot he navigation to automate content understanding

Issue#https://github.com/MicrosoftDocs/microsoft-365-docs/issues/3417

@JohanFreelancer9 Please copy review

@MikePlumleyMSFT Please merge this PR. Thanks

@msbemba @yogkumgit "Organizational knowledge" is a temporary heading. "Files and content" should be rolling out soon.


README: added api-docs links

Includes links to the API documentation in the README

Xi changed the p4w3 footer in https://github.com/oasisprotocol/sapphire-paratime/pull/203


Filter log entries by different options

Is your feature request related to a problem? Please describe.
The log window can be helpful for troubleshooting but often times you have too many log events so that it becomes cluttered and hard to find and see what you are acutally looking for.
Describe the solution you'd like
The log window provides a filter option to filter by varios things:

free text - any log message that matches the filter query, include and exclude of matches would be nice
log level - select from the predefined log levels to only see that items that match it
pause / resume - pauses the log view until you resume

Describe alternatives you've considered
n/a

pause/resume YES PLEASE


Circular dependency error with rollup for browser

Describe the bug
When bundling yaml for the browser using rollup, I get a circular dependency error. This seems to be a quirk (maybe even a bug?) of the way rollup builds for the browser. A small tweak seems to solve the problem.
Change this,
import * as YAML from './dist/index.js'

to this,
import * as YAML from '../browser/dist/index.js'

To Reproduce
Here's a minimal reproduction.
package.json
{
  "scripts": {
    "build": "rollup -c"
  },
  "dependencies": {
    "@rollup/plugin-commonjs": "^19.0.0",
    "@rollup/plugin-node-resolve": "^13.0.0",
    "rollup": "^2.52.4",
    "yaml": "^2.0.0-6"
  }
}

rollup.config.js
const { nodeResolve } = require("@rollup/plugin-node-resolve");
const commonjs = require("@rollup/plugin-commonjs");

module.exports = {
  input: "index.js",
  output: {
    format: "iife",
    file: "dist.js",
    name: "Test",
    exports: "auto"
  },
  plugins: [
    nodeResolve({
      browser: true
    }),
    commonjs(),
  ]
};

index.js
const YAML = require("yaml");

const data = YAML.parse(`foo: bar`);
console.log(data);

Run rollup with npm run build. You should see the circular dependency error. Make the change suggested above (or a better one if it exists) and the error goes away and you can run the bundled app with node dist.js.

Huh, this looks like it's actually a bug in @rollup/plugin-node-resolve.
When its browser: true option is enabled, the package.json "browser" field is considered during resolution, and for yaml it includes the mapping
"./dist/index.js": "./browser/index.js"

which according to the spec should mean that just yaml/dist/index.js is resolved as yaml/browser/index.js. However, that file itself includes a dependency "./dist/index.js", which should resolve as yaml/browser/dist/index.js but happens to be an exact string match to the mapped dependency from the package root, and therefore produces the weird circular dependency
node_modules/yaml/browser/index.js -> node_modules/yaml/browser/index.js

I'll file a bug about this there. In the meantime, for yaml the easiest fix would be to leave out the browser: true setting, as its export map is already set up to have Rollup use the yaml/browser/... files as they're the "default" export ("node" is special-cased). This won't help of course with projects that need said option for other dependencies.

Closing in favour of the upstream bug rollup/plugins#919.


Update to Yocto 4.2 - Mickledore

This is the long-awaited update from Langdale (4.1) to Mickledore (4.2)
Things to do before merging¹:

[x] Fix the underlying issue that makes trace-cmd fail to build and fix it instead of disabling the package.
2023-11-01: It looks like this issue fixed itself in the meantime 🎉.
[x] systemd-repart.service fails to start with "Could not determine temporary directory: No such file or directory", which needs to be fixed.
[x] barebox-state does not work. This can be observed by running e.g. rauc status mark-bad other:
rauc mark: Failed marking slot rootfs.1 as bad: barebox backend: Failed to run barebox-state: Child process exited with code 1
This makes RAUC unusable, which needs to be fixed.
[x] Test on hardware

Other Pull requests that need coordination:

[ ] #61 can not happen before this is merged, so it needs to be rebased on top of this work and the target branch has to be updated.
[x] #69 backports a systemd service file. This should become obsolete in mickledore, so the backport should be removed again.
2023-11-01: added a commit that removes the file again.

¹ Due to the way meta layers are ususually handled, e.g. having a branch name matching the release name I have created a mickledore branch based on the current langdale branch content to be able to open this PR against it.

It looks like the newer barebox-state looks for the state on one of the eMMC hardware boot partitions:
$ strace barebox-state
…
openat(AT_FDCWD, "/dev/mmcblk1boot1", O_RDONLY|O_LARGEFILE) = 4
ioctl(4, MIXER_READ(1) or MEMGETINFO, 0xbefe8ae8) = -1 EINVAL (Invalid argument)
close(4)                                = 0
openat(AT_FDCWD, "/dev/mmcblk1boot1", O_RDONLY|O_LARGEFILE) = 4
openat(AT_FDCWD, "/dev/mmcblk1boot1", O_RDONLY|O_LARGEFILE) = 5
openat(AT_FDCWD, "/dev/mmcblk1boot1", O_RDONLY|O_LARGEFILE) = 6
_llseek(4, 786432, [786432], SEEK_SET)  = 0
read(4, "\271&\3\0\r-\3\0", 8)          = 8
write(2, "state: No meta data header found"..., 33state: No meta data header found
) = 33
_llseek(5, 790528, [790528], SEEK_SET)  = 0
read(5, "\10\20\7\26\34P\0\0", 8)       = 8
write(2, "state: No meta data header found"..., 33state: No meta data header found
) = 33
_llseek(6, 794624, [794624], SEEK_SET)  = 0

While the old barebox-state finds it on the normal eMMC partition:
$ barebox-state --version
dt-utils 2021.03.0
Configured with build-time option '--disable-state-backward-compatibility'.
$ strace barebox-state
openat(AT_FDCWD, "/dev/mmcblk1", O_RDONLY|O_LARGEFILE) = 4
ioctl(4, MIXER_READ(1) or MEMGETINFO, 0xbefcaaa0) = -1 EINVAL (Invalid argument)
close(4)                                = 0
openat(AT_FDCWD, "/dev/mmcblk1", O_RDWR|O_LARGEFILE) = 4
openat(AT_FDCWD, "/dev/mmcblk1", O_RDWR|O_LARGEFILE) = 5
openat(AT_FDCWD, "/dev/mmcblk1", O_RDWR|O_LARGEFILE) = 6
_llseek(4, 786432, [786432], SEEK_SET)  = 0

In my opinion having the state on the normal partition makes more sense, as the active boot partition switches with every RAUC update. I did not yet investigate further @a3f have you seen this before?

In my opinion having the state on the normal partition makes more sense, as the active boot partition switches with every RAUC update.

Agreed.

I did not yet investigate further @a3f have you seen this before?

dt-utils iterates via libudev over all block devices in cdev_from_block_device to find the matching device. Indeed all of boot0, boot1 and the user area have type "disk", so barebox-state gets the wrong device thinking it's the disk device. I am not sure how to best differentiate between boot and user partitions. Maybe check prefer block devices that have no block devices as a parent?

I've worked around the barebox-state issue for now by stepping the meta-rauc submodule back by one commit (the one upgrading to dt-utils 2023.08.0).
This is obviously not a permanent solution, but combined to another workaround for systemd-repart I can now at least pass the (not yet public - sorry potential outside readers) LXA TAC labgrid testsuite.
I think I will do some manual testing and then mark this PR as ready for review.
Would be glad to take suggestions for more elegant solutions for the aforementioned workarounds.

dt-utils iterates via libudev over all block devices in cdev_from_block_device to find the matching device. Indeed all of boot0, boot1 and the user area have type "disk", so barebox-state gets the wrong device thinking it's the disk device. I am not sure how to best differentiate between boot and user partitions. Maybe check prefer block devices that have no block devices as a parent?

For now, I restored the old behavior, namely taking the first "disk" again instead of the last. Fix is here<EMAIL_ADDRESS>IMO, it's worth a bugfix release, so once tested, we can kick that off.

I've included the barebox-state patch and tested manually and using the LXA TAC testsuite.
It looks to be working as intended.
With this I will mark this PR as "Ready for review".

Now that #71 is merged we should have everything we want to have in a first stable release (not having it would have been annoying because we would have needed to keep the workaround documentation around somewhere).
This means we should leave langdale behind and concentrate on getting this PR merged.
All other open PRs should then be updated to go to the mickledore branch instead.

PS: Something weird is going on with GitHubs commit list. It shows commits before cc4d0ea as part of this PR, even though they are already in the "mickledore" branch (which matches current langdale).

I've toggled the base branch to langdale and back to mickledore, which seems to have repaired the list of changes to review.

FYI, dt-utils v2023.11.0 incorporates the fix in https://github.com/linux-automation/meta-lxatac/pull/70/commits/62dfa038848123597e994d524f2154d2a7c921e4, so you should be able to drop the patch on your next update.

FYI, dt-utils v2023.11.0 incorporates the fix in 62dfa03, so you should be able to drop the patch on your next update.

Cool, I've added Pull-Requests in pengutronix/meta-ptx#121 and rauc/meta-rauc#292 to update dt-utils there.


[Minor][Core][1.6-backport] Fix display wrong free memory size in the log

What changes were proposed in this pull request?
Free memory size displayed in the log is wrong (used memory), fix to make it correct. Backported to 1.6.
How was this patch tested?
N/A

Test build #61712 has started for PR 14043 at commit a519540.

Just for reference, what PR or JIRA is this backporting?

#13804

Test build #61712 has finished for PR 14043 at commit a519540.

This patch fails from timeout after a configured wait of `250m`.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Jenkins, retest this please.

Test build #61725 has started for PR 14043 at commit a519540.

Test build #61725 has finished for PR 14043 at commit a519540.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

LGTM pending tests.

Test build #3163 has started for PR 14043 at commit a519540.

Test build #3163 has finished for PR 14043 at commit a519540.

This patch fails build dependency tests.
This patch merges cleanly.
This patch adds no public classes.

Jenkins retest this please

Test build #61793 has started for PR 14043 at commit a519540.

Test build #61793 has finished for PR 14043 at commit a519540.

This patch fails build dependency tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Looks like there're some problem with build:
exec: curl -s -L https://www.apache.org/dyn/closer.lua?action=download&filename=/maven/maven-3/3.3.3/binaries/apache-maven-3.3.3-bin.tar.gz

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
exec: curl -s -L http://downloads.typesafe.com/zinc/<IP_ADDRESS>/zinc-<IP_ADDRESS>.tgz
exec: curl -s -L http://downloads.typesafe.com/scala/2.10.5/scala-2.10.5.tgz
Using `mvn` from path: /home/jenkins/workspace/NewSparkPullRequestBuilder/build/apache-maven-3.3.3/bin/mvn
build/mvn: line 152: /home/jenkins/workspace/NewSparkPullRequestBuilder/build/apache-maven-3.3.3/bin/mvn: No such file or directory
Error while getting version string from Maven:

Maven tarball cannot be downloaded or uncompressed.

Jenkins, retest this please.

Test build #61802 has started for PR 14043 at commit a519540.

Test build #61802 has finished for PR 14043 at commit a519540.

This patch fails build dependency tests.
This patch merges cleanly.
This patch adds no public classes.

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

Merged build finished. Test FAILed.

Jenkins, retest this please.

Test build #61831 has started for PR 14043 at commit a519540.

Test build #61831 has finished for PR 14043 at commit a519540.

This patch fails build dependency tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Looks like this url (https://www.apache.org/dyn/closer.lua?action=download&filename=/maven/maven-3/3.3.3/binaries/apache-maven-3.3.3-bin.tar.gz) to download maven is 404 not found.
Tried with different urls, only 3.3.9 can be found, there's no 3.3.3 maven binaries.
Is it a building issue for branch 1.6? Checked the master branch building log looks like it uses maven 3.3.9 on the Jenkins server.

Oh, I imagine they finally cleaned out the old 3.3.x binaries from the mirrors. I think it's best to update branch-1.6 to refer to Maven 3.3.9 in the build. It was done for 2.0/master in https://github.com/apache/spark/commit/b84404865b90fc07858a8b28c2a7028f96517167 but we don't necessarily want to apply that whole patch.

Thanks @srowen for pointing out this pr, I'm not sure how many changes need to be back-ported into 1.6, can you please file a patch to 1.6 branch to upgrade maven? Seems currently it blocks 1.6 build. Thanks a lot.

Jenkins retest this please

Test build #61847 has started for PR 14043 at commit a519540.

Test build #61847 has finished for PR 14043 at commit a519540.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Jenkins retest this please

Test build #61848 has started for PR 14043 at commit a519540.

Test build #61849 has started for PR 14043 at commit a519540.

Test build #61849 has finished for PR 14043 at commit a519540.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

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

Merged build finished. Test FAILed.

Test build #61848 has finished for PR 14043 at commit a519540.

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

Merged build finished. Test PASSed.

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

Merged to 1.6

@jerryshao can you close the pull request now it's merged? thanks.

Thanks @srowen and @rxin for your review, I will close it.


The Logo and Background is just purple and black.

 Do not distribute!",
        "hoverText" : "§nCopyright Mojang AB. Do not distribute!",
        "posX" : -197,
        "posY" : -10,
        "color" : -1,
        "alignment" : "bottom_right",
        "action" :
        {
            "type" : "openGui",
            "gui" : "credits"
        }
    },

    "fml":
    {
        "text" : "",
        "posX" : 2,
        "posY" : -40,
        "color" : -1,
        "alignment" : "bottom_left"
    }
},

"other":
{
    "splash-text":
    {
        "posX" : 90,
        "posY" : 70,
        "color" : -256,
        "alignment" : "top_center",
        "texts" : "file:minecraft:texts/splashes.txt"
    },

    "background":
    {
        "image" : "GAMINGLIFELITE:backround.png",
        "mode" : "fill"

    }
}

}

Make all the directories and files lower case.
Also, you shouldn't have the file: in the splash text

I did what Sqaaakoi said, it is still doing it.

oh didnt see this one made a ticket here #297 seems to be a conflict with another mod if you have chance cubes installed try changing chancecubes version to 224

@KingDan27  I don't have that installed


affected by CVE-2020-26235 via transitive dependencies

Just ran cargo audit on this repo out of curiosity.
$ cargo audit
    Fetching advisory database from `https://github.com/RustSec/advisory-db.git`
      Loaded 468 security advisories (from /home/xxxxxxxx/.cargo/advisory-db)
    Updating crates.io index
    Scanning Cargo.lock for vulnerabilities (156 crate dependencies)
Crate:     time
Version:   0.1.44
Title:     Potential segfault in the time crate
Date:      2020-11-18
ID:        RUSTSEC-2020-0071
URL:       https://rustsec.org/advisories/RUSTSEC-2020-0071
Solution:  Upgrade to >=0.2.23
Dependency tree:
time 0.1.44
└── chrono 0.4.22
    └── wthrr 0.4.1

Crate:     term
Version:   0.6.1
Warning:   unmaintained
Title:     term is looking for a new maintainer
Date:      2018-11-19
ID:        RUSTSEC-2018-0015
URL:       https://rustsec.org/advisories/RUSTSEC-2018-0015
Dependency tree:
term 0.6.1
└── term-painter 0.3.0
    └── wthrr 0.4.1

error: 1 vulnerability found!
warning: 1 allowed warning found

chrono currently depends on a deprecated and vulnerable version of time.
Fix as suggested here:
diff --git a/Cargo.toml b/Cargo.toml
index 0405f62..1a62243 100755
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -13,7 +13,7 @@ categories = ["command-line-utilities"]

 [dependencies]
 anyhow = "1.0.58"
-chrono = "0.4.19"
+chrono = { version = "0.4.22", default-features = false, features = ["clock"] }
 clap = { version = "4.0", features = ["derive"] }
 dialoguer = "0.10.1"
 regex = "1.6.0"

thanks for investigating @arctic-penguin
You want to PR the suggestions? Would be great 😊


不能运行 image_quality_prediction.py

当我运行image_quality_prediction.py 报You are trying to load a weight file containing 13 layers into a model with 14 layers.错误，能否帮忙看看哪里出问题了？

I just tested the script with the weight file downloaded from the link in Readme, and everything is normal. Please try again.


esModuleInterop does not handle named imports when combined with synthetic default imports

TypeScript Version:  2.8.0-dev.20180204
Search Terms: esModuleInterop
Code
I am seeing some unexpected behaviour when using esModuleInterop and importing from a commonjs module in 2 different ways at the same time:
// dep.js
exports.var1 = 'var1';
exports.var2 = 'var2';

import Deps, { var2 } from './dep';
console.log(Deps.var1);
console.log(var2);

Expected behaviour:
Running the code outputs:
var1
var2

Actual behaviour:
Running the code outputs:
var1
undefined

This is the javascript which is generated:
"use strict";
var __importDefault = (this && this.__importDefault) || function (mod) {
    return (mod && mod.__esModule) ? mod : { "default": mod };
}
exports.__esModule = true;
var dep_1 = __importDefault(require("./dep"));
console.log(dep_1["default"].var1);
console.log(dep_1.var2);

Related Issues:
None that I am aware of
The real-world code which is triggering this problem is here
The 'named' import and 'default' import work fine individually but do not work when they are both present in the same file.

This is working as intended, then. import { var2 } from './dep' imports the var2 export, but there is no var2 export as it is not an ES module export.
CommonJS modules only have a default export. exports.var2 = is not a var2 export, it is the var2 property of the default export.

@Kovensky This is not intended. We should be emitting the __importStar and not the __importDefault helper when the import form is import D, { ... }.

But looking at React specifically, we see https://github.com/facebook/react/blob/master/packages/react/src/React.js#L33
The top level package exports a single binding. All of what have been used as named imports are properties of this export.

React does not set the __esModule flag so it will be seen as a normal commonjs module. Typescript is then converting it to an object with a default property and trying to access other named imports from that object.
<EMAIL_ADDRESS>

Yeah what I was getting at is that it seems anything but clear how the package intends to be consumed. With no __esModule flag I don't see how it will work with named exports even if you discount the fact that Node.js doesn't support them.
@weswigham

This is still under discussion is by no means set yet (we're watching it carefully).

I really hope things do change but it is easy to get the impression that Node.js is supremely disinterested in these compatibility scenarios.

@aluanhaddad as I understand it (and @weswigham indicated) - even if nodejs does not itself support named imports, they will still be supported when using typescript or babel. The code you would need to write will be automatically generated based upon the value of the __esModule flag.

@frankwallis thank you for clarifying that. But since React doesn't set the flag, I would still argue that
import React, Component from 'react';

even if supported, should be avoided because React does not seem at all interested in supporting it. Granted, that is a philosophical argument.
Regarding named imports in Node.js, it implies a perpetual transpilation step even where not-needed. Users seeing NodeJS advertising module support in Node.js 10, may be confused or surprised, unaware that they have taken such a dependency. More problematically, if they are authoring libraries, their documentation may not reflect the larger Node.js community's expectations.
I'm not trying to say what ought to happen here, but rather that these usage patterns emerged at a time when Node.js was not expected to take the course they now have.
As @Kovensky has noted many times, both TypeScript and babel are highly permissive. I believe a strict conformance mode would be beneficial if only to set a baseline expectation of behavior in TypeScript.

I believe a strict conformance mode would be beneficial if only to set a baseline expectation of behavior in TypeScript.

Right. But whose strict behavior? Node doesn't know how the feature will stabilize yet, and browsers don't support any cross module-kind interop at all (yet do seem somewhat open to opening up their loader more in the future). As it turns out, es modules "arrived" with es6, but were the least standard new feature in the standard, since many behaviors are left unspecified. Browsers operate without interop, so how TS works today without a flag can emulate browser behavior pretty well (excepting the fact that declaration files allow you to confuse module kinds). The esmoduleinterop flag allows TS to emulate Babel's and webpack's interop behaviors, which, as should be obvious, many people have come to rely on. Whatever the node team finally lands on, we'll support; but I think the devs are doing a huge disservice to their existing community who was told they were using "es6 modules" with their transpiled where they would "just be able to disable Babel" in the future when the JavaScript of the future arrives by not meeting developers where they are. They're clearly aware of this - they've introduced exceptions to the only-default approach for the buildin packages like fs and path, so they clearly know how awful it is right now (though such exceptions are gonna make our life more difficult).
Really, we were all sold on the lie that we could reasonably smoothly transition into these things called modules without actually knowing how they'd behave in some very important cases. I'm a bit biased because I'm immersed in how the feature has evolved, but I'd not advocate for using modules with the intent of writing future-looking code anymore. Use them if you only want to target one runtime, or never remove a transpiler from your toolchain, but don't decieve yourself into thinking they'll ever be as portable as a chunk of code with a UMD definition block around it was in the last era of the web.

It would be great to get some clarity on this from the TS team.
Here it is labelled as a bug, but in #22678 @RyanCavanaugh said it's the expected behaviour.
The current behaviour is extremely surprising, and, AFAICT, should be considered a bug.
i.e. Why should
import _, { blah } from 'thing'
console.log(blah)

and
import _ from 'thing'
import { blah } from 'thing'
console.log(blah)

produce different results? Because that's what's happening right now if an imported module doesn't specify __esModule: true
I'm happy to contribute a fix for this, if there's agreement on what the behaviour should be.

It's definitely a bug. People are getting hung up on tangential issues. We're just not counting the named imports for an importStar helper after we see the default import.

I'm still having this problem. Not sure if it's the same thing, can you confirm? @weswigham
Compile error:
import API from 'apifn';

// TS2351: Cannot use 'new' with an expression whose type lacks a call or construct signature.
export default new API('https://google.com', []);

This works:
import { default as API } from 'apifn';

export default new API('https://google.com', []);

I can't understand how those syntaxes are different, as I believe the default import syntax is part of the TC39 standard already or isn't it? Asking because this works perfectly with Babel. Only when I'm with projects with TypeScript that this confusion with default starts to happen.
The apifn package is a small package developed by myself. It uses TypeScript for generating ES5+Common JS.

Definitely unrelated to this issue - this issue only affected emit, while that's a typechecking error.

I'm still having this error when using esModuleInterop with dynamoose library and Typescript 2.9.2 / 3.0.0-dev.20180704 (current @next).
When I use only named imports it works just fine
import { Schema } from 'dynamoose';

console.log(Schema)    // constructor function

On the other hand, if I use default import, named import changes to undefined
import dynamoose, { Schema } from 'dynamoose';

console.log(Schema)   // Schema is undefined
console.log(dynamoose.Schema)    // constructor function

Both of these examples work with Babel 6.24 so I don't think it's correct behavior. It compiles just fine, but this could be a weakness of type definitions.
For reference, in first example the generated code looks like this
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
const dynamoose_1 = require("dynamoose");
console.log(dynamoose_1.Schema);

In second case the code generated looks like this
"use strict";
var __importStar = (this && this.__importStar) || function (mod) {
    if (mod && mod.__esModule) return mod;
    var result = {};
    if (mod != null) for (var k in mod) if (Object.hasOwnProperty.call(mod, k)) result[k] = mod[k];
    result["default"] = mod;
    return result;
};
Object.defineProperty(exports, "__esModule", { value: true });
const dynamoose_1 = __importStar(require("dynamoose"));
console.log(dynamoose_1.Schema);
console.log(dynamoose_1.default.Schema);

And that's what Babel generates
'use strict';

var _dynamoose = require('dynamoose');

var _dynamoose2 = _interopRequireDefault(_dynamoose);

function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }

console.log(_dynamoose.Schema);
console.log(_dynamoose2.default.Schema);

The second one (where Schema is undefined) is the correct one.
This is how dynamoose exports itself: https://github.com/dynamoosejs/dynamoose/blob/master/lib/index.js#L125
This should be defined as an export = commonjs export.

Even if dynamoose export is technically incorrect, it's still very strange that adding new import type breaks the one used previously. If using named import isn't correct, shouldn't it's value also be undefined in example 1 - when used without default import?
I may be mistaken in thinking that esModuleInterop would bring TS behavior in line with the way that Babel interprets it, but even ignoring Babel, current behavior is still puzzling...

@frankwallis Do you think it's worth opening a new issue describing this problem?

@rafsawicki I do believe this is a new issue, maybe @weswigham can comment?

I'm having the same problems.

Shouldn't esmoduleinterop make it possible to do
import { useState } from 'react' ?
It's very annoying to use right now.

@AlexGalays that's probably just waiting on an updated react declaration file on definitely typed.

Oh no, I meant it doesn't work at runtime. Nevermind it works now... debugging with approximative source maps were showing useState as undefined but it wasn't.

FYI for those who got here from a google search seeing this error in intellisense in VS2019 despite their create-react-app based project building fine from the command line, I the error to go away by doing this (not sure if all these steps were necessary):

Cleaned solution
Closed solution
Deleted bin/obj folders
Did a clean yarn install (deleted node_modules)
Opened solution again
Problem went away (for me at least)


Register broker not working on kubernetes 1.18

Bug Report
When I try to register a broker:
svcat register mybroker --url <broker_url> --basic-secret <secret_name>
I get the following error:
Error: register request failed (ServiceBroker.servicecatalog.k8s.io "mybroker" is invalid: metadata.managedFields.fieldsType: Invalid value: "": must be FieldsV1\)
What you expected to happen:
The broker to be registered successfully.
How to reproduce it (as minimally and precisely as possible):

create a k8s cluster with version 1.18.x
install service catalog version 0.3.0-beta2
register a broker using svcat

Anything else we need to know?:
Environment:

Kubernetes version (use kubectl version): v1.18.2
service-catalog version: v0.3.0-beta.2
Cloud provider or hardware configuration: aws
Install tools:

Did you use helm? - Yes. What were the helm arguments? Did you --set any extra values? helm install catalog svc-cat/catalog  --namespace catalog --version 0.3.0-beta.2

Are you trying to use ALPHA features? -  No . Did you enable them? - No .

Hi @georgifarashev
Yes, the service catalog does not support 1.18 yet. AFAIK there are some changes in client-go so we need to bump that dependency.

Hi @mszostok ,
Thanks for your quick response!  and the rapid PR to update everything (https://github.com/kubernetes-sigs/service-catalog/pull/2796/commits)
Is the fix for supporting k8s 1.18 version is planned to be released as part of the 0.3.0 milestone?  or perhaps implemented and released more early?
Thanks,
Alex

Hi @alexwo
so the plan is as follow:

Switch service catalog to go 1.13 with go modules (https://github.com/kubernetes-sigs/service-catalog/pull/2795)
Remove unused code from api-server (https://github.com/kubernetes-sigs/service-catalog/pull/2720)
Bump to K8s version (https://github.com/kubernetes-sigs/service-catalog/pull/2796)

We hope to finish all that stuff this week and do the 0.3.0 release as beta does not make sense anymore as we are using the CRD already for half a year and we didn't have any problems with this implementation.
Rest issues from the 0.3.0 milestone will be addressed later and release with 0.3.x versions ;)

Hi @alexwo & @georgifarashev 🙂
The new release is now available https://github.com/kubernetes-sigs/service-catalog/releases/tag/v0.3.0 with support for k8s 1.18 🎉
please let me know if you will encounter any problem with that release and sorry for the delayed release but we had a few problems (e.g. downtime of quey.io, switching from go dep to go mod etc.)


Run code coverage with log both enabled and disabled

Fixes #27, although there are still a few missed lines due to the log statements being no-ops when log is disabled. Not sure if there is a way to fix that, since they compile into nothing.

Codecov Report

Merging #29 (f2219f7) into master (d3a8b3b) will increase coverage by 33.33%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           master      #29       +/-   ##
===========================================
+ Coverage   58.33%   91.66%   +33.33%
===========================================
  Files           1        1
  Lines          60       60
===========================================
+ Hits           35       55       +20
+ Misses         25        5       -20

Impacted Files
Coverage Δ

src/internal_log.rs
91.66% <0.00%> (+33.33%)
:arrow_up:

Continue to review full report at Codecov.

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


[kmac] Add Current AppInfo context

This commit adds the current Application Interface configuration in the
KMAC technical specification. Previously, readers should check the
kmac_pkg.sv source code to get the correct application configuration.
This addresses the AI at the ROM_CTRL D2S meeting.

Thanks, @eunchan!


WAR-2120 skip printing sensitive data

@ryadaval-warrior
Is there a reason why log=true/false was chosen instead of yes/no. We typically use yes/no everywhere else in the testdata file.  Please let me know if this is a step towards WAR-1261.

@ryadaval-warrior
Is there a reason why log=true/false was chosen instead of yes/no. We typically use yes/no everywhere else in the testdata file. Please let me know if this is a step towards WAR-1261.

@sanikakulkarni  - no special reason for using true/false, this fix is already given to Microapps team, can we retain true/false as it is.


Create 0000-01-02-54t6f.md

Nothing Special

Your site is so exellent and too helpful for me
And i\I extremely liked it


Get metadata for specific entity class when creating query.

Currently when fetching meta data for an ODM entity the method createQuery() uses the getAllMetadata() methods from the MetadataFactory object and then opts to use the first key (0) as the mapping to be passed to the filter manager. However the first key doesn't necessarily hold the correct mapping data. For example if an entity extends an abstract class then the abstract class meta data will be returned. This leads to fieldMappings being absent from computation in the filter.
A good example is the typeCaseField method which uses a try/catch switch to determine the type, however when the entity extends other classes as per my example above, then the fieldMappings for the given field aren't necessarily in the meta data (for example they are only declared in the entity and not the extended classes).
I propose to use the getMetadataFor() methods of the metadataFactory class to fetch specific meta data for the given entity class.
https://github.com/zfcampus/zf-doctrine-querybuilder/pull/29/files

+1
I asked to change the readme for this on PR #28


cloudflare-warp: init at 2017.12.1

Motivation for this change
cloudflare-warp allows you to serve a website behind Cloudflare without opening any port.
Things done

[X] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[X] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[X] Fits CONTRIBUTING.md.

I think the errors are only relating to it being unfree.

@GrahamcOfBorg eval

Why is it two packages instead of the first patchelf just making a --set-interpreter?
(trying to look at PR list page 17)

In the meantime Warp has been renamed Argo Tunnel and it seems the client has become cloudflared

Closing for now.
@lezed1 please feel free to come up with a new PR if you want cloudflared inside NixPkgs


error when connecting to cogito

When I try to access cogito at http://ip address:8585, I get an error at the top of the page
"An error occurred, detail: Code: 403, Message: Http failure response for http://:8585/api/thoughts: 403 OK"
I create a new account, but when attempting to sign in, get the same message..
my docker-compose:
services:
  cogito:
    image: tukks/cogito:v1.3-alpha
    ports:
      - "8585:9191"
    volumes:
      - ./db:/app/db
      - ./image:/app/image
    environment:
      - APP_JWT_SECRET="xjurrsalgwfnmgozhvhxhiocehsqqppxjpxvyucrrsaqppxvwiobttgjizaadfuhizkbilzjlsniargqsdrjswfhsutrljlrjmxinaqqkeqhfhiurtlfqzwsqwhdwhvc"
#   - API_TWITTER_KEY_SECRET="YOUR_API_TWITTER_KEY_SECRET"
#     - API_TWITTER_KEY="YOUR_API_TWITTER_KEY"
#     - HTTPS_ONLY=true # true if you use https

You're url is in http://, set HTTPS_ONLY=false.
The default value is true.
And reboot the docker-container

thanks, i misunderstood the instructions. of course- that fixed it!


feat(tasksEvaluationPage): Made a new Page - Tasks Evaluation

Signed-off-by: sid-bagwe<EMAIL_ADDRESS>Functionality:
Created a new page named Tasks Evaluation.
Solution:
Created a new API to read the data, implemented pagination, Added filter by sprint number, Added 'Move to Current Sprint' Functionality for Tasks.
Risk level:

[ ] high
[x] medium
[ ] low

How to test:
ng serve
firebase emulators:start

Resolve Merge conflict ASAP


Phpunit never stops running: > Illuminate\Foundation\ComposerScripts::postAutoloadDump > @php artisan package:discover

Never ending running:
> Illuminate\Foundation\ComposerScripts::postAutoloadDump
> @php artisan package:discover

Weird error! only happens at first execution of phpunit. Ctrl+c first execution and following executions works ok!

Problem when upgrade Laravel 5.5

Had same problem and thats occurs when PhpStorm is listening for PHP Debug Connections --- there it hangs. Stop listening and it works :)

Thanks @lauri911 for the info!

Ok is not a problem with Laravel or Phpunit: One of my tests (callAdminlteAdminCommand) in some cases runs infinitely. The test is related with a command I want to change completely so the problem will solve then.


Feature request: A way to manually / automatically add cookietemple to existing repo

Is your feature request related to a problem? Please describe.
Right now, there is no immediate solution for adding cookietemple to an existing repo.
This would be a great feature since it keeps the history while solving the problems that arise with manually renaming and merging branches from a different origin.
I have provided my tutorial for doing this manually below, which hopefully helps in finding an automated solution in the future.
Describe the solution you would like
Best would be to run cookietemple sync in an existing repo which automatically detects that there is no TEMPLATE branch yet.
Alternatively, sth. like cookietemple create --existing-repo or so which would be executed within the folder of the existing repo.
The only real problem is associated with merge conflicts in the dockerfile, poetry.lock and pyproject.toml based on my experience.
But if these files exist, one could simply tell cookietemple to use the ones that already exist or add the cookietemple dev-dependencies in the pyproject.toml and call poetry install to update the poetry.lock file.
Additional context
Migrating an existing repo with a new cookietemple repo and keeping the history can be done this way (python only):
If you want to migrate, don't forget that cookietemple requires a new repository. If you want to keep the name, you need to first rename the existing repo.

In a first step, try to merge as many branches as possible, as it is much easier if you only need to merge one single branch. If you cannot do that, you will need to migrate each branch individually.
Create a new repository on github using cookietemple CLI
Clone the newly create repository locally, then add a second origin (the existing repo to be migrated) using git remote add <origin name> <URL>. Note: <origin name> must not be "origin", as this key already exists in the .git/config file. Choose for example "origin_existing_repo"; <URL> is either the https or ssh address of your existing repo.
git fetch --all in order to fetch all the branches from both origins. Then git checkout origin/development (this is the github development branch created by cookietemple).
Now, git merge <origin name>/<your main branch in the existing repo> --allow-unrelated-histories. You will need the additional flag, since the entire history of your main branch will be prepended to the single commit on the origin/development branch created by cookietemple.
You are likely getting merge conflicts, especially if you already have a Dockerfile, unit tests or a pyproject.toml + poetry.lock file. My personal advice: Overwrite the default Dockerfile with your Dockerfile, delete the poetry.lock and merge the pyproject.toml which mainly adds the cookietemple dev dependencies, then recreate the poetry.lock file by poetry install. This is the most critical point in the process. You should know how to use a mergetool, such as vimdiff, which you can configure using git config merge.tool vimdiff. Here, some cookietemple automation could help the average user immensely imo.
Now that your main branch is migrated, you can push the origin/development branch and it will contain the cookietemple template as well as your work and commit history.
If necessary, git checkout origin main and  git merge origin/development.

Important notes:
If you have any other branches to merge, you can always git checkout development and git merge <your arbitrary branch in the exsiting repo>. Be aware, that your branches do not yet contain the cookietemple templates. It is therefore an option to first git checkout <your arbitrary branch in the existing repo> and then git merge origin/development. This also ensures you fix potential merge conflicts on your existing branch prior to merging it on the new development branch.
If you follow these instructions, you won't experience any merge conflicts other than the ones mentioned in point 6. Since the history of your main branch in the existing repo is now part of your development branch in the newly created cookietemple repo, you can now start checking out new branches from it without any issues and also merge branches from the existing repo without further problems, as long as they have been checked out from the main branch you used for migration in point 5.
Be aware of merge conflicts when fixing pre-commit hooks on the development branch before merging the other branches you might have in the existing repo . Since the automatic pipelines might do a lot of changes to your code, fixing these later on will be a nightmare. It is therefore recommended to first merge everything into origin/development, then freeze the repo (i.e. tell your collabs they should prepare to feel a Hinkelstein fall on their head if they dare to push / checkout new stuff during that time) until you have fixed all the github actions that fail before you release the repository for further development.
Afterwards, everyone is required to fixing the actions before merging onto development which ensures that you don't need to worry about merge conflicts that exceed the complexity of the occasional conflicts in the future. This is only true of course if everybody does pip install pre-commit and pre-commit install on their local machine or at least use nox manually before pushing new stuff (which should be the default anyways imo.)

Thank you very much for the excellent description. We'll brainstorm and see what we can do.


Assertion failed: m_capacity != 0

On migrating from RealmSwift v1.1.0 to RealmSwift v2.0.3, getting this crash (1) at launch. It wasn't the first launch of the application, but I think it may have directly followed another Realm related crash (2). We were also frequently experiencing this crash https://github.com/realm/realm-cocoa/issues/4244 (on RealmSwift 1.1.0). Apologies for the lack of accompanying project.
Crash 1
array_integer.cpp:131: [realm-core-2.1.4] Assertion failed: m_capacity != 0
0   Realm                               0x0000000101c46720 _ZN5realm4utilL18terminate_internalERNSt3__118basic_stringstreamIcNS1_11char_traitsIcEENS1_9allocatorIcEEEE + 44
1   Realm                               0x0000000101c46968 _ZN5realm4util9terminateEPKcS2_lOSt16initializer_listINS0_9PrintableEE + 368
2   Realm                               0x0000000101cc38c0 _ZN5realm12ArrayIntNull13init_from_memENS_6MemRefE + 124
3   Realm                               0x0000000101ccdee4 _ZN5realm6BpTreeINS_4util8OptionalIxEEE20create_root_from_memERNS_9AllocatorENS_6MemRefE + 180
4   Realm                               0x0000000101cec050 _ZN5realm15TimestampColumnC2EbRNS_9AllocatorEmm + 328
5   Realm                               0x0000000101d6d978 _ZN5realm5Table22create_column_accessorENS_10ColumnTypeEmm + 440
6   Realm                               0x0000000101d69840 _ZN5realm5Table24refresh_column_accessorsEm + 356
7   Realm                               0x0000000101cf0a14 _ZN5realm5Group21create_table_accessorEm + 280
8   Realm                               0x0000000101cf0870 _ZN5realm5Group12do_get_tableEmPFbRKNS_4SpecEE + 220
9   Realm                               0x0000000101d6991c _ZN5realm5Table24refresh_column_accessorsEm + 576
10  Realm                               0x0000000101cf0a14 _ZN5realm5Group21create_table_accessorEm + 280
11  Realm                               0x0000000101cf0870 _ZN5realm5Group12do_get_tableEmPFbRKNS_4SpecEE + 220
12  Realm                               0x0000000101d6991c _ZN5realm5Table24refresh_column_accessorsEm + 576
13  Realm                               0x0000000101cf0a14 _ZN5realm5Group21create_table_accessorEm + 280
14  Realm                               0x0000000101cf0870 _ZN5realm5Group12do_get_tableEmPFbRKNS_4SpecEE + 220
15  Realm                               0x0000000101b1b788 _ZN5realm12ObjectSchemaC2ERKNS_5GroupENS_10StringDataEm + 148
16  Realm                               0x0000000101b20544 _ZN5realm11ObjectStore17schema_from_groupERKNS_5GroupE + 284
17  Realm                               0x0000000101bd41bc _ZN5realm5Realm4initENSt3__110shared_ptrINS_5_impl16RealmCoordinatorEEE + 128
18  Realm                               0x0000000101b27714 _ZN5realm5_impl16RealmCoordinator9get_realmENS_5Realm6ConfigE + 560
19  Realm                               0x0000000101bd5578 _ZN5realm5Realm16get_shared_realmENS0_6ConfigE + 244
20  Realm                               0x0000000101bb70d0 +[RLMRealm realmWithConfiguration:error:] + 568
21  RealmSwift                          0x0000000102ec01dc _TFC10RealmSwift5RealmCfzT_S0_ + 120
22  Other Chat                          0x00000001002ba540 _TZFC10Other_Chat5Model9configurefT_T_ + 692
23  Other Chat                          0x0000000100344814 _TFC10Other_Chat11AppDelegate11applicationfTCSo13UIApplication29didFinishLaunchingWithOptionsGSqGVs10DictionaryCSo8NSObjectPs9AnyObject____Sb + 124
24  Other Chat                          0x00000001003457f4 _TToFC10Other_Chat11AppDelegate11applicationfTCSo13UIApplication29didFinishLaunchingWithOptionsGSqGVs10DictionaryCSo8NSObjectPs9AnyObject____Sb + 208
25  UIKit                               0x000000018dffb42c <redacted> + 400
26  UIKit                               0x000000018e20bb70 <redacted> + 3524
27  UIKit                               0x000000018e2118e0 <redacted> + 1656
28  UIKit                               0x000000018e226080 <redacted> + 48
29  UIKit                               0x000000018e20e8c4 <redacted> + 168
30  FrontBoardServices                  0x0000000189ce18bc <redacted> + 36
31  FrontBoardServices                  0x0000000189ce1728 <redacted> + 176
32  FrontBoardServices                  0x0000000189ce1ad0 <redacted> + 56
33  CoreFoundation                      0x00000001880ee278 <redacted> + 24
34  CoreFoundation                      0x00000001880edbc0 <redacted> + 524
35  CoreFoundation                      0x00000001880eb7c0 <redacted> + 804
36  CoreFoundation                      0x000000018801a048 CFRunLoopRunSpecific + 444
37  UIKit                               0x000000018dff45dc <redacted> + 608
38  UIKit                               0x000000018dfef360 UIApplicationMain + 208
39  Other Chat                          0x00000001002f089c main + 876
40  libdyld.dylib                       0x0000000186ffc5b8 <redacted> + 4
IMPORTANT: if you see this error, please send this log to help@realm.io.(lldb)

Crash 2
MachException: EXC_CRASH
  libsystem_kernel    0x18710e014  __pthread_kill + 8
  libsystem_pthread   0x1871d5460  pthread_kill + 112
  libsystem_c         0x1870823f4  abort + 140
  Realm               0x100cc251c  please_report_this_error_to_help_at_realm_dot_io + 12
  Realm               0x100cc27dc  realm::util::terminate_internal(std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> >&) + 232
  Realm               0x100cc2968  realm::util::terminate(char const*, char const*, long, std::initializer_list<realm::util::Printable>&&) + 368
  Realm               0x100b8c23c  void realm::util::terminate<unsigned long, unsigned long>(char const*, char const*, long, unsigned long, unsigned long) + 44
  Realm               0x100b8c344  realm::LinkView::get(unsigned long) + 264
  Realm               0x100b8aef0  realm::_impl::DeepChangeChecker::check_outgoing_links(unsigned long, realm::Table const&, unsigned long, unsigned long) + 380
  Realm               0x100b8b124  realm::_impl::DeepChangeChecker::check_row(realm::Table const&, unsigned long, unsigned long) + 252
  Realm               0x100b8afcc  realm::_impl::DeepChangeChecker::check_outgoing_links(unsigned long, realm::Table const&, unsigned long, unsigned long) + 600
  Realm               0x100b8b124  realm::_impl::DeepChangeChecker::check_row(realm::Table const&, unsigned long, unsigned long) + 252
  Realm               0x100b8af04  realm::_impl::DeepChangeChecker::check_outgoing_links(unsigned long, realm::Table const&, unsigned long, unsigned long) + 400
  Realm               0x100b8b124  realm::_impl::DeepChangeChecker::check_row(realm::Table const&, unsigned long, unsigned long) + 252
  Realm               0x100b8af04  realm::_impl::DeepChangeChecker::check_outgoing_links(unsigned long, realm::Table const&, unsigned long, unsigned long) + 400
  Realm               0x100b8b124  realm::_impl::DeepChangeChecker::check_row(realm::Table const&, unsigned long, unsigned long) + 252
  Realm               0x100b8afcc  realm::_impl::DeepChangeChecker::check_outgoing_links(unsigned long, realm::Table const&, unsigned long, unsigned long) + 600
  Realm               0x100b8b124  realm::_impl::DeepChangeChecker::check_row(realm::Table const&, unsigned long, unsigned long) + 252
  Realm               0x100b8af04  realm::_impl::DeepChangeChecker::check_outgoing_links(unsigned long, realm::Table const&, unsigned long, unsigned long) + 400
  Realm               0x100b8b124  realm::_impl::DeepChangeChecker::check_row(realm::Table const&, unsigned long, unsigned long) + 252
  Realm               0x100b8afcc  realm::_impl::DeepChangeChecker::check_outgoing_links(unsigned long, realm::Table const&, unsigned long, unsigned long) + 600
  Realm               0x100b8b124  realm::_impl::DeepChangeChecker::check_row(realm::Table const&, unsigned long, unsigned long) + 252
  Realm               0x100b8af04  realm::_impl::DeepChangeChecker::check_outgoing_links(unsigned long, realm::Table const&, unsigned long, unsigned long) + 400
  Realm               0x100b8b124  realm::_impl::DeepChangeChecker::check_row(realm::Table const&, unsigned long, unsigned long) + 252
  Realm               0x100b8af04  realm::_impl::DeepChangeChecker::check_outgoing_links(unsigned long, realm::Table const&, unsigned long, unsigned long) + 400
  Realm               0x100b8b124  realm::_impl::DeepChangeChecker::check_row(realm::Table const&, unsigned long, unsigned long) + 252
  Realm               0x100b8afcc  realm::_impl::DeepChangeChecker::check_outgoing_links(unsigned long, realm::Table const&, unsigned long, unsigned long) + 600
  Realm               0x100b8b124  realm::_impl::DeepChangeChecker::check_row(realm::Table const&, unsigned long, unsigned long) + 252
  Realm               0x100b8af04  realm::_impl::DeepChangeChecker::check_outgoing_links(unsigned long, realm::Table const&, unsigned long, unsigned long) + 400
  Realm               0x100b8b124  realm::_impl::DeepChangeChecker::check_row(realm::Table const&, unsigned long, unsigned long) + 252
  Realm               0x100b8af04  realm::_impl::DeepChangeChecker::check_outgoing_links(unsigned long, realm::Table const&, unsigned long, unsigned long) + 400
  Realm               0x100b8b124  realm::_impl::DeepChangeChecker::check_row(realm::Table const&, unsigned long, unsigned long) + 252
  Realm               0x100b8af04  realm::_impl::DeepChangeChecker::check_outgoing_links(unsigned long, realm::Table const&, unsigned long, unsigned long) + 400
  Realm               0x100b8b124  realm::_impl::DeepChangeChecker::check_row(realm::Table const&, unsigned long, unsigned long) + 252
  Realm               0x100b8af04  realm::_impl::DeepChangeChecker::check_outgoing_links(unsigned long, realm::Table const&, unsigned long, unsigned long) + 400
  Realm               0x100b8b124  realm::_impl::DeepChangeChecker::check_row(realm::Table const&, unsigned long, unsigned long) + 252
  Realm               0x100b8afcc  realm::_impl::DeepChangeChecker::check_outgoing_links(unsigned long, realm::Table const&, unsigned long, unsigned long) + 600
  Realm               0x100b8b124  realm::_impl::DeepChangeChecker::check_row(realm::Table const&, unsigned long, unsigned long) + 252
  Realm               0x100b8af04  realm::_impl::DeepChangeChecker::check_outgoing_links(unsigned long, realm::Table const&, unsigned long, unsigned long) + 400
  Realm               0x100b8b124  realm::_impl::DeepChangeChecker::check_row(realm::Table const&, unsigned long, unsigned long) + 252
  Realm               0x100b8b224  realm::_impl::DeepChangeChecker::operator()(unsigned long) + 68
  Realm               0x100b850b0  std::__1::function<bool (unsigned long)>::operator()(unsigned long) const + 40
  Realm               0x100b96ecc  realm::_impl::ListNotifier::run() + 148
  Realm               0x100ba5074  realm::_impl::RealmCoordinator::run_async_notifiers() + 1192
  Realm               0x100ba4b78  realm::_impl::RealmCoordinator::on_change() + 24
  Realm               0x100b8e168  realm::_impl::ExternalCommitHelper::listen() + 172
  Realm               0x100b8f244  std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0>::operator()() + 28
  Realm               0x100b8f1cc  std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >::__execute() + 28
  Realm               0x100b8f394  std::__1::__thread_proxy<std::__1::tuple<void (std::__1::__async_assoc_state<void, std::__1::__async_func<realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >::*)(), std::__1::__async_assoc_state<void, std::_... + 84
  libsystem_pthread   0x1871d3860  <redacted> + 240
  libsystem_pthread   0x1871d3770  _pthread_start + 284

We just released Realm 2.1.1 which includes several bug fixes, including one for a critical bug that could have caused file corruption. This looks like the issue you reported.
Please update to this version as soon as possible. https://github.com/realm/realm-cocoa/releases/tag/v2.1.1
Updating to this version won't automatically repair already corrupt files, so existing users who have experienced corruption will need to delete their affected Realm files. You can send these Realm files to us for forensic recovery if the data is critical.
Thanks.

I'm closing this issue because it seems to be fixed at 2.1.1. But please let us know if what we've posted here helped, and if you have any further questions or suggestions!


perf: Apply VisitCache to GenericExpander

Description:
csstype: 11.4 seconds => 10.2 seconds
Related issue:

Closes https://github.com/dudykr/stc/issues/523.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: kdy1:x: kodiakhq[bot]You have signed the CLA already but the status is still pending? Let us recheck it.


No source code?

Comment:
Hey, any clue where did the source code go? https://github.com/goodwanghan/qpd, linked from the project metadata on PyPI, gives 404 now. cc @goodwanghan

cc @kvnkho too, since I see qpd is listed as a Fugue dependency

@astrojuanlu it was not open sourced yet. We are trying to get rid of this package from the core dependency of Fugue. Is there any concern about this?

It appeared as a transitive dependency of ours through other package (darts), I investigated, and found it weird that the repo was not accessible. Thanks for the clarification. Is there an issue on Fugue tracking the removal of qpd?

It's not open source but uses BSD-3-Clause?

@thewchan , that's a good call. So for context, qpd is a dependency for Fugue, but users don't ever interact with it or see it. It's very much a backend thing, and we wanted to deprecate it actually for Fugue, which is why it's not open sourced. We didn't want people to be using something directly that we'd eventually deprecate. It's not about hiding the source.
For @astrojuanlu , no issue tracking yet.

I'd just note here that Conda Forge requires all dependency to have open source license of some sort to host. We were able to get around this because the sdist for qpd is available on PyPI, hence why it fell through the cracks way back when we first bring fugue to Conda Forge. My recommendation is that if qpd is "harmless" and contain no confidential/proprietary code/data, it should be released open source. But of course, since fugue and also qpd is already up on Conda Forge and there is apparently plans to drop qpd in the near future, perhaps we just maintain the status quo. I would just say that if for qpd only the wheel binaries were on PyPI and not the sdist, and that its source code repo was not published, that would have actually been a blocker to bring fugue on board to conda forge back then.


shared task folder

Hi evrenvarol,
I like your kanban System for Outlook. it is a great idea!
What I'm trying to do is to share a task folder with my colleges and show it in the kanban view.
The problem is, that the person who receive the task folder can not show it in the kanban view, because it didn't find the shared folder.
In the folder settings is no path where the shared folder could be.
Do you have a solution for that?
I'm looking forward to your answer.
Best Greetings
Michael

Thanks Michael, I'm not using any shared task folders with my colleagues but I think there seems to be solution for that.
I will update the code and let you know when it is ready for testing.
Evren

Hi Evren,
I would really appreciate that! Thank you!
Michael

I have found a solution for our problem. Now we are using a shared email account.
To get the tasks this function is needed:
var myRecipient = outlookNS.CreateRecipient(addressName);
 myRecipient.Resolve;
if(myRecipient.Resolved){
var tasks = outlookNS.GetSharedDefaultFolder(myRecipient,13);
}

Where should that function be added?

inside app.js.
it depends on which folder/tasks you need, but for example on every line like this:
var tasksfolder = outlookNS.GetDefaultFolder(13).Folders

Hi @kohlhaas1808,
I have done some updates to the master repo, can you please download it again and edit the config.js file for your shared folder setup.
You can change the Name value for the name of the folder and the Owner value for the owner's name. (whoever is sharing the folder)
Unfortunately, I wasn't able to test it as i don't have any shared folders. In theory, it should work.  Let me know how it goes. Thanks!

Hey Evren,
I have found a minor mistake on Line 116 in app.js
var folder = outlookNS.GetSharedDefaultFolder(recipient, 13).Folders(path);
you need to change path to folderpath
After that change the code is working

Thanks a lot Michael, I have corrected the line with the current update (several other items fixed as well).
I will be closing this issue as the issue seems to be resolved.


Implement authentication and authorization

Fixes #7 .
Changes proposed in this pull request:

Implement Session Authentication using username and password.
Implement Authorization.

I have checked successfully working this application. I will merge to master.


Create 1 serial communication with DB-25

The instructions say:
Connect computer to Create's 7-pin serial port
-If using Create 1, ensure that nothing is connected to Create's DB-25 port
Just to be clear, is there support for using DB-25 port rather than the 7-pin port?

I have not had the opportunity to try running the driver using the DB-25. I know you can control the robot with the same protocol through either port, so I guess there shouldn't be any problems.

Has anyone had any success with this method? I'm also considering trying to use this method.
Can I just use a DB25 to USB converter use the driver?

The robot is connected successfully through the DB25 port but this error keeps coming up

@pradhanshrijal When you say the robot is connected successfully, what do you mean? Can you see the robot in the device list?
If you are using the default config, then the driver tries to open /dev/ttyUSB0.

I'm having the same issue, but with the create2.
When I try running roslaunch ca_driver create_2.launch, I get the below error. I've made sure to source my devel/setup.bash and have done sudo usermod -a -G dialout $USER and restarted. This is running on a raspberry pi 4 connected to a iRobot Roomba Create2 via the normal serial USB cable. I have also ensured that the roomba is connected to the default dev/tty/USB0.
setting /run_id to fcd666f0-c5f5-11ea-bf57-dca63263c8e0
process[rosout-1]: started with pid [7613]
started core service [/rosout]
process[ca_driver-2]: started with pid [7617]
[ INFO] [1594747093.564272165]: [CREATE] "CREATE_2" selected
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >'
  what():  open: No such file or directory
[ca_driver-2] process has died [pid 7617, exit code -6, cmd /home/ubuntu/Programming/create_ws/devel/lib/ca_driver/ca_driver __name:=ca_driver __log:=/home/ubuntu/.ros/log/fcd666f0-c5f5-11ea-bf57-dca63263c8e0/ca_driver-2.log].

@jacobperron
I'm having the same issue, but with the create2.
When I try running roslaunch ca_driver create_2.launch, I get the below error. I've made sure to source my devel/setup.bash and have done sudo usermod -a -G dialout $USER and restarted. This is running on a raspberry pi 4 connected to a iRobot Roomba Create2 via the normal serial USB cable. I have also ensured that the roomba is connected to the default dev/tty/USB0.
setting /run_id to fcd666f0-c5f5-11ea-bf57-dca63263c8e0
process[rosout-1]: started with pid [7613]
started core service [/rosout]
process[ca_driver-2]: started with pid [7617]
[ INFO] [1594747093.564272165]: [CREATE] "CREATE_2" selected
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >'
  what():  open: No such file or directory
[ca_driver-2] process has died [pid 7617, exit code -6, cmd /home/ubuntu/Programming/create_ws/devel/lib/ca_driver/ca_driver __name:=ca_driver __log:=/home/ubuntu/.ros/log/fcd666f0-c5f5-11ea-bf57-dca63263c8e0/ca_driver-2.log].