Re: The hackathon week roundup
On 5/2/2015 7:43 PM, Rikki Cattermole wrote: Shouldn't it be creative commons because it is more a creative work aka documentation? Everything else is boost licensed. Consistency.
Re: DTiled: Tiled map loader
On Saturday, 2 May 2015 at 19:16:03 UTC, rcorre wrote: Any D game developers out there looking to create a tile-based game? DTiled aims to provide a quick and easy way to load maps created with Tiled Good! Thank you!
Re: DTiled: Tiled map loader
Nice that you named Dgame on your repo. ;) As soon as it supports XML and CSV I would definitely use it. Everyone who starts a game in D calls it Dgame!
Re: The hackathon week roundup
On Sunday, 3 May 2015 at 04:13:35 UTC, Andrei Alexandrescu wrote: On 5/2/15 6:27 PM, Walter Bright wrote: On 5/2/2015 5:12 PM, Andrei Alexandrescu wrote: On 5/2/15 4:50 PM, Ilya Yaroshenko wrote: * Tutorial: http://d.readthedocs.org (btw should we link that from the homepage?) May I transfer the repositories (both GitHub and RTD) to the D-Programming-Language community? That'd be a fine idea. Thoughts from Walter, Martin et al? -- Andrei I think it's a great idea. It'd have to be Boost licensed, though. Ilya, your turn. Proceed and be bold. -- Andrei I have requested repository transfer to Andrei because only members of a organisation can transfer. Andrey or/and someone from D core team, please send me your user names at readthedocs.org.
Re: The hackathon week roundup
On Sunday, 3 May 2015 at 04:13:35 UTC, Andrei Alexandrescu wrote: On 5/2/15 6:27 PM, Walter Bright wrote: On 5/2/2015 5:12 PM, Andrei Alexandrescu wrote: On 5/2/15 4:50 PM, Ilya Yaroshenko wrote: * Tutorial: http://d.readthedocs.org (btw should we link that from the homepage?) May I transfer the repositories (both GitHub and RTD) to the D-Programming-Language community? That'd be a fine idea. Thoughts from Walter, Martin et al? -- Andrei I think it's a great idea. It'd have to be Boost licensed, though. Ilya, your turn. Proceed and be bold. -- Andrei Project Home https://readthedocs.org/projects/d/ Repository https://github.com/andralex/thenextafterc Short URLs http://d.readthedocs.org http://d.rtfd.org
Re: This Week in D #15: hackathon, mem management, ARM, tip for C coders
On Mon, 04 May 2015 03:23:07 +, Adam D. Ruppe wrote: So I guess it is more a peeve of mine than anything else, but I wanted to talk about it anyway and used the tip of the week as my vehicle. D code that looks like C isn't a bad thing, indeed, I think it is a selling point. i found that i can write code in C style first, and then gradually converting it to be more D-like. btw, it's a great way to start using D for begginers with C expirience: just do it as you are used to, and then change some parts as you learned new trick. it's very useful when converting C libraries to D. i have some libraries that is hard/impractical to rewrite from scratch in D, but i want 'em in D to ease hacking and improving. so i'm first converting code using D as better C, and then adding better interfaces or rewriting some parts. signature.asc Description: PGP signature
This Week in D #15: hackathon, mem management, ARM, tip for C coders
I covered two weeks this time, as I missed last week. http://arsdnet.net/this-week-in-d/may-03.html The tip this week might be a bit controversial but I actually feel kinda strongly about this. So many times, I see people asking questions about how to do task X in D. I think that's the wrong question: you should just be asking how to do task X. The programming language isn't terribly important: if you can do it in C, you can do it in D basically the same way; D provides similar language features to other common languages like C and Java, so a LOT of knowledge carries over from them... as long as you aren't afraid to use it. I think that when people are new to D, we ought to press this carry-over point. They don't have to forget everything and suddenly do everything the D way, using only Phobos, doing it all with lazy ranges, etc. It doesn't have to be all that new, unfamiliar territory at once. Similarly, I get a bit bothered when I see a lot of work done to add a bit of common functionality to a C library. Now, don't get me wrong, I reinvent the wheel as much as the next guy (actually, I don't even like the term reinventing the wheel exactly because so much knowledge carries over. Just because I'm re-coding it doesn't mean I'm reinventing it. By carrying over knowledge of the problem domain from any source, it makes coding it again a lot easier - I already know what needs to be done and where the pitfalls are, unlike a truly novel invention, where all that is a mystery going into it. But I digress). I almost never use third party libraries personally for a variety of reasons, so I get the desire to rewrite things, especially when D offers so many ways to do it better than ever before. But at the same time, I'm also a working programmer accustomed to things like last-minute client requests, deadlines, and other schedule constraints (including just simply not *wanting* to spend that kind of time on a problem, believe it or not, I don't actually care for programming all day every day) In these cases, being able to say yes we can, and I can do it today, though it might look like C is so much more valuable than saying maybe... if I figure out how to make it idiomatic D So I guess it is more a peeve of mine than anything else, but I wanted to talk about it anyway and used the tip of the week as my vehicle. D code that looks like C isn't a bad thing, indeed, I think it is a selling point.
Desktopfile library
dub package: http://code.dlang.org/packages/desktopfile Implementation of Desktop Entry Specification in D. Note that currently it's not fully compliant to spec, though it should work in the most cases.
Re: [hackathon] ARE WE SLIM YET?
On Sunday, 3 May 2015 at 13:20:03 UTC, cym13 wrote: I got a parsererror for data/data.json, Unrecognized token '?' Please try Chrome or Firefox.
Re: D 2.067.1
On Sunday, 26 April 2015 at 17:53:07 UTC, Martin Nowak wrote: We're glad to announce dmd 2.067.1 which includes several regression and bug fixes over 2.067.0. http://dlang.org/changelog.html#2.067.1 Please report any bug you encounter at https://issues.dlang.org/. travis-ci still uses DMD64 D Compiler v2.067.0 on default and not the latest. where can one submit a PR for this ?
Digger 2.1
Digger v2.0 (2015-04-26) * `idgen.d` update (DMD now requires DMD to build) * Full core overhaul, for improved performance, granularity and extensibility. A fresh install is recommended. Digger v2.1 (2015-05-03) * Add license (dual MPL/Boost) * Add `git` cache engine * Add `cache` action and subcommands * Fix starting `digger-web` in OS X (auto-correct working directory) https://github.com/CyberShadow/Digger/releases/tag/2.1 Digger is a tool for working with D's source code and its history. It can build D (including older D versions), customize the build with pending pull requests or forks, and find the exact pull request which introduced a regression (or fixed a bug). It comes with a web interface which makes building D from source trivial even for people new to D, Git or the command line.
Re: [hackathon] ARE WE SLIM YET?
On Sunday, 3 May 2015 at 13:04:41 UTC, Vladimir Panteleev wrote: Gah, I'm late! Anyway, this is my hackathon project: http://digger.k3.1azy.net/trend/ Succinctly, it is the lovechild of Digger and Mozilla's areweslimyet.com. It measures stats about D built from D's entire GitHub history, as well as those of programs built with said D versions. Currently only two programs are tested (empty program and hello world), so please send PRs for meaningful benchmarks. Adding new programs is very easy: http://j.mp/1I7ELEc. There is a bunch of cool things happening under the hood about which I might or might not do a full blog post later. Currently it's still collecting data from recently added benchmarks, so coverage is spotty for some tests - should be fleshed out in a few days. Enjoy! I got a parsererror for data/data.json, Unrecognized token '?'
Re: [hackathon] ARE WE SLIM YET?
On Sunday, 3 May 2015 at 13:04:41 UTC, Vladimir Panteleev wrote: Gah, I'm late! Anyway, this is my hackathon project: http://digger.k3.1azy.net/trend/ Succinctly, it is the lovechild of Digger and Mozilla's areweslimyet.com. It measures stats about D built from D's entire GitHub history, as well as those of programs built with said D versions. Currently only two programs are tested (empty program and hello world), so please send PRs for meaningful benchmarks. Adding new programs is very easy: http://j.mp/1I7ELEc. There is a bunch of cool things happening under the hood about which I might or might not do a full blog post later. Currently it's still collecting data from recently added benchmarks, so coverage is spotty for some tests - should be fleshed out in a few days. Enjoy! Cool project, can't wait to see benchmarks/compile times for larger programs get tracked.
Re: The hackathon week roundup
On Sunday, 3 May 2015 at 04:15:58 UTC, Mike wrote: My idea: 1. Members of the D leadership/committers form a working group. 2. The working group creates of list of bugs they are willing to work on. 3. Hackathon is announced. To motivate participants, the working group agrees to fix a bug of the winner's choosing. 4. After the hackathon, the working group subjectively chooses a winner from the participants. 5. The winner discloses which bug they would like fixed, and the qualified members of the working group agrees to fix it for the next release. 7. Wash, rinse, repeat. Good idea
Re: Quick Start with D: few examples and set of links.
On 1 May 2015 at 11:14, cym13 via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Friday, 1 May 2015 at 08:18:10 UTC, Ilya Yaroshenko wrote: http://d.readthedocs.org I hope this examples will be useful for students. Ilya Showing how easy interacting with python can be is a very good idea, and doing so by dealing with scientific data is an even better one! Only comment I have to say on it is rather than embedding the python script in a string, use import! immutable script = import(myscript.py); Iain
Re: Quick Start with D: few examples and set of links.
On Sunday, 3 May 2015 at 09:46:13 UTC, Iain Buclaw wrote: On 1 May 2015 at 11:14, cym13 via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Friday, 1 May 2015 at 08:18:10 UTC, Ilya Yaroshenko wrote: http://d.readthedocs.org I hope this examples will be useful for students. Ilya Showing how easy interacting with python can be is a very good idea, and doing so by dealing with scientific data is an even better one! Only comment I have to say on it is rather than embedding the python script in a string, use import! immutable script = import(myscript.py); Iain Thanks! Implemented. Ilya
Re: DTiled: Tiled map loader
On Sunday, 3 May 2015 at 06:57:34 UTC, tired_eyes wrote: Nice that you named Dgame on your repo. ;) As soon as it supports XML and CSV I would definitely use it. Everyone who starts a game in D calls it Dgame! That may be true, but I was referring to my framework.
Re: DTiled: Tiled map loader
On Sunday, 3 May 2015 at 01:18:01 UTC, rcorre wrote: On Saturday, 2 May 2015 at 19:24:12 UTC, Namespace wrote: Nice that you named Dgame on your repo. ;) As soon as it supports XML and CSV I would definitely use it. For my April/Mai game Angry Snowball (https://github.com/Dgame/AngrySnowball) I use currently a CSV format. Unfortunately XML support is not a top priority for me, as I always use the JSON format. I normally have a build step that converts updated TMX file sto JSON files, which isn't a big deal since I already have a sort of content pipeline for music and art. It is a possibility but I'd need to find a good XML serializer. Orange looks good but isn't on dub, and I'd like to integrate it in a way that users who only want JSON don't need to pull in the XML dependency (and visa-versa). Out of curiosity, any reason for preferring the XML format? Not that I have a good reason for preferring JSON. No, no reason. And at the moment I am using CSV, so CSV would be my top priority.
[hackathon] ARE WE SLIM YET?
Gah, I'm late! Anyway, this is my hackathon project: http://digger.k3.1azy.net/trend/ Succinctly, it is the lovechild of Digger and Mozilla's areweslimyet.com. It measures stats about D built from D's entire GitHub history, as well as those of programs built with said D versions. Currently only two programs are tested (empty program and hello world), so please send PRs for meaningful benchmarks. Adding new programs is very easy: http://j.mp/1I7ELEc. There is a bunch of cool things happening under the hood about which I might or might not do a full blog post later. Currently it's still collecting data from recently added benchmarks, so coverage is spotty for some tests - should be fleshed out in a few days. Enjoy!
Re: [hackathon] ARE WE SLIM YET?
On Sunday, 3 May 2015 at 13:04:41 UTC, Vladimir Panteleev wrote: It measures stats about D built from D's entire GitHub history, as well as those of programs built with said D versions. Currently only two programs are tested (empty program and hello world), so please send PRs for meaningful benchmarks. Adding new programs is very easy: http://j.mp/1I7ELEc. You can find a few self-contained benchmarks at https://github.com/D-Programming-Dash. This is the compiler performance CI project I started a while ago, but unfortunately couldn't quite finish yet due to life/academia getting in the way. My focus for this project was a bit different, though. I primarily collected real-world test cases instead of trying to focus on the most meaningful ones, and there is quite a number of them. The history tracking display mode is not written yet, and the UI lacks a lot of tooltips, etc. (In case anybody is curious what the current state looks like: http://dash.klickverbot.at/dash1/compare/gdc_main:release_boundschecked@current..ldc_master:release_boundschecked@current. It seems that the system hit a GitHub API rate limit from which it failed to recover some time in January, though, so there are no recent results. Also, the server currently runs in debug mode and I didn't put any effort into front-end optimizations yet, so expect it to be slow.) — David
Re: [hackathon] ARE WE SLIM YET?
On 5/3/15 6:04 AM, Vladimir Panteleev wrote: Gah, I'm late! Anyway, this is my hackathon project: http://digger.k3.1azy.net/trend/ Succinctly, it is the lovechild of Digger and Mozilla's areweslimyet.com. It measures stats about D built from D's entire GitHub history, as well as those of programs built with said D versions. Currently only two programs are tested (empty program and hello world), so please send PRs for meaningful benchmarks. Adding new programs is very easy: http://j.mp/1I7ELEc. There is a bunch of cool things happening under the hood about which I might or might not do a full blog post later. Currently it's still collecting data from recently added benchmarks, so coverage is spotty for some tests - should be fleshed out in a few days. Enjoy! This is awesome! Any chance to get the guilty commit more precisely? For example I see a large jump recently, but any of 3 dozens commits (or a combination thereof) could have caused it. Andrei
Re: [hackathon] ARE WE SLIM YET?
On Sunday, 3 May 2015 at 19:06:50 UTC, Andrei Alexandrescu wrote: On 5/3/15 12:04 PM, Andrei Alexandrescu wrote: This is awesome! Any chance to get the guilty commit more precisely? For example I see a large jump recently, but any of 3 dozens commits (or a combination thereof) could have caused it. Oh, it looks like the zoom feature already does that. Apparently a jump from 492KB to 1,379KB was caused by this? https://github.com/D-Programming-Language/tools/pull/130 Not sure how you got that. The program-hello-binarysize spike from May 2014 was caused by https://github.com/D-Programming-Language/dmd/pull/2561 .
Re: [hackathon] ARE WE SLIM YET?
On Sunday, 3 May 2015 at 19:04:20 UTC, Andrei Alexandrescu wrote: This is awesome! Any chance to get the guilty commit more precisely? For example I see a large jump recently, but any of 3 dozens commits (or a combination thereof) could have caused it. Keep zooming in until you start seeing individual commits. If the lines begin to disappear, there is as of yet insufficient data, check back in a few hours. I wrote a little help page here: https://github.com/CyberShadow/TrenD/wiki
Re: [hackathon] ARE WE SLIM YET?
On 5/3/15 12:04 PM, Andrei Alexandrescu wrote: This is awesome! Any chance to get the guilty commit more precisely? For example I see a large jump recently, but any of 3 dozens commits (or a combination thereof) could have caused it. Oh, it looks like the zoom feature already does that. Apparently a jump from 492KB to 1,379KB was caused by this? https://github.com/D-Programming-Language/tools/pull/130 Andrei
