nuget packages and build script

[drslump]

Scripts to build and publish NuGet packages for Boo.

I've setup a test gallery to play with them, although I think you should publish them on the official NuGet repository for easier access.

You can use the following command to update them in the test gallery:

nant -D:nuget.feed=https://www.myget.org/F/drslump-testing -D:nuget.apikey=cf7f9f55-1784-4e77-a3fa-5a6c98ca24db publish

[rfvgyhn]

Any status on merging this? It would be nice to have the latest version of the assemblies and .exes from the official repo available on nuget.org.

I'm not sure if the owners of the existing packages include anyone that has write access to this repo. If not, maybe we could get them to add/transfer ownership to some boo-lang or boo-community nuget user.

I did notice that the existing boo.lang package would be a conflict. It looks like it packages all of the assemblies and .exes and not just the Boo.Lang assembly. Might need to rename the boo.lang.nuspec in this pull request to something else.

[masonwheeler]

Just looked this over, and it looks basically OK, except there are a bunch of out-of-date URLs that need to be updated. @drslump, care to take care of that?

@hmah It looks like you're the owner of the existing nuget package, and that your repo has a bunch of unmerged changes. Would you like to work with us to resolve this satisfactorily? :)

[hmah]

@masonwheeler what do you want me to do? Do you want to be an additional owner of the boo.lang package?

[masonwheeler]

@hmah I'm not sure. To be honest, I have zero experience with NuGet publishing; I've only ever interacted with it as a user. What I want to do is first figure out what the best solution would be, and then implement it.

First off, can you send some PRs for the features you've added? From the NuGet package description, it makes it look like you've published various features that aren't actually in the Boo language as defined by the Master repository. Having that kind of fragmentation around is a bit worrisome, and it would be nice to clear it up for starters...

[rfvgyhn]

My thoughts:

1. Merge @hmah's features into the master repo
2. Publish @drslump's nugets (this PR) to nuget with the Boo.Lang package renamed to Boo
3. Have all of the old packages that aren't composed of more than one assembly and don't have name collisions be marked obsolete, point to the new packages from this PR in the description and then be unlisted
   • Boo-Interpreter -> new Boo.Lang.Interpreter
4. Have all of the old packages that aren't composed of more than one assembly and do have name collisions include new ownership and be updated to the latest
   • Boo -> new renamed Boo.Lang
   • Boo.Lang.Useful -> new Boo.Lang.Useful
5. Have all of the old packages that are composed of more than one assembly become dependent/wrappers on the new base nugets from this PR
   • Boo-Compiler -> new Boo.Lang.Compiler
   • Boo (Compiler, Interpreter, and Shell) -> new booc, booi, booish, Boo.Lang.PatternMatching, Boo.Lang.Useful

I think that would cause the least amount of friction for the existing packages while still allowing the maintainers of the master repo to keep the packages up-to-date (ideally handled by travisci when master branch is tagged with new version).

The Boo-Compiler nuget could be marked obsolete as well but it seems to be relatively popular with about 15 downloads per day.

Just my two cents. :)

[hmah]

@masonwheeler: I understand that it's certainly the best that current developers of Boo have access to nuget package boo.lang. As far as I understand, I only need the nuget user names to add.
Regarding my changes: Well, that's more than 2 years away. Some further remarks are available at http://www.sieda.com/de-wAssets/en/docs/products/Boo-distrib/ .
Beside some fixes regarding e.g. fields of enumerations in attributes and some smaller extension to be more wrist friendly (keyword constructor does no longer require a preceeding def, macro getproperty defines a property with private setter), I have been mainly working on the booish because I was searching for a tool to use the .net framework interactively. So, I tried to improve command completion. For instance, pressing [TAB] in the following situation

>>> DateTime.A
will show the following list of alternatives:
1> def Add(value as timespan) as date
2: def AddDays(value as double) as date
3: def AddHours(value as double) as date
4: def AddMilliseconds(value as double) as date
5: def AddMinutes(value as double) as date
6: def AddMonths(months as int) as date
7: def AddSeconds(value as double) as date
8: def AddTicks(value as long) as date
9: def AddYears(value as int) as date
>>> DateTime.A

Now, users may use cursor up and down to select the methof to use.
Cursor up and down can be used to browse the history of input lines.
Descriptions of methods and classes now also show the content of eventually available XML documentation.

>>> d DateTime.AddSeconds
struct date:
def AddSeconds(value as double) as date
   """
   Gibt eine neue <see cref="T:System.DateTime" /> zurück, die die angegebene Anzahl der Sekunden zum Wert dieser Instanz addiert.
   Returns: Eine <see cref="T:System.DateTime" />, deren Wert die Summe aus der von dieser Instanz dargestellten Datums- und Uhrzeitangabe und der von <paramref name="value" /> dargestellten Anzahl von Sekunden ist.
   Param System.Xml.XmlAttribute: Eine Zahl, die aus ganzen Sekunden und dem Bruchteil einer Sekunde besteht.Der <paramref name="value" />-Parameter kann negativ oder positiv sein.
   """
>>>

Since creation of XML docs have not been supported by BOO (at least 2 years ago), I fixed option /doc of the compiler. So, I was able to add XML docs to a binary distribution.

>>> d interpreter
class InteractiveInterpreter(Boo.Lang.Interpreter.AbstractInterpreter):
    def constructor()
    def constructor(parser as Boo.Lang.Compiler.ICompilerStep)
    Ducky as bool:
        get
        set
...
   def Equals(obj as object) as bool
    """
    Bestimmt, ob das angegebene <see cref="T:System.Object" /> und das aktuelle <see cref="T:System.Object" /> gleich sind.
    Returns: true, wenn das angegebene <see cref="T:System.Object" /> gleich dem aktuellen <see cref="T:System.Object" /> ist, andernfalls false.
    Param System.Xml.XmlAttribute: Das <see cref="T:System.Object" />, das mit dem aktuellen <see cref="T:System.Object" /> verglichen werden soll.
    """
...
    def SuggestCompletionsFor(code as string) as Boo.Lang.Environments.EnvironmentBoundValue[of (Boo.Lang.Compiler.TypeSystem.IEntity)]
    """
    The code must contain a __codecomplete__ member reference as a placeholder to the suggestion. The return value is a an environment bound array of candidate members and/or namespaces to replace __codecomplete__.
    """

The docs in English come from the Boo code. Docs in German stem from my German installation of the .net framework.
In order to be able to produce some printable docs, I played around with ndoc. However, this project died in 2004, so I added the modified code to my github repo (tools/ndoc).
A new assembly booish.mod.os.dll enables use of simple commands like "ls", "type" etc. in the booish shell.
In order to enable more flexible configuration of booish, I added some additional options regarding imports etc. that can also be used in configuration file booish.rsp.

C:\> booish -h
booish [OPTIONS] [BooFile]*
-h/-help/--help        Print this information
-d/-debug/--debug      Turn on a mode printing debug information
-w                     Turn on mode showing warnings
-autoindent+           Turn on indention automatic (default)
-autoindent-           Turn off indention automatic
-colors-               Disable use of colors
-colors+               Enable use of colors
-s/-shell              Turn on shell mode. Accept shell commands without introducing slash
-r:BooFile             Interpret a BOO file on start
-r:AssemblyFile        Add reference to this assembly
-r:AssemblyPartialName Add reference to this assembly
-i:Namespace           Import a namespace
-i:Namespace Assembly  Import a namespace from an assembly

Furthermore, I maintained the Boo bindung of SharpDevelop 4.4, however I don't know, where I put the sources of these changes.
I found it quite difficult to maintain the code base, so I stopped my efforts at a state that somehow complied with my demands. In particular, console output of booish might show unexpected begaviour on multiline input.

[masonwheeler]

@hmah Those look like some definite improvements! I've actually got an open PR for fixing multiline in booish. It works well, except for introducing a bug that raises an unhandled exception. As soon as @KidFashion posts a fix for that, I plan to merge it. :)

[masonwheeler]

And the multiline fix is in.

@drslump Still hoping to hear back from you on this.

@hmah Can you split out your changes to the language and your improvements to Booish into two separate PRs and post them here so they can be evaluated and hopefully merged? 😄

[hmah]

@masonwheeler I'll try to do so. I do, however, not know when I will have time to review the commits.

[hmah]

@masonwheeler @rfvgyhn
I prepared Pull Request #147. I have not been able to pick and separate commits regarding compiler, docs, and booish. instead I merged with boo-lang/master. In BooCompiler.MetaProgrammingIntegration.Tests.dll tests meta_methods_with_macro and meta_methods_with_statement_modifier fail (because of a side effect in the compiler pipeline). Something I cannot fix and I cannot see how the changes in this commitment can cause these problems