|
OMG! makes total sense! 
|
|
|
|
|
|
|
Definitely! 
|
|
|
|
|
hey, what about koalas?
so cute, they don't want to kill you,
they'll only give you tetanus, rabies and/or chlamydia.
Message Signature
(Click to edit ->)
|
|
|
|
|
Super Lloyd wrote: At any rate, I am now 6 months into my 3 months contract, going well, yeeha!  
Tomorrow completes week 69 in to my 2 - 4 week contract.
Michael Martin
Australia
"I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible."
- Mr.Prakash One Fine Saturday. 24/04/2004
|
|
|
|
|
Quote: I found my freedom
a paradise meant for me
I found my freedom, I found my freedom
Da dada 'n dee dee dee
Hold my head up and look to the sun
|
|
|
|
|
Super Lloyd wrote: Pays a lot more in Australia!
Good on you ! I'm sure you shear them sheep tenderly.
I'll probably need that loan pretty soon.
cheers, Bill
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
I am already slave to an home loan in a bust town 
The contract money is helping!
|
|
|
|
|
I thought DLR let you truly interpret .NET code?
Instead it's just more fancy wrappers around the compiler it looks like?
This means I can't support syntactic predicates or code behinds in my grammars at run time.
Code in the grammars would be limited to generated code.
Which *would* be acceptable except for the fact that the code makes the grammars work in the first place.
Meaning any code in any grammars renders the grammar unusable to the runtime parsers.
That's not okay to me. Why doesn't .NET let you interpret code finally?
I don't need a lot of it. Just a few lines here and there.
But now, because of this, if i were to support it, I'd need to make an elaborate caching system so as not to overrun the app with temporary assemblies, just like before the DLR came along.
Am I wrong?
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
It's not clear what you mean here...
the
"dynamic" object (which is a keyword for anything implementing..err.. some interface I forgot and has a powerful default implementation) can already call most method and property at runtime. You can also provide your own implementatino.
There is also Emit to generate code at runtime.
It's unclear here what is your beef, but I suspect you are wrong....
|
|
|
|
|
I'm not worried about how to generate code. I'm worried about the architecture of Win32 loading a zillion tiny DLLs into the process space over the course of my application in order to enable dynamic compilation
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
i wanted a way to run small amounts of code without any compilation going on. that's all. interpreted. like JS is.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Well.. What about reflection then?
You can call any method and any property. It doesn't emit any code / create DLL. It's "slow" as well. Perfect!
An example.
Under the hood XAML and Razor access random object's properties with that.
|
|
|
|
|
i'd still need to write my own interpreter.
Hey, you'll understand this because you've used TinyPG.
You know how tinyPG lets you put code in the grammars?
That's what this is about.
TinyPG does not do runtime parsing, only generated parsers.
Mine does both. For mine to also do the code in the grammars, and do it at runtime, i'd need to solve this problem.
The only solution i can think of is one that relies on an elaborate caching mechanism for these compiled code bits.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
I see....
Gonna think on that....
But what do you have against Emit?
It's no big deal to load of those generated code, is it now? Why does that concerns you?
|
|
|
|
|
I don't have anything against Emit. In fact, I love it.
What I do not love is win32's inability to unload a DLL once it has been mapped to a process' address space.
It's an understandable limitation but one that causes problems if you just start generating code willy nilly under .NET.
What you need to do is ensure you basically never generate the same code twice.
That requires caching. That complicates the code considerably.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
I see....
I can understand that could be a problem for very long running processes...
How about running them as Scheduled Task instead of non stop services? Just an idea...
|
|
|
|
|
That's the thing. I don't know how long the process will run. It's an API. It might very well be used in a service.
I much prefer to keep code out of grammars for precisely this problem, but almost all other parser generators support it.
And in using mine, there would be areas where it could come in handy, but if I'm doing it at all, I'm not doing it half cocked. I HATE leaks. Hate them. I come from a C++ world. Leaks are leaks. I don't care that they're not due to a pointer being unfreed - leaking process address memory by constantly loading and throwing away DLLs is a show stopper for me, frankly, in all but the shortest running apps.
So I don't understand why Microsoft is so cavalier about it in .NET. It's nonsense. I'm caching or I'm not doing it at all.
If I'm at least not generating the same code over and over again it's acceptable, but now I'd have to cache the grammars once they're loaded.
On the other hand, I *did* already implement value semantics for all my grammar objects (meaning my grammars themselves can already be dictionary keys)
So I guess it wouldn't be that hard. My problem is thread safety. It's true my system wasn't designed for it, but also I wasn't sharing a process wide cache system either! I at least want the thing to *work* from different threads without causing problems.
 so that's work.
You see what I'm getting at? This to me is bare minimum for what I'd consider acceptable in this scenario.
I assumed Expressions would already take care of that, but if it doesn't even do that, well, I may as well do it all myself and get full code behind support, not just expressions. ah well, it is what it is.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
What if it's all interpreted?
I.e. the piece of code in the grammar is either, generated .cs file or interpreted in memory, i.e. NO EMIT?
This way, no leaks! 
Though it's a bit more work for ya...
|
|
|
|
|
That's why the OP was a rant. I thought the DLR already did that. The truth is, even if I wanted to put in the work, i wouldn't trust C# to be fast enough to do it well where i need it done, and marshalling would kill any performance gain i'd get - that's why i was hoping the DLR already did this..
Like i said, with caching, this is acceptable - i'll take the hit on that as long as when i generate the parsers, the parsers aren't *then* emitting more code. I think i can manage that.
It's just more work and more clunky than i was hoping for. I thought DeclareDynamicMethod/DynamicAssembly was more special than it apparently is
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Adding, I do use reflection in this, but only in one area.
It allows you to define new transform classes to translate grammars to and from different formats.
It uses reflection to enumerate the available transforms and to invoke them.
But that's not time critical code.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
I'm sorry, but reading a paragraph per sentence makes my head hurt trying to string together your thought process here. Are you asking if the DLR supports .NET interpretation? If you are, then yes it does (sort of, as there is still a .NET generation phase going on underneath), as you can see through the DLR supporting REPL - without this capability, Microsoft would not have been able to create IronPython. If you really want to get your head around how it all works, have a read of this[^].
|
|
|
|
|
Can't do compilation here. Because I'm not going to implement the necessary caching to make it realistic.
Just dynamically compiling willy nilly throws a bunch of tiny DLLs into the windows process space and they never get unloaded.
So in order to work around that, one must cache any code they're compiling so they don't recompile the same code twice. Because if they do, their win32 space gets completely polluted with loaded DLLs that are no longer being used. And that number just keeps growing because win32 does not unload DLLs from a process's address space.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
It is possible to have multiple app domains handle this so you could potentially spin up a new AppDomain, run through the interpret phase and execute it, then tear down the AppDomain.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
