[Usable: Settings>Keyboard Manager>Remap a Shortcut]: Complete text is not getting selected when navigate to the Target App edit field in Remap a Shortcut.

[Power Toys Setting-Keyboard Manager-Remap a key]
User Experience:
This will impact all the users if keyboard focus is not selecting the complete text present in the edit field as user have to remove the text manually.
Test Environment:
OS Version: 20221.1000
App Name: Power Toy Preview
App Version: v0.23.0
Screen Reader: Narrator
Repro Steps:

Open Power Toys Settings App. Turn on narrator.
Navigate to Keyboard Manager menu item present in left pane and activate it.
Navigate to Remap a shortcut button present in right pane and activate it.
Remap shortcut window will open.
Navigate to 'Add' button present in window and activate it.
Navigate to 'App Target' edit field and activate it.
Type any word and navigate to the field and verify the issue.

Actual Result:
Complete text is not getting selected when navigate to the Target App edit field in Remap a Shortcut.
Expected Result:
Complete text should be getting selected when navigate to the Target App edit field in Remap a Shortcut.
MAS Reference:
https://microsoft.sharepoint.com/:w:/r/teams/msenable/_layouts/15/Doc.aspx?sourcedoc=%7BF98F4235-B6BD-47D3-8DA4-F28B9B6FBFA8%7D&file=Guideline%20101%20%E2%80%93%20Recommended%20Assistive%20Technology%20Tools%20for%20MAS%20Testing%20of%20Microsoft%20Digital%20Properties.docx&action=default&mobileredirect=true
Remap shortcut_Usable_complete text is not getting selected.zip

Added in 0.25 release https://github.com/microsoft/PowerToys/releases/tag/v0.25.0


Accessing sprite before assignment: error message is unhelpful

From the forum: https://forum.makecode.com/t/why-does-this-happen/6798
When trying to access a null sprite - in this case the call to fog.kind() when fog is null, results in this error message:
Program Error: Cannot read property 'fields' of null
This seems like an easy programming error for beginners to make. Improving this specific error message would help beginners over this hurdle, and serve as a teaching moment rather than a dead end.
Could this instead say Sprite 'fog' accessed before assignment?
Additionally, highlighting the block where the error occurred would be helpful. At the moment there's no indication where the program failed.

Duplicate of https://github.com/microsoft/pxt-arcade/issues/2321


Fix macos/widevine patch

Looks good.
BTW, are you not using quilt to refresh the patch? I noticed the filenames are different in the patch header, which I think quilt removes if you use it to manage patches. There are some usage examples in DEVELOPING.md

no, just diff.
I didn't touch the filenames though, I think it's just github patch syntax highlighting.


[Rewrite] API Changes

Change all API routes to use /api/v1/(internal | external)/ (route)
For example, our request to GET /api/stats now => GET /api/v1/internal/stats
Or, POST /api/rcon => POST /api/v1/external/rcon
This rewrite would make use of the express router, so handling routes would be better eased. Leaves a ton of room in the index.ts file to be for the dashboard site.
A "catch-all" route would be applied as well, and would tell the user that it was not found on the server. This will come in handy for the dashboard site I believe.
All external routes would be revamped as well perhaps, as the rcon uses a promise which is not applicable there.

Comment to remind self about the private vs public aspect of the API.
Everyone should have access to the stats, commands, autoresponses and all of those combined routes.
No one should have access to private API routes, such as those listing stuff from the DB. Private API routes should also be noted on the URL, so then when creating the Router I can attach 1 middleware and it will just "work" as they say.

https://www.teamfortress.tv/49738/pugchamp-helper/?page=2#48
Note to self: do a PR when this happens so pugchamp-helper and TF2-Helper don't die when this migration takes place.


Incorrect main/module/exports specified in its package.json

Brief bug description
When using this package in an Astro project, Astro throws this error
error   Failed to resolve entry for package "@kontent-ai/delivery-node-parser". The package may have incorrect main/module/exports specified in its package.json.
It looks like
"module": "./dist/esm5/index.js",
"es2015": "./dist/esm/index.js",

in the package.json should read
"module": "./dist/es6/index.js",
"es2015": "./dist/es6/index.js",

as there is no esm5 or esm folder in the package /dist folder, only 'cjs, es6, es2020, esnext'.
Repro steps
There's quite a few steps to reproduce in our demo repo but I believe if you try and add this package to any Vite project, it should throw the same error (as Astro uses Vite under the hood).
If you need more details @Enngage I'm more than happy to record a quick demo video or jump on a Zoom call / Hangout.
Expected behavior
The module references in package.json point to the correct output folder.
Additional context
In our demo Astro project we resolve rich text info from the Delivery API into an object, so that we can create a custom resolver component for outputting the HTML we need.
import { nodeParser } from "@kontent-ai/delivery-node-parser";
import { createRichTextObjectResolver, Elements, linkedItemsHelper } from "@kontent-ai/delivery-sdk";

export default async function resolveRichText(richTextElement: Elements.RichTextElement) {
    const resolvedObject = createRichTextObjectResolver(nodeParser).resolveRichText({
        element: richTextElement,
        linkedItems: linkedItemsHelper.convertLinkedItemsToArray(richTextElement.linkedItems),
    });

    return resolvedObject;
}

but while our editor doesn't throw an error (it resolves the dist/cjs files), the Vite dev server Astro runs under the hood throws an error

Going into<EMAIL_ADDRESS>and changing module and es2015 to the following resolves the issues
"module": "./dist/es6/index.js",
"es2015": "./dist/es6/index.js",

I've released the PR by @benmorana in 3.1.0


missing feedback when there a no results for a search

a message like "No results available" could help the user understand what is going on

added feedback in German and English


Server rendering?

I am building an univers app. I tried to use RIC but it seems that it doesn't work for server rendering? Or maybe I got wrong on something?

Hey @brickyang, I haven't had to use this project in an SSR environment. Would you be interested in contributing a PR that implements this?

I would like to try, but I can't make any promise. Because I haven't tried PR a project before. Not sure if I can do it right. Anyway, I will try my best.

I had the same issue earlier and created the PR - https://github.com/clauderic/react-infinite-calendar/pull/98


Download the latest version of package url

Description

Download the latest version of package url (pypi, npm, maven, pub)
Type of change
Please insert 'x' one of the type of change.

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Documentation update
[ ] Refactoring, Maintenance
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

@dd-jy , fosslight_util의 최소 버전을 1.4.36으로 변경 필요합니다.


Revamping for xcode 9

Actual Behaviour
App doesn't run and gives an error of 'Ambiguous use of title' on line 22 of TrainingVCMethods.swift
App doesn't run and gives an error of 'Ambiguous use of title' on line 20 of ResetPasswordVCMethods.swift
Note: This issue now includes all the occurences of navigationItem.title = ... and they all have now been changed to navigationItem.titleLabel.text.
Expected Behaviour
App was supposed to run, guess it was a bug in xcode 9. But i have fixed it and i'll be building for ios 11.
Steps to reproduce it
Replace titleLabel with title and you get the error
Would you like to work on the issue?
Yes, gladly

Hi @chashmeetsingh I am working on this issue!


Include stderr when retrieving docker logs

Resolves #1158

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Shahin Saneinejad seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

Thanks!


Add support for filesystem polling

Adds WIREIT_WATCH_STRATEGY and WIREIT_WATCH_POLL_MS environment variables which can be used to switch filesystem detection from event-based to polling:
export WIREIT_WATCH_STRATEGY=poll
export WIREIT_WATCH_POLL_MS=<a number of you don't like the default of 500>

Currently this just sets the chokidar usePolling and interval options. It might be nice to actually bypass chokidar entirely so that this option can be used to bypass any potential issues with chokidar generally, but it's slightly complex (just re-running the script on an interval isn't great, because of scripts which aren't set up well for caching).
This is published as v0.14.9-pre.1. Would be great to hear from @peschee if this is a useful workaround for the OOM errors they have been seeing in their project.

So cool @aomarks, will give this a spin on Monday.

@aomarks I gave this a go yesterday and in my first tests, using WIREIT_WATCH_STRATEGY=poll I'm not experiencing any OOM issues anymore. I will keep an eye out the next few days, but from where I stand, this looks like a great addition to me!

💪🏼


Fetch Data through DuckDuckGo News Feed Tab

Hello,
Can we get a feature that fetches data directly through DuckDuckGo News tab?
Such As:
https://duckduckgo.com/?q=MY_KEYWORD&iar=news&ia=news

No need:
https://www.reddit.com/r/rss/comments/jg289o/rss_from_duckduckgo_results/
https://www.bing.com/news/search?q=MY_KEYWORD&format=rss

close?

Yes


Enhancement of Contact forms and correction of improper alignment of qucik links section and also wanted to add a preloader if possible

Hello @codervivek5
I would like to enhance the contact forms
###Screenshot

There is imprpoer alignment of the Quick links section and lack of responsiveness according to screen width and height

[x] I agree to follow this project's Code of Conduct
[x] I'm a GSSOC'24 contributor
[x] I want to work on this issue
Please assign this issue to me...
would like to work upon this

Hi. Under GSSOC'24, I would like to work on this issue.
Please Assign me this task.

@pand-coder somone is alrady working  on this issue so I can't assign it to  you now


Failed assertion: line 5241 pos 14: '_dependents.isEmpty': is not true.

Steps to Reproduce

Execute flutter run to default Page Login.dart
Click Sign in with token and Navigator to Home.dart.
Click Logout button to navigator to Login.dart
Click Sign in with different token and Navigator to Home.dart.
Expected results:
display normal and no error logs.
Actual results:

white screen and error log:

Code sample

body: WillPopScope(
        onWillPop: () async {
          if (app.navigatorKey.currentState != null && app.navigatorKey.currentState!.canPop()) {
            app.navigatorKey.currentState!.pop();
            return false;
          }
          return true;
        },
        child: Navigator(
          key: app.navigatorKey,
          initialRoute: '/',
          onGenerateRoute: (RouteSettings settings) {
            WidgetBuilder builder = routes[settings.name]!;
            // Manage your route names here

            Future.delayed(Duration(milliseconds: 100)).then((value) => updateState(settings.name));

            // You can also return a PageRouteBuilder and
            // define custom transitions between pages
            return MaterialPageRoute(
              builder: builder,
              settings: settings,
            );
          },
        ),
      ),
      bottomNavigationBar: BottomNavigationBar(...)

Logs

======== Exception caught by widgets library =======================================================
The following assertion was thrown building WillPopScope(dependencies: [_ModalScopeStatus], state: _WillPopScopeState#27f1e):
'package:flutter/src/widgets/framework.dart': Failed assertion: line 5241 pos 14: '_dependents.isEmpty': is not true.

Either the assertion indicates an error in the framework itself, or we should provide substantially more information in this error message to help you determine and fix the underlying cause.
In either case, please report this assertion by filing a bug on GitHub:
  https://github.com/flutter/flutter/issues/new?template=2_bug.md

The relevant error-causing widget was:
  WillPopScope WillPopScope:file:///E:/front/project_flutter_crm/lib/view/home.dart:53:13
When the exception was thrown, this was the stack:
#2      InheritedElement.debugDeactivated.<anonymous closure> (package:flutter/src/widgets/framework.dart:5241:14)
#3      InheritedElement.debugDeactivated (package:flutter/src/widgets/framework.dart:5243:6)
#4      _InactiveElements._deactivateRecursively.<anonymous closure> (package:flutter/src/widgets/framework.dart:2000:15)
#5      _InactiveElements._deactivateRecursively (package:flutter/src/widgets/framework.dart:2002:6)
#6      ComponentElement.visitChildren (package:flutter/src/widgets/framework.dart:4845:14)
#7      _InactiveElements._deactivateRecursively (package:flutter/src/widgets/framework.dart:1998:13)
#8      SingleChildRenderObjectElement.visitChildren (package:flutter/src/widgets/framework.dart:6288:14)
#9      _InactiveElements._deactivateRecursively (package:flutter/src/widgets/framework.dart:1998:13)
#10     ComponentElement.visitChildren (package:flutter/src/widgets/framework.dart:4845:14)
#11     _InactiveElements._deactivateRecursively (package:flutter/src/widgets/framework.dart:1998:13)
#12     SingleChildRenderObjectElement.visitChildren (package:flutter/src/widgets/framework.dart:6288:14)
#13     _InactiveElements._deactivateRecursively (package:flutter/src/widgets/framework.dart:1998:13)
#14     SingleChildRenderObjectElement.visitChildren (package:flutter/src/widgets/framework.dart:6288:14)
#15     _InactiveElements._deactivateRecursively (package:flutter/src/widgets/framework.dart:1998:13)
#16     ComponentElement.visitChildren (package:flutter/src/widgets/framework.dart:4845:14)
#17     _InactiveElements._deactivateRecursively (package:flutter/src/widgets/framework.dart:1998:13)
#18     ComponentElement.visitChildren (package:flutter/src/widgets/framework.dart:4845:14)
#19     _InactiveElements._deactivateRecursively (package:flutter/src/widgets/framework.dart:1998:13)
#20     _InactiveElements.add (package:flutter/src/widgets/framework.dart:2010:7)
#21     Element.deactivateChild (package:flutter/src/widgets/framework.dart:3863:30)
#22     Element._retakeInactiveElement (package:flutter/src/widgets/framework.dart:3763:14)
...     Normal element mounting (27 frames)
#49     Element.inflateWidget (package:flutter/src/widgets/framework.dart:3823:14)
#50     MultiChildRenderObjectElement.inflateWidget (package:flutter/src/widgets/framework.dart:6436:36)
#51     MultiChildRenderObjectElement.mount (package:flutter/src/widgets/framework.dart:6448:32)
...     Normal element mounting (263 frames)
#314    Element.inflateWidget (package:flutter/src/widgets/framework.dart:3823:14)
#315    MultiChildRenderObjectElement.inflateWidget (package:flutter/src/widgets/framework.dart:6436:36)
#316    Element.updateChild (package:flutter/src/widgets/framework.dart:3562:18)
#317    RenderObjectElement.updateChildren (package:flutter/src/widgets/framework.dart:5865:32)
#318    MultiChildRenderObjectElement.update (package:flutter/src/widgets/framework.dart:6461:17)
#319    Element.updateChild (package:flutter/src/widgets/framework.dart:3541:15)
#320    ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:4818:16)
#321    StatefulElement.performRebuild (package:flutter/src/widgets/framework.dart:4963:11)
#322    Element.rebuild (package:flutter/src/widgets/framework.dart:4515:5)
#323    StatefulElement.update (package:flutter/src/widgets/framework.dart:4995:5)
#324    Element.updateChild (package:flutter/src/widgets/framework.dart:3541:15)
#325    ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:4818:16)
#326    Element.rebuild (package:flutter/src/widgets/framework.dart:4515:5)
#327    ProxyElement.update (package:flutter/src/widgets/framework.dart:5140:5)
#328    Element.updateChild (package:flutter/src/widgets/framework.dart:3541:15)
#329    ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:4818:16)
#330    Element.rebuild (package:flutter/src/widgets/framework.dart:4515:5)
#331    ProxyElement.update (package:flutter/src/widgets/framework.dart:5140:5)
#332    _InheritedNotifierElement.update (package:flutter/src/widgets/inherited_notifier.dart:108:11)
#333    Element.updateChild (package:flutter/src/widgets/framework.dart:3541:15)
#334    SingleChildRenderObjectElement.update (package:flutter/src/widgets/framework.dart:6308:14)
#335    Element.updateChild (package:flutter/src/widgets/framework.dart:3541:15)
#336    ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:4818:16)
#337    StatefulElement.performRebuild (package:flutter/src/widgets/framework.dart:4963:11)
#338    Element.rebuild (package:flutter/src/widgets/framework.dart:4515:5)
#339    StatefulElement.update (package:flutter/src/widgets/framework.dart:4995:5)
#340    Element.updateChild (package:flutter/src/widgets/framework.dart:3541:15)
#341    SingleChildRenderObjectElement.update (package:flutter/src/widgets/framework.dart:6308:14)
#342    Element.updateChild (package:flutter/src/widgets/framework.dart:3541:15)
#343    SingleChildRenderObjectElement.update (package:flutter/src/widgets/framework.dart:6308:14)
#344    Element.updateChild (package:flutter/src/widgets/framework.dart:3541:15)
#345    ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:4818:16)
#346    Element.rebuild (package:flutter/src/widgets/framework.dart:4515:5)
#347    ProxyElement.update (package:flutter/src/widgets/framework.dart:5140:5)
#348    Element.updateChild (package:flutter/src/widgets/framework.dart:3541:15)
#349    ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:4818:16)
#350    StatefulElement.performRebuild (package:flutter/src/widgets/framework.dart:4963:11)
#351    Element.rebuild (package:flutter/src/widgets/framework.dart:4515:5)
#352    BuildOwner.buildScope (package:flutter/src/widgets/framework.dart:2713:19)
#353    WidgetsBinding.drawFrame (package:flutter/src/widgets/binding.dart:882:21)
#354    RendererBinding._handlePersistentFrameCallback (package:flutter/src/rendering/binding.dart:367:5)
#355    SchedulerBinding._invokeFrameCallback (package:flutter/src/scheduler/binding.dart:1145:15)
#356    SchedulerBinding.handleDrawFrame (package:flutter/src/scheduler/binding.dart:1082:9)
#357    SchedulerBinding._handleDrawFrame (package:flutter/src/scheduler/binding.dart:996:5)
#361    _invoke (dart:ui/hooks.dart:151:10)
#362    PlatformDispatcher._drawFrame (dart:ui/platform_dispatcher.dart:308:5)
#363    _drawFrame (dart:ui/hooks.dart:115:31)
(elided 5 frames from class _AssertionError and dart:async)
====================================================================================================

======== Exception caught by widgets library =======================================================
The following assertion was thrown while finalizing the widget tree:
Duplicate GlobalKey detected in widget tree.

The following GlobalKey was specified multiple times in the widget tree. This will lead to parts of the widget tree being truncated unexpectedly, because the second time a key is seen, the previous instance is moved to the new location. The key was:
- [LabeledGlobalKey<NavigatorState>#d402b]
This was determined by noticing that after the widget with the above global key was moved out of its previous parent, that previous parent never updated during this frame, meaning that it either did not update at all or updated before the widget was moved, in either case implying that it still thinks that it should have a child with that global key.
The specific parent that did not update after having one or more children forcibly removed due to GlobalKey reparenting is:
- WillPopScope(dependencies: [_ModalScopeStatus], state: _WillPopScopeState#7ce4a)
A GlobalKey can only be specified on one widget at a time in the widget tree.
When the exception was thrown, this was the stack:
#0      BuildOwner.finalizeTree.<anonymous closure> (package:flutter/src/widgets/framework.dart:3045:15)
#1      BuildOwner.finalizeTree (package:flutter/src/widgets/framework.dart:3070:8)
#2      WidgetsBinding.drawFrame (package:flutter/src/widgets/binding.dart:884:19)
#3      RendererBinding._handlePersistentFrameCallback (package:flutter/src/rendering/binding.dart:367:5)
#4      SchedulerBinding._invokeFrameCallback (package:flutter/src/scheduler/binding.dart:1145:15)
#5      SchedulerBinding.handleDrawFrame (package:flutter/src/scheduler/binding.dart:1082:9)
#6      SchedulerBinding._handleDrawFrame (package:flutter/src/scheduler/binding.dart:996:5)
#10     _invoke (dart:ui/hooks.dart:151:10)
#11     PlatformDispatcher._drawFrame (dart:ui/platform_dispatcher.dart:308:5)
#12     _drawFrame (dart:ui/hooks.dart:115:31)
(elided 3 frames from dart:async)
====================================================================================================

======== Exception caught by scheduler library =====================================================
The following assertion was thrown during a scheduler callback:
Tried to build dirty widget in the wrong build scope.

A widget which was marked as dirty and is still active was scheduled to be built, but the current build scope unexpectedly does not contain that widget.

Sometimes this is detected when an element is removed from the widget tree, but the element somehow did not get marked as inactive. In that case, it might be caused by an ancestor element failing to implement visitChildren correctly, thus preventing some or all of its descendants from being correctly deactivated.

The root of the build scope was: [root]
  renderObject: RenderView#16531
The offending element (which does not appear to be a descendant of the root of the build scope) was: FocusScope
  debugLabel: "_ModalScopeState<dynamic> Focus Scope"
  focusNode: FocusScopeNode#c6bfe(_ModalScopeState<dynamic> Focus Scope [PRIMARY FOCUS])
  dirty
  dependencies: [_FocusMarker]
  state: _FocusScopeState#e871c
When the exception was thrown, this was the stack:
#0      BuildOwner.buildScope.<anonymous closure> (package:flutter/src/widgets/framework.dart:2675:13)
#1      BuildOwner.buildScope (package:flutter/src/widgets/framework.dart:2700:10)
#2      WidgetsBinding.drawFrame (package:flutter/src/widgets/binding.dart:882:21)
#3      RendererBinding._handlePersistentFrameCallback (package:flutter/src/rendering/binding.dart:367:5)
#4      SchedulerBinding._invokeFrameCallback (package:flutter/src/scheduler/binding.dart:1145:15)
#5      SchedulerBinding.handleDrawFrame (package:flutter/src/scheduler/binding.dart:1082:9)
#6      SchedulerBinding._handleDrawFrame (package:flutter/src/scheduler/binding.dart:996:5)
#10     _invoke (dart:ui/hooks.dart:151:10)
#11     PlatformDispatcher._drawFrame (dart:ui/platform_dispatcher.dart:308:5)
#12     _drawFrame (dart:ui/hooks.dart:115:31)
(elided 3 frames from dart:async)
====================================================================================================
W/IInputConnectionWrapper( 4436): setComposingText on inactive InputConnection
W/IInputConnectionWrapper( 4436): getTextBeforeCursor on inactive InputConnection

@alaxcc
The code sample you provided is not complete, so we can't directly use it to run and verify. Please provide a complete minimal reproducible code sample that we can simply copy paste and run that triggers the issue you are reporting.
Also, from the log, it shows below that indicates you'll need to revisit your code implementation to see if you are not using duplicate globalkey and its usage.
The following assertion was thrown while finalizing the widget tree:
Duplicate GlobalKey detected in widget tree.
The following GlobalKey was specified multiple times in the widget tree. This will lead to parts of the widget tree being truncated unexpectedly, because the second time a key is seen, the previous instance is moved to the new location. The key was:
- [LabeledGlobalKey<NavigatorState>#d402b]
This was determined by noticing that after the widget with the above global key was moved out of its previous parent, that previous parent never updated during this frame, meaning that it either did not update at all or updated before the widget was moved, in either case implying that it still thinks that it should have a child with that global key.
The specific parent that did not update after having one or more children forcibly removed due to GlobalKey reparenting is:
- WillPopScope(dependencies: [_ModalScopeStatus], state: _WillPopScopeState#7ce4a)
A GlobalKey can only be specified on one widget at a time in the widget tree.

I solved this problem.
The cause was caused by repeatedly entering a Page that contained a WillPopScope. When trying to always use a Page containing a WillPopScope as a container to display multiple other components, it's easy to get confused with other real pages. I think this is the reason for the error.
I got around this by determining if the GlobalKey used by this WillPopScope exists....


Add GetBuildID method. Add some retries to api calls

The GetBuildID method takes the buildTypeID, branchName and buildNumber and returns the buildID.
All the call to the api are retried up to 8 times if an error occured

Ship it..looks good quickly :-)


Always include json-c as 'json-c/json.h'

Some systems (e.g. MacOS X) can't find json-c without the relative
directory. This means make depslist breaks the compilation there.

pkg-config should take care of paths. Can you please:

run ./config.sh and show the contents of config.mk?
tell me what version of macOS you're running
tell me how you installed json-c

Also, what compiler are you using? It added system paths (/usr/local/include) to the depslist, which broke all the Linux builds (because on Linux it's usually /usr/include).

Either way, I suspect to really resolve this we need to resolve #792. Then everybody gets their personal depslists, and this problem automatically goes away.

pkg-config should take care of paths. Can you please:
1. run `./config.sh` and show the contents of _config.mk_?

mario.rugiero@mrugiero-macbook newsboat % ./config.sh
Checking for package sqlite3... found
Checking for package libcurl... found
Checking for package libxml-2.0... found
Checking for package stfl... found
Checking for package json... not found
Checking for package json-c... found
Checking for package ncurses5.4 using ncurses5.4-config... found
mario.rugiero@mrugiero-macbook newsboat % cat config.mk

# configuration for package sqlite3
LDFLAGS+=-lsqlite3

# configuration for package libcurl
LDFLAGS+=-lcurl

# configuration for package libxml-2.0
DEFINES+=-I/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/libxml2
LDFLAGS+=-lxml2

# configuration for package stfl
DEFINES+=-I/usr/local/Cellar/libstfl/0.24_10/include
LDFLAGS+=-L/usr/local/Cellar/libstfl/0.24_10/lib -lstfl

# configuration for package json-c
DEFINES+=-I/usr/local/Cellar/json-c/0.13.1/include/json-c
LDFLAGS+=-L/usr/local/Cellar/json-c/0.13.1/lib -ljson-c

# configuration for package ncurses5.4
DEFINES+=-I/usr/include/ncurses
LDFLAGS+=-lncurses

LDFLAGS+=-framework Security
LDFLAGS+=-framework CoreFoundation

2. tell me what version of macOS you're running

Mojave, then Cataline.

3. tell me how you installed json-c

brew install json-c

Also, what compiler are you using? It added system paths (/usr/local/include) to the depslist, which broke all the Linux builds (because on Linux it's usually /usr/include).

mario.rugiero@mrugiero-macbook newsboat % c++ --version
Apple clang version 11.0.3 (clang-1<IP_ADDRESS>)
Target: x86_64-apple-darwin19.5.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Either way, I suspect to really resolve this we need to resolve #792. Then everybody gets their personal depslists, and this problem automatically goes away.
Actually, the issue appears only after I run make depslist. Pristine works fine, but I'm working on a few changes that may add or remove source files and thus need to rebuild the list.

Anyway, I'm sure this is not the place to propose it, but I started replacing the places where json-c is used to use the implementation shipped in the repository (nlohmann), so we can just get rid of one dependency. Does that sound like a good idea? It'll probably need some scrutiny, but I think I can have an RFC working next weekend.

Pristine works fine

Ah, that's an important clue! It explains why the exact same setup on CI works; we are not running make depslist on macOS on CI.
Your config.mk contains -I/usr/local/Cellar/json-c/0.13.1/include/json-c, so #include <json.h> should just work. Do you see this -I… in compiler's parameters when you're running make? Can you take a look inside /usr/local/Cellar/json-c/0.13.1/include/json-c to ensure that it contains json.h? I'm afraid I'm of not much help here, since I don't have a Mac to test all of this myself (experimenting on CI is excruciatingly slow).

I started replacing the places where json-c is used to use the implementation shipped in the repository (nlohmann), so we can just get rid of one dependency. Does that sound like a good idea?

It's not a bad one :) There are a couple of twists, though:

json-c is used in "remote APIs", for which we don't have tests. Changes have to be tested manually, by registering with the API provider and using Newsboat with it. Are you up for that?
Newsboat is being ported to Rust. Bugfixes, refactoring, and features are definitely welcome in the C++ code, but migrating between C++ libraries doesn't have nearly as much impact — it's all going to be replaced again, anyway. How interested/ready are you in just porting these APIs to Rust? It's a much larger task, but I will break it down into manageable pieces (porting one class at a time) and assist you in figuring out what's going on in the C++ code.

I'm going to close this PR (it can't be merged because it breaks Linux, and it isn't even strictly necessary on macOS); thanks for submitting it though!
We can continue the hlohmann/json discussion here, though; I have no better place for it right now.

Pristine works fine

Ah, that's an important clue! It explains why the exact same setup on CI works; we are not running make depslist on macOS on CI.

Yeah, I see how that may be complicated :/

Your config.mk contains -I/usr/local/Cellar/json-c/0.13.1/include/json-c, so #include <json.h> should just work. Do you see this -I… in compiler's parameters when you're running make? Can you take a look inside /usr/local/Cellar/json-c/0.13.1/include/json-c to ensure that it contains json.h? I'm afraid I'm of not much help here, since I don't have a Mac to test all of this myself (experimenting on CI is excruciatingly slow).

mario.rugiero@mrugiero-macbook newsboat % make
c++ -std=c++11 -O2 -ggdb -Iinclude -Istfl -Ifilter -I. -Irss -Werror -Wall -Wextra -Wunreachable-code -DLOCALEDIR=\"/usr/local/share/locale\" -I/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/libxml2 -I/usr/local/Cellar/libstfl/0.24_10/include -I/usr/local/Cellar/json-c/0.13.1/include/json-c -I/usr/include/ncurses  -o src/newsblurapi.o -c src/newsblurapi.cpp

mario.rugiero@mrugiero-macbook newsboat % ls -1 /usr/local/Cellar/json-c/0.13.1/include/json-c
arraylist.h
bits.h
debug.h
json.h
json_c_version.h
json_config.h
json_inttypes.h
json_object.h
json_object_iterator.h
json_pointer.h
json_tokener.h
json_util.h
json_visit.h
linkhash.h
printbuf.h

I started replacing the places where json-c is used to use the implementation shipped in the repository (nlohmann), so we can just get rid of one dependency. Does that sound like a good idea?

It's not a bad one :) There are a couple of twists, though:
1. json-c is used in "remote APIs", for which we don't have tests. Changes have to be tested manually, by registering with the API provider and using Newsboat with it. Are you up for that?

Yes, as long as it's free :)

2. Newsboat is being ported to Rust. Bugfixes, refactoring, and features are definitely welcome in the C++ code, but migrating between C++ libraries doesn't have nearly as much impact — it's all going to be replaced again, anyway. How interested/ready are you in just porting these APIs to Rust? It's a _much_ larger task, but I will break it down into manageable pieces (porting one class at a time) and assist you in figuring out what's going on in the C++ code.

I'm interested, but I'm not ready yet, as my knowledge of Rust is quite shallow. I'm in, though.

I'm going to close this PR (it can't be merged because it breaks Linux, and it isn't even strictly necessary on macOS); thanks for submitting it though!

OK. I'll have Linux again (in a Docker container, sadly) by the time I send anything again, so I'll be able to ship things that work there :)

We can continue the hlohmann/json discussion here, though; I have no better place for it right now.

Good.

Re json-c: my next test would be to create a small file that includes json.h, compile it manually with minimum of options, adding --verbose to see the standard include paths, and then figure out why the compiler can't find the header even though we explicitly gave it a path. The "figure out" part is obviously the hardest one :)
I believe all the services touched by this PR have a free tier, so you should be fine.

I'm interested, but I'm not ready yet, as my knowledge of Rust is quite shallow. I'm in, though.

That's great to hear! Take a look at "good first issue" and "rust-port" tags, they can provide you with something to work on to ease you into the project. For example, https://github.com/newsboat/newsboat/issues/57 is a relatively simple issue that'll require you to update some code both on Rust and C++ sides of things. I expect it to be mostly mechanical, i.e. you can follow the existing code and concentrate on specifics of the languages and their interaction.
I'm also ready to answer questions. Just comment on an issue that you're working on.
Looking forward to your next contribution!


feat(ants): support ANT apis in SDK

Supports ANT apis for the ar-io-ant-process spec defined here https://github.com/ar-io/ar-io-ant-process

:tada: This PR is included in version 1.2.0-alpha.5 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.2.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


All messages are sent to stdout, even errors, which should be in stderr.

Librespot echoes everything into stdout. This could be improved by properly echoing all INFO messages to stdout and all WARN and ERROR messages to stderr.
Currently, when I start librespot with:
# ./librespot > /dev/null

I would expect all info messages redirected to /dev/null, but still see any possible warnings or errors. However, this is not the case.
This also breaks when using systemd and specifying:
StandardOutput=append:/var/log/librespot.stdout.log
StandardError=append:/var/log/librespot.stderr.log

With this configuration, all messages are in the librespot.stdout.log file.

First of all: AFAIK all log messages are printed to stderr, not stdout. Which of us is wrong?
I do not agree: stderr is in a way a misleading name, because it is thought for all kind of status messages. E.g. curl will print the download progress to stderr (if stdout is redirected). Or bash will show the $  on stderr.
stdout is often used for that kind of output that is the purpose of the program, e.g. the list of files in ls, the downloaded file in curl.
And as a matter of fact, librespot uses already stdout for another purpose: If the "pipe" backend is selected, the audio data will be passed to stdout. Considering this, your idea doesn't make so much sense anymore.
If you just want to see errors and warning, use the RUST_LOG environment variable. If you want to log all messages but see only errors, use grep to filter the messages. Another advantage: The order of messages will be preserved if you use a single file.

I stand corrected, you are right and was mistaken with logging levels. Which should work fine.
@coderootme you should use 2>/dev/null syntax.

Yes, guys, I am sorry. Everything goes to stderr. My point still stands, however, but it seems like you don't agree with that idea, so I will close it here.


Screencast link in Readme

@jbarker7 Due to end of flash, can't view the video link shared in Readme. Is there an alternative?
http://screencast.com/t/5I2N4GQgcb4

Would love to see a new version of the video.


Not loading in IE11

I'm using linq-es2-15 2.4.9 and Angular2 2.0.0. Linq works fine in Chrome and Firefox, but it won't even load in IE11. Any idea what the problem might be?
Thanks,
John
From the IE console:
Error: SyntaxError: Expected identifier
at ZoneDelegate.prototype.invoke (http://localhost:54040/node_modules/zone.js/dist/zone.js:190:13)
at Zone.prototype.run (http://localhost:54040/node_modules/zone.js/dist/zone.js:85:17)
at Anonymous function (http://localhost:54040/node_modules/zone.js/dist/zone.js:451:17)
at ZoneDelegate.prototype.invokeTask (http://localhost:54040/node_modules/zone.js/dist/zone.js:223:17)
at Zone.prototype.runTask (http://localhost:54040/node_modules/zone.js/dist/zone.js:125:21)
at drainMicroTaskQueue (http://localhost:54040/node_modules/zone.js/dist/zone.js:357:25)
Evaluating http://localhost:54040/node_modules/linq-es2015/dist/linq.js
Error loading http://localhost:54040/node_modules/linq-es2015/dist/linq.js as "linq-es2015" from http://localhost:54040/app/fc/fc.component.js

IE does not implement EcmaScript-2015 specification and does not provide all the features required by  linq-es2015.
You could use linq-es5 in IE with no code changes. These two packages implement exactly the same API but with two different technologies.


AudioTool source code?

I tried to get Usagi running on Mac, but rake fails immediately because the .NET program AudioTool.exe can't be used. Mono can be used on Mac, so running a simple command line .NET application should be possible, but unfortunately AudioTool.exe does seem to try to use System.Drawing stuff which probably requires Windows:
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.TypeInitializationException: The type initializer for 'System.Windows.Forms.WindowsFormsSynchronizationContext' threw an exception. ---> System.TypeInitializationException: The type initializer for 'System.Windows.Forms.ThemeEngine' threw an exception. ---> System.TypeInitializationException: The type initializer for 'System.Windows.Forms.ThemeWin32Classic' threw an exception. ---> System.TypeInitializationException: The type initializer for 'System.Drawing.KnownColors' threw an exception. ---> System.TypeInitializationException: The type initializer for 'System.Drawing.GDIPlus' threw an exception. ---> System.DllNotFoundException: libgdiplus.dylib
When AudioTool.exe is invoked by rake, it shouldn't run any Windows graphics related code, right? But can't fix the tool without source code...

The aim was to push out the audio tool with 0.4 (currently still focused on 0.3) but I'll bump it up on the priority list and hopefully have it uploaded within the week.
AudioTool.exe is actually the editor for constructing the sound banks so it's no mistake it's using the graphics code, that said it should really be split into two executables. In an ideal world we'd move away from ATF for all of the tools, but that's not immediately practical.
As a word of warning though; Mac support hasn't been a thing since pretty early in Usagi's lifetime.


Collections links lead to "Page not found"

Under the Collections drop down, all of the links lead to 404s - please link to collections.

The header links are supposed to be part of civic platform, which isn't working yet AFAIK. Most of the other projects are not including the header component which is maybe what we should do as well for now.

Assigning to Megan to push to platform team


Update README.md

No description provided.

No description provided.

ISSUE : https://github.com/GoTo-Coders/DS-Algo/issues/25


htslib: 1.15 -> 1.16

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/samtools/htslib/releases.
meta.description for htslib is: "A C library for reading/writing high-throughput sequencing data"
meta.homepage for htslib is: "http://www.htslib.org/"
meta.changelog for htslib is: ""
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.16 with grep in /nix/store/gsyjaap0xyilnmnq30nmgwp9lmn3p87j-htslib-1.16
found 1.16 in filename of file in /nix/store/gsyjaap0xyilnmnq30nmgwp9lmn3p87j-htslib-1.16

Rebuild report (if merged into master) (click to expand)

18 total rebuild path(s)

18 package rebuild(s)

First fifty rebuilds by attrpath
angsd
bcftools
deeptools
delly
htslib
mosdepth
nimPackages.hts-nim
octopus-caller
platypus
python310Packages.HTSeq
python310Packages.cnvkit
python310Packages.pysam
python39Packages.HTSeq
python39Packages.cnvkit
python39Packages.pysam
samtools
tebreak
truvari

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/gsyjaap0xyilnmnq30nmgwp9lmn3p87j-htslib-1.16 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A htslib https://github.com/r-ryantm/nixpkgs/archive/51064f5bfffb1ca5db52326ec91929f241a36b54.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/gsyjaap0xyilnmnq30nmgwp9lmn3p87j-htslib-1.16
ls -la /nix/store/gsyjaap0xyilnmnq30nmgwp9lmn3p87j-htslib-1.16/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package marked as broken and skipped:

truvari

1 package failed to build:

octopus-caller

16 packages built:

angsd
bcftools
deeptools
delly
htslib
mosdepth
nimPackages.hts-nim
platypus
python310Packages.HTSeq
python310Packages.cnvkit
python310Packages.pysam
python39Packages.HTSeq
python39Packages.cnvkit
python39Packages.pysam
samtools
tebreak

Maintainer pings
cc @mimame for testing.

octopus-caller

is already broken on target branch


[Navigation] Add Navigation-Material

New module that allows registering composable bottom sheet destinations with navigation-compose!
This is imported from https://github.com/androidx/androidx/pull/173.
For easier integration with compose-material's ModalBottomSheetLayout, this library provides convenience wrappers and a BottomSheetNavigator to be able to declare and navigate to bottom sheet destinations, similar to bottom sheet dialog destinations in vanilla navigation.
BottomSheetNavigator drives a ModalBottomSheetLayout's sheetContent and state, controlling visibility according to the back stack and composing and disposing destinations that are navigated to or away from. BottomSheetNavigator offers the sheetContent as a composable that should be set as the ModalBottomSheetLayout's sheetContent.

Composable bottom sheet destinations can be added using NavGraphBuilder#bottomSheet
The BottomSheetNavigator needs to be registered with the NavController's navigatorProvider
The main entry point is the ModalBottomSheetLayout composable that accepts a BottomSheetNavigator

This is rebased on jbw0033/snapshot from #574 but I'll rebase it on main.

Hah, wrong repo. Sorry! Professionalism all around :p


Bower components directory does not exist

Fresh install in my windows machine with xampp stack.
When i run gulp, i am geeting the followin error.
Error: Bower components directory does not exist at d:\xampp\htdocs\l aravel5-angular-material-starter\bower_components

I think you forgot to run the Bower install command
Let me know if that fixes it for you

I did bower install and the packages are under www\packages folder.

Do you have a global .bowerrc that changes the default folder to www\packages? There isn't any .bowerrc committed in this repository so it must be something on your end changing the default directory for bower.
Can you check if there's a .bowerrc anywhere?

I don't see the file .bowerrc.
i just removed www\packages the folder and i run again bower install, it store the file under www\packages only.
Then i created new file .bowerrc with contents
{ 	"directory": "bower_components" }
Now works every think.
Thanks

I guess you have a global .bowerrc
Can you check if you have one in your root directory? (I guess it's C:/users/your-username)


Make forced tunneling a deployment configuration setting

Benefit/Result/Outcome
So that forced tunneling is an option at deployment time.
Description
Many people who are connecting a Mission Landing Zone secure network enclave in Azure will want all internet traffic from the enclave to go through a forced tunnel so that it is routed through another set of network devices, either on premises or another Azure device. Therefore, MLZ now implements forced tunneling. However, there are some drawbacks to having forced tunneling turned on by default:

Additional configuration is required after deployment to connect the tunnel routes to whatever destination route is required, e.g. an on-premises security stack.
When MLZ is deployed, networks within MLZ do not have internet access until the above configuration is finished.
Undoing forced tunneling requires redeploying the firewall.

While the forced tunneling configuration is desirable for many people, there will be other scenarios in which not having internet access (without additional configuration) will be the wrong choice. Therefore, we want to provide a configuration option, before deployment, to skip the forced tunneling configuration.
Acceptance Criteria

A deployment configuration setting is added that allows users to decline forced tunneling configuration.
The default deployment will continue to set up forced tunneling.

Consult with @Phydeauxman about registering the client and management subnets required to not do forced tunneling.


Graph Coloring Problem

Aim

To determine all the different ways in which graph can be colored using at most m colors.

Details

Graph represented by its adjacency matrix.
Colors are represented by the integers 1,2,...,m.

Programming language

[ ] C
[x] C++
[ ] Java
[ ] Python

I wish to work on this issue please assign this to me under LGM-SoC'21.

I want to work in this problem in c++ please assign me under LGM-SoC'21

@Saurabh4626  @Amit366 @Ayush7614  Assign me in c under LGMSOC21

Assign me in Python under LGMSOC'21


Build failure when compiling in parallel

This is seen in Debian (stretch, unstable):
make[3]: Entering directory '/«PKGBUILDDIR»/obj-arm-linux-gnueabi'
[  4%] Building Fortran object src/mpi/CMakeFiles/caf_mpi.dir/__/extensions/opencoarrays.F90.o
[  4%] Building Fortran object src/mpi/CMakeFiles/caf_mpi_static.dir/__/extensions/opencoarrays.F90.o
cd /«PKGBUILDDIR»/obj-arm-linux-gnueabi/src/mpi && /usr/bin/mpifort  -DMPI_WORKING_MODULE -DPREFIX_NAME=_gfortran_caf_ -I/usr/lib/arm-linux-gnueabi/openmpi/lib -I/usr/lib/arm-linux-gnueabi/openmpi/include -I/usr/lib/arm-linux-gnueabi/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent/include -I/usr/lib/arm-linux-gnueabi/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent -I/usr/lib/arm-linux-gnueabi/openmpi/include/openmpi -I/«PKGBUILDDIR»/src -I/«PKGBUILDDIR»/obj-arm-linux-gnueabi/mod  -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. -fstack-protector-strong -J../../mod   -c /«PKGBUILDDIR»/src/extensions/opencoarrays.F90 -o CMakeFiles/caf_mpi_static.dir/__/extensions/opencoarrays.F90.o
cd /«PKGBUILDDIR»/obj-arm-linux-gnueabi/src/mpi && /usr/bin/mpifort  -DMPI_WORKING_MODULE -DPREFIX_NAME=_gfortran_caf_ -Dcaf_mpi_EXPORTS -I/usr/lib/arm-linux-gnueabi/openmpi/lib -I/usr/lib/arm-linux-gnueabi/openmpi/include -I/usr/lib/arm-linux-gnueabi/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent/include -I/usr/lib/arm-linux-gnueabi/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent -I/usr/lib/arm-linux-gnueabi/openmpi/include/openmpi -I/«PKGBUILDDIR»/src -I/«PKGBUILDDIR»/obj-arm-linux-gnueabi/mod  -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. -fstack-protector-strong -J../../mod -fPIC   -c /«PKGBUILDDIR»/src/extensions/opencoarrays.F90 -o CMakeFiles/caf_mpi.dir/__/extensions/opencoarrays.F90.o
f951: Fatal Error: Can't rename module file '../../mod/opencoarrays.mod0' to '../../mod/opencoarrays.mod': No such file or directory
compilation terminated.
src/mpi/CMakeFiles/caf_mpi.dir/build.make:113: recipe for target 'src/mpi/CMakeFiles/caf_mpi.dir/__/extensions/opencoarrays.F90.o' failed
make[3]: *** [src/mpi/CMakeFiles/caf_mpi.dir/__/extensions/opencoarrays.F90.o] Error 1
make[3]: Leaving directory '/«PKGBUILDDIR»/obj-arm-linux-gnueabi'
CMakeFiles/Makefile2:178: recipe for target 'src/mpi/CMakeFiles/caf_mpi.dir/all' failed
make[2]: *** [src/mpi/CMakeFiles/caf_mpi.dir/all] Error 2

This appears (randomly?) when make -j2 or -j4 used, but not when -j1. A race condition?
This with openmpi-2.0.2

This appears to be a CMake bug, although I need to confirm this to ensure we're setting up the dependencies correctly. Which version of CMake are you using?

@amckinstry I suspect that your patch to src/mpi/CMakeLists.txt is to blame for this race condition.  CMake should be able to handle building a static and shared Fortran library in parallel that uses module files. Due to the way CMake handle's mod files, building two targets producing the same mod file appears to cause a race condition. I suspect that if we serialize the build of the shared and static libs that this problem will go away.
Knowing which version of CMake you're using would still be helpful so I can test/confirm locally and then submit a bug report to CMake.

3.7.2
It might also be triggered by my patch:
https://github.com/sourceryinstitute/OpenCoarrays/issues/365#issuecomment-296979575
but I can't tell why.

It might also be triggered by my patch:
#365 (comment)
but I can't tell why.

Yes, it is triggered by your patch. It's because we're compiling and adding the coarrays extension module with the library... If we were to make that it's own target this would go away... I'll look into this.

Moving patch issue from #365 here because implementing the patch goes hand in hand with fixing the parallel build issue...
Index: ./src/mpi/CMakeLists.txt
===================================================================
--- ./src/mpi/CMakeLists.txt
+++ ./src/mpi/CMakeLists.txt
@@ -36,7 +36,8 @@ if (MPI_Fortran_MODULE_COMPILES)
   set(MPI_CAF_FORTRAN_FILES ../extensions/opencoarrays.F90)
 endif()

-add_library(caf_mpi mpi_caf.c ../common/caf_auxiliary.c ${MPI_CAF_FORTRAN_FILES})
+add_library(caf_mpi SHARED mpi_caf.c ../common/caf_auxiliary.c ${MPI_CAF_FORTRAN_FILES})
+add_library(caf_mpi_static STATIC  mpi_caf.c ../common/caf_auxiliary.c ${MPI_CAF_FORTRAN_FILES})
 target_link_libraries(caf_mpi PRIVATE ${MPI_C_LIBRARIES} ${MPI_Fortran_LIBRARIES})

 set_target_properties ( caf_mpi
@@ -53,9 +54,14 @@ endif()
 include_directories(${CMAKE_BINARY_DIR}/mod)

 install(TARGETS caf_mpi EXPORT OpenCoarraysTargets
+  DESTINATION "${CMAKE_INSTALL_LIBDIR}"
+  LIBRARY DESTINATION "${CMAKE_INSTALL_LIBDIR}"
+)
+install(TARGETS caf_mpi_static EXPORT OpenCoarraysTargets
   ARCHIVE DESTINATION "${CMAKE_INSTALL_LIBDIR}"
   LIBRARY DESTINATION "${CMAKE_INSTALL_LIBDIR}"
 )
+set_target_properties(caf_mpi PROPERTIES SOVERSION 1 SONAME "libcaf_mpi.so.${OpenCoarraysVersion}")

 # Install modules to standard include dir, but namespace them with compiler/version
 set (mod_install "OpenCoarrays/${CMAKE_Fortran_COMPILER_ID}/${CMAKE_Fortran_COMPILER_VERSION}")

dylib-targets.patch.txt

Hello. I come from completely different Fortran project. We also have hit (I believe) the same race condition-during-compilation bug. Unlike you, we don't build shared libraries, though. Error is non-deterministic and hard to reliably reproduce. I'd like to file a bug report against (CMake? gfortran?), but I can't really nail it.
I understand from this topic that you also didn't find the root cause of the bug. The bug went gone accidentally with the fix for another issue, #365. Am I correct?

@adamryczkowski

I understand from this topic that you also didn't find the root cause of the bug. The bug went gone accidentally with the fix for another issue, #365. Am I correct?

No, I know the root cause of this behavior. It is due to CMake's handling of .mod files. The "bug" arises when one or more Fortran source files containing modules is used in the compilation of multiple targets. CMake manipulates the .mod file output by the compiler, so make (or what ever "generator" you're using) might launch parallel compilation tasks for each target that has the Fortran source with the module, but then one of those jobs ends up moving/renaming etc. the output .mod file before/while the other one needs it.
CMake/Kitware is aware of this behavior, and it is intentional (not a bug). In fact, under some circumstances the same problem may be encountered using make directly. The CMake way to handle this is to put the Fortran source file(s) with the module into their own library. If you don't want to explicitly build an additional library you can create an "object library" which is a sort of alias to a collection of object files. You can't install or export this "object library" target, but you CAN pass it, via a generator expression, in the sources list to add_library and add_executable:
add_library(my_obj_lib OBJECT ftn_mod1.f90 ftn_mod2.f90 ftn_mod3.f90)
add_library(lib_using_ftn_mods STATIC $<TARGET_OBJECTS:my_obj_lib> lib_src.f90)
add_executable(exe_using_ftn_mods $<TARGET_OBJECTS:my_obj_lib> a.out)
add_library(other_ftn_lib STATIC $<TARGET_OBJECTS:my_obj_lib> other_lib_src.f90)

Now CMake compiles object files (and corresponding .mod files) into the target my_obj_lib first and then is able to safely use them across multiple targets compiled in parallel.
Hope this helps!

Fixed in #440

I am seeing a very similar race condition, but was thinking this problem was with the Intel Fortran compiler.
In my case I compile the same source directory twice in two different build directories.   Each creates a different library and the .mod files are copied to different "include" subdirectories.   (One build is single precision and one is double precision, but I don't think that is relevant here.)    I was thinking that the Intel compiler is somehow using a shared resource because the source file is the same for both builds and I get errors like "empty" stream.   CMake uses Intel's "-module" flag to move the .module, and I think this is correlated.
OTOH, I've not been able to make a non-cmake reproducer for this behavior yet.   I'll try some more experiments tomorrow.  Unfortunately, I only hit the error about 50% of my builds and it takes about 2 minutes to get to the race after a make clean.

oh boy, that doesn't sound fun to debug...
I'm not sure I completely understand though... are the builds in the two separate directories (single and double precision) happening concurrently? Are they triggered manually or by a script/super-build?
My thoughts on the matter are:

It's possible that the connection with two build directories could be a red herring, if a parallel build is being attempted in each; there could be source files defining modules used to build multiple targets that don't always get serialized
If the two build directories are built at the same time, it's possible that the compilation order may be non-deterministic if the build system is trying to compile more files than there are available threads. If the collision is happening across the two build directories, somehow, then I would suspect Intel is to blame somehow, but this strikes me as unlikely.

I would make sure that all source files containing module definitions appear in one and only one add_library or add_executable CMake statement. If you need to specify a source file defining a module in multiple targets, your best bet is to move to using the "object" library w/ generator expression technique. Another idea is to serialize targets referencing the same source file defining the module, but this will slow down the build in an unnecessary fashion.
I've never been one to shy away from accusing Intel of having Fortran compiler bugs, but the "empty stream" error you're getting really sounds to me like a CMake parallel build issue. This CMake behavior is pretty obnoxious, IMO, whether they consider it a "bug" or not, and I'd be willing to share my opinions on the matter with them if you file a new issue.

Just to elaborate more, the "empty stream" error sounds like one instance/thread of ifort is opening a freshly generated .mod file to compile or link a target, but then another target has been told to recompile with the source file creating that .mod file and is stepping on it after it's been opened by the first compiler thread/instance for reading.

The directory in question is built in two separate directories.   This is using cmake's optional argument for add_subdirectory.      Until recently, only one of the directories was actually being built because only one was a dependency for my targets.   Having resolved a long standing issue with another target, both directories are now dependencies for my ultimate target and  so now both are being built - apparently simultaneously.
In theory, there is no need to serialize anything.   If the compiler only creates files in the different working directories, it should be fine that two threads are reading from the same file simultaneously.
I've had a number of issues where Intel is "overly" clever about finding .mod files in directories that are not part of the build, so I'm perhaps predisposed to be suspicious here.    I have a project where I can do a conventional GNUmake build in the source tree or a CMake build in a build tree.  I've spent hours tracking down a problem that eventually turned out to be that Intel was first looking in the same directory as the source file for .mod files rather than the working directory.    (No "-I" was pointing to the source directory.)    May have been tied to a particular version of Intel, but I'm now careful to either clone or to do make clean if I need to check the GNUmake build.

Regarding your "empty stream" comment.   Each invocation of the compiler should be creating a different .mod file.  Either in a different build directory as explained above, or due to the use of CMake's module move option which specifies a different target directory for each precision.
Hence why I think Intel is doing something unnecessary (like a tmp file based upon the source file name) but possibly not technically a bug.

And of course, typing "make" a second time always appears to work, so it is more annoying than problematic.   (May undermine my attempt to cell cmake to the org though.)

Cmake does some tricky stamp creation, modfile relocation etc. too. Without
seeing what's going on myself it's hard to know for sure what's up.
On Tue, Sep 5, 2017 at 5:13 PM tclune<EMAIL_ADDRESS>wrote:

Regarding your "empty stream" comment. Each invocation of the compiler
should be creating a different .mod file. Either in a different build
directory as explained above, or due to the use of CMake's module move
option which specifies a different target directory for each precision.
Hence why I think Intel is doing something unnecessary (like a tmp file
based upon the source file name) but possibly not technically a bug.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/sourceryinstitute/OpenCoarrays/issues/366#issuecomment-327305324,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAREPIO8xZDULIap08PcBhlDTe2xGYtBks5sfbmJgaJpZM4NHUFE
.

I am now encountering this issue (or similar) with gfortran on Darwin.    It happens almost immediately when I start to build (but of course not with VERBOSE=1 or with serial).
[  0%] Building Fortran object GMAO_Shared/MAPL_cfio_r4/CMakeFiles/MAPL_cfio_r4.dir/ESMF_CFIOBaseMod.f.o
[  0%] Building Fortran object GMAO_Shared/MAPL_pFUnit/CMakeFiles/MAPL_pFUnit.dir/ESMF_TestParameter.F90.o
[  0%] Building Fortran object GMAO_Shared/GMAO_pFIO/CMakeFiles/GMAO_pFIO.dir/pFIO_Constants.F90.o
[  0%] Building Fortran object GMAO_Shared/GMAO_pFIO/CMakeFiles/GMAO_pFIO.dir/pFIO_Constants.F90.o
f951: Fatal Error: Can't rename module file '../../include/GMAO_pFIO/pfio_constantsmod.mod0' to '../../include/GMAO_pFIO/pfio_constantsmod.mod': No such file or directory

Notice that apparently two different threads are trying to build the same file.    I've double checked that this file is only listed once in a single target for the build.    Further it is not always this file or even this target that is effected.      Another potential data point, is that this is currently happening when I am building a top level target that includes EXCLUDE_FROM_ALL targets (building tests).
Hmmmm.
This is now with cmake 3.11.4

After a bit more investigating, I understand what was causing my current issue.    It could easily be argued that it is not a CMake bug.
I had used ALLOW_DUPLICATE_CUSTOM_TARGETS for my tests and this was triggering simultaneous builds.      I had already planned my next bit of work to be eliminating that cmake antipattern before I raised the issue above.   Having done that now, the build seems fine again.

Happy to hear you've sorted it out. This is always a source of confusion. My rule of thumb is never, ever allow a source file providing a .mod module file to be built by more than one thread. In practice this usually means the use of object libraries.

I completely agree on the principle, but I had no idea that cmake was doing this to me via the indirect route.   The compilation errors were happening in a layer that was quite clean.   It was 2 different “test” targets with the same name that both wanted the same source file to be built …
On Jul 23, 2018, at 1:39 PM, zbeekman <notifications<EMAIL_ADDRESS>wrote:
Happy to hear you've sorted it out. This is always a source of confusion. My rule of thumb is never, ever allow a source file providing a .mod module file to be built by more than one thread. In practice this usually means the use of object libraries.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/sourceryinstitute/OpenCoarrays/issues/366#issuecomment-407140856, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AF7_4C3wKaj-3oa6YWAFImu-IL94c1sHks5uJgpngaJpZM4NHUFE.

Yes, I agree that it is very unintuitive.
On Mon, Jul 23, 2018 at 1:45 PM Tom Clune<EMAIL_ADDRESS>wrote:

I completely agree on the principle, but I had no idea that cmake was
doing this to me via the indirect route. The compilation errors were
happening in a layer that was quite clean. It was 2 different “test”
targets with the same name that both wanted the same source file to be
built …
On Jul 23, 2018, at 1:39 PM, zbeekman<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
Happy to hear you've sorted it out. This is always a source of confusion.
My rule of thumb is never, ever allow a source file providing a .mod module
file to be built by more than one thread. In practice this usually means
the use of object libraries.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<
https://github.com/sourceryinstitute/OpenCoarrays/issues/366#issuecomment-407140856>,
or mute the thread<
https://github.com/notifications/unsubscribe-auth/AF7_4C3wKaj-3oa6YWAFImu-IL94c1sHks5uJgpngaJpZM4NHUFE>.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/sourceryinstitute/OpenCoarrays/issues/366#issuecomment-407142449,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAREPPwg1kv8ewEGqCcltzhMPxukyQlBks5uJgupgaJpZM4NHUFE
.


Upgrade task should warn about expected portlet_header dynamic-include extension point

In updated themes, we are adding a dynamic include extension point so applications can contribute content to a portlet header:
<@liferay_util["buffer"] var="portlet_header">
	<@liferay_util["dynamic-include"] key="portlet_header_${portlet_display_root_portlet_id}" />
</@>

...

<#if portlet_header?has_content>

			${portlet_header}

</#if>

We should include this in the upgrade tool for a better upgrade process

Tangential question: why are you not using the extended Freemarker assign directive (<#assign> … </#assign>) instead of<EMAIL_ADDRESS>/>?

That's a good point, @yuchi! I'll look into that... not sure if we have a specific reason, so probably we might be able to defer to Freemarker syntax as you suggest!


_key parameter needs to be enforced to prevent genieacs-cwmp for continuousely fail

Genieacs-gui permits creating a object element with the  "_key" not set.
This will have the effect that genieacs-cwmp will fail continuously when
trying to access the obj["_keys"] parameter in genieacs/lib/cache.js and
genieacs/lib/local-cache.js. The Gui should check that _key is set before
adding it to the DB.

This is better fixed in core. If no keys are defined then it should assume all parameters as keys as this was the behavior in v1.0. Just fixed it here zaidka/genieacs@4d255acfc6a0294760e8fb6a6d2c918cd8514f97.
FYI, objects are kept for compatibility only, so you should probably use scripts for all your device configuration.


CAN Packet update

Description

defective CAN Packet implementation
bug fix for casual CAN Packets

How Has This Been Tested?

unit tests
integrations tests (especially for previously found defect)

Process

I know the process and did my best to follow it

Pull Request Test Coverage Report for Build 839

160 of 160 (100.0%)  changed or added relevant lines in 12 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 834:
0.0%

Covered Lines:
1709

Relevant Lines:
1709

💛  - Coveralls


chore: moved core app & e2e tests as monorepo prep

Part of VAX-631

@icehaunter you might want to rebase, as the recent bump of the protocol version introduces the conflict


TypeScript code completion

Hi Marijn,
It is rather feature request than issue, but I think a lot of people are interested in the answer.
As far as I know TernJS could currently only analyse JavaScript code and could not "understand" TypeScript, right?
Is there a plan for TernJS to analyse TypeScript and support code completion in TypeScript files in near future?
As its community grows every day it will be awesome to have it built in.
Thank you!

Hi all. I know this is an old issue, but I was also playing with TypeScript API for a long time, and have to add that they finally stabilized and improved it a lot starting from TypeScript 1.5. So it should be possible to fix this issue as soon as someone willing to spend a bit of time to adapt to the new (non-breaking) API.

If anyone wants to collaborate, I've migrated from_ts and related code to dannysu/dts2tern. It's been updated with the new way of accessing the TypeScript parser and AST.
Currently running ./bin/from_ts node_modules/definitely-typed/exit/exit.d.ts will produce:
{
  "exit": {
    "exit": "fn(code: number)"
  },
  "!name": "exit.d.ts"
}

It's a work-in-progress. I have no idea if the produced tern file is correct or not. With the time I spent on it today so far, I only got to it kinda running.

That's great! Once it's more mature I'll gladly add a link from the Tern documentation.


Remove needless tokio::spawn's

tokio::spawn is extremely useful for cases when you know the amount of work you are doing is expensive, however it is really expensive to call. We should avoid using tokio::spawn except for areas we know it will make meaningful improvements.
Rationale

Giving one user (grpc stream) the ability to spawn thousands of spawns causing other users to be punished is not a great idea. By not using spawn, we are limiting each user / grpc stream to maxing out one CPU at a time (except under specific cases where it's useful).
We can control grpc stream limits higher up in the stack. For example, if we want to allow each stream to use up to N number of spawns / cores, we can easily control that higher up in the stack giving nearly all the benefits of parallelizing with tokio::spawn, but make it fair for other users.
Gives the compiler the ability to optimize better. tokio::spawn always is a Box<dyn Future>, which cannot be optimized by the compiler. By avoiding it we give the compiler more information about our intentions.
Better chance our data will be immediately available. Because we are not forcing a CPU core context switch, we have a much greater chance our data is still in the hot path and the CPU will have the ability to run instructions in parallel (tokio::spawn forces a CPU sync point, since it might swap to another core).
tokio::spawn is just an expensive operation in general.

Most of the important ones have been removed. I'm happy to close this.


The file CMakeTests.txt is no longer included if ENABLE_TESTING is off

This is a quick solution for uber/h3-py#239, but does not address the underlying issue of the file not being found. I do think this is useful because it allows us to unindent the CMakeTests.txt file.
Also fixed a missing CHANGELOG item for #603

Coverage remained the same at 98.66% when pulling a9f27f91490423a2595d18678627d935f4832289 on isaacbrodsky:tests-dont-open-cmaketests into 294c20ed7d447122d5ab37260896d4ef7579ebfb on uber:master.


End-to-end testing of ECS/ECR

Pulling from ECR is tested and confirmed to be operational. ECS end-to-end testing is still necessary, but this will need to be conducted by the Streamline engineers.


Colin's actioncable lightning talk post

Mikaila's post isn't finished yet, forgot it was part of this branch.


perform multiple calls in a single http request

It would be nice to be able to provide a way to chain multiple method calls together into a single request when possible.
When making requests to Fastmail's API directly, you can do something like
[[ "Email/query",{
  "accountId": "ue150411c",
  "filter": {
    "inMailbox": "fb666a55"
  },
  "sort": [{
    "isAscending": false,
    "property": "receivedAt"
  }],
  "collapseThreads": true,
  "position": 0,
  "limit": 30,
  "calculateTotal": true
}, "0" ],
[ "Email/get", {
  "accountId": "ue150411c",
  "#ids": {
    "resultOf": "0",
    "name": "Email/query",
    "path": "/ids"
  },
  "properties": [
    "threadId"
  ]
}, "1" ]]

(source)
to both reduce the number of required HTTP requests and to be able to pass values between method calls.

This should be possible now that a requests.Request takes a slice of Call interface values, but still needs to be validated.

Still working out how to refer to the output of a prior method in the slice of Calls. One idea is to pass a slice of some kind of Reference struct to a Call that would define what field referred to a prior call.

A first step toward implementing a reference architecture as described in the prior comment has been made with commit d1ada3cf079c2527a41c34f0b50883ffc346a525 - this implements the ability to retrieve multiple emails in a single call + request, which will be needed to validate references. Next step will be to implement the Reference struct, then attempt chaining multiple calls of different types and referring to values from an earlier call.

It turns out the ability to utilize references between a given request's calls is very limited. I tried many approaches, and the only thing that seems to work is in the very specific case when you query for a bunch of IDs and then you want to get data about all of them. You cannot, for example, make a set request and then try to get the created object because the ID that is returned by the set request is not usable in the get request, as get requires a list of IDs, not 1 single ID.
Conclusion: Implementing anything specific for referring to data between calls is not worth it. It can still be done by modifying the body for a Call to use a reference as described in the spec, but users should be warned it is highly error prone, and that it is usually better to just make another request to get the data you need.
I am working on a test that validates multiple calls can be made in a request, but I will not be pursuing the reference architecture.

Multiple requests test implemented with commit 27928d54ee393f04c8576ea58e1f1fac3e089735


Allow separator without trim

Currently, this action with attribute separator is only working with a single character (eg: :)...
Request: allow separator to use with :  - or however anyone choose in that string...

Apologies for the delay, @huantbui would you be able to provide an example of what is not working and the expected outcome?


feat(Makefile): run unit tests for only modified packages

Two new Makefile targets:
1. unit-test-patch

    Does a little git magic to figure out from the files that've changed
from upstream which go packages have had changes, and then runs only
those unit tests. This is convenient when running the tests
frequently, as in red-green development or for careful refactoring.

2. coverage-view-patch

    Like unit-test-patch, but generates and opens in your browser a
coverage report for your changes. This is different from "make
coverage-view" in that it only generates reports for files in the
packages that are modified from upstream. What that means is that you
have far fewer files to sort through to find useful test coverage
information in the report, as it's likely to include only a handful of
files, as opposed to every source file in the repo.

/approve

This is really awesome, great utility for a quick sanity check. I wonder if we might find somewhere to note (preferably as close to the target as possible) the trade-offs. Namely the fact that dependencies of the changed code could be fail if behavioral expectations have been tweaked. In the same spot, we might want to establish the exepcted use also that you detailed in the description.

This is convenient when running the tests frequently, as in red-green development or for careful refactoring.

This is really awesome, great utility for a quick sanity check. I wonder if we might find somewhere to note (preferably as close to the target as possible) the trade-offs. Namely the fact that dependencies of the changed code could have their tests fail if behavioral expectations have been tweaked.
Ideally that won't happen if unit tests on the changed code are sufficient, but we live in the real world. Hopefully a note will help make clear this is an additional tool to make test, not a replacement.
In the same spot, we might want to establish the exepcted use also that you detailed in the description.

This is convenient when running the tests frequently, as in red-green development or for careful refactoring.

Great thoughts, I'll add something.


.NET Core 2.1.0 RC 1

.NET Core 2.1.0 RC1
Blog post
Release Notes
Please report any issues you find with 2.1 RC 1, either responding to this issue, creating a new issue or creating a new issue in one of the following repos:

dotnet/cli - for CLI tools and questions
dotnet/corefx - for API issues and questions
dotnet/coreclr - for runtime issues
dotnet/core-setup - for installer issues
nuget/home - for NuGet questions and issues

Is there a soft guestimate on RTW date?

Finally found it after making some assumptions based on file names and other download locations...
https://download.microsoft.com/download/B/1/9/B19A2F87-F00F-420C-B4B9-A0BA4403F754/dotnet-sdk-2.1.300-rc1-008673-linux-arm.tar.gz
Why make it so hard to find this stuff?

Sorry @RoySalisbury, we'll get it worked into the download pages.

@RoySalisbury there should be one without the build number in it. @leecow sound like he has it under control :)

Still having fun trying to find this one:
aspnetcore-runtime-2.1.0-rc1-final-linux-arm.tar.gz
Since its not part of the SDK install I figure I need that installed separately.

It should be in the SDK tar.gz and there should be an ASP.NET Core Runtime for ARM32 tar.gz @livarcocc @DamianEdwards @muratg . Can you confirm whether the ASP.NET runtime made it in or if thats something we need to address for RTM?

The only thing the SDK installed (for ARM) was
/opt/dotnet/shared/Microsoft.NETCore.App/2.1.0-rc1
and
/opt/dotnet/sdk/2.1.300-rc1-008673
But the hash listing here shows it exists as a separate file (my guess is it is not part of the SDK or runtime for ARM).
https://dotnetcli.blob.core.windows.net/dotnet/checksums/2.1-RC1-Runtime-SHA.txt

That may be true. It should have its own runtime tar.gz and should have been in the sdk. I opened this to track it: https://github.com/dotnet/cli/issues/9218

I have been working with dotnet core 2.1 preview 2 and earlier without issues. Installing the dotnet core 2.1 rc-1 SDK causes my webapi projects that are targeting 4.6.1 framework to fail to load.
It fails in the Startup at ConfigureServices when calling services.AddMvcCore().
The error message is: "the given key was not present in the dictionary"
It seems to error out in the stack trace at: "DefaultAssemblyPartDiscoveryProvider"
Uninstalling the 2.1 SDK makes everything work again, so it's definitely the issue.
Any ideas?

Never used the global.json and the MS docs are still referencing 1.0 preview. What is the current reference for 2.1 SDK that should be in the global.json. Is it: 2.1.300-rc1-008673
There should be a list somewhere with all the numbers - suggestion.

@laultman - 2.1.300-rc1-00873 and https://github.com/dotnet/core/blob/master/release-notes/releases.json is the 'canonical' release version list.

@leecow Thanks, great. I had the correct version but had no way to know. On another though, VS 2017 15.7.1 Stills spits out this statement: You are working with a preview version of the .NET Core SDK. You can define the SDK version via a global.
I found a thread where they were talking about how to stop or hide these messages. I guess that has not been done. Thanks again for the info!

Closing this now as .NET Core 2.1 has released.


test(note): add test cases for difference

Adds missing notes_test.main() call from #54.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.9%) to 93.75%

Totals

Change from base Build<PHONE_NUMBER>:
0.9%

Covered Lines:
300

Relevant Lines:
320

💛  - Coveralls


Test Smell: it is not a good practice to use the loop in the test

Hi!
We notice that you use the loop structure in your test cases.
For example, shouldDemonstrateCopiesAreEqual() in PerpetualCacheTest.java

However, using the loop in test cases is not a good test practice.
We analyzed the relevant Stack Overflow posts and summarized four potential negatives it brings:

Loops make the test case more complex
In most cases a loop can be replaced with a data driven test which is more readable.
Loops break assert-for-one-thing thumb rule. I don't mean a single assert statement.
When a test fails, knowing the reason is more complicated.

Solution:
To avoid using the loop in the test, JUnit provides an annotation (i.e., @ParameteredTest), which can enable a test case to run multiple times with different parameters.
We provide a usage example here:

Besides, when you set numbers in the annotation, you should try to set edge case numbers to reduce the running times.
In your example, the variable ''i in (0, 1000)'', so you can set edge case numbers as 0, 1, 999, 1000.
To ensure the correctness of your test case, you can randomly set 10 - 20 random numbers in every 100 numbers.

Thanks. We're aware.


Block comments unfold when typing outside the region

VSCode Version: 1.49.1
OS Version: Windows_NT x64 10.0.19041

Steps to Reproduce:

Type one or more block comments in a .js file
Fold any or all comments
Type anything outside the blocks and they will all unfold.

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

I can't reproduce. Can you add a small code sample with steps? What do you type?


xml.etree.ElementTree.ParseError: mismatched tag

Hello,
I am having an issue with an update_connection push. This code works on our 10.5 AWS based server, but not our 2018.1 AWS based server. It runs through the GET commands just fine, but errors when it tries to update the connection. Thanks in advance for any help.
tableau_auth = TSC.TableauAuth('username', 'pw',site_id='mysite') # , site_id='prod'

search_string = 'servername'  # use pipe '|USDAL...' for additional search criteria
search_string_regex = search_string.replace('.','\.') # replace periods with escape character
replace_string = '<IP_ADDRESS>9'  # use if server name/address is changing
overwrite_credentials = True    # set to false to use existing credentials
replace_username = sys.argv[1] # us if
replace_pw = sys.argv[2]

request_options = TSC.RequestOptions(pagesize=1000)

server = TSC.Server('https://www.myserver.com') # tableau server

server.version = '3.0'

#Update published data sources

y = 0

with server.auth.sign_in(tableau_auth):
    all_workbooks, pagination_item = server.workbooks.get(req_options=request_options)
    # print(len(all_workbooks))
    for wb in all_workbooks:
        server.workbooks.populate_connections(wb)
        for item, conn in enumerate(wb.connections):  # make sure to iterate through all connections in the workbook
            if wb.connections[item].connection_type != 'sqlproxy':  # sqlproxy indicates published datasource
                if re.search(search_string_regex, wb.connections[item].server_address, re.IGNORECASE):
                    connection = wb.connections[item]
                    connection.server_address = replace_string
                    if overwrite_credentials:
                        connection.embed_password = True
                        connection.username = replace_username
                        connection.password = replace_pw
                    server.workbooks.update_connection(wb, connection) # this is where it breaks
                    y = y + 1

ERROR:
Traceback (most recent call last):
File "C:/Users/310209207/OneDrive - Philips/PycharmProjects/Master/Tableau_DC_Changes_AWS.py", line 50, in
server.workbooks.update_connection(wb, connection)
File "C:\Python\lib\site-packages\tableauserverclient\server\endpoint\endpoint.py", line 114, in wrapper
return func(self, *args, **kwargs)
File "C:\Python\lib\site-packages\tableauserverclient\server\endpoint\workbooks_endpoint.py", line 100, in update_connection
server_response = self.put_request(url, update_req)
File "C:\Python\lib\site-packages\tableauserverclient\server\endpoint\endpoint.py", line 83, in put_request
content_type=content_type)
File "C:\Python\lib\site-packages\tableauserverclient\server\endpoint\endpoint.py", line 54, in _make_request
self._check_status(server_response)
File "C:\Python\lib\site-packages\tableauserverclient\server\endpoint\endpoint.py", line 66, in _check_status
raise ServerResponseError.from_response(server_response.content, self.parent_srv.namespace)
File "C:\Python\lib\site-packages\tableauserverclient\server\endpoint\exceptions.py", line 17, in from_response
parsed_response = ET.fromstring(resp)
File "C:\Python\lib\xml\etree\ElementTree.py", line 1315, in XML
parser.feed(text)
xml.etree.ElementTree.ParseError: mismatched tag: line 7, column 2

Here are debug results for the PUT...
DEBUG:urllib3.connectionpool:https://www.ourserver.com:443 "PUT /api/3.0/sites/20399901-69cb-42ae-93a5-fad4d5fb2f89/workbooks/fda742af-ac47-4255-8abe-52e327a4eea1/connections/236ed7d2-4c52-41d7-9dfd-da9bee5af9d9 HTTP/1.1" 501 495
DEBUG:tableau.endpoint:[Truncated File Contents]
DEBUG:urllib3.connectionpool:Resetting dropped connection: www.ourserver.com
DEBUG:urllib3.connectionpool:Starting new HTTPS connection (2): www.ourserver.com:443
DEBUG:urllib3.connectionpool:https://www.ourserver.com:443 "POST /api/3.0/auth/signout HTTP/1.1" 204 0
DEBUG:tableau.endpoint:[Truncated File Contents]
INFO:tableau.endpoint.auth:Signed out
Traceback (most recent call last):
File "C:/Users/Tableau_DC_Changes_AWS.py", line 54, in
server.workbooks.update_connection(wb, connection)
File "C:\Python\lib\site-packages\tableauserverclient\server\endpoint\endpoint.py", line 114, in wrapper
return func(self, *args, **kwargs)
File "C:\Python\lib\site-packages\tableauserverclient\server\endpoint\workbooks_endpoint.py", line 100, in update_connection
server_response = self.put_request(url, update_req)
File "C:\Python\lib\site-packages\tableauserverclient\server\endpoint\endpoint.py", line 83, in put_request
content_type=content_type)
File "C:\Python\lib\site-packages\tableauserverclient\server\endpoint\endpoint.py", line 54, in _make_request
self._check_status(server_response)
File "C:\Python\lib\site-packages\tableauserverclient\server\endpoint\endpoint.py", line 66, in _check_status
raise ServerResponseError.from_response(server_response.content, self.parent_srv.namespace)
File "C:\Python\lib\site-packages\tableauserverclient\server\endpoint\exceptions.py", line 17, in from_response
parsed_response = ET.fromstring(resp)
File "C:\Python\lib\xml\etree\ElementTree.py", line 1315, in XML
parser.feed(text)
xml.etree.ElementTree.ParseError: mismatched tag: line 7, column 2

@RussTheAerialist- Thanks for the quick reply- let me know if you have any ideas from my logs. We had a server migration this past weekend and are going one by one to update the connections- really hoping I can get this working ASAP. Again- this works on our 10.5 server perfectly. Thanks in advance.

Closing this issue as @schefs26 last comment.


Fix build discovery

This will now do build discovery as part of DependencyBuild, rather than doing it multiple times per build as part of the artifact discovery process.
It also fixes a potential issue were different artifacts could have different build configs for the same build, the build info has now been moved into its own directory structure that is mapped to a repo rather than an artifact.

/approve

/lgtm

/retest


Fix compilation error when compiling with GHC 9.0

GHC 9.0 requires generated typeclass instances to be generated before they are used.

This is a reasonably straight-forward change, I think. I'll leave it here for a couple of days for folks to raise concerns, otherwise I'll merge and do a release!

Released as <IP_ADDRESS>!
Will remove it from the list of broken packages in stackage in an hour or so.


[flow] Fixes

Fix the examples and the demos that were no longer compatible with a flow less environment.

[x] PR has tests / docs demo, and is linted.
[x] Commit and PR titles begin with [ComponentName], and are in imperative form: "[Component] Fix leaky abstraction".
[x] Description explains the issue / use-case resolved, and auto-closes the related issue(s) (http://tr.im/vFqem).

I yanked weak out of demos in #7883, are you adding it back?

I'm adding it back where we can.


Issue: Map on main page block features

Hello, I have been using PiGalley with and iPhone and iPad (I do not test with Android devices), and it seems that map feature in main page disallow using the app, I mean, pictures can't be opened, language can't be changed, menu can't be opened. On the other hand, if Map feature is disabled, the app works properly.
I could probably z-index issue of the map ? I don't know, If I get more info I will added to this issue.
Thanks for the app and your support.

Thanks for the report.
this might be related to this: #206 and maybe this #155 ?
I'll try to look into it, but any help, contribution is welcome.
The main issue is that I do not actively use any apple product, so I do not see these issues.

I took a look on an older Ipad (Ipad Air, 12.4.4) and it kinda worked. I had to double tap on the photos to show up in the big preview (first only only brought up the black info bar). The buttons does not work in the preview, but you can navigate with swipes.
Can you provide more details about your issue?

Yes of course. On that pages where the map icon is showed, the actions like openning the menu (upper right corner), open photo preview and even changing the folder are not working. It is like there is a handler of click event and a stopPropagation, because on HTML is selected (the link is underscored) but not doing what is supposed that must do.

This is a duplicate of #155. Lets continue it there.


Specify Node.js 6.x in install instructions

To force compatibility, devs should install Node.js v 6.x (6.9.5 latest).

thanks

so you closed this with no comment as to why it wasn't necessary. I'm just trying to save potential new contributors a headache when they're getting setup for the first time. If the patch isn't high enough quality, I can change it.
Maybe at least mention that we're currently limited to Node 6.x due to package version restrictions?

Sorry!
I commented "thanks" but hint close instead of merge...

now it should be ok!

oops! thanks, balbuze! 😀


Add *.png binary to gitattributes

core.autocrlf can do some really annoying stupid stuff otherwise, leaving local png files in a permanently modified state and making updating with tpm impossible

Thanks.


DL not normalized

Firefox / Gecko does not add margin to DL element if it is inside a list. This means there is a rendering difference between Firefox and other browsers.
Compare rendering of http://codepen.io/Merri/pen/zchxA

@battaglr, this would be one to look into, time permitting.

@jonathantneal, I'll take a look!

I’m not seeing any differences in Chrome 30/49, Firefox 30/45, IE8-11, Edge, or Safari 6.2-9, Android
http://s.codepen.io/jonneal/debug/dd0c888cb9486acd7f0468aaed59d297


authentication problem

I tried to call the wunderlist api through your code with my credentials and I got this error:
Fatal error: Uncaught exception 'JeroenDesloovere\Wunderlist\WunderlistException' with message 'Could not Authenticate.' in /home/hederhu/domains/heder.hu/public_html/w/src/Wunderlist.php:86 Stack trace: #0 /home/hederhu/domains/heder.hu/public_html/w/src/Wunderlist.php(63): JeroenDesloovere\Wunderlist\Wunderlist->authenticate() #1 /home/hederhu/domains/heder.hu/public_html/w/examples/example.php(20<EMAIL_ADDRESS>'mypass') #2 {main} thrown in /home/hederhu/domains/heder.hu/public_html/w/src/Wunderlist.php on line 86
It seems to me, that I don’t have the right authority even to log in.
I have a basic free accouint on Wunderlist.
Do I neet to get an authority key from wunderlist?
Or I do wrong something else?
Thank's for your time!!:)
Zoltán
ps.: For testing purposes I changed my password to mypass.
There is really nothing in my workspace yet:)

Hi, I'm working on an updated class that connects to Wunderlist v3 by using OAUTH.


Error 0x80073D02 when calling DeploymentManager::Initialize()

Describe the bug
We are seeing many of our app users receiving error 0x80073D02 (aka ERROR_PACKAGES_IN_USE) from DeploymentManager::Initialize() on both Windows 10 and 11.
From our analytics it seems that the error occurs intermittently on affected machines, i.e. initialization sometimes succeeds, but many times it doesn’t.
Steps to reproduce the bug
Launch packaged app using Windows App SDK on affected machines.
Expected behavior
Initialization of the Windows App SDK succeeds (i.e. DeploymentManager::Initialize() returns no error).
NuGet package version
Windows App SDK 1.3: 1.3.230331000
Packaging type
Packaged (MSIX)
Windows version
Windows versions that were seen affected:

10.0.19041.3208
10.0.22621.963
10.0.22621.1848
10.0.22621.1992

IDE
Other

Close this issue as it was resolved by a fix in a related issue https://github.com/microsoft/WindowsAppSDK/issues/3740.


swagger UI: add support for embedded Swagger UI API explorer

Hi,
I've added support for embedded Swagger UI API explorer along with tests and basic documentation.

Coverage decreased (-0.1%) to 99.434% when pulling aed2ccbe80e92586e6bb93a042899ddf91d2e7ba on ergo:master into eac2bb4b9fb80084ed1707d60a3586b6a8a4757b on striglia:master.

Coverage decreased (-0.1%) to 99.434% when pulling aed2ccbe80e92586e6bb93a042899ddf91d2e7ba on ergo:master into eac2bb4b9fb80084ed1707d60a3586b6a8a4757b on striglia:master.

When is this going to be merge?
I like the idea of embedded swagger UI.
Also, It would be great if the JSON error responses were enabled through a configuration option like:
pyramid_swagger.error_reponse_format = json or html


Why are there two training functions?

I see two functions called train defined in different places. Which one is the user-facing training interface?

train.py is the thing cog.yaml is pointing to.
training/trainer.py is ... maybe being used by the former?

To add to the confusion, the llama training inputs on the site don't seem to match the inputs of either of the train functions:

To Do

[ ] If they're both used, clarify the purpose of each with a docstring or comment
[ ] If they're not both used, get rid of the dead one

cc @replicate/models

Should be looking at the train-dev branch (but everything might still be broken in that branch too)