Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Aug 25 2020 04:13
    AArnott opened #120
  • Aug 25 2020 04:12
    AArnott opened #119
  • Jul 13 2020 22:17
    robertellisuk closed #118
  • Jul 13 2020 22:17
    robertellisuk commented #118
  • Jul 13 2020 15:44
    robertellisuk opened #118
  • Sep 16 2019 18:37

    AArnott on freshenup

    Hide deserializing constructor … Add xml doc comments to factory… Add xml doc comments to several… and 2 more (compare)

  • Sep 09 2019 04:53

    AArnott on freshenup

    (compare)

  • Sep 09 2019 04:53

    AArnott on master

    Target newer frameworks and SDK… Update to latest CG.R Fix test failures by targeting … and 1 more (compare)

  • Sep 09 2019 04:53
    AArnott closed #117
  • Sep 09 2019 00:31
    AArnott synchronize #117
  • Sep 09 2019 00:31

    AArnott on freshenup

    Fix test failures by targeting … (compare)

  • Sep 08 2019 03:32
    AArnott synchronize #117
  • Sep 08 2019 03:32

    AArnott on freshenup

    Target newer frameworks and SDK… Update to latest CG.R (compare)

  • Sep 08 2019 02:27
    AArnott synchronize #117
  • Sep 08 2019 02:27

    AArnott on freshenup

    Target newer frameworks and SDK… Update to latest CG.R (compare)

  • Sep 07 2019 23:13
    AArnott opened #117
  • Sep 07 2019 23:13
    AArnott assigned #117
  • Sep 07 2019 23:12

    AArnott on freshenup

    Target newer frameworks and SDK… (compare)

  • Sep 07 2019 23:00

    AArnott on stylecop

    (compare)

  • Aug 29 2019 14:38

    AArnott on stylecop

    Add stylecop.analyzers to solut… (compare)

Andrew Arnott
@AArnott
true. But as you say, we don't want to invent a DSL.
Attila Hajdrik
@attilah
and not just attributes but any code node.
yup :)
Andrew Arnott
@AArnott
So my goal with this project was to truly use C#, and recognize patterns and add more code.
Attila Hajdrik
@attilah
:+1:
Andrew Arnott
@AArnott
gotta run again. sorry. guests still here.
Attila Hajdrik
@attilah
sure
:)
Andrew Arnott
@AArnott
BTW, I have brainstormed on the topic of removing attributes in the compilation. That's when I realized the PDB-source file mismatch problem that would probably come up. Also, if the goal is to avoid an assembly reference to ImmutableObjectGraph.dll in the finished product, it wouldn't work out (depending on which options used) anyway because there is actually a functional runtime dependency on the DLL for some algorithms (e.g. diffing, recursive trees) anyway.
Andrew Arnott
@AArnott
ah, dang. I didn't realize it, but the package I released is actually broken. It's supposed to add an import and it didn't. fixing now.
Andrew Arnott
@AArnott
fixed in beta6
Attila Hajdrik
@attilah
that's clear that if you're codegenning against an API, like your diff stuff, you do need to have a reference in the end product.
:D :+1:
if the generated files are published to source server together with the generated PDB maybe it can work, and the generated files doesn't have to be part of the csproj physically. Don't know the roslyn and new build system capabilities this deep :(
Andrew Arnott
@AArnott
Yes, MSBuild can handle generating code files, removing others, and then reporting what the final set of source files were so that the right thing can happen. So that's not a blocker.
Attila Hajdrik
@attilah
That sounds cool. It would be much cleaner if Roslyn would support somehow it without a dependency on MSBuild. :D
Andrew Arnott
@AArnott
At the moment, Roslyn's design doesn't include such substitution. It just compiles what you tell it to. So if you want to do something fancy with what you compile, that has to happen before handing it to Roslyn.
And MSBuild is responsible for reporting which files actually went into compilation so that other things like source archiving, indexing, etc., work properly. So if Roslyn was playing tricks, other things would malfunction.
Attila Hajdrik
@attilah
I see. I thought that Roslyn is the one who is kicking the build in the new version. What you say is totally makes sense.
Attila Hajdrik
@attilah
isn't the ImmutableDeque type should be called ImmutableDequeue?
Andrew Arnott
@AArnott
From my research, a double-ended queue collection is called a deque.
Your "Roslyn is the one who is kicking the build in the new version" thought might be inspired by ASP.NET v5, which doesn't use MSBuild, but rather has its own build step which is composed almost entirely on Roslyn.
Attila Hajdrik
@attilah
Ahh ok, I didnot know that I beleived that's a typo :-)
Yup maybe that formed my thought about how build should happen :-)
Robert Friberg
@rofr
Nice lib! Im going to write up an example for origodb which supports immutable in-memory graphs.
Are there any collection classes on the lib or are you using the bcl immutable collections nuget from ms?
Andrew Arnott
@AArnott
Hi @rofr. the immutable object graph uses bcl immutable collections.
Please share a link to your example when you have it done, @rofr. I'd love to see it.
Robert Friberg
@rofr
Great, will do! I just found an alternate persistent collections lib:
Andrew Arnott
@AArnott
The ImmutableObjectGraph relies on the collections to implement the Builder pattern, which this alternate set of collections don't appear to do.
Robert Friberg
@rofr
It does support the builder pattern but has a different name, transients.https://persistent.codeplex.com/documentation
Andrew Arnott
@AArnott
well then that isn't the Builder pattern, is it? :)
it may have a solution to the same problem, but if it doesn't look like ToBuilder and ToImmutable, it isn't the Builder pattern. Thus the code produced by this code gen will not compile because the method names are wrong.
Robert Friberg
@rofr
The behavior is the same and it seems it would be easy to apply the adapter pattern to match the expected interface. I'll try it out...
Andrew Arnott
@AArnott
Why bother? Have you found the BCL immutable collections insufficient?
The reason I ask is I've reviewed several alternative implementations of them (not this one in particular though) and they all either had data corrupting bugs or they were faster in some cases by being slower in others.
Robert Friberg
@rofr
The lib has a benchmark which shows that the BCL classes are significantly slower for almost every type of operation and have a much larger memory footprint than this library. There are also multiple list implementations with different performance characteristics allowing you to choose the trade-offs that make most sense for a given workload. There are certainly bugs, but bugs can be fixed. Also, the collections are serializable, which the BCL types aren't and never will be.
Which other implementations have you looked at?
Andrew Arnott
@AArnott
I haven't kept a list. The BCL Immutable collections are certainly serializable. Just not using the [Serializable] attribute. I can't recall right now but there is already at least open source and popular serialization library that supports the BCL immutable collections, via the Builder pattern.
Of course bugs can be fixed, but I personally don't want to find them as a consumer of such a core library. One perf marker that I'd be interested in comparing is GC pressure given large churn of the collection.
Robert Friberg
@rofr
OrigoDB default serialization uses BinaryFormatter, so [Serializable] is a plus for our users even though custom serialization is fairly trivial.
Good point on the GC pressure comparison, I'll see if I can add that to the benchmark.
Andrew Arnott
@AArnott
I was just reading a bit of the persistent collection docs you pointed me to. It appears they allow use of mutable state inside the collections in order to achieve some of their perf. In particular, they allow different versions of an immutable collection to share a mutable array. I haven't looked at the source code yet, but that sounds like it suffers from another serious problem: if I add an element to the collection and then release all references to the new collection, an older version of the collection that I still reference will end up holding a strong reference to the added element. So it's not safe to add and then remove an element from the collection and expect the element to be GC'd.That's a big problem for some folks.
If you're interested, I started a discussion on the codeplex site: https://persistent.codeplex.com/discussions/641239
Andrew Arnott
@AArnott
I guess I was right. The author replied and agreed with the GC problem I detected. That's certainly something (discretely holding references to freed objects) that goes against a great deal of precedent with the .NET Framework and libraries written for it.
Andrew Arnott
@AArnott
I'm going to freshen up the source tree and see that the experience works well in VS2017 soon.
Oskar Gewalli
@wallymathieu
How is it going?
Andrew Arnott
@AArnott
How's what going? My review? of the VS2017 experience?
Oskar Gewalli
@wallymathieu
Getting the solution working in vs2017 ?