Re: dfmt 0.1.0
On 2015-03-05 13:10, Daniel Murphy wrote: It isn't, but it's slowly getting better. eg You can now build the lexer as a library without pulling everything else in. Yes, that is absolute fantastic as a first step. It's quite possible that in a couple of years it will be in a state where it's reasonable to build tools on top of it. That would be awesome. You're doing a great job, keep it up. -- /Jacob Carlborg
Re: D 2.067.0-b3
On Wednesday, 4 March 2015 at 00:49:04 UTC, Martin Nowak wrote: Glad to announce the third 2.067.0 beta, this time with installers and documentation. https://dlang.dawg.eu/downloads/dmd.2.067.0-b3/ Soon to be mirrored and available on Travis-CI. http://downloads.dlang.org/pre-releases/2.x/2.067.0/ http://ftp.digitalmars.com/ This beta comes with 7 dmd and 2 phobos fixes on top of 2.067.0-b2. https://github.com/D-Programming-Language/dmd/compare/v2.067.0-b2...v2.067.0-b3 https://github.com/D-Programming-Language/phobos/compare/v2.067.0-b2...v2.067.0-b3 - -Martin - -- To check the *.asc signatures, you can import https://dlang.dawg.eu/downloads/d-keyring.gpg or compare them with this key. pub 4096R/0xAB8FE924C2F7E724 2014-09-01 [expires: 2018-03-03] Key fingerprint = AFC7 DB45 693D 62BB 472B F27B AB8F E924 C2F7 E724 uidMartin Nowak (dawg) uidMartin Nowak uidMartin Nowak sub 4096R/0xA78068C444E12E4D 2014-09-01 [expires: 2018-03-03] Key fingerprint = 0D91 720A 3DA5 F106 CEB0 7070 A780 68C4 44E1 2E4D sub 4096R/0xB273811612BB1939 2015-02-27 [expires: 2018-03-03] Key fingerprint = A734 4DAD 3C34 1EA1 2D13 C4E6 B273 8116 12BB 1939 The changelog is missing notes about this: https://github.com/D-Programming-Language/dmd/pull/3651
Re: dfmt 0.1.0
On 3/5/2015 7:15 PM, Brian Schott wrote: You probably feel that way because tabs are better. dfmt only defaults to spaces because that's what's in the Phobos style guide. Spaces are used in Phobos because no two tools agree on what the tab size should be.
Re: dfmt 0.1.0
On 3/5/2015 1:04 AM, Russel Winder via Digitalmars-d-announce wrote: It would be good if the D implemented D parser were though. Parsing to create an AST is needed for many things. If each tool in the tool chain implements it's own… it just seems wrong. True, but on the other hand, a D lexer and parser are pretty simple.
Re: dfmt 0.1.0
On 3/3/2015 3:03 PM, Brian Schott wrote: dfmt works by re-using my existing lexer and parser. The parser is run on the code first so that the formatting step knows a few things like the difference between the binary and unary forms of "*". Line splitting is figured out using a badly mangled version of A*. How are comments handled?
Re: dfmt 0.1.0
On Friday, 6 March 2015 at 09:40:07 UTC, Walter Bright wrote: How are comments handled? The source code makes a DC 15 wisdom save, if it fails then the comments get distributed randomly. The serious answer is that there's a lot of special casing that I'm still trying to figure out.
Re: dfmt 0.1.0
On Friday, 6 March 2015 at 09:39:13 UTC, Walter Bright wrote: True, but on the other hand, a D lexer and parser are pretty simple. Did you mean "simple compared to C++"? I remember having to report/fix a LOT of bugs in the language specification and explore the DMD front end source code to get to where I am now.
Re: dfmt 0.1.0
On Fri, 2015-03-06 at 01:37 -0800, Walter Bright via Digitalmars-d-announce wrote: > On 3/5/2015 7:15 PM, Brian Schott wrote: > > You probably feel that way because tabs are better. dfmt only > > defaults to spaces > > because that's what's in the Phobos style guide. > > Spaces are used in Phobos because no two tools agree on what the tab > size should be. That is the whole point of using tabs for indent, you can chose the indent amount: I tend to use 20ex. Remember a tab is not a number of spaces, it is semantic markup. Using spaces is a low-level hack founded on a lack of separation of concerns and abstraction. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: dfmt 0.1.0
On Fri, 2015-03-06 at 09:48 +, Brian Schott via Digitalmars-d-announce wrote: > On Friday, 6 March 2015 at 09:40:07 UTC, Walter Bright wrote: > > How are comments handled? > > The source code makes a DC 15 wisdom save, if it fails then the > comments get distributed randomly. But with a d4, d6, d8, d10, d12, d20, d100? > The serious answer is that there's a lot of special casing that I'm > still trying to figure out. I prefer the previous answer :-) -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: dfmt 0.1.0
On Friday, 6 March 2015 at 09:39:13 UTC, Walter Bright wrote: On 3/5/2015 1:04 AM, Russel Winder via Digitalmars-d-announce wrote: It would be good if the D implemented D parser were though. Parsing to create an AST is needed for many things. If each tool in the tool chain implements it's own… it just seems wrong. True, but on the other hand, a D lexer and parser are pretty simple. I'd like to hear your definition of simple.
Re: dfmt 0.1.0
On Fri, Mar 06, 2015 at 10:31:29 +, Russel Winder via
Digitalmars-d-announce wrote:
> That is the whole point of using tabs for indent, you can chose the
> indent amount: I tend to use 20ex.
>
> Remember a tab is not a number of spaces, it is semantic markup. Using
> spaces is a low-level hack founded on a lack of separation of concerns
> and abstraction.
The problem with tabs, IMO, are the following:
- don't look right in patches (notice the different alignment of
indented lines versus lines without any):
-int foo(int bar) {
- return bar;
-}
versus (assuming 8 space indents):
-int foo(int bar) {
-return bar;
-}
- I have yet to see an editor properly do tab-for-indent with proper
space-for-alignment without manual management:
int my_long_function_name(int bar,
int baz)
^__tab_^^___spaces___^
By the way, this is *wrong* because tabs now have a defined size (8
here) which defeats the only (tangible[1]) advantage they have:
int my_long_function_name(int bar,
int baz)
^__tab_^
--Ben
[1]File size savings are negligible.
DDT 0.11.0 released
A new version of DDT is out. Improvements to the semantic engine, important fixes: https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.11.0 There has also been some big internal changes lately, so these latest releases might be a bit more buggy than usual. (as exemplified by the regression where code folding and quick-outline were broken :s - and shame on me for taking so long to notice that) -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.11.0 released
On Friday, 6 March 2015 at 17:37:51 UTC, Bruno Medeiros wrote: A new version of DDT is out. Improvements to the semantic engine, important fixes: https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.11.0 There has also been some big internal changes lately, so these latest releases might be a bit more buggy than usual. (as exemplified by the regression where code folding and quick-outline were broken :s - and shame on me for taking so long to notice that) Thank you! DDT is actually the most convenient D IDE at the moment. P.S. Could I request a feature? a better support for dub subconfigurations (yep, I know, if I want something, then it's my fault that isn't implemented yet).
Re: DDT 0.11.0 released
On Friday, 6 March 2015 at 17:37:51 UTC, Bruno Medeiros wrote: A new version of DDT is out. Improvements to the semantic engine, important fixes: https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.11.0 There has also been some big internal changes lately, so these latest releases might be a bit more buggy than usual. (as exemplified by the regression where code folding and quick-outline were broken :s - and shame on me for taking so long to notice that) This is great, thank you! Just to let you know, in release notice there is the text "It is recommended that Recommend re-create project." Im guessing it is meant to be: "It is recommended to re-create you're project."
Re: dfmt 0.1.0
On Fri, 2015-03-06 at 09:54 -0500, Ben Boeckel via
Digitalmars-d-announce wrote:
> On Fri, Mar 06, 2015 at 10:31:29 +, Russel Winder via
> Digitalmars-d-announce wrote:
> > That is the whole point of using tabs for indent, you can chose the
> > indent amount: I tend to use 20ex.
> >
> > Remember a tab is not a number of spaces, it is semantic markup. Using
> > spaces is a low-level hack founded on a lack of separation of concerns
> > and abstraction.
>
> The problem with tabs, IMO, are the following:
>
> - don't look right in patches (notice the different alignment of
> indented lines versus lines without any):
>
> -int foo(int bar) {
> - return bar;
> -}
>
> versus (assuming 8 space indents):
>
> -int foo(int bar) {
> -return bar;
> -}
Is your point that in this case they have rendered identically?
> - I have yet to see an editor properly do tab-for-indent with proper
> space-for-alignment without manual management:
>
> int my_long_function_name(int bar,
> int baz)
> ^__tab_^^___spaces___^
But, for me anyway, the fundamental flaw here is the idea of alignment.
Find a style that eliminates all this alignment malarkey.
I really dislike the Go obsession with block style alignment of
declarations.
The core problem here is teletype, monospace font thinking. Using a
proper proportional font for you code and you rapidly lose the need for
all this alignment stuff.
> By the way, this is *wrong* because tabs now have a defined size (8
> here) which defeats the only (tangible[1]) advantage they have:
>
> int my_long_function_name(int bar,
> int baz)
> ^__tab_^
In a real editor there is no hard line break, no need for this form of
indentation. Should a line be too long for the rendering area either
viewport or syntax directed soft line wrap are used. Having overflow is
mixing content with rendering.
> --Ben
>
> [1]File size savings are negligible.
Indeed, no argument with that point.
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: dfmt 0.1.0
On Fri, Mar 06, 2015 at 19:55:10 +, Russel Winder via
Digitalmars-d-announce wrote:
> On Fri, 2015-03-06 at 09:54 -0500, Ben Boeckel via
> Digitalmars-d-announce wrote:
> > -int foo(int bar) {
> > - return bar;
> > -}
> >
> > versus (assuming 8 space indents):
> >
> > -int foo(int bar) {
> > -return bar;
> > -}
>
> Is your point that in this case they have rendered identically?
Well it is now more apparent with more quoting. It now appears that the
first block is using 3-space indents while the bottom looks just fine
even with the quote markers.
> > - I have yet to see an editor properly do tab-for-indent with proper
> > space-for-alignment without manual management:
> >
> > int my_long_function_name(int bar,
> > int baz)
> > ^__tab_^^___spaces___^
>
> But, for me anyway, the fundamental flaw here is the idea of alignment.
> Find a style that eliminates all this alignment malarkey.
Well, when that means you're going to have absurdly long lines to deal
with in anything other than your definition "real" editors (and I've
never seen one which fits your definition).
> I really dislike the Go obsession with block style alignment of
> declarations.
I won't say I'm a fan of it indiscriminently, but if it's that or
200+-character lines, I'll chop argument lists up a bit to fit something
more reasonable.
> The core problem here is teletype, monospace font thinking. Using a
> proper proportional font for you code and you rapidly lose the need for
> all this alignment stuff.
>
> this is likely a bikeshed issue.>
And I find that monospace fonts tend to make it much easier to tell the
difference between 'l', '1', and 'I'. Not so important in English, but
it can be all the difference in code.
> In a real editor there is no hard line break, no need for this form of
> indentation. Should a line be too long for the rendering area either
> viewport or syntax directed soft line wrap are used. Having overflow is
> mixing content with rendering.
You're making assumptions about the features of your users' editors.
These features are not trivial to implement and this basically requires
things like pygments and other tools used to render code to the web with
all kinds of logic to handle dynamic viewports of the shown code. IMO,
it is even worse than putting #vim:, #kate:, or emacs formatting
directives in your code since it is implicit.
Personally, I use Vim because it works similarly for all uses. I don't
know what I'd do if I had to work with a different editor for each
language I work with.
--Ben
Re: DDT 0.11.0 released
On 06/03/2015 18:48, wobbles wrote: On Friday, 6 March 2015 at 17:37:51 UTC, Bruno Medeiros wrote: A new version of DDT is out. Improvements to the semantic engine, important fixes: https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.11.0 There has also been some big internal changes lately, so these latest releases might be a bit more buggy than usual. (as exemplified by the regression where code folding and quick-outline were broken :s - and shame on me for taking so long to notice that) This is great, thank you! Just to let you know, in release notice there is the text "It is recommended that Recommend re-create project." Im guessing it is meant to be: "It is recommended to re-create you're project." Yup, thx, fixed that. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.11.0 released
On 06/03/2015 17:37, Bruno Medeiros wrote: A new version of DDT is out. Improvements to the semantic engine, important fixes: https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.11.0 There has also been some big internal changes lately, so these latest releases might be a bit more buggy than usual. (as exemplified by the regression where code folding and quick-outline were broken :s - and shame on me for taking so long to notice that) Also fixed that this 0.11.0 version was being reported as 0.10.4 still. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: dfmt 0.1.0
On 3/6/2015 2:31 AM, Russel Winder via Digitalmars-d-announce wrote: Remember a tab is not a number of spaces, it is semantic markup. All I can say is good luck with that. ASCII is not a markup language, and trying to reinvent it as one is doomed to failure. I can also say from experience that removing tabs from Phobos source has removed a lot of irritation with messed up code rendering and wasted effort arguing about it. We're not going back :-)
Re: dfmt 0.1.0
On 3/6/2015 1:54 AM, Brian Schott wrote: On Friday, 6 March 2015 at 09:39:13 UTC, Walter Bright wrote: True, but on the other hand, a D lexer and parser are pretty simple. Did you mean "simple compared to C++"? It's simple in both absolute terms and relative to C++ terms. It's not as simple as Java's. I remember having to report/fix a LOT of bugs in the language specification and explore the DMD front end source code to get to where I am now. True, but there have been very few bugs in the lexer/parser itself. My laziness in being pedantically correct in writing the specification is an orthogonal issue.
Re: dfmt 0.1.0
On 3/6/2015 1:48 AM, Brian Schott wrote: The serious answer is that there's a lot of special casing that I'm still trying to figure out. Ah. I had thought that maybe there was an obvious algorithm I didn't think of!
Re: dfmt 0.1.0
On 3/6/2015 2:47 AM, Stefan Koch wrote: I'd like to hear your definition of simple. It's easy to understand, and one could write one from scratch over a weekend. I haven't done any statistics, but I'd bet that that parse.c & lexer.c are among the most stable parts of dmd judging by change history.
Re: dfmt 0.1.0
On 3/6/2015 11:55 AM, Russel Winder via Digitalmars-d-announce wrote: The core problem here is teletype, monospace font thinking. Using a proper proportional font for you code and you rapidly lose the need for all this alignment stuff. Unlike english prose, code follows patterns. With a monospace font, one can line up those patterns which makes for easier visual checking for errors.
Re: dfmt 0.1.0
On Fri, 2015-03-06 at 18:31 -0800, Walter Bright via Digitalmars-d-announce wrote: […] > > Unlike english prose, code follows patterns. With a monospace font, one can > line > up those patterns which makes for easier visual checking for errors. That works for you fine, but it doesn't work for me. I find monospace fonts and alignment of code gets in the way of reading and comprehending code. The difficulty here is turning a personal preference into a social orthodoxy. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: dfmt 0.1.0
On Fri, 2015-03-06 at 18:21 -0800, Walter Bright via Digitalmars-d-announce wrote: > On 3/6/2015 2:31 AM, Russel Winder via Digitalmars-d-announce wrote: > > Remember a tab is not a number of spaces, it is semantic markup. > > All I can say is good luck with that. ASCII is not a markup language, and > trying > to reinvent it as one is doomed to failure. I try to use Unicode (UTF-8 encoded) languages, restricting to ASCII is very 1970s. The use of tab as the indent character is far from failing. Many C++ projects are returning to it, Go enforces it if you let it, many Python projects are starting to use it in spite of PEP-8. OK so Go enforced format does alignment as well on the assumption of monospace font. I dislike that so just carry on with proportional fonts. ASCII per se is not a markup language, and it retains all the quirks of teletypes, but that should not stop progress. Unicode replacing ASCII is one step forward. Rethinking old established rules is always worthwhile: just because a thing has always been done some way does not make it the right way, nor should it hinder change. > > I can also say from experience that removing tabs from Phobos source has > removed > a lot of irritation with messed up code rendering and wasted effort arguing > about it. We're not going back :-) And I am not going to work on Phobos for exactly the same reasons. My loss, not yours. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: On fonts and editors [was dfmt 0.1.0]
On Fri, 2015-03-06 at 15:22 -0500, Ben Boeckel via Digitalmars-d-announce wrote: […] > > Well it is now more apparent with more quoting. It now appears that the > first block is using 3-space indents while the bottom looks just fine > even with the quote markers. But there is no semantic difference in the code and it is all being replaced anyway. I think the fact that a codebase should have a formatter run over any change before being committed, to enforce the rules of the codebase, will get round the issue anyway. Pythons pep-8, gofmt, dfmt,… the use of such a tool, enforcing the standard of the codebase is a good thing. […] > Well, when that means you're going to have absurdly long lines to deal > with in anything other than your definition "real" editors (and I've > never seen one which fits your definition). Such editors were being researched and created in the 1980s but computers were a bit too slow for the necessary infrastructure and, more importantly, a vocal section of the development community screamed, these things are wasteful of resources, and we must have ASCII encoded files as the storage of our code. This attitude has, in my view, been the biggest stumbling block to progress in software development for the last 30 years. Now with suitably fast processors and graphics, we are seeing all the technology of the 1980s reentering the arena, but instead of doing it right, IDEs are having to spend huge resources continually reconstructing AST data from the flat file input. Some of them do it better than others, but if only it had been accepted that AST is the correct unit of editing in the 1980s we would be a lot further forward today. > > I really dislike the Go obsession with block style alignment of > > declarations. > > I won't say I'm a fan of it indiscriminently, but if it's that or > 200+-character lines, I'll chop argument lists up a bit to fit something > more reasonable. There is more than one way of chopping things up, and even aligning them. Stepping away from monospace fonts, and the obsession with 2D rendering of 1D data, gives a different view on chopping up which ends up no better, but no worse. […] > > And I find that monospace fonts tend to make it much easier to tell the > difference between 'l', '1', and 'I'. Not so important in English, but > it can be all the difference in code. Important point. Fonts are context dependent. A font for easy reading of plain English novels, may not be appropriate for other uses exactly because the different uses and contexts of the characters mean the glyphs must have different relationships. But this is a font design thing and monospace versus proportional is not the major determinant. > > In a real editor there is no hard line break, no need for this form of > > indentation. Should a line be too long for the rendering area either > > viewport or syntax directed soft line wrap are used. Having overflow is > > mixing content with rendering. > > You're making assumptions about the features of your users' editors. > These features are not trivial to implement and this basically requires > things like pygments and other tools used to render code to the web with > all kinds of logic to handle dynamic viewports of the shown code. IMO, > it is even worse than putting #vim:, #kate:, or emacs formatting > directives in your code since it is implicit. > > Personally, I use Vim because it works similarly for all uses. I don't > know what I'd do if I had to work with a different editor for each > language I work with. I do not disagree. The problem is that Emacs, VIM, IntelliJ IDEA, Eclipse, Netbeans, are editors based fundamentally on a 1970s view of editing and resources and the world has changed. Fortunately, I am hearing that some of the ideas of the SOE and AST editors of the 1980s are being re-raised, now with the resources to deal with it. Should this go forward, I can see VIM dying, Emacs dying or being rewritten, and IntelliJ IDEA, Eclipse, Netbeans, etc. losing at least half their code or more. The IDEs with all their "refactoring support" are almost reproducing what comes for free with SOE and AST focused editors. As actors, dataflow, CSP were rejected by programmers in the 1970s and 1980s because they had processes and threads and really enjoyed shared-memory multi-threaded programming (*), SOE and AST based editors of the 1980s are effectively being recreated by the IDEs of the 2010s. They are hamstrung by the continued obsession with the text file as the primary unit of editing. As soon as they and programmer users get over this, the sooner we can get on with better UX for development. (**) (*) OK so operating system developers are allowed to do this stuff because they have to, but applications people should not be doing any such thing. (**) And yes the very foundation of version control will have to change as well. -- Russel. = Dr Russel Winder
