FirmwareService.cpp warning

@matth-x
I am getting a warning when I am trying to compile my code on ArduinoIDE.
Also,
HTTP_UPDATE_FAILED Error (-11): HTTP error: read Timeout
I am not sure if this error because of this warning.
warning: lambda capture initializers only available with -std=c++14 or -std=gnu++14
     fwService->setOnInstall([fwService = fwService] (String &location) {

And how to remove this warning?

My update firmware link is of https:// is this an issue?

Hi @ChaitanyaYeole02, did you succeed in the meantime?
The warnings should be fixed by now. Have you checked if you can access the update URL with a web browser from the same network as the controller?


Fix tests for different Xcode versions

Fix tests for Xcode 13 case
And add another test for Xcode 14 case

#4 introduced a call of FastlaneCore::Helper.xcode_at_least? that requires the running environment to have Xcode.app installed. It's not possible on Linux. We stubbed the helper to return false and true for both Xcode version situations.


Is the project still maintained?

There are two pull request and 18 issues open. And it looks like latest API changes has broke few things.
Nothing personal, if you have no time to maintain the project, someone else should do it.

Looks like I missed one pull request. The other is stale though and wasn't ever finished.
As for open issues, some are probably irrelevant or already completed and just need cleaned up. I'm around, just been working on other projects.
Feel free to contribute to help close issues or send pull requests.

Oh yeah. I actively use it in several ongoing projects I have for mod tools. It's not going anywhere :)


Weex android debug is not work

Description
Weex debug is not work   with  weex app scan or  Android  simulator
weex app scan  alert  “devtool”
Android simulator click QR code  alert  “模拟器调试暂时不可用”
Environment
weex -v
v1.3.11

weex-debugger : v1.2.5
weex-builder : v0.4.1
weex-previewer : v1.5.1

Project package.json
"weex-devtool": "0.3.8"
Broken Example

@quanchaoguo the simulator debug has been closed, it will be active while<EMAIL_ADDRESS>be published.
For now, you can use weex playground app to debug with your weex page, see Weex Debug Document.

why phone is not work  I use phone scan alert " devtool "


Add support for CRLF line endings or improve documentation and error message

Lightgbm should handle CRLF (\r\n) line endings or at the very least it should fail gracefully with a nice error message.
Summary
I have examples of lightgbm model files (.lgb files) which crash python when trying to load them in lightgbm.  If you change the line endings from CRLF (\r\n) to LF (\n) then it is loaded without a problem.
According to a comment in #3589 this is expected behavior since lightgbm only supports LF (\n) line endings.  That is why I am putting it here as a feature request rather than a bug.
Ideally lightgbm should support CRLF line endings. But even if that is the expected behavior, the current failure is far from ideal

Error message: The error message is [LightGBM] [Fatal] Model format error, expect a tree here. met  200 1298 1149 12880 ... which does not state what the actual problem is.
Crashing: It does not handle the error. And since the error occurs in low level code (not in python) it completely crashes python with message *** buffer overflow detected ***: python terminated
Documentation: If it is expected to fail for CRLF line endings then it should be documented somewhere.  I have not found that documentation.
Consistency: I have many examples of lightgbm model files with CRLF line endings which can be loaded just fine.  Only certain ones crash python.

I think lightgbm should either add support for CRLF line endings or at least gracefully handle failures caused by line endings -- returning a useful error message and not crashing python.
Motivation
Many people on windows use lightgbm.  Git also has a standard feature to convert line endings when cloning a repo.  So even if the model is checked in with \n line endings, it may still fail on windows machines.

Closed in favor of being in https://github.com/microsoft/LightGBM/issues/2302. We decided to keep all feature requests in one place.
Welcome to contribute this feature! Please re-open this issue (or post a comment if you are not a topic starter) if you are actively working on implementing this feature.

XGBoost solution:
https://github.com/dmlc/xgboost/blob/a1bcd33a3b74f2e80b870c8f4d4f13e94375a8e4/src/common/config.h#L55-L75

Sorry, this was locked accidentally. Just unlocked it. We'd still love help with this feature!


Multiply velocity on flick (fast swipe)

This behavior is how iOS native momentum scrolling works.
For example:
Multiply the current velocity with dt, if the time threshold (touchend - touchstart)  (in this case 100ms) is not reached.

Tried adding this, but it feels hacky. So not Pull Request worthy.
But my code can be found here: http://pastebin.com/Txx3eexS

@RuudBurger At the first, big thanks for your contribution!
Can you explain what it is, that feels hacky to you? I like it! This feels much more like the iOS-way ;)
Anyway, looks pretty good! Thanks alot :-*


ConfiguredJsonCodec example failing

This simple example, given on the documentation, fails on Scala 2.11.11:
import io.circe.generic.extras._, io.circe.syntax._

@ConfiguredJsonCodec case class Bar(@JsonKey("my-int") i: Int, s: String)

Bar(13, "Qux").asJson

with the error:
<console>:17: error: could not find Lazy implicit value of type io.circe.generic.extras.decoding.ConfiguredDecoder[Bar]
       @ConfiguredJsonCodec case class Bar(@JsonKey("my-int") i: Int, s: String)

to fix it, one must define the implicit to return the Configuration within the class' object:
object Bar {
  implicit val config: Configuration = Configuration.default
}

Good catch. The problem here is that all of the code blocks on the page are compiled with the previous blocks' definitions in context, so this example is picking up the configuration from the previous block.
In this case the configuration could go either in the companion object or in any enclosing scope. I don't have a strong opinion about which we should use in these docs, but definitely think each example should contain its own Configuration definition (if it uses one).

This example keeps falling for me.
I'm using Scala Version 2.12.3

Yeah, keeps failing even with implicit configuration defined in scope.

This has been fixed in the meantime by @gvolpe . Current examples work fine.


refactor(plugins/tidy-css): remove param reassign

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

2 of 2 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.0002%) to 99.864%

Totals

Change from base Build<PHONE_NUMBER>:
0.0002%

Covered Lines:
548

Relevant Lines:
549

💛  - Coveralls


Do we have some mechanism to guarantee backward compatibility of osb version?

As the title shows, I didn't find any explanation on backward compatibility of osb version. But there exist some use cases about it:

Suppose the platform has integrated many external service brokers and they both support v2.12, but now the platform wants to upgrade its version to v2.13, and they are afraid that some service brokers don't work well anymore.

Would be appreciated it if someone give some answers.

As long as we're still in the v2.x range, any changes to the spec are supposed to be backwards compatible. If they're not then its a bug and we'll need to fix it.

@duglin Got it, thanks. So is that what deprecated used for? And all deprecated stuffs would be removed in v3.x ?

that's the current plan, yes

Ok, if so, I suggest we add some declaration (just like what you say above) in the spec about the term deprecated, so that it can be more clear for vendors to know about the version control of osb. Just my thought : )

While I think its implied by the definition of "deprecated", do you want to open a PR with some suggested text?

Sure, I'm glad to have a try.

Good issue.
It means if the platform  want to upgrade from V2.x to V3.x, the broker should be upgraded at the same time.  But I think it is difficult to upgrade the platform and broker at the same time, because  they are always developed by different company.

it might help to have deprecated as of 2.xx or something along those lines.
@XinzhongZhou keep in-mind that the communication between the broker and the platform contains the version the platform would like to speak, so technically to migrate from v2->v3 it would require all brokers to support v2 and v3, then switch the platform to asking for v3 protocol.
Read the API Version Header section.

Got it, thanks. @n3wscott , Do you think  it is more clear for broker developer  to add some text in the API version Header section about this scenario, even though it is implied by this section?
This section only said that the broker can reject :),

@XinzhongZhou I think what I have suggested is a strategy for implementation, but not to be a hard rule on how you develop a broker. This is a common enough pattern that I don't see the need to detail it in this spec. OSBAPI has the hooks to make in-place upgrades work, it is up to the broker authors and platforms to make the details happen. (This is my opinion, @duglin or anyone else feel free to disagree)

@duglin @n3wscott Hi, I have checked the release notes and it turns out the 2.1 was released 4 years ago, so does that mean we need to keep it compatible of over 4 years work? If so, I think we have a lot of bugs to be fixed as long as we compare 2.13 with 2.1 : )
Any thoughts?

@leonwanghui that's the intent - ignoring any changes that were made due to clarifications and bugs. If you know of some things that have broken it might be good to enumerate them someplace (aside from the release notes) so that 1) we can agree that it was intentional, and 2) its easy for someone to find all of them.

Yeah I agree, but it seems to extend to another question that when is next enabling-deprecated release (3.x) to be published, which is also concerned by both platforms and service broker vendors. Or do we have the general plan of next one or two big releases?

This raises the question of what happens when v3 is released? My guess is that Platforms would support both v2 and v3, and would likely 'try' v3 first, and then revert to v2 if the broker rejected the request. But is that the ideal workflow? Why not allow brokers to advertise the versions of the spec they support?

version negotiation sounds like a good plan.

Sorry for the long-time delay, I know it's a tough battle to keep version compatible, and actually I don't have any proposed solution for solving this problem. So I'm gonna close this issue, for now.
But personally for tracking any patch with compatibility impact, I suggest we can mark these patches with specific tag (such like needs-backward-compatible).


Inconsistency between az ml environment supported names and Azure ML Portal

Azure ML Portal allows the creation of environments named with dots. For instance: "transformers-torch-1.9". However, the command az ml environment will fail saying that there is unsupported characters. Please use a consistent definition and document the one you select.
Code: UserError
Message: Request is invalid and/or missing fields.
Exception Details:      (RequestInvalid) Resource name is invalid. Resource name can only contain alphanumeric characters, dashes, and underscores, with a limit of 255 characters.
        Code: RequestInvalid
        Message: Resource name is invalid. Resource name can only contain alphanumeric characters, dashes, and underscores, with a limit of 255 characters.

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

ID: 5df96774-93c9-004d-70b8-4f82154fa5cb
Version Independent ID: 8d43e07e-d738-dd2c-a992-e52e6192e071
Content: Manage Azure Machine Learning environments with the CLI (v2) - Azure Machine Learning
Content Source: articles/machine-learning/how-to-manage-environments-v2.md
Service: machine-learning
Sub-service: core
GitHub Login: @mx-iao
Microsoft Alias: minxia

@saachigopal please resolve this issue, thanks

Sent email asking for status update.

This issue has been resolved - UI/CLI should be consistent

As today, in ML CLI v2 version 2.0.7 and a workspace on East US, this remains active.

The team is still investigating, will update once the issue has been identified. Thanks!

@santiagxf thank you for reporting this.  An internal bug has been filed with the product team to address in the next release. We will now proceed to close this thread.
#please-close


Map does not pan with touchscreen on Windows

I have Windows 10 Pro with a touchscreen monitor, and I'm using Chrome as my browser. I went to use one of your maps, and discovered that I can pan the map around if I use my mouse and hold left click, however your map panning does not work if you have a Windows 10 computer with a touchscreen monitor. When I touch my stylus or my finger to the screen to initiate a drag/pan of the map, nothing happens. This is a very disjointing experience, because every other map software I've used, and including the browser, responds to touch scrolling or movement of elements on the screen, except your map applet does not.
Leaflet's focus is "making the basic things work perfectly", and to that degree, I believe this to be a bug because it is a basic function of any map that should work flawlessly in modern computers.

First off: I'm interpreting your wording as passive-aggressive, so I'm sending you off to read https://www.chiark.greenend.org.uk/~sgtatham/bugs.html . Reminding the maintainers of the design focus doesn't help, really.
Second: You didn't specify your environment (even though the bug report template prompts to do so). So, please be specific in the environment this bug is reproducible, including:

Leaflet version (you're working with the latest 1.6.0, right?)
Windows version
Chrome/Chromium version
Make/model of your touchscreen

Also:

Can this be reproduced ni the same computer+touchscreen with a different web browser (edge, firefox)? What versions do and don't work?
Does Chrome in your environment fire the right PointerEvents when using the touchscreen? i.e. what happens in a console when doing something along the lines of L.DomEvent.on(map.getContainer(), 'pointerdown pointerup pointermove', console.log); (as in this plnkr)?

I'm considering putting this under the umbrella of #7200

I'm considering putting this under the umbrella of #7200

It's also possible that latest master already has that fixed.
If not, it worth checking over #7029 (and other Pull Requests of https://github.com/Leaflet/Leaflet/projects/1).

First off: I'm interpreting your wording as passive-aggressive, so I'm sending you off to read https://www.chiark.greenend.org.uk/~sgtatham/bugs.html . Reminding the maintainers of the design focus doesn't help, really.
Second: You didn't specify your environment (even though the bug report template prompts to do so). So, please be specific in the environment this bug is reproducible, including:

Leaflet version (you're working with the latest 1.6.0, right?)
Windows version
Chrome/Chromium version
Make/model of your touchscreen

Also:

Can this be reproduced ni the same computer+touchscreen with a different web browser (edge, firefox)? What versions do and don't work?
Does Chrome in your environment fire the right PointerEvents when using the touchscreen? i.e. what happens in a console when doing something along the lines of L.DomEvent.on(map.getContainer(), 'pointerdown pointerup pointermove', console.log); (as in this plnkr)?

My apologies if this came off as passive aggressive. Github was trying to ask if this was a feature request or a bug report, so I figured it was a bug based on the design focus. It was not my intention to make that sound like anything. I don't frequent bug reporting communities, so maybe there's a certain level of objectiveness or information I'm missing. Again, I apologize for this. I'm just an end user who would like to see the best for the public, including myself. :)
I am not sure the leaflet version, can't find it in the map view or in the HTML source code. When I go to leafletjs.com, I am testing this functionality on the map present there today. I noticed the bug when I was trying to interact with geocaching.com's implementation of the map, but for testing I'm using your live sample on the main website.
Windows version: Windows 10 Pro 19041.329
Chrome version: 83.0.4103.116/Official Build
Touchscreen: Panasonic Toughbook CF-31 OEM, Fujitsu FCL USB Pen tablet. It's a single point resistive touchscreen.
Other browsers: Edge 44.19041.1.0 does work as intended, both pan and doubletap (although CTRL+Doubletap zooms in, not out, strangely enough.)
I see your code asking what Chrome does in my environment under certain programming conditions, but I don't understand how to test what you are asking for.
Does this help? Let me know what I can do to help you fix this problem :)

I attempted to take the code from that Plinkr and put it into an html document. The console reports that both style.css and script.js are missing. I have downloaded the 1.7 beta build to my desktop, I'll see if I can get it working in a local html file to test here.

Let me know what I can do to help you fix this problem :)

https://gist.githack.com/johnd0e/8abac2f4af311bd3cc842270c01cf497/raw/test-taphold-pan.html
Try to pan here, and compare Chrome log with Edge log.

https://gist.githack.com/johnd0e/8abac2f4af311bd3cc842270c01cf497/raw/test-taphold-pan.html
Try to pan here, and compare Chrome log with Edge log.

I have tested this page on my Surface 3 device with Chrome and Edge. Using none I could pan/pinch-zoom via touch or pen. The only action worked as expected was double tap to zoom-in.
If by "log" you mean the printed text in page, logs are identical on both browsers in my case. Both detected the pointer type (pen/touch) correctly.
Versions:
Windows 10 Home 1909
Chrome 84.0.4147.89
Edge 84.0.522.40

https://gist.githack.com/johnd0e/8abac2f4af311bd3cc842270c01cf497/raw/test-taphold-pan.html

Using Firefox on Surface 3 device btw, I could pan with both touch and pen. But still could not pinch-zoom.
Something interesting happens with logs: When I pan using pen, the moment that the map starts to pan, the recorded pointer type changes from "pen" to "touch":
id:115 [0] -1 0 (pen) pointermove
id:115 [0]  0 0 (touch) pointerup <- pen up from screen
id:115 [1] -1 1 (touch) pointermove
id:115 [1] -1 1 (touch) pointermove
id:115 [1] -1 1 (touch) pointermove
id:115 [1] -1 1 (touch) pointermove
id:115 [1] -1 1 (touch) pointermove
id:115 [1] -1 1 (touch) pointermove
id:115 [1] -1 1 (touch) pointermove
id:115 [1] -1 1 (touch) pointermove
id:115 [1] -1 1 (touch) pointermove
id:115 [1] -1 1 (touch) pointermove
id:115 [1] -1 1 (touch) pointermove
id:115 [1] -1 1 (touch) pointermove <- map starts to pan
id:115 [1] -1 0 (pen) pointermove
id:115 [1]  0 1 (touch) pointerdown <- pen touches the screen
id:115 [0] -1 0 (pen) pointermove
id:114 [0] -1 0 (pen) pointermove
id:114 [0] -1 0 (pen) pointermove
and for the unsuccessful pinch zoom the log was:
id:131 [0]  0 1 (touch) pointercancel (not primary)
id:130 [1]  0 1 (touch) pointercancel
id:131 [2]  0 1 (touch) pointerdown (not primary)
id:130 [1]  0 1 (touch) pointerdown
In contrast with Chrome and Edge where pinch-zoom, zoomed the webpage, in Firefox nothing happens when you pinch-zoom the map.
Versions:
Windows 10 Home 1909
Firefox 78.0.2

How to globe?
The globe panning geo tag's is not working on cordova why?

I just tried on surface as I'm building a Pole Permitting and Strand Mapping application for the telecommunications industry.  I will update later with the surface version model.
I know it was Windows 10 Pro and was Using Edge.
Specifics to come later after I check it's use in other browsers as well, I just need to get my ass in bed now though and did a quick search to see if this was just me or others were having issues.

Let me know what I can do to help you fix this problem :)

https://gist.githack.com/johnd0e/8abac2f4af311bd3cc842270c01cf497/raw/test-taphold-pan.html
Try to pan here, and compare Chrome log with Edge log.

I opened up the test and gave it a try. Double tap zoom in works. Double tap zoom out works when shift is held. This is not a multi touch display so I can't test pinch zoom. Panning the map does not work, but creates event log data, as seen below. This data is created whether I'm on the map element or base page... the only difference is if I try and pan on the log which is unpannable there's a pointercancel event.:
id:4 [0]  0 0 (touch) pointerup
id:4 [1] -1 1 (touch) pointermove
id:4 [1] -1 1 (touch) pointermove
id:4 [1] -1 1 (touch) pointermove
id:4 [1] -1 1 (touch) pointermove
id:4 [1] -1 1 (touch) pointermove
id:4 [1]  0 1 (touch) pointerdown
id:3 [0]  0 0 (touch) pointerup
id:3 [1] -1 1 (touch) pointermove
id:3 [1] -1 1 (touch) pointermove
id:3 [1] -1 1 (touch) pointermove
id:3 [1] -1 1 (touch) pointermove
id:3 [1]  0 1 (touch) pointerdown
id:2 [0]  0 0 (touch) pointerup
id:2 [1] -1 1 (touch) pointermove
id:2 [1] -1 1 (touch) pointermove
id:2 [1] -1 1 (touch) pointermove
id:2 [1] -1 1 (touch) pointermove
id:2 [1] -1 1 (touch) pointermove
id:2 [1] -1 1 (touch) pointermove
id:2 [1]  0 1 (touch) pointerdown

Are there fundamental differences between multi-touch (eg MS Surface) and single-touch. At the moment, I've only tested https://gist.githack.com/johnd0e/8abac2f4af311bd3cc842270c01cf497/raw/test-taphold-pan.html on a Surface:
Chrome 85.0.4183.83

Mouse events work fine
Only touch event which works is double-tap zoom (in and out via Shift)
Touch pan fails:

id:2 [0] 0 0 (touch) pointerup
id:2 [1] -1 1 (touch) pointermove
id:2 [1] -1 1 (touch) pointermove
id:2 [1] -1 1 (touch) pointermove
id:2 [1] 0 1 (touch) pointerdown

Edge 85.0.564.44

Mouse events work fine
Only touch event which works is double-tap zoom (in and out via Shift)
Touch pan fails:

id:2 [0] 0 0 (touch) pointerup
id:2 [1] -1 1 (touch) pointermove
id:2 [1] -1 1 (touch) pointermove
id:2 [1] -1 1 (touch) pointermove
id:2 [1] 0 1 (touch) pointerdown

So Edge behaves the same as Chrome.
Pinch-zoom in both browsers zooms the whole page (native behaviour as though no Leaflet map were present). I can give the debug output of that if required, but it's obviously noisier.

https://gist.githack.com/johnd0e/8abac2f4af311bd3cc842270c01cf497/raw/test-taphold-pan.html

Just updated that to latest Leaflet, you should test again.
And compare with results from here: https://gist.githack.com/johnd0e/39784605658089e4cf1bf66530c0d1e5/raw/test.html

@johnd0e
Both those links now work correctly in those browsers on a Surface. Thank you!
I've got a an external touchscreen, but it appears to be multitouch (and I can't find the PSU), so I doubt that will shed more light. Need a single-touch device, and don't think I've got one.

Both those links now work correctly in those browsers on a Surface. Thank you!

That means that your issue is already fixed in latest Leaflet, so update it on your side.

I've got a an external touchscreen, but it appears to be multitouch (and I can't find the PSU), so I doubt that will shed more light. Need a single-touch device, and don't think I've got one. How common are non-multitouch Windows touchscreen setups? Is there an argument that it's too niche for support?

Sorry, I do not understand what are tou trying to do.
Do you have Leaflet issues with that external touchscreen?
Do that issues belong to this issue, or we can close it?

I have no issue - I was trying to help debug this issue (after it was mentioned online: https://twitter.com/tomchadwin/status/1302950132393140224). If it's fixed, fine (I assumed it wasn't because it was still open). As I say, there might be a remaining issue with single-point touch devices, but I don't have one to test with.

Ok, let's wait for @omgitsgela reply.

I have a similar problem and didn't know if I should open a new issue. It only happens in Firefox (80.0.1 x64) and with my Wacom Intuos pen tablet. The map pans correctly if I start by using the trackpad, but from the moment I click it for the first time with the stylus it stops panning — even with the trackpad I can not pan anymore, unless I reload the page.
I tested it on the leafletjs.com homepage and on the test page by @johnd0e. pointermove, pointerdown and pointerup are working as expected, both with pen and trackpad.

I tested it on the leafletjs.com homepage and on the test page by @johnd0e.

And pan brakes in both cases, right?

pointermove, pointerdown and pointerup are working as expected, both with pen and trackpad.

We need to see exact log of this page: https://gist.githack.com/johnd0e/8abac2f4af311bd3cc842270c01cf497/raw/test-taphold-pan.html

I have a similar problem and didn't know if I should open a new issue.

I suppose you should open separate issue.


Backport discord

Motivation for this change
backport #94811  #94814
Things done

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

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

I apologize for spam, wrong base branch


Continuous ZoomOnScroll looses the mouse position when using constrainResolution true

Describe the bug
on the map with constrainResolution, when zooming with scroll, the position of the map start to change like crazy, doesnt matter if its zoom in or zoom out.
To Reproduce
Steps to reproduce the behavior:

set View constrainResolution  true
place the mouse far from the map center
scroll fast to zoom (when zoom changes more then 2 levels, the map position of the mouse snaps )

Expected behavior
keep the mouse position on the map

the problem lies in "ol/interaction/MouseWheelZoom". Anchor coordinate changes midway.

+1, have noticed this also

There is a general issue with constrained anchored animations being cancelled.  Wait for this animation to stop (it is cancelled while at a fractional zoom) https://codesandbox.io/s/simple-tudh4 then attempt to zoom in on the Galapagos.  The view immediately snaps to an integer zoom using the view center as anchor so the pointer is no longer over the Galapagos.

Here is an example that sets constrainResolution: true: https://codesandbox.io/embed/simple-nbb80 (with the<EMAIL_ADDRESS>release).  Can you see the problem in that example?  I'm not sure I'm seeing it.
If you can edit that example until the problem can be spotted, that would help verify the issue.

Forcing an immediate resolving of constraints with the anchor seems to fix it https://codesandbox.io/s/simple-siywi

I have testet both fixes #10078 and #10120 with various browsers (Firefox, Chrome, IE). With both, "MouseWheelZoom" interacts much better with "constrainResolution: true". Is it planned to integrate one of the fixes in the next release?

@richnic thanks a lot for taking the time to test. I agree with you: it'd be great to have this in the next release. This bug has been there for a while now.
@tschaub what's your opinion on this? should we merge Mike's latest PR?


Feature request: configuration option validAtRules (for UnknownAtRules), just like the existing validProperties (for UnknownProperty)

Code references:
https://github.com/microsoft/vscode-css-languageservice/blob/06085e80fb12729c0c3f81feca1a5776d31a4d38/src/services/lintRules.ts#L53-L55
https://github.com/microsoft/vscode-css-languageservice/blob/06085e80fb12729c0c3f81feca1a5776d31a4d38/src/services/lintRules.ts#L43-L44
Related issues:
https://github.com/microsoft/vscode-css-languageservice/issues/113
https://github.com/microsoft/typescript-styled-plugin/issues/83
https://github.com/microsoft/typescript-styled-plugin/issues/82
https://github.com/microsoft/typescript-styled-plugin/issues/77
Related documentation:
https://github.com/microsoft/typescript-styled-plugin#validproperties

Note that in VSCode this can already be solved by adding custom data: https://code.visualstudio.com/Docs/languages/CSS#_css-custom-data


[BUG] Cannot paste text in Canvas

Enable Custom Attachment Location as the only plugin on a vault
Create a canvas
Make 2 nodes, and a link between them
Double click on the link to edit its label, you can't paste text (right click > paste doesn't work either)
Group the nodes and edit the group's label, you can't paste text

Pasting text still works inside the nodes, just not on the links or groups titles

Fixed in https://github.com/RainCat1998/obsidian-custom-attachment-location/releases/tag/4.27.0


Use coap pings instead of get request

Pinging the remote endpoint can be simplified starting with node-coap-client v0.3:
https://github.com/AlCalzone/node-coap-client/#ping-a-coap-origin
const success: boolean = await coap.ping(...);

Also, that method uses inexpensive CoAP pings instead of a full-blown request.

Thanks
Do you know if the ping request can be used to detect if the DTLS session has died?
The issue I'm having is that the gateway either stops responding completely, or that the DTLS session expires and I have to renegotiate a new session.

Basically this should be handled on the DTLS layer. My implementation is by no means complete, so it might be that the client is missing a renegotiation request or something like that. Currently, I'm checking on the application layer if a couple of consecutive pings have failed (which can mean that the session is failed) and then reset the CoAP client.

coap.ping() is now being used since 4de7687


The append vs overwrite document

my magnum opus.  All your comments on the gdocs version have been addressed, I hope.

Note: you may actually need to pull this and build in sphinx to see the animations for cross and union, since I used HTML markup to scale them and relative links for efficiency.  I've verified it builds correctly in my environment.

@pappasilenus Hey, I believe the titles Overwriting files and Appending to files might be reversed?

@pappasilenus Hey, I believe the titles Overwriting files and Appending to files might be reversed?

Good catch, @gpkc !  Fixed, added a transition.  Thanks!

This was truly a huge project doc so great job!


Why are child templates ignored in merge and matrix generators?

Hi, I'm trying to use the merge generators with templates, but the documentation points out that templated in child generators are ignored. I'm curious as to why and whether there's another way to achieve what I want.
I'm trying to use generators additively because I need to optionally include a field in the spec for the Application.
spec:
  generators:
    - merge:
        mergeKeys:
          - server
        generators:
          - clusters:
              # some other cluster generator that adds values
          - clusters:
              selector:
                matchExpressions: - {key: isDev, operator: In, values:[dev]}
              template:
                spec:
                  source:
                    path: charts/some-chart
                    repoURL: https://somgit.com/some-chart.git
                    targetRevision: develop
          - clusters:
            selector:
              matchExpressions: - {key: isDev, operator: NotIn, values:[dev]}
            template:
              spec:
                source:
                  chart: some-chart
                  repoURL: https://somehelm.com
                  targetRevision: 1.0

In this example I need to have path or chart in the final template but never both.

@ssomuah I thought about this when implementing merge generator and couldn't think of a use case to justify the extra complexity.
Can you achieve what you're trying to do by using two cluster generators instead of three in a merge generator?
spec:
  generators:
  - clusters:
      # add values from the old top-level cluster generator here
      selector:
        matchExpressions:
          - {key: isDev, operator: In, values:[dev]}
      template:
        spec:
          source:
            path: charts/some-chart
            repoURL: https://somgit.com/some-chart.git
            targetRevision: develop
  - clusters:
      # add values from the old top-level cluster generator here
      selector:
        matchExpressions:
          - {key: isDev, operator: NotIn, values:[dev]}
      template:
        spec:
          source:
            chart: some-chart
            repoURL: https://somehelm.com
            targetRevision: 1.0


ld-2.24.90 does not support -l:/full/path/to/library.so

pkg-config files are generated with items like -l:/full/path/to/library.so.
(See https://github.com/ros/catkin/blob/indigo-devel/cmake/catkin_package.cmake#L264 )
This does not seem to work with ld-2.24.90. Only -l:library.so works (also, -L/ -l:/full/path/ seems to work, but it's not clear if this is an intended behaviour or not). The ld manual only talks about -l:library.so.
I could not find yet it this is a regression in ld or a deliberate change.
One option could be to change catkin so that it generates proper -L/full/path -lrary in the .pc to link with /full/path/library.so.
Another option is to add an explicit -L/ in front of the -l: items.
Any comment?

Reviving an old thread, but I'm facing the same issue on Arch with binutils 2.25.0. One way to solve the issue is to only add -l:library.so instead of -l:/full/path/to/library.so to the generated pkg-config files. I haven't tested whether this works on the supported Ubuntu platforms, but for someone looking for a quick solution, here is the hack:
diff --git a/cmake/catkin_package.cmake b/cmake/catkin_package.cmake
index 7d56edf..a8f9257 100644
--- a/cmake/catkin_package.cmake
+++ b/cmake/catkin_package.cmake
@@ -261,7 +261,8 @@ function(_catkin_package)
     if(IS_ABSOLUTE ${library})
       get_filename_component(suffix ${library} EXT)
       if(NOT "${suffix}" STREQUAL "${CMAKE_STATIC_LIBRARY_SUFFIX}")
-        set(library "-l:${library}")
+        get_filename_component(libname ${library} NAME)
+        set(library "-l:${libname}")
       endif()
     else()
       set(library "-l${library}")

Just using the library name without the absolute path won't work since a) it does not set the library dirs anywhere and b) even if it would prepend a -L that would still make the lookup try wrong locations first (due to non-deterministic order of the library paths). So I am afraid the proposed patch is not a viable solution.

Well, according to the ld man page, it says

-l namespec
If namespec is of the form :filename, ld will search the library path for a file called filename, otherwise it will search the library path for a file called libnamespec.a.

so it is should only search for the file in the library path. And as per https://sourceware.org/bugzilla/show_bug.cgi?id=17532#c3, the use of full path in the argument is an undocumented ld feature, in actual fact a ld bug, that has since been fixed.
This would require a fix for the next Ubuntu release (15.04) which includes ld 2.25.0. Why is the full library path needed anyway?

Using numerous -L and -l arguments in large scale builds like ROS packags with lots of dependencies has the problem that we can not ensure the right search order for libraries.
Especially when intentionally overlaying workspaces (http://www.ros.org/reps/rep-0128.html#overlays). E.g. when a workspace B overlays workspace A that means that any shared library from workspace B should be preferred over any from workspace A. if every package simply exports library dirs and library names the order in which you find and use them results in a non-deterministic order of -L flags on the link line. Therefore each package exports absolute paths to their libraries.
I could not imagine a workaround for the ROS buildsystem which does not involve a significant refactoring of all ROS packages if the linker would suddenly not support absolute paths anymore. Also we are building ROS Jade packages for Ubuntu Vivid for several months now and I have not seen a single failure related to this. So to me it seems that its ld version still supports that use case.

@dirk-thomas It only occurs when building rosbuild packages, catkin packages build fine so you might not have noticed it. I just tried building a rosbuild package, with a trivial executable as the target, depending on roscpp (with jade on Ubuntu 15.04) and it gave me errors in the linking stage
Linking CXX executable ../bin/test_node
/usr/bin/ld: cannot find -l:/usr/lib/x86_64-linux-gnu/libboost_signals.so
/usr/bin/ld: cannot find -l:/usr/lib/x86_64-linux-gnu/libboost_filesystem.so
/usr/bin/ld: cannot find -l:/usr/lib/x86_64-linux-gnu/liblog4cxx.so
/usr/bin/ld: cannot find -l:/usr/lib/x86_64-linux-gnu/libboost_regex.so
/usr/bin/ld: cannot find -l:/usr/lib/x86_64-linux-gnu/libboost_date_time.so
/usr/bin/ld: cannot find -l:/usr/lib/x86_64-linux-gnu/libboost_system.so
/usr/bin/ld: cannot find -l:/usr/lib/x86_64-linux-gnu/libboost_thread.so
/usr/bin/ld: cannot find -l:/usr/lib/x86_64-linux-gnu/libpthread.so
/usr/bin/ld: cannot find -l:/usr/lib/x86_64-linux-gnu/libconsole_bridge.so
collect2: error: ld returned 1 exit status

I didn't notice that you referred to -l:. The reason for that is described in other comments above:

https://github.com/ros/catkin/issues/694#issuecomment-62938803
https://github.com/ros/catkin/issues/694#issuecomment-62948545

Sadly then seems like rosbuild package building would be broken from Utopic onwards...

I am open to suggestions if you can imagine a way to address the problem.

It could sound a bit stupid but: what about adding the absolute path to the .pc file without the -l flag, just as the absolute path?
jrivero@nium tmp $ cat foo.pc
Name: foo
Description: The foo library
Version: 1.0.0
Libs: /tmp/libboost_system.so.1.54.0
jrivero@nium tmp $ g++ foo.cc -o foo `PKG_CONFIG_PATH=. pkg-config --libs foo`

We can discuss (and probably lost the discussion) if we are not breaking the semantic of the Libs: clause of pkg-config, which specifies:
Libs: The link flags specific to this package and any required libraries that don't support pkg-config. The same rule as Cflags applies here.

I've found that Ogre and OpenCV are doing this kind of tricks in OGRE-PCZ.pc (together with rpath). In the case of OpenCV I think that the .pc file kind of buggy: ... ${exec_prefix}/lib/x86_64-linux-gnu/libopencv_videostab.so -lopencv_videostad

I was able to create a catkin_workspace with catkin modified with this patch and ros_comm. All seems to be working. Absolute paths are passing to the compiler without the -l
Linking CXX executable /home/jrivero/code/ros/ws/devel/lib/rosbag/play
cd /home/jrivero/code/ros/ws/build/ros_comm/tools/rosbag && /usr/bin/cmake -E cmake_link_script CMakeFiles/play.dir/link.txt --verbose=1
/usr/bin/c++       CMakeFiles/play.dir/src/play.cpp.o  -o /home/jrivero/code/ros/ws/devel/lib/rosbag/play -rdynamic /home/jrivero/code/ros/ws/devel/lib/librosbag.so /home/jrivero/code/ros/ws/devel/lib/librosbag_storage.so -lbz2 -lboost_program_options /home/jrivero/code/ros/ws/devel/lib/libroslz4.so -llz4 /home/jrivero/code/ros/ws/devel/lib/libtopic_tools.so /home/jrivero/code/ros/ws/devel/lib/libroscpp.so -lboost_signals -lboost_filesystem /home/jrivero/code/ros/ws/devel/lib/librosconsole.so /home/jrivero/code/ros/ws/devel/lib/librosconsole_log4cxx.so /home/jrivero/code/ros/ws/devel/lib/librosconsole_backend_interface.so -llog4cxx -lboost_regex /opt/ros/indigo/lib/libroscpp_serialization.so /opt/ros/indigo/lib/librostime.so -lboost_date_time /home/jrivero/code/ros/ws/devel/lib/libxmlrpcpp.so /opt/ros/indigo/lib/libcpp_common.so -lboost_system -lboost_thread -lpthread -lconsole_bridge -Wl,-rpath,/home/jrivero/code/ros/ws/devel/lib:/opt/ros/indigo/lib

I was not able to find any singe rosbuild package. @kartikmohta could please point me to your rosbuild package or test the patch by yourself?

I think we first should reproduce the original problem (the reordering) which was the reason why this was changed in the first place (ros/catkin#300).

I'm looking into this, too.  As @tho- asked, can somebody provide a .pc file that will cause pkg-config to reorder the libs?

Removing the -l: prefixes in the .pc files in my Jade installation, to leave bare absolute library paths (cd /opt/ros/jade/lib/pkgconfig; for f in *.pc; do sed -i 's/-l://g' $f; done) fixes my simple example rosbuild package on Utopic.  Presumably I've broken something else in exchange; how I can demonstrate that other broken thing?

On Monday, at 14:55, gerkey wrote:
| Removing the -l: prefixes in the .pc files in my Jade installation, to leave bare
| absolute library paths (cd /opt/ros/jade/lib/pkgconfig; for f in *.pc; do sed -i 's
| /-l://g' $f; done) fixes my simple example rosbuild package on Utopic.
To strictly comply with pkg-config, I think (to be checked again) that Libs:
may only contain -L/-l flags. Absolute path to libraries is not supported,
although it will/should work in practice?
I think that the reordering issues come from libtool, which is too ...  clever
(hum) and separates -L/-l and other flags (like absolute paths to libs) and
then does it's own reordering. So the issue is that if you use -lstuff
/full/path/to/other/stuff, you might end-up linking in the wrong order
(other/stuff before stuff or vice-versa). If you use only -L/-l flags, then
libtoo should still do the right thing. So there is no issue if each library is
installed only once in a unique place.
[I know that libtool is not used by ros packages, but it happens that I do use
it myself in combination with autoconf (hard or impossible to use autoconf
without libtool those days) in some of my (not ros) packages.]
The reordering, when using ony -L/-l and no absolute paths, is only an issue if
you try to solve the scenario where -lstuff might be taken from different -Lpath
(i.e. stuff exists in different places in the system). E.g. :
% ls A/
libfoo.so libbar.so
% ls B/
libfoo.so libbar.so
% gcc ... -LA/ -lfoo -LB/ -lbar
i.e trying to pick-up foo from A and bar from B where both A and B both contain
foo and bar.
My personal opinion on this is that trying to solve this is bound to fail, no
matter what you try to make it apparently work. I personnaly always avoid this
situation. If I need different versions of something, I install everything
into different prefixes, that do not know each other and do not interfere.
For instance, if it happens that foo depends on bar, then the libfoo.so
will have a registered dependency on "libbar.so". And if it there is an ELF
RPATH flag as well in libfoo pointing on A/, then you are going to have
confliting versions of libbar.so (picked up both from A because of libfoo.so
and from B because of the ld flags). This is only the most trivial example of
what could go wrong. I'm pretty sure you can imagine many other kind of
failures.
So, I would personnaly say that the reordering issue is ... not an issue :)
And using only -L/-l in .pc files is the only supported, working, standard and
usual way to go :)

My personal opinion on this is that trying to solve this is bound to fail, no
matter what you try to make it apparently work.

Well, to be fair, it didn't fail when ld provided the mechanism for us to order it and keep it ordered. From my perspective (maybe I'm not forseeing yet another issue that we don't handle) if either ld left this mechanism in place (or one like it) or if pkg-config didn't reorder things, then everything would be working.

If I need different versions of something, I install everything
into different prefixes, that do not know each other and do not interfere.

That's great if it works for you, but for most of our users who don't have an intimate knowledge of linkers, it still leaves them with a subtly broken library exporting mechanism when used with rosbuild. So I think we should still try to resolve the issue, if possible.

Presumably I've broken something else in exchange; how I can demonstrate that other broken thing?

@gerkey I have an idea of how to setup a simple(ish) set of workspaces which reproduces the issue, but they'll be sort of contrived. If you'd like to get together in the near future maybe we can work through it on a white board. Unfortunately I don't remember the exact scenario where this caused us a problem before, so finding an existing package with this issue may not be the easiest way to reproduce the problem.

@wjwwood You need to link against two libraries which work works with one order of those but not the other. Usually you do that by having one library require symbols from the other library. While the symbols required for the executable will always be found - independent of the library order - the symbols used in one library provided by the other will only work for one of the the cases. Based on that you can construct the two workspaces.

@tho- I appreciate that using something other than -L/-l flags in Libs: is unusual, but I can't find anything in the documentation that advises against it.  E.g., from the man page:
Libs:  This line should give the link flags specific to your package.  Don't add any flags for required packages; pkg-config will add  those  automatically

Hypothesis: pkg-config isn't reordering libraries, but rosbuild is.  To get build flags, rosbuild calls out to rospack, which in turn calls out to pkg-config (via rosdep2 running inside an embedded Python interpreter, but for own sanity, let's pretend that that last step is not happening).
For libs, rosbuild calls out three times, once for libs-only-L, once for libs-only-l, and once more for libs-only-other.  The resulting lists are then used separately with different CMake calls: link_directories, target_link_libraries, and set_target_properties LINK_FLAGS.
When we specify in Libs: an absolute library without a -l prefix, it ends up in the libs-only-other bucket, which is given to CMake separately from the other libs, without preserving ordering between -lfoo args and /path/to/libbar.so args.  I would expect ordering to be preserved within the -lfoo args and within the /path/to/libbar.so args (I haven't verified this), but it's up to CMake to decide where on the command line the link flags go with respect to the libs (link flags probably go first?).
So, a potential fix is to modify rosbuild to call rospack differently, or to use the results differently.  We already have an example of parsing the contents of the return from libs-only-other to treat absolute library path names differently (only static libs in that case).
Before I implement this fix, any comments or alternative suggestions?

To clarify, my proposal is:

Change catkin to produce .pc files that don't use any -l prefix on absolute library path names in Libs:.
Change rosbuild to give absolute library path names to CMake in target_link_libraries (along with non-absolute library names, preserving order among them all), rather than set_target_properties LINK FLAGS.

@gerkey That sounds reasonable, and I trust your diagnosis of the issue, but do we have a test case yet that will tell us if it is resolved? Put another way, how will we know it works after your change?
I started working on a test setup for this yesterday, but I didn't finish it yet.
It seems likely that what you've described may be the case. When we were fixing the compatibility between catkin and rosbuild when I first joined WG, I remember that we always approached the issues with the mind set that we would not change rosbuild if at all possible. So we may have originally arrived at this solution we have by avoiding the consideration that we could change rosbuild to fix the issue.

It turns out that I couldn't fix the behavior in rosbuild, because rospack doesn't offer a subcommand to give the entire libs string.  The fix, which is pretty minor, needs to go in rospack: ros/rospack#48.  I'm working on a test case for it.

ros/rospack#48 now has a test for the new parsing behavior (and I verified that the change doesn't break any existing tests).
@dirk-thomas, what do you think about this solution, and the change that'll be needed in catkin's .pc file generation?

Do we have a rosbuild example which succeeds based on a differently overlayed catkin workspace when using -l: but fails when splitting the linker arguments into a path and a library name? If not, I think it is crucial to ensure the patched versions won't break this use case.

No, we don't have a test for that yet.  I could use some help preparing it.  I guess that we need two underlying catkin workspaces, with competing locations / versions of libraries by the same name, with a rosbuild package on top?

There are two cases to test / cover:

No reordering: As mentioned above the example must use two libraries with inter-library dependencies. And the link order must matter. So one order is not supposed to work while the other does. Based on this example we need to ensure that no reordering is happening.

Overlaying: The library A is only present in the underlay workspace while library B is present in the underlay as well as the overlay workspace when using -L it might lead to using B from the underlay. This should not happen but might be something we have to sacrifice in order to fix this ticket. But it would be good to reproduce this first and then consider options how to prevent wrong libraries to be selected (may be rosbuild can internally reorder -L arguments - of course while not changing the order of the actual library names).

+1 currently broken on 15.04 ubuntu

In ros/fix_abspath, I tried another approach: inside rosbuild, strip the leading : character from library paths that have been returned from rospack libs-only-l.  That should work without modifying catkin's generation of .pc files or the way that rospack calls pkg-config.  The -l: prefix in the .pc file ensure proper ordering until the args get into rosbuild, where we strip the prefix and give the resulting list (same order) to CMake in target_link_libraries().
Right?
Wrong.
It turns out that CMake treats :/foo/libbar.so and /foo/libbar.so differently when they're passed to target_link_libraries().  The former is left as is, passed through to the linker.  The latter is split into separate linker args, -L/foo and -lbar, which defeats the purpose of providing the absolute path in the first place.
Now, that behavior should be controlled by policy CMP0003.  And, sure enough, rosbuild is setting that policy to OLD.  But I can't elicit a different behavior by setting it to NEW (that is, I'm still getting the split -L/-l args).

ros/ros#87 has what I believe to be the simplest fix for this problem.  @dirk-thomas and I just went over it in detail and we both agree that it's correct and safe.

Since the .pc files are left unchanged, the issue is still present!
I understand that ros/ros#87 fixes things for ros itself, but anything else
that uses the .pc files will still get linker errors, unless it fiddles itself
with the syntax issues.

@tho- : that's a fair point.   To be honest, I hadn't considered the use case of people get build flags from the pkg-config files directly.  I was concerned with making rosbuild-based ROS packages work.  I still think that that's an important thing, so ros/ros#87 should be merged once we get confirmation that it works.
To remove the -l: prefixes from the .pc files, we'll need to figure out another solution.  As I wrote while exploring that route, it's not easy, because of changes in the handling of library flags between different versions of pkg-config.  I'm open to suggestions.

I only see one approach to "fix" the pkg-config files. We have to introduce the following assumption:
The version of pkg-config is the same when the .pc file is generated and when it is being used.

For our Debian packages that assumption holds as long as the user does not change the default version of pkg-config. For platforms where ROS is build from source that should also be the case.
Therefore I would suggest the following approach: when generating the .pc file check the pkg-config version. If it is "good' (aka has the fix to prevent reordering) the .pc does not use -l:/path/to/so anymore. Either keep the current behavior.
I would assume that this also makes the proposed patch in rosbuild unnecessary since the information provided by pkg-config is already correct (assuming that systems either have old versions of pkg-config and ld or new versions of both).

There's also the interaction with ld version to consider.  It happens to be the case that Trusty has the old pkg-config (which needs the -l: syntax to ensure proper library ordering) and the old version of ld (which accepts the -l: syntax), while Utopic has the new pkg-config (which doesn't need the -l: syntax) and the new ld (which doesn't accept the -l: syntax).
I'm not sure whether that combination of versions holds in general.
If we do go this route (checking pkg-config version and modifying the generation of .pc files in catkin), then we we should revisit ros/rospack#48, which changes how rospack invokes pkg-config.  That change should work in either case, so long as the .pc content is correctly generated for the given version of pkg-config.

I'd also vote to fix rosbuild, but if we move forward with @dirk-thomas's idea to use pkg-config with the ROS 2 bridge, then this will perhaps bite us then.
If you do end up generating different pc files based on the version, then you could add the version of pkg-config it was intended for as an extra variable. That way rospack could at least check to see if the file it found is for the pkg-config it is using.

While the patch from ros/ros#87 fixes building with rosbuild it does not address the problem that the generated pkg-config files are not usable with newer version of ld. Since older versions of pkg-config do not keep the order intact this requires a conditional generation of the .pc files. If pkg-config is new enough that it does not break the library order the .pc file should be generated without the :.
If someone would like to work on a PR for that it would be highly appreciated.

I will set the milestone to untargeted for this since the maintainers will likely not work on this in the foreseeable future.

We ran into this problem again while writing some examples of building against ROS packages directly with pkg-config. So far, we've been working around it with the $(subst) function in Makefiles: https://github.com/gerkey/ros1_external_use/blob/master/ros1_comms/Makefile#L9-L14.

I was also just surprised by this. We are using pkgconfig to depend on some ROS packages in a qmake project. The following works fine on trusty / indigo, but fails on xenial / kinetic:
CONFIG += link_pkgconfig

PKGCONFIG += \
    roscpp \
    tf \
    geometry_msgs

We might have to resort to manually calling pkg-config and using somehting like $(subst) as @gerkey does in the external use Makefile :neutral_face:

@NikolausDemmel I agree with you that having to work around this by modifying the output of pkg-config is pretty bad. I suggested an alternative above which wouldn't require such hacks but @gerkey decided to implement the workaround in rosbuild since it was less effort.
Imo it would be better to actually fix what pkg-config outputs. Since time has moved forward it might be the case that we can rely on all platforms targeted by Kinetic to have new enough ld and libtool which don't have the reordering bug anymore. That would make implementing my proposal much easier. It would be great if you could try to make a PR for this since you have a use case for it.

Thanks for the update Dirk.

It would be great if you could try to make a PR for this since you have a use case for it.

I would love to, but I am not sure when I will have the time (which usually means never, at least until priorities shift, unfortunately...). We are still mostly using trusty / indigo, but I recently needed to release one package for xenial/kinetic for one xenial machine... For that we have simply modified the pc file after install as a quick and dirty workaround.

I just ran into this problem again while trying to link to some ROS libraries directly via pkg-config from a non-ROS project. Can we assume that all platforms running Kinetic now have ld versions that don't understand the -l: syntax any more? For Ubuntu, that's everything from 14.10 Utopic upwards.
If so, couldn't we just merge @kartikmohta 's proposal (slightly modified) into the kinetic-devel branch?
diff --git a/cmake/catkin_package.cmake b/cmake/catkin_package.cmake
index 07613ce..f2a13ad 100644
--- a/cmake/catkin_package.cmake
+++ b/cmake/catkin_package.cmake
@@ -272,7 +272,8 @@ function(_catkin_package)
     if(IS_ABSOLUTE ${library})
       get_filename_component(suffix ${library} EXT)
       if(NOT "${suffix}" STREQUAL "${CMAKE_STATIC_LIBRARY_SUFFIX}")
-        set(library "-l:${library}")
+        get_filename_component(libname ${library} NAME)
+        set(library "-l${libname}")
       endif()
     else()
       set(library "-l${library}")

Look at it this way: On systems with the new version of ld, we cannot break anything (like rosbuild) because it's already broken - any attempt to use the .pc files in question will result in linker errors.
I haven't tested the proposal above yet; my quick and dirty workaround was to simply replace all calls to -l: with -l in the installed .pc files, while keeping the absolute paths. It made the linker errors go away, but I still need to do some testing.

Or, alternatively, follow @gerkey 's example and keep the absolute paths without any -l prefix:
diff --git a/cmake/catkin_package.cmake b/cmake/catkin_package.cmake
index 07613ce..f2a13ad 100644
--- a/cmake/catkin_package.cmake
+++ b/cmake/catkin_package.cmake
@@ -272,7 +272,8 @@ function(_catkin_package)
     if(IS_ABSOLUTE ${library})
       get_filename_component(suffix ${library} EXT)
       if(NOT "${suffix}" STREQUAL "${CMAKE_STATIC_LIBRARY_SUFFIX}")
-        set(library "-l:${library}")
+        set(library "${library}")
       endif()
     else()
       set(library "-l${library}")

It could very well be that newer platforms won't be affected anymore and it would be safe to use either of the proposed changes. This will require some significant testing though (including reproduce the original problem and than confirm that it has been resolved in newer versions across all targeted platforms). I will likely not have the bandwidth to do that so if anybody would like to spend that effort that would be great.

Ok, I've set up a small repo to demonstrate the original problem and to confirm that it affects all Ubuntu versions from Xenial onwards:
https://github.com/mintar/catkin_pkgconfig_tests
Quick summary:
The catkin-generated *.pc files are broken on all platforms except trusty:

compiles?
compiles with hack?

trusty/indigo
✔
✔

xenial/kinetic
✘
✔

yakkety/lunar
✘
✔

zesty/lunar
✘
✔

fedora23/kinetic
✘
✔

fedora24/kinetic
✘
✔

fedora26/lunar
✘
✔

jessie/kinetic
✘
✔

stretch/lunar
✘
✔

"compiles" means whether the test_project in this repo compiles and runs with the original *.pc files.
"compiles with hack" means whether the test_project compiles and runs after running the following command:

sudo find /opt/ros/$ROS_DISTRO -name '*.pc' -exec sed -i -e 's/-l://g' {} \;

If you have any suggestions what else I should test, please let me know or submit a PR to my test repo.
Is there a way to keep the current behavior for Trusty and implement a quick fix like the one from my previous comment for all other platforms? Remember, it's already broken on those platforms, so doing anything is better than doing nothing and hoping a future version of ld will restore the -l:/full/path syntax.

If you have any suggestions what else I should test, please let me know

The interesting question is on which platforms the -l: prefix is needed in order to prevent the reordering to happen (since that was what the prefix was working around in the first place). If that workaround is not required anymore on newer platforms the prefix can just be removed as your proposed. But if the reordering still happens on some platforms I think a solutions which considers the exact versions of the tools involved might be necessary.

Is there a way to keep the current behavior for Trusty

A potential fix could only be applied to the kinetic-devel branch and would not affect Indigo and Jade.

The interesting question is on which platforms the -l: prefix is needed in order to prevent the reordering to happen

Ok, the answer to that question is easy: none of the platforms except perhaps trusty need the -l: prefix. On the contrary: all of them require the prefix to be removed.
Merging the fix into kinetic-devel cannot hurt and will fix at least 99% of the use cases (right now, 100% are broken). If we later find that some reordering takes place, we'll have a concrete example that needs a more elaborate fix. As @gerkey wrote 2 years ago, he hasn't seen any reordering in pkg-config 0.28 (Utopic and later), so we should be good.
Note that we don't change Trusty, where the current version is tested and tried and we know it works. We change the other platforms, where we know that the current version is broken.

That sounds indeed easy. If we only target Kinetic and newer we only have to care for Ubuntu Xenial (and higher), Debian Jessie and Fedora 23 (and higher). All of those ship with at least version 0.28 of pkg-config. Under the assumption that neither of them has the reordering bug anymore it should be safe to remove the workaround. I created #879 with the simple patch. It would be great if you could confirm that it works for your use case.

I've just tested this and it works for my use case!

Thank you for your effort on this long standing ticket.

Thanks @mintar  and @dirk-thomas !

Any ETA when this will land in kinetic? If I see it correctly, there was a tag containing this fix created in July (0.7.7), but ros-kinetic-catkin is still on 0.7.6.

The new version was released only into Lunar during the last release round. This will certainly be released into Kinetic when the next round of ROS core packages are released into Kinetic. I would estimate that this happens in the next 2-3 weeks - but don't quote me on this :wink:


Add installer switches

Is your feature request related to a problem? Please describe.

switches in EXE installer
Describe the feature you'd like

switches that allow silent execution of exe
eg.
1.<path> /S : automaticaly installs better discord to all found versions of discord
2.<path>/uninstall : uninstalls better discord to all found versions of discord
3. <path> [/uninstall] /target <target version> : installs/uninstalls better discord to target version only
note : [] means optional

Additional context

boink

Any updates

See https://github.com/BetterDiscord/BetterDiscord/issues/1215 & https://github.com/BetterDiscord/BetterDiscord/issues/382 for why this will likely not happen.


isAssignableTo is not symmetric, but used in some checks where that is expected

Strong mode isAssignableTo is almost equivalent to:
isAssignableTo(t1, t2) iff t1 <: t2 or t2 <: t1

But there's an extra check to rejecting an implicit cast from a function type to a callable class. There's also an optional flag to disable implicit casts. (and there's dead code relating to generic functions, which isn't reachable anymore because we don't allow generic/non-generic functions to subtype each other)
For newer features (like parameters marked with the covariant keyword) we started using t1 <: t2 or t2 <: t1.
It might be nice to have a symmetric "is either of these a subtype of the other" operation, and a different operation for checking if assignment (and potentially an implicit downcast) should be allowed.
At the very least, we should clean out the dead code from isAssignableTo :)

Do you know why there is a check rejecting implicit cast from a function type to a callable class?
It's possible that the function is an instance of the class, so I don't see any reason to single out that implicit cast compared to other similar implicit down-casts.
It sounds like it's the only actual difference between isAssignableTo and <: || :> (if you ignore the flags to disable implicit casts, which is a lint, not part of the language).

I was wondering so I checked a couple of examples: Strong mode assignability actually does seem to use "S <: T || T <: S" assignability, also for function types. For example:
typedef SuperFun = int Function(int);
typedef SubFun = int Function([int]);

void foo(SubFun f) => f();

main() {
  SuperFun f = (int n) => n;
  foo(f);
}

// This produces the following response (no hints: unused variable):
//
//   > dartanalyzer n032.dart
//   Analyzing n032.dart...
//     warning • The argument type '(int) → int' can't be assigned to the parameter type '([int]) → int' at n032.dart:22:7 • argument_type_not_assignable
//   1 warning found.
//   > dartanalyzer --strong n032.dart
//   Analyzing n032.dart...
//   No issues found!

It's slightly surprising that strong mode is more forgiving in this particular kind of situation. Of course, we can outlaw the downcast with --no-implicit-casts to make strong mode less forgiving, but we could have done that in Dart 1 as well.
The reason why Dart 1 was designed to be more strict in this particular place was probably the run-time effect: Even if you ignore type annotations completely, the function which gets called at run time with f() does not support invocations with zero positional arguments.
The obvious question is then: Should we preserve the approach in strong mode whereby function type assignability admits upcasts and downcasts, but it does not admit assignments where the structure of the argument list of the assigned value violates the requirements according to the type annotation of the assignee? I guess it could be implemented as an additional "argument list shape check" which is performed on function-type-to-function-type downcasts in addition to current assignability checks.

Do you know why there is a check rejecting implicit cast from a function type to a callable class?
It's possible that the function is an instance of the class, so I don't see any reason to single out that implicit cast compared to other similar implicit down-casts.

I'm not sure! Perhaps @leafpetersen remembers?

The reason why Dart 1 was designed to be more strict in this particular place was probably the run-time effect: Even if you ignore type annotations completely, the function which gets called at run time with f() does not support invocations with zero positional arguments.

I have no idea what the thinking behind the Dart 1 function behavior was.  Given the general philosophy of "if it could potentially work we should allow it", I would expect this to be allowed in Dart 1 (since the thing assigned to SuperFun could have an optional argument).  But it's not, so... shrug.
I'd be fine with changing function type assignability to strict subtyping.

The obvious question is then: Should we preserve the approach in strong mode whereby function type assignability admits upcasts and downcasts, but it does not admit assignments where the structure of the argument list of the assigned value violates the requirements according to the type annotation of the assignee?

I'm not really following this.  I don't believe that there are any additional checks that you can add that don't make currently working code into a static error, are there?   I'm obviously in favor of not allowing the implicit downcast, but I feel like adding additional ad hoc checks here just makes things confusing.  I'm a type theorist, and I still have to go and re-read the Dart 1 spec and scratch my head at length to figure out what is and is not supposed to be allowed for function types under the Dart 1 spec.    For example:

https://github.com/dart-lang/sdk/issues/22033
https://github.com/dart-lang/sdk/issues/29791#issuecomment-305934711

So basically, I'd be fine with only doing one way subtyping here, but I don't think I'm keen on something in between.  But I suppose I could be convinced otherwise if there's a reasonably understandable point in the middle.

I'm not sure! Perhaps @leafpetersen remembers?

I think we basically observed that function types are almost never inhabited by instances of nominal types at runtime, so this implicit cast was essentially always going to fail, so why not make it an error?  The user can always put an explicit cast if they're sure that it's the right thing.

That can be said for many implicit downcasts - you can always just cast explicitly if you mean it, and this particular case sounds less error-prone than many other ones that we do allow.
If you are casting a function type to a class type, and the class type is callable with a compatible function signature, then I'd expect the cast to be deliberate more often than not. There aren't that many callable classes anyway.
I think it's an exception (and therefore complication) that doesn't feel like it's carrying its own weight.
If accidental downcasts to callable classes actually happens often, I'd probably reconsider, but otherwise I'd just remove that restriction.

Having thought about this a bit more, I think it's reasonable to drop the distinction: We used to treat an argument list shape mismatch as a more serious fault than a type annotation mismatch, but with the Dart 2 run time discipline (heap soundness & expression soundness) the type annotation mismatch will lead to a dynamic error just as inevitably as the argument list shape mismatch.
With that, using a plain "S <: T || T <: S" definition of assignability also for function types would be a good choice. On top of being meaningful, it's also a simplification.
I agree with Lasse that it is a somewhat weakly motivated exception to treat downcasts from a function type to a callable class differently from downcasts between function types. Presumably, such a downcast would occur in the source code exactly in those situations where developers have a good reason to expect that it will actually succeed.
If the phrase "almost equivalent" doesn't hide anything extra, dropping this exception would make assignability completely symmetric. That would be a simplification of Dart as a whole: Developers will need to know about assignability, but if the story about assignability is short and sweet then they can continue doing their actual work almost immediately. ;-)
Allowing or disallowing implicit downcasts is a separate topic, so let's take that somewhere else.

This is a bit of a digression from the subject at hand, but I am not willing to let this slide by, because it keeps coming up:

Presumably, such a downcast would occur in the source code exactly in those situations where developers have a good reason to expect that it will actually succeed.

I have no idea why you would presume this, and I think it reflects a fundamental misunderstanding of the way that most code comes into being.  In particular, most code comes into being through editing, modification, and refactoring of already written code.  So we start with code that looks like this (hugely simplified from a real code base, of course):
typedef int Callback(int x);

class Foo {
   Callback c;
   void registerCallback(int f(int x)) { c = f; };
}
void main() {
  new Foo().registerCallback((x) => x);
}

And now we come along and decide we want to refactor the code to make Callback a callable class:
abstract class Callback {
  int call(int x);
}

class Foo {
   Callback c;
   void registerCallback(int f(int x)) { c = f; };
}
void main() {
  new Foo().registerCallback((x) => x);
}

And we get no static feedback that our code is now broken.  We didn't have a good reason to expect the implicit cast would succeed because we had no idea an implicit cast was happening.  They are implicit.  That's the whole point.  There is no syntactic difference whatsoever between code with and without an implicit cast, and therefore to "intend" the implicit cast, we have to fully simulate, in our head, the type checking algorithm to understand where all of the implicit casts are happening.
In my experience, most people are not aware of places where implicit casts are happening at all.  The IDE tells them the places where invalid assignments are happening, and all other places are assumed good until proven otherwise.
I have had numerous issues filed, and feedback provided, to the effect that refactoring is hard in Dart because of implicit casts.
I have had no issues filed that I can recall, or any other feedback provided, to the effect that having to explicitly downcast from a function type to a nominal type was a problem.
I actually think it would be a fascinating user study to pick a large range of recent CLs, find all of the implicit casts added by that CL, and ask the author of the CL whether they intended/were aware of, the implicit cast that was added by their code.  @lukechurch

Concretely to the main point of this issue.  We were not able to remove call methods from the Dart 2.0, so my plan to solve the issue described here:  https://github.com/dart-lang/sdk/issues/29791 is to remove call method subtyping from the type system, and instead allow assignment to introduce an implicit tear-off of the call method when assigning from a callable class to a function type.  This means that the asymmetry will remain, since there is no coercion in the other direction, and there is no subtyping relation between function types and callable classes.

This is a bit of a digression from the subject at hand, but I am not willing to let this slide
by, because it keeps coming up:

Presumably, such a downcast would occur in the source code exactly in those situations
where developers have a good reason to expect that it will actually succeed.

I have no idea why you would presume this, and I think it reflects a fundamental
misunderstanding of the way that most code comes into being.

It sounds a little bit like you're addressing implicit downcasts in general here, not the asymmetry which is the topic of this issue. The point I was making was relative to downcasts in general: If we assume that implicit downcasts are being managed in a reasonable way then I would expect implicit FunctionType-2-CallableClass downcasts to be no more dangerous than other implicit downcasts. Btw, I believe this is very much in line with Lasse's argument on the same topic.
Of course, I already advocated giving programmers some more help in the area of implicit casts, say, by having IDEs give every expression which is subject to an implicit downcast a different background color, and I'm also open to have more of --no-implicit-casts by default. That's just a different topic.

In particular, most code
comes into being through editing, modification, and refactoring of already written code.

Right, and that's a very good reason to think carefully about how to support developers. For instance, the IDE should, as far as possible, help developers track down locations where significant changes occur as a result of a given change (say, a git commit). You could get a list of locations where there a non-trivial downcast has been introduced. Same thing when you run pub upgrade. But that's still about implicit downcasts in general, not about FunctionType-2-CallableObject downcasts.
By the way, changes may also introduce bugs around explicit casts (which includes C#, Java, C++ and others): If you claim to know that a given expression has a specific type, and somebody changes the code that you depend on such that this assumption is no longer justified, you can have a clean compile and still get a (newly introduced) run-time error at such a cast.

So we start with code that looks like this (hugely simplified from a real code base, of course):

The code you show is basically a scenario where (1) a type Callback is redefined to denote a proper subtype of its former value, and then (2) client code passing a value of the old type used to be a trivial cast and it is now an implicit downcast. No warning at compile time, but failure at run time. In that sense it's the same as this scenario:
class C { foo(num n) {}}
main() { num n = 3.14; new C().foo(n); }

.. where somebody later on commits the change to make it class C { foo(int n) {}}: suddenly the invocation in main has an implicit downcast, and it will fail at run time.
Granted, there are some extra elements in your example. In particular, the argument (x) => x in your example contains implicit type annotations which are subject to inference (making it an int Function(int) in both the "before" and the "after" scenario). The scenario could, for instance, give rise to a situation where the type inference "repairs" the code upon the change (say, because typedef int Callback(int i); is changed to typedef String Callback(String s);). However, this "self-repair" effect only occurs in special situations, and rather arbitrary (say, (n) => n.floor(); could have types int Function(num) and Floor Function(Room), and maybe a few other very ad-hoc types).
The essence of the example is still "Type T denotes S, then change it to denote a proper subtype U of S, and now clients passing values to parameters/variables typed T may have an implicit downcast that they didn't have before".

And we get no static feedback that our code is now broken.

You could actually get that in this particular case: You've introduced a notion of exact types (we know that new A() is an "exactly A" when that newExpression invokes a generative constructor, so we can detect the dynamic error statically at a downcast like B b = new A();), and we have something very similar here:
It can be detected statically that the type of (x) => x cannot ever be a callable class, no matter which type annotations type inference will add to it (including the return type which has no syntax, of course), so when Callback is a callable class we can statically detect the run time failure at Callback c = (x) => x;.
If you're really worried about this kind of situation then I'd suggest introducing this new kind of exactness: "The run-time type of this value is guaranteed to be a function type".

We didn't have a good reason to expect the implicit cast would succeed because we had no
idea an implicit cast was happening. They are implicit. That's the whole point.

That's still concerned with implicit cast in general and not so relevant for the FunctionType-2-CallableObject downcast in particular. The same applies to the remaining 5 paragraphs.

[Choose] recent CLs, find all of the implicit casts added by that CL, and ask the author of
the CL whether they intended/were aware of, the implicit cast that was added by their code

That would be really cool!

I have no idea why you would presume this, and I think it reflects a fundamental misunderstanding of the way that most code comes into being.

On re-reading, this comment was more strongly worded and combative than it needed to be - my apologies.

@leafpetersen, on re-reading, I can see why you thought that I was talking about downcasts in general, not just FunctionType-2-CallableObject -- counter-apologies. ;-)
By the way, you mentioned a different issue that might actually play a bigger role for this issue than symmetry and assignability: Type complexity.
It would be a problem if we support a type universe whose complexity is significantly greater than we intend. It could affect the comprehensibility of the language, the ability to maintain soundness, or the ability to obtain the type of expressions (in a reasonable amount of time, or at all). So if the subtype relationship between function types and callable classes creates this kind of issue, we should discuss that explicitly and address it directly.
An example of a situation that creates a peculiar kind of recursion is the following:
typedef T F<T>(T t);

class C<T extends F<T>> {}

class D extends C<D> {
  D call(D x) => x;
}

Class D is correct because D <: F<D>, that is D <: D Function(D), because D has a call method with type D Function(D). So entities of type C<...> can exist, for example C<D>.
But considering a raw C, instantiate-to-bound produces an infinite type of a kind that I haven't seen elsewhere (I think): C means C<W> where W = W Function(W), which may then be unfolded any number of levels, e.g., C<W Function(W Function(W...) ...) Function(W Function(W...) ...) ...>.
Is this what you were getting at?
If we aim to eliminate such a class of types that we deem "too complex", we might eliminate the subtype relationship between function types and callable classes entirely (which would of course eliminate all issues concerned with that subtype relationship, including assignability). In that case we would essentially get rid of callable classes entirely, because there's nothing special about call if everything you can do with it is to tear it off (even if that would happen implicitly when an instance of a "now-not-so-callable-class" is provided where a function is expected).
We might also be able to eliminate the overly complex types by adding some (hopefully simple and practical) constraints on the allowed declarations of callable classes.

So, the problem is that we:

allow nominative types to be recursive (function typedefs are not allowed to refer to themselves)
allow function types as bounds in F-bounded classes.
allow the type of the object with a call method to be reduced to its function type, throwing away the nominative indirection.

We can create infinite class type constraints with F-bounded classes, like class Comparable<T extends Comparable<T>>. That is "not a problem" except when we try to invent a solution, so we give up on that.
The problem here is that assigning a function typed value to a callable class tp means checking against a structural type against an F-bounded nominative type where the bound, so we do need to unfold arbitrarily far to check that the assignment is valid. Because of the covariance, we can switch the burden from side to side and force an infinite unfolding.
Assignment in the other direction is safe - it's an up-cast, not a down-cast, so we don't need to do runtime checking.
So, if we do implicit tear-offs instead of assigning the object itself when assigning a callable object to a function type, then we can certainly, and statically, reject assignments from function types to objects, which avoids the potentially infinite runtime type-check. I can see why it's desirable.

I've created a separate dart-lang-evolution issue (152) to discuss the type system complexity issue.

The problem here is that assigning a function typed value to a callable class tp means checking against a structural type against an F-bounded nominative type where the bound,

I don't think this has anything to do with F-bounded types, at least not uniquely.  The original example from here:
https://github.com/dart-lang/sdk/issues/29791
is just:
class Foo {
  void call(void callback(Foo foo)) {}
}

main() {
  Foo foo = new Foo();
  foo(foo);
}

The question is, does Foo subtype Foo -> void.

To answer that question, we need to know whether (Foo -> void) -> void subtypes Foo -> void
To answer that, we need to know whether Foo subtypes Foo -> void, and we're back to where we started.

It's possible (likely)? That the algorithms developed to handle equi-recursive types (e.g. by Amadio and Cardelli) would handle this just fine, but that's quite a bit of machinery for a small feature.  That is another direction we can explore though.

I believe this is "fixed" by not making callable class's types subtypes of function types.
We then have an asymmetry in the other direction, since a Foo is assignable to void Function(Foo), but not vice-versa (there is no type relation between the two, but an automatic coercion in one direction).
Nothing more is expected to happen here.
Is it still an issue that the relation is not symmetric?

https://dart-review.googlesource.com/c/sdk/+/62660


feat: support ClientMetadata during SignUp and ForgotPassword

Added according to https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-pre-sign-up.html#cognito-user-pools-lambda-trigger-syntax-pre-signup

LGTM!


Loop error

I've done EVERYTHING, the domains, the let's encrypt certificates, ports in the router... everything. Even tried the testing branch....
It show a message that it has been disconnected, wait some seconds and reconnect... and back again, is like i forgot anything. But everything else works, it ask for camera permits, audio, blah blah, but suddenly it disconnect

...

Any news?

Any news?

Any help ?

Hi!, i had a problem like that on my odroid hc1 . this one hay 2 gb of ram.

journalctl | grep jicofo
returns
Jun 15 00:27:01 domain.tld jicofo.sh[9671]: Error occurred during initialization of VM Jun 15 00:27:01 domain.tld jicofo.sh[9671]: Could not reserve enough space for 3145728KB object heap i read https://jitsi.org/jitsi-videobridge-performance-evaluation/
So i decided to reduce the space reservation to 500meg for the javavm in both of jitsivideobridge and jicofo start script. knowing that i will never do 100 participant confcall.

/var/www/jitsi/jitsi-jicofo/jicofo.sh
LD_LIBRARY_PATH=$libs exec java -Xmx**572m** -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -Djava.library.path=$libs $LOGGING_CONFIG_PARAM $JAVA_SYS_PROPS -cp $cp $mainClass $@

/var/www/jitsi/jitsi-videobridge/jvb.sh
`if [ -z "$VIDEOBRIDGE_MAX_MEMORY" ]; then VIDEOBRIDGE_MAX_MEMORY=572m; fi

LD_LIBRARY_PATH=$libs exec java -Xmx$VIDEOBRIDGE_MAX_MEMORY $VIDEOBRIDGE_DEBUG_OPTIONS -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -Djava.library.path=$libs $LOGGING_CONFIG_PARAM $JAVA_SYS_PROPS -cp $cp $mainClass $@`
tell me if that helps you

duplicate of #10


cloudshell create ingress The network is abnormal

use version: cloudtty 0.7.2
problem description：After the cloudshell is created successfully, the url cannot be accessed immediately，The access is normal after a period of time
suggest:  pod successfully created, then created ingress

@harlee-x Did you use ingress mode?  It may take some time to update the route, I'm not sure.

yes, use ingress mode, It takes a while to see ingress provide support from use


igv: init at 2.3.77

Motivation for this change
Add Integrative Genomics Viewer (IGV) to NixOS
Things done

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

[X] NixOS
[ ] OS X
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[X] Fits CONTRIBUTING.md.

Needs rebasing.

@mimadrid why close? You can simply rebase ontop of master and force push the branch.

Github closed it because I deleted the branch by accident D: although I repushed it Github doesn't reattach it.

With the pull request open Github reattached it now.

@joachifm thanks for be so patient. Fixed.

Thanks @jagajaga, fixed.


Fix some miispellis in cluster/engine.go

Signed-off-by: fate-grand-order<EMAIL_ADDRESS>

LGTM


TEH

README.md:
"The specific features supported are described in teh Release Notes"
TEH! :)

We are just trying to keep it hip ;)
Glen Wiley
Principal Engineer
Verisign, Inc.
(571) 230-7917
A5E5 E373 3C75 5B3E 2E24
6A0F DC65 2354 9946 C63A
From: Jeroen Massar <notifications<EMAIL_ADDRESS>Reply-To: verisign/smaug <reply<EMAIL_ADDRESS>Date: Wednesday, March 25, 2015 at 4:19 AM
To: verisign/smaug <smaug<EMAIL_ADDRESS>Subject: [smaug] TEH (#1)
README.md:
"The specific features supported are described in teh Release Notes"
TEH! :)
—
Reply to this email directly or view it on GitHubhttps://github.com/verisign/smaug/issues/1.

Thanks for the catch.  Fixed teh issue. . . ;)


errors in config

Hello,
I'm very interested to install your Module.
I tried to install the part for open windows, but I keep on getting errors when booting Magic Mirror.
Can you please check the example code provided?
The part of code for on top of config.js, does that have to be copied above or below:
var config = {
address: "localhost",
When checking the code, for the part to be copied on top of config.js,  counting the brackets, at least }) are missing to stay in line with the opening brackets.
Also on 2 places ; are used. Shouldn't that be komma's?
For the module entry, after port: 8123 the , is missing.
I played around with all these variables but didn't get it working.
In the documentation, could you also add the required settings for Home Assistant to ensure on both ends it works as expected?
I appreciate your support,
Thanks for looking into the issue.

Got this working. Add a comma after port and this is working:
let perimeterWindowSections = [];
perimeterWindows.forEach((item, i) => {
    perimeterWindowSections.push({
        triggerEntities: [
            item.entity
        ],
        displayTemplate: `
        {% if states.${item.entity}.state == "on" %}<i class='mdi mdi-window-open'></i> ${item.name}{% endif %}
        `,
        class: "window"
	})
})


Can you provide the xml annotation format of voc

Hi there, sorry for replying late.
There seems some useful tools for the yolo2voc conversion provided here. You can use them for quick conversions.


souce map does not work with standard options

Hi,
I am using uglify as a part of webpack and I am not able to get the sourcemap working properly. I want to enable sourcemaps to get a better stack trace for errors. I still see cryptic errors.
When i remove the UglifyJS plugin from the webpack, it works fine i.e I see the correct stack traces and I see a "sourceMappingURL" line in the js bundles.
With UglifyJS and sourcemap enabled, I see that map files are being generated (js.map in the build) but I do not find the "sourceMappingURL" line in the js bundles. and the stacktraces are from the minified code.
My Configuration:
devtool: "source-map"
Below are my plugins:
new ForkTsCheckerWebpackPlugin({
some options
}),
new webpack.optimize.CommonsChunkPlugin({
names: ["x1", "x2", "x3", "x4", "manifest"],
}),
new webpack.DefinePlugin(),
extractLess,
new webpack.optimize.UglifyJsPlugin({
compress: {
warnings: false
},
sourceMap: true
}),
// new BundleAnalyzerPlugin(),
new HtmlWebpackPlugin({
filename: "../index.html",
template: "./config/template.html"
}),
]

@shkrishms can you create minimum reproducible test repo, thanks!

@shkrishms Could you try with the latest beta please ?
npm i -D uglifyjs-webpack-plugin@beta

But for development (debugging etc) I recommend to not use a minifier
webpack.config.js
const env = process.env.NODE_ENV

{
   plugins: [ env === 'development' ? new UglifyJSPlugin() : false ].filter(Boolean)
}

@michael-ciniawsky , the beta does not seem to help.
I have created a repository at https://github.com/shkrishms/UglifyJsIssue. This should have the code necessary to reproduce the issue.
Please use chrome only.
Go to the OspApp folder. and then do the following:

npm run build:prod
npm run start:release
Open https://localhost:44326 in the browser and see the sources.

"\OspApp\config\webpack.prod.js" has the config for UglifyJS. When UglifyJS plugin is removed, the stack trace is correctly reproduced.

@michael-ciniawsky , @evilebottnawi -, any update on this? Please let me know if anything is needed.

@shkrishms sorry, don't have time right now for this :disappointed: in near future i try to investigate this, thanks!

Closing in favour of #134

I am in the same situation now. i'm using webpack4 and it looks like not working with option sourceMap true


Export in png and svg

Hi,
How can we export the structures generate with fornac in png and svg?
Thanks.

Hey,
You can't export to SVG or PNG natively, but you can use SVG Crowbar to extract its contents as an SVG. If you want native SVG or PNG export, I recommend using forna.

I'll try forna.
Thanks


get an error, RangeError: Maximum call stack size exceeded

Installing this plugin in nodebb v1.0.2, after restarting nodebb, it throws such error.
11/4 10:24 [86089] - verbose: [meta/js] nodebb.min.js minification complete
11/4 10:24 [86089] - verbose: [hotswap] Router with id `plugins` replaced successfully
11/4 10:24 [86089] - verbose: [plugins] All plugins reloaded and rerouted
11/4 10:24 [86089] - error: RangeError: Maximum call stack size exceeded
    at Function.EventEmitter.listenerCount (events.js:397:38)
    at Log.listenerCount (/Users/hain/glory/cnodebb/node_modules/nodebb-plugin-search-elasticsearch/node_modules/el
asticsearch/src/lib/log.js:68:25)
    at Function.EventEmitter.listenerCount (events.js:399:20)
    at Log.listenerCount (/Users/hain/glory/cnodebb/node_modules/nodebb-plugin-search-elasticsearch/node_modules/el
asticsearch/src/lib/log.js:68:25)
    at Function.EventEmitter.listenerCount (events.js:399:20)
    at Log.listenerCount (/Users/hain/glory/cnodebb/node_modules/nodebb-plugin-search-elasticsearch/node_modules/el
asticsearch/src/lib/log.js:68:25)
    at Function.EventEmitter.listenerCount (events.js:399:20)
    at Log.listenerCount (/Users/hain/glory/cnodebb/node_modules/nodebb-plugin-search-elasticsearch/node_modules/el
asticsearch/src/lib/log.js:68:25)
    at Function.EventEmitter.listenerCount (events.js:399:20)

So, after configuring elasticsearch, the search does not works.
11/4 10:18 [85521] - error: [plugin/elasticsearch] Could not delete and re-create index. Error: not-conne[280/1914]
express deprecated res.send(status): Use res.sendStatus(status) instead node_modules/nodebb-plugin-search-elasticse
arch/library.js:331:8
11/4 10:19 [85521] - warn: [middleware.admin.isAdmin] deprecation warning, no need to use this from plugins!
11/4 10:19 [85521] - error: [plugin/elasticsearch] Could not delete and re-create index. Error: not-connected
11/4 10:22 [85521] - warn: [middleware.admin.isAdmin] deprecation warning, no need to use this from plugins!
11/4 10:22 [85521] - error: [plugin/elasticsearch] Could not delete and re-create index. Error: not-connected
11/4 10:22 [85521] - warn: [middleware.admin.isAdmin] deprecation warning, no need to use this from plugins!
11/4 10:22 [85521] - error: [plugin/elasticsearch] Could not delete and re-create index. Error: not-connected
11/4 10:23 [85521] - warn: [middleware.admin.isAdmin] deprecation warning, no need to use this from plugins!
11/4 10:23 [85521] - warn: [middleware.admin.isAdmin] deprecation warning, no need to use this from plugins!
11/4 10:23 [85521] - error: [plugin/elasticsearch] Could not delete and re-create index. Error: not-connected
^C11/4 10:24 [85521] - info: [app] Shutdown (SIGTERM/SIGINT) Initialised.
11/4 10:24 [85521] - info: [app] Database connection closed.
11/4 10:24 [85521] - info: [app] Web server closed to connections.

I also get a warning
11/4 10:49 [87352] - warn: [plugins/load] The following plugins may not be compatible with your version of NodeBB.
This may cause unintended behaviour or crashing. In the event of an unresponsive NodeBB caused by this plugin, run
`./nodebb reset -p PLUGINNAME` to disable it.
  * nodebb-plugin-search-elasticsearch

And the elasticsearch module is too old.

I update elastic search module within the nodebb-plugin-search-elasticsearch but still
3/2 00:26:44 [2958] - info: Routes added 3/2 00:26:44 [2958] - info: NodeBB Ready 3/2 00:26:44 [2958] - info: Enabling 'trust proxy' 3/2 00:26:44 [2958] - info: NodeBB is now listening on: <IP_ADDRESS>:4567 3/2 00:27:18 [2958] - error: /api/search  TypeError: Cannot read property 'replace' of undefined     at escapeSpecialChars (/Users/eeeeeeric/Downloads/NodeBB-master-3/node_modules/nodebb-plugin-search-elasticsearch/library.js:19:11)     at Object.Elasticsearch.search [as method] (/Users/eeeeeeric/Downloads/NodeBB-master-3/node_modules/nodebb-plugin-search-elasticsearch/library.js:229:18)     at /Users/eeeeeeric/Downloads/NodeBB-master-3/src/plugins/hooks.js:114:12     at /Users/eeeeeeric/Downloads/NodeBB-master-3/node_modules/async/lib/async.js:375:13     at iterate (/Users/eeeeeeric/Downloads/NodeBB-master-3/node_modules/async/lib/async.js:262:13)     at Object.async.forEachOfSeries.async.eachOfSeries (/Users/eeeeeeric/Downloads/NodeBB-master-3/node_modules/async/lib/async.js:281:9)     at Object.async.inject.async.foldl.async.reduce (/Users/eeeeeeric/Downloads/NodeBB-master-3/node_modules/async/lib/async.js:374:15)     at fireFilterHook (/Users/eeeeeeric/Downloads/NodeBB-master-3/src/plugins/hooks.js:106:9)     at Object.Plugins.fireHook (/Users/eeeeeeric/Downloads/NodeBB-master-3/src/plugins/hooks.js:87:5)     at Object.search.searchQuery (/Users/eeeeeeric/Downloads/NodeBB-master-3/src/search.js:445:10)     at async.parallel.pids (/Users/eeeeeeric/Downloads/NodeBB-master-3/src/search.js:61:13)     at /Users/eeeeeeric/Downloads/NodeBB-master-3/node_modules/async/lib/async.js:718:13     at async.forEachOf.async.eachOf (/Users/eeeeeeric/Downloads/NodeBB-master-3/node_modules/async/lib/async.js:233:13)     at _parallel (/Users/eeeeeeric/Downloads/NodeBB-master-3/node_modules/async/lib/async.js:717:9)     at Object.async.parallel (/Users/eeeeeeric/Downloads/NodeBB-master-3/node_modules/async/lib/async.js:731:9)     at /Users/eeeeeeric/Downloads/NodeBB-master-3/src/search.js:58:9     at /Users/eeeeeeric/Downloads/NodeBB-master-3/node_modules/async/lib/async.js:726:13     at /Users/eeeeeeric/Downloads/NodeBB-master-3/node_modules/async/lib/async.js:52:16     at async.forEachOf.async.eachOf (/Users/eeeeeeric/Downloads/NodeBB-master-3/node_modules/async/lib/async.js:236:30)     at _parallel (/Users/eeeeeeric/Downloads/NodeBB-master-3/node_modules/async/lib/async.js:717:9)     at Object.async.parallel (/Users/eeeeeeric/Downloads/NodeBB-master-3/node_modules/async/lib/async.js:731:9)     at searchInContent (/Users/eeeeeeric/Downloads/NodeBB-master-3/src/search.js:46:8) Thu, 02 Feb 2017 16:35:30 GMT express deprecated res.send(status): Use res.sendStatus(status) instead at node_modules/nodebb-plugin-search-elasticsearch/library.js:331:8

Fixed with #7


Extend  & improve workflows

Here is a PR to extend and improve the workflows in the repo:

Add a labeler to the Github workflows to ensure consistent labels within the repo.
Add a CONTRIBUTING.md file to comply with Github repo standards and to explain the creation of code contributions and bugs, feature requests, etc.
Add a dependabot.yml file so that Dependabot can be used to automatically update dependencies and github actions in the future.
Fix linting workflow by updating Python Version in pyproject.toml and Run poetry update.

Merged V2 into master, this will probably need a rebase before I can review it

Hi @DurgNomis-drol. Merge conflicts should be resolved now