krauthaufen/adaptify

adaptify's Issues

Server mode

Could improve build times

dotnet hang from within aardvark.build

dotnet aardpack hangs in dotnet build, most likely because some stream is not closed (?). This might be a similar issue. dotnet/msbuild#3383

FSharp.Core union support

• Option
• Choice

dotnet install does not work on osx

when run without prior installation of adaptify, adaptify.msbuild fails to install adaptify since dotnet is not found. should be easily fixable via 'useShellExecute'

Subtile hash changes lead to non-existing generated files

Only happens with net472 and maybe .net 5, project hashes might me different (unkown reasons till now), which tempt designtime builds in reusing non existing files.

Getting started help

Hi. Sorry if this is the wrong place to ask this, but are there any minimal examples/templates of how to set up a project using Adaptify that 1) aren't part of this repository and 2) also don't use the Aardvark Platform? I'm trying to wrap my head around it, but I haven't used Paket or Fake, etc. very much, so I'm having trouble getting started setting up a project to try out generating adaptive types. Thanks!

Current aval

Missing in new generator

Caching

implement

install via msbuild tool fails for 1.1.10

unknown(1,1,1,1): Adaptify warning :    at [e-mail]
e(Unit unitVar0)) [I:\development\template\src\test\test.fsproj]
unknown(1,1,1,1): Adaptify warning : error installing tool to path "C:\Users\hs\AppData\Local\adaptify\0.0.0.0
\adaptify.exe" (System.Exception: dotnet failed [I:\development\template\src\test\test.fsproj]

TreatAsValue / NonAdaptive

Ignored in new generator

1.1.6 silently requires FSharp.Core 6.0

manifests in apps using F# 5.0.. seealso aardvark-platform/aardvark.base#79

'tracing' deltas through update

I'm currently thinking about "tracing" deltas through update functions in our elm-like apps again.
Basically all our collections would need to maintain two additional things. E.g. HashSet would need to new fields

basedOn : HashSet<'T>
deltas : seq<SetOperation<'T>

Whenever Adaptify sees those things it could check if the basedOn happens to be the current state of the output and (when successful) apply the deltas to it.

After that it would need to "destroy" both fields, which could be done by replacing them in the immutable model or by mutating them under the hood.

The latter would certainly perform better but it may also cause many problems (threading, etc)

Since computeDelta uses reference-equality on subtrees (for HashMap/HashSet/etc.) this will most likely not improve the performance drastically, but we should investigate that eventually...

@haraldsteinlechner

keeping deltas aside immutable update: we had some sketches some years back. while looking for it i found this folder: https://github.com/aardvark-platform/aardvark.base/blob/master/src/Demo/Sketch/UndoRedo.fsx

adaptify tool cannot handle relative project paths

dotnet adaptify --local --force src\PRo3D.2D3DLinking\PRo3D.Linking.fsproj
Unhandled exception. System.UriFormatException: Invalid URI: The format of the URI could not be determined.
   at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind, UriCreationOptions& creationOptions)
   at System.Uri..ctor(String uriString)
   at Ionide.ProjInfo.VisualTree.relativePathOf(String fromPath, String toPath) in /_//src/Ionide.ProjInfo/VisualTree.fs:line 22
   at Ionide.ProjInfo.VisualTree.visualPathVSBehaviour(String projPath, String filePath) in /_//src/Ionide.ProjInfo/VisualTree.fs:line 30
   at Ionide.ProjInfo.VisualTree.getVisualPath(FSharpOption`1 linkMetadata, FSharpOption`1 fullpathMetadata, String identity, String projPath) in /_//src/Ionide.ProjInfo/VisualTree.fs:line 55
   at Ionide.ProjInfo.VisualTree.getCompileProjectItem(FSharpList`1 projItems, String projPath, String sourceFile) in /_//src/Ionide.ProjInfo/VisualTree.fs:line 65
   at Ionide.ProjInfo.ProjectLoader.mapToProject(String path, IEnumerable`1 compilerArgs, IEnumerable`1 p2p, IEnumerable`1 compile, IEnumerable`1 nugetRefs, ProjectSdkInfo sdkInfo, IEnumerable`1 props, IEnumerable`1 customProps) in /_//src/Ionide.ProjInfo/Library.fs:line 576
   at Ionide.ProjInfo.ProjectLoader.getLoadedProjectInfo(String path, FSharpList`1 customProperties, LoadedProject project) in /_//src/Ionide.ProjInfo/Library.fs:line 645
   at Program.ProjectInfo.tryOfProject(FSharpList`1 additionalMSBuildProps, String file) in D:\a\Adaptify\Adaptify\src\Adaptify.Compiler\Program.fs:line 66
   at [email protected](String projFile) in D:\a\Adaptify\Adaptify\src\Adaptify.Compiler\Program.fs:line 294
   at Microsoft.FSharp.Collections.ArrayModule.Choose[T,TResult](FSharpFunc`2 chooser, T[] array) in D:\a\_work\1\s\src\FSharp.Core\array.fs:line 631
   at Program.main(String[] argv) in D:\a\Adaptify\Adaptify\src\Adaptify.Compiler\Program.fs:line 292

CheapEquals for HashMap/etc.

expose in FSharp.Data.Adaptive...
maybe a special implementation for diffing too...

Fable Compat

Core needs to be fable-able

msbuild logging

better logging (currently none)

Namespaces

Implement proper namespace/module handling

Shallow equality for structs

Currently using unchecked equals

For large projects Intellisense oversees model changes

might be a race condition on generation/update mechanism.

workaround

• touch files manually

solution strategy:

• touch files after generations
• drawback: files are touched.

will add file touching as optional feature to check out how it works out.

Support for dotnet 5?

Installation currently fails on SDK 5.0.102 with:

example.fsproj: [NU1202] Package adaptify 1.0.3 is not compatible with net5.0 (.NETCoreApp,Version=v5.0). Package adaptify 1.0.3 supports:
  - netcoreapp2.1 (.NETCoreApp,Version=v2.1) / any
  - netcoreapp2.2 (.NETCoreApp,Version=v2.2) / any
  - netcoreapp3.0 (.NETCoreApp,Version=v3.0) / any
  - netcoreapp3.1 (.NETCoreApp,Version=v3.1) / any

Namespace module bug

Generic unions

implement

Properties on union types

Implement via interface members and bind on container type

Adaptify does not work with .net 4.7.2

build and design time runs get different hashes because of dozens of satellite references placed in build as opposed to design time builds.

resolution idea: prune satellites from hashing.
other ideas: not easy as satellites are needed for ordinary builds and we are in legacy world here.

HashSet primarykey

implement or drop entirely?
@haraldsteinlechner @ThomasOrtner

Generated code does not build with VS 2022

Repository: https://github.com/aardvark-platform/aardvark.media

Just make names in as patterns lower case?