problem with LG

Hi, I'm wanting to use the plugin in a LG Q6 cell phone and when I open the camera I get the following error

How could I solve this problem?
Thanks!

Fixed: b24997c feel free to reopen :- update to 3.1.x


yubioath-desktop: prefix QML2_IMPORT_PATH

Otherwise, yubioath-desktop can't find pyothersides qml files:
QQmlApplicationEngine failed to load component
qrc:/qml/main.qml:168 Type YubiKey unavailable
qrc:/qml/YubiKey.qml:2 module "io.thp.pyotherside" is not installed
[1]    17017 segmentation fault  result/bin/yubioath-desktop
Motivation for this change
I wasn't able to run yubioath-desktop.
Things done

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] 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/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@samueldr , @ttuegel: If I got it right, qml file loading seems to be adressed in https://github.com/NixOS/nixpkgs/pull/54525 as well, but not in https://github.com/NixOS/nixpkgs/pull/44047, right?

Was this also a problem, when you install the application in your profile?

@Mic92 no, that only happened when building separately via nix-build, and then calling from the nix store. Still, I often use that to try out applications.
Could you backport this to 19.03 and 18.09 too?

backported to 19.03 in 50876481a01.
18.09 is still on 3.1.0, which seems to be much older (more Python and less QT, not using pyotherside at all) - so it's not affected.


Autocomplete window not opening on dot

I've been facing the same issue as #175, but none of my packages seem to be the cause. I disabled all of my packages except for GoSublime and still doesn't open an autocomplete window when typing the dot .. It does open with the hotkey ctrl+space. "auto_complete" in the ST3 settings is also set to true. What could be the cause here?

I'm experiencing the same issue, would be keen to hear if there is another configuration parameter for this.

+1

GoSublime doesn't trigger the autocomplete. If ctrl+space works and none of your other plugins are overriding auto_complete_triggers, it's probably a Sublime Text issue.


Supporting custom network strategy configuration

@FYJen
I'm not sure how to provide users with the ability to customize the network strategy configuration within this package. See "Configure Network Strategy" section here for reference.
Magic Admin PHP is set up to allow for customizing timeout, retries and backoff_factor by passing them as optional parameters when creating a Magic object. However when this package is in use the Magic object is instantiated automatically by the package, which means that the package would need to pass those values for the user.
But with how php default parameters work the package would either need to pass/override all 3 of those values, or pass none of them so that the default values will kick in. The problem is that there is no easy way to force the user to provide an override value for all 3 of those values.
For example what if a user only wanted to customize retries but doesn't care about timeout or backoff_factor? As far as I know in PHP you can't pass a subsequent argument without supplying the previous argument.
If this package could easily reference those default values that are defined as constants here then that would solve the problem by allowing the package to always supply a value for those optional parameters when an override is not given by the user.
Here is one potential solution that can be implemented within the register method here.
    public function register()
    {
        $this->app->singleton(Magic::class, function () {
            new Magic();  // causes Magic.php to run and those 3 constants to be defined

            return new Magic(
                config('magic.secret_api_key'),
                config('magic.network.timeout') ?? TIMEOUT,
                config('magic.network.retries') ?? RETRIES,
                config('magic.network.backoff_factor') ?? BACKOFF_FACTOR
            );
        });
    }

My only hesitation with this is that it feels hacky and would tightly couple this package to this file. If Magic Admin PHP ever changes how it handles these default values then this package will break. It seems like it would be best for Magic Admin PHP to be internally refactored so that those default values are accessible to the outside through an explicit interface.
The only other option I can think of is to simply copy those 3 default values into this package but then we have to maintain those default values in 2 separate places which is not ideal.

To me, one alternate solution is, providing options through .env file and updating our config/magic.php file to:
<?php

return [
    /*
     |--------------------------------------------------------------------------
     | Secret API Key
     |--------------------------------------------------------------------------
     |
     | Your API secret key retrieved from https://dashboard.magic.link
     |
     */

    'secret_api_key' => env('MAGIC_SECRET_API_KEY', null),

    /*
     |--------------------------------------------------------------------------
     | HTTP request strategy
     |--------------------------------------------------------------------------
     |
     | Customize your HTTP request strategy when making calls to the Magic API
     |
     */

    'http' => [
        'retries' => env('MAGIC_RETRIES', 3), // Total number of retries to allow

        'timeout' => env('MAGIC_TIMEOUT', 10), // A period of time the request is going to wait for a response

        'backoff_factor' => env('MAGIC_BACKOFF_FACTOR', 0.02), // A backoff factor to apply between retry attempts
    ],
];

What do you think of this method @brianrlewis?

@shahbaz17 I think your approach is an improvement. Thanks.


Fast touch up inside

Hi,
Thank you for BFPaperButton, it looks great)
Could you help me some issue I got..
I am using BFPaperButtons inside UITableVIewCell,
when I push It fast, it stops and begins again not from correct state,
so it look like duplicate animation, pls see the gif file I attached.
And one more queation - is it possible not to "pause" animation
when you hold the button, but let it finish straight away?
thank u.

Ok, as I read in other closed issue it could be so because of delayContentTouches in tableview..
setting it to NO. but the result is the same.
Also I have a single BFPaperButton on a simle view in other vc, and it is working like a charm.
Seems like I should find the solution to fix up tableView's delayscontenttouches..

Hi aekosyakov!
I'm not sure what is causing your issue but I would like to recommend that you use BFPaperTableViewCell as the superclass of your cells! BFPaperTableViewCell was designed specifically for use within UITableViews and addresses content delays as well. If possible, you may want to try that instead.


mc_att_control: don't generate attitude setpoint for tailsitters during transitions

This regression most likely comes from PR #10805
Without this, transitions in manual / stabilized mode are broken. The vehicle does not react to the transition command as the mc attitude controller controls an attitude setpoint which it generates by itself.
Tested in SITL.
This bug was found by @VTOLDavid
@VTOLDavid Can you test this and report back?
Signed-off-by: Roman<EMAIL_ADDRESS>

@dagar Should we determine the vtol vehicle type in commander and publish is as part of the vehicle status?

Now It makes the transition. That step in throttle at the begining of the transition can be tunned to be smother?
https://logs.px4.io/plot_app?log=066aace0-57cf-48de-9d65-a577f8993744

Hi, I just flight tested this pull request and seems that It tries to do the transition rolling or pitching indiferently.
https://logs.px4.io/plot_app?log=bf8fe26a-9984-4051-9a91-9a96e92d16a3

@VTOLDavid Thanks for testing! I'll have a look.


Update permissions.md

Ticket: https://secure.helpscout.net/conversation/2286383801/53474/
The customer was confused about  permissions for teams and pipelines. Its best to clarify about the order the precedence so they know the expected behaviour

I'm closing this PR as the changes will be made on another page


Move the use of VerifyType in tests

Those calls to duck.VerifyType are done at runtime and thus could be
costly at program startup. Putting them under tests ensure we still
assert those types but during unit testing.
This is part of #97 (not clusing it as there will be PRs on serving, eventing and build to follow :wink:
cc @dprotaso
Signed-off-by: Vincent Demeester<EMAIL_ADDRESS>

I think the point was we wanted them run at runtime to catch type mismatches? You could deploy code that never ran a unit test
What if they are called at runtime in the init block in a go func? So they would spin a thread up and not block

@n3wscott hum :thinking: right, but anything released should have ran the unit tests at some point (and unit tests are ran on any PR, …)… so I would think it is safe to not call those at runtime.

What if they are called at runtime in the init block in a go func? So they would spin a thread up and not block

That would work if we think it should be called at runtime yeah.

I think the point was we wanted them run at runtime to catch type mismatches? You could deploy code that never ran a unit test
What if they are called at runtime in the init block in a go func? So they would spin a thread up and not block

I'm not really concerned about the performance enough to warrant spinning up go-routines. Having these as tests should provide confidence that the concrete type satisfies the duct type. So you shouldn't need runtime checks.
For those deploying code without running unit tests whether duck typing is satisfied will be the least of their concerns.

So vendoring could lead to skew between the version tested and the version in use, so we'll need to be careful about how we version these.


Give implementor ability to chose value for strip_css

strip_css is hard coded to true here however that will strip out all CSS including media queries, which breaks the Mailchimp responsive templates.
Mailchimp defaults to false and even touts that there tool doesn't strip out media queries here.
Would be nice if this was updated as follows
function gulpInlineCSS(apikey, strip_css = false)

If we really wanted to strip out all CSS we could override when calling the task
inlineCss(config.MC_APIKEY, true)

I think it should be defaulted to false since that's the default behavior of the API.
I'd be happy to prepare a PR if you agree.
Otherwise, thanks for releasing this plugin. Very useful!

+1 I don't want media queries stripped out, this would be a easy solution.


depth_from_video_in_the_wild: Variables in motion_field_net not being reused properly

It appears that some of the variables in the motion_field_net from google-research/depth_from_video_in_the_wild/motion_prediction_net.py are not being reused when the the model is initialized for the forward and inverse ego-motion prediction.
When inspecting the variables  using
tf_path = os.path.abspath('kitti_learned_intrinsics/model-248900')
tf_vars = tf.train.list_variables(tf_path)
print(tf_vars)

and only considering variables in the scope 'MotionFieldNet'
there are four redundant name spaces:
('MotionFieldNet/compute_loss/MotionFieldNet/...
('MotionFieldNet/compute_loss/MotionFieldNet_1/...
('MotionFieldNet/compute_loss/MotionFieldNet_2/...
('MotionFieldNet/compute_loss/MotionFieldNet_3/...
However when I initialize the model and comment out the second call of motion_field_net (as in the following code block from google-research/google-research/depth_from_video_in_the_wild/model.py)
def _build_egomotion_test_graph(self):
    """Builds graph for inference of egomotion given two images."""
    with tf.variable_scope(tf.get_variable_scope(), reuse=tf.AUTO_REUSE):
      self._image1 = tf.placeholder(
          tf.float32, [self.batch_size, self.img_height, self.img_width, 3],
          name='image1')
      self._image2 = tf.placeholder(
          tf.float32, [self.batch_size, self.img_height, self.img_width, 3],
          name='image2')
      # The "compute_loss" scope is needed for the checkpoint to load properly.
      with tf.name_scope('compute_loss'):
        rot, trans, _, _ = motion_prediction_net.motion_field_net(
            images=tf.concat([self._image1, self._image2], axis=-1))
        """
        inv_rot, inv_trans, _, _ = (
            motion_prediction_net.motion_field_net(
                images=tf.concat([self._image2, self._image1], axis=-1)))
        """
        return

restoring from the kitti checkpoint and then re-saving yields only a set of variables under the name scope
('MotionFieldNet/compute_loss/MotionFieldNet/...
without the scopes having the _1, _2 & _3 suffixes, Indicating that these variables are being copied instead of reused. It is my understanding that all of the motion_field_net variables should be reused for the forward and inverse ego-motion prediction.

Here are the variables names from the KITTI checkpoint.
kitti_checkpoint_var_names.txt
And here are the variable names after using the modified code from the previous comment.
kitti_checkpoint_var_names_single_init.txt

Hi, I found the same issue as well. And I also believe reusing these variables is intended. Could you help to explain it? @gariel-google

Hi liyingliu@ and jenkspt@
I am sorry for the delayed response. Yes, there is a bug here
https://github.com/google-research/google-research/blob/master/depth_from_video_in_the_wild/motion_prediction_net.py#L244-L250
which causes some of the variables to not be reused. We fixed it since in
our internal version, but all the numbers we published in the paper were
obtained with that code, and the checkpoints we released are compatible
with that (buggy) code. If we fix the code now, the checkpoints we
published will not reproduce the numbers in the paper.
Perhaps we can publish the corrected version protected by a flag that will
be off by default? Would that help you guys?
On Sun, Apr 12, 2020 at 11:58 PM juju<EMAIL_ADDRESS>wrote:

Hi, I found the same issue as well. And I also believe reusing these
variables is intended. Could you help to explain it? @gariel-google
https://github.com/gariel-google
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/google-research/google-research/issues/230#issuecomment-612779372,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADXKUNDPRWFVJGWR3HVROBLRMKZ3BANCNFSM4LNXM3GQ
.

Thanks for the response! Yes this would be helpful.
I would hope reusing the variables properly would improve results and/or reduce training time. However there is always the chance that the bug is actually necessary to achieve the published results.

From what we tried, the results do reproduce with the fix, and are slightly
better in some cases, but we did not re-run systematically all
the experiments in the paper and we do not have checkpoints for all of
them. We will release the fixed code, hopefully over the next few days.
On Mon, Apr 13, 2020 at 12:52 PM Penn<EMAIL_ADDRESS>wrote:

Thanks for the response! Yes this would be helpful.
I would hope reusing the variables properly would improve results and/or
reduce training time. However there is always the chance that the bug is
actually necessary to achieve the published results.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/google-research/google-research/issues/230#issuecomment-613066046,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADXKUNHOWBSQFSUH4ZZY2EDRMNUPTANCNFSM4LNXM3GQ
.


Custom Date and List Filters

I need a couple of advanced filters where users would enter starting and ending date and all dates within this range would be filtered.
Another advanced filter I use is where user the data in the cells are list of strings. Cells are displayed if the selected value matches one of the values in each cell.
With react-bootstrap-table, I created custom React components to handle this. It seems that is not possible with react-bootstrap-table2. Will this feature be added soon?

@sudhirshakya it's not implemented yet.

@AllenFang Is there any way to disable the weekends in the calendar

@AllenFang I created a work around where i filter the source by the date range which works perfectly. This is still an amazing library and really enjoy using it thank you!

@sgwcollins Hi sgwcollins, could you give some hints on how to filter by date range? Thanks in advance!

Hi @sgwcollins, please give some hints to implement filter by date range.

Hi @sgwcollins, please give some hints to implement filter by date range.


181891254 rollup svg import

Moves imported svgs into the quantity-node so they no longer need to be imported.

As a follow up on this. I tried using the SVGR rollup plugin. However it fails with not very useful error.
[!] Error: Unexpected token (Note that you need plugins to import files that are not JavaScript)
../src/assets/edit.svg (1:0)

My hunch is that it is related to this issue:
https://github.com/gregberge/svgr/issues/679#issuecomment-1061071611
The error message shows a relative path, so if the svgr plugin doesn't handle those, then that would explain this.
My guess is that the relative path happens because the rollup config is setting the input to be a relative parent folder. I tried setting this to be an absolute path, but that didn't help. I also tried moving the svgs around so they were in the same folder as the component using them, that didn't help either.
Because rollup doesn't have verbose logging it is hard to know if I'm on the right track or not. I'm thinking at this point I'd try switching to webpack, we use it to build other libraries so it should be doable.
But I'll try one more thing first: I'll add an svg and the svgr plugin to slate-editor because its rollup config doesn't refer to a parent folder for the input.
https://react-svgr.com/docs/rollup

I'm thinking at this point I'd try switching to webpack, we use it to build other libraries so it should be doable.

FYI: you'll probably have to give up the bundling of types.

Looking at what we do in the lara-typescript, we just rollup to bundle the types. So we could take that same approach. That way we get the same build configuration, and we get bundled types.
Because this is going to take more work, @eireland I now think your approach in this PR is the right one for now.  I'm going try it out locally and merge if it works.


I can create notification with the interface, but default style is applied to the component

I don't know what is missing ....
in script tag I have:
this.$notify({             group: 'foo-css',             title: '<b>Important message</b>',             text: e.data,             type: 'warn'           });
in template Vue I have
<notifications group="foo-css"                     position="top center"                     classes="n-light"                      :width="400"/>

@XiayidanAlimu see this might be helpful
https://github.com/euvl/vue-notification/issues/171#issuecomment-634933154


Voting no breaks plugin

Supposedly voting no breaks the plugin, not sure how but need additional documentation/steps for reproduction

Supposedly this seems to work fine in local testing but it is an issue on RetroMC

Seems to be caused by the way votes are calculated. Solution is to restrict vote calculations to yes/no only and not count abstaining players


asString/abstract class work

TODO
test optional asString
default asString impl
asString on empty concrete and abstract class
empty properties on empty abstract class

Moved into #308


Panic on initialization related to tokio timer

MacOS version 10.14.6
$ rustc -V
rustc 1.39.0 (4560ea788 2019-11-04)

This is using the alpha version 0.13.0-alpha.4 so definitely understaning of errors. My full code can be found here: https://github.com/cloudflare/wrangler/pull/882/files
I'm getting this stack trace and it's probably the case that I'm doing something wrong but my assumption is that this should be a compiler error rather than a runtime error - the timer stuff seems to be under hyper's hood. Let me know if y'all need more info!
$ RUST_BACKTRACE=full  wrangler proxy
Listening on http://localhost:8000
[2019-11-18T19:57:53Z ERROR hyper::server::tcp] accept error: no current reactor
thread 'main' panicked at 'timer error: timer is shutdown', /Users/averyharnish/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-timer-0.3.0-alpha.6/src/delay.rs:119:23
stack backtrace:
   0:        0x10ead3c05 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::heacebe1ed3e94ea0
   1:        0x10eafb3f0 - core::fmt::write::h8638ece1f1f1e4d6
   2:        0x10eacc69b - std::io::Write::write_fmt::he2c24b24a8e9b7c7
   3:        0x10ead60d3 - std::panicking::default_hook::{{closure}}::ha77d5a7055757c52
   4:        0x10ead5dda - std::panicking::default_hook::hd4612bd6164910bb
   5:        0x10ead679b - std::panicking::rust_panic_with_hook::h2df95ade3be7924d
   6:        0x10ead6329 - std::panicking::continue_panic_fmt::hd67e809aaf4bcccd
   7:        0x10eb122bf - std::panicking::begin_panic_fmt::h077b408a90ae88a4
   8:        0x10de17ea9 - <tokio_timer::delay::Delay as core::future::future::Future>::poll::h3d5b52d9f1751bf9
   9:        0x10dd4d279 - hyper::server::tcp::AddrIncoming::poll_next_::h764f724d81318586
  10:        0x10dd4d7ea - <hyper::server::tcp::AddrIncoming as hyper::server::accept::Accept>::poll_accept::h35db97ae1411bd60
  11:        0x10d66fc06 - hyper::server::conn::Serve<I,S,E>::poll_next_::h3ba9b96abf583fc8
  12:        0x10d66ffc4 - hyper::server::conn::SpawnAll<I,S,E>::poll_watch::hbd6b23938904b859
  13:        0x10d6b256f - <hyper::server::Server<I,S,E> as core::future::future::Future>::poll::h92cd2dc5879f253d
  14:        0x10d67a086 - std::future::poll_with_tls_context::hc65e2d399d658b82
  15:        0x10d665c9a - wrangler::commands::preview::proxy::proxy::{{closure}}::h85fe6b34c6f11864
  16:        0x10d67a379 - <std::future::GenFuture<T> as core::future::future::Future>::poll::h5f4fcf655d767bfc
  17:        0x10d6b2217 - futures_executor::local_pool::block_on::{{closure}}::h10b9d00ae345e118
  18:        0x10d6b2089 - futures_executor::local_pool::run_executor::{{closure}}::ha245081c6b309da9
  19:        0x10d6ccd01 - std::thread::local::LocalKey<T>::try_with::hae1e85fc15148503
  20:        0x10d6ccae1 - std::thread::local::LocalKey<T>::with::h920cb05eae0473a1
  21:        0x10d6b1fd9 - futures_executor::local_pool::run_executor::he53175d7eb1e9d51
  22:        0x10d6b2161 - futures_executor::local_pool::block_on::hb6427b2efa633356
  23:        0x10d6c48a1 - wrangler::run::h2be2ef01c3182a77
  24:        0x10d6bdfec - wrangler::main::hc20c11e448718aad
  25:        0x10d6b14e2 - std::rt::lang_start::{{closure}}::hbf566e56c1c797ee
  26:        0x10ead61f8 - std::panicking::try::do_call::hebc26a6b701bb8e5
  27:        0x10eae012f - __rust_maybe_catch_panic
  28:        0x10ead6bee - std::rt::lang_start_internal::hff117e6b3eab52ac
  29:        0x10d6b14c2 - std::rt::lang_start::hfd21e56996b171cb
  30:        0x10d6cc392 - main

Is the server being executed in a tokio runtime? I noticed a futures_executor::block_on, which won't have an IO driver or timer setup.

ah, no! I'm very new to how this all works. I'm trying to call this from clap as its own subcommand - is it possible to have a tokio runtime for a small subset of a Rust program? I don't want my entire app to be tokio

Sure, you can make a runtime object whenever you want. https://docs.rs/tokio/0.2.0-alpha.6/tokio/runtime/struct.Runtime.html

oh sick. got it to work :) thanks a bajillion

If y'all are interested, I'd love to see if I could help to give a better error message when there's no tokio runtime.

Issue for improving those panic messages: https://github.com/tokio-rs/tokio/issues/1713

great :) https://github.com/tokio-rs/tokio/pull/1789


Step 3 Port test

To what destination endpoints do we test ports 443 and 80? Or is there a utility available that we can use to verify connectivity to the correct endpoints?
[Enter feedback here]

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

ID: 057be820-930e-4a15-fad0-3466f6cb0b13
Version Independent ID: 4f34c185-0f69-28cf-0292-b721b36514c3
Content: Debug Application Proxy connectors - Azure Active Directory
Content Source: articles/active-directory/manage-apps/application-proxy-debug-connectors.md
Service: active-directory
Sub-service: app-mgmt
GitHub Login: @kenwith
Microsoft Alias: kenwith

@LioDiera Thank you for your feedback . We will investigate and update the thread.

@LioDiera The step 3 actually tests outbound connectivity to the following URLs as listed in the prerequisite page for setting up app proxy in your environment .

URL
How it's used

*.msappproxy.net*.servicebus.windows.net
Communication between the connector and the Application Proxy cloud service

mscrl.microsoft.com:80crl.microsoft.com:80ocsp.msocsp.com:80www.microsoft.com:80
The connector uses these URLs to verify certificates.

login.windows.netsecure.aadcdn.microsoftonline-p.com*.microsoftonline.com*.microsoftonline-p.com*.msauth.net*.msauthimages.net*.msecnd.net*.msftauth.net*.msftauthimages.net*.phonefactor.netenterpriseregistration.windows.netmanagement.azure.compolicykeyservice.dc.ad.msft.netctdl.windowsupdate.com:80
The connector uses these URLs during the registration process.

You can allow connections to *.msappproxy.net and *.servicebus.windows.net if your firewall or proxy lets you configure DNS allow lists. If not, you need to allow access to the Azure IP ranges and Service Tags - Public Cloud. The IP ranges are updated each week.
I hope the above explains the same. The outbound endpoints are the ones which App proxy will use for proper operation. Outbound port 80 is needed for Downloading certificate revocation lists (CRLs) while validating the TLS/SSL certificate and outbound 443 is needed for all outbound traffic to the app proxy service in the cloud.
I have added a link to the step 3 or referring to Port section which describes the URL list as well. Hope this clarifies your point . We will now close this issue.


Fixes for display mainly in Fr

a few translation fixes
Utilities: fix the display of french "Enable logging" was broken on small screens (480x800)
many fixes (mainly in fr) for display menus on small screens(480x800)
ja/fr/en: fix connection timeout is for server and not client

Some menus could not be read in both portrait and landscape orientation mainly on 480x800 display, but also on 1080x1920 for one or two in french
The Enable Logging menu was completely broken on 480x800 because of the too long button
All menus in Eng and Fr are perfectly fitting and readable now

Broken menus were cut by displaying "Something to Say about the Scr..." and we cannot read the menu text end
The worst was this one:
Before:

After changes:


Fix bug with the --topic flag.

I fixed the error mentioned in issue #102
Also I noticed your contributing.md has a place where you need to put in your email address :)
Cheers,
Ed

@allcontributors please add @davised for code


[Win10] Compilation fails for 8.4.2 version

Microsoft Windows [Version 10.0.16299.371]
HIE at 97f67d4
Running stack build --copy-compiler-tool results in failure with following output:
ghc-mod-core-<IP_ADDRESS>: build (lib)
ghc-exactprint-<IP_ADDRESS>: configure
ghc-exactprint-<IP_ADDRESS>: build
Progress 2/8

--  While building custom Setup.hs for package ghc-exactprint-<IP_ADDRESS> using:
      C:\sr\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_<IP_ADDRESS>_ghc-8.4.2.exe --builddir=.stack-work\dist\7d103d30 build --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always"
    Process exited with code: ExitFailure 1
    Logs have been written to: C:\Users\Anrock\projects\haskell-ide-engine\.stack-work\logs\ghc-exactprint-<IP_ADDRESS>.log

    Configuring ghc-exactprint-<IP_ADDRESS>...
    Warning: The package has an extraneous version range for a dependency on an
    internal library: ghc-exactprint >=0.5.4. This version range includes the
    current package but isn't needed as the current package's library will always
    be used.
    Warning:
        This package indirectly depends on multiple versions of the same package. This is very likely to cause a compile failure.
          package time (time-<IP_ADDRESS>-D1fwd9ZaD3eDd2StmPCsSC) requires Win32-<IP_ADDRESS>-LVNqK0SwW285hUwHpPOkae
          package directory (directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1) requires Win32-<IP_ADDRESS>-LVNqK0SwW285hUwHpPOkae
          package time (time-<IP_ADDRESS>) requires Win32-<IP_ADDRESS>
          package process (process-<IP_ADDRESS>) requires Win32-<IP_ADDRESS>
          package ghc (ghc-8.4.2) requires Win32-<IP_ADDRESS>
          package directory (directory-<IP_ADDRESS>) requires Win32-<IP_ADDRESS>
          package process (process-<IP_ADDRESS>) requires directory-<IP_ADDRESS>
          package hpc (hpc-<IP_ADDRESS>) requires directory-<IP_ADDRESS>
          package ghc-boot (ghc-boot-8.4.2) requires directory-<IP_ADDRESS>
          package ghc (ghc-8.4.2) requires directory-<IP_ADDRESS>
          package ghc-exactprint (ghc-exactprint-<IP_ADDRESS>) requires directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1
          package ghc-boot (ghc-boot-8.4.2-IjXXYP7XIDA1Af0Wr3EqUE) requires directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1
          package ghci (ghci-8.4.2) requires ghc-boot-8.4.2
          package ghc (ghc-8.4.2) requires ghc-boot-8.4.2
          package ghc-exactprint (ghc-exactprint-<IP_ADDRESS>) requires ghc-boot-8.4.2-IjXXYP7XIDA1Af0Wr3EqUE
          package hpc (hpc-<IP_ADDRESS>) requires time-<IP_ADDRESS>
          package ghc (ghc-8.4.2) requires time-<IP_ADDRESS>
          package directory (directory-<IP_ADDRESS>) requires time-<IP_ADDRESS>
          package directory (directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1) requires time-<IP_ADDRESS>-D1fwd9ZaD3eDd2StmPCsSC
    Preprocessing library for ghc-exactprint-<IP_ADDRESS>..
    Building library for ghc-exactprint-<IP_ADDRESS>..
    [ 1 of 13] Compiling Language.Haskell.GHC.ExactPrint.Types ( src\Language\Haskell\GHC\ExactPrint\Types.hs, .stack-work\dist\7d103d30\build\Language\Haskell\GHC\ExactPrint\Types.o )
    [ 2 of 13] Compiling Language.Haskell.GHC.ExactPrint.Lookup ( src\Language\Haskell\GHC\ExactPrint\Lookup.hs, .stack-work\dist\7d103d30\build\Language\Haskell\GHC\ExactPrint\Lookup.o )
    [ 3 of 13] Compiling Language.Haskell.GHC.ExactPrint.AnnotateTypes ( src\Language\Haskell\GHC\ExactPrint\AnnotateTypes.hs, .stack-work\dist\7d103d30\build\Language\Haskell\GHC\ExactPrint\AnnotateTypes.o )
    GHC runtime linker: fatal error: I found a duplicate definition for symbol
       rgb
    whilst processing object file
       C:\Users\Anrock\AppData\Local\Programs\stack\x86_64-windows\ghc-8.4.2\lib\Win32-<IP_ADDRESS>\HSWin32-<IP_ADDRESS>.o
    The symbol was previously defined in
       C:\sr\snapshots\03fa9465\lib\x86_64-windows-ghc-8.4.2\Win32-<IP_ADDRESS>-LVNqK0SwW285hUwHpPOkae\HSWin32-<IP_ADDRESS>-LVNqK0SwW285hUwHpPOkae.o
    This could be caused by:
       * Loading two different object files which export the same symbol
       * Specifying the same object file twice on the GHCi command line
       * An incorrect `package.conf' entry, causing some object to be
         loaded twice.
    ghc.EXE: panic! (the 'impossible' happened)
      (GHC version 8.4.2 for x86_64-unknown-mingw32):
        loadObj "C:\\Users\\Anrock\\AppData\\Local\\Programs\\stack\\x86_64-windows\\ghc-8.4.2\\lib\\Win32-<IP_ADDRESS>\\HSWin32-<IP_ADDRESS>.o": failed

    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

--  While building custom Setup.hs for package ghc-mod-core-<IP_ADDRESS> using:
      C:\sr\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_<IP_ADDRESS>_ghc-8.4.2.exe --builddir=.stack-work\dist\7d103d30 build lib:ghc-mod-core --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always"
    Process exited with code: ExitFailure 1
    Logs have been written to: C:\Users\Anrock\projects\haskell-ide-engine\.stack-work\logs\ghc-mod-core-<IP_ADDRESS>.log

    Preprocessing library for ghc-mod-core-<IP_ADDRESS>..
    Building library for ghc-mod-core-<IP_ADDRESS>..
    [10 of 45] Compiling GhcMod.Types     ( GhcMod\Types.hs, .stack-work\dist\7d103d30\build\GhcMod\Types.o )
    GHC runtime linker: fatal error: I found a duplicate definition for symbol
       rgb
    whilst processing object file
       C:\Users\Anrock\AppData\Local\Programs\stack\x86_64-windows\ghc-8.4.2\lib\Win32-<IP_ADDRESS>\HSWin32-<IP_ADDRESS>.o
    The symbol was previously defined in
       C:\sr\snapshots\03fa9465\lib\x86_64-windows-ghc-8.4.2\Win32-<IP_ADDRESS>-LVNqK0SwW285hUwHpPOkae\HSWin32-<IP_ADDRESS>-LVNqK0SwW285hUwHpPOkae.o
    This could be caused by:
       * Loading two different object files which export the same symbol
       * Specifying the same object file twice on the GHCi command line
       * An incorrect `package.conf' entry, causing some object to be
         loaded twice.
    ghc.EXE: panic! (the 'impossible' happened)
      (GHC version 8.4.2 for x86_64-unknown-mingw32):
        loadObj "C:\\Users\\Anrock\\AppData\\Local\\Programs\\stack\\x86_64-windows\\ghc-8.4.2\\lib\\Win32-<IP_ADDRESS>\\HSWin32-<IP_ADDRESS>.o": failed

    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

@alanz should i move this issue to alanz/ghc-exactprint?

@alanz stack build fails too, although messages a little different now:
ghc-mod-core-<IP_ADDRESS>: configure (lib)
ghc-mod-core-<IP_ADDRESS>: build (lib)
ghc-exactprint-<IP_ADDRESS>: configure
ghc-exactprint-<IP_ADDRESS>: build
Progress 2/8

--  While building custom Setup.hs for package ghc-exactprint-<IP_ADDRESS> using:
      C:\sr\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_<IP_ADDRESS>_ghc-8.4.2.exe --builddir=.stack-work\dist\7d103d30 build --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always"
    Process exited with code: ExitFailure 1
    Logs have been written to: C:\Users\Anrock\projects\haskell-ide-engine\.stack-work\logs\ghc-exactprint-<IP_ADDRESS>.log

    Configuring ghc-exactprint-<IP_ADDRESS>...
    Warning: The package has an extraneous version range for a dependency on an
    internal library: ghc-exactprint >=0.5.4. This version range includes the
    current package but isn't needed as the current package's library will always
    be used.
    Warning:
        This package indirectly depends on multiple versions of the same package. This is very likely to cause a compile failure.
          package time (time-<IP_ADDRESS>-D1fwd9ZaD3eDd2StmPCsSC) requires Win32-<IP_ADDRESS>-LVNqK0SwW285hUwHpPOkae
          package directory (directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1) requires Win32-<IP_ADDRESS>-LVNqK0SwW285hUwHpPOkae
          package time (time-<IP_ADDRESS>) requires Win32-<IP_ADDRESS>
          package process (process-<IP_ADDRESS>) requires Win32-<IP_ADDRESS>
          package ghc (ghc-8.4.2) requires Win32-<IP_ADDRESS>
          package directory (directory-<IP_ADDRESS>) requires Win32-<IP_ADDRESS>
          package process (process-<IP_ADDRESS>) requires directory-<IP_ADDRESS>
          package hpc (hpc-<IP_ADDRESS>) requires directory-<IP_ADDRESS>
          package ghc-boot (ghc-boot-8.4.2) requires directory-<IP_ADDRESS>
          package ghc (ghc-8.4.2) requires directory-<IP_ADDRESS>
          package ghc-exactprint (ghc-exactprint-<IP_ADDRESS>) requires directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1
          package ghc-boot (ghc-boot-8.4.2-IjXXYP7XIDA1Af0Wr3EqUE) requires directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1
          package ghci (ghci-8.4.2) requires ghc-boot-8.4.2
          package ghc (ghc-8.4.2) requires ghc-boot-8.4.2
          package ghc-exactprint (ghc-exactprint-<IP_ADDRESS>) requires ghc-boot-8.4.2-IjXXYP7XIDA1Af0Wr3EqUE
          package hpc (hpc-<IP_ADDRESS>) requires time-<IP_ADDRESS>
          package ghc (ghc-8.4.2) requires time-<IP_ADDRESS>
          package directory (directory-<IP_ADDRESS>) requires time-<IP_ADDRESS>
          package directory (directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1) requires time-<IP_ADDRESS>-D1fwd9ZaD3eDd2StmPCsSC
    Preprocessing library for ghc-exactprint-<IP_ADDRESS>..
    Building library for ghc-exactprint-<IP_ADDRESS>..
    [ 1 of 13] Compiling Language.Haskell.GHC.ExactPrint.Types ( src\Language\Haskell\GHC\ExactPrint\Types.hs, .stack-work\dist\7d103d30\build\Language\Haskell\GHC\ExactPrint\Types.o )
    [ 2 of 13] Compiling Language.Haskell.GHC.ExactPrint.Lookup ( src\Language\Haskell\GHC\ExactPrint\Lookup.hs, .stack-work\dist\7d103d30\build\Language\Haskell\GHC\ExactPrint\Lookup.o )
    [ 3 of 13] Compiling Language.Haskell.GHC.ExactPrint.AnnotateTypes ( src\Language\Haskell\GHC\ExactPrint\AnnotateTypes.hs, .stack-work\dist\7d103d30\build\Language\Haskell\GHC\ExactPrint\AnnotateTypes.o )
    GHC runtime linker: fatal error: I found a duplicate definition for symbol
       rgb
    whilst processing object file
       C:\Users\Anrock\AppData\Local\Programs\stack\x86_64-windows\ghc-8.4.2\lib\Win32-<IP_ADDRESS>\HSWin32-<IP_ADDRESS>.o
    The symbol was previously defined in
       C:\sr\snapshots\03fa9465\lib\x86_64-windows-ghc-8.4.2\Win32-<IP_ADDRESS>-LVNqK0SwW285hUwHpPOkae\HSWin32-<IP_ADDRESS>-LVNqK0SwW285hUwHpPOkae.o
    This could be caused by:
       * Loading two different object files which export the same symbol
       * Specifying the same object file twice on the GHCi command line
       * An incorrect `package.conf' entry, causing some object to be
         loaded twice.
    ghc.EXE: panic! (the 'impossible' happened)
      (GHC version 8.4.2 for x86_64-unknown-mingw32):
        loadObj "C:\\Users\\Anrock\\AppData\\Local\\Programs\\stack\\x86_64-windows\\ghc-8.4.2\\lib\\Win32-<IP_ADDRESS>\\HSWin32-<IP_ADDRESS>.o": failed

    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

--  While building custom Setup.hs for package ghc-mod-core-<IP_ADDRESS> using:
      C:\sr\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_<IP_ADDRESS>_ghc-8.4.2.exe --builddir=.stack-work\dist\7d103d30 build lib:ghc-mod-core --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always"
    Process exited with code: ExitFailure 1
    Logs have been written to: C:\Users\Anrock\projects\haskell-ide-engine\.stack-work\logs\ghc-mod-core-<IP_ADDRESS>.log

    Configuring ghc-mod-core-<IP_ADDRESS>...
    Warning:
        This package indirectly depends on multiple versions of the same package. This is very likely to cause a compile failure.
          package unix-compat (unix-compat-<IP_ADDRESS>-ALLPuaD7J24dL9b6NTbA5) requires Win32-<IP_ADDRESS>-LVNqK0SwW285hUwHpPOkae
          package time (time-<IP_ADDRESS>-D1fwd9ZaD3eDd2StmPCsSC) requires Win32-<IP_ADDRESS>-LVNqK0SwW285hUwHpPOkae
          package process (process-<IP_ADDRESS>-FMzG7P7MVAn6mqfwmNuxPP) requires Win32-<IP_ADDRESS>-LVNqK0SwW285hUwHpPOkae
          package directory (directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1) requires Win32-<IP_ADDRESS>-LVNqK0SwW285hUwHpPOkae
          package ansi-terminal (ansi-terminal-<IP_ADDRESS>-AQwelgnwMTFGc4jiARIgzm) requires Win32-<IP_ADDRESS>-LVNqK0SwW285hUwHpPOkae
          package Cabal (Cabal-<IP_ADDRESS>-FeOI90Zvmr7AkYuby89JJ) requires Win32-<IP_ADDRESS>-LVNqK0SwW285hUwHpPOkae
          package time (time-<IP_ADDRESS>) requires Win32-<IP_ADDRESS>
          package process (process-<IP_ADDRESS>) requires Win32-<IP_ADDRESS>
          package ghc (ghc-8.4.2) requires Win32-<IP_ADDRESS>
          package directory (directory-<IP_ADDRESS>) requires Win32-<IP_ADDRESS>
          package process (process-<IP_ADDRESS>) requires directory-<IP_ADDRESS>
          package hpc (hpc-<IP_ADDRESS>) requires directory-<IP_ADDRESS>
          package ghc-boot (ghc-boot-8.4.2) requires directory-<IP_ADDRESS>
          package ghc (ghc-8.4.2) requires directory-<IP_ADDRESS>
          package unix-compat (unix-compat-<IP_ADDRESS>-ALLPuaD7J24dL9b6NTbA5) requires directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1
          package temporary (temporary-<IP_ADDRESS>-8f2WBQRkfsZ9IwRyqpPINq) requires directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1
          package process (process-<IP_ADDRESS>-FMzG7P7MVAn6mqfwmNuxPP) requires directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1
          package ghc-mod-core (ghc-mod-core-<IP_ADDRESS>) requires directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1
          package ghc-boot (ghc-boot-8.4.2-IjXXYP7XIDA1Af0Wr3EqUE) requires directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1
          package extra (extra-1.6.6-E23jajM052SDJ4GgmArFUp) requires directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1
          package cpphs (cpphs-1.20.8-JKmr2FfpPiI6VediyrxNsH) requires directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1
          package cabal-helper (cabal-helper-<IP_ADDRESS>-1xg5DxHt7TJ8aF98p8nk0A) requires directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1
          package Cabal (Cabal-<IP_ADDRESS>-FeOI90Zvmr7AkYuby89JJ) requires directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1
          package ghci (ghci-8.4.2) requires ghc-boot-8.4.2
          package ghc (ghc-8.4.2) requires ghc-boot-8.4.2
          package ghc-mod-core (ghc-mod-core-<IP_ADDRESS>) requires ghc-boot-8.4.2-IjXXYP7XIDA1Af0Wr3EqUE
          package ghc (ghc-8.4.2) requires process-<IP_ADDRESS>
          package optparse-applicative (optparse-applicative-<IP_ADDRESS>-2cLHts4ddm62O3ilVqxDVF) requires process-<IP_ADDRESS>-FMzG7P7MVAn6mqfwmNuxPP
          package ghc-mod-core (ghc-mod-core-<IP_ADDRESS>) requires process-<IP_ADDRESS>-FMzG7P7MVAn6mqfwmNuxPP
          package extra (extra-1.6.6-E23jajM052SDJ4GgmArFUp) requires process-<IP_ADDRESS>-FMzG7P7MVAn6mqfwmNuxPP
          package cabal-helper (cabal-helper-<IP_ADDRESS>-1xg5DxHt7TJ8aF98p8nk0A) requires process-<IP_ADDRESS>-FMzG7P7MVAn6mqfwmNuxPP
          package Cabal (Cabal-<IP_ADDRESS>-FeOI90Zvmr7AkYuby89JJ) requires process-<IP_ADDRESS>-FMzG7P7MVAn6mqfwmNuxPP
          package hpc (hpc-<IP_ADDRESS>) requires time-<IP_ADDRESS>
          package ghc (ghc-8.4.2) requires time-<IP_ADDRESS>
          package directory (directory-<IP_ADDRESS>) requires time-<IP_ADDRESS>
          package unix-compat (unix-compat-<IP_ADDRESS>-ALLPuaD7J24dL9b6NTbA5) requires time-<IP_ADDRESS>-D1fwd9ZaD3eDd2StmPCsSC
          package ghc-mod-core (ghc-mod-core-<IP_ADDRESS>) requires time-<IP_ADDRESS>-D1fwd9ZaD3eDd2StmPCsSC
          package extra (extra-1.6.6-E23jajM052SDJ4GgmArFUp) requires time-<IP_ADDRESS>-D1fwd9ZaD3eDd2StmPCsSC
          package directory (directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1) requires time-<IP_ADDRESS>-D1fwd9ZaD3eDd2StmPCsSC
          package Cabal (Cabal-<IP_ADDRESS>-FeOI90Zvmr7AkYuby89JJ) requires time-<IP_ADDRESS>-D1fwd9ZaD3eDd2StmPCsSC
    Preprocessing library for ghc-mod-core-<IP_ADDRESS>..
    Building library for ghc-mod-core-<IP_ADDRESS>..
    [ 8 of 45] Compiling GhcMod.DynFlagsTH ( GhcMod\DynFlagsTH.hs, .stack-work\dist\7d103d30\build\GhcMod\DynFlagsTH.o )

    GhcMod\DynFlagsTH.hs:26:1: warning: [-Wunused-imports]
        The import of `GHC.LanguageExtensions' is redundant
          except perhaps to import instances from `GHC.LanguageExtensions'
        To import instances alone, use: import GHC.LanguageExtensions()
       |
    26 | import GHC.LanguageExtensions
       | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    GhcMod\DynFlagsTH.hs:209:1: warning: [-Wmissing-signatures]
        Top-level binding with no type signature:
          toSet :: (Ord a, Enum a) => E.EnumSet a -> IS.Set a
        |
    209 | toSet es = IS.fromList $ E.toList es
        | ^^^^^

    GhcMod\DynFlagsTH.hs:211:1: warning: [-Worphans]
        Orphan instance: instance Ord GeneralFlag
        To avoid this
            move the instance declaration to the module of the class or of the type, or
            wrap the type with a newtype and declare the instance on the new type.
        |
    211 | deriving instance Ord GeneralFlag
        | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    GhcMod\DynFlagsTH.hs:212:1: warning: [-Worphans]
        Orphan instance: instance Ord WarningFlag
        To avoid this
            move the instance declaration to the module of the class or of the type, or
            wrap the type with a newtype and declare the instance on the new type.
        |
    212 | deriving instance Ord DynFlags.WarningFlag
        | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    GhcMod\DynFlagsTH.hs:213:1: warning: [-Worphans]
        Orphan instance: instance Ord DumpFlag
        To avoid this
            move the instance declaration to the module of the class or of the type, or
            wrap the type with a newtype and declare the instance on the new type.
        |
    213 | deriving instance Ord DynFlags.DumpFlag
        | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    GhcMod\DynFlagsTH.hs:214:1: warning: [-Worphans]
        Orphan instance: instance Ord LlvmTarget
        To avoid this
            move the instance declaration to the module of the class or of the type, or
            wrap the type with a newtype and declare the instance on the new type.
        |
    214 | deriving instance Ord DynFlags.LlvmTarget
        | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    GhcMod\DynFlagsTH.hs:215:1: warning: [-Worphans]
        Orphan instance: instance Ord Extension
        To avoid this
            move the instance declaration to the module of the class or of the type, or
            wrap the type with a newtype and declare the instance on the new type.
        |
    215 | deriving instance Ord Extension
        | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    GhcMod\DynFlagsTH.hs:216:1: warning: [-Worphans]
        Orphan instance: instance Eq LlvmTarget
        To avoid this
            move the instance declaration to the module of the class or of the type, or
            wrap the type with a newtype and declare the instance on the new type.
        |
    216 | deriving instance Eq LlvmTarget
        | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    [ 9 of 45] Compiling GhcMod.Options.Help ( GhcMod\Options\Help.hs, .stack-work\dist\7d103d30\build\GhcMod\Options\Help.o )
    [10 of 45] Compiling GhcMod.Types     ( GhcMod\Types.hs, .stack-work\dist\7d103d30\build\GhcMod\Types.o )
    GHC runtime linker: fatal error: I found a duplicate definition for symbol
       rgb
    whilst processing object file
       C:\Users\Anrock\AppData\Local\Programs\stack\x86_64-windows\ghc-8.4.2\lib\Win32-<IP_ADDRESS>\HSWin32-<IP_ADDRESS>.o
    The symbol was previously defined in
       C:\sr\snapshots\03fa9465\lib\x86_64-windows-ghc-8.4.2\Win32-<IP_ADDRESS>-LVNqK0SwW285hUwHpPOkae\HSWin32-<IP_ADDRESS>-LVNqK0SwW285hUwHpPOkae.o
    This could be caused by:
       * Loading two different object files which export the same symbol
       * Specifying the same object file twice on the GHCi command line
       * An incorrect `package.conf' entry, causing some object to be
         loaded twice.
    ghc.EXE: panic! (the 'impossible' happened)
      (GHC version 8.4.2 for x86_64-unknown-mingw32):
        loadObj "C:\\Users\\Anrock\\AppData\\Local\\Programs\\stack\\x86_64-windows\\ghc-8.4.2\\lib\\Win32-<IP_ADDRESS>\\HSWin32-<IP_ADDRESS>.o": failed

    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

Probably related: https://ghc.haskell.org/trac/ghc/ticket/11748

sigh...
I'm hitting this too, I think. I'm too new to Haskell to know for sure.
PS C:\projects\personal\haskell-ide-engine> stack build
No packages found in snapshot which provide a "cabal" executable, which is a build-tool dependency of "cabal-helper"
ghc-mod-core-<IP_ADDRESS>: configure (lib)
haskell-src-exts-util-0.2.2: download
haskell-lsp-types-<IP_ADDRESS>: download
haskell-src-exts-util-0.2.2: configure
ghc-mod-core-<IP_ADDRESS>: build (lib)
haskell-src-exts-util-0.2.2: build
haskell-lsp-types-<IP_ADDRESS>: configure
haskell-lsp-types-<IP_ADDRESS>: build
haskell-src-exts-util-0.2.2: copy/register
hlint-2.1.3: download
ghc-exactprint-<IP_ADDRESS>: configure
ghc-exactprint-<IP_ADDRESS>: build
hlint-2.1.3: configure
hlint-2.1.3: build
hlint-2.1.3: copy/register
haskell-lsp-types-<IP_ADDRESS>: copy/register
Progress 5/13

--  While building custom Setup.hs for package ghc-exactprint-<IP_ADDRESS> using:
      C:\sr\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_<IP_ADDRESS>_ghc-8.4.2.exe --builddir=.stack-work\dist\7d103d30 build --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always"
    Process exited with code: ExitFailure 1
    Logs have been written to: C:\projects\personal\haskell-ide-engine\.stack-work\logs\ghc-exactprint-<IP_ADDRESS>.log

    Configuring ghc-exactprint-<IP_ADDRESS>...
    Warning: The package has an extraneous version range for a dependency on an
    internal library: ghc-exactprint >=0.5.4. This version range includes the
    current package but isn't needed as the current package's library will always
    be used.
    Warning:
        This package indirectly depends on multiple versions of the same package. This is very likely to cause a compile failure.
          package time (time-<IP_ADDRESS>-D1fwd9ZaD3eDd2StmPCsSC) requires Win32-<IP_ADDRESS>-LVNqK0SwW285hUwHpPOkae
          package directory (directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1) requires Win32-<IP_ADDRESS>-LVNqK0SwW285hUwHpPOkae
          package time (time-<IP_ADDRESS>) requires Win32-<IP_ADDRESS>
          package process (process-<IP_ADDRESS>) requires Win32-<IP_ADDRESS>
          package ghc (ghc-8.4.2) requires Win32-<IP_ADDRESS>
          package directory (directory-<IP_ADDRESS>) requires Win32-<IP_ADDRESS>
          package process (process-<IP_ADDRESS>) requires directory-<IP_ADDRESS>
          package hpc (hpc-<IP_ADDRESS>) requires directory-<IP_ADDRESS>
          package ghc-boot (ghc-boot-8.4.2) requires directory-<IP_ADDRESS>
          package ghc (ghc-8.4.2) requires directory-<IP_ADDRESS>
          package ghc-exactprint (ghc-exactprint-<IP_ADDRESS>) requires directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1
          package ghc-boot (ghc-boot-8.4.2-IjXXYP7XIDA1Af0Wr3EqUE) requires directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1
          package ghci (ghci-8.4.2) requires ghc-boot-8.4.2
          package ghc (ghc-8.4.2) requires ghc-boot-8.4.2
          package ghc-exactprint (ghc-exactprint-<IP_ADDRESS>) requires ghc-boot-8.4.2-IjXXYP7XIDA1Af0Wr3EqUE
          package hpc (hpc-<IP_ADDRESS>) requires time-<IP_ADDRESS>
          package ghc (ghc-8.4.2) requires time-<IP_ADDRESS>
          package directory (directory-<IP_ADDRESS>) requires time-<IP_ADDRESS>
          package directory (directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1) requires time-<IP_ADDRESS>-D1fwd9ZaD3eDd2StmPCsSC
    Preprocessing library for ghc-exactprint-<IP_ADDRESS>..
    Building library for ghc-exactprint-<IP_ADDRESS>..
    [ 1 of 13] Compiling Language.Haskell.GHC.ExactPrint.Types ( src\Language\Haskell\GHC\ExactPrint\Types.hs, .stack-work\dist\7d103d30\build\Language\Haskell\GHC\ExactPrint\Types.o )
    [ 2 of 13] Compiling Language.Haskell.GHC.ExactPrint.Lookup ( src\Language\Haskell\GHC\ExactPrint\Lookup.hs, .stack-work\dist\7d103d30\build\Language\Haskell\GHC\ExactPrint\Lookup.o )
    [ 3 of 13] Compiling Language.Haskell.GHC.ExactPrint.AnnotateTypes ( src\Language\Haskell\GHC\ExactPrint\AnnotateTypes.hs, .stack-work\dist\7d103d30\build\Language\Haskell\GHC\ExactPrint\AnnotateTypes.o )
    GHC runtime linker: fatal error: I found a duplicate definition for symbol
       rgb
    whilst processing object file
       C:\Users\crypt\AppData\Local\Programs\stack\x86_64-windows\ghc-8.4.2\lib\Win32-<IP_ADDRESS>\HSWin32-<IP_ADDRESS>.o
    The symbol was previously defined in
       C:\sr\snapshots\03fa9465\lib\x86_64-windows-ghc-8.4.2\Win32-<IP_ADDRESS>-LVNqK0SwW285hUwHpPOkae\HSWin32-<IP_ADDRESS>-LVNqK0SwW285hUwHpPOkae.o
    This could be caused by:
       * Loading two different object files which export the same symbol
       * Specifying the same object file twice on the GHCi command line
       * An incorrect `package.conf' entry, causing some object to be
         loaded twice.
    ghc.EXE: panic! (the 'impossible' happened)
      (GHC version 8.4.2 for x86_64-unknown-mingw32):
        loadObj "C:\\Users\\crypt\\AppData\\Local\\Programs\\stack\\x86_64-windows\\ghc-8.4.2\\lib\\Win32-<IP_ADDRESS>\\HSWin32-<IP_ADDRESS>.o": failed

    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

--  While building custom Setup.hs for package ghc-mod-core-<IP_ADDRESS> using:
      C:\sr\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_<IP_ADDRESS>_ghc-8.4.2.exe --builddir=.stack-work\dist\7d103d30 build lib:ghc-mod-core --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always"
    Process exited with code: ExitFailure 1
    Logs have been written to: C:\projects\personal\haskell-ide-engine\.stack-work\logs\ghc-mod-core-<IP_ADDRESS>.log

    Configuring ghc-mod-core-<IP_ADDRESS>...
    Warning:
        This package indirectly depends on multiple versions of the same package. This is very likely to cause a compile failure.
          package unix-compat (unix-compat-<IP_ADDRESS>-ALLPuaD7J24dL9b6NTbA5) requires Win32-<IP_ADDRESS>-LVNqK0SwW285hUwHpPOkae
          package time (time-<IP_ADDRESS>-D1fwd9ZaD3eDd2StmPCsSC) requires Win32-<IP_ADDRESS>-LVNqK0SwW285hUwHpPOkae
          package process (process-<IP_ADDRESS>-FMzG7P7MVAn6mqfwmNuxPP) requires Win32-<IP_ADDRESS>-LVNqK0SwW285hUwHpPOkae
          package directory (directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1) requires Win32-<IP_ADDRESS>-LVNqK0SwW285hUwHpPOkae
          package ansi-terminal (ansi-terminal-<IP_ADDRESS>-AQwelgnwMTFGc4jiARIgzm) requires Win32-<IP_ADDRESS>-LVNqK0SwW285hUwHpPOkae
          package Cabal (Cabal-<IP_ADDRESS>-FeOI90Zvmr7AkYuby89JJ) requires Win32-<IP_ADDRESS>-LVNqK0SwW285hUwHpPOkae
          package time (time-<IP_ADDRESS>) requires Win32-<IP_ADDRESS>
          package process (process-<IP_ADDRESS>) requires Win32-<IP_ADDRESS>
          package ghc (ghc-8.4.2) requires Win32-<IP_ADDRESS>
          package directory (directory-<IP_ADDRESS>) requires Win32-<IP_ADDRESS>
          package process (process-<IP_ADDRESS>) requires directory-<IP_ADDRESS>
          package hpc (hpc-<IP_ADDRESS>) requires directory-<IP_ADDRESS>
          package ghc-boot (ghc-boot-8.4.2) requires directory-<IP_ADDRESS>
          package ghc (ghc-8.4.2) requires directory-<IP_ADDRESS>
          package unix-compat (unix-compat-<IP_ADDRESS>-ALLPuaD7J24dL9b6NTbA5) requires directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1
          package temporary (temporary-<IP_ADDRESS>-8f2WBQRkfsZ9IwRyqpPINq) requires directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1
          package process (process-<IP_ADDRESS>-FMzG7P7MVAn6mqfwmNuxPP) requires directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1
          package ghc-mod-core (ghc-mod-core-<IP_ADDRESS>) requires directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1
          package ghc-boot (ghc-boot-8.4.2-IjXXYP7XIDA1Af0Wr3EqUE) requires directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1
          package extra (extra-1.6.6-E23jajM052SDJ4GgmArFUp) requires directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1
          package cpphs (cpphs-1.20.8-JKmr2FfpPiI6VediyrxNsH) requires directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1
          package cabal-helper (cabal-helper-<IP_ADDRESS>-1xg5DxHt7TJ8aF98p8nk0A) requires directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1
          package Cabal (Cabal-<IP_ADDRESS>-FeOI90Zvmr7AkYuby89JJ) requires directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1
          package ghci (ghci-8.4.2) requires ghc-boot-8.4.2
          package ghc (ghc-8.4.2) requires ghc-boot-8.4.2
          package ghc-mod-core (ghc-mod-core-<IP_ADDRESS>) requires ghc-boot-8.4.2-IjXXYP7XIDA1Af0Wr3EqUE
          package ghc (ghc-8.4.2) requires process-<IP_ADDRESS>
          package optparse-applicative (optparse-applicative-<IP_ADDRESS>-2cLHts4ddm62O3ilVqxDVF) requires process-<IP_ADDRESS>-FMzG7P7MVAn6mqfwmNuxPP
          package ghc-mod-core (ghc-mod-core-<IP_ADDRESS>) requires process-<IP_ADDRESS>-FMzG7P7MVAn6mqfwmNuxPP
          package extra (extra-1.6.6-E23jajM052SDJ4GgmArFUp) requires process-<IP_ADDRESS>-FMzG7P7MVAn6mqfwmNuxPP
          package cabal-helper (cabal-helper-<IP_ADDRESS>-1xg5DxHt7TJ8aF98p8nk0A) requires process-<IP_ADDRESS>-FMzG7P7MVAn6mqfwmNuxPP
          package Cabal (Cabal-<IP_ADDRESS>-FeOI90Zvmr7AkYuby89JJ) requires process-<IP_ADDRESS>-FMzG7P7MVAn6mqfwmNuxPP
          package hpc (hpc-<IP_ADDRESS>) requires time-<IP_ADDRESS>
          package ghc (ghc-8.4.2) requires time-<IP_ADDRESS>
          package directory (directory-<IP_ADDRESS>) requires time-<IP_ADDRESS>
          package unix-compat (unix-compat-<IP_ADDRESS>-ALLPuaD7J24dL9b6NTbA5) requires time-<IP_ADDRESS>-D1fwd9ZaD3eDd2StmPCsSC
          package ghc-mod-core (ghc-mod-core-<IP_ADDRESS>) requires time-<IP_ADDRESS>-D1fwd9ZaD3eDd2StmPCsSC
          package extra (extra-1.6.6-E23jajM052SDJ4GgmArFUp) requires time-<IP_ADDRESS>-D1fwd9ZaD3eDd2StmPCsSC
          package directory (directory-<IP_ADDRESS>-J5MwWdrFyEn9y6RDLELiL1) requires time-<IP_ADDRESS>-D1fwd9ZaD3eDd2StmPCsSC
          package Cabal (Cabal-<IP_ADDRESS>-FeOI90Zvmr7AkYuby89JJ) requires time-<IP_ADDRESS>-D1fwd9ZaD3eDd2StmPCsSC
    Preprocessing library for ghc-mod-core-<IP_ADDRESS>..
    Building library for ghc-mod-core-<IP_ADDRESS>..
    [ 1 of 45] Compiling Data.Binary.Generic ( Data\Binary\Generic.hs, .stack-work\dist\7d103d30\build\Data\Binary\Generic.o )
    [ 2 of 45] Compiling GhcMod.DynFlagsTH ( GhcMod\DynFlagsTH.hs, .stack-work\dist\7d103d30\build\GhcMod\DynFlagsTH.o )

    GhcMod\DynFlagsTH.hs:26:1: warning: [-Wunused-imports]
        The import of `GHC.LanguageExtensions' is redundant
          except perhaps to import instances from `GHC.LanguageExtensions'
        To import instances alone, use: import GHC.LanguageExtensions()
       |
    26 | import GHC.LanguageExtensions
       | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    GhcMod\DynFlagsTH.hs:209:1: warning: [-Wmissing-signatures]
        Top-level binding with no type signature:
          toSet :: (Ord a, Enum a) => E.EnumSet a -> IS.Set a
        |
    209 | toSet es = IS.fromList $ E.toList es
        | ^^^^^

    GhcMod\DynFlagsTH.hs:211:1: warning: [-Worphans]
        Orphan instance: instance Ord GeneralFlag
        To avoid this
            move the instance declaration to the module of the class or of the type, or
            wrap the type with a newtype and declare the instance on the new type.
        |
    211 | deriving instance Ord GeneralFlag
        | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    GhcMod\DynFlagsTH.hs:212:1: warning: [-Worphans]
        Orphan instance: instance Ord WarningFlag
        To avoid this
            move the instance declaration to the module of the class or of the type, or
            wrap the type with a newtype and declare the instance on the new type.
        |
    212 | deriving instance Ord DynFlags.WarningFlag
        | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    GhcMod\DynFlagsTH.hs:213:1: warning: [-Worphans]
        Orphan instance: instance Ord DumpFlag
        To avoid this
            move the instance declaration to the module of the class or of the type, or
            wrap the type with a newtype and declare the instance on the new type.
        |
    213 | deriving instance Ord DynFlags.DumpFlag
        | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    GhcMod\DynFlagsTH.hs:214:1: warning: [-Worphans]
        Orphan instance: instance Ord LlvmTarget
        To avoid this
            move the instance declaration to the module of the class or of the type, or
            wrap the type with a newtype and declare the instance on the new type.
        |
    214 | deriving instance Ord DynFlags.LlvmTarget
        | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    GhcMod\DynFlagsTH.hs:215:1: warning: [-Worphans]
        Orphan instance: instance Ord Extension
        To avoid this
            move the instance declaration to the module of the class or of the type, or
            wrap the type with a newtype and declare the instance on the new type.
        |
    215 | deriving instance Ord Extension
        | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    GhcMod\DynFlagsTH.hs:216:1: warning: [-Worphans]
        Orphan instance: instance Eq LlvmTarget
        To avoid this
            move the instance declaration to the module of the class or of the type, or
            wrap the type with a newtype and declare the instance on the new type.
        |
    216 | deriving instance Eq LlvmTarget
        | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    [ 3 of 45] Compiling GhcMod.Options.DocUtils ( GhcMod\Options\DocUtils.hs, .stack-work\dist\7d103d30\build\GhcMod\Options\DocUtils.o )
    [ 4 of 45] Compiling GhcMod.Options.Help ( GhcMod\Options\Help.hs, .stack-work\dist\7d103d30\build\GhcMod\Options\Help.o )
    [ 5 of 45] Compiling GhcMod.Read      ( GhcMod\Read.hs, .stack-work\dist\7d103d30\build\GhcMod\Read.o )
    [ 6 of 45] Compiling Paths_ghc_mod_core ( .stack-work\dist\7d103d30\build\autogen\Paths_ghc_mod_core.hs, .stack-work\dist\7d103d30\build\Paths_ghc_mod_core.o )
    [ 7 of 45] Compiling System.Directory.ModTime ( shared\System\Directory\ModTime.hs, .stack-work\dist\7d103d30\build\System\Directory\ModTime.o )
    [ 8 of 45] Compiling Utils            ( shared\Utils.hs, .stack-work\dist\7d103d30\build\Utils.o )
    [ 9 of 45] Compiling GhcMod.Caching.Types ( GhcMod\Caching\Types.hs, .stack-work\dist\7d103d30\build\GhcMod\Caching\Types.o )
    [10 of 45] Compiling GhcMod.Types     ( GhcMod\Types.hs, .stack-work\dist\7d103d30\build\GhcMod\Types.o )
    GHC runtime linker: fatal error: I found a duplicate definition for symbol
       rgb
    whilst processing object file
       C:\Users\crypt\AppData\Local\Programs\stack\x86_64-windows\ghc-8.4.2\lib\Win32-<IP_ADDRESS>\HSWin32-<IP_ADDRESS>.o
    The symbol was previously defined in
       C:\sr\snapshots\03fa9465\lib\x86_64-windows-ghc-8.4.2\Win32-<IP_ADDRESS>-LVNqK0SwW285hUwHpPOkae\HSWin32-<IP_ADDRESS>-LVNqK0SwW285hUwHpPOkae.o
    This could be caused by:
       * Loading two different object files which export the same symbol
       * Specifying the same object file twice on the GHCi command line
       * An incorrect `package.conf' entry, causing some object to be
         loaded twice.
    ghc.EXE: panic! (the 'impossible' happened)
      (GHC version 8.4.2 for x86_64-unknown-mingw32):
        loadObj "C:\\Users\\crypt\\AppData\\Local\\Programs\\stack\\x86_64-windows\\ghc-8.4.2\\lib\\Win32-<IP_ADDRESS>\\HSWin32-<IP_ADDRESS>.o": failed

    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
PS C:\projects\personal\haskell-ide-engine>

What version of stack are you using? It needs a fairly recent one, and I recommend the current one (1.7.1).
Any experienced windows users able to help here?

@alanz latest one available, 1.7.1

The only other thing I can suggest is to delete the .stack-work directory
and try again, there may be some old state in it.
On 8 May 2018 at 10:11, Vladislav Shtepin<EMAIL_ADDRESS>wrote:

@alanz https://github.com/alanz latest one available, 1.7.1
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/haskell/haskell-ide-engine/issues/550#issuecomment-387321672,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAZAB9g5X9IzJc4aRifB0xjuvorQASt6ks5twVNPgaJpZM4T1itx
.

Ok, will try when i get home.

stack clean --full prior to stack build didn't change anything :(

I'm using the latest also, 1.7.1.

@Anrock This won't fix the issue itself but have you considered trying windows subsystem for Linux instead of mingw?

@razvan-panda yeah, something wasn't working last time i tried, don't remember what. I guess i'll try again sometime.

FWIW, I was using WSL and getting the same issue. I've since switched to Arch, I'll let you know if the problem persists on Linux.

Here's an issue in Stack that seems to explain the root cause:

Usually it doesn't matter if stack installs different versions of these packages, but when there is also a dependency on ghc, errors like this will occur.

I wonder if there is a way to fix the project dependencies to make sure that we're only ever compiling against the same version of the ghc package that Stack is using as the compiler?
PS: as a last resort, there is also the horrible way: clearing out of ALL of stack's various package repositories (${HOME}/AppData, C:\sr, haskell-ide-engine/.stack-work, etc. etc.) and then running stack build from a completely clean environment.

In fact it looks like Win32-<IP_ADDRESS> has never been in a Stackage snapshot, despite that version being a dependency in GHC 8.4.2:

C:\Users\crypt\AppData\Local\Programs\stack\x86_64-windows\ghc-8.4.2\lib\Win32-<IP_ADDRESS>\HSWin32-<IP_ADDRESS>.o

(from @cryptoquick's error log).
Here's the Win32 dependency for the GHC binary
And a similar dependency for what I think is the ghc package
(TIL: GHC is a very complex project :P)
I wonder if there is a reason that Stackage doesn't pin its package versions to the same ones used in the ghc dependencies?

Oh hello, here's an issue in Stackage for just this problem!
It looks like a fix was attempted but it was reverted, and then implemented in stackage-curator instead.
I think that when stackage-curator gets released next, this should be fixed?

@johnsonwj do i understand correctly that some next stackage nightly will fix this issue? I have no idea what stackage-curator is.

stackage-curator is an executable that generates the snapshot files for each build plan. My comment about it needing to be released wasn't correct, I think; from poking around stackage, it seems that they use the latest master anyway.
Win32 hasn't been explicitly included in a stackage snapshot since nightly-2018-05-02. I suspect that any snapshot after that will work, as well as LTS 11.8 or 11.9.

I will confirm this and PR updates to the stack files if they end up working for me. I am worried that LTS 9 and 10 will be broken for Windows unless for some reason new snapshots are generated for those versions of GHC. However, one possible glimmer of hope is that the version of Win32 in those snapshots lines up with the one that is used in ghc; I will try to find out if that is the case and update the corresponding stack files accordingly.

GHC Version
Stackage Snapshot
Stackage Win32
GHC Win32 Dependency
Should Work?

8.4.2
>= nightly-2018-05-03
n/a
<IP_ADDRESS>
✅

8.4.2
< nightly-2018-05-03
<IP_ADDRESS>
<IP_ADDRESS>
❌

8.4.1
all
<IP_ADDRESS>
<IP_ADDRESS>
❌

8.2.2
all
<IP_ADDRESS>
<IP_ADDRESS>
✅

8.2.1
>= nightly-2017-08-17
<IP_ADDRESS>
<IP_ADDRESS>
✅

8.2.1
< nightly-2017-08-17
<IP_ADDRESS> or <IP_ADDRESS>
<IP_ADDRESS>
❌

8.0.2
all
<IP_ADDRESS>
<IP_ADDRESS>
✅

I based the "GHC Win32 Dependency" column on the most recent version of Win32 that matches the constraints in ghc/compiler/ghc.cabal.in. If there is some subtlety in the way stack/cabal resolve the specific version number based on those constraints, maybe the values in that column are incorrect.
For the problematic setups, I will try a couple things:

Updating the snapshot version in stack-*.yaml to one without conflicts (if possible)
If this isn't possible (see GHC 8.4.1), I will try putting an explicit constraint in the yaml file so that stack doesn't get a mismatched version of Win32.

If those solutions work I'll PR the changes to the stack-*.yaml files.

@Anrock, have you tried the most recent nightly for the 8.4.2 build?

Disregard my previous message, for >= nightly-2018-05-03 actually there was another error:
--  While building custom Setup.hs for package haddock-api-<IP_ADDRESS> using:
      C:\sr\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_<IP_ADDRESS>_ghc-8.4.2.exe --builddir=.stack-work\dist\7d103d30 configure --with-ghc=C:\Users\Anrock\AppData\Local\Programs\stack\x86_64-windows\ghc-8.4.2\bin\ghc.EXE --with-ghc-pkg=C:\Users\Anrock\AppData\Local\Programs\stack\x86_64-windows\ghc-8.4.2\bin\ghc-pkg.EXE --user --package-db=clear --package-db=global --package-db=C:\sr\snapshots\77071368\pkgdb --package-db=C:\Users\Anrock\projects\haskell-ide-engine\.stack-work\install\21156836\pkgdb --libdir=C:\Users\Anrock\projects\haskell-ide-engine\.stack-work\install\21156836\lib --bindir=C:\Users\Anrock\projects\haskell-ide-engine\.stack-work\install\21156836\bin --datadir=C:\Users\Anrock\projects\haskell-ide-engine\.stack-work\install\21156836\share --libexecdir=C:\Users\Anrock\projects\haskell-ide-engine\.stack-work\install\21156836\libexec --sysconfdir=C:\Users\Anrock\projects\haskell-ide-engine\.stack-work\install\21156836\etc --docdir=C:\Users\Anrock\projects\haskell-ide-engine\.stack-work\install\21156836\doc\haddock-api-<IP_ADDRESS> --htmldir=C:\Users\Anrock\projects\haskell-ide-engine\.stack-work\install\21156836\doc\haddock-api-<IP_ADDRESS> --haddockdir=C:\Users\Anrock\projects\haskell-ide-engine\.stack-work\install\21156836\doc\haddock-api-<IP_ADDRESS> --dependency=Cabal=Cabal-<IP_ADDRESS> --dependency=array=array-<IP_ADDRESS> --dependency=base=base-<IP_ADDRESS> --dependency=bytestring=bytestring-<IP_ADDRESS> --dependency=containers=containers-<IP_ADDRESS> --dependency=deepseq=deepseq-<IP_ADDRESS> --dependency=directory=directory-<IP_ADDRESS> --dependency=filepath=filepath-1.4.2 --dependency=ghc=ghc-8.4.2 --dependency=ghc-boot=ghc-boot-8.4.2 --dependency=ghc-paths=ghc-paths-<IP_ADDRESS>-BTJEJFO7ixU1hUjA8BfQ4h --dependency=haddock-library=haddock-library-<IP_ADDRESS>-DfHt27RGS18LxLALgHOunK --dependency=transformers=transformers-<IP_ADDRESS> --dependency=xhtml=xhtml-3<IP_ADDRESS> --extra-include-dirs=C:\Users\Anrock\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\include --extra-lib-dirs=C:\Users\Anrock\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\bin --extra-lib-dirs=C:\Users\Anrock\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib
    Process exited with code: ExitFailure 1
    Logs have been written to: C:\Users\Anrock\projects\haskell-ide-engine\.stack-work\logs\haddock-api-<IP_ADDRESS>.log

    Configuring haddock-api-<IP_ADDRESS>...
    Error:
        The following packages are broken because other packages they depend on are missing. These broken packages must be rebuilt before they can be used.
    installed package haddock-library-<IP_ADDRESS> is broken due to missing package haddock-library-<IP_ADDRESS>-919WkNWGnku6Kvc4vlhbv1-attoparsec

Not sure how to fix this, any advice?
@alanz nightlies from 2018-05-13 have dependency conflict
Error: While constructing the build plan, the following exceptions were encountered:

In the dependencies for cabal-helper-<IP_ADDRESS>:
    temporary-1.3 from stack configuration does not match <1.3 && >=1.2.1  (latest matching version
                  is <IP_ADDRESS>)
needed due to haskell-ide-engine-<IP_ADDRESS> -> cabal-helper-<IP_ADDRESS>

In the dependencies for ghc-mod-<IP_ADDRESS>:
    temporary-1.3 from stack configuration does not match <1.3 && >=<IP_ADDRESS>  (latest matching
                  version is <IP_ADDRESS>)
needed due to haskell-ide-engine-<IP_ADDRESS> -> ghc-mod-<IP_ADDRESS>

In the dependencies for ghc-mod-core-<IP_ADDRESS>:
    temporary-1.3 from stack configuration does not match <1.3 && >=<IP_ADDRESS>  (latest matching
                  version is <IP_ADDRESS>)
needed due to hie-plugin-api-<IP_ADDRESS> -> ghc-mod-core-<IP_ADDRESS>

I'm trying to fix it now.

Thanks. We need to bump forward to a current one from time to time.

Bumped temporary upper bound in all listed places and got same error about broken haddock-api...

With a little help from cabal new-build and the plan.json it generates, I
end up with compilation proceeding for
extra-deps:
- apply-refact-<IP_ADDRESS>
- constrained-dynamic-<IP_ADDRESS>
- haddock-api-<IP_ADDRESS>
- haddock-library-<IP_ADDRESS>
- haskell-lsp-<IP_ADDRESS>
- haskell-lsp-types-<IP_ADDRESS>
- syz-<IP_ADDRESS>
- temporary-<IP_ADDRESS>

On 15 May 2018 at 21:51, Vladislav Shtepin<EMAIL_ADDRESS>wrote:

Bumped temporary upper bound in all listed places and got same error
about broken haddock-api...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/haskell/haskell-ide-engine/issues/550#issuecomment-389291786,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAZAB1f3h8mLwtLZOs7sgdeM24NQTg2_ks5tyzG1gaJpZM4T1itx
.

Is this going to affect everyone who's used a one of the bad snapshots? If manually blowing away STACK_ROOT is the only way to get it to build on Windows it might be useful to put a note in the readme

I have a version that builds with the current nightly, and uses an appropriate haddock-api/haddock-library.
See https://github.com/haskell/haskell-ide-engine/pull/571, which I will merge as soon as CI passes.


When using the --manual switch with the --pfxpassword switch does not seem to work

Issue description
When using the --manual switch with the --pfxpassword switch does not seem to work, I get "The Password you entered is incorrect" when trying to use the PFX file
Steps to reproduce
I am trying to create a Central SSL using the below command
wacs.exe --store centralssl --centralsslstore C:\Certificates\ --pfxpassword MyPassword --target manual --host my.domain.com --test --verbose
It all works and creates the PFX file in the right place, but the password I specified does not work.
I get "The Password you entered is incorrect"
If I run the below and go through all the manual steps it works just fine.
wacs.exe --store centralssl --centralsslstore C:\Certificates\ --pfxpassword MyPassword --test --verbose
Please include the command line and/or manual input, relevant details about the IIS bindings, your scripts, etc.
Client version:  <IP_ADDRESS>5
Windows version: Windsows 2012 and Windows 2016
Relevant part of log file:
[INFO] A simple Windows ACMEv2 client (WACS)
[INFO] Software version <IP_ADDRESS>5 (RELEASE)
[INFO] IIS not detected
[INFO] Please report issues at https://github.com/PKISharp/win-acme
[VERB] Verbose mode logging enabled
[VERB] Arguments: --store centralssl --centralsslstore C:\Certificates\ --pfxpassword MyPassword --hidehttps --test --verbose --target manual --host my.domain.com
[DBUG] Config folder: C:\ProgramData\win-acme\acme-staging-v02.api.letsencrypt.org
[DBUG] Certificate cache: C:\ProgramData\win-acme\acme-staging-v02.api.letsencrypt.org\Certificates
[VERB] Settings SettingsService {ConfigPath="C:\ProgramData\win-acme\acme-staging-v02.api.letsencrypt.org", CertificatePath="C:\ProgramData\win-acme\acme-staging-v02.api.letsencrypt.org\Certificates", ClientNames=["win-acme", "win-acme"], RenewalDays=75, HostsPerPage=50, ScheduledTaskRandomDelay=00:00:00, ScheduledTaskStartBoundary=09:00:00, ScheduledTaskExecutionTimeLimit=02:00:00}
[VERB] Sending e-mails True
[DBUG] Renewal period: 75 days
[INFO] Running in mode: Unattended, Test
[INFO] Target generated using plugin Manual: my.domain.com
[VERB] Checking [Manual] my.domain.com
[DBUG] Loading signer from C:\ProgramData\win-acme\acme-staging-v02.api.letsencrypt.org\Signer_v2
[DBUG] Send GET request to https://acme-staging-v02.api.letsencrypt.org/directory
[DBUG] Send HEAD request to https://acme-staging-v02.api.letsencrypt.org/acme/new-nonce
[DBUG] Loading account information from C:\ProgramData\win-acme\acme-staging-v02.api.letsencrypt.org\Registration_v2
[DBUG] Send POST request to https://acme-staging-v02.api.letsencrypt.org/acme/new-order
[DBUG] Send GET request to https://acme-staging-v02.api.letsencrypt.org/acme/authz/jsOAA5ADcXIaY49QHzK8lep1M6Wb39RxxWrKJm7ozHw
[INFO] Authorize identifier: my.domain.com
[INFO] Authorizing my.domain.com using http-01 validation (SelfHosting)
[DBUG] Submitting challenge answer
[DBUG] Send POST request to https://acme-staging-v02.api.letsencrypt.org/acme/challenge/jsOAA5ADcXIaY49QHzK8lep1M6Wb39RxxWrKJm7ozHw/325925650
[INFO] Authorization result: valid
[DBUG] RSAKeyBits: 3072
[DBUG] Send POST request to https://acme-staging-v02.api.letsencrypt.org/acme/finalize/9775435/38508407
[INFO] Requesting certificate [Manual] my.domain.com
[--test] Do you want to install the certificate? (y*/n)  - yes
[DBUG] Using Centralized SSL path: C:\Certificates
[INFO] Store with CentralSsl...
[INFO] Copying certificate to the Central SSL store
[INFO] Saving certificate to Central SSL location C:\Certificates\my.domain.com.pfx
[INFO] Installing with None...
[--test] Do you want to automatically renew this certificate? (y*/n)  - no
[EROR] Create certificate failed: User aborted
[--test] Quit? (y*/n)  - yes

Confirmed that this is a bug processing the command line arguments. The workaround for now is either to set the DefaultCentralSslPfxPassword in settings.config or to use interactive mode. It will be fixed in the next release. Thanks for the report!

This has been released in version 2.0.8


Is it possible to disable studio?

I've been getting errors with each message sent to my bot and the error occurs in studio
An error occured in the receive middleware:  Error: Illegal argument null
    at module.exports (node_modules/md5/md5.js:152:13)
    at node_modules/botkit/lib/Studio.js:809:23
    at node_modules/botkit/lib/CoreBot.js:1257:56
    at next (node_modules/ware/lib/index.js:82:27)
    at Ware.run (node_modules/ware/lib/index.js:88:3)
    at Object.Botkit.botkit.trigger (node_modules/botkit/lib/CoreBot.js:1255:45)
    at node_modules/botkit/lib/CoreBot.js:1204:36
    at next (node_modules/ware/lib/index.js:82:27)
    at Ware.run (node_modules/ware/lib/index.js:88:3)
    at Object.<anonymous> (node_modules/botkit/lib/CoreBot.js:1202:49)

I commented out the lines at the bottom of CoreBot and resolved the issue.
//studio(botkit);

The Bot seems to works fine and no longer prints the errors to the console.  Is there a way to disable Studio as a configuration option?

Hi Peter,
Want to know whether Botkit Studio is open source or not !!!
When trying to connect with it, Botkit Studio is no longer accepting new registrations. pop ups


Alt text on tabs' close button

VSCode Version: Code - Insiders 1.3.0-insider (a2b9738a942237b59cb920940b93a0206f1b61d0, 2016-07-01T19:26:22.011Z)
OS Version: Darwin x64 15.5.0

Steps to Reproduce:

Enable OS X Voice Over
'Tab' to editor tabs
-> You can't distinguish between the tab and it's close button

https://github.com/Microsoft/vscode/issues/8659


Worked on 2011-1812 and 2015-1252

@andymeneely Looking into if there is something wrong with my YAML. Wanted you to see as well

Looks like this isn't still done - I need you to finish this ASAP so you can help me with this project. Students are starting this tomorrow and they'll want feedback.


SWC misunderstands precedence when using yield* expression

Describe the bug
Given this expression yield* (0, async_iterator) SWC will remove the parentheses and turn it into yield* 0, async_iterator, probably in an effort to remove bytes.
However, the precedence makes that actually say (yield* 0), async_iterator which is wrong and causing issues.
Input code
async function* level1(){
  yield 1;
  yield 2;
  yield 3;
}

async function* level2(){
  yield* (0, level1());
}

(async () => {
for await(const v of level2()){
  console.log(v);
}
})();

Config
Using parcel, I can share parcel config if needed. The issue is also reproducible on the REPL, please see attached link.

Playground link
https://play.swc.rs/?version=1.2.237&code=H4sIAAAAAAAAA23MwQrCMBCE4XueYo67RcTWY9B3CTGRwJIFGyOl9N2LEaIHb8PA%2F7l5yR7xmX1JmgdIqEFG4tUASwpyw2j7nL7zbM1mjPtXTz%2F1ADodOsotok9FjMsVq4n6gHu5VMhrngsqNHaoSe9fJRxF71SbsTGx3QGHOfQjuwAAAA%3D%3D&config=H4sIAAAAAAAAA02OsQ6DMAxEfwV5ZmgZOjB37UdYwUGpQoxsFxWh%2FHsTCmo3%2B3z3fBs81UG%2FwYyiJHXSNRm%2BoQdbZ1InYTZowbRIHqNSLotgUs8yVX%2BkEd16J8eCxgVh8qIWhlN4kOGAhn9xlJGsfCDtLt210COz0mFoYQop%2BLWyHU%2BzkOrvhGmMpzMX1sTDqwrbXndn3iD%2FGEcu6OMwfttRWvbM3qTgIaJac218EPL8bhYSDZwg5w%2Bx293IIgEAAA%3D%3D
Expected behavior
When exececuted, logs
1
2
3

to the console
Expected output code by SWC:
async function* level1() {
    yield 1;
    yield 2;
    yield 3;
}
async function* level2() {
    yield* (0, level1());
}
(async ()=>{
    for await (const v of level2()){
        console.log(v);
    }
})();

Actual behavior
When executed throws with: Uncaught (in promise) TypeError: 0 is not iterable
Actual output code by SWC:
async function* level1() {
    yield 1;
    yield 2;
    yield 3;
}
async function* level2() {
    yield* 0, level1();
}
(async ()=>{
    for await (const v of level2()){
        console.log(v);
    }
})();

Version
1.2.237
Additional context
This only happened by "doing a second pass" of SWC I guess?
So we built code to a library using parcel (parcel build with scope hoisting). Then we included that library in a project and built (parcel serve) it again and everything fell apart due to the aforementioned issue.

Thank you for the quick fix! @mischnic should I open a parcel issue to bump SWC version?

@danieltroger  https://github.com/parcel-bundler/parcel/pull/8390


[NFC] math_brute_force: add type argument to getAllowedUlpError

Add a type argument so that in the future we can request the ULP requirement for fp16 and fp64 types through getAllowedUlpError too.
Contributes to https://github.com/KhronosGroup/OpenCL-CTS/issues/867

Merging - has three approved reviews.


Missing Files on Initial Gradle Build of ver 1.5.2

Hi jjhesk - I have loaded your build ver 1.5.2 into Android Studio<PHONE_NUMBER>. The Gradle build went fine, with the exception of 7 errors as shown below. Can you please advise where the missing files can be found? Thanks in advance. Regards, TCM
C:\Users\TCM\Documents\AndroidStudioProjects\BringItBackAdvanceSlidingMenu-1.5.2\AdvancedSlidingMenu\demoslidemenu\build\intermediates\exploded-aar\com.google.android.gms\play-services-base\7.5.0\res\drawable\common_signin_btn_icon_dark.xml
Error:(10, 28) No resource found that matches the given name (at 'drawable' with value '@drawable/common_signin_btn_icon_disabled_focus_dark').
C:\Users\TCM\Documents\AndroidStudioProjects\BringItBackAdvanceSlidingMenu-1.5.2\AdvancedSlidingMenu\demoslidemenu\build\intermediates\exploded-aar\com.google.android.gms\play-services-base\7.5.0\res\drawable\common_signin_btn_icon_light.xml
Error:(10, 28) No resource found that matches the given name (at 'drawable' with value '@drawable/common_signin_btn_icon_disabled_focus_light').
Error:(16, 28) No resource found that matches the given name (at 'drawable' with value '@drawable/common_signin_btn_icon_disabled_light').
C:\Users\TCM\Documents\AndroidStudioProjects\BringItBackAdvanceSlidingMenu-1.5.2\AdvancedSlidingMenu\demoslidemenu\build\intermediates\exploded-aar\com.google.android.gms\play-services-base\7.5.0\res\drawable\common_signin_btn_text_dark.xml
Error:(10, 28) No resource found that matches the given name (at 'drawable' with value '@drawable/common_signin_btn_text_disabled_focus_dark').
C:\Users\TCM\Documents\AndroidStudioProjects\BringItBackAdvanceSlidingMenu-1.5.2\AdvancedSlidingMenu\demoslidemenu\build\intermediates\exploded-aar\com.google.android.gms\play-services-base\7.5.0\res\drawable\common_signin_btn_text_light.xml
Error:(10, 28) No resource found that matches the given name (at 'drawable' with value '@drawable/common_signin_btn_text_disabled_focus_light').
Error:(16, 28) No resource found that matches the given name (at 'drawable' with value '@drawable/common_signin_btn_text_disabled_light').
Error:Execution failed for task ':demoslidemenu:processDebugResources'.

com.android.ide.common.process.ProcessException: org.gradle.process.internal.ExecException: Process 'command 'C:\Users\TCM\AppData\Local\Android\sdk\build-tools\22.0.1\aapt.exe'' finished with non-zero exit value 1

I think the setup for mine went normal.
my build script is

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:1.2.3'

        // NOTE: Do not place your application dependencies here; they belong
        // in the individual module build.gradle files
    }
}

allprojects {
    repositories {
        jcenter()
    }
}

with the default gradle compile script mentioned from the readme file and the wiki.


Wrong values in local mouse position related a Camera2D under TileMap

Godot version
v3.4.beta4.mono.official [6a058cbf3]
System information
Debian 11
Issue description
I wrote this code inside _PhysicsProcess(float delta)
GD.Print( "local ", GetLocalMousePosition()," global ",  GetGlobalMousePosition());
Then I set physics fps to 1 in project settings.
The result is while global mouse position remain the same for each physical cycle the value of x of the local mouse position switch between two values.
local (215, 137) global (527, 274)
local (312, 137) global (527, 274)
local (215, 137) global (527, 274)
local (312, 137) global (527, 274)

Steps to reproduce
set pys fps to 1
 private Vector2 _cameraMovement = new Vector2();
    public override void _Ready()
    {
    }

    public override void _PhysicsProcess(float delta)
    {
        Position = GetLocalMousePosition();
        GD.Print(GetLocalMousePosition(), GetGlobalMousePosition());
        Position += _cameraMovement * Zoom;
    }

Minimal reproduction project
TestMouse.zip

Closed. I managed this error in different way. It was interesting because it happen each physical frame.


Support logging for mark_failure outside of except blocks

Currently, we may get a logging error about lacking exception context

Looks good.  In a more perfect world, we could save the exception context ... not now.


the "new" keyword causing member to be initialized twice in generated code.

if u have a member in a MemoryPackable type like this,
  public new string Description { get; set; }
u'll get this in generated code:
   [global::MemoryPack.Internal.Preserve]
    public static void Deserialize(ref MemoryPackReader reader, scoped ref PluginInfo? value)
    {

        if (!reader.TryReadObjectHeader(out var count))
        {
            value = default!;
            goto END;
        }

        string __Description;
    ...
        string __Description;
     ...
}

thanks!
I've fixed and released.


Lacking *.msidentity.cn in the 21v version URL list.

My customer implemented firewall whitelist according to the URLs listed in the document.
They were blocked when accessing Microsoft Entra portal pages in 21v environment because applicationmanagement.msidentity.cn was blocked by the firewall.
The URL list in the document did NOT contain *.msidentity.cn in it, while in the public version https://learn.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide, *.msidentity.com is listed.
We would also request you to review the rest of the URL list in the 21v version document in order not to miss any further URL being used in 21v Entra services.

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

ID: 1248ba04-fd9a-c009-9821-94c7b7aec88b
Version Independent ID: eec20193-ee91-0f70-2d62-a8aa99e6e84a
Content: URLs and IP address ranges for Office 365 operated by 21Vianet - Microsoft 365 Enterprise
Content Source: microsoft-365/enterprise/urls-and-ip-address-ranges-21vianet.md
Service: microsoft-365-enterprise
GitHub Login: @kelleyvice-msft
Microsoft Alias: kvice

@sscchh2001 We appreciate your feedback. This page is automatically generated from a database so we can’t manually update the page. However, if you suspect there is an error in this list of URLs and IP addresses or have questions, please contact Microsoft Support.
To contact Microsoft 365 Support:

Sign in to Microsoft 365 admin center with your Microsoft 365 admin account, and select Support > Help and support, enter your question, and then select Contact support.

If you're an admin on the account, you can call<PHONE_NUMBER> (toll-free, US only).


Height is misaligned compared to standard form fields

I have a form where I'm looking to use both DropdownButtonFormField2 and some default TextFormField
When next to each other the misalignment between the 2 is quite obvious, I managed to get it "close" with some extra work but it's still kind of obvious. Maybe I'm missing something but it would be nice if the default builder was the same height / layout. Note I use a selectedItemBuilder to show just the ID, but the same occurs even without this (in fact worse because the text tries to wrap).
Ugh - pasting the code has killed the formatting - I made the edits bold
Without additional code:

Code:
Row(
children: [
Expanded(
child: DropdownButtonFormField2(
isExpanded: true,
value: _costCode,
dropdownWidth: 300,
decoration: InputDecoration(
labelText: "Cost Code",
border: UnderlineInputBorder(),
),
selectedItemBuilder: (context) {
return Provider.of(context, listen: false)
.costCodes
.codes
.map((e) {
return Container(
alignment: Alignment.bottomLeft,
child: Text(
e.id.toString(),
),
);
}).toList();
},
items: _codeOptions.map((e) {
return DropdownMenuItem(
enabled: e.type == "code",
child: Text(
"${e.id} - ${e.label}",
style: TextStyle(
fontWeight: e.type == "code"
? FontWeight.normal
: FontWeight.bold),
),
value: e,
);
}).toList(),
onChanged: (v) {
setState(() {
_costCode = v;
});
},
),
),
SizedBox(
width: 30,
),
Expanded(
flex: 5,
child: TextFormField(
controller: _descriptionController,
decoration: InputDecoration(
labelText: "Description",
border: UnderlineInputBorder(),
),
),
),
],
),
With additional code:

Code:
Row(
crossAxisAlignment: CrossAxisAlignment.end,
children: [
Expanded(
child: DropdownButtonFormField2(
isExpanded: true,
value: _costCode,
dropdownWidth: 300,
buttonHeight: 25,
decoration: InputDecoration(
labelText: "Cost Code",
border: UnderlineInputBorder(),
),
selectedItemBuilder: (context) {
return Provider.of(context, listen: false)
.costCodes
.codes
.map((e) {
return Container(
alignment: Alignment.bottomLeft,
child: Text(
e.id.toString(),
),
);
}).toList();
},
items: _codeOptions.map((e) {
return DropdownMenuItem(
enabled: e.type == "code",
child: Text(
"${e.id} - ${e.label}",
style: TextStyle(
fontWeight: e.type == "code"
? FontWeight.normal
: FontWeight.bold),
),
value: e,
);
}).toList(),
onChanged: (v) {
setState(() {
_costCode = v;
});
},
),
),
SizedBox(
width: 30,
),
Expanded(
flex: 5,
child: TextFormField(
controller: _descriptionController,
decoration: InputDecoration(
labelText: "Description",
contentPadding: EdgeInsets.only(bottom: 15),
border: UnderlineInputBorder(),
),
),
),
],
)

I later realised that not even the default DropdownButtonFormField is aligned correctly, but the text alignment of the selected value is better, you can see the space between the label and value is pretty narrow. Making that larger would be an improvement already

Can you provider a working sample that can produce your issue? I can't run the code as it has lots of dependencies.
Also, you can add your code nicely by selecting the code then pressing <> in the comment tools or cmd+e.

@AhmedLSayed9 - Ah sorry for the dependencies - it was too late when I wrote it and wanted to put something down, I'll get you a working sample later.

I'll close this for now. Feel free to re-open when your working sample is ready.


P2P Volume Streaming

Signed-off-by: Chao Li<EMAIL_ADDRESS>

I have done a PoC with performance comparison with and without P2P Volume Streaming, see https://github.com/concourse/concourse/pull/6186#issue-507204153.

Hi, @evanchaoli I think we could consider this one merged (though some implementations are already done) if we could sort out how P2P streaming works for worker within a different network i.e. external worker that under a completely different network.
I have read your comments under related PRs. Could you have a brief summary of those comments and update this RFC with it so we could proceed? Thx!

@xtremerui I have updated the RFC, please take a look.

one thing is unclear to me, if all workers are not in the same network and P2P streaming is enabled, what is the expected behaviour? I think we should make it clear in the feature flag description about the consequence of doing that.

@xtremerui Just add a statement in "New implications", please take a look.


Support local memory widths that aren't 512 bits

ASE models whatever width the platform or AFU configure.
AFU JSON may now request any local memory or address width that is no
larger than the platform's memory interface.

Tests pass: http://sw-pert.altera.com/pert/pert.php?test_run_id=2380344
@deepakcu84: The full memory model remains at fixed 512 bit wide data. At some point it needs to be updated to handle parameterization. That may be difficult. Maybe you'll have to make it wider and scale truncate the ports using a shim to whatever the AFU requests -- similar to what we would do on hardware.


fix: updater file name with spaces in them

Fixes #843

I don't know how I gonna test this to be honest 😖

we can merge this (after ci is happy) and see how the ci run on the dev branch behaves. Or if you enable ci in your fork it should also upload everything to a draft release there.

Or maybe not quite. Just noticed that it skips the upload on the dev branch...

I'll try to run it in my fork, at the mean time, do you know what is our updater public key? Seems like there private key set in the actions, but no public key's found

https://github.com/tauri-apps/tauri-action/blob/dev/.github/fixtures/example-with-tauri-v1/src-tauri/tauri.conf.json#L41

Hmm, still doesn't work yet

https://github.com/Legend-Master/tauri-action-test/actions/runs/9757232213/job/26929173063

Ah that looks like my mistake, try adding this: https://github.com/tauri-apps/tauri-action/commit/f8044a1d9fa468d71dd285d9f17b467dc8c9b334#diff-eab77d5479dfaa2e1e42c5a470ba2543fd78189b8a71e9de66c2f0b1ba74cb2fR46
<space>( will get converted to . by github but our logic converts it to ..

Looking at https://github.com/Legend-Master/tauri-action-test/releases/tag/3 signature files seem missing, not sure if it's related to ./.. to be honest

Yeah, the looking for artifcats log is also wrong, only checking for v1 sigs

Trying it on https://github.com/Legend-Master/tauri-action-test/actions/runs/9757784582

should be good to go now
https://github.com/Legend-Master/tauri-action-test/actions/runs/9758129429
https://github.com/Legend-Master/tauri-action-test/releases/tag/7


Warning messages in bes server.log

[Version]
16.1 fix6+ 2017/03/02
[How to reproduce]

install with GL4 version
use existing db and upgrade
after domain start check bes server.log

[Expected result]
server.log contain only "good" messages
[Observed result]
lots of messages indicating that some jars:
e.g.
FileNotFoundException: C:\glassfish4\glassfish\domains\bes\applications\oscm\lib..\modules\javax.batch-api.jar (The system cannot find the path specified)
[Details]
These messages make me feel worried about the system.
see attached logfile.

server_logMar03.txt

[Details of fix]
Packaging was modified and gl-client.jar is removed from libraries of ear.

Checked on Glassfish 4, jdk1.8.0u121, build GLASSFISH4_EE_UNIT-85 2017/04/06 in SAML mode.
Such errors do not occur.


Action Log

A lot of people have requested an action log in Hanabi. There's a few possible solutions to this:

Display a small bar at the top showing what all actions are

guest-123 --> guest-456 White (Display white card)
guest-123 --> guest-456 3's (Display gray 3)
guest-123 --> Play White 3 (Display white 3)
guest-123 --> Discard White 3 (Display white 3, marked with a cross or something)

Use a "live replay" so that you have the possibility to go back and see how the game looked like at an earlier stage, and then have the possibility to go back again (similar to Lichess)

There is however one possible problem with this: Clients may not be aware of the previous actions, only about the current state. This can probably be mitigated though, as Clients should be informed whenever someone performs an action.

This might be a feature that all games want.
A toggleable transaction log:
Player A made move X
Player B made move Y
...

With the new rule-based system in #89 it could be quite easy to implement something like this.
For example:
action(play).log { message("$player played $card", action.playerIndex, action.card) }
Could also be applied to Triggers:
myTrigger.log { message("MyTrigger occurred and caused $stuff!", trigger.stuff) }
These things could then be stored in frontend and using the variables it could also be possible to solve #43.
Hanabi example: (exact syntax to be determined
action(play).log { "$player played $card" } highlights card in frontend and adds log like "Zomis played white 3"
action(discard).log .... (same as action(play)
action(giveClue).log { "$player gave clue to $targetPlayer about $affectedCards $clueValue" } highlights affectedCards in frontend and adds log like "Zomis gave clue to GustaMagic about two white cards"
Needs to be stored in frontend as an object: { message: ..., highlight: ... } (should it use a generic highlight key or a more specific affectedCards key? Need to make sure they are highlighted somehow.

It could certainly look better, but the first version of the action log now exists on the new-actions branch.