PlugManager: bug in my design fixed.
FatFileSystem: completed the todo that said trailing periods should be ignored.
Buffer: Added __Memcpy plug so that String.Trim method compiles so that FAT code will compile.
Displays .Net Classes which have been plugged in a list. On selecting one, it displays the Cosmos classes that plug that .Net class and all the plugged/unplugged methods (including private/hidden methods).
You can select a plugged method and run it with all Null parameters to see what it does.
- VS error message when closing VS during a debugging session
- VS can now do multiple debugging session in a row without needing restart. Issues:
- Unhandled exceptions in DataReceived event handler caused UpPipe to break resulting in total loss of connection between AD7Process and ToolsWindows
- Added new code to clean out the Action handler that PipeServer uses. By holding onto the old Action reference, it was holding onto a reference to the old AD7Process instance thus reulting in all sorts of weird errors.
- VS crashes completely without VIX API - now just shows error message in Output window.
- Colours of text in Cosmos windows invisble in dark theme. Tenp fix: Bg colour forced to light,
- XSharo project referencing outdated libraries.
Slowly fixing the debugger...
- Single-level fields now work.
- "This" in locals window now works - this and #1 were related to SQLite issue that was just a bad line of code
- Arguments/Stack window now displays correct values. Used to display same value for both args and stack mistakenly.
Locals window now works! (For primitive types and pointers only.) Exceptions related to unrecognised (i.e. more complex) types should be caught and display as the local variable's value instead of causing VS to crash.
Autos window still causes instant VS crash.
Cosmos windows works.
Call Stack works (sort of...only ever displays current line)
Threads works (but there is only ever 1 thread so not very helpful)
Watch window is only capable of doing 1 watch result per break - step to next line to be able to run another - will look into why this is.
This is relatively stable but no to be considered complete. Currently supported:
1. Installing user/dev kit (as normal)
2. Creating C#/VB/F# projects (latter 2 untested)
3. Debugging a Cosmos project - see limitations list below.
Debugging limitations:
1. Breakpoints sometimes fail to be hit. Only known thing that may help is recompile everything.
2. Specific breakpoint failure case: If you try and place a breakpoint on or after a "while(true)" statement it is extremely unreliable.
Other limitations:
1. VMWare occasionally breaks. If you get "Internal error" messages, or if VS crashes (don't let Windows "fix" it) or if VMWare fails to load properly there is only one known & reliable solution: Re-run the VMWare installer and hit "Repair". No restart required. You won't lose your VMs or settings (AFAI can tell).
If it all breaks, feel free to rant at it ;)
Added two constructors one with TYpe and one with type name. However there is still some cases (a null or empty type name for example) that will make the IL2CPU task crash. Fixing this would require allowing IL2CPU tasks funneling back to MSBUILD some error messages instead of throwing an exception. This will be adressed in a future patch when we will plug the IL2CPU task with X# instead of the current assembler.
You can now embed a single quote character in an X# literal string provided you escape this character by preceding it with a backslash. For example :
var .DebugWaitMsg = 'Waiting for \'debugger\' connection...'
X# asm code generator now uses back quotes to surround literal strings in generated asm code. Back quote characters in X# literal strings are properly escaped if they aren't already. Double quotes characters ub X# literal strings don't trigger a NASM compilation error anymore.
Limitations :
- Bochs must be installed on the system. This is not checked as a prerequisite by the Builder.
- You will find a GuessForBochs Cosmos project under BlueSkeye user project folder that can be used to launch the Guess project under Bochs.
- You may have to fix manually the path for the following properties in Cosmos.bxrc file copied to the CosmosForBochs\Bin\Debug folder
* romimage
* vgaromimage
- The Cosmos project UI is not yet Bochs aware. If you do not use the GuessForBochs project you must manually edit your Cosmos project file to modify the following property in both the Debug and Release property group from the project file :
<Launch>Bochs</Launch>
You must also add the following properties in both the Debug and Release property group from the project file :
<BochsConfig>Cosmos.bxrc</BochsConfig>
<Bochs_Deployment>ISO</Bochs_Deployment>
<Bochs_Launch>Bochs</Bochs_Launch>
<Bochs_DebugEnabled>True</Bochs_DebugEnabled>
<Bochs_DebugMode>Source</Bochs_DebugMode>
<Bochs_IgnoreDebugStubAttribute />
<Bochs_VMwareEdition>Player</Bochs_VMwareEdition>
<Bochs_OutputPath>bin\Debug\</Bochs_OutputPath>
<Bochs_Framework>MicrosoftNET</Bochs_Framework>
<Bochs_UseInternalAssembler>False</Bochs_UseInternalAssembler>
<Bochs_TraceAssemblies />
<Bochs_EnableGDB>False</Bochs_EnableGDB>
<Bochs_StartCosmosGDB>false</Bochs_StartCosmosGDB>
<Bochs_Name>GuessForBochs</Bochs_Name>
<Bochs_Description>Use Bochs emulator to deploy and debug.</Bochs_Description>
<Bochs_VisualStudioDebugPort>Pipe: Cosmos\Serial</Bochs_VisualStudioDebugPort>
<Bochs_PxeInterface>192.168.43.1</Bochs_PxeInterface>
<Bochs_SlavePort>Serial: COM3</Bochs_SlavePort>
<Bochs_ShowLaunchConsole>False</Bochs_ShowLaunchConsole>
