metasharp Issue Tracker Rss Feed

Commented Issue: Memoization Fails for large input streams [29]

justinc — Sat, 04 Feb 2012 22:37:05 GMT

When the input stream become large (~1.1M nodes without children, or ~6K nodes with children) the ID used to track memos in the memo table ceases to be unique. This causes "garbage" production matches with no error reported.

Attached is a patch that uses a first-class key to identify the memos => survives largish inputs. It also places a test after memo retrieval to verify and fail if the memo does not refer to the expected input position. This can be removed once confidence is gained...
Comments: Committed #4e896f18ec7c I will wait for the grammar to reproduce this and make a test before closing this.

Edited Issue: Memoization Fails for large input streams [29]

justinc — Sat, 04 Feb 2012 22:37:05 GMT

Edited Issue: Memoization Fails for large input streams [29]

justinc — Sat, 04 Feb 2012 22:36:06 GMT

Commented Issue: Memoization Fails for large input streams [29]

justinc — Sat, 04 Feb 2012 18:47:52 GMT

When the input stream become large (~1.1M nodes without children, or ~6K nodes with children) the ID used to track memos in the memo table ceases to be unique. This causes "garbage" production matches with no error reported.

Attached is a patch that uses a first-class key to identify the memos => survives largish inputs. It also places a test after memo retrieval to verify and fail if the memo does not refer to the expected input position. This can be removed once confidence is gained...
Comments: Unfortunately with this patch the time it takes to run all the tests goes from about 15s to 30s on my laptop... I will run some perf analysis and see what I can do here.

Created Feature: Optional primitive [30]

justinc — Sat, 04 Feb 2012 00:33:49 GMT

Rules with the form "w x? y z" should be transformed into:

And(w, Optional(x, And(y, z))

Where optional has the form of "x y z | y z" except the productions are in the same scope as the original form.

Commented Issue: Memoization Fails for large input streams [29]

justinc — Thu, 02 Feb 2012 18:21:41 GMT

When the input stream become large (~1.1M nodes without children, or ~6K nodes with children) the ID used to track memos in the memo table ceases to be unique. This causes "garbage" production matches with no error reported.

Attached is a patch that uses a first-class key to identify the memos => survives largish inputs. It also places a test after memo retrieval to verify and fail if the memo does not refer to the expected input position. This can be removed once confidence is gained...
Comments: You mentioned that you had a script that was provoking the collisions earlier, do you have that handy by any chance? I would really like to create a unit test so I can ensure that it's fixed and that we're not regressing this issue...

Created Issue: Memoization Fails for large input streams [29]

Aethon — Thu, 02 Feb 2012 17:45:07 GMT

Edited Feature: nuget package [28]

justinc — Tue, 11 Oct 2011 15:44:40 GMT

Currently we are packaging the msbuild task in with the VS extension which results in a changing path every time the extension is updated, which causes errors for projects pointing to these assemblies. This is not a reasonable location for build dependencies. Installing these same assets into an administrator protected location is also not acceptable. The solution is to use nuget to deliver per-project dependencies.

The nuget package should:
* Contain only these files:
- MetaSharp.Transformation.dll
- MetaSharp.Build.dll
- MetaSharp.Build.targets
* Add an <Import /> to the project the package was referenced by to the .targets file.

The VS Extension should:
* have a dependency on Nuget
* have a project template that already includes the metasharp nuget package referenced and imported.
* not have a command to add meta# to a project (users will use nuget to do this instead).

The "build deploy" command should:
* place the nuget package into /deploy/$(Version)/$(Configuration)/ alongside the vsix file.

Edited Feature: nuget package [28]

justinc — Tue, 11 Oct 2011 15:44:01 GMT

Currently we are packaging the msbuild task in with the VS extension which results in a changing path every time the extension is updated, which causes errors for projects pointing to these assemblies. This is not a reasonable location for build dependencies. Installing these same assets into an administrator protected location is also not acceptable. The solution is to use nuget to deliver per/project dependencies.

The nuget package should:
* Contain only these files:
- MetaSharp.Transformation.dll
- MetaSharp.Build.dll
- MetaSharp.Build.targets
* Add an <Import /> to the project the package was referenced by to the .targets file.

The VS Extension should:
* have a dependency on Nuget
* have a project template that already includes the metasharp nuget package referenced and imported.
* not have a command to add meta# to a project (users will use nuget to do this instead).

The "build deploy" command should:
* place the nuget package into /deploy/$(Version)/$(Configuration)/ alongside the vsix file.

Created Feature: nuget package [28]

justinc — Tue, 11 Oct 2011 15:41:57 GMT

Currently we are packaging the msbuild task in with the VS extension which results in a changing path every time the extension is updated, which causes errors for projects pointing to these assemblies. This is not a reasonable location for build dependencies. Installing these same assets into an administrator protected location is also not acceptable. The solution is to use nuget to deliver per/project dependencies.

The nuget package should:
* Contain only these files:
- MetaSharp.Transformation.dll
- MetaSharp.Build.dll
- MetaSharp.Build.targets
* Add an <Import /> to the project the package was referenced by to the .targets file.

The VS Extension should:
* have a dependency on Nuget
* have a project template that already includes the metasharp nuget package referenced and imported.
* not have a command to add meta# to a project (users will use nuget to do this instead).

Created Issue: Grammar ItemTemplate should say "Meta# Grammar" [27]

justinc — Mon, 10 Oct 2011 16:59:09 GMT

In the item templates right now it just says "Grammar" but to the right it will say "Visual C# Items". The class item template does just say "Class" but that sort of implies that inside of that template is C# code for a class. Just saying "Grammar" implies that inside will be C# code but instead you get meta# code. Therefore the name should be "Meta# Grammar" to make that distinction more clear. Also the icon should be that of a codefile with the meta# logo (like the C# class template) instead of just the meta# logo.

Closed Issue: MetaSharp Console Window button should be in Windows menu [26]

justinc — Sat, 01 Oct 2011 19:55:20 GMT

Right now it's in a context menu off a project but it should be in with the list of other windows.
Comments: done.

Closed Task: MetaSharp.Build.Test should be built during "build test" [23]

justinc — Thu, 29 Sep 2011 02:50:19 GMT

This project should be run and tested when the "build test" command is issued at the command line.
Comments: obsolete. The project has been replaced by mocking msbuild in the unit test project.

Created Issue: MetaSharp Console Window button should be in Windows menu [26]

justinc — Sat, 03 Sep 2011 19:54:21 GMT

Right now it's in a context menu off a project but it should be in with the list of other windows.

Edited Feature: Generate C# from Lang AST [13]

justinc — Sat, 03 Sep 2011 19:53:06 GMT

In an attempt to replace the CodeDom we will need to generate C# ourselves. Write a grammar that visits a Lang AST and generates code into a textwriter service stored in the context.

Edited Feature: Implement interfaces in Lang. [18]

justinc — Sat, 03 Sep 2011 19:52:46 GMT

allow users to create interfaces using the lang grammar.

Edited Feature: Implement Enums in Lang. [19]

justinc — Sat, 03 Sep 2011 19:52:33 GMT

Allow users to declare enums in the Lang grammar. Syntax example:

public enum Values as int:
One,
Two,
Three = 3
end

Edited Feature: Implement quasi quotes for Lang. [21]

justinc — Sat, 03 Sep 2011 19:52:20 GMT

Quasi quotes return the ast of the generated code rather than the code itself. Example syntax:

string x = "foo";
CodeObject ast = [| public class $x: $y.Members end |];

The following would return a new CodeTypeMember(...) expression.

Closed Feature: InvalidTypeDeclaration node. [17]

justinc — Sat, 03 Sep 2011 19:47:21 GMT

Inside of the Lang namespace rule, if it fails to parse a block of code completely it should instead read it all and return an InvalidTypeDeclaration node (assume valid imports for now). Next a new grammar should be created that visits the code dom and looks for InvalidTypeDeclaration objects inside of namespaces and calls into an IErrorReporterService in a projection.

Put the new Grammar in /src/MetaSharp.Transformation/GrammarErrorReporter.g, the IErrorReporterService should go into /src/MetaSharp.Transformation.

Mock the error reporter in the unit tests. In other work items we will create an error reporter for the msbuild project and another for the VS project.
Comments: This functionality is now obsolete, in favor of using error logging behavior. Now we will produce valid types but the presence of errors is used to determine if it's valid or not.

Closed Feature: Statement rule should never return Fail. [22]

justinc — Sat, 03 Sep 2011 19:45:19 GMT

The statement rule should always read up to the next StatementEnd or BlockEnd. If it cannot find a valid Statement it should return an InvalidStatement.
Comments: All statements now uses error unless rule to ensure that Statement never returns Fail.