by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Aaron Glover
    @aarondglover
    @paul1956 how much performance can be gained by unchecked math? One of the major reasons for unchecked math as I understand it is to improve performance - particularly on a block of code which is not expected to result in overflow exceptions. Is that your key driver for this feature?
    Aaron Glover
    @aarondglover
    Does anyone know of any work being done on a grpc VB.NET proxy generator?
    The solution this far seems to have a dedicated c# project for the proxy and DTO objects ... Native VB generator would improve the approachability of this for VB devs
    Cory Smith
    @DualBrain
    @aarondglover On the single instance front, let me put something together on that early in the week. I just need to pull some code out of one of my projects that handles this as I needed to find a work around due to a problem I found with single instance and click once updates.
    Paul M Cohen
    @paul1956
    @aarondglover that was not the direct reason for me. I did it because I inherited a lot of code that calls into C# to do unchecked math, things like hash and the call is a high overhead and I fully expect overflow.
    As far an single instance that really should be added to WinForms. A lot of VB code will break if it isn’t supported in Core 5.
    Paul M Cohen
    @paul1956
    @aarondglover I have a DLL that can translate the proxy and DTO objects if anyone wants.
    Aaron Glover
    @aarondglover
    @paul1956 Single instance isn't going to happen... Kathleen already stated as such.
    Is that your general C# to VB converter youve been working on? That sounds much more useful than the current online converters which seem to miss the mark more times than not these days....
    Wouldnt it be great if GRPC added support for VB projects natively. Conversion of the code is nice but generally not much more achieved when compared to just throwing the generated code into its own DLL is there?
    Aaron Glover
    @aarondglover
    I've reached out to GRPC team... There are no plans to support such an initiative... The answer... Just do it in c# and reference the Class Library ☹️
    It's disappointing but not surprising given that .NET core not moving forward with WCF or any other type of RPC, they're essentially recommending HTTP REST or GRPC moving forward. So for those wanting to develop with a more RPC type approach in visual basic - yet again we are forced to use C# for atleast some of the development.
    Paul M Cohen
    @paul1956
    @aarondglover yes. @jnm2 contributed the conversion to a standalone Async converter. Since it’s based on Roslyn it can get very close. Now that it does projects it can get much better as type resolution. I don’t know anything about GRPC so can’t comment on what’s needed. I assume it’s Open Source so I might take a look. Also don’t why why just referencing the library isn’t good enough to handle SingleInstance.
    Mohammad Hamdy Ghanem
    @VBAndCs
    I cloned ADG Roslyn fork to my PC. I think this is the VB we should evolve, but first we should wait to last MS VB update, then try to convince ADG to update his fork, then we can send PR to his fork if he is willing to be responsible for that, or someone of us can fork it and talk over this job. This doesn't mean he should do most of the work, but just keep all efforts summing in one fork. We Can call it VB.Core.
    I have an idea: Why doesn't every VB programmer send an issue to the MS user voice to ask to keep VB alive and evolving assuring they will not move on to C#? If they received a flood of at least 1 million issues, I think they will think twice!
    Aaron Glover
    @aarondglover
    @paul1956 I'm definitely going to look at your project to convert c#. Thanks!
    Regarding your comment about referencing the library... Do you mean why isn't referencing the C# library good enough?
    I don't have a huge issue with that. It works fine but it does require VB developers to switch to C# for atleast one project in your solution and it also adds to the futher "degradation" of VB.NET by the erosion of support in tooling etc. Death by a thousand cuts. My desire for VB native support in GRPC tooling is to continue to keep VB as an approachable language and platform for new developers.
    Aaron Glover
    @aarondglover
    RPC will remain a fundamental requirement in many cases and given this is the recommended path forward to achieve RPC in CORE applications, removing impediments/Complications such as switching to C# to develop the DTOs and/or generate proxy classes would be a positive step forward.
    Thoughts?
    @VBAndCs mobilising the VB community will always remain difficult. F# proved it can be done with a small team of dedicated, passionate people... That's the model we have to some how achieve and convince MSFT to adopt. How we achieve that is the million dollar question.
    I tend to agree with ADG that forking VB would represent a failure.
    Aaron Glover
    @aarondglover
    I feel like convincing product teams (Azure Functions comes to.mind) that they should create VB project templates, documentation and samples in VB is a commitment that can only be driven by MSFT. Language development should not cease but we should not thrive to have a myriad of new language features. Compatibility and the ability to consume or otherwise interact with C# libraries should be the most critical driver to change the VBLANG. That's just my two cents of course
    Paul M Cohen
    @paul1956
    @aarondglover sorry for the length, VB developers call libraries in C# all the time without knowledge. Even my converter needs a C# library for Unchecked math. I didn't write it, it is stable and I never expect to look at the code. If and when VB gets unchecked math I might get rid of it but there is really no need. When I worked on file VB IO for Winforms I ported the code which was trivial and then wrote many tests since none existed, naturally in VB. When I pushed the PR someone ported all the tests to C# which was a ridiculous waste of effort, so from that point I agree. I believe there are differences between F# and VB two are key. F# has dedicated resource with Repo merge permission and it is a separate repo from any other language. VB is tightly intertwined with C# and much code (and more every day) is shared. When I did a prototype for Unchecked I finished it and then went to merge with my current fork of Roslyn/Master I ran into many merge conflicts because the Roslyn team had combined more VB and C# code into C# interfaces. This appears to me to be done to continue allow VB to get the latest refactoring in VS which I love but it means, as one engineer said, every change to Roslyn is twice the work.
    Aaron Glover
    @aarondglover
    Referencing a library I don't mind, but the tooling requires me to create a C# project to define
    Mohammad Hamdy Ghanem
    @VBAndCs
    If C# code doesn't contain any new syntax feature that is required to complete the job, we can use a Vazor-style solution:
    Do it in VB.NET, and generate the C# necessary project at runtime
    Mohammad Hamdy Ghanem
    @VBAndCs
    So, we can mark some classes in VB with attributes to be converted to c# and added to that generated project., and the rest of vb code goes to a dll library referenced in the C# project. Paul can provide us with robust VB to C# converter Try to do that for Azure functions. Finally we will write all in VB.NET, and trick them with a generated C# project!
    Aaron Glover
    @aarondglover
    Whoa the level of understanding you guys have with Roslyn and code gen is far beyond me! Sounds impressive... Would be a cool extension for VS.
    Mohammad Hamdy Ghanem
    @VBAndCs
    I did nothing with Roslyn in ZML. You can generate every thing as a text (code and project files are text files after all. It would need a complex code to implement ZML with Roslyn code. So, if you use an existing VB to C# converter, all the rest work if to generate the expected text files that forms the C# project and its dependencies.
    If there is a final step to load and compile the project with Roslyn, we will seek assistance. But I think this is not necessary. We can just open the C# project manually for testing. After all the functional VB code is still in VB library projects and we can debug.
    Mohammad Hamdy Ghanem
    @VBAndCs
    Or at least make the whole thing a C# project template that adds the necessary VB libray skeleton, so we focus on VB only.
    Think like this, and the experience will evolve while you are working
    We can even hide the C# files from the solution explorer, and manipulate them with VB files where any change in them triggers a VB to C# converter that overwrite the C# files.
    Mohammad Hamdy Ghanem
    @VBAndCs
    The whole idea in short: write what you want, and output what they want, so every one is happy.
    Give it some thinking, and you'll find many easy solutions.
    Aaron Glover
    @aarondglover
    Yeah that approach certainly does open up many possibilities for tooling support etc
    Aaron Glover
    @aarondglover
    It's an approach which as an extension could interativly add new project types... Think of creating a new c# project from a template, then convert it to a VB proj... Fewer complaints about lack of template support
    Paul M Cohen
    @paul1956
    Compiling code with Roslyn is not difficult if you understand what compile options and flags you need (something that VS handles for you in the background, I just learned how to include a projectReference this week), I am still learning everything that is needed. I don't know what tooling is referred to by @aarondglover.
    Aaron Glover
    @aarondglover
    I was describing a non existent tool... The general approach outlined by @VBAndCs lends it's self well to an extension for visual studio to create VB projects from C# templates/wizards. This would overcome the problem of missing visual studio templates ... new VB projects could be created on the fly after using the C# project wizard/template
    Mohammad Hamdy Ghanem
    @VBAndCs
    A new overload resolution bug and a crash
    Mohammad Hamdy Ghanem
    @VBAndCs
    untitled1.jpg
    It's working now at basic level
    There are few things to perfect, such as not suggesting tags that can appear only once
    Paul M Cohen
    @paul1956
    According to WinForms Repo singleInstance is schedule for the 5.0 release. It doesn't look extremely difficult using the existing design and using existing Core IPC functionality, I don't see needing gRPC. It would be nice if it was moved out of VB namespace so it could be used by any language but that might be a stretch.
    Aaron Glover
    @aarondglover
    I thought Kathleen ruled it out. Said it wasn't going to happen.
    What IPC methods are available in Core? Named Pipes?
    Paul M Cohen
    @paul1956
    Named pipes and memory mapped files. In the repo updated Feb 20th it listed as core 5.0 milestone. It looks like < 100 lines of code in reference source and when I dropped it in as a trial there were only a few of unsupported functions most of which are in Repo except the actual remoting which has a workaround and 1 windows API call where source to call it is provided in C# but easily ports to VB. If someone want to partner that understands remoting it could be done in a day. Then it would need to a UI in Visual Studio as does many VB features that are already in WinForms but can’t be enabled.
    Mohammad Hamdy Ghanem
    @VBAndCs
    For willing contributors:
    I added a VbXmlCompletionProvider to this repo
    You can add these two files to your Roslyn fork, in the folder Completion/CompletionProviders in the project Microsoft.CodeAnalysis.VisualBasic.Features
    It will provide HTML5 auto completion in VB.NET XML Literals, but only inside the <vbxml></vbxml> tag.
    I did this for two reasons:
    1. not to mess with other xml literals that doesn't deal with html.
    2. to support Vazor.
      I will make a VSIX for this to allow install it as a VS extension (in progress now), but my aim from publishing this, is to allow contributors to build upon to provide a generic XML literals completion provider, based on the xsd that user supplies in the context as this missing feature was described in the docs