microsoft / workbooks Goto Github PK

See PR #35.

Explicitly report both in logs and to the user when there are no known hosts available for connection.

See InitializeSimulatorAsync in iOSAgentProcess.

The last workbook type created should be the default selection.

• List items in tree
• Add existing items from file system
• Remove items from workbook

Cell 1

var x = 10

Cell 2

Console.WriteLine (x + y)

This results in an editor squiggly in Cell 2 against y. Now go back to Cell 1 and define y. As Cell 1 is being edited and y is defined, Cell 2 should reflect this. We need to chain the SourceTextContainer.TextChanged even to also raise it on the next cell until there are no more cells.

Given a .workbook file, implicitly reference a similarly named .csx file if it exists. For example, SomePage.workbook would implicitly #load "SomePage.csx" if it exists.

@lewing: If you load a WPF workbook on Mac it silently retargets to Console/Mono, it would be nice to have a way to detect this case and show the user a warning or error that this workbook may not work. This is particularly true for some NuGets that will install and fail at execution time.

I created a workbook with .NET Core in there, then on the UI, I switched to Mono and saved the result. The workbook is saved with "DotNetCore" as the platform

https://bugzilla.xamarin.com/show_bug.cgi?id=58655

Steps to Reproduce

1. Open a Xamarin.iOS app in VSmac.
2. Deploy to any non-5s simulator.
3. Try to use view picker.

Expected Behavior

Views highlight as you hover over them. Clicking a view selects it in the Inspector.

Actual Behavior

Total no-op.

Xcode 9 introduced new simulator chrome as well as the ability to run multiple simulators simultaneously.

We updated iOSSimulatorCoordinateMapper to handle these new options, but made a mistake. Although currently Workbooks always uses the iPhone 5s simulator, the Inspector cannot control the device being used and needs to support all devices.

So, we need to not filter out non-5s devices.

Additionally, we should introduce a way for the IDE (or the agent) to communicate to the Inspector client which simulator is being used so we can pick the right one if multiple devices are running.

We currently default to an iPhone 5S simulator. We should move this forward to iPhone X now that we require Xcode 9.

This is independent of device switching (#21).

Add some kind of global API like Keystore ["DocumentDB"] that would allow workbook authors a nice way to indicate to Workbooks that the user needs to provide some kind of auth key/token/whatever for the workbook to be functional.

We could use Roslyn to intercept the call to this API and prompt for/look up an already stored key and return it (e.g. the method/indexer/property call would simply be rewritten in the AST as a const string after the user responds to the UI, etc.)

Ideally this would merge all save prompts into one dialog. Closing several unsaved workbooks using the taskbar's "close all windows" is not a fun experience.

Console.be prefers NumberLock over Beep because of the casing. This is a regression in master compared to 1.1, and is presumably due to the Monaco bump.

@sandyarmstrong I wonder if microsoft/vscode@c02a8d0#diff-c736a6665daa725bb10fa992c14c5f81L152 is the culprit.

@sandyarmstrong Might be able to fix just by changing filtertext and/or sorttext for the completion items.

@sandyarmstrong Maybe related, long and haven't read through yet: microsoft/vscode#26096

Upgrading our build to Xcode 9 resulted in a number of surprises - notably every time we save our storyboard, most objects in the storyboard now explicitly instantiate a delegate.

This is problematic in Xamarin.Mac when using synthesized events - subscribing to a synthesized event results in Xamarin.Mac setting a proxy delegate to power the event raising. In the case where Xcode or event Cocoa (targeting the 10.13 SDK) provides a default delegate, Xamarin.Mac will throw an exception on event subscription because it cannot set the backing delegate.

While this seems to be an issue in Xcode/10.13/Xamarin.Mac, we should just avoid using C# events and use our own delegate implementations.

A number of known ones have been fixed, but there may still be more. We should manually audit the Mac code.

We should use /etc/paths.d instead of writing out a wrapper script to /usr/local/bin/workbook

We should automatically define preprocessor symbols on the submissions that map to the workbook's agent type and also standard target framework symbols:

https://docs.microsoft.com/en-us/dotnet/standard/frameworks

Examples

We should shove our CLI tool into %PATH on Windows.

@sandyarmstrong: Installer option

@bojanrajkovic: I don't see the need to put in an installer option--VSCode, Node, and a handful of other tools just do this automatically for you.

Default representation changes:

• ToString representation if the type itself overrides ToString (not a base type)

• ToString inline + collapsed members if a base type (not including System.Object) overrides ToString

• Otherwise just show collapsed members

We may be able to eliminate our base DependencyResolver and use RuntimeMetadataReferenceResolver, which probably handles the system (Mono + .NET Framework) GACs better than we do?

I believe this is Windows-only. Needs confirmation on both Mac and Windows though.

This needs to be confirmed. Was reported in Slack by @chkn at the end of June:

@chkn I'm trying to build a quick workbook, but every letter I press takes seconds 😞
@chkn Mac, 1.3 alpha 2, console
@chkn I have what appears to be a consistent repro here

@sandyarmstrong I've never seen laggy input on Mac. Consistent repros are awesome if you can give us the steps

@chkn it's while typing the path in #r .. I'm not sure if it's related to the actual directory it's in or not

@sandyarmstrong thanks. when you are typing in #r, we are doing a fair bit of searching for matching assemblies. It's possible we regressed on some of our optimizations there
@sandyarmstrong do you have time to file a bug?
@sandyarmstrong actually I'll just make a trello card

As reported in https://bugzilla.xamarin.com/show_bug.cgi?id=57596

We did this for the Workbooks icon but not Inspector. The iOS workbook app icons have a similar issue.

Opening https://github.com/xamarin/Workbooks/tree/master/graphics/urhosharp/custom-geometries/CustomGeometries.workbook or other large workbooks can take several seconds on Windows or Mac. Content should show up faster.

This is a meta issue that will probably result in several pull requests, and may get split up into additional issues.

It is time to implement a complete NuGet package management experience within Workbooks. We will take our inspiration from Visual Studio, where package management and search all happen from one rich UI.

The idea is to give users more information about the packages they install (before and after installation), to keep their workbooks updated, and to better warn them of package issues that are unique to Workbooks.

Package Manager (to replace current search UI)

Package list

• Title
• Author
• Download stats
• Installed version
• Latest available version
• Description
• Icon
• Overlay icon to indicate install/update status

Package details

• Uninstall button
• Update/install button
• Change version dropdown (actionable via Update button)
• Description
• Version
• Authors
• License
• Date published
• Project URL
• Report Abuse URL
• Tags
• Dependency list

Other Changes

Workbooks sidebar changes

• Show package dependency tree like VS
• Allow updating packages from sidebar, all or individually (and restart workbook app afterwards)
• Show package install/load errors in sidebar. Auto-expand nodes when errors occur.

Behavior

• We allow installing packages that don't bring in any references on this platform, since workbooks can change their target platform at any time. When this happens, warn the user. See https://forums.xamarin.com/discussion/comment/294918/#Comment_294918
  • One suggestion is to add error state to the sidebar tree, and auto-expanding nodes when errors occur.
  • Could also show a warning in the status area
• Eliminate #r code cells that are currently required to bring in NuGet assembly references.

Under the hood

• Support private feeds that require authentication
• Support exclude: all in workbook manifest (https://docs.microsoft.com/en-us/nuget/consume-packages/dependency-resolution)
• ClientSession.InstallPackageAsync should do its own error handling and reporting, since it is used in a few places now

The installer check for .NET Framework is broken on both Windows 7 and 8.1. 8.1's runtime error at least gives a download button.

This worked at one point. Need to run old installers and see when it stopped.

In the following scenario, I am getting signature help for method B and not the method A as I would expect.

A (│B (...))
   ↑
   cursor

From https://bugzilla.xamarin.com/show_bug.cgi?id=40655

The output of help could use some work when rendering methods with long signatures. Particularly signatures that have parameters with default values. Consider collapsing these. For instance:

public static Task<Image> ImageAsync (Stream stream, CancellationToken cancellationToken = default (CancellationToken))

Might render in help as

Task<Image> ImageAsync (Stream stream, …)

IntelliSense will actually show the full member completion.

@lewing mentions that it might happen if trying to switch from workbook tab to inspect view tab before the visual tree comes in from the agent.

Still happening with master on 6/20/2017. Does not require multiple workbooks. It might be more common if I switch tabs while code is executing but I'm not sure. I usually end up using the view menu to refresh the visual tree @lewing

Right now we just show the "agent terminated while evaluating" error message if we abort evaluation. We should instead [again] use/handle SubmissionExecutionStatus.Interrupted and show "evaluation was aborted" or something.

Users want to be able to pick their preferred device instead of being forced into an iPhone 5s (for example). It should also be possible to change the device for a workbook while it is running.

This work was mostly completed in an old branch, but was put on hold and needs to be rebased and finished.

Need to also make sure that our iOS workbook app works as expected on iPad.

Requirements

• Add new page to workbook
• Remove page from workbook
• Link between pages via markdown links

To Discuss

• Page references

Notably, we need to update the highlighter coordinate code to account for the new bezel, resizability, etc.

Notably this is an issue on .NET Core when using dynamic and some other features. We should probably have some default suppressions.

Says "run all cells up to and including this cell", but actually it only starts with itself if it thinks it can, and it always runs the cells below it too.

More details: https://forums.xamarin.com/discussion/comment/277421

new Regex ().$

Where the completion dropdown is at $, I am offered both static Regex members and instance members. I should only be offered instance members in this case.

Inspector needs us to ship Xamarin.Interactive.Wpf.dll in the same folder as the client EXE, even though the client no longer depends on that assembly. That's just where the Inspector extension knows to look for the WPF agent assembly.

There are a few goals here:

1. Begin defining the API a third party would use to provide their own workbook apps.
2. Break up our build so that identical components (such as the Android app and iOS app) do not have to take up build time on both Mac and Windows.
3. Make it possible to ship a smaller installer, and download large workbooks apps on-demand.
4. Allow us to ship a larger variety of workbook apps without worrying about bloating the installer.

There is a proof-of-concept branch that needs to be updated and migrated to the new repository. It begins the work of bundling workbook apps with their client support assemblies in NuGet packages, which would allow us to use NuGet as our distribution platform for workbook apps.

The proposed layout for such a NuGet package is:

/
  xamarin.workbooks/
    app/
      net45/ (typically able to share app everywhere)
      mac/ (use these if necessary)
      win64/
    client-support/ (AgentProcess, coord mapper, etc)
      net45/ (more likely to have these split)
      mac/
      win64/

The workbookapp.json file would be in xamarin.workbooks/app/{platform}/, and would make use of the appManagerAssembly property to name the client integration assembly that should be loaded from xamarin.workbooks/client-support/{platform}/.

Ideally we would move public API into Xamarin.Interactive.dll from Xamarin.Interactive.Client.dll, to prevent having multiple assemblies with public API.

If a diagnostic yields from a .csx file that has been #loaded we currently do not render the path of the file relative to the workbook.

Although Workbooks and Inspector clients are based on the same code, distributing them together is no longer helpful. The Inspector client and necessary agent files should be distributed with the the Inspector extension itself (which is already shipped as part of the Visual Studio Enterprise products), not with the Workbooks installers.

The current plan is to still build the Inspector client and the various agents out of the Workbooks git repo, but the build output for them would change into a NuGet package that the IDE extensions could consume.

Since this would add up to 100MB or so to each IDE's on-disk footprint, we need to get approval from IDE leads.

Additionally, we would want to keep shipping Inspector files in our installers until after the bundled Inspector IDE work hit the stable release channel.

Currently, you can zoom the 3D view on Mac with trackpad pinch, and on Windows you can use mouse drag plus some modifiers.

It would be nice if cmd+scrollwheel on Mac and ctrl+scrollwheel on Windows worked, like they do in most web browsers.

We currently install an SDK directory with Workbooks that isn't really necessary. The SDK assembly is available from https://www.nuget.org/packages/Xamarin.Workbooks.Integration.

We should publish xamarin-interactive.d.ts to npm so we can completely remove this from our install.

This will simplify #23 on Mac, to the point where we can completely eliminate /Library/Frameworks/Xamarin.Interactive.framework.

See https://github.com/dotnet/roslyn/blob/94ab292d2c79b1675de0d6ff0a7361ecfbf20cfb/src/Workspaces/Core/Portable/Shared/Extensions/ISymbolExtensions.cs#L649