Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 03:14
    guaaug starred dotnet/orleans
  • 02:51
    adminnz commented #6093
  • 01:35
  • 01:35
    gongap starred dotnet/orleans
  • Dec 10 23:56
    lx09 starred dotnet/orleans
  • Dec 10 23:48

    sergeybykov on master

    CodeGen: fix ambiguous referenc… (compare)

  • Dec 10 23:48
    sergeybykov closed #6171
  • Dec 10 23:48
    sergeybykov closed #6165
  • Dec 10 23:44
    ReubenBond commented #6158
  • Dec 10 23:36
    ReubenBond commented #6160
  • Dec 10 23:28
    sergeybykov closed #6134
  • Dec 10 23:28
    sergeybykov commented #6134
  • Dec 10 23:27
    ReubenBond commented #6166
  • Dec 10 23:26
    sergeybykov milestoned #6169
  • Dec 10 23:26
    sergeybykov assigned #6169
  • Dec 10 23:26

    sergeybykov on master

    Make IFatalErrorHandler public … (compare)

  • Dec 10 23:26
    sergeybykov closed #6170
  • Dec 10 23:11
    ReubenBond milestoned #6171
  • Dec 10 23:11
    ReubenBond opened #6171
Veikko Eeva
@veikkoeeva
.DiscoverTypesInDirectory() would read all appropriate files in the directory and supply them as a list to the "most detailed API", I think.
Gutemberg Ribeiro
@galvesribeiro
this is something we don't want inside Orleans, imagine the developer consuming that?
Julian Dominguez
@jdom
ONLY if they care to load types very differently in each implementation... I would imagine that if they have built the whitelist, they will use it for both :)
also, not sure why app developers will target both platforms separately...
Gutemberg Ribeiro
@galvesribeiro
@veikkoeeva I'm not discussing even the assembly load issue, I'm mentioning the approach to make the port to .Net Standard
Veikko Eeva
@veikkoeeva
@galvesribeiro OK.
Too much awake.
Gutemberg Ribeiro
@galvesribeiro
hahah
@jdom we can't restrict the developer heheh
the same way we care about adding binding redirects or enforce user to add latest nugets, we can't enforce them to have #IF or not give them the ability to run on both environments, who knows what they are up to? :)
Julian Dominguez
@jdom
by that, then we must only support the MCD of the 2 platforms...
Gutemberg Ribeiro
@galvesribeiro
MCD?
Julian Dominguez
@jdom
all I'm saying is that 95% of the code should use the MCD, but there are a few features that we can leverage from each specific platform
maximum common denominator
Gutemberg Ribeiro
@galvesribeiro
ah ok
MDC here heaahahhaha
@jdom and example of that is Performance Counters... the user can add the Nugets for it if they want... but that is completely outside Orleans
Veikko Eeva
@veikkoeeva
What I have in my mind is that we have some pre-canned regular expressions. Then one of them could be name CurrentOrleansImplementation (I just made this up for the sake of this example). Regex currentImpl = new Regex(@"..."); var files = Directory.GetFiles(ysomePath, "*.dll").Where(path => reg.IsMatch(path)) and then feed this to the new implementation that works with a explicit list of files. This we we could have some predefined ones and one is free to supply ones own ones too. That "currentImpl" thing could, should, be wrapped so that if nothing is given, it works as currently. Or something like that
Gutemberg Ribeiro
@galvesribeiro
the core should run on both worlds without changes
actually
lets stop talk about both worlds... not it is a single world... .Net Standard
Veikko Eeva
@veikkoeeva
Then somewhere inside Orleans code we might need a #ifdef for CoreCLR and others on how to actually load the assemblies.
Gutemberg Ribeiro
@galvesribeiro
as long as we stay on top of it, we will have it running everywhere (that include even mobile phone - not that we should do that)
@veikkoeeva that is not necessary
Veikko Eeva
@veikkoeeva
@galvesribeiro Rephrasing that mobile phone looks like ARM processors to me, which could become quite crucial in industrial settings. That's where the really high-value IoT stuff is. That's systems that's inherently IoT since 80's, and some systems are actually that long.
The problem for this Azure strategy MS has is that they don't want to go the cloud. :)
Air gaps and all, factory floor systems built like ships with their compartments having firewalls and so forth.
In factories one problem is, for instance, that although one would like to have more sensors and chips, they would need to leech current from, say, control wires, which easily would cause too much fluctuation. Hmm, I have written about this before, just a sec...
Sergey Bykov
@sergeybykov
@galvesribeiro I skimmed through the discussion. Do you think we should not discover app assemblies at silo startup at all? Sorry, if I misunderstood.
Veikko Eeva
@veikkoeeva
These people are paranoid. They say outright the U.S. does spy their secrets and deliver data to the rival U.S. companies and the data will never leave their vaults.
Some of that is true too, naturally.
Which makes the Azure Pack, "user maintained datacentres" (as in Germany) quite a smart idea.
Gutemberg Ribeiro
@galvesribeiro
@sergeybykov besides for runtime codegen, why does we actually do that? I know I'm one of the ones which made a lot of voice here to have just the runtime codegen since @ReubenBond started developing it due to the several problems with VS cache, the orleans.codegen.cs not being correctly updated and other issues but, think straight, and given the current scenario of Roslyn, .Net Standard, the new way of "think", why would we need that?
Sergey Bykov
@sergeybykov
@galvesribeiro Why we do run time codegen or compile time one?
Gutemberg Ribeiro
@galvesribeiro
I mean, why we dynamicly load assemblies on silo startup? Runtime codegen is (today) a reason, but that could be made differently... I, and I think most of us, has the grain interfaces and implementation dlls both referenced on silo host so visual studio just put those assemblies (and their direct dependencies) on output... If you don't add the reference, you must copy everything there by yourself, which will probably reduce the productivity while developing your cluster and in production. the only reason dynamic assembly loading IMHO make sense, is if you can hot replace it later on...
I'm just advocating 2 things>
Sergey Bykov
@sergeybykov
The original reason for dynamic loading was they one doesn't need to rebuild the runtime/host for every change in their app code - grain assemblies.
Gutemberg Ribeiro
@galvesribeiro
  1. .Net Standard is an API spec that everyone will have to follow in a very soon future so we should be compliant with it if we want to run xplat
  2. Dynamic Assembly loading is something that makes not much sense in this scenario since we does not (and don't have plans) to support hot swap of grain assemblies
ok but, by hitting F5, you are going to build it
Sergey Bykov
@sergeybykov
@galvesribeiro Not if you run OrleansHost.exe or an equivalent.
Gutemberg Ribeiro
@galvesribeiro
and the grain dlls will be copied to the host output dir
ok but, who uses that? what is the clear scenario that you dont have a console/worker role today ?
Sergey Bykov
@sergeybykov
We were also interested in scenarios with dynamic loading of grain assemblies and providers.
Gutemberg Ribeiro
@galvesribeiro
ok
Sergey Bykov
@sergeybykov
I'm afraid of throwing baby with bath water here.
Fundamentally, silo code is a static runtime for app assemblies, so rebuilding it for every app change doesn't make a lot of sense to me.
Gutemberg Ribeiro
@galvesribeiro
I agree