Better Dynamic Fields Solution #107

mrut2pac · 2021-04-01T00:45:05Z

Moved the field parsing methods into a helper class and updated some of the references
Added all "dynamic" field properties to IUpdateSummaryMessage, marking the DynamicFields property as a candidate for removal
Added NotImplementedException throwing stubs for the added "dynamic" properties for UpdateSummaryMessage and UpdateSummaryDynamicMessage classes
Added new static class that allows generating UpdateSummaryMessage implementations classes on the fly for the selected dynamic fields. Used advanced IL code generation from Reflection.Emit. Tried my best to add enough comments to make the code reading less of a nightmare. :)
Added unit tests to cover all of the functionality for the generated objects
Added a new Level1MessageUniversalHandler which utilizes the runtime generated classes and allows changing the dynamic fields without need to recreate the client
Added an example how to use Level1MessageUniversalHandler
Added references to System.Reflection.Emit and System.Reflection.Emit.ILGeneration packages in the client project
Added few methods to StringExtensions to shortcut the IL code generation

…me of the references 2. Added all "dynamic" field properties to IUpdateSummaryMessage, marking the DynamicFields property as a candidate for removal 3. Added NotImplementedException throwing stubs for the added "dynamic" properties for UpdateSummaryMessage and UpdateSummaryDynamicMessage classes 4. Added new static class that allows generating UpdateSummaryMessage implementations classes on the fly for the selected dynamic fields. Used advanced IL code generation from Reflection.Emit. Tried my best to add enough comments to make the code reading less of a nightmare. :) 5. Added unit tests to cover all of the functionality for the generated objects 6. Added a new Level1MessageUniversalHandler which utilizes the runtime generated classes and allows changing the dynamic fields without need to recreate the client 7. Added an example how to use Level1MessageUniversalHandler 8. Added references to System.Reflection.Emit and System.Reflection.Emit.ILGeneration packages in the client project 9. Added few methods to StringExtensions to shortcut the IL code generation

src/IQFeed.CSharpApiClient.Examples/Examples/StreamingLevel1/StreamingLevel1UniversalExample.cs

mathpaquette · 2021-04-01T11:45:39Z

@mrut2pac I think we need some kind of benchmark to support this improvement no?

mathpaquette · 2021-04-01T11:54:16Z

@mrut2pac I was not expecting to change the default non dynamic interface (IUpdateSummaryMessage) at least for now. Is there a way that we can merge your PR without impacting this one and just when we use DynamicFields ? Just wondering,

mrut2pac · 2021-04-01T22:08:10Z

@mrut2pac I was not expecting to change the default non dynamic interface (IUpdateSummaryMessage) at least for now. Is there a way that we can merge your PR without impacting this one and just when we use DynamicFields ? Just wondering,

My changes were 100% backwards compatible, except for the case if someone has a logic of listing the IUpdateSummaryMessage fields using reflection. Using DynamicFields won't work cause it is a class and not interface.
I added a new interface that adds the dynamic fields on top of IUpdateSummaryMessage and for now the caller has to cast the received message to access the new fields. Hope this will suffice.

mrut2pac · 2021-04-01T22:18:02Z

@mrut2pac I think we need some kind of benchmark to support this improvement no?

For memory it is obvious that the new solution is better since it creates objects with less number of fields (except when you select all fields, then it will be the same). In terms of CPU usage, I ensured that the generated IL code for each concrete class is practically the same set of instructions (only negligible differences that only affect the compiled IL code size), since there are no loops and branching compared to the current solution where we have to make a check for every field to see if it is included or not (or if the value is different than the default), it "SHOULD" be faster or at least achieve same speed.
I agree that benchmarking would have been nice, but unfortunately I don't have more time to spend on this.
Already went above my initial estimate. :)

mathpaquette · 2021-04-02T01:22:15Z

@mrut2pac I think we need some kind of benchmark to support this improvement no?

For memory it is obvious that the new solution is better since it creates objects with less number of fields (except when you select all fields, then it will be the same). In terms of CPU usage, I ensured that the generated IL code for each concrete class is practically the same set of instructions (only negligible differences that only affect the compiled IL code size), since there are no loops and branching compared to the current solution where we have to make a check for every field to see if it is included or not (or if the value is different than the default), it "SHOULD" be faster or at least achieve same speed.
I agree that benchmarking would have been nice, but unfortunately I don't have more time to spend on this.
Already went above my initial estimate. :)

thats very good and interesting work I have to say. few questions though. (just doing my devil advocate here)

there's a slight performance hit carrying out unused properties for UpdateSummaryMessage, observed it using Level1MessageHandlerPerformanceTests after and before your changes. Just wondering if it would make sense to whether create a new Level1Client like Level1ClientDynamic able to deal with UpdateSummaryMessage with this new set of properties OR make Level1Client generic like we've done float, double, decimal before. Personally, from a user perspective, I think its more convenient the first option but what are your thoughts on this.
checking ILevel1Event, do you think having Summary and Update using IUpdateSummaryMessage instead of the class still relevant?
do you think there's some duplication between StreamingLevel1DynamicExample and StreamingLevel1UniversalExample can we combine both? Like keeping both seems to be a little bit overkill. Not sure I like the term Universal...

mathpaquette · 2021-04-02T01:30:12Z

@mrut2pac I was not expecting to change the default non dynamic interface (IUpdateSummaryMessage) at least for now. Is there a way that we can merge your PR without impacting this one and just when we use DynamicFields ? Just wondering,

My changes were 100% backwards compatible, except for the case if someone has a logic of listing the IUpdateSummaryMessage fields using reflection. Using DynamicFields won't work cause it is a class and not interface.
I added a new interface that adds the dynamic fields on top of IUpdateSummaryMessage and for now the caller has to cast the received message to access the new fields. Hope this will suffice.

Yes sorry, I was checking the code on my phone :)

src/IQFeed.CSharpApiClient/Common/FieldParser.cs

mathpaquette · 2021-04-02T01:34:50Z

src/IQFeed.CSharpApiClient/Streaming/Level1/Handlers/Level1MessageUniversalHandler.cs

+using System;
+using IQFeed.CSharpApiClient.Streaming.Level1.Messages;
+
+namespace IQFeed.CSharpApiClient.Streaming.Level1.Handlers


can we mark the other one deprecated ?

we sure can

mathpaquette · 2021-04-02T01:36:33Z

src/IQFeed.CSharpApiClient/Streaming/Level1/Messages/IUpdateSummaryMessage.cs

@@ -20,6 +20,8 @@ public interface IUpdateSummaryMessage
        double Close { get; }
        string MessageContents { get; }
        string MostRecentTradeConditions { get; }
+
+        // TODO: drop this for the next MAJOR version, once we migrate to the new solution


mark it deprecated?

sure, let's decide if we are OK adding the new fields to IUpdateSummaryMessage or we still want to keep the new interface.
I will make this change

mathpaquette · 2021-04-02T01:48:06Z

@BunkerCoder what do you think?

mrut2pac · 2021-04-02T04:05:23Z

@mrut2pac I think we need some kind of benchmark to support this improvement no?

For memory it is obvious that the new solution is better since it creates objects with less number of fields (except when you select all fields, then it will be the same). In terms of CPU usage, I ensured that the generated IL code for each concrete class is practically the same set of instructions (only negligible differences that only affect the compiled IL code size), since there are no loops and branching compared to the current solution where we have to make a check for every field to see if it is included or not (or if the value is different than the default), it "SHOULD" be faster or at least achieve same speed.
I agree that benchmarking would have been nice, but unfortunately I don't have more time to spend on this.
Already went above my initial estimate. :)

thats very good and interesting work I have to say. few questions though. (just doing my devil advocate here)

there's a slight performance hit carrying out unused properties for UpdateSummaryMessage, observed it using Level1MessageHandlerPerformanceTests after and before your changes. Just wondering if it would make sense to whether create a new Level1Client like Level1ClientDynamic able to deal with UpdateSummaryMessage with this new set of properties OR make Level1Client generic like we've done float, double, decimal before. Personally, from a user perspective, I think its more convenient the first option but what are your thoughts on this.

checking ILevel1Event, do you think having Summary and Update using IUpdateSummaryMessage instead of the class still relevant?

do you think there's some duplication between StreamingLevel1DynamicExample and StreamingLevel1UniversalExample can we combine both? Like keeping both seems to be a little bit overkill. Not sure I like the term Universal...

Thanks!

I'd personally prefer setting the needed fields when creating a client via factory and live with it. If you need to change it just create a new client with the new fields set. Currently, both mine and your existing dynamic solutions are suffering from a possible Race condition - if you change the fields set while there is something already on watch there is a possibility of crashing the application or, what is worse, getting wrong data. I don't see much benefit of supporting on the fly changes, because most applications would just select the desired set of fields on startup and always use them. So yes, I'd vote for creating a new client which gets the list of fields during initialization and doesn't allow changing it later.
You mentioned a performance hit - is the new solution slower or the old one?
If you ask me, I'd move back all the dynamic fields into IUpdateSummaryMessage and remove the new interface. With new solution I don't see why anyone wouldn't want to use dynamic fields. I'd deprecate the Level1DynamicFields property and remove it in the next major version.
As far as ILevel1Event I think we can add few extra events there - allowing client to hook into any exception that could be thrown while parsing the messages received from IQ feed. Currently the application crashes when you throw exception from any of these handlers. An unhandled exception hits the async socket receiver thread and kills it. Why not protect it and feed the exception to the client? This way the use can at least log the exception details, or in some cases even handle it and continue.
There certainly is a lot of duplication in the example code, we can consolidate it when we decide how to finalize the solution, I wanted to have it there in order to demonstrate (read show off) the new capabilities. :)
The name Universal should definitely go away and we should stick with Dynamic, I just didn't want to have DynamicV2 or anything like that. An initially I was thinking it can support both versions, until I thought about the race condition.

mathpaquette · 2021-04-02T13:06:11Z

@mrut2pac check Level1MessageHandlerPerformanceTests class and run it on master and your branch. It takes slightly more time on yours probably because of the additional properties on UpdateSummaryMessage.

I'm not talking about the Dynamic Fields at all. Seems that even Level1MessageHandler is impacted because the set of new fields.

mathpaquette · 2021-04-02T13:20:28Z

I'd personally prefer setting the needed fields when creating a client via factory and live with it. If you need to change it just create a new client with the new fields set. Currently, both mine and your existing dynamic solutions are suffering from a possible Race condition - if you change the fields set while there is something already on watch there is a possibility of crashing the application or, what is worse, getting wrong data. I don't see much benefit of supporting on the fly changes, because most applications would just select the desired set of fields on startup and always use them. So yes, I'd vote for creating a new client which gets the list of fields during initialization and doesn't allow changing it later.
Makes sense.
You mentioned a performance hit - is the new solution slower or the old one?
check Level1MessageHandlerPerformanceTests class and run it on master and your branch. It takes slightly more time on yours probably because of the additional properties on UpdateSummaryMessage.
I'm not talking about the Dynamic Fields at all. Seems that even Level1MessageHandler is impacted because the set of new fields.
If you ask me, I'd move back all the dynamic fields into IUpdateSummaryMessage and remove the new interface. With new solution I don't see why anyone wouldn't want to use dynamic fields. I'd deprecate the Level1DynamicFields property and remove it in the next major version.
SOrry which interface are you talking about?
As far as ILevel1Event I think we can add few extra events there - allowing client to hook into any exception that could be thrown while parsing the messages received from IQ feed. Currently the application crashes when you throw exception from any of these handlers. An unhandled exception hits the async socket receiver thread and kills it. Why not protect it and feed the exception to the client? This way the use can at least log the exception details, or in some cases even handle it and continue.
Not sure for exceptions. The idea here is to avoid all of them to avoid Try Catch blocks. The way it has been design from the start, all handlers should be resilient to incorrect data.
There certainly is a lot of duplication in the example code, we can consolidate it when we decide how to finalize the solution, I wanted to have it there in order to demonstrate (read show off) the new capabilities. :)
ok we can live with that for now
The name Universal should definitely go away and we should stick with Dynamic, I just didn't want to have DynamicV2 or anything like that. An initially I was thinking it can support both versions, until I thought about the race condition.
Cool

src/IQFeed.CSharpApiClient/Streaming/Level1/Messages/UpdateSummaryMessage.cs

mathpaquette · 2021-04-02T13:40:52Z

@mrut2pac I think we are very close to merge this. Can we get on the same page for the next small refactor about passing dynamic fields in the constructor ?

I was thinking to have a Level1DynamicClient that supports your new Handler and instead of creating all these new properties in existing UpdateSummaryMessage we could have a new UpdateSummaryDynamicMessage and this one will be available in ILevel1Event as a generic for your new Handler. What do you think? That way, there's a clear separation. Personally, I dont use dynamic fields so, I'd prefer to have the leanest possible path.

Any thoughts ?

mrut2pac · 2021-04-02T20:52:11Z

Level1MessageHandlerPerformanceTests

The current version doesn't have any new fields and I'm getting my branch run slower than master for Debug but faster with Release. Since there is nothing changed for this test at the moment I am inclined to ignore the slight variations as statistically insignificant. :) I will look to write similar test for the current dynamic and new solutions, would be interesting to compare.
*** Update:
Actually I just realized the parsing code is changed. Interestingly the Release build runs faster...
Are you sure you want to keep the code duplication across the board and not use FieldParser?
I think we should use the FieldParser...

mrut2pac · 2021-04-02T21:01:03Z

@mrut2pac I think we are very close to merge this. Can we get on the same page for the next small refactor about passing dynamic fields in the constructor ?

I was thinking to have a Level1DynamicClient that supports your new Handler and instead of creating all these new properties in existing UpdateSummaryMessage we could have a new UpdateSummaryDynamicMessage and this one will be available in ILevel1Event as a generic for your new Handler. What do you think? That way, there's a clear separation. Personally, I dont use dynamic fields so, I'd prefer to have the leanest possible path.

Any thoughts ?

Have you looked at my latest version? There is IUpdateSummaryDynamicMessage interface and generated object now implement it.

Personally, I dont use dynamic fields so, I'd prefer to have the leanest possible path.

Are you using every single field from IUpdateSummaryMessage? If you don't you can still benefit by omitting the unneeded ones...

I will find time and create a new client to work with the new handler.

mathpaquette · 2021-04-02T21:49:14Z

Level1MessageHandlerPerformanceTests

The current version doesn't have any new fields and I'm getting my branch run slower than master for Debug but faster with Release. Since there is nothing changed for this test at the moment I am inclined to ignore the slight variations as statistically insignificant. :) I will look to write similar test for the current dynamic and new solutions, would be interesting to compare.
*** Update:
Actually I just realized the parsing code is changed. Interestingly the Release build runs faster...
Are you sure you want to keep the code duplication across the board and not use FieldParser?
I think we should use the FieldParser...

okay lets try that.

mathpaquette · 2021-04-02T22:08:53Z

@mrut2pac do you want to wait for the new client or you want to merge this ASAP?

…me of the references 2. Added all "dynamic" field properties to IUpdateSummaryMessage, marking the DynamicFields property as a candidate for removal 3. Added NotImplementedException throwing stubs for the added "dynamic" properties for UpdateSummaryMessage and UpdateSummaryDynamicMessage classes 4. Added new static class that allows generating UpdateSummaryMessage implementations classes on the fly for the selected dynamic fields. Used advanced IL code generation from Reflection.Emit. Tried my best to add enough comments to make the code reading less of a nightmare. :) 5. Added unit tests to cover all of the functionality for the generated objects 6. Added a new Level1MessageUniversalHandler which utilizes the runtime generated classes and allows changing the dynamic fields without need to recreate the client 7. Added an example how to use Level1MessageUniversalHandler 8. Added references to System.Reflection.Emit and System.Reflection.Emit.ILGeneration packages in the client project 9. Added few methods to StringExtensions to shortcut the IL code generation

mrut2pac · 2021-04-03T21:12:15Z

I am still working on it. I wrote the new client and separated the common code. Still got to fo few things. Please wait. Regards, Vardan
…
On Apr 3, 2021, at 7:26 AM, Mathieu Paquette @.***> wrote: @mrut2pac do you want to wait for the new client or you want to merge this ASAP? @mrut2pac are we ready to merge this one? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

@mrut2pac Ill merge protocol 6.1 PR first. @NichUK proposed that for a while and now almost ready. We might have some minor conflicts afterward.

No worries, if you are ready to merge please go ahead. I will fix the conflicts in my branch, if any.

mathpaquette · 2021-04-04T00:10:14Z

@mathpaquette finalized the solution.

Refactored to completely separate this new Dynamic flow. Refactored some of the existing classes to minimize the code duplication. When we remove the old dynamic code we can clean it up even more.

Added performance tests to cover both old and new dynamic handler.

The new code generated is much faster than the old dynamic code and is even slightly faster than UpdateSummaryMessage parse code when the standard set of fields are selected. The difference is much more drastic in Debug build. For Release the compiler helps to optimize it, but still my code beats it.
Here are some stats:
https://docs.google.com/spreadsheets/d/1DkrHW9Doyc_gs2xz0Q90CsulqmUEeshAgrXZlv23_Dw/edit?usp=sharing

Please let me know what you think.

P.S. a kind ask - next time please let me do the reverse merge from master to my branch as it will reduce the thrash and iterations if I do it at the right time ;)

sorry about it... i wont to it again, or at least without notifying you.

mathpaquette · 2021-04-04T13:42:47Z

I am still working on it. I wrote the new client and separated the common code. Still got to fo few things. Please wait. Regards, Vardan
…
On Apr 3, 2021, at 7:26 AM, Mathieu Paquette @.***> wrote: @mrut2pac do you want to wait for the new client or you want to merge this ASAP? @mrut2pac are we ready to merge this one? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

@mrut2pac Ill merge protocol 6.1 PR first. @NichUK proposed that for a while and now almost ready. We might have some minor conflicts afterward.

No worries, if you are ready to merge please go ahead. I will fix the conflicts in my branch, if any.

Okay just merged, please rebase yours, Ill merge it as well.

mrut2pac · 2021-04-04T17:44:19Z

I am still working on it. I wrote the new client and separated the common code. Still got to fo few things. Please wait. Regards, Vardan
…
On Apr 3, 2021, at 7:26 AM, Mathieu Paquette @.***> wrote: @mrut2pac do you want to wait for the new client or you want to merge this ASAP? @mrut2pac are we ready to merge this one? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

@mrut2pac Ill merge protocol 6.1 PR first. @NichUK proposed that for a while and now almost ready. We might have some minor conflicts afterward.

No worries, if you are ready to merge please go ahead. I will fix the conflicts in my branch, if any.

Okay just merged, please rebase yours, Ill merge it as well.

done. thanks!

src/IQFeed.CSharpApiClient/Streaming/Level1/Level1Client.cs

mathpaquette · 2021-04-04T18:50:16Z

src/IQFeed.CSharpApiClient/Streaming/Level1/Level1Client.cs


        public void SelectUpdateFieldName(params DynamicFieldset[] fieldNames)
        {
            var dynamicFieldHandler = _level1MessageHandler as ILevel1MessageDynamicHandler;
            if (dynamicFieldHandler == null)
-                throw new Exception("Level1MessageDynamicHandler is required to use DynamicFields property.");
+                throw new Exception($"{nameof(Level1MessageDynamicHandler)} is required to enable Dynamic Fields!");


nice catch!

…tself

mathpaquette · 2021-04-04T18:56:46Z

src/IQFeed.CSharpApiClient/Streaming/Level1/Level1ClientBase.cs

@@ -3,8 +3,7 @@

 namespace IQFeed.CSharpApiClient.Streaming.Level1
 {
-    public class BaseLevel1Client
-
+    public abstract class BaseLevel1Client


nice! thanks

mathpaquette · 2021-04-04T18:59:14Z

src/IQFeed.CSharpApiClient/Streaming/Level1/ILevel1EventCommon.cs

+
+namespace IQFeed.CSharpApiClient.Streaming.Level1
+{
+    public interface ILevel1EventCommon


IBaseLevel1Event maybe... I dont know. Its minor. Lets review that later.
Lets merge this baby!

mathpaquette · 2021-04-04T19:04:36Z

@mrut2pac damn. I wanted to squash these commits... one second.

mathpaquette · 2021-04-04T19:11:25Z

@mrut2pac damn. I wanted to squash these commits... one second.

please re-create the PR from your branch.,

BunkerCoder · 2021-04-04T19:14:23Z

Nice work guys. Thanks! Quick heads-up.
I've been working on getting my test environment up-to-date so that I can do some testing on my live code.
Just updated to VS 16.9.3, and started getting missing NumberStyles and CultureInfo errors in Level1DynamicFields.cs.
Adding "using System.Globalization;" fixed it.
I haven't tracked down the root cause (probably something I goofed), but wanted to pass it along.

mrut2pac · 2021-04-04T19:18:18Z

@mrut2pac damn. I wanted to squash these commits... one second.

Jumped the gun, sorry :) created a new PR

mrut2pac · 2021-04-04T19:19:36Z

Nice work guys. Thanks! Quick heads-up.
I've been working on getting my test environment up-to-date so that I can do some testing on my live code.
Just updated to VS 16.9.3, and started getting missing NumberStyles and CultureInfo errors in Level1DynamicFields.cs.
Adding "using System.Globalization;" fixed it.
I haven't tracked down the root cause (probably something I goofed), but wanted to pass it along.

@BunkerCoder could you please check if you're on the latest? Might have been an intermediate state

fixes #116 #107

mathpaquette · 2021-04-04T19:24:21Z

@mrut2pac damn. I wanted to squash these commits... one second.

Jumped the gun, sorry :) created a new PR

HAHAHAH i'll call you lucky luke... pretty quick on the trigger!!! Merged now!! Thank you so much

BunkerCoder · 2021-04-04T19:27:18Z

Nice work guys. Thanks! Quick heads-up.
I've been working on getting my test environment up-to-date so that I can do some testing on my live code.
Just updated to VS 16.9.3, and started getting missing NumberStyles and CultureInfo errors in Level1DynamicFields.cs.
Adding "using System.Globalization;" fixed it.
I haven't tracked down the root cause (probably something I goofed), but wanted to pass it along.

@BunkerCoder could you please check if you're on the latest? Might have been an intermediate state

@mathpaquette - Per https://docs.microsoft.com/en-us/visualstudio/releases/2019/release-notes, it's the latest. Released 3/30/2021.

mathpaquette · 2021-04-04T19:30:42Z

@mrut2pac @NichUK quite a productive weekend.. Protocol 6.1 and now this live Dynamic client!! Congrats.

mathpaquette · 2021-04-04T19:37:38Z

Nice work guys. Thanks! Quick heads-up.
I've been working on getting my test environment up-to-date so that I can do some testing on my live code.
Just updated to VS 16.9.3, and started getting missing NumberStyles and CultureInfo errors in Level1DynamicFields.cs.
Adding "using System.Globalization;" fixed it.
I haven't tracked down the root cause (probably something I goofed), but wanted to pass it along.

@BunkerCoder could you please check if you're on the latest? Might have been an intermediate state

@mathpaquette - Per https://docs.microsoft.com/en-us/visualstudio/releases/2019/release-notes, it's the latest. Released 3/30/2021.

Probably a bad intermediate state .... Make sure you Clean solution and Build.. Usually it helps.
We dont merge anything without a successfully CI build in order to avoid such frustrating situation that the build doesnt pass :)

mrut2pac · 2021-04-04T19:42:32Z

Thanks guys and Happy Easter, if you're celebrating!

…

On Sun, Apr 4, 2021 at 12:30 PM Mathieu Paquette ***@***.***> wrote: @mrut2pac <https://github.com/mrut2pac> @NichUK <https://github.com/NichUK> quite a productive weekend.. Protocol 6.1 and now this live Dynamic client!! Congrats. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#107 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTDKSVOGAYC53YU634OHGLTHC463ANCNFSM42F4YCWQ> .

BunkerCoder · 2021-04-04T19:50:52Z

Nice work guys. Thanks! Quick heads-up.
I've been working on getting my test environment up-to-date so that I can do some testing on my live code.
Just updated to VS 16.9.3, and started getting missing NumberStyles and CultureInfo errors in Level1DynamicFields.cs.
Adding "using System.Globalization;" fixed it.
I haven't tracked down the root cause (probably something I goofed), but wanted to pass it along.

@BunkerCoder could you please check if you're on the latest? Might have been an intermediate state

@mathpaquette - Per https://docs.microsoft.com/en-us/visualstudio/releases/2019/release-notes, it's the latest. Released 3/30/2021.

Probably a bad intermediate state .... Make sure you Clean solution and Build.. Usually it helps.
We dont merge anything without a successfully CI build in order to avoid such frustrating situation that the build doesnt pass :)

@mathpaquette - I just pulled latest master (73d15c0), cleaned solution and rebuilt. Now I'm seeing "Merge conflict marker encountered" in Level1Client.cs, Level1DynamicFields.cs, and iUpdateSummaryMessage.cs.
Looks legit, but probably my issue again, Checking.

BunkerCoder · 2021-04-04T19:54:03Z

@mathpaquette - my mistake - those are on my side...I'll resolve. Sorry...

mathpaquette · 2021-04-04T19:54:32Z

Nice work guys. Thanks! Quick heads-up.
I've been working on getting my test environment up-to-date so that I can do some testing on my live code.
Just updated to VS 16.9.3, and started getting missing NumberStyles and CultureInfo errors in Level1DynamicFields.cs.
Adding "using System.Globalization;" fixed it.
I haven't tracked down the root cause (probably something I goofed), but wanted to pass it along.

@BunkerCoder could you please check if you're on the latest? Might have been an intermediate state

@mathpaquette - Per https://docs.microsoft.com/en-us/visualstudio/releases/2019/release-notes, it's the latest. Released 3/30/2021.

Probably a bad intermediate state .... Make sure you Clean solution and Build.. Usually it helps.
We dont merge anything without a successfully CI build in order to avoid such frustrating situation that the build doesnt pass :)

@mathpaquette - I just pulled latest master (73d15c0), cleaned solution and rebuilt. Now I'm seeing "Merge conflict marker encountered" in Level1Client.cs, Level1DynamicFields.cs, and iUpdateSummaryMessage.cs.
Looks legit, but probably my issue again, Checking.

Sorry earlier I force pushed on master to come back in a previous state. If you dont have any changes on master (technically should be the case) do this:

git fetch origin
git checkout master
git reset origin/master --hard

you will come back to HEAD

BunkerCoder · 2021-04-04T20:00:22Z

Nice work guys. Thanks! Quick heads-up.
I've been working on getting my test environment up-to-date so that I can do some testing on my live code.
Just updated to VS 16.9.3, and started getting missing NumberStyles and CultureInfo errors in Level1DynamicFields.cs.
Adding "using System.Globalization;" fixed it.
I haven't tracked down the root cause (probably something I goofed), but wanted to pass it along.

@BunkerCoder could you please check if you're on the latest? Might have been an intermediate state

@mathpaquette - Per https://docs.microsoft.com/en-us/visualstudio/releases/2019/release-notes, it's the latest. Released 3/30/2021.

Probably a bad intermediate state .... Make sure you Clean solution and Build.. Usually it helps.
We dont merge anything without a successfully CI build in order to avoid such frustrating situation that the build doesnt pass :)

@mathpaquette - I just pulled latest master (73d15c0), cleaned solution and rebuilt. Now I'm seeing "Merge conflict marker encountered" in Level1Client.cs, Level1DynamicFields.cs, and iUpdateSummaryMessage.cs.
Looks legit, but probably my issue again, Checking.

Sorry earlier I force pushed on master to come back in a previous state. If you dont have any changes on master (technically should be the case) do this:
git fetch origin
git checkout master
git reset origin/master --hard
you will come back to HEAD

I should have seen that. Back to HEAD now. Clean/Rebuild All worked. Now I'm frozen trying to open Test Explorer...probably an issue in 16.9.3. I'll figure it out and let you know what happened.

Update - It's Windows... Reboot fixed it... Ran tests locally without failures (but we knew that because of CI...).
Thanks again.

mrut2pac added enhancement New feature or request architecture Architectural design related issue. labels Apr 1, 2021

mrut2pac requested a review from mathpaquette April 1, 2021 00:45

mrut2pac assigned mathpaquette Apr 1, 2021

Fixed the last minute messup

754c0b8

mathpaquette reviewed Apr 1, 2021

View reviewed changes

src/IQFeed.CSharpApiClient.Examples/Examples/StreamingLevel1/StreamingLevel1UniversalExample.cs Outdated Show resolved Hide resolved

BunkerCoder mentioned this pull request Apr 1, 2021

Level1 Dynamic Field Type Issue #104

Closed

Addressed some of the PR feedback

82f7a19

mathpaquette reviewed Apr 2, 2021

View reviewed changes

src/IQFeed.CSharpApiClient/Common/FieldParser.cs Show resolved Hide resolved

mathpaquette reviewed Apr 2, 2021

View reviewed changes

src/IQFeed.CSharpApiClient/Streaming/Level1/Messages/UpdateSummaryMessage.cs Show resolved Hide resolved

BunkerCoder mentioned this pull request Apr 2, 2021

Fix handling of Dynamic Field: Type #110

Merged

mrut2pac added 2 commits April 4, 2021 10:35

Merge branch 'master' into better-dynamic-fields-solution

32def98

fixed a minor merge issue

c5af97b

mathpaquette reviewed Apr 4, 2021

View reviewed changes

src/IQFeed.CSharpApiClient/Streaming/Level1/Level1Client.cs Outdated Show resolved Hide resolved

mathpaquette reviewed Apr 4, 2021

View reviewed changes

mrut2pac added 2 commits April 4, 2021 11:53

renamed the base client class

cab4c90

made the base class abstract since it is not intended to be used by i…

1fbfb94

…tself

mathpaquette reviewed Apr 4, 2021

View reviewed changes

mathpaquette approved these changes Apr 4, 2021

View reviewed changes

mrut2pac merged commit bda526f into master Apr 4, 2021

mathpaquette pushed a commit that referenced this pull request Apr 4, 2021

feat(streaming): improved Level1 dynamic client

73d15c0

fixes #116 #107

mrut2pac deleted the better-dynamic-fields-solution branch April 4, 2021 19:42

Better Dynamic Fields Solution #107

Better Dynamic Fields Solution #107

Conversation

mrut2pac commented Apr 1, 2021

mathpaquette commented Apr 1, 2021

mathpaquette commented Apr 1, 2021

mrut2pac commented Apr 1, 2021

mrut2pac commented Apr 1, 2021

mathpaquette commented Apr 2, 2021

mathpaquette commented Apr 2, 2021

mathpaquette Apr 2, 2021 • edited Loading

Choose a reason for hiding this comment

mrut2pac Apr 2, 2021

Choose a reason for hiding this comment

mathpaquette Apr 2, 2021

Choose a reason for hiding this comment

mrut2pac Apr 2, 2021

Choose a reason for hiding this comment

mathpaquette commented Apr 2, 2021

mrut2pac commented Apr 2, 2021

mathpaquette commented Apr 2, 2021 • edited Loading

mathpaquette commented Apr 2, 2021 • edited Loading

mathpaquette commented Apr 2, 2021

mrut2pac commented Apr 2, 2021 • edited Loading

mrut2pac commented Apr 2, 2021 • edited Loading

mathpaquette commented Apr 2, 2021

mathpaquette commented Apr 2, 2021

mrut2pac commented Apr 3, 2021

mathpaquette commented Apr 4, 2021

mathpaquette commented Apr 4, 2021

mrut2pac commented Apr 4, 2021

mathpaquette Apr 4, 2021

Choose a reason for hiding this comment

mathpaquette Apr 4, 2021

Choose a reason for hiding this comment

mathpaquette Apr 4, 2021

Choose a reason for hiding this comment

mathpaquette commented Apr 4, 2021

mathpaquette commented Apr 4, 2021

BunkerCoder commented Apr 4, 2021

mrut2pac commented Apr 4, 2021

mrut2pac commented Apr 4, 2021 • edited Loading

mathpaquette commented Apr 4, 2021

BunkerCoder commented Apr 4, 2021

mathpaquette commented Apr 4, 2021

mathpaquette commented Apr 4, 2021 • edited Loading

mrut2pac commented Apr 4, 2021 via email

BunkerCoder commented Apr 4, 2021

BunkerCoder commented Apr 4, 2021

mathpaquette commented Apr 4, 2021

BunkerCoder commented Apr 4, 2021 • edited Loading

mathpaquette Apr 2, 2021 •

edited

Loading

mathpaquette commented Apr 2, 2021 •

edited

Loading

mathpaquette commented Apr 2, 2021 •

edited

Loading

mrut2pac commented Apr 2, 2021 •

edited

Loading

mrut2pac commented Apr 2, 2021 •

edited

Loading

mrut2pac commented Apr 4, 2021 •

edited

Loading

mathpaquette commented Apr 4, 2021 •

edited

Loading

BunkerCoder commented Apr 4, 2021 •

edited

Loading