calendar bug report

Description of the Issue and Steps to Reproduce:
Please include the values of all variables used.
Environment:
*Examples: Chrome 60 on OSX,  Node.JS 8.4.0 on OSX
Both the browser and the OS are important to us, particularly if you have an unsual environment like an IOT application.
Other information that may be helpful:

The time zone setting of the machine the code is running on Asia/Shanghai
The time and date at which the code was run 2017-09-07

If you are reporting an issue, please run the following code in the environment you are using and include the output:
// today 2017-08-31
console.log(moment('2017-09-07').calendar())
// 09/07/2017
// it's Saturday next week indeed
console.log(moment('2017-09-02').calendar())
// 下星期六00:00
// which means Saturday next week, but it's Saturday this week indeed

Ensure your issue is isolated to moment. Issues involving third party tools will be closed unless submitted by the tool's author/maintainer.
source code:
calendar : {
  sameDay : '[Today at] LT',  // today, right
  nextDay : '[Tomorrow at] LT', // tomorrow, right
  nextWeek : 'dddd [at] LT', // this week, wrong
  lastDay : '[Yesterday at] LT', // yesterday, right
  lastWeek : '[Last] dddd [at] LT', // this week, wrong
  sameElse : 'L' // have no idea about this
}

today is 2017-08-31, in chinese:

2017-08-28 ~ 2017-09-03 from Monday to Sunday are all in this week.
2017-08-21 ~ 2017-08-27 are last XXXday
2017-09-04 ~ 2017-09-10 are next XXXday

This seems similar to #4097


Add link to prospect page in the web app

It would be very convenient to have a link to the prospect page near the "Sky Viewer" link for each target in the fastspecfit web app. This will work for DESI collaborators only as it points to daily spectra, but it has all the functionality with zooming, smoothing, trying different redshifts, etc. The URL can be constructed for a given targeted: https://www.legacysurvey.org/viewer-desi/desi-spectrum/daily/targetid{targetid}

Thank you for the suggestion @stephjuneau. This is done.


[Feature Request] FSB does not respect Iris-shader-modified day-cycle rotational offset

I mentioned this on discord as well, but if one uses a shaderpack through Iris which allows the day-cycle rotation to be angled differently than vanilla (say, 45 degrees to the side so it's diagonal), FSB will not respect it and operate on this new offset. It enforces its own fixed trajectories based on the vanilla day-cycle angle.
Here's an example shot where an Iris shader (Complementary) is enabled while FSB is active. The shader respects all skybox assets, but is unable to enforce its offset on them. As a result, the sunlight and rays are originating from the side of the sun:

I'd love it if something could be done so that the two would play nice with each other, thank you!
Related to #28

Duplicate of #28
Also I don't think this is very feasible, not only would it require accessing the zenith angle from iris (or other mods), it would also need to tilt the sun skybox specifically. If all the skyboxes were tilted, most of them would look slanted and weird, and there is no easy way to find out which skybox(es) are the sun/moon do they can be tilted.
I might be missing something though, if you have an idea of how this may be implemented please let me know

I mean, why would you tilt the skyboxes in general? Leave them be. All you'd want is a specific setting that you could enable in any config you want that would make FSB respect angle/tilt changes that Iris (or whatever) make and apply the maths that FSB already does on top of these offsets.
As for the exact method of insertion.. not entirely sure. I reckon you'd need to ask more details to the shader maker and whether FSB can access these values in the first place before deciding how to account for the offsets in the calculation.
In theory anyway... perhaps FSB could go the agnostic route instead. For example, instead of tying the two together and working at the same time.. ensure they stay completely separated and out of each other's way. To be specific:
A) Existing skybox setups and such will just operate as they are now and completely ignore any Iris/mod changes to the day/night cycle angle and tilt (we already do this more or less).
B) A dedicated setting could allow a particular skybox to be locked to the day/night cycle specifically, even if that's modified by something else (aka respecting the vanilla or modified angle/tilt). The only rotating allowed would be in-place (so still centered at the sun or moon, configurable).

So the user would have to pick the sun/moon skyboxes manually? I think that might be too much work for the user and the dev (esp considering it would have to be done for every resourcepack)

So the user would have to pick the sun/moon skyboxes manually? I think that might be too much work for the user and the dev (esp considering it would have to be done for every resourcepack)

It already is a fair amount of work because the direct conversion is not sufficient to make optifine skies work the same in FSB, so that's a moot point. Adding a single extra line of config is hardly an effort.

This is not currently on my radar to fix, especially since there are so many moving pieces to this problem.  In order for this to properly be fixed to my knowledge both FSB and Iris, as well as the active shader and skybox, would all have to account for this happening.  It's possible there's a simpler solution, but without a deep dive into Iris's code I don't know.

This should fixed from Iris' end now
https://github.com/IrisShaders/Iris/blame/1.18.2/docs/changelogs/1.6.0/full.md#L21

It's not, I have discussed this on the Discord server.


Paginate Releases page

Paginating the releases page into more precise versions (e.g. /releases/2.x, /releases/1.x) would help find changelogs and details easily.

Related to #1071


fix: fix EC issues in release 2.7

/retest

@mnecas @yaacov PTAL and merge if everything OK

@yaacov your requested change is failing the build:
[2/3] STEP 6/8: RUN GOOS=linux GOARCH=amd64 go build -ldflags="-w -s" -o virt-v2v-monitor github.com/konveyor/forklift-controller/cmd/virt-v2v-monitor/virt-v2v-monitor.go
cannot find module providing package github.com/konveyor/forklift-controller/cmd/virt-v2v-monitor/virt-v2v-monitor.go: import lookup disabled by -mod=vendor
subprocess exited with status 1
subprocess exited with status 1
Error: building at STEP "RUN GOOS=linux GOARCH=amd64 go build -ldflags="-w -s" -o virt-v2v-monitor github.com/konveyor/forklift-controller/cmd/virt-v2v-monitor/virt-v2v-monitor.go": exit status 1


WIP: add node logger code generation

Looking good @Torakushi. I think it works well for the RN framework as it written currently.
There is a bigger rework that needs to be made for the React Native library to really take advantage for this, which is to make it multi-instance compatible. The typescript client and native code have to manage a Breez SDK instance over the RN bridge, which probably means communicating with an additional instance ID and emitting from the native code to a specific instance handler.

Right, I was thinking about tha, the multi instance PR will be quite more complex indeed (unless you meant that it has to be done right know?)
Anyway, here are some solutions to dig maybe to make the RN app multi-instances friendly:

make "supportedEvent" dynamic, each time we call connect, we will add  a new event in the supportedEvent. (But quite unsure that we can do that way? if we can, it will be easier!

If we can't make supportedEvent dynamic, we create a BreezSDKLogListenerDispatcher, that will listen to breezSdkNodeLog and then dispatch it to the right node_logger using an ID like you suggested for example.

Right, I was thinking about tha, the multi instance PR will be quite more complex indeed (unless you meant that it has to be done right know?)

@Torakushi these are good ideas that Ross and you are adding but certainly not part of this PR.

Happy to keep the scope for this PR minimal to accompany your other PR. I don't think there is a huge use-case for multi-instances in RN, so we can think about it more broadly in a follow-up PR.


Fix discovery for AVR-X1600H

The upnp looks different for AVR-X1600H.
I have added a test to verify it for my model. Maybe we can add more tests for other devices.

Yes thank you @JPHutchins
The AVR-x-2016 uses a different URL, so it is nice to know it works for those receivers too.

@scarface-4711 looks good to me, could this be merged?
@JPHutchins, @MarBra is the Upnp for Heos speakers also:
"urn:schemas-denon-com:device:AiosDevice:1"?
Because I don't think that the denonavr integration works for Heos speakers, only for Denon and Marantz receivers that support Heos.
I do not want to wrongfully discover Heos speakers.....

@scarface-4711 looks good to me, could this be merged?
@JPHutchins, @MarBra is the Upnp for Heos speakers also:
"urn:schemas-denon-com:device:AiosDevice:1"?
Because I don't think that the denonavr integration works for Heos speakers, only for Denon and Marantz receivers that support Heos.
I do not want to wrongfully discover Heos speakers.....

Not sure, if it will also detect Heos speakers. I don't have one.
If you search for serialNumber in tests/xml/AVR-X1600H_upnp.xml you see that there are three "devices" with serialNumber tag. We can also use one of them to discover the device.
These deviceTypes are suitable:

urn:schemas-denon-com:device:AiosDevice:1
urn:schemas-denon-com:device:ACT-Denon:1
urn:schemas-upnp-org:device:MediaServer:1

I think urn:schemas-denon-com:device:ACT-Denon:1 would be better to avoid discovering HEOS speakers, but I think urn:schemas-denon-com:device:AiosDevice:1 would also be fine, we could always filter out Heos later if they cause problems

@starkillerOG I've chosen urn:schemas-upnp-org:device:MediaServer:1 now, because urn:schemas-denon-com:device:ACT-Denon:1 has a ACT prefix in friendlyName.
This could be easily changed, because we are looping over a deviceList, if one exists.