Tailwind classes rendered in head don't get forwarded

Component or Package Name: Tailwind
Component or Package Version: 1.7.0
@jsx-email/cli Version?: 3.0.1
Operating System (or Browser): osx
Node Version: 20.10
Link to reproduction (⚠ read below): N/A
Link to previous PR where this was fixed: https://github.com/resend/react-email/pull/629

Expected Behavior
Tailwind styles are converted to inline styles unless they have media queries.
Actual Behavior
All tailwind ends up in the head, so forwarded emails won't have original styling.
Additional Information
When using react-email last year, I ran into the problem where my designer excited forwarded me the email template I made, only for me to find out that the head (and styles) doesn't get forwarded!
For development, I decided to do the templates Mobile first, and any responsive css would then end up in the head (that is the only place for media queries). This resulted in an email that could be mobile or desktop, but would fallback to mobile if forwarded / resent anywhere else.
For our emails, it is very important that they can be sent, resent, and maintain at least a mobile fallback.

I poked around UnoCSS to see if they have a similar tw-to-css function, and I wasn't able to find anything. Perhaps we could add that as a transformer, but I'm unfamiliar with the lib.

I made a very quick example of an example email, and then I forwarded it to show that the tailwind colors didn't come along:
Original:

Forwarded:

Perhaps I could be of more help if I could be pointed in a good direction as well!
Excited to be able to move to jsx-email and keep contributing

Hey thanks for opening an issue and the kind words. We actually looked at a similar thing when we were debugging some issues with gmail styles in classes in  as well. What we arrived on was using https://github.com/posthtml/posthtml-inline-css. tw-to-css is a great project but just isn't efficient enough for the speed we wanted to achieve.
We ended up finding a better way around the issues we were triaging (hashing class names and replacing css vars). posthtml is an interesting project, they aim to be postcss for html. posthtml-inline-css worked well in demos, but getting it to bundle correctly for our preview app (and anyone else wanting to bundle templates) was a hard slog - it's just not meant to be bundled. That said, it could be a really great post-processing tool for you, if you're running something serverside or in a worker.
What we do use internally is https://github.com/rehypejs/rehype, which is also an html processing package, and bundles quite nicely. While it doesn't have anything premade to handle this, I wouldn't be opposed to including a plugin for rehype that processed CSS in <head> and <style> tags and inlined it. The one warning I have for you about that is - the size of the email will explode. One great benefit to jsx-email over react-email is the size of the output, especially with tailwind. It can be as much as 10x smaller because we don't inline the tailwind css into style attributes. If you were up for trying your hand at a rehype plugin, we could include an inlineCss option for the render method that would run your plugin as part of processing.
Hope all that made sense 😄

I did find this https://github.com/tani/rehype-inline-css which would be a good basis. It's using an outdated css package that doesn't support modern css and would probably swap that out for postcss, but it's a start.

Having this same issue — just to summarize / make sure my understanding of the current status is right:

Tailwind-based emails break when forwarded (or put in a reply)
There is no current workaround that allows continuing to use Tailwind, the "rehype plugin" idea above is suggested as a possible change to jsx-email itself that might allow a workaround via exposing an inlineCss option in render which would allow us to make the trade off of bloating the email size but getting Tailwind emails to be forward-able
The best path forward today if I need my emails to be fowardable is to rewrite them without Tailwind at all

@grahamplace not entirely.
Gmail (and it seems limited to Gmail) strips <head> tags when forwarding (and it's selective about replies).
The current workaround is to use the rehype plugin linked to above - for usage, reference this https://github.com/rehypejs/rehype?tab=readme-ov-file#what-is-this and expand Show example code.  And that rehype plugin works very well.
If Tailwind accelerates your development and makes maintenance easier, I would suggest introducing an additional step that ran the html from jsx-email through that rehype plugin. The next major version of jsx-email is in development and will provide an internal option to inline the css, but it requires some breaking changes we can't introduce to the 1.x.x version.

@samducker you should be able to use? disableDefaultStyle. https://jsx.email/docs/components/hr#component-props

I've got a solution for the forwarded emails in mind, and I'll be working on that over the next week. What I have in mind will be in the next v2.0.0 preview.

Just wrapped up work on a new hooks system to allow for this. More to come...

I've implemented a new plugin for the next release that inlines CSS which will effectively resolve this issue. I just can't close this until we release that new version. Still a bunch to wrap up on that before we can.

v2.0.0 PR is up https://github.com/shellscape/jsx-email/pull/206 and contains a plugin to inline css, which will take care of the problems outlined in this issue. We're converting our docs site from vitepress over to astro, and following that we'll have a full page dedicated to the lifecycle hooks and the core plugins.


Changing the trigger event and the pattern for the BE tag version

This one is duplicate and was used for try and error.


rc.filter_configure_sync causes empty config flush while plugging "enc0" internally

Hi Ad,
I'm leaving this for you to look at. "enc0" is plugged, but not written to the config. However, $changed_interfaces is still set so the config is flushed creating a spurious revision.
Cheers,
Franco

Hi Franco,
No problem, I found the bug, will fix and close in the next commit.
Cheers,
Ad

super, thanks a lot :)


SU-351: Evidencias Sprint 14-15 (19) - Liquidacion de Compras: agrega…

…r Código de punto de venta
Description
Describe the changes made and why they were made.
Ignore if these details are present on the associated Apache Fineract JIRA ticket.
Checklist
Please make sure these boxes are checked before submitting your pull request - thanks!

[ ] Write the commit message as per https://github.com/apache/fineract/#pull-requests

[ ] Acknowledge that we will not review PRs that are not passing the build ("green") - it is your responsibility to get a proposed PR to pass the build, not primarily the project's maintainers.

[ ] Create/update unit or integration tests for verifying the changes made.

[ ] Follow coding conventions at https://cwiki.apache.org/confluence/display/FINERACT/Coding+Conventions.

[ ] Add required Swagger annotation and update API documentation at fineract-provider/src/main/resources/static/legacy-docs/apiLive.htm with details of any API changes

[ ] Submission is not a "code dump".  (Large changes can be made "in repository" via a branch.  Ask on the developer mailing list for guidance, if required.)

FYI our guidelines for code reviews are at https://cwiki.apache.org/confluence/display/FINERACT/Code+Review+Guide.

We will not pushing this change


Update to OpenSearch 1.2.4

Signed-off-by: Andriy Redko<EMAIL_ADDRESS>Description
Update to OpenSearch 1.2.4 (SNAPSHOT) (which includes https://github.com/opensearch-project/OpenSearch/issues/1814)
Issues Resolved
N/A
Check List

[X] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@dblock @AmiStrn removing the workaround since we've fixed the plugin itself

Only worry i have is that this is not backwards compatible with previous versions. But not a big concern really since this has a documented workaround in the previous commit. @dblock wdyt?

Only worry i have is that this is not backwards compatible with previous versions. But not a big concern really since this has a documented workaround in the previous commit. @dblock wdyt?
(Basically leading to the question of managing versions in this repo...)

Thanks @AmiStrn , yeah the workaround would work even with the new versions (with the fix available), won't break anything,  it is just not necessary anymore


Upgrade to new torch metrics

Description

Change F1 to F1Score
Fixes F1 score issue with torchmetrics>=0.6.1

Changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Checklist

[x] My code follows the pre-commit style and check guidelines of this project.
[x] I have performed a self-review of my code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing tests pass locally with my changes

This will cause conflicts with https://github.com/openvinotoolkit/anomalib/pull/230. Maybe it would be better to change F1 -> F1Score in that PR

This will cause conflicts with #230. Maybe it would be better to change F1 -> F1Score in that PR

In that case should I close this or rebase and target to #230 ?

This will cause conflicts with #230. Maybe it would be better to change F1 -> F1Score in that PR

In that case should I close this or rebase and target to #230 ?

In that case should I close this or rebase and target to #230 ?

Actually most of the lines that are changed in this PR are removed in my PR, because we no longer hard code the F1 metric. You could close this one and I'll take care of it in https://github.com/openvinotoolkit/anomalib/pull/230.


MDX Docs: Add example of reading a raw JSON string

Currently we only have an example of reading an OCaml value that represents JSON (see https://github.com/geocaml/ocaml-topojson#reading). It would be good to provide an example where we read a JSON string i.e. { "type": "Topology"... which is more likely what users will do.

Hello @patricoferris , I am  Joshua, an Outreachy applicant and would like to work on this issue. I have already set up OCaml and its package manager opam and I really look forward to your approval to start contributing to this effort.

Great, thank you for wanting to contribute and for setting everything up, I've assigned you the issue :))

@EngOmbasa how's everything going, anything you need help with ?

Hi @patricoferris ! Having had no experience in OCaml, the learning curve is so steep. It was hard to know where best to start, but I solved this by jumping in at the basics. I have learned more about the purpose of geocaml tools and libraries, and taught myself more about coding in Ocaml and functional programming in general. Soon enough, I will be comfortable to jump into the codebase and play around with the issues you assigned me, learning more as I go.

Hi @patricoferris !
I thought of this:
For simple JSON string
`
utop # (*In this example I have used a simple JSON string *)
let json_string = {|
{"name" : "Joshua Ombasa",
"age" : 25,
"country" : "Kenya",
"passion" : ["basketball","chess","charity"]}|};;
utop # #require "yojson";;
utop # let json = Yojson.Safe.from_string json_string;;
utop # Format.printf "Parsed to %a" Yojson.Safe.pp json;;`
For a topojson string:
utop # (*In this example I have used a simple topoJSON string *)
utop # let topojson_string = {|{
"arcs": [[[0.0, 0.0], [0.0, 9999.0], [2000.0, 0.0], [0.0, -9999.0], [-2000.0, 0.0]]],
"objects": {"example ": {
"type": "GeometryCollection",
"geometries": [
{"coordinates": [4000.0, 5000.0],
"properties": {"prop0": "value0"},
"type": "Point"},
{"arcs": [[0]],
"properties": {"prop0": "value0", "prop1": {"this": "that"}},
"type": "Polygon"}
]
}},
"transform": {"scale": [0.0005, 0.0001], "translate": [100.0, 0.0]},
"type": "Topology"
}|};;
utop # #require "yojson";;
utop # open Yojson;;
let json = Yojson.Safe.from_string topojson_string;;
utop # Format.printf "Parsed to %a" Yojson.Safe.pp json;;

@patricoferris  Kindly advice.

Hey @EngOmbasa,
Thanks! I formatted your comment to use codeblock so it is easier to read.
I don't think we need the "Reading a JSON string" example (also it's completely up to you, but in examples is best to use made up information rather than personal information, but as I said that's up to you ^^).
Yes! Your TopoJSON example looks good to me. However two points:

We want to read the raw JSON string into the TopoJSON library. At the moment you have gone as far as JSON to OCaml, we need the last step of OCaml to Topojson.t. I.e. using
https://github.com/geocaml/ocaml-topojson/blob/5bc10d52c1102e5a4a666848e17d45768a70669d/src/topojson/topojson_intf.ml#L226

Yojson is a perfectly good choice, but we're already using Ezjsonm (see here) for the examples so let's stick with that :)

Hi @EngOmbasa, how's everything going ? Can I help getting a PR over the line ?

Hi @patricoferris ! Almost there!

Hi @patricoferris ! I  tried this;
#require "topojson";;
#require "ezjsonm";;
module Topojson = Topojson.Make (Ezjsonm_parser);;
let topojson_string = {|{
    "arcs": [[[0.0, 0.0], [0.0, 9999.0], [2000.0, 0.0], [0.0, -9999.0], [-2000.0, 0.0]]],
    "objects": {"example ": {
            "type": "GeometryCollection",
            "geometries": [
                {"coordinates": [4000.0, 5000.0],
                 "properties": {"prop0": "value0"},
                 "type": "Point"},
                {"arcs": [[0]],
                 "properties": {"prop0": "value0", "prop1": {"this": "that"}},
                 "type": "Polygon"}
            ]
     }},
    "transform": {"scale": [0.0005, 0.0001], "translate": [100.0, 0.0]},
    "type": "Topology"
}|};;
#Topojson.of_json topojson_string;;

However I am running into this error,
Error: Unbound module Topojson

I have tried various ways of installing the package Topojson but none has worked. I have checked around the Ocaml community chat but I cant get any help. Kindly advice.

Hi @patricoferris ! I will try that. Thank you for the quick response.

Hi @patricoferris.  Does #23 and #26 fix this issue fully?

Yep, thanks


Discussion: Official guidance on how to use Paket with .NET Core?

It seems like users of Paket waited a long time to use it without the dependency on Mono, and we've been able to do so for a few months now.  However, it's not clear according to the docs whether there is a preferred method of using Paket in this new .NET Core world.  Is it better to use it as a global tool?  Or install it as a local tool in the /.paket directory and commit it?
My personal opinion is that we should encourage the use of Paket as a global tool.  It seems like package managers in other language ecosystems don't require committing the package manager to the repo.  I also think that it makes for a better user experience (i.e. paket add blah vs ./paket/paket add blah).
Do you have any thoughts on this?

I've just been digging through the docs and commit history to try and figure this out. It looks like it's doable at the moment, but the docs aren't clear.
I would have expected there to be a section in Getting Started that outlines what to do with .NET Core projects. I'm happy to help put together the docs and test things, just need to know what the guidance should be.

cc @enricosada

Currently using paket as a global tool isn't working for me (without extra steps, it's not creating the Paket.Restore.targets file I expect under .paket). What does work is installing it as a local tool under .paket, then running .paket/paket.
I wouldn't check this in as we have developers on Windows and macOS, and the tool shim is platform specific. So at the moment I'd have a build script that installs a local tool and calls paket restore, this creates the .targets file I need. However, if you then delete the paket local tool, you can do a dotnet restore and it just works.
So is it that we just need to explain how to acquire the Paket.Restore.targets in the Getting Started section?

@slang25 Using it as a global tool does work for me.  To get it to recreate the Paket.Restore.targets you need to run paket restore -f (if you're already using Paket), which unfortunately does a full restore again in addition to recreating Paket.Restore.targets.  Would be nice to have an option to ONLY overwrite the Paket.Restore.targets for this particular scenario.
What I'd like to see is lowering the friction of being able to use Paket immediately, from command line, with just a couple of one-liners (and not having to edit or download anything manually).  A lot of the steps to get started with it now make sense if you're coming from the .NET community, but aren't obvious if you're totally new to .NET/F#/MSBuild.
Here's my experience using Paket as a global tool from command line on macOS:
(warning: the GIF is a little long/slow for some reason.  Please bear with it for a bit).

You can actually see that it works okay.  The only major snafu is that it doesn't add a reference to FSharp.Core by default, which can cause issues.  On the plus side though, the user experience is pretty good:

Install Paket with dotnet tool install -g Paket
Make your directory
dotnet console new -lang F#
Start using Paket with paket init
You can then do dotnet run, which will work.

If you add a package though using paket add {PackageName} and then do dotnet run, it fails.  I wonder if it would be better for user experience to add a reference to FSharp.Core to *.fsproj files by default (but print an appropriate warning, similar to what's printed today).  And make this configurable via some configuration file.
A few open questions:

Do we think people would actually find this easier?  I personally think so, but I'm Paket is used in a lot of different ways and this might not be compatible with them.
If this WERE to be recommended as the default way to do things with .NET Core, would we want any changes made to the way files are stored?  There's a paket-files directory, and also a .paket directory.  If you're using Paket as a global tool, the only thing stored in .paket is the Paket.Restore.targets file.  Which seems kind of "wrong"/inefficient from an engineering perspective, but maybe it's worth living with since it's not that big a deal and changing it would be complicated.
Is it better to install Paket as a "local" tool, but using .NET Core?  I personally don't think so, because it adds a bunch of files and it annoys me to have to commit it to the repo.  For example:

What do you think?

I also see that the SAFE stack docs suggest using Paket as a global tool: https://safe-stack.github.io/docs/quickstart/

Regarding the startup friction, have you looked at https://github.com/thinkbeforecoding/paket.install? It creates a setup based on https://github.com/enricosada/paket-netcore-testing-as-tool that works quite well in my experience. It also adds the relevant bits to .gitignore so that having paket as local tool is not a problem:
.paket/*
!.paket/Paket.Restore.targets
!.paket/paket.bootstrapper.proj
!.paket/paket.bootstrapper.props


Add launchSettings.json to .gitignore.

With new VS a launchSettings.json is added to every project. Assuming this is an intentional change we should be ignoring it.

/cc @Eilon @rynowak @dougbu @pranavkm

Shouldn't this go into every repo? Also, this is going to be irritating

Yup, should def go to every repo. Thought I'd try it out here first.

/cc @barrytang

@rynowak we could update individual repos as and when we touch them.

:shipit:

@rynowak we could update individual repos as and when we touch them

That often ends up being annoying. Isn't there a way to update universe and push this everywhere?

Wait. This is a bug. @BillHiebert fixed it already and will show up in next tooling build. Don't change anything on your side.

Correct. I checked in a fix this afternoon.

Assuming this is an intentional change we should be ignoring it.

:smile: I'll back out the change once we get upgraded to new tooling.


Add 7810 data (CO2 and CH4)

LI-7810 data; see https://github.com/PNNL-PREMIS/PREMIS-ghg/pull/166
From my to-do list in #7


Develop

@m-schuetz After this, I can no longer get it to build on Ubuntu. It fails like this:
/build/PotreeConverter/PotreeConverter/src/stuff.cpp:38:21: warning: extra tokens at end of #include directive
 #include <Windows.h>>
                     ^
/build/PotreeConverter/PotreeConverter/src/stuff.cpp:38:22: fatal error: Windows.h: No such file or directory
compilation terminated.

From my limited understanding this problem would have been introduced in commit b74f2cafa4b728cc2e28c7b2f8dc3a6731be223c. I have very limited recent experience of building C/C++ applications and have never used Boost, so I'm not really sure why it is not working. That BOOST_OS_WINDOWS is defined when compiling on Ubuntu is a bit surprising.

Does it work if you remove the second ">" ? I don't think that should be there.

Hi @m-schuetz, sorry for the delay. The stray ">" doesn't seem to bother it too much: if removed the warning goes away but the error remains (can't find Windows.h). I presume it has something to do with the OS detection not working as it should. Not knowing Boost, I have no idea where those would be defined.

Discussion continued in #228


removed cs-webhook and secretshare from relatedImages

Do we need to remove the zen operator image too?
  - image: icr.io/cpopen/ibm-zen-operator:1.7.0
    name: IBM_ZEN_OPERATOR_IMAGE

I think we still need to get IBM_ZEN_OPERATOR_IMAGE from Env variable to create the pre-zen job
https://github.com/IBM/ibm-common-service-operator/blob/9b8a67b3e22811aad677fc4054b7a68c4a9f166b/controllers/constant/odlm.go#L284

Do we wanna remove the image references in Env variable as well?
https://github.com/IBM/ibm-common-service-operator/pull/1104/files#diff-1e712f94a52ad685abf2d1f28324abad859456b92f4d1ce5061b3d69ab51d5c2L271

Implemented via https://github.com/IBM/ibm-common-service-operator/pull/1654


🐛🐛  the plugin args of room-join is invalid

requirements

padlocal (docker img 0.65)
0.8.39

Describe your problem
when received a room-join event, the following error happened:
2022-07-03 05:35:56,653 - Wechaty - ERROR - internal error <WechatyPluginError('the plugin args of room-join is invalid, the source args:<([<wechaty.wechaty.Contact object at 0x7f0d947524c0>], <wechaty.wechaty.Contact object at 0x7f0d947524c0>, datetime.datetime(2022, 7, 3, 5, 35, 55))>, but expected args is room, invitees, inviter, date', None, None)>

Thanks for your issue about this problem which is known for a long time. We will try to fix it later.

You can upgrade the version of wechaty to fix this issue.


How to monitor the progress of replication from the source cluster to the target cluster？

We deployed ureplicator in the poc environment, and can restore the source cluster information to the target cluster normally. Thank you very much for being able to use ureplicator, but we don’t know how to check the replication progress，Any tools here？

you can use graphite to montior the replication progress.  in order to do that, you need to specify -graphite_host and -graphite_port in the ureplicator startup command ,  some of the worker metrics are direct export from jmx,  you can find an jmx config example in https://github.com/uber/uReplicator/blob/master/config/jmxtrans.xml
In practice, the most useful metrics to monitor replication status are the NumNoProgressPartitions from uReplicator controller and ConsumerLag from uReplicator Worker.

How to use jmx to monitor the replication progress for uReplicator? Is there any jmx using example?
Thanks.

yes, the example is in the user guide


Home and OCP Page

Type of change

[ ] Refactor
[X] New feature
[ ] Bug fix
[ ] Optimization
[ ] Documentation Update

Description
This PR has the Home and CPT page Tables with Filters, sorting, dynamic column selection and pagination
Related Tickets & Documents

Related Issue #
Closes #

Checklist before requesting a review

[ ] I have performed a self-review of my code.
[ ] If it is a core feature, I have added thorough tests.

Testing

Please describe the System Under Test.
Please provide detailed steps to perform tests related to this code change.
How were the fix/results from this change verified? Please provide relevant screenshots or results.

@MVarshini Can you also get our recent Telco integration added here as well?

@chentex Thanks for the suggestions. I'll address the mentioned issues.

@chentex Thanks for your valuable suggestions.
The Sorting and repeating values issues are resolved.
And, the request for multi-select in filter and updating the filter values based on previous selection will be addressed in a separate PR and is tracked in PANDA-446

@MVarshini telco specific tab doesn't seem to be working. Looks like a redirection problem. It seems to appear well in the homepage but not in the product specific page. Can you cross-check please?

As we talked with @MVarshini telco and quay are going to be worked on another PR


cifar10_multi_gpu_train.py - unintended loss reporting

#cifar10_multi_gpu_train.py
At this line, every loss for each tower in the multi GPU is calculated
However, these losses are not averaged, and it seems like the loss from the last GPU is used to return loss.
Is this on purpose (if yes, why?) or is it a bug in the code?

This is a question better suited for StackOverflow. Please ask it there and tag it with the tensorflow tag.


Samples 1..10 need porting to Terrain component

currently they rely on the Terrain Scene Manager that was removed with Ogre 1.8.
See the RoR guide and Sample11 for reference on how to port.

could do auto-porting as https://forums.ogre3d.org/viewtopic.php?f=5&t=72455

fixed by 7c7943d1dca0ec8e3298a8ef9911ffe42a60b80a


UTF-8 encode both body and subject of email

It seems that perhaps it is necessary to change the charset to UTF-8 in two places to get the body correctly encoded (exactly why this is so is a little bit unclear to me, I solved this by trail and error). I also added that the subject should be utf-8 encoded, to make sure that non-ascii characters are allowed there.

Thanks. I will have a look and merge those changes directly into my branch.

LGTM, thanks :+1:


Add Support for dag.get, dag.put

This provides support for a minimalist implementation of dag.get, dag.put.  DAG's replace the older object API, and allow pretty much any kind of json data to be written.
The API here is minimalist; it fails to implement any of the options/optional settings, mostly because I am not clear on what a good C++ API for the options should be. Ping me with suggestions, and I can update this or a later pull request.
This pull req does NOT depend on any of the other outstanding pull reqs.

Pull your branch with the latest master branch please. And I think you should now be able to implement the API, new URL: https://github.com/ipfs/js-ipfs/blob/master/docs/core-api/DAG.md

Create a new PR if you want..


[Doop][Panel] Add sticky positioning to filter/search bar and description info box

In the violations details view we want the filter/search bar and the description info box to always stay stuck at the top of the panel. In case the violations list contains multiple description boxes then the bottom one should replace the top one when scrolling further down.

outdated


Automate installer for unattended setup

Is there a way to script the installer itself? Ex:
connectd_installer -u<EMAIL_ADDRESS>-p somepasswordtoken -n devicename -p someport

Hi George, please try the attached file.  Hopefully it is self explanatory.  Let me know if not.
connectd_register.zip

@Digital-Larry I'm not able to get this script working.  It says "You have entered either an incorrect username or password." but I've verified the credentials are correct.  Is it possible the API key is wrong?  I noticed in the remote.it account page there are both a "Developer API Key" and "Access Keys".
There is also a param in the script called AUTH_HASH which isn't explained in the comments.

@Digital-Larry I'm not able to get this script working.  It says "You have entered either an incorrect username or password." but I've verified the credentials are correct.  Is it possible the API key is wrong?  I noticed in the remote.it account page there are both a "Developer API Key" and "Access Keys".
There is also a param in the script called AUTH_HASH which isn't explained in the comments.

If you wish to automate setup of a specific set of services at startup I suggest you use one of the "mass production" methods outlined here: https://support.remote.it/hc/en-us/categories/360000746111-Mass-Production-Preparation


End state overturning and barotropic streamfunctions

Approximately steady state circulation in warm and cold cavities - are there differences between models? Are these explained by the sponge, geometry or resonance in the domain (Zhao et al., 2022 )?

Depth-coordinate overturning streamfunctions for Ocean1 calculated from the average of year 20:

@chrisb13
At the second hackathon, we discussed making two versions of the barotropic streamfunction -- one with the full cavity domain and one just zoomed into the ice shelf region (same region as the melt rate plots https://github.com/misomip/isomip-plus/issues/3). This way there can be a different colourbar, since the outside-cavity circulation is largely sponge driven and stronger, so it is hard to see the circulation within the cavity. Would you be able to do the two versions?

@claireyung
Ok so, one with full domain (includes open ocean I think you mean) and another just zoomed into the cavity?
I've also noted your recent update to the dataset (Jun 4, 2024) for the MOM6 changes.
Question: what time period do you want me to plot? I gather the above was 120 months?

I think we agreed on all the plots being an average the last year (year 20), right?

Yep, average of year 20 for Ocean1 and Ocean2 simulations!
@chrisb13 Yes that's right for the time period and domain changes, but you may find the new xarray versions easier to digest than the current barotropic streamfunction notebook. @xylar's melt rate code is here.

Here are the updated overturning plots (with updated MOM6 data and using the same layout/labelling as @dgwyther's temperature structure plots). Do we have guidelines for font size? I increased the cbar and tick_params font size compared to what others have been using.

@chrisb13 how are you going with the barotropic streamfunctions? I'm happy to jump in and start on those too if you haven't yet / don't have time?

#31

I feel like adding the cavity geometry as a solid black line onto the baro and osf plots would improve understanding of what's 0 flow and what's ice.
I can see the 0 colour isn't quite white, so you can discern the cavity geometry if you squint (my second monitor is pretty rubbish and I couldn't see the 0 colour).

thanks, good idea Dave! Like this maybe?

It's harder to do cleanly for the OSF. I've plotted the boundaries from the minimum ice draft and maximum depth topography at each x, but it doesn't look so clean. There are also parts in the ice region with nonzero OSF (so I can't use that as a mask) because of the streamfunction not closing quite properly I guess... any ideas?

1st fix looks good.
2nd looks pretty weird! The OSF not quite closing properly suggests issues
with the calculation applied by each team? I know that Xylar was very
precise when he helped to calculate the ROMS OSF calculation ;) I'd
probably still apply the solid lines though - non-zero OSF values inside
the ice are the issue, not the topography?
In order to fill the gaps, maybe can you join the two vectors of points
together, so that the end of the bathymetry line joins the beginning of the
ice draft at the grounding line? At least then there's no gap there.. You
could also add a 0 value so that the last ice draft point goes all the way
to 0?
On Wed, 11 Dec 2024 at 15:59, claireyung @.***> wrote:

thanks, good idea Dave! Like this maybe?
image.png (view on web)
https://github.com/user-attachments/assets/5a226e7e-0fa3-470d-85ca-92a0399d4e67
It's harder to do cleanly for the OSF. I've plotted the boundaries from
the minimum ice draft and maximum depth topography at each x, but it
doesn't look so clean. There are also parts in the ice region with nonzero
OSF (so I can't use that as a mask) because of the streamfunction not
closing quite properly I guess... any ideas?
image.png (view on web)
https://github.com/user-attachments/assets/05b86e43-4c59-4acc-98e8-12312e793955
—
Reply to this email directly, view it on GitHub
https://github.com/misomip/isomip-plus/issues/6#issuecomment-2533709030,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABIZWM5NCQXQA7V2HYMZFED2E7IE5AVCNFSM6AAAAABTMUJ5Z6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZTG4YDSMBTGA
.
You are receiving this because you were mentioned.Message ID:
@.***>

I would definitely mask out the OSF outside of the topography.  The zero contour is also proving pretty distracting so it might be best to make it more subtle rather than more bold than the other contours.
Small errors can lead to nonzero values of the OSF outside of the ocean domain.  The approach to integration can affect whether those errors appear in the ice or not.
I like @dgwyther's suggestions about how to make the topography contours a bit more continuous.  I still think they will be lost compared with the zero contour unless something is done to tone that one down.

thanks for the ideas @dgwyther @xylar
I've masked out regions above the min ice draft and below the max topography, and added a contour around that. Also made the 0Sv line a different linestyle. Thoughts? MITgcm-BAS-Coupled has very thin layers extending into the ice/grounding zone hence the weirdness there...

Except for MITgcm-BAS-Coupled, that looks good.  I don't know what we can do to clean up that one.  They should have masked out the thin film region from the output they shared with us.  I don't suppose we have a mask from them showing where there is and isn't floating ice?

Fixed by masking out regions where ocean thickness <= 1m as used in BAS-Coupled.
Thanks Xylar and Dave! Looks much cleaner now :)


Custom field component value not retained across renders

Hi guys, I'm trying to swap out a field component, but the value doesn't seem to be retained between renders. Any ideas? Here's a component I'm using in its simplest form:
import React from 'react';
import { withCondition, useField } from 'payload/components/forms';
import { TextField } from 'payload/dist/fields/config/types';

function TestField({ path }: TextField & { path?: string }) {
    const { value, setValue } = useField<string>({
        path: path || ''
    });

    return (
        <input
            className="border py-1 px-4"
            type="text"
            value={value}
            onChange={({ target: { value } }) => setValue(value)}
        />
    );
}

export default withCondition(TestField);

As soon as a rerender occurs (in this case, my cursor leaves the parent array field) the value is lost.

Hey @GeorgeyB — this is strange. Do you have any other fields that may be impacting the data of this specific field's path? At first glance, it doesn't seem like there's anything wrong with your custom field.
We will test around with custom fields within array fields, but we've got a lot of these in use across many projects and haven't seen this specific issue.
Let us report back shortly.

@jmikrut Good catch. The issue doesn't seem to occur when the component is for a top-level field - though even at the top level, the field seems to clear after an arbitary amount of time and then never again. Here's a screen recording to try and demonstrate:
https://user-images.githubusercontent.com/13889255/171512269-b884207f-2659-419c-bf7d-cfbe1dac5698.mp4

Thanks @DanRibbens!
I can confirm that this works as expected with your fix.

Hi @DanRibbens,
this change seems to prevent any native React hooks from functioning correctly. Using this minimal example:
import React, { ChangeEventHandler, useCallback } from 'react';
import { useField } from 'payload/components/forms';

function TestField({ path, name }: any) {
    const { value, setValue } = useField<string>({
        path: path || name
    });

    const onChange: ChangeEventHandler<HTMLInputElement> = useCallback(
        ({ target: { value } }) => setValue(value),
        [setValue]
    );

    return (
        <input
            className="border py-1 px-4"
            type="text"
            value={value || ''}
            onChange={onChange}
        />
    );
}

export default TestField;

Throws a dispatcher is null error on the client:

Hey @GeorgeyB I can't reproduce this in demo using your exact component on a conditional field in a collection.
I suspect that your package.json has an issue with 1. You might have mismatching versions of React and the renderer
We upgraded Payload to use React 18 recently so any other dependencies you have need to be on 18.
Would you mind sharing a repo that recreates this or a branch from Payload that shows it in demo for me to see?

Hi @DanRibbens, apologies for the delay coming back to you. React hooks are working as expected, but I'm still experiencing the initial issue whereby values are being lost between renders. I've been able to reproduce this in a completely fresh Payload install:

Initialise a new install with the npx create-payload-app command
Uncomment the "Examples" collection import and configuration item in payload.config.ts
Use the following config for the Examples collection (I've added the testFields array field and a testField sub field inside it):

import { CollectionConfig } from 'payload/types';

import CustomTextField from './CustomTextField';

// Example Collection - For reference only, this must be added to payload.config.ts to be used.
const Examples: CollectionConfig = {
    slug: 'examples',
    admin: {
        useAsTitle: 'someField'
    },
    fields: [
        {
            name: 'someField',
            type: 'text'
        },
        {
            name: 'testFields',
            type: 'array',
            fields: [
                {
                    name: 'testField',
                    type: 'text',
                    admin: {
                        components: {
                            Field: CustomTextField
                        }
                    }
                }
            ]
        }
    ]
};

export default Examples;

Where CustomTextField is essentially the example provided in the Payload documentation:
import { useField } from 'payload/components/forms';

const CustomTextField = ({ path }) => {
  const { value, setValue } = useField({ path });

  return (
    <input
      onChange={(e) => setValue(e.target.value)}
      value={value || ''}
    />
  )
}

The value shows in the input until the parent array field rerenders, then it is lost.
It's worth noting that even if testField is a top-level field, the value is still lost after some arbitary time/event, but only once (as shown in the video in this comment)

Hey @GeorgeyB I haven't published the fix yet in the latest version yet. There were some other big changes merged at the same time and we wanted to do some additional QA on it first. I'll update again when its released.

@GeorgeyB — the fix is now deployed in 0.18.0.
Will you give it a shot, and if it resolves the problem you're facing, will you close this issue?

@jmikrut, @DanRibbens.
Looking good now, thanks guys.


Google Analytics is only activated in production - missing from documentation?

📚 Documentation
From what I can see, the google analytics plugin that ships with preset-classic is only enabled in production mode. Maybe this could be added to the documention? I spent a while wondering why the analytics script wasn't loaded when running yarn start.
I definitely feel like this is good and intentional, but should still be hinted to on the plugin's documentation. Unless I'm missing it?
Have you read the Contributing Guidelines on issues?
Yes.

Does Google Analytics run in a production Docusaurus v2 site by default?
I'd like documentation on how to opt-out/disable Google Analytics as well.

It's only active if you specify a tracking ID I believe. But i could be wrong.

Yes I think trackingId is required and it's only enabled in production mode.
Any doc PR is welcome. I guess having an option to enable this in dev could also be useful?

I guess having an option to enable this in dev could also be useful?

I'm not sure about that, as that could potentially mess up the resulting data, if you include both data from development and production audiences. I think the current behaviour is definitely correct.
I can try to spin up a PR later, if I have time.


docs(readme) : added a letter

Closes #
📑 Description

✅ Checks

[ ] My code requires changes to the documentation
[ ] I have updated the documentation as required

ℹ Additional Information

@hanshal101 corrected but still shows failure

Ok here you can either squash the commit or ammend the last commit message.


test: lock ava to 3

Signed-off-by: Jytesh<EMAIL_ADDRESS>

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage remained the same at 93.621%

Files with Coverage Reduction
New Missed Lines
%

packages/redis/src/index.js
1
93.33%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
317

Relevant Lines:
325

💛  - Coveralls


experimenting with a devcontainer

What type of PR is this? (check all applicable)

[ ] Refactor
[X] Feature
[ ] Bug Fix
[ ] Optimization
[ ] Documentation Update

Description
Experimenting with a noetic devcontainer
Related Tickets & Documents

Related Issue #
Closes #

QA Instructions, Screenshots, Recordings
Please replace this line with instructions on how to test your changes.
[optional] Are there any post deployment tasks we need to perform?

@francescodelduchetto not sure if this is still useful to you, but I thought I at least let you know I did this.


GetRowByIndex(0) thorws "System.NullReferenceException"

Describe the bug
I have a Wpf DataGrid in my application.
When i create the datagrid object using AsGrid(), it return rowcount and column count correctly.
But when I try to GetRowByIndex(0) then it thorws "System.NullReferenceException"
Code snippets
Grid grd = element.AsGrid();
grd.GetRowByIndex(0).Cells[0].Click();
Screenshots

Additional context
I have similar DataGrid in another screen of the application, there the code works fine. But same code is not working on another DataGrid.
This is the dataGrid visible on Flaui inspect

Is the problem in the GetRowByIndex or the Cells property? Please check which one.

Problem is with GetRowByIndex. It throws System.NullReferenceException.

Digging deeper, it looks like the issue is in the PreCheckRow
if (RowCount <= rowIndex) {
RowCount is not set


Check if we can remove 'pragma: no cover' tag for missing code coverage on imports

In our code base, for a few imports which are added when TYPE_CHECKING is set to true, we're adding the tag
'pragma: no cover' as those lines are not covered by tests. Investigate if we can cover those lines.

I really don't think we can as per https://github.com/astronomer/astro-sdk/pull/1258#discussion_r1029169535

cc @tatiana


Creating a training set for ML competitions

Training Dataset Creation Process
This issue describes how we generated a set of pairwise comparisons between open source projects, where the weights are derived from their relative funding amounts.
Data Sources

Project funding data from OSO's BigQuery tables (oss_funding_v0)
Repository information from OSO's BigQuery tables (repositories_v0)
Initial dependency graph containing repository URLs (unweighted_graph.json)

Process

Data Collection: For each project in our dependency graph, we collected:

Quarterly funding amounts
Funder information
Associated GitHub repository URLs (using the most starred repo when multiple exist)

Comparison Generation: For each funding round (defined by funder + quarter):

Found all projects that received funding in that round
Generated all possible pairs of projects
Calculated relative weights based on funding amounts

weight_a = amount_a / (amount_a + amount_b)
weight_b = amount_b / (amount_a + amount_b)

Data Consistency:

Project pairs are always stored with alphabetically larger URL as project_a
When the same pair appears in multiple rounds, weights are averaged
Weights for each pair sum to 1.0

Output Format
The final CSV contains four columns:

project_a: GitHub repository URL (alphabetically larger)
project_b: GitHub repository URL (alphabetically smaller)
weight_a: Average relative funding weight for project_a
weight_b: Average relative funding weight for project_b

Key Assumptions

Projects are identified by their GitHub repository URLs
For projects with multiple repositories, we use the most starred one
Projects must appear in the same funding round to be compared
Funding amounts within the same quarter are treated equally (no time-based weighting)
All funding currencies are converted to USD

Example
If Project A received $75 and Project B received $25 in a funding round:

Included in this PR here:
https://github.com/deepfunding/dependency-graph/pull/12


Version Packages

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.
Releases
<EMAIL_ADDRESS>Patch Changes

#757 5337ba7 Thanks @threepointone! - create: allow passing arbitrary strings to --template. expose react template.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Use for custom datasets

Hello,
Would you mind sharing a guide and tips to train it for custom data?
Would it be possible to use different teacher model architectures (e.g. instant NGP)? In order for this to possible, what functions are needed besides call_eval, trace_eval, transmittance_eval?
Can you also share how to choose keypoints in keypoints.json?
Thank you!

Hi!
The code we have provided has only been tested on original completely implicit representations of NeRF, but you should be able to apply it to iNGP style NeRFs, too. In order to use a NeRF model with the code we provided in GitHub, you should hook it up to the nerf_wrapper.py. To do that, you need to save your NeRF model using PyTorch Jit and through that provide the three interfaces needed in the nerf_wrapper.py for your model. These three functions are:

nerf.call_eval: this is NeRF’s standard evaluation function (takes in a point and direction and returns the rgb and density of the point)
nerf.transmittance_eval: this is the interface to an auxiliary network that can be trained along side your NeRF, to store for each point and direction what is the value of transmittance.  In the code we provided we found this network works better if you train it on point positions and camera origin positions (instead of ray direction). In instant-NGP, depending on the repository that you are using there might not be an auxiliary transmittance network, in that case you should add it to the NeRF pipeline and train it on the volume rendering transmittance throughout the NeRF training.
nerf.trace_eval: this is an interface to the rendering function in your pipeline and takes rays, near/far bound, etc and returns the radiance (and optionally depth). This interface is only used for visualization purposes in our code.

If you provide these three interfaces and the network weights through PyTorch Jit, you should be able to connect your models to our code and run distill.py to get the surface field and so forth. You might also want to change distillation code so you distill into a grid rather than an implicit network to make it even faster.
General Tip: We found that distilling the surface field is much easier if your objects of interest are not of relatively tiny scale, to avoid that you can upscale your NeRF around a bounding box of the part of the scene that interests you (e.g table top) and use that.
To choose keypoints, you can use any tool that show you pixel coordinates when hovering the mouse on an image (e.g. Paint app) or you can use Mouse event in python and have a callback to get the pixel coordinates whenever you click on a point on image.

Hello, thanks for sharing your work!
Could you please sharing your code that defines the three interfaces as well? I’m trying to train nerf2nerf for custom data and want to refer to your code.
Thank you!

Hi, Thanks for your interest in the work.
We used this code for our NeRF model. You can find the three interface methods at the bottom of the file.

Thanks so much!  It helps me a lot.

@lilygoli  Thanks for the clarification. I was wondering what's the difference between torch.save and torch.jit.save?

torch.jit.save is a function of TorchScript that serializes and saves the model like torch.save, but has two advanatages for our usecase as it saves an intermidiate representation of a PyTorch model: 1- For loading it you do not need access to the original model's code and architecture to be able to first load the weights into the model and then use the model's methods. You can directly load the model instance itself and call the methods on it. This allows us to write general external scripts that manipulate models with different internal code but same interface (for example different NeRF models with different pipelines). 2- It is in general faster to run evaluation and call methods using the jit saved model as it has gone through some compilation beforehand.

I see. Thanks!

@lilygoli Another question. For custom data collection and preprocess. What data do we need?
I have checked your data folder.
The following data should be collected first:
(n2n) sse@CN0316000027L:~/code/nerf2nerf/scenes/scene_2$ tree
.
├── a
│   ├── 1.json
│   ├── 2.json
│   ├── distilled_a_1.ckpt
│   ├── distilled_a_7.ckpt
│   ├── extracted_pc.json
│   ├── nerf_model_a.pt
│   ├── rgb_1.png
│   └── rgb_2.png
├── b
│   ├── 1.json
│   ├── 2.json
│   ├── distilled_b_1.ckpt
│   ├── extracted_pc.json
│   ├── nerf_model_b.pt
│   ├── rgb_1.png
│   └── rgb_2.png
├── distill_output
│   ├── gt.png
│   └── predicted.png
├── gt_transform.json
├── jar_keypoints.json
├── object_point_clouds
│   ├── jar.json
│   ├── pedestal.json
│   └── pip.json
├── output
│   └── output_transform.npy
├── pedestal_keypoints.json
├── pip_keypoints.json
└── transforms.json

From my understanding, there are
trained nerf models for each view
point cloud for each object
keypoint for each object
camera pose for two views of one scene

torch.jit.save is a function of TorchScript that serializes and saves the model like torch.save, but has two advanatages for our usecase as it saves an intermidiate representation of a PyTorch model: 1- For loading it you do not need access to the original model's code and architecture to be able to first load the weights into the model and then use the model's methods. You can directly load the model instance itself and call the methods on it. This allows us to write general external scripts that manipulate models with different internal code but same interface (for example different NeRF models with different pipelines). 2- It is in general faster to run evaluation and call methods using the jit saved model as it has gone through some compilation beforehand.

Another question. Should the pytorch and python version be the same for nerf2nerf repo and the one for the trained and saved by torch.jit.save?

torch.jit.save is a function of TorchScript that serializes and saves the model like torch.save, but has two advanatages for our usecase as it saves an intermidiate representation of a PyTorch model: 1- For loading it you do not need access to the original model's code and architecture to be able to first load the weights into the model and then use the model's methods. You can directly load the model instance itself and call the methods on it. This allows us to write general external scripts that manipulate models with different internal code but same interface (for example different NeRF models with different pipelines). 2- It is in general faster to run evaluation and call methods using the jit saved model as it has gone through some compilation beforehand.

hi, thanks for sharing your code! I am trying to save the model through torch.jit.save :
model = RadianceField(use_coarse=True)
m = torch.jit.script(model)
torch.jit.save(m, path)

but  I get an error:
torch.jit.frontend.NotSupportedError: Compiled functions can't take variable number of arguments or use keyword-only arguments with defaults:
  File "/root/nerf2nerf/nerf.py", line 424
    def forward(self, *args, method="query", **kwargs):
                                              ~~~~~~~ <--- HERE
        return getattr(self, method)(*args, **kwargs)

seems that it is not allowed to use **kwargs in the forward() function.  Did you go through the same problem when training and could you please tell me how did you solve it ?


Allow local llama library usage

Sometimes its nice to try different library versions and different forks of llama etc (given they still use the same api).
This commit adds the local path as the first place to search for llama libraries.

I agree we may need an escape hatch of sorts at the moment (e.g #30 ) and @MillionthOdin16 has brought this up previously in #12 .
I'm not sure the that using the local directory is the right solution, I would prefer something more explicit such as using an environment variable or even a custom function to update _lib in llama_cpp.

I agree we may need an escape hatch of sorts at the moment (e.g #30 ) and @MillionthOdin16 has brought this up previously in #12 .
I'm not sure the that using the local directory is the right solution, I would prefer something more explicit such as using an environment variable or even a custom function to update _lib in llama_cpp.

I made it into an environment variable.
A custom function will probably take a bigger refactor because of the way the library is loaded.


Fixing jinja template for redis to allow for no properties.

Previously it assumed properties would exist.
Fixes #35.

LGTM


Why is the result of my experiment so bad?

According to the configuration of TimesNet in this paper, the performance of the ETTh1 dataset is very poor. I don't know why. I hope the author can solve the confusion. I'm much obliged.
This is the result:
long_term_forecast_ETTh1_96_192_TimesNet_ETTh1_ftM_sl96_ll48_pl192_dm32_nh8_el2_dl1_df512_fc3_ebtimeF_dtTrue_'Exp'_0
mse:nan, mae:nan, corr:nan, nse:nan

Hi, we have provided the corresponding script in this repo. Please see: https://github.com/thuml/Time-Series-Library/blob/main/scripts/long_term_forecast/ETT_script/TimesNet_ETTh1.sh
The difference lies in the setting of d_ff. We set d_ff as 32 here.

Thanks for your reply. I'll change the parameter settings to run again.
Darry00
@.***

------------------ 原始邮件 ------------------
发件人:                                                                                "thuml/Time-Series-Library"                                                                                @.>;
发送时间: 2023年4月26日(星期三) 下午5:20
@.>;
<EMAIL_ADDRESS>主题: Re: [thuml/Time-Series-Library] Why is the result of my experiment so bad? (Issue #86)
Hi, we have provided the corresponding script in this repo. Please see: https://github.com/thuml/Time-Series-Library/blob/main/scripts/long_term_forecast/ETT_script/TimesNet_ETTh1.sh
The difference lies in the setting of d_ff. We set d_ff as 32 here.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>


tslint:disable-next-line difficult to apply to object-literal-sort-keys

Bug Report

TSLint version: 5.8.0
TypeScript version: 2.6.1
Running TSLint via: VSCode

TypeScript code being linted
// tslint:disable-next-line:object-literal-sort-keys
 const UiBreakpoints = {
  xxsmall: 0,
  xsmall: 450,
  small: 700,
  large: 800,
}

with tslint.json configuration:
{
  "extends": [
    "tslint:recommended",
    "tslint-eslint-rules",
    "tslint-react"
  ],
  "defaultSeverity": "error",
  "rules": {
    "array-bracket-spacing": [true, "never"],
    "curly": [true, "ignore-same-line"],
    "indent": [true, "spaces", 2],
    "interface-name": false,
    "jsx-curly-spacing": [true, "never"],
    "jsx-no-multiline-js": false,
    "jsx-boolean-value": [true, "never"],
    "max-line-length": [true, 120],
    "member-access": [true, "no-public"],
    "no-console": [true, "warn", "error"],
    "no-constant-condition": true,
    "no-debugger": true,
    "no-unused-variable": [true, "check-parameters", { "ignorePattern": "^_" }],
    "no-var-keyword": true,
    "no-var-requires": false,
    "object-curly-spacing": [true, "always"],
    "ordered-imports": false,
    "prefer-const": true,
    "quotemark": [true, "double", "jsx-double", "avoid-escape"],
    "semicolon": [true, "never"],
    "trailing-comma": [true, {
      "multiline": {
        "objects": "always",
        "arrays": "always",
        "functions": "ignore",
        "typeLiterals": "always",
        "imports": "always",
        "exports": "always"
      },
      "singleline": "never"
    }],
    "variable-name": {
      "options": [
        "allow-leading-underscore",
        "ban-keywords",
        "check-format",
        "allow-pascal-case"
      ]
    }
  },
  "linterOptions": {
    "exclude": ["./node_modules/**/*"]
  }
}

Actual behavior

The key 'xsmall' is not sorted alphabetically (object-literal-sort-keys)

Expected behavior
Rule disabled for entire object definition.

Ah, no sooner did I post it did I see the example on https://palantir.github.io/tslint/usage/rule-flags/. Still it would be nice to have this behaviour changed. Feel free to close the issue.

Do any other linters work like this? I'm not sure this proposed behavior will be intuitive. For example, what if I want to only disable the sorting check for one of the fields in a literal? It will look confusing to see a disable-next-line flag do something different based on the line where it's placed.

For example, what if I want to only disable the sorting check for one of the fields in a literal?

Fair point.


Stats not updating

The stats page hasn't been updating since November 2015: [(http://data.nhm.ac.uk/about/statistics/records)]
Current text on page: "Record statistics are updated daily - these figures were last updated on November 25, 2015"

There is a command for updating the stats in ckanext-nhm:
 paster datastore update-stats -c [path to development.ini].

This should have been running via cron, but hasn't been. I have just re-run the command so stats are now correct and added it to cron so they will update weekly.


Use *_test packages to make examples copy-pasteable

The main reason for this PR was to make the examples in documentation
copy-pasteable, but there are some additional benefits too.
For example, the pool example before this change:
p := New().WithMaxGoroutines(3)
for i := 0; i < 5; i++ {
	p.Go(func() {
		fmt.Println("conc")
	})
}
p.Wait()

and after:
p := pool.New().WithMaxGoroutines(3) // has package name
for i := 0; i < 5; i++ {
	p.Go(func() {
		fmt.Println("conc")
	})
}
p.Wait()

The function defaultMaxGoroutines in iter package had to be exported because it was used from the tests.

Codecov Report

Merging #124 (4f9a721) into main (b3c39d3) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #124   +/-   ##
=======================================
  Coverage   99.31%   99.31%
=======================================
  Files          12       12
  Lines         441      441
=======================================
  Hits          438      438
  Misses          3        3

:mega: Codecov offers a browser extension for seamless coverage viewing on GitHub. Try it in Chrome or Firefox today!


feat: Ewbank grades

Add Ewbank grades with conversions from YDS as in
https://en.wikipedia.org/wiki/Grade_(climbing)#Free_climbing_2

Thank you.  This is awesome!
@all-contributors add @musoke for code & ideas


Add support for QualifiedDo in Haddock

This changes the matches for ITdo and ITmdo so that they match the new ITdo Expr in the -XQualifiedDo extension, but in a backwards compatible manner.

Cool, I wonder why this wouldn't produce a warning.

And also: How did this slip Travis?

Ah, now we are talking!

Thanks!


Custom scopes, example of propagating the custom scope to other classes

Add example to docs or example application, where a scope is propagated to other classes.
See example written as test case of this:  https://github.com/kohesive/injekt/blob/master/core/src/test/kotlin/uy/kohesive/injekt/TestInjektion.kt#L202-L247
Which uses LocalScoped(see implementation)
And uses scoped factory registrations (see implementation)

related:  http://stackoverflow.com/questions/35315548/in-the-injekt-library-for-kotlin-how-do-i-create-local-scopes-such-as-for-each

Is there a sensible alternative for binding an object to a scope without having to create a base class implementation?
I'm trying to use a better pattern in my Android app than using a static reference to bind an object to a local scope but certain classes can't/shouldn't extend a class.  Any ideas?


Broken makers output formatting in terminal (Windows)

Describe The Bug
Broken makers output formatting in terminal. Probably only on Windows (git bash, ps, cmd)

To Reproduce
Run makers on Windows.
How to resolve it
We were debugging it in Trunk and this code (+ related dependency) should be enough to resolve it:
#[cfg(windows)]
if let Err(err) = ansi_term::enable_ansi_support() {
    eprintln!("error enabling ANSI support: {:?}", err);
}

Note: cargo make works well, I assume cargo calls similar command by itself.

OT: Hi @sagiegurari. I'm just integrating cargo-make to https://github.com/MoonZoon/MoonZoon - cargo make is still the best task runner 🙂

@MartinKavik  thanks a lot for reporting this.
i just tried on linux and both work ok and i don't have a windows box to try this on :(
its so strange that only makers fails on windows.
if you have the ability to help here and maybe provide a PR with a fix that would be amazing, otherwise i'll probably be blocked on this one.

this is now released.


fix status updater.

@morvencao: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gencheck_operator
b670d46878d40cdbe1193195c4c94e963567ff15
link
/test gencheck_operator

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ostromart Thanks


Request - add @media print to carry over full styles to PDF exports

When exporting to PDF using this theme, a lot of the colours such as the different headings come across to the generated PDF but the overall theme gets more or less switched out for a light mode. Background colour is white and text is black, this contrasts poorly with the rest of the theme, so currently to get a good looking export you would have to change theme back to default or a light theme before exporting.
Seems that you can write a CSS @media query to customise the appearance of generated PDFs, I tried doing this with limited success, CSS is not my strong suit.
My very rudimentary css snippet below gets me like 80% there, but doesn't handle pre code snippets well as it adds bg colour to the text within the block.
e.g.

I'm also struggling to change tag links from italicised blue to non-italic green, the a tag selector doesn't work.
e.g.
In obsidian:

In pdf

Hopefully the experts here could take my starting point and polish it up to make it production ready:
@media print {
	* {
		background-color: #282a36;
	}

	@page {
		margin: 0mm 0mm 0mm 0mm;
	}
	body {
		margin: 0mm 0mm 0mm 0mm;
	}
	span,
	li,
	p {
		color: #f8f8f2;
	}
}

Interesting. I didn't know about this behavior and just assumed Obsidian would render the current view into a PDF. Let me see if I can figure something out. Any outside help is also much appreciated.

I have used some of your code as well as pieces found in the Obsidian forum to make "most" stuff working correctly on PDF export. The bottom of the page still shows up as pure white and links have the wrong color, while specifically checked lists seem to have a bit too much margin. For the vast majority of content this is good however. Thank you!


Support for CoreCLR

It seems that AutoFixture currently doesn't support the new DNX platform.
Are there plans to add support this?

Not yet, at least. What is DNX?

Haha.. it's the new cross-platform asp.net framework. https://github.com/aspnet/DNX
the runtime is "dnx451" instead of "net451", etc.

What does "support for" mean in this context? Are you saying that it's impossible to test ASP.NET 5 from a test library with a dependency on a .NET 4 library?

ASPNET 5 runs on multiple platforms.  We're only writing ASPNET 5 on the dnx platform right now, so it is a different set of runtime libraries.  Our code currently is not compiled for "net451", so the libraries are effectively targeting incompatible platforms

My tests run just fine with this project.json:
{
"dependencies": {
	 "xunit.runner.dnx": "2.1.0-*",
	 "xunit":"2.1.0-*",
	"AutoFixture.Xunit2":"3.30-*",
	"NSubstitute": "1.8.0",
	"ManagementWeb": "",
	"Microsoft.AspNet.Mvc": "6.0.0-beta4",
	"AutoFixture": "3.30.4-*",
	"AutoFixture.AutoNSubstitute": "3.30.4-*",
	"Microsoft.Azure.Documents.Client": "0.9.2-preview",
	"WindowsAzure.Storage": "4.4.1-*",
	"DeepEqual": "1.1-*"
},
 "frameworks": {
    "dnx451": { }
},
"commands": {
	"test": "xunit.runner.dnx"
}

}

interesting.  I'll have to bug the guy that's working on this to see what the difference is.
Did you do anything special to make it work?

Not really, no. IIRC Autofixture always worked with aspnet 5 but in the past I had trouble with the xUnit extension. Now that xUnit 2 support for AF is out and DNX & xUnit play together nicely it just works.

Seems to the the idea here is really "support for CoreCLR", not DNX.  Anything that works for the .NET Framework 4.5 will work for 4.5 on DNX.  CoreCLR will likely require some effort to support, but I have no idea how much.  The best way to find out is to try building it for CoreCLR and see what breaks.

Yes, I should have been clear.  I meant CoreCLR, not just DNX.

From just looking in the coreclr repo, it's difficult for me to glean the status of the project. Is it in preview? Beta? Released?
Without having tried it at all, if CoreCLR is anything like Portable Class Libraries in that the supported features is an intersection of available features on various platforms, it's quite unlikely that it would be possible to retrofit AutoFixture to run on CoreCLR without breaking changes.
Recently, @moodmosaic was so kind to make the analysis for AtomEventStore (a much smaller project than AutoFixture), and here the outcome was that a PCL version was infeasible.

Without having looked at AutoFixture sources at all, I agree with your assessment: breaking changes are likely.  #if DNX_*-style directives will be necessary if support is in the plan.

CoreCLR is, more or less,  up an Running since Windows Phone 8.
ASP.NET 5 will be RC in November,  CoreCLR for Linux and Mac will also be RC in November 2015. Alongside with CoreFX. Release 1.0 for everything planned for 1Q2016.

It would surprise me tremendously if it was possible to add support for CoreCLR without introducing breaking changes, so I've added the 4.0 milestone to this issue.

Out of curiosity, I run the API Portability Analyzer on the Ploeh.AutoFixture assembly and got some interesting results:

Wait before you open the Champagne, though. That rough 3% unfortunately accounts for some rather fundamental symbols:

Target type
Target member

System.Console
M:System.Console.get_Out

System.Threading.Thread
M:System.Threading.Thread.get_ManagedThreadId

System.Threading.Thread
M:System.Threading.Thread.get_CurrentThread

System.Reflection.ICustomAttributeProvider
M:System.Reflection.ICustomAttributeProvider.GetCustomAttributes(System.Type,System.Boolean)

System.Net.Mail.MailAddress
M:System.Net.Mail.MailAddress.#ctor(System.String)

System.SerializableAttribute
M:System.SerializableAttribute.#ctor

System.Runtime.Serialization.SerializationInfo
T:System.Runtime.Serialization.SerializationInfo

System.Reflection.ParameterInfo
M:System.Reflection.ParameterInfo.IsDefined(System.Type,System.Boolean)

System.Type
M:System.Type.get_IsGenericTypeDefinition

System.Type
M:System.Type.get_IsEnum

System.Type
M:System.Type.get_BaseType

System.Type
M:System.Type.get_IsPrimitive

System.Type
M:System.Type.get_Assembly

System.Type
M:System.Type.get_IsGenericType

System.Type
M:System.Type.GetTypeCode(System.Type)

System.Type
M:System.Type.get_IsClass

System.Type
M:System.Type.get_IsValueType

System.Type
M:System.Type.get_IsAbstract

System.Reflection.MemberInfo
M:System.Reflection.MemberInfo.get_ReflectedType

System.Reflection.PropertyInfo
M:System.Reflection.PropertyInfo.GetSetMethod

System.Exception
M:System.Exception.#ctor(System.Runtime.Serialization.SerializationInfo,System.Runtime.Serialization.StreamingContext)

System.Reflection.MethodBase
M:System.Reflection.MethodBase.GetCurrentMethod

However, there are a few solutions:

[x] Replace all references to the properties in System.Type with the corresponding ones in System.TypeInfo, available through the GetTypeInfo(Type) extension method.
[x] Remove all references to System.SerializableAttribute.
[x] Remove all references to System.Runtime.Serialization.SerializationInfo (likely only used in exception constructors).
[x] Remove all references to the System.Reflection.MemberInfo.ReflectedType property and use the reflected object to get a hold of its type.
[x] Replace all references to the System.Reflection.PropertyInfo.GetSetMethod property with the System.Reflection.PropertyInfo.SetMethod property instead.

This is only a first pass and things might change as CoreCLR is still being developed. At least we got an idea of what it would take to make AutoFixture compatible with it.

Wow, thank you, @ecampidoglio, for performing this analysis :+1:
Some of the incompatible types (e.g. MailAddress) we can move to an add-on library that only works on the full framework. I already had in mind to pull some features out of the Ploeh.AutoFixture library for version 4.
The idea of replacing PropertyInfo.GetSetMethod with PropertyInfo.SetMethod is good. AFAICT, it'll only work on .NET 4.5+, but that's okay, because the v4 branch is already on .NET 4.5.

Not sure if the "Jump In" label is appropriate for this issue. Usually it is used to indicate small, isolated, bite sized issues that are fairly easy and new contributer friendly. It seems this issue would require a fairly good understanding of a large part of the code base and it's history.

@chaitanyagurrapu, perhaps you're right.
The reason I added the jump in label was that I consider this work somewhat unrelated to AutoFixture details. Yes: decisions will have to be made on how to address various incompatibilities, but there's also a great deal of work simply figuring out how the entire code/build infrastructure works related to CorCLR, and that part is completely unrelated to AutoFixture.
At the moment, I don't have these skills, so I would love getting help with this. The decisions that need to be made regarding compatibility issues we can discuss here, or in dedicated Github issues.

I've started working on this. Questions to come :)

Sounds good to me :+1:

@lbargaoanu Sounds good :+1: Remember, if at all possible, keep it small.

Reflection has changed in 4.5. I need 4.5 (TypeInfo) in order to write reflection code that would work for .NET Core. But that would cascade to all project referencing AutoFixture.

I guess I should work on the v4 branch :)

I would like to move MailAddressGenerator to a different project that targets the full framework in the v4 branch, so I can build AutoFixture for .NET Core. I could also declare a placeholder type for .NET Core, but I avoided conditional compilation until now. And there will always be things supported only in the full framework.

[It's in the works] (https://github.com/dotnet/corefx/issues/1006). But meanwhile...

For future reference
https://blogs.msdn.microsoft.com/dotnet/2016/02/10/porting-to-net-core/

Nice post! Does it also cover libraries? (I searched for library but didn't find much...)

:) That's all about libraries, but this post and its links should be enough.

I'd love to see AutoFixture working on CoreCLR, as well, and willing to help out where needed. Looking at the last PRs of Lucian Bargaoanu (#511, and #513), it looks like this issue got stale on some unresolved discussions.
I'd like to get the ball rolling, but don't know what the overall plan was for this, and how to deal with some of the details that were blocking the discussions. So it might be useful to get to something like that, before getting into all of the details.
Some questions that I've seen floating around, or that I have myself:

should AutoFixture be converted into a PCL, or use something like shared projects?
which platforms are definitely needed, or wanted for the long run? (.NET, CoreCLR, UWP?)
are conditional compilations unwanted for a project like this?

@ploeh I can image that not all of these questions can be answered by you, but maybe the core contributors have some input on this. @lbargaoanu Do you have maybe some input on this? Thanks!

I see that I have forgotten to reply to this thread; please accept my apologies :flushed:
Any work we can do in order to prepare the AutoFixture code base for .NET Core is welcome, as long as it doesn't degrade the code base or introduce breaking changes.
Breaking changes are still possible, but they'd have to go into the v4 branch.
In any case, though, I'll need good justification for any change that seems unwarranted as is. While I can't say that I'm following the .NET Core situation closely, it seems like there's still a lot of thrashing, and I'm not keen to introduce speculative changes as long as the target is still moving.
I wouldn't be surprised if conditional compilation would end up being necessary, and I'm not against it as long as we can keep it sane. If I can still run the build script in order to build whatever needs to be published, it'll probably be OK. I must admit, though, that I don't have a lot of experience with this.
I also don't know which platforms are wanted. Essentially, if anyone in the community sends us pull requests that look maintainable, and that extend AutoFixture's reach, we'll consider taking them.

AFAICT, we would need to target netstandard1.X which is the set of APIs that would run on any platform that implements them (including netcore cross platform and net framework on Windows only).
See https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md
In general, the higher numbers have more APIs, but less supported platforms. We should probably start (continue) this discussion by understanding which X we should target in netstandard1.X.

The first paragraph of that document scares me a little bit:

We're sharing early plans for the future of building .NET class libraries.
-- https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

@moodmosaic it scares me too, but the thing is, the general concept of choosing which APIs we would be targeting would essentially be necessary either way. netstandard just gives them a well known name and agreed subsets, and an easier way to describe them. That is assuming we wanted to be portable in the first place.
For example, if we need reflection APIs for AutoFixture, the list of targets we could possibly have is reduced. If we need concurrent collections, the same is true. Those platforms already exist (net framework full, Windows phone, etc), so I think it's not something that can change if we discuss which APIs we need.

I might kick off the conversation... (disclaimer: I'm still learning this stuff too)
I start with the lowest (netstandard1.0) which is implemented already on the largest number of platforms, and look for reasons why we cannot (or will not) commit to that platform.
According to my understanding, the netstandard1.0 set of APIs is pretty old and restrictive. It doesn't have things things like:

System.Linq.Parallel (starts from netstandard1.1)
System.Console (starts from netstandard1.3)
System.Collections.Concurrent (starts from netstandard1.1)
System.ComponentModel.Annotations (starts from netstandard1.1)
System.Collections.Specialized (starts from netstandard1.3)

This leads me to think it's not practical for AutoFixture to target netstandard1.0.

I wonder if waiting for the analyser mentioned by @ecampidoglio here is a better strategy

Sorry for too much comment spam, I'll stop now :)
FYI I ran the latest portability analyser on a locally built Ploeh.AutoFixture.dll from v4 4a7d415 and the summary is:

Assembly
.NET Core, Version=v5.0
.NET Framework, Version=v4.6.2
.NETPlatform, Version=v5.0

            <a href="#Ploeh.AutoFixture, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null">    Ploeh.AutoFixture, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null
    (.NETFramework, Version=v4.5)

98.56%
100.00%
98.37%

Here are some changes it currently recommends:

Full output is [here](https://rawgit.com/adamchester/ddb48926e65d80b2526c825125b8ba38/raw/d6c6b591e4310aea0ec97960b2e58ea1f725f550/AutoFixturePortability-11-05-2016.html#Ploeh.AutoFixture, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null).

@ploeh Many widely-used componenets of Asp.Net Core require at minimum netstandard1.3. Examples of this include EntityFrameworkCore (uses 1.3) and Mvc (uses 1.6).
If Autofixture used either of these as the baseline, I think it'd be in a good place.

Any timelines on when .Net Core support might be available?

I managed to make a build on .NET Core based on v4 branch. I did not try to build test projects though. Check out this branch if you want to create a package.

FWIW, here's the comparison between AutoFixture/AutoFixture v4 and uhaciogullari/AutoFixture net-core. It's looking good 👍

Well it's not that straightforward really. The existence of project.json causes an error on building regular csproj projects right now. We could migrate all projects to project.json format but I am not sure if it's a good idea for the other projects. I haven't checked them in detail but I suspect they are plugins for some other testing frameworks. No idea if they support .NET Core as well.
Another thing is Microsoft announced they will move away from project.json soon and they will go back to csproj. They promise an easy migration but do you want to take your time to use this temporary format? It's all up to you. I could push a package from my current branch but v4 seems like work in progress.

There is a way to build without the errors: #712

I actually tried to build from your branch but it doesn't generate a dll.  It's probably missing some configuration but creating an extra folder in each project didn't appeal to me aesthetically.

Is there any update on this?

I think it was prudent to wait until the .net core tooling reaches RTM status. The updated csproj tooling will not be ported to VS2015 and thus will only be available in VS2017. See https://twitter.com/TheCodeJunkie/status/822048014172880900

https://blogs.msdn.microsoft.com/dotnet/2017/03/07/announcing-net-core-tools-1-0/

@hoetz you can still install vs2017 community edition.
Is there any plan to look at this issue?
It feels really bad to write tests for .NET standard assemblies without AitoFixture...

Hi Everyone, this requires somebody from the community to step in and contribute. It's obviously difficult right now because the governance model issues haven't been resolved yet (#703). Somebody also needs to step in on that front too.

I'm play around with the problem. Right now I'm focusing only on Src\AutoFixture.sln.
My strategy is to convert Src\AutoFixture\AutoFixture.csproj to the new project format (VS 2017) so that it can support both .NET Framework and .NET Standard.
I ran the .NET Portability Test and the best target should be .NET Standard 1.5 (see attached file).
To begin with, I won't be converting the test projects, although I assume we might want to run the test also in .NET Core runtime in the future.
AutoFixtureNetPortabilityTest.zip

Hey @Kralizek - Just FYI - I had success with netstandard1.3 over in #712

@Kralizek my mistake, it looks like I started planning for netstandard1.3 but actually ended up with netstandard1.5 👍

Almost there. The tests are all green in .NET Framework. The build is all red in .NET Standard. :D
I met only these categories of problems:
Generator not needed
Only one case, MailAddressGenerator, because System.Net.Mail.MailAddress is not available in .NET Standard. Solution: the entire file has been "removed" by #if NET40 ... #endif
Serialization
SerializableAttribute, SerializationInfo and StreamingContext don't exist in .NET Standard. Also, Exception doesn't have the constructor that take those two types. Using compiler directive I've removed the attribute and that constructor from all the exceptions. Especially removing the attribute isn't really pretty.
Usage of Reflection to get information about a Type
In .NET Standard Type is much poorer. Everything is delegated to a TypeInfo object that contains all the properties that are used. The problem is that .NET Framework uses still the old Type class.
Solution:
I created an extension method that forwards the very same Type object public static Type GetTypeInfo(this Type type) => type; and made this extension method available only in .NET Framework via compiler directive. This trick solved many incompatibilities leaving the files untouched. Note: the extension method is marked as internal.
Usage of Reflection to get the current Assembly
Ok, this one was a tough one because I don't know perfectly the project layout. I used ReSharper to quickly check class hierarchy but you guys should double check.
The file is TerminatingWithPathSpecimenBuilder and the line is var thisAssembly = MethodBase.GetCurrentMethod().DeclaringType.Assembly;. It looks like you are looking for the assembly we are in. Since this class doesn't have inheritors, it's safe to assume that typeof(TerminatingWithPathSpecimenBuilder).DeclaringType[.GetTypeInfo()].Assembly returns the same result, but again, I might be wrong. (I put the fake extension method in brackets). If my assumption is correct, I would suggest to mark this class as sealed to avoid the risk of it being inherited and breaking it.

Usages of System.Threading.Thread.
System.Threading.Thread does not exist and it will be never part of .NET Standard. The good news is that it's used in two classes, TerminatingWithPathSpecimenBuilder (again) and RecursionGuard and in the same way. The bad news is that I really have no idea how to reimplement the same behaviour.
private readonly ConcurrentDictionary<Thread, Stack<object>>
    _requestsByThread = new ConcurrentDictionary<Thread, Stack<object>>();

private Stack<object> GetMonitoredRequestsForCurrentThread()
{
    return _requestsByThread.GetOrAdd(Thread.CurrentThread, _ => new Stack<object>());
}

Anyway, let me introduce you the new project file.
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>net40;netstandard1.5</TargetFrameworks>
    <GenerateAssemblyConfigurationAttribute>false</GenerateAssemblyConfigurationAttribute>
    <GenerateAssemblyCompanyAttribute>false</GenerateAssemblyCompanyAttribute>
    <GenerateAssemblyProductAttribute>false</GenerateAssemblyProductAttribute>
    <GenerateAssemblyVersionAttribute>false</GenerateAssemblyVersionAttribute>
    <GenerateAssemblyFileVersionAttribute>false</GenerateAssemblyFileVersionAttribute>
    <GenerateAssemblyTitleAttribute>false</GenerateAssemblyTitleAttribute>
    <GenerateAssemblyDescriptionAttribute>false</GenerateAssemblyDescriptionAttribute>
  </PropertyGroup>
  <ItemGroup Condition=" '$(TargetFramework)' == 'net40' ">
    <Reference Include="System" />
    <Reference Include="System.Core" />
    <Reference Include="Microsoft.CSharp" />
    <Reference Include="System.ComponentModel.DataAnnotations" />
  </ItemGroup>
  <ItemGroup Condition=" '$(TargetFramework)' == 'netstandard1.5' ">
    <PackageReference Include="System.ComponentModel.Annotations" Version="4.1.0" />
  </ItemGroup>
</Project>

yes, this is the whole project file.

@Kralizek have you noticed we intend to target >= net45 in the v4 branch?

@adamchester nope... It shouldn't matter that much but I will change the target framework. Thanks for the heads up! 👍
Btw, I found out that System.Threading.Thread is available as a package.
It unlocked a whole new level of compiler errors... nice :P

.NET Standard 2.0 Should add a lot api back, maybe it is worth waiting?

No, it's not. .NET Standard 2.0 is due in Q3 2017. We are one commit away from supporting .NET Standard 1.5, why should we wait for 2.0? For generating mail messages on a runtime will never support it?
Also, 2.0 is mostly going to be a shim of framework 4.6 with a lot of NotSupportedException being thrown all around.

@Kralizek Fair enough. I would of course love autofixter released faster, so was a more general question.

FWIW, I'm the contributor that added the support for the mail address generator, and although, it's nice that it made AutoFixture to have support for that out of the box, it's by no means a vital aspect of AutoFixture and worth the effort to wait for it.
Having AutoFixture on the lowest possible .NET Standard should have most priority, IMHO. Keep up the good work, and if you're looking for any help, or support in testing it, then I can definitely pitch in.

@Kralizek the TypeInfo stuff is also present in .NET 4.5, so it would help.

Was bitten by the error "Package AutoFixture 3.50.5 is not compatible with netcoreapp1.1 (.NETCoreApp,Version=v1.1)" today when starting to add tests to a number of .NET Core projects.
I'm asking for a "state of autofixture for .net core" kind of reply that gives a direction for when this extremely useful nuget package will be available for this platform (and .net core 2.0 is already rtm and pending release ..).
What's holding it back? (thanks in advance)

We are currently working on that and you can track the progress in #773. Notice, this PR is about the AutoFixture project itself. We have 9 more other projects that should be migrated, but that should be done only after we finish work on this one.
.NET Core support will be released as v4, you can find the whole scope here. I'd expect a couple of months before everything is ready.
In the meanwhile, we are also working on the Dev NuGet feed (#762), so you will be able to participate in early product testing 😉

@zvirja thanks for the detailed update. I'm sure it'll come in handy for other developers as well. I'd be happy to participate in early product testing.

@zvirja so just to clarify - the current (temporary) approach to writing unit tests against .NET Core applications/libraries is using AutoFixture in e.g. .NET 4.7 test projects and migrate the test project(s) to .NET Core at a later time?
Is this the suggested workaround for the time being? (as long as the app I'm writing is allowed to be fully .NET Core, it's actually not a big issue to write the tests in a regular .NET 4.7 environment).

@andersborum I never thought about the temporary workaround. I'm not sure that all the API we use in v3 (packages, published to NuGet) are .Net Standard 2.0 compliant (to use a new feature of .NET Standard).
Let us know if you found a way to combine both v3 and .Net Core, so we could advice that to other people 😉

Just to notify everybody - .Net Standard support for AutoFixture PR (#762) has been merged to the v4 branch. You can consume package from our private feed.
Notice, only AutoFixture library has been migrated. Other glue libraries will follow up later.

It is possible to move the v4 to the nuget.org, even the alpha version? Couldn't find anything comparable to autofixture until now that support .netstandard.

@RomanKernSW Not at this moment - we haven't migrated even a half of the projects yet (like xUnit, NUnit, NSubstitute support), so it's too early. Also we have a plan to change the namespace, so I'd prefer to do that before we release something publicly as that would be a major break between releases.
Do you have any issues with the private feed? You can add the feed via NuGet.config if that is strongly needed.

hm I have to check if it possible to use nuget.config for nuget restore (.Net Core 2 - preview Task in VSO). Right now, we have one private Feed (VSO) with nuget.org  without any nuget.config files. Need time to test this...

.Net Standard 2.0 has a compatibility mode for .Net Framework NuGets.
I have written .Net Core tests with AutoFixture 3.50.x and no problems so
far.
RomanKernSW<EMAIL_ADDRESS>schrieb am Mi., 30. Aug. 2017 um
09:56 Uhr:

hm I have to check if it possible to use nuget.config for nuget restore
(.Net Core 2 - preview Task in VSO). Right now, we have one private Feed
(VSO) with nuget.org without any nuget.config files. Need time to test
this...
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/AutoFixture/AutoFixture/issues/404#issuecomment-325912883,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACEWQBok4gYi5B0vrQ-2UxmsDYnei7qbks5sdRWPgaJpZM4EZWLQ
.

@roarwrecker Awesome, thanks for sharing! Meaning we have larger time buffer till we roll out the official support to NuGet :wink:

@roarwrecker thanks... this was not the issue on .netstandard 1.6. I could install the nuget, but it never compile without error

Hey Guys, not sure how far along the .NetCore work is, but is it possible to get an alpha version on NuGet?

@selmendorfFrontline Copying the reply from here:

Publish of the pre-release version to the NuGet is a bit painful question to me. While we started to support .NET Core for most of the projects, we have a plan to change the default namespace. This would be a huge breaking change for our clients and all the client code will stop to compile. This is the point when the confusion appears:

if we release alpha with existing namespace and change namespace in between the alpha and RTM, it will confuse our clients as they already saw v4 with existing namespace. I want our clients to feel that v4 was always released with a new namespace as governance model was changed.
if we release alpha with changed namespace, we'll be unable to merge master to v4 branch without pain anymore. Currently we commit to both the branches, that's why I'd like to defer namespace change to the end. Another point is that our documentation is not currently ready, so people might simply not understand why all the namespace imports are invalid and that they need to simply run a text replace. That will make them scary and experience will not be as smooth as I wish.

The best way to solve this situation would be to not release alpha and release the RTM only. Unfortunately, I cannot provide you with precise ETA as it depends on my capacity (I'm working on this project in my free time) and availability of other contributors (my PRs should be reviewed 😉). In my head I imagine the release in a month or two and hope it will happen within this range. This project was dead for about 9 months due to governance model change - that's the main reason of such a delay in support.

Please use the package from the preview feed in the meanwhile. You can tune your Nuget.config as it was mentioned above, so this should be an issue.

I'm going to close this issue after the #857 is finally merged. Our final .NET Compatibility table would be following:

Product
.NET Framework
.NET Standard

AutoFixture
:heavy_check_mark: 4.5.2
:heavy_check_mark: 1.5

AutoFixture.xUnit
:heavy_check_mark: 4.5.2
:heavy_minus_sign:

AutoFixture.xUnit2
:heavy_check_mark: 4.5.2
:heavy_check_mark: 1.5

AutoFixture.NUnit2
:heavy_check_mark: 4.5.2
:heavy_minus_sign:

AutoFixture.NUnit3
:heavy_check_mark: 4.5.2
:heavy_check_mark: 1.5

AutoFakeItEasy
:heavy_check_mark: 4.5.2
:heavy_check_mark: 1.6

AutoFoq
:heavy_check_mark: 4.5.2
:heavy_minus_sign:

AutoMoq
:heavy_check_mark: 4.5.2
:heavy_check_mark: 1.5

AutoNSubstitute
:heavy_check_mark: 4.5.2
:heavy_check_mark: 1.5

AutoRhinoMock
:heavy_check_mark: 4.5.2
:heavy_minus_sign:

Idioms
:heavy_check_mark: 4.5.2
:heavy_check_mark: 2.0

Idioms.FsCheck
:heavy_check_mark: 4.5.2
:heavy_minus_sign:

SemanticComparison
:heavy_check_mark: 4.5.2
:heavy_check_mark: 1.5

All the unsupported libraries except Idioms.FsCheck cannot be updated as their dependencies don't support .Net Standard and it's unlikely that they will (most of them are obsoleted). I've tried to port Idioms.FsCheck to support both .NET 452 and .NET Standard 2.0 (as it's technically possible), however wasn't able to make it work. It seems that SDK is still pretty rough and we need to wait for new releases. Compilation and project load simply fail after I define TargetFrameworks node.
Unless anybody have other vision, I'm going follow this plan 😃I also feel how close we are to the release and how much is behind 😊

Go go go!

I've tried to port Idioms.FsCheck to support both .NET 452 and .NET Standard 2.0

Have you tried switching to a newer F# version on that one? IIRC, it's on F# 3.1 and this might be the case (?)

Great work @zvirja. Do you think we can get v4 out? The closer we get, the more excited i feel :)
I wish i could offer you a beer :)

Have you tried switching to a newer F# version on that one? IIRC, it's on F# 3.1 and this might be the case.

@moodmosaic Yep. If you check FsCheck 2.9.0 you will find that it depends on FSharp.Core (>= 4.1.17), therefore I had no other choice 😅 The issue is rather with SDK. If I start to target both frameworks simultaneously, I'm unable to load the solution in VS
Project:
<PropertyGroup>
  <TargetFrameworks>net452;netstandard2.0</TargetFrameworks>
  .....
</PropertyGroup>

<ItemGroup>
  <PackageReference Include="FsCheck" Version="[0.9.2,3.0.0)" Condition=" '$(TargetFramework)'=='net452' " />
  <PackageReference Include="FSharp.Core" Version="3.1.2" Condition=" '$(TargetFramework)'=='net452' " />

  <PackageReference Include="FsCheck" Version="[2.9.0,3.0.0)" Condition=" '$(TargetFramework)'=='netstandard2.0' " />
  <PackageReference Include="FSharp.Core" Version="4.1.17" Condition=" '$(TargetFramework)'=='netstandard2.0' " />

  <PackageReference Include="FSharp.NET.Sdk" Version="1.0.*" PrivateAssets="All" />
</ItemGroup>

Trying to open in VS:

Everything is fine with the project - the issue is somewhere in F# SDK. That's why I'd like to postpone .NET Core support by FsCheck till the better times.
@Kralizek Please see the reply a few answers above.

Just checked in VS 2017.4 and still cannot target multiple frameworks for F# project. Therefore, I'm closing this issue for now as we support .NET Core for all other projects.

JFYI: I released v4 rc1 to the NuGet, so you can consume and test without need to play with a custom feed.


Multi-Window for TimeSeriesPredictor.feature_importance

Hi,
it would be great if the known multi-window-splitter logic which is used for extended testing ( predictor.evaluate() )would be natively available for more robust feature-importance testing. Right now I am calling the feature_importance in a loop on the test_set which is sliced in each iteration and in the end summed and averaged. I hope this makes sense :)
After testing on a rather simple water-temperature prediction: The feature importance is highly unstable. One arbitrarily choosen window (default: the last one) will give a very different result to a window 6 hours before. I don't know if this is a problem of the model, the data, or the method of testing on just the last window is just a bad idea.

@obwohl thank you for the suggestion, this is a nice idea!


.net maiu execution on physical device with error

Hi, I'm not able to find any way to run my .net Maiu application on my physical device. I'm connected to it on the computer via cable, but I can't find it in visual studio to debug directly on it.
When I run an application in xamarin, I can run it smoothly, when I run the command 'dotnet build -t:Run -f net6.0-android', in the command line, I can run the application on my android tanbén.
In visual studio, I can only run on windows.
Does anyone know how I can solve this problem?
I'm using visual studio version 17.3.5

Hi @RafaelFernandesBR sorry for the late reply. Did you find a solution to this problem? I was able to get it to appear in the debug target list by following the instructions to Enable Physical Device Debugging. The device automatically appeared in Visual Studio when I

Turned on developer mode on the device
Enabled USB debugging on the device
Plugged in the device to the computer via USB

I'm going to closet his as I believe this is the solution to your problem. If it isn't please feel free to reopen. Let me know either way!

Hi, where do you click exactly to show this?
Here on mine it doesn't show up. At least not with screen readers.
I'm going to debug > other debug targets