Re: Implementing a Programming Language in D: Lexical Analysis
On 12/28/2015 09:57 PM, Ali Çehreli wrote: > anonymous enums Wow! They are pretty weird: 1) The second form of the AnonymousEnumDeclaration spec is redundant, right? http://dlang.org/spec/enum.html#AnonymousEnumDeclaration enum : EnumBaseType { EnumMembers } enum { EnumMembers }<-- Redundant? enum { AnonymousEnumMembers } The reason is, AnonymousEnumMembers already covers EnumMembers, no? 2) Anonymous enum definitions can have types right inside the list: AnonymousEnumMember: EnumMember Type Identifier = AssignExpression enum { a, ulong b = 42, c, // b and c are ulong s = "hello", // an inferred string between integrals! x = 7, y, z } 3) The types of x, y, and z are 'int' because 7 is an int (they don't follow the type of 'c'). However, move 's' to the end of the list or remove it altogether, then x, y, and z become ulong! Weird. Ok, I'm going to forget about this feature now. :p Ali
Re: Implementing a Programming Language in D: Lexical Analysis
On 12/28/2015 04:28 PM, Walter Bright wrote: > https://www.reddit.com/r/programming/comments/3ykko7/implementing_a_programming_language_in_d_lexical/ Although the author does not use many D idioms, I've just learned (re-learned?) anonymous enums from that code. I've realized that with a nested anonymous enum, there is no need to (and no way of) mentioning the enum type inside a user-defined type. This can simplify the implementation: struct S { enum { value } void foo() { // Look ma, no type: assert(value == 0); } } void main() { // Properly name-spaced outside of the struct: assert(S.value == 0); } As can be seen, the users of the struct still have to name-space the enum value as S.value. There is no need for an additional enum type for example like S.MyEnum.value. Ali
Re: Better docs for D (WIP)
On 29/12/15 4:08 PM, Andrei Alexandrescu wrote: Rikki Cattermole wrote: On 29/12/15 12:05 PM, Andrei Alexandrescu wrote: One more note: I salute the initiative of another doc generator and read the motivation behind it. Yet I do think it's worth asking ourselves two questions: (a) is the new proposed system differentiated enough to justify its existence and motivate others to join in? It supports comments on manifest enums sorta like as if it was named. The others do not ;) So I'm already very wanting of this solution to say the least. Is this feature unreasonably difficult to integrate within the existing products? From what Adam has said, definitely won't be happening with DDOC. There is simply no symbol to attach the comment to.
Re: pl0stuff an optimizing pl0 > c transcompiler
On Tuesday, 29 December 2015 at 00:50:49 UTC, Stefan Koch wrote: so could it be used to produce D output instead of C ? Could it be used to parse PHP as input ? That would probably require implementing a vm. fancyPars can certainly be used to create a php parser but a straightforward translation will not give you good performance... Would you know what is required to get good performance ?
Re: Better docs for D (WIP)
Rikki Cattermole wrote: > On 29/12/15 12:05 PM, Andrei Alexandrescu wrote: >> One more note: I salute the initiative of another doc generator and read >> the motivation behind it. Yet I do think it's worth asking ourselves two >> questions: >> >> (a) is the new proposed system differentiated enough to justify its >> existence and motivate others to join in? > > It supports comments on manifest enums sorta like as if it was named. > The others do not ;) > > So I'm already very wanting of this solution to say the least. > Is this feature unreasonably difficult to integrate within the existing products?
Re: Better docs for D (WIP)
On Monday, 28 December 2015 at 23:01:05 UTC, Andrei Alexandrescu wrote: The signature proper is nice. The formatting of "&&" in the constraint is inconsistent, but I guess that's a matter with the formatting of the code. Yeah, that is a css bug I just forgot about getting in to everything else, fixed now. The vertical spacing post "Parameters" of http://dpldocs.info/findSkip is annoying. In a simple function it may be unnecessary but doesn't really hurt, while in a complex type or a function with a lot of parameters, it improves legibility. A type alone can be a pretty complex beast and can warrant the use of multiple lines. I *might* change my mind on this, Qt puts the types on one line, but the real question is what they look like when I finish the constraint analyzer. I haven't even started implementing it yet, but the type of haystack is not really R1. It is actually "duck-typed forward range", which is gleamed from the constraint. Qt's types are rarely more complex than a class pointer. Sometimes, you might see a QList or a QMapQValue>, but never anything like what Phobos deals in. C++ doesn't have D's const and immutable, it doesn't have the dip 25 ref checker, it doesn't use much design by introspection. Voldemort types both simplify the signature and make the explanation more complex at the same time. So what works for us may be quite different than what works for them. But once I get the constraint analyzer set up and try it on more real world code, if it remains legible in complex cases on one line (which it might, I should be able to simplify stuff like `!isInfinite!Range && isForwardRange!Range` into something like "finite forward range"), I'll revisit this. Ideally most of these things would be adjustable via css. Of course, it is primarily an issue of margins, and I'm mostly using the browser defaults for the semantic tags at this point. But I do want it to be good out of the box and find too much space to be better than too little. Essentially it would be fantastic if the docs contained the semantic info and the formatting would be entirely shipped to css. Yes, I agree, that is one of my goals too.
Re: pl0stuff an optimizing pl0 > c transcompiler
On Monday, 28 December 2015 at 23:40:31 UTC, Nick B wrote: On Monday, 28 December 2015 at 16:41:30 UTC, Stefan Koch wrote: On Monday, 28 December 2015 at 10:45:59 UTC, Nick B wrote: what languages do you plan to support for input and output ? I just planned on PL/0 as input and C as output. It is a simple one-pass (okay 2 pass if you count the optimizer) trans-compilation. There is no middle-end. And very little verification. Everything that parses will produce an c-output. Which does may or may not compile. Since PL/0 just one type. Int you can get away with anything :) so could it be used to produce D output instead of C ? Could it be used to parse PHP as input ? That would probably require implementing a vm. fancyPars can certainly be used to create a php parser but a straightforward translation will not give you good performance...
Implementing a Programming Language in D: Lexical Analysis
http://blog.felixangell.com/implementing-a-programming-language-in-d-part-1/ https://www.reddit.com/r/programming/comments/3ykko7/implementing_a_programming_language_in_d_lexical/ https://news.ycombinator.com/item?id=10802610 (Go through the front page, not this link, or your votes won't count)
Poodinis 6.0.0 released
Poodinis 6.0.0 has been released! Poodinis is a dependency injection framework for the D programming language. It is inspired by the Spring Framework and Hypodermic IoC container for C++. Poodinis supports registering and resolving classes either by concrete type or interface. Automatic injection of dependencies is supported through the use of UDAs (Referred to as autowiring). New in this release: - Application contexts: Java programmers familiar with the Spring Framework should be familiar with application contexts. They allow you to set-up complex dependencies through custom defined factory methods. Complex dependencies are dependencies which require constructor arguments or other sorts of configuration before their instances can be used. You can find the project at: Github: https://github.com/mbierlee/poodinis D package registry: http://code.dlang.org/packages/poodinis
Re: pl0stuff an optimizing pl0 > c transcompiler
On Monday, 28 December 2015 at 16:41:30 UTC, Stefan Koch wrote: On Monday, 28 December 2015 at 10:45:59 UTC, Nick B wrote: what languages do you plan to support for input and output ? I just planned on PL/0 as input and C as output. It is a simple one-pass (okay 2 pass if you count the optimizer) trans-compilation. There is no middle-end. And very little verification. Everything that parses will produce an c-output. Which does may or may not compile. Since PL/0 just one type. Int you can get away with anything :) so could it be used to produce D output instead of C ? Could it be used to parse PHP as input ?
Re: Better docs for D (WIP)
On 29/12/15 12:05 PM, Andrei Alexandrescu wrote: One more note: I salute the initiative of another doc generator and read the motivation behind it. Yet I do think it's worth asking ourselves two questions: (a) is the new proposed system differentiated enough to justify its existence and motivate others to join in? It supports comments on manifest enums sorta like as if it was named. The others do not ;) So I'm already very wanting of this solution to say the least.
Re: Better docs for D (WIP)
One more note: I salute the initiative of another doc generator and read the motivation behind it. Yet I do think it's worth asking ourselves two questions: (a) is the new proposed system differentiated enough to justify its existence and motivate others to join in? (b) are the existent systems reaching hard limits that the proposed system overcomes by design? Last thing we want is the idyllic Balkanic landscape of several "me too" documentation systems, neither of which is better and has more of a following than others. This is just musing. Please don't make it into Archduke Ferdinand's assassination :o). Andrei
Re: Better docs for D (WIP)
On 12/28/15 3:15 PM, Adam D. Ruppe wrote: http://dpldocs.info/ Inspired by the php docs, I also have it able to search direct from a URL. Click this: http://dpldocs.info/findSkip The signature proper is nice. The formatting of "&&" in the constraint is inconsistent, but I guess that's a matter with the formatting of the code. The vertical spacing post "Parameters" of http://dpldocs.info/findSkip is annoying. So we have a healthy vertical space between the "Parameters" and "haystack" headings - fine - then a dinghy space between "haystack" and the type, then again a large space between the "Type:" and the description. I think types should be massaged with the parameter names. Also the type of the return value should be massaged with the heading "Return Value" and the valign of the return value's description should be the same as for the parameters, so we have: Parameters ((vspace 1)) R1 haystack ((hspace 1))The forward range to search in. ((vspace 2)) R2 needle ((hspace 1))The forward range to search for. ((vspace 2)) Return Value (bool) ((vspace 1)) ((hspace 1))true if the needle was found, in which case haystack is positioned after the end of the first occurrence of needle; otherwise false, leaving haystack untouched. etc. Ideally most of these things would be adjustable via css. Even some of the text (e.g. "Return Value" etc.) would be in a perfect world part of the css (there's that property "before" or something). Essentially it would be fantastic if the docs contained the semantic info and the formatting would be entirely shipped to css. Andrei
Better docs for D (WIP)
Last week, I posted in the general forum my dream for better D docs. Today, about 4 days of work later, I'm about 1/4 of the way there. Still a long way to go, but I've already come so far. First, behold my old dpldocs.info site. Yes, it is still up and now it ties into my new docs! You can use it to quickly jump to a doc given its name: http://dpldocs.info/ Inspired by the php docs, I also have it able to search direct from a URL. Click this: http://dpldocs.info/findSkip and it automatically sends you here: http://dpldocs.info/experimental-docs/std.algorithm.searching.findSkip.html I haven't run all of Phobos through my generator yet (it still crashes on some of it) but I have run a lot of it through so you can browse around and get a feel. I also described why in This Week in D last night: http://arsdnet.net/this-week-in-d/dec-27.html While I'm still probably at least a month away from having this really finished, I feel it is already a massive improvement on the main docs and wanted to announce it so other people can give it a try too. Once I finish the generator, I'll start writing new articles to fill in some of the dummy links there, and perhaps make minor changes to Phobos itself (if I can make changes that help me without hurting the existing ddoc based site or source legibility). The new articles are a big part of the work too! Finally, when I am happy with this program, I will document the doc generator and release it for other people to use too. But until then, have fun playing with dpldocs.info!
Re: DLanguage IntelliJ plugin released
On Friday, 25 December 2015 at 17:43:06 UTC, Kingsley wrote: On Friday, 25 December 2015 at 16:55:32 UTC, Bogdan wrote: On Friday, 25 December 2015 at 15:28:23 UTC, Pradeep Gowda wrote: On Friday, 25 December 2015 at 15:04:42 UTC, eyveer wrote: On Friday, 25 December 2015 at 13:57:52 UTC, Pradeep Gowda wrote: [...] https://github.com/kingsleyh/DLanguage Thank you. The screenshots are very impressive! Gives me motivation to figure out why i couldn't get it to work. Couldn't figure out what went wrong until I read your comment and looked at the screenshots. Try going to Settings/Other Tools/D Tools and press all the "Auto Find" buttons. Raise any issues at the GitHub page and I will fix - I will write some documentation over the next few days also Intellij D plugin version 1.5 released with improved DUB support and bug fixes
Re: Better watch out! D runs on watchOS!
Jacob Carlborg writes: > > Would it be possible to bypass LLVM and do the thread local specific > parts in LDC? That is Plan B.2
Re: Better watch out! D runs on watchOS!
Joakim writes: > > Thanks for the detailed answer; I'm sure this will now become the > definitive answer online. I've gone googling for technical info only > to sometimes be directed back to a post in these D forums. :) Me too! Its very funny when that happens. > Time to get emulated TLS for Mach-O into llvm, as one google engineer > did with ELF for Android, which will be released in the upcoming llvm > 3.8: > > https://code.google.com/p/android/issues/detail?id=78122 That is Plan B.1
Re: pl0stuff an optimizing pl0 > c transcompiler
On Monday, 28 December 2015 at 10:45:59 UTC, Nick B wrote: what languages do you plan to support for input and output ? I just planned on PL/0 as input and C as output. It is a simple one-pass (okay 2 pass if you count the optimizer) trans-compilation. There is no middle-end. And very little verification. Everything that parses will produce an c-output. Which does may or may not compile. Since PL/0 just one type. Int you can get away with anything :)
Re: Three Cool Things about D
On 27 Dec 2015 6:25 PM, "Andrei Alexandrescu via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote: > > On 12/27/15 1:27 AM, Rory McGuire via Digitalmars-d-announce wrote: [snip] >> Vibe.d had a template engine called diet which is almost like Jade. It >> is also completed so you might prefer that as an example. > > > Either or both would be awesome to express with Pegged. -- Andrei > I'm working on the output part now while it's the holidays. Will share once I've got my test template translating to html as a demo.
Re: Better watch out! D runs on watchOS!
On 2015-12-28 09:45, Dan Olson wrote: On implication of Apple requiring bitcode: if Apple is compiling the bitcode with their clang or llc, then it means using a modifed LLVM like I do to support thread-locals on watchOS, tvOS, or iOS is only good for side loading. Probably going to have to work on plan B for thread-locals. Would it be possible to bypass LLVM and do the thread local specific parts in LDC? -- /Jacob Carlborg
Re: Three Cool Things about D
On 2015-12-27 17:23, Andrei Alexandrescu wrote: That looks pretty cool! -- Andrei It's based on Haml which is pretty well known as well. -- /Jacob Carlborg
Re: So You Want To Write Your Own Language
On 2015-12-27 00:55, Walter Bright wrote: Many of the lowerings require semantic information that is not available from ASTs. Hence the "in theory" ;). It's hard to tell what would be possible to implement with AST macros without implementing the complete macro system and use it. Of course it's possible to look what's possible in other languages. -- /Jacob Carlborg
Re: pl0stuff an optimizing pl0 > c transcompiler
On Sunday, 27 December 2015 at 21:13:07 UTC, Stefan Koch wrote: Hello again. please feel free to comment or ask questions here. Hi. what languages do you plan to support for input and output ?
Re: Better watch out! D runs on watchOS!
On Monday, 28 December 2015 at 08:45:46 UTC, Dan Olson wrote: Joakim writes: I don't understand how the bitcode requirement works on your own device: I thought that was for an Apple-submitted app that they then compiled to binary themselves? Do you have to go through the same process even for test apps, ie no sideloading? Or does the device itself take bitcode? This is all based on my experience and I don't know the full bitcode story. I may state erroneous info below. The device takes normal executables but there is a check to make sure that each object file has the appropriate bitcode sections. I think the linker does this, but did not check which tool in build chain spit out the error. The bitcode is actually two new sections in every object file: .section __LLVM,__bitcode .section __LLVM,__cmdline The __bitcode section seems to just be the LLVM IR for the object file in the .bc binary format. Some sources say it is a xar archive but in my investigation I used Apple's clang with -fembed-bitcode and inspected the IR or ARM assembly to see these two sections. Extracting and using llvm-dis on the __bitcode section gave back the containing module's IR in human readable format. It exactly matches the LLVM IR for its object file sans Apple's clang -fembed-bitcode. So not sure when xar is used yet. The __cmdline section appears to be some of the clang options used to compile the bitcode. The compile process becomes something like this: 1. Create IR for module as usual. 2. Generate the IR bitcode representation. 3. Add the two new sections, using bitcode from (2) as contents of __bitcode section and __cmdline options to compile it 4. Generate object from IR. But not wanting to figure all that out now, I tried simpler things and discovered that at least for testing, these sections only need to be present and the contents don't seem to matter. So for now I skip 2 and just put a zero in each. Thanks for the detailed answer; I'm sure this will now become the definitive answer online. I've gone googling for technical info only to sometimes be directed back to a post in these D forums. :) On implication of Apple requiring bitcode: if Apple is compiling the bitcode with their clang or llc, then it means using a modifed LLVM like I do to support thread-locals on watchOS, tvOS, or iOS is only good for side loading. Probably going to have to work on plan B for thread-locals. Time to get emulated TLS for Mach-O into llvm, as one google engineer did with ELF for Android, which will be released in the upcoming llvm 3.8: https://code.google.com/p/android/issues/detail?id=78122
Re: Better watch out! D runs on watchOS!
Joakim writes: > > I don't understand how the bitcode requirement works on your own > device: I thought that was for an Apple-submitted app that they then > compiled to binary themselves? Do you have to go through the same > process even for test apps, ie no sideloading? Or does the device > itself take bitcode? This is all based on my experience and I don't know the full bitcode story. I may state erroneous info below. The device takes normal executables but there is a check to make sure that each object file has the appropriate bitcode sections. I think the linker does this, but did not check which tool in build chain spit out the error. The bitcode is actually two new sections in every object file: .section __LLVM,__bitcode .section __LLVM,__cmdline The __bitcode section seems to just be the LLVM IR for the object file in the .bc binary format. Some sources say it is a xar archive but in my investigation I used Apple's clang with -fembed-bitcode and inspected the IR or ARM assembly to see these two sections. Extracting and using llvm-dis on the __bitcode section gave back the containing module's IR in human readable format. It exactly matches the LLVM IR for its object file sans Apple's clang -fembed-bitcode. So not sure when xar is used yet. The __cmdline section appears to be some of the clang options used to compile the bitcode. The compile process becomes something like this: 1. Create IR for module as usual. 2. Generate the IR bitcode representation. 3. Add the two new sections, using bitcode from (2) as contents of __bitcode section and __cmdline options to compile it 4. Generate object from IR. But not wanting to figure all that out now, I tried simpler things and discovered that at least for testing, these sections only need to be present and the contents don't seem to matter. So for now I skip 2 and just put a zero in each. On implication of Apple requiring bitcode: if Apple is compiling the bitcode with their clang or llc, then it means using a modifed LLVM like I do to support thread-locals on watchOS, tvOS, or iOS is only good for side loading. Probably going to have to work on plan B for thread-locals. -- Dan