Skip to content

Conversation

@antonfirsov
Copy link
Member

@antonfirsov antonfirsov commented Jan 19, 2020

Prerequisites

  • I have written a descriptive pull-request title
  • I have verified that there are no overlapping pull-requests open
  • I have verified that I am following matches the existing coding patterns and practice as demonstrated in the repository. These follow strict Stylecop rules 👮.
  • I have provided test coverage for my change (where applicable)

Description

Merge sources and tests from SixLabors.Core, resolve #1002.

  • Namespace structure were left untouched.
  • The new source structure follows namespace hierarchy in src.
  • SixLabors.Core tests have been grouped under their own directory
  • Most memory-intensive ArrayPoolMemoryAllocatorTests have been disabled temporarily. The safest way to run such tests would be arcane's RemoteExecutor

Do not squash-merge!

@codecov
Copy link

codecov bot commented Jan 19, 2020

Codecov Report

Merging #1086 into master will increase coverage by 0.05%.
The diff coverage is 66.66%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1086      +/-   ##
==========================================
+ Coverage   83.71%   83.77%   +0.05%     
==========================================
  Files         688      705      +17     
  Lines       28853    29312     +459     
==========================================
+ Hits        24155    24555     +400     
- Misses       4698     4757      +59
Flag Coverage Δ
#unittests 83.77% <66.66%> (+0.05%) ⬆️
Impacted Files Coverage Δ
src/ImageSharp/ImageSharp/Formats/Tga/TgaFormat.cs 83.33% <ø> (ø)
...eSharp/Formats/Jpeg/Components/Block8x8F.CopyTo.cs 100% <ø> (ø)
...olorSpaces/Conversion/ColorSpaceConverter.Adapt.cs 82.85% <ø> (ø)
...rc/ImageSharp/ImageSharp/Formats/Bmp/BmpDecoder.cs 100% <ø> (ø)
...harp/Formats/Jpeg/Components/Decoder/JFifMarker.cs 92.1% <ø> (ø)
...plementation/Converters/CIeLchToCieLabConverter.cs 100% <ø> (ø)
...rp/ImageSharp/Formats/Png/Filters/AverageFilter.cs 100% <ø> (ø)
...lorSpaces/Conversion/ColorSpaceConverter.CieLuv.cs 100% <ø> (ø)
...arp/Formats/Jpeg/Components/Encoder/HuffmanSpec.cs 100% <ø> (ø)
...harp/Formats/Jpeg/Components/Encoder/HuffmanLut.cs 100% <ø> (ø)
... and 1156 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c3ecd89...6ef017e. Read the comment docs.

@antonfirsov antonfirsov requested review from a team and JimBobSquarePants and removed request for JimBobSquarePants January 19, 2020 04:42
Copy link
Member

@JimBobSquarePants JimBobSquarePants left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should go all in and merge the code under the collective SixLabors.ImageSharp namespace with folder structure.

It seems very odd to me not to have that as the default and developers will expect things like Point to be under the same root namespace as Image since System.Drawing groups objects like that together.

/// <summary>
/// Utility class for common geometric functions.
/// </summary>
public static class GeometryUtilities
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a naming convention I want to adopt throughout the codebase. Currently we've also got Utils and Helper(s)

<PackageId>SixLabors.ImageSharp</PackageId>
<PackageTags>Image Resize Crop Gif Jpg Jpeg Bitmap Png Core</PackageTags>
<RootNamespace>SixLabors.ImageSharp</RootNamespace>
<RootNamespace>SixLabors</RootNamespace>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You'll have to sell this change to me. Was it to reduce breaking changes?

<s:Boolean x:Key="/Default/CodeInspection/NamespaceProvider/NamespaceFoldersToSkip/=common/@EntryIndexedValue">True</s:Boolean>
<s:Boolean x:Key="/Default/CodeInspection/NamespaceProvider/NamespaceFoldersToSkip/=common_005Cexceptions/@EntryIndexedValue">True</s:Boolean>
<s:Boolean x:Key="/Default/CodeInspection/NamespaceProvider/NamespaceFoldersToSkip/=imagesharp_005Cpixelformats_005Cpixelimplementations/@EntryIndexedValue">True</s:Boolean>
<s:Boolean x:Key="/Default/CodeInspection/NamespaceProvider/NamespaceFoldersToSkip/=imagesharp_005Cpixelformats_005Cutils/@EntryIndexedValue">True</s:Boolean>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really don't want to keep dotsettings files, Resharper is a nightmare or performance. We should use .editorconfig + ruleset.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The other "toy IDE" 😆, Rider is also using this, and it's somewhat faster.
Still unsure what will be my IDE of choice in long term, but for now I'm pretty much addicted to JetBrains features, so I need .DotSettings.

"NamespaceProvider" is one of the features I really like btw.

}

[Fact]
public void AllStaticMethodsOnOnDebugGuardHaveDEBUGConditional()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't need these tests. The shared code is already tested, though I should add a simple workflow to that repo.

https://github.com/SixLabors/SharedInfrastructure/blob/7730e662d25d78566aed7a6e2b78a16592feee7c/tests/SharedInfrastructure.Tests/DebugGuardTests.cs

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Previously we used to test them in Core. If you setup an action in SharedInfrastructure, I'm happy to delete them here.

namespace SixLabors.Memory.Tests
{
// TODO: Re-enable memory-intensive tests with arcade RemoteExecutor:
// https://github.com/dotnet/runtime/blob/master/docs/project/writing-tests.md#remoteexecutor
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@antonfirsov
Copy link
Member Author

@JimBobSquarePants if we move the types, we should also do SixLabors.Shapes -> SixLabors.Drawing.Shapes in the drawing project for consistency. (cc @tocsoft)

I don't have a strong opinion apart from the fact that our decision should be user and business-focused now. So the question is: Does this worth the breaking changes (again) in beta7 -> RC1? Wouldn't it discourage users from adapting RC1?

@JimBobSquarePants
Copy link
Member

I agree it should be user focused. That’s why I’m opting for creating the long term expected result over immediate upgrade.

I don’t think it’s too painful an upgrade anyway. The reference will remain and the user will be able to bulk delete the old namespace.

@antonfirsov
Copy link
Member Author

antonfirsov commented Jan 19, 2020

That’s why I’m opting for creating the long term expected result over immediate upgrade.

OK 👍. Just to double check: this means that you also agree with the changes in Drawing, right? That one will have a bigger impact (on drawing users).

@tocsoft
Copy link
Member

tocsoft commented Jan 19, 2020

@anton changing the namespaces seems fine as an idea to me but I agree with @JimBobSquarePants and we should just totally drop the Primitives namespace part entirely and roll the types directly into the SixLabors.ImageSharp namespace. Memory on the other hand is more specialised and as people don't/wont be touching them regularly then SixLabors.ImageSharp.Memory makes sense for them.

re: drawing & shapes not sure exactly how to cut that namespace but as that project is not a target for our RC we can worry about cleaning us the structure over there at a later date.

@antonfirsov antonfirsov changed the title Merge SixLabors.Core sources into ImageSharp Merge SixLabors.Core sources into ImageSharp [first attempt] Jan 20, 2020
@antonfirsov
Copy link
Member Author

Closing in favor of #1087.

@JimBobSquarePants JimBobSquarePants deleted the af/merge-core branch April 24, 2020 11:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Externalize ImageSharp.Drawing

8 participants