tag:blogger.com,1999:blog-7864497598813874355.post9168904109383956075..comments2023-07-14T03:00:28.739-07:00Comments on brrt to the future: Inching CloserBart Wiegmanshttp://www.blogger.com/profile/05760700924227974153noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-7864497598813874355.post-17280025372403379632015-08-19T07:15:49.847-07:002015-08-19T07:15:49.847-07:00Thtat's really cool! Thanks a lot :-).
I hope...Thtat's really cool! Thanks a lot :-). <br />I hope you thought my explanation in the post made some sense.<br />RegardsBart Wiegmanshttps://www.blogger.com/profile/05760700924227974153noreply@blogger.comtag:blogger.com,1999:blog-7864497598813874355.post-25784467467589991812015-08-19T04:09:39.690-07:002015-08-19T04:09:39.690-07:00Found it: http://dragonbook.stanford.edu/lecture-n...Found it: http://dragonbook.stanford.edu/lecture-notes/Stanford-CS143meislhttps://www.blogger.com/profile/02608695500862437227noreply@blogger.comtag:blogger.com,1999:blog-7864497598813874355.post-25148373260715109142015-08-18T12:47:40.287-07:002015-08-18T12:47:40.287-07:00Hi there,
I'm having a bit of a hard time fin...Hi there,<br /><br />I'm having a bit of a hard time finding the exact pdfs (or ps's), but they should be somewhere here:<br /><br />http://web.stanford.edu/class/cs143<br /><br />(see "Handouts"; particularly http://web.stanford.edu/class/cs143/handouts/parsing.pdf<br />- they're good but more preliminary, and not really what I was referring to above)<br /><br />I remember comprehensive, textbook-like texts (ie not slides) on constructing LR-k parser tables and optimization, including some stuff on code-generation. As said, I'm not even sure how I came across 'em, possibly by some hint of yours...<br />So, even it's maybe nothing new to you, I'll try some more to dig 'em out.<br /><br />meisl<br /><br />meislhttps://www.blogger.com/profile/02608695500862437227noreply@blogger.comtag:blogger.com,1999:blog-7864497598813874355.post-16346390540803926892015-08-16T14:08:17.962-07:002015-08-16T14:08:17.962-07:00Great, I just saw you posted the next one already ...Great, I just saw you posted the next one already :D<br />I'll try to find those scripts.meislhttps://www.blogger.com/profile/02608695500862437227noreply@blogger.comtag:blogger.com,1999:blog-7864497598813874355.post-3779386505607720462015-08-16T05:07:30.896-07:002015-08-16T05:07:30.896-07:00Hi! Thanks for your constructive reaction. I think...Hi! Thanks for your constructive reaction. I think the answer to your questions deserve another blog post, which I'm in the process of writing. But to answer your first question very shortly: it's possible to view the tile 'grammar' as a graph, and it yields important insight into why my earlier approach didn't work, but ultimately it's not the right way to view it, and the final effective algorithm to generate all tile states is not really graph-based. (I'll explain why in my blog).<br />Oh, and I did manage to solve it, and other issues. If you have any papers to share, please do so :-)Bart Wiegmanshttps://www.blogger.com/profile/05760700924227974153noreply@blogger.comtag:blogger.com,1999:blog-7864497598813874355.post-3205391418886195992015-08-14T14:24:33.899-07:002015-08-14T14:24:33.899-07:00Hi Bart,
>> I've documented the syntax ...Hi Bart,<br /><br />>> I've documented the syntax and structure of the expression tree format. [...] Documentation on the tiler is work in progress.<br /><br />Yep, I too think that documentation is crucial in this endeavor. Actually, that's why I commented on your last post, http://brrt-to-the-future.blogspot.de/2015/07/tiles-and-compiler-compilers.html - as I think it's quite qualified as such, worth of integrating it into the project's repo.<br /><br />BTW, maybe add a direct link to github, for convenience?<br /><br /><br />>> My current problem is that [...] it tried to apply a topological sort on a graph that had cycles. Breaking these cycles leads to not generating all permissible tile states, which leads to runtime failure for the tiler.<br /><br />I'm definitely not into it, but are you sure that the problem is the graph having (real) cycles? Maybe it's only that you're working with a DAG rather than a tree? If so you might be able to simplify your strategy for "breaking the cycles".<br />I'm not sure, as said, just what my gut told me at first sight...<br /><br /><br />>> So this [runtime failure] has to be avoided, at the same time it is also very important not to generate more tiler states than necessary because otherwise the tile table (and the time spent constructing it) becomes prohibitively large. [...] but what I had not realized is that a 'real' compiler requires many moving parts working correctly.<br /><br />So now we're REALLY in compiler-compiler-land..! You're aiming at a compiler for your tiles (represented as s-exprs) that optimizes - but for one aspect only: covering all relevant (to be defined) but no more than necessary tiler states.<br />I'd say: re *that* compiler (the tiler states generator) focus on this *only*, since, as you mentioned, "a 'real' compiler requires many moving parts working correctly". Any other one optimization there *multiplies* chances of incorrectness.<br /><br />I remember that, some time after you had directed my interest to the Aho tree-matching paper, I read (again) some introductory yet comprehensive scripts on compiler construction (covering rec. descent/table-driven, LL/R-k etc). I can't remember right now which and where, neither how I came upon it but they were related to Aho-Ullmann ("Dragon" Book).<br />Are you interested, ie should I try and dig them out?<br /><br />All the best for Wednesday, at YAPC::EU!<br />meislmeislhttps://www.blogger.com/profile/02608695500862437227noreply@blogger.com