|
I am following your work with interest, and hoping that, at some point, you will explain what you are doing in more detail.
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
|
|
|
|
|
How to Make an LL(1) Parser: Lesson 1[^]
So that doesn't do it for you eh?
I don't know what to say. I pored over that. =D
Explained all the concepts, i thought.
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.
modified 18-Jul-19 4:50am.
|
|
|
|
|
thanks, we mere mortals sometimes need help with interpreting the oracular.
"pored," ... not "poured"
fyi: there is an amazing CP example of a custom parser to allow run-time scripting/interaction of a complex WinForm app (spreadsheet) with its .NET internals. See 'ReoScript [^] in 'ReoGrid [^] .
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
|
|
|
|
|
BillWoodruff wrote: "pored," ... not "poured"
Whoops. My fingers sometimes get ahead of my brain. 
BillWoodruff wrote: fyi: there is an amazing CP example of a custom parser to allow run-time scripting/interaction of a complex WinForm app (spreadsheet) with its .NET internals. See 'ReoScript [^] in 'ReoGrid [^] .
That's pretty ambitious. I'll check it out.
BillWoodruff wrote: we mere mortals sometimes need help with interpreting the oracular
The parser generator code itself is not so complicated. The concepts behind it are. Without knowing them, the code looks like gibberish. Once you understand them, the code becomes obvious.
It's backward from how we devs usually like to hack.
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.
|
|
|
|
|
fyi: ReoScript uses ANTLR. It's on GitHub at: [^]
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
|
|
|
|
|
ah, well ANTLR is pretty well covered territory for me. In fact I started experimenting with a similar technology that ANTLR uses for its "parse tables" (actually state machines) in my projects though I may not go with it as I think I found a better way to do LL(k)
In the end, I'm making a universal LL generator. LL parsing is the easiest to use, but currently the hardest to design grammars for because LL(1) is limited, and LL(k) is complicated and traditionally memory intensive, while LL(*) is expensive.
ANTLR4 uses a variant of LL(k) called LL regular (I think?)
I'm making my own "strong" LL(k) using a technique that i think is somewhat similar to this one: The PREDICT-k Function[^]
So basically I'm making my own ANTLR but eventually I intend to extend it to LL(*) - which I've already implemented part of, and I need to finish my LL(k) parser.
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.
|
|
|
|
|
The fact I don't understand what you are saying, doesn't stop me from wishing you well in whatever journey you are on 
«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
|
|
|
|
|
sorry. they're names for algorithms. different ways to generate the tables to parse using top down parsing similar to recursive descent parsing like you'd do if you were writing your own parser.
LL is a family of parsing algorithms.
LL(1) is very simple.
LL(k) is not.
But they both operate using the same basic overarching concepts at their core. Their tables even look somewhat the same. Very much the same once you understand the differences, if that makes sense.
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.
|
|
|
|
|
When is the last time you worked on .Net Remoting?
Potential opportunity but I don't think I'd like the work.
|
|
|
|
|
Used it when it came out just to gain familiarity, never used it in anger though and wouldn't like to today. Might struggle to find good documentation.
|
|
|
|
|
The North remembers! Ehhh, wrong.
So say we all! No, that's also wrong.
The Internet does not forget!
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
GKP1992 wrote: When is the last time you worked on .Net Remoting?
Well, actually, today. The project is that old.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Probably not so much.
Basically it was a way to implement Remote Procedure Calls (RPC) - expose functionality to other apps.
Now there are other (better and simpler) ways to implement that functionality.
WCF (though it was complicated at one point in history) is far more prevalent now (maybe the default for C#?)
Now you can quite easily create a self-hosted app and expose functionality.
(of course, security is always a challenge and a necessity).
Check this out and you can get an overview of how much simpler it can be than the old days of .NET Remoting.
How to: Host a WCF Service in a Managed Application | Microsoft Docs[^]
Update
Here are a couple of SO entries that were basically asking same question that I just found.
Custom RPC vs WCF vs .NET Remoting - Stack Overflow[^]
c# - Does WCF really replace .NET Remoting? - Stack Overflow[^]
That last one was posted 9 years ago and even then the reply was, "remoting is old". 
|
|
|
|
|
Yes, I am familiar with those, but I don't know if I'd like to work on it.
|
|
|
|
|
It's never fun working on old tech, even with newer tools.It's even worse if you're stuck using similarly ancient tools.
|
|
|
|
|
JSON-RPC replaces them all. And it doesn't depend from MS clowns.
|
|
|
|
|
That's a name I haven't heard in a long time. A long time.
|
|
|
|
|
May the fourth be with you.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
.NET Remoting .. if it pays for the insanity afterward..maybe.....
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
The first book I got on .Net was Petzolds book on remoting, never used it and went on to simpler things.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
(If I'm right) As part of API/Framework standardization, Soon this would be marked Obsolete & ultimately removed from the framework. Migrate or die type.
|
|
|
|
|
|
|
used it for 7ish years back in the day for last company's flag ship product for communication between computers, it worked well, then WCF came out; and I believed the hype that it was so much better, and restructured the system for a big new release around WCF. In the long run it wasn't anything spectacular and I don't think it improved anything, now according to the latest news WCF will not be carried forward into Dotnet 5.
before that news came out though we had already made the commitment to leave WCF and start using REST services, it was more flexible and I could tie our java products into the same calls as the .net projects with no extra work.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
