Re: Hash Tables in D
On 2016-01-07 15:11, Steven Schveighoffer wrote:
With dcollections [1] I had a feature called "purging" where you would
iterate over a collection like this:
foreach(ref bool removeIt, int val; collection)
{
if(someCondition) removeIt = true;
}
The entire reason for this is because you can do something similar in
C++ containers, and I found it absolutely annoying that the existing
container classes don't allow this. A very frequent use of containers is
to iterate through picking which ones should be removed (think of a cache)
In Ruby that's called "reject", i.e. the opposite of "filter".
--
/Jacob Carlborg
Re: Three Cool Things about D
Some of the template support code is still in the app.d file. And I mean to rename some of the functions etc. You can access all the output in current_output.txt and the template used is index.jade. github.com/rjmcguire/jaded On 08 Jan 2016 04:45, "Jack Stouffer via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote: > On Friday, 8 January 2016 at 00:32:05 UTC, Rory McGuire wrote: > >> On Mon, Dec 28, 2015 at 5:24 PM, Rory McGuire >> wrote: >> >> >>> 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. >>> >>> A little teaser, this is the output of the app and runtime >> > > Can you post all of the D code on github as well, seeing as the forum > strips your code formatting, making it very hard to read. >
Re: My LLVM talk @ FOSDEM'16
It will be recorded or live? Bubba.
Re: Three Cool Things about D
On Friday, 8 January 2016 at 00:32:05 UTC, Rory McGuire wrote: On Mon, Dec 28, 2015 at 5:24 PM, Rory McGuire wrote: 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. A little teaser, this is the output of the app and runtime Can you post all of the D code on github as well, seeing as the forum strips your code formatting, making it very hard to read.
Re: Three Cool Things about D
On Mon, Dec 28, 2015 at 5:24 PM, Rory McGuire wrote:
>
> 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.
>
A little teaser, this is the output of the app and runtime and/or compile
time:
Index of
Demobody {
margin: 0px;
background-color: #eee;
} This is the index.jade
paragraph thattest continues on multiplelines goto https://github.com/jadejs/jade/blob/master/docs/views/reference/interpolation.jade";>Jade
Reference to see examples of interpolationas2dfas3dfas3dfThis is the text in footer
blockYou are logged in3:
three2: two1:
one123you have 42
friendsfoobarbazfoobarbazcatdogpigHello worldNo content
providedHello worldThis is myAmazing
articlefoofoo1234If you take a
look at this page's source https://github.com/jadejs/jade/blob/master/docs/views/reference/interpolation.jade";>on
GitHub, you'll see several places where the tag interpolation operator
is used like so. .quote // this is raw text so the .quote means nothing to
jade, only string and tag interpolation works here p Joel:
riskyThis is supposed to just be text inside a p
tag.This is NOT MY INSIDE VOICE <- upper case
characters
Translated from these files:
*=*
extends second_layout.jade
block title
title Index of Demo
block content
// this is the actual displayed content
p(id="", p-form-hook=some_d_var ? "yes" :"no", marked) This is the
index.jade #[i paragraph] that
| #[b test] continues #[i on] multiple
| lines goto #[a(target="_blank", href="
https://github.com/jadejs/jade/blob/master/docs/views/reference/interpolation.jade";)
Jade Reference]
// TODO: should allow empty lines in PipedText or at least show an error
//|
| to see examples of interpolation
ul(isit=some_other_d_var == "woot")
li.one-css.two-css: a(href!="#"): a(href!="#")!= clickme2
.img-holder
img.image(src="logo2.gif", style={background: "red", padding: "0px"})/
**
extends second_layout.jade
block title
title Index of Demo
block content
// this is the actual displayed content
p(id="", p-form-hook=some_d_var ? "yes" :"no", marked) This is the
index.jade #[i paragraph] that
| #[b test] continues #[i on] multiple
| lines goto #[a(target="_blank", href="
https://github.com/jadejs/jade/blob/master/docs/views/reference/interpolation.jade";)
Jade Reference]
// TODO: should allow empty lines in PipedText or at least show an error
//|
| to see examples of interpolation
ul(isit=some_other_d_var == "woot")
li.one-css.two-css: a(href!="#"): a(href!="#")!= clickme2
.img-holder
img.image(src="logo2.gif", style={background: "red", padding: "0px"})/
rmcguire@rmcguire-hx:~/Projects/jade$ cat views/second_layout.jade
extends base_layout.jade
block footer
p This is the text in footer block
*===*
doctype html
- auto currentUrl = "/";
- auto riskyBusiness = "risky";
- bool some_d_var = true;
- string some_other_d_var = "woot";
html(lang="en")
head
block title
title Page Title Here
style
include style.css
body.base-css(ng-app="MyApp", ng-controller="CtrlII")
block content
// this is the displayed content
p(id="", p-form-hook=some_d_var ? "yes" :"no", marked) This is a paragraph
| That continues on
| multiple lines
ul(isit=some_other_d_var == "woot")
li.one-css.two-css: a(href!="#"): a(href!="#")!= clickme
.img-holder
img.image(src="logo.gif", style={background: "red", padding: "0px"})/
woot#content1 as2df
#woot2(class=["c1", "c2"]) as3dfas3df
woot3(class={active: currentUrl == "/about"})
block footer
p Placeholder footer block
- var host = "remotehost";
- var user = var.emptyObject;
if "localhost" == host
div#foo(data-bar="foo", goot-one)&attributes({"data-cew": "baer",
"ng-show": 1234})
//- include:markdown ./includes/footer.jade
else
merrrt
unless user.isAnonymous
p You are logged in
//- :markdown
//- ### Markdown Need dedent support to parse this
//- I often like including markdown documents.
ul
- import std.conv;
each index, val in [1:"one",2:"two",3:"three"]
li= to!string(index) ~": "~ val
- int n=1;
while n < 4
li= n++
- auto friends = 42;
case friends
when 0
when 1
p you have very few friends
default: p you have #{friends} friends
//- Declaration
mixin list
ul
li foo
li bar
li baz
//- Use
+list
+list
mixin pet(name)
li.pet= name
ul
+pet("cat")
+pet("dog")
+pet("pig")
mixin article(title)
.article
.article-wrapper
h1= title
if block
block
else
p No content provided
+article("Hello world")
+article("Hello world")
p This is my
p Amazing article
mixin link(href, name)
//- attributes == {class: "btn"
Re: Better docs for D (WIP)
On 08.01.2016 00:13, Bastiaan Veelo wrote: My first experience with this: [...] Fixing these small documentation errors took more than an hour of my time. I just hope the PR can be merged before it needs rebasing again ;-) The master plan here is to get you invested in D. You just spent a non-trivial amount of time on improving it. You may think that has been annoying, but at the same time you don't want to see the effort go to waste. You want D to succeed now. You're one of us now. One of us. One of us. ;) More seriously, maybe someone more experienced should just take over in such cases. I think people don't do that, because * it's not common practice, * they have more than enough on their plate already, * they want to encourage the newbie to become familiar with the system so that they'll be able to make larger contributions in the future, * they don't want to steal the newbie's credit, * they'd have to wait for another staff member to review it while they can just pull it themselves when the newbie perseveres (not sure if that one's accurate). But you can totally say that it's too much trouble for you, and that you'd like someone else to take over, of course. Also, a tip: After rebasing, leave a message stating that you did. Reviewers are not notified of rebases by GitHub.
My LLVM talk @ FOSDEM'16
Hi everybody! Like the last 2 years I am a speaker in the LLVM toolchain devroom @ FOSDEM'16. My talk is not D related but more about LLVM internals. (For sure, it is related to my work on LDC!) Read the announcement at https://fosdem.org/2016/schedule/event/llvm_to_new_os/. FOSDEM is a two-day event organised by volunteers to promote the widespread use of open source software. Taking place in the beautiful city of Brussels (Belgium), FOSDEM is widely recognised as "the best open source conference in Europe". FOSDEM 2016 will take place at ULB Campus Solbosch on Saturday 30 and Sunday 31 January 2016. Read more about the event at https://fosdem.org/2016/. Regards, Kai
Re: Better docs for D (WIP)
On Thursday, 7 January 2016 at 14:05:27 UTC, Steven Schveighoffer wrote: On 1/7/16 8:38 AM, anonymous wrote: On 07.01.2016 14:31, Andrei Alexandrescu wrote: Here's a simple idea we can implement rather quickly. Say a user is browsing https://dlang.org/builtin.html and find a typo. They press a button labeled "Fix typo". That opens https://github.com/D-Programming-Language/dlang.org/edit/master/builtin.dd. From there people can edit the source file to fix the typo and create a PR, all without leaving the browser or building the documentation. We have this already. Top right corner, "Improve this page". People are using the feature occasionally. Yes, in fact, core developers use this too. It's actually quite a bit more convenient than doing stuff locally. -Steve I'm a D user and forum lurker, not a contributor. I have used this feature several times in the past and it was seamless and easy each time. For small typos/one-liners it takes <5 minutes to edit changes and submit the PR. Cheers, lobo
Re: Better docs for D (WIP)
On Thursday, 7 January 2016 at 13:38:20 UTC, anonymous wrote: We have this already. Top right corner, "Improve this page". People are using the feature occasionally. My first experience with this: 1) Seems to work well enough initially, if you can do without a preview. 2) Then the request comes to rebase to stable [1]. There is no web interface for that, so I followed friendly instructions from the reviewer and created a new PR by hand by clicking through github and redoing the changes. Not so smooth but doable if you have been on github before. 3) Then the PR needs to be rebased again because of merge conflicts, introduced by another PR [2]. Reluctant to close the PR and correcting the mistakes a third time in a new PR, I decided to download a local clone and merge locally. Git not being part of my daily routines, that was as smooth as I feared it would be (not at all). Fixing these small documentation errors took more than an hour of my time. I just hope the PR can be merged before it needs rebasing again ;-) [1] https://github.com/D-Programming-Language/phobos/pull/3907 [2] https://github.com/D-Programming-Language/phobos/pull/3908 Bastiaan.
Berlin D Meetup January 2016
Hi All, The first Berlin D Meetup of the year will be happening at 19:30 on Friday January the 15th at Berlin Co-Op (http://co-up.de/) on the fifth floor. This time Mathias Lang will be talking about "Duck Typing in D". Both alcoholic and non-alcoholic drinks will also be available. Details are also on the meetup page here: http://www.meetup.com/Berlin-D-Programmers/ Thanks, Ben.
Re: Better docs for D (WIP)
On Thursday, 7 January 2016 at 06:30:28 UTC, Rory McGuire wrote: If not a tagging system then at least adding synonyms would be great. dpldocs.info actually had this in its first version, way back in 2010, because so many people would ask me these kinds of things. In the first draft, I did it as a separate database. In the new one, I will add a "Tags:" section to my ddoc parser that will figure them all out. The search engine will use it definitely, and perhaps the See Also referencer too, though I'm not sure about how that'd look. I need to flesh things out a bit more. I'm also thinking about adding a "category" thing too but submodules or aggregates in the source code are usually better there, so I'll probably stop at tags. In the ddoc source code, the section would look like: /++ Some explanation See_Also: * $(REF indexOf) * $(REF findSplit) Tags: contains, in +/ canFind()... That is, the tags is just a comma-separated list of keywords in the source.
Re: Better docs for D (WIP)
On Thursday, 7 January 2016 at 13:31:57 UTC, Andrei Alexandrescu wrote: On 1/6/16 1:54 AM, default0 wrote: In the end most of this comes down to a lack of motivation: I'm fine trying to improve documentation text if I see an issue about it, but if that entails stopping what I was originally doing for so long that I will possibly forget what I was originally doing (ie requires me to read documentation on how to set up a whole new development environment), I will usually decide that nah, it isn't THAT important. Yeah, I empathize a lot. Adam's idea for using web forms for fixes is great. Here's a simple idea we can implement rather quickly. Say a user is browsing https://dlang.org/builtin.html and find a typo. They press a button labeled "Fix typo". That opens https://github.com/D-Programming-Language/dlang.org/edit/master/builtin.dd. From there people can edit the source file to fix the typo and create a PR, all without leaving the browser or building the documentation. If this is too heavy-handed, I think Adam's idea of web forms for simple changes is great. We could devise a simple web form in e.g. errata format a la "Replace this" ... "With this". Would this improve the state of affairs? Creating the "Fix Typo" button is an easy project. Andrei Something along those lines would certainly be very encouraging for making small changes here or there, as it removes much of the learning curve if all I want to do is suggest to change something. That being said, the improvement would be marginal if most of these PRs end up not getting much attention. For instance, if what I'm doing is not fixing a typo but rephrasing two sentences, then the mentality of someone reviewing the PR should not be to simply say yes or no to the change, but to take it as a suggestion that ought to be thought about and possibly improved upon (with or without involvement of the original PR-creator). That is, the line of thinking should be "someone thought what was here originally could be phrased better/wasn't obvious enough about a certain aspect, why and how can we improve it?" given that his rephrasing is not satisfactory or up to quality standards. All that aside, something small like this while being helpful does not address the issues of the documentation as a whole that Adam is also tackling (layout, navigation, inter-linking(!), pages to explain idioms/commonly used concepts) and having two "official" documentations (one being experimental, I take it) is also less than helpful for navigating around and with regards to these, I would defer to Adams reasoning behind why he chose to not improve on this as opposed to starting over since I am by no means involved enough with this to have my own opinion about how difficult it is to make these types of changes.
Re: Better docs for D (WIP)
On 07.01.2016 14:31, Andrei Alexandrescu wrote: Here's a simple idea we can implement rather quickly. Say a user is browsing https://dlang.org/builtin.html and find a typo. They press a button labeled "Fix typo". That opens https://github.com/D-Programming-Language/dlang.org/edit/master/builtin.dd. From there people can edit the source file to fix the typo and create a PR, all without leaving the browser or building the documentation. We have this already. Top right corner, "Improve this page". People are using the feature occasionally.
Re: Better docs for D (WIP)
On 1/7/16 2:14 AM, Rory McGuire via Digitalmars-d-announce wrote: I wonder; would it be possible to make the website inline editable and then it automatically creates github pull requests that update the docs in github as D comments? Ha. I just posted about that! -- Andrei
Re: Hash Tables in D
On Sunday, 3 January 2016 at 19:29:05 UTC, Martin Nowak wrote: There is a bug. You should never do this b/c of iterator/range invalidation. foreach (key; aa.keys) aa.remove(key); I've recently hit this when trying to remove some of the elements from an AA while iterating over it. It's easy to forget that it is not allowed, especially when working on more complex algorithms. Accidentally, it worked all fine even with large data sets with DMD 2.069, but with GDC mysterious segfaults appeared - the first thought in such case was obviously a bug in GDC or in the older front-end. However, this is a very convenient, natural and intuitive syntax for something that is needed quite frequently, yet this code breaks silently in non-predictable ways. There are already registered issues concerning this (or similar with insertion) problem, including: https://issues.dlang.org/show_bug.cgi?id=4179 https://issues.dlang.org/show_bug.cgi?id=2255 https://issues.dlang.org/show_bug.cgi?id=10821 https://issues.dlang.org/show_bug.cgi?id=10876 https://issues.dlang.org/show_bug.cgi?id=13903 I've personally encountered segfaults, infinite loops, programs producing incorrect results. Some solutions to this were proposed in the bug reports - either: a) explicitly allow removing during iteration, and make sure it always works, or b) explicitly disallow removing during iteration, and always throw an Error whenever it is attempted. In some cases it could even be detectable in compile time. And I don't mean including a single sentence about this somewhere in the docs. I mean an error reported by the compiler and/or runtime. The runtime checks could be disabled for -release, but there should be at least an option to detect such errors. Probably the worst part of it is that you're free to wrap it in @safe, while it's not safe at all.
