Silly v1.0.0 finally released!
Hi, I am glad to announce that a new version of silly, tiniest and smallest unit-test runner, has been released. There are just a few changes compared to v0.8.2: - Licence has been changed to ISC. It is identical to the MIT licence used in the past, just fancy and new - CI is now using latest DMD/LDC to test silly weekly - Web page has been removed, all of the necessary documentation is now in the README - A couple of other internal improvements that help with occasional SEGFAULTs caused by tests in a template, make compilation faster a bit and utilize latest features of DMD and LDC (isModule trait) Page on DUB: http://silly.dub.pm/ Repository: https://gitlab.com/AntonMeep/silly
Re: silly is released - new test runner for the D programming language
On Wednesday, 12 September 2018 at 04:02:14 UTC, Soulsbane wrote: On Sunday, 12 August 2018 at 15:07:04 UTC, Anton Fediushin wrote: Hello, I'm glad to announce that silly v0.0.1 is released. Silly is a brand-new test runner with simplicity in mind. It's developed to be as simple as possible and contain no useless features. Another important goal is to provide flexible tool which can be easily integrated into existing environments. In my local version I've modified the test name to be colorized. Could you add this feature? it really helps the readability in my opinion. I doubt that will make it more readable, in fact it'd annoy me. Another thing to consider is the fact that colours in terminal are highly customizable so if something works and most importantly looks good for somebody it might look terrible and be unreadable on different terminal preferences. This is something I experienced with trial which colours test names white and vibe-core's logger which used different shades of grey for different log levels. Both of these as you can imagine are unreadable on black-on-white terminals. Either way, I really love silly! Thanks a lot! You are welcome!
tg.d - Telegram Bot API client implementation for D v0.0.1 is released
Greetings, I am glad to announce that tg.d is finally released. Telegram Bot API is an extremely flexible and robust platform which can be used to build bots that interact with users utilizing fast instant messaging application on your smartphone and PC. All data is synchronized across all devices, making it easy to switch between them. Tg.d is a fork of project telega. There are some missing features (like webhooks and file uploading) but it is ready to be used in hobby projects. Read "Introduction to bots" which explains what bots are and what they're good at. After you create a new bot with the help of the BotFather you can use token to run examples: ``` git clone https://gitlab.com/ohboi/tg.d.git -b v0.0.1 cd tg.d dub examples/echo.d -- --token= ``` This will start a bot which will send your messages back. Repository: https://gitlab.com/ohboi/tg.d Package page: http://tg-d.dub.pm/ API reference: https://ohboi.gitlab.io/tg.d/ Introduction to bots: https://core.telegram.org/bots Telegram Bot API documentation: https://core.telegram.org/bots/api Telega: https://github.com/nexor/telega
Re: silly is released - new test runner for the D programming language
On Wednesday, 15 August 2018 at 14:01:24 UTC, rikki cattermole wrote: On 16/08/2018 1:31 AM, Bogdan Szabo wrote: I wonder if the test runners could provide a template for the injected code, that dub could use it on `dub test`. I wonder if we could add something like `"testRunner": "trial"` in the dub.json file. I've thought about this a bit. Adding special support for test runners does seem like a bad idea. An alternative could be to enable injection of a mixin template by the compiler for each compiler parsed. You can either get an alias to initialize a template for only type purposes, or you can throw a module constructor in. That would enable more interesting use cases like route registration for web routers. I disagree, adding special support for test runners is great, in fact dub already has that (it uses `tested` if it's installed). What we need to do is just extend this feature a little bit and tell the ones who develop test runners to update them accordingly. I'd be happy to have that and I think Atila and Bogdan too. Also, dub has special support for documentation generators that are compatible with ddox. There's `"-ddoxTool"` configuration option. I think we could do the same with test runners being compatible with tested.
Re: silly is released - new test runner for the D programming language
On Wednesday, 15 August 2018 at 14:33:26 UTC, Steven Schveighoffer wrote: On 8/12/18 11:07 AM, Anton Fediushin wrote: Hello, I'm glad to announce that silly v0.0.1 is released. Silly is a brand-new test runner with simplicity in mind. It's developed to be as simple as possible and contain no useless features. Another important goal is to provide flexible tool which can be easily integrated into existing environments. Instead of using dub as part of the test runner or hacking into `preBuildCommands` silly seamlessly integrates into `dub test` requiring user to just add it as a dependency into dub.json or dub.sdl. Check out project's website [1], repository [2] and page on dub registry [3] where you can find more information. [1]: https://ohboi.gitlab.io/silly/ [2]: https://gitlab.com/ohboi/silly [3]: https://silly.dub.pm/ I notice that you're using the new unittest system added in 2.078, but bypassing the reporting mechanism (i.e. using exit instead of returning). Is there a reason why? This is exactly the type of thing I envisioned would be used when developing said feature. I'm asking because I'd like to understand what the limitations are that caused you to bypass it. -Steve Thanks for pointing it out, I never really looked into that. I used `exit` before because everything was split into functions, so it was simpler to just `exit` than return things here and there. It's fixed now in v0.0.2. I'm still using own printer for summary, because built-in one is boring: --- Summary: 2 passed, 2 failed in 0 ms --- vs --- 2/4 unittests FAILED ---
Re: silly is released - new test runner for the D programming language
On Wednesday, 15 August 2018 at 08:42:46 UTC, Bogdan Szabo wrote: Nice work Anton! It's nice to see that people are interested in writing better test runners. This project reminds me of `tested`: http://code.dlang.org/packages/tested Thanks, tested works just like unit-threaded - list of modules has to be passed to a special template. Silly, on the other hand, exploits features of dub to do its job. Well, 'advertise' might not be the right word for that, but both unit-threaded and trial provide means to write integration tests. Even though there is support for some simple things like creating temporary files and defining steps, it goes beyond "unit testing" but is not enough for integration tests. This kind of testing can require things like setting up a database or running other services which cannot be done with existing tools. ... For me, integration tests are long and sometimes are too many. When you embed the integration tests inside the source code makes harder to find the tested code. I know that we lack of features for the integration tests, but my time is limited and I would like work on other projects too... It's ok, we're all enthusiasts here. I would like to see if we can make those runners compatible, in the sense that if someone wants to switch from silly to unit-threaded or trial, to be done with no headaches. Removing silly will be simple enough, but switching between runners... not so much, it'd require different `configurations` in dub.json for different runners. What we could do though is improve dub to handle this in the same way it uses tested to run tests when it's installed [1]. [1]: https://github.com/dlang/dub/blob/9914720ca5dcd9b37eb2ec0ffb08f218642a1960/source/dub/dub.d#L717
Re: silly is released - new test runner for the D programming language
On Monday, 13 August 2018 at 11:57:34 UTC, Atila Neves wrote: On Monday, 13 August 2018 at 04:13:46 UTC, Anton Fediushin wrote: On Sunday, 12 August 2018 at 21:33:21 UTC, Dechcaudron wrote: On Sunday, 12 August 2018 at 15:07:04 UTC, Anton Fediushin wrote: Problem with unit-threaded and similar tools is that they are too complicated for no particular reason. Yes, I often wake up and think to myself "what feature can I add that aren't going to be useful to anyone at all?" then write some code. Nobody adds complication "for no particular reason". Even people who shouldn't be doing it do it because they're trying to accomplish something else. Hacking into dub.json to add some scripting into it is not something everybody wants to waste their time on. Agreed. Other than manually listing modules however (which is what I do these days anyway due to a dub bug), I don't know of a better way. I wish there were a compile-time trait like __traits(allModules). I've thought of writing a DSI Sadly, there's no better way yet. Silly imports `dub_test_root` which contains all of the modules. That's why no `main()` should be defined and tests must be run with `dub test`. Another thing, these tools are trying to be everything people might need adding all kinds of features nobody really uses. For example, assertions in unit-threaded and a lot of different reporters in trial. This is a good point. I think I should split unit-threaded up into separate dub subpackages. Thanks for the idea! That'd be nice. These tools also advertise usage of built-in `unittest` blocks for integration testing. I think it's just wrong because `unittest`s are obviously meant for unit testing and slapping integration tests on with some duct tape and zip ties is not a good solution. Integration testing needs it's own tool and it's quite possible that I'll end up writing one soon or later. I'm curious as to why you think that's the case. Well, 'advertise' might not be the right word for that, but both unit-threaded and trial provide means to write integration tests. Even though there is support for some simple things like creating temporary files and defining steps, it goes beyond "unit testing" but is not enough for integration tests. This kind of testing can require things like setting up a database or running other services which cannot be done with existing tools. ...
Re: silly is released - new test runner for the D programming language
On Sunday, 12 August 2018 at 21:33:21 UTC, Dechcaudron wrote: On Sunday, 12 August 2018 at 15:07:04 UTC, Anton Fediushin wrote: Silly is a brand-new test runner with simplicity in mind. It's developed to be as simple as possible and contain no useless features. Another important goal is to provide flexible tool which can be easily integrated into existing environments. I like the "add as dependency and you're done" thing (unfortunately you have to apply conditional compilation to main(). But quick question (just playing the devil's advocate). Why use this library instead of, say, unit-threaded? Problem with unit-threaded and similar tools is that they are too complicated for no particular reason. Hacking into dub.json to add some scripting into it is not something everybody wants to waste their time on. Trial might be the first test runner to solve this problem because it just runs as a stand-alone tool and uses dub internally, but it takes forever to compile. It uses too many compile-time features which results in high RAM usage and slow compilation times. Another thing, these tools are trying to be everything people might need adding all kinds of features nobody really uses. For example, assertions in unit-threaded and a lot of different reporters in trial. These tools also advertise usage of built-in `unittest` blocks for integration testing. I think it's just wrong because `unittest`s are obviously meant for unit testing and slapping integration tests on with some duct tape and zip ties is not a good solution. Integration testing needs it's own tool and it's quite possible that I'll end up writing one soon or later. Silly is just my attempt to improve current state of D's ecosystem where programmers don't use advanced test runners, well, because it doesn't worth it for small projects.
silly is released - new test runner for the D programming language
Hello, I'm glad to announce that silly v0.0.1 is released. Silly is a brand-new test runner with simplicity in mind. It's developed to be as simple as possible and contain no useless features. Another important goal is to provide flexible tool which can be easily integrated into existing environments. Instead of using dub as part of the test runner or hacking into `preBuildCommands` silly seamlessly integrates into `dub test` requiring user to just add it as a dependency into dub.json or dub.sdl. Check out project's website [1], repository [2] and page on dub registry [3] where you can find more information. [1]: https://ohboi.gitlab.io/silly/ [2]: https://gitlab.com/ohboi/silly [3]: https://silly.dub.pm/ Cheers, Anton
Re: Symmetry Autumn of Code
On Saturday, 14 July 2018 at 06:02:37 UTC, Mike Parker wrote: Thanks to the sponsorship of Symmetry Investments, the D Language Foundation is happy to announce the Symmetry Autumn of Code! We're looking for three university students to hack on D this autumn, from September - January. We're also in search of potential mentors and ideas for student projects. Head to the Symmetry Autumn of Code page for the details. Spread the word! https://dlang.org/blog/symmetry-autumn-of-code/ I wish I could participate but even though I am 18 years old, I am studying at the secondary school. I hope something similar gets arranged next year. Good luck to all of the participants!
Re: docker images
On Friday, 29 June 2018 at 04:51:49 UTC, Joakim wrote: On Thursday, 28 June 2018 at 17:54:45 UTC, Radu wrote: Created a couple of docker images useful for dlang dev. LDC cross compiler for ARM - https://hub.docker.com/r/rracariu/ldc-linux-armhf/ This image allows one to easily cross compile to ARM. Main use-case is continuous integration servers. - https://hub.docker.com/r/rracariu/dub-registry/ Allows easily running a private dub repository on cloud. Note that there is also an Alpine container with LDC, should be useful for building D microservices: https://hub.docker.com/r/andrewbenton/alpine-ldc/ It would be so nice if I knew about this image earlier. I ended up making my own minimal image for LDC with OpenSSL 1.1 and goinsu for privilege lowering. https://hub.docker.com/r/ohboi/minildc/ It's 153MiB, which is just 53MiB bigger than alpine-based image. I think I did a pretty good job there, most importantly there aren't any problems with musl libc, since it's based on debian-slim. Yet still I don't really use this image - LDC has some problems compiling my vibe.d applications. For every CI build I use my other image: https://hub.docker.com/r/ohboi/minidmd/ Which is the same thing, but with DMD instead. It's even smaller, only 91MiB.
Re: D only has Advantages
On Thursday, 14 June 2018 at 11:19:37 UTC, jmh530 wrote: On Thursday, 14 June 2018 at 10:18:26 UTC, Walter Bright wrote: Evidently my brand of humor got lost in translation. I grovel and beg for forgiveness, and will appropriately flagellate myself with a wet noodle. I found myself getting in trouble when I was texting and being sarcastic. I always add the little winky face now. People don't get mad anymore, but instead just say I'm not funny. Good trade-off. I think everybody should just calm down and don't think too much about such things. I honestly don't know how a little joking post can bring up DPRK and propaganda. Also, did you notice that DPRK starts with D? ;) And your jokes aren't funny. ;) Just like mine. ;)
Re: D only has Advantages
they have bugs and features D only has features
Re: iopipe v0.1.0 - now with Windows support!
On Tuesday, 12 June 2018 at 14:00:32 UTC, Steven Schveighoffer wrote: File.byLine is fast, but only because of the underlying non-range tricks it uses to achieve performance. And iopipe still is 2x faster. I wish iopipe was around a little bit earlier so I could use it in my small project. It doesn't use IO much, just reads large file (60GB+) and computes some hashes. Now I'd like to rewrite it using iopipe just to compare the performance.
Re: iopipe v0.1.0 - now with Windows support!
On Sunday, 10 June 2018 at 20:10:31 UTC, Steven Schveighoffer wrote: iopipe version 0.1.0 has been released. iopipe is a high-performance pipe processing system that makes it easy to string together pipelines to process data with as little buffer copying as possible. I saw iopipe a while back, but never looked at it closely. Now I did and... it implements its own kind of pattern and not ranges? I guess it is done for the sake of performance, but how easy it is to use iopipe with standard range-based methods from std.algorithm for example? As long as it's easy to use with the rest of the phobos - I'd like to see it in the standard library. This version ONLY builds on 2.080.1 or later (the bug fix that I submitted at dconf has been merged in that version, and so iopipe will now build against Martin Nowak's io library). In fact, iopipe development was kind of stalled due to this bug, so I'm super-happy to see it fixed and released! These are great news, keep it up!
Re: dlangbot for Telegram - D compiler in your pocket
On Monday, 11 June 2018 at 12:32:32 UTC, Dechcaudron wrote: On Monday, 11 June 2018 at 05:50:56 UTC, Anton Fediushin wrote: Regarding vulnerabilities, if there are any I and authors/maintainers of dlang-tour will be interested in fixing them ASAP. After all, dlangbot uses tour's code under the hood. Then I assume all trivial vulnerabilities are taken care of. I just thought you had implemented this from scratch to run on a computer of yours. I'd like to believe it though I know there must be a bug somewhere. There always is. Dlangbot runs on AWS. I use docker-compose to isolate all of the related services (bot, database and the one which executes the code). Executable downloading would require me to rewrite the back-end. I am not sure if it'll worth it because it's not clear how safe that would be for a user and how usable that feature will be. I mean, if user already has x86-64 Linux machine (that's what dlangbot uses) then will it be any simpler and faster to message the bot with code, download an executable and run it than compiling it using installed compiler? Here you are assuming the user has a compiler installed on his machine. It may not be the case in some environments or for some people that are just toying around with the language. I think my assumption is right, because newbies are more likely to start with D either reading books or dlang-tour which provides means to compile and execute examples and edit them as one wants. Even dub, official package manager and build tool for D promotes using `dub run package` instead of building the project and running an executable manually. This approach does make sense because it prevents some silly mistakes people make. I'll open an issue about your idea, but I can't see it being very useful so it's very unlikely to be implemented at all. Who knows though, it might be very easy to do if I decide to change the architecture of the whole project.
Re: dlangbot for Telegram - D compiler in your pocket
On Sunday, 10 June 2018 at 19:54:20 UTC, Dechcaudron wrote: On Saturday, 9 June 2018 at 20:28:24 UTC, Anton Fediushin wrote: Hello, I am glad to announce that new Telegram bot which can execute D code is up and running! Check it out here: https://t.me/dlangbot Features: - Two compilers to choose from: dmd (default) and ldc - Support for custom compiler arguments with `/args` command - It's possible to set program's stdin with `/stdin` - Code is automatically compiled and ran again when you edit your message Repository: https://gitlab.com/ohboi/dlangbot Any ideas on how to improve it are appreciated! As much as I love Telegram bots and D, compilation and execution offered by a bot provides no clear advantage to me (still, I kinda like it). I assume you are looking out for potential vulnerabilities? How about allowing for download of the executable? This bot has the same purpose as run.dlang.io - a sandbox to try some things and share code with people. Even though sharing can be done with simple 'highlight your message with code and bot's reply -> share these messages' I am thinking about ways to make it simpler and faster. Regarding vulnerabilities, if there are any I and authors/maintainers of dlang-tour will be interested in fixing them ASAP. After all, dlangbot uses tour's code under the hood. Executable downloading would require me to rewrite the back-end. I am not sure if it'll worth it because it's not clear how safe that would be for a user and how usable that feature will be. I mean, if user already has x86-64 Linux machine (that's what dlangbot uses) then will it be any simpler and faster to message the bot with code, download an executable and run it than compiling it using installed compiler?
dlangbot for Telegram - D compiler in your pocket
Hello, I am glad to announce that new Telegram bot which can execute D code is up and running! Check it out here: https://t.me/dlangbot Features: - Two compilers to choose from: dmd (default) and ldc - Support for custom compiler arguments with `/args` command - It's possible to set program's stdin with `/stdin` - Code is automatically compiled and ran again when you edit your message Repository: https://gitlab.com/ohboi/dlangbot Any ideas on how to improve it are appreciated!
Re: GitHub could be acquired by Microsoft
On Monday, 4 June 2018 at 18:17:24 UTC, Joakim wrote: On Monday, 4 June 2018 at 09:47:58 UTC, Anton Fediushin wrote: Oh look, rumours are confirmed: https://itsfoss.com/microsoft-github/ MS bought GitHub for $5 billion. It's official, Nat Friedman, formerly of Xamarin, is the new CEO: https://blog.github.com/2018-06-04-github-microsoft/ Also, there's an article from Satya Nadella, current CEO of Microsoft: https://blogs.microsoft.com/blog/2018/06/04/microsoft-github-empowering-developers/ MS is basically selling a story to Wall Street, "Everything new we tried since Windows and Office has failed abysmally, so we've learned our lesson and will be the business software company from now on," hence buying LinkedIn, pushing Azure, and now buying Github. I don't expect this new management direction to go any better. Of course MS does, since they spent $5 billion on it. They will try their best to make profit out of it, just like they did with LinkedIn.
Re: GitHub could be acquired by Microsoft
On Monday, 4 June 2018 at 09:38:57 UTC, Vladimir Panteleev wrote: On Monday, 4 June 2018 at 05:50:26 UTC, Anton Fediushin wrote: I can think of hundreds of things what can go wrong including: forcing users to use Microsoft accounts, advertising own products, changing search to Bing (that's pretty bad one, no idea how I came up with it) and more and more. Something that might be worth being concerned about is that Microsoft might be more strict in policing its online properties than GitHub, so watch out for them shutting down projects/repositories of politically charged subjects, or those e.g. based on reverse-engineered MS code. GitHub removed repositories before when contents were illegal. That's an interesting question though: now there's nothing stopping MS from changing user agreement and removing repositories without any kind of legal lawsuit. Also, nothing stops MS from making it harder for other big companies like Google and Apple to support and host their projects on the GitHub.
Re: GitHub could be acquired by Microsoft
On Monday, 4 June 2018 at 08:42:08 UTC, Walter Bright wrote: On 6/3/2018 8:51 PM, Anton Fediushin wrote: This is still just a rumour, we'll know the truth on Monday (which is today). We'll stay on Github as long as it continues to serve our interests, which it has done very well, and I have no reason to believe will change. It's understandable, moving organization this big around is not easy and it shouldn't be done unless it is absolutely needed. We have a number of ties to Microsoft: It's great to know that MS is so nice to D. I guess that's because D isn't something over-hyped and MS might be interested in technologies, not in money or popularity.
Re: GitHub could be acquired by Microsoft
Oh look, rumours are confirmed: https://itsfoss.com/microsoft-github/ MS bought GitHub for $5 billion.
Re: GitHub could be acquired by Microsoft
On Monday, 4 June 2018 at 04:40:44 UTC, Jonathan M Davis wrote: On the bright side, maybe this will encourage online repo hosting to become less of a monopoly as folks move elsewhere due to their concerns about Microsoft. - Jonathan M Davis Can't agree more: GitLab and Bitbucket deserve more attention. Speaking of which, there's huge spike [1] in project imports on GitLab. These are some great news for it, I hope it doesn't crash. [1] https://monitor.gitlab.net/dashboard/db/github-importer?orgId=1
Re: GitHub could be acquired by Microsoft
On Monday, 4 June 2018 at 04:26:25 UTC, Dmitry Olshansky wrote: On Monday, 4 June 2018 at 03:51:15 UTC, Anton Fediushin wrote: This is still just a rumour, we'll know the truth on Monday (which is today). Some articles about the topic: https://fossbytes.com/microsoft-github-aquisition-report/ https://www.theverge.com/2018/6/3/17422752/microsoft-github-acquisition-rumors What's your opinion about that? Will you continue using GitHub? Well, MS already contributes big time to many open-source projects, including Git. I do not see immanent problem with them buying it. I can think of hundreds of things what can go wrong including: forcing users to use Microsoft accounts, advertising own products, changing search to Bing (that's pretty bad one, no idea how I came up with it) and more and more. I can agree though that last 5 years or so Microsoft is doing well with open-source projects. Question is: will it carry on with open-source? Both GitLab and Bitbucket can be used instead to host your D projects - dub registry supported them for a while now. Both are fine, though Gitlab seems more sexy now. Indeed it is. GitHub is stuck in 2010-s and the UI of GitLab is beautiful and smooth. IMHO Microsoft isn't the type of company I want to see behind the GitHub. Maybe I am wrong since Microsoft has both money and programmers to improve it further, I just don't trust them too much which is the right thing to do when dealing with companies. Would you trust Google? Me, I’m not. In fact if we were to place trust, comercial IT companies would be pretty down on my list of “trust” in any case. If you'd ask me a year or two ago - maybe, but now I have no idea what Google is doing and last bits of trust I had are gone.
GitHub could be acquired by Microsoft
This is still just a rumour, we'll know the truth on Monday (which is today). Some articles about the topic: https://fossbytes.com/microsoft-github-aquisition-report/ https://www.theverge.com/2018/6/3/17422752/microsoft-github-acquisition-rumors What's your opinion about that? Will you continue using GitHub? Both GitLab and Bitbucket can be used instead to host your D projects - dub registry supported them for a while now. IMHO Microsoft isn't the type of company I want to see behind the GitHub. Maybe I am wrong since Microsoft has both money and programmers to improve it further, I just don't trust them too much which is the right thing to do when dealing with companies. This means that I will move my repositories elsewhere and use GitHub just to contribute to other projects.
Re: Vulkan ErupteD breaking changes and transition strategy
On Monday, 26 March 2018 at 11:13:03 UTC, ParticlePeter wrote: I strongly believe that the generator can be made fail safe, so that the produced binding is error free. I will elaborate a little more about the greater plan at the bottom, I just didn't think that anyone is interested in it. Well, I am interested in it - Vulkan is cool and so is D. Here I was hoping for a little more attentive reading, the bugfix (if any bugs happen in the end) for v1.1.70 would be v1.1.71 (as in "point seven ONE") -bugfix.1. I would hope for community colaboration to always use prerelease. Not sure if this is the best idea, as it cannot be specified in dub dependency afaics, but only on dub upgrade. That might actually be expecting to much from users. I'll think about it. But then 1.1.71 without `-bugfix.1` will be a binding to vulkan v1.1.71? That doesn't make any sense. Dah again, no it cannot. Could it be that you are talking about DEPRECATED ErupteD? Please compare [0] and [1], and their project names. I'm talking about erupted-v1. Erupted-V2 doesn't work for me - when compiling on Linux it fails on some Windows-specific code. I'll open an issue as soon as I get home. I am really sorry for that, I have an idea what might be wrong. Please, if you don't min, post an issue with the error. I hope that in this alpha stage of ErupteD-V2, where some poo poo was expected to hit the fan, it would be ok to move the semvers. Actually, if you use ErupteD as a submodule, why do care about semvers at all? Because dub can notify about new version. That's why it exists in the first place Sorry, here I cannot follow any more, so why are you using it then as a submodule again? Erupted_v1 has a configuration which uses old derelict-util. Even though I use derelict-glfw to load vulkan, dub downloads both old derelict-util and the new one used by derelict-glfw. This results in warnings because versions mismatch (erupted wants old one while derelict-glfw uses newest). I opened an issue about erupted-v2 on linux as well: https://github.com/ParticlePeter/Erupted-V2/issues/1 The GREATER Plan - as promised -- I want to evolve and learn more about techniques which I have never touched before. This is already great I would think. But fun aside, I would like to look into full automation. 1.) get informed about vulkan-docs updates, trigger automated build process with V-Erupt. Is this possible? Don't know, want to find out. I think it is possible. 2.) setup auto testing for ErupteD-V2. If fail, get informed. Else apply version tag, the same as vulkan-docs. Is this possible? Don't know, want to find out. It is possible but tests are required. More tests - better.
Re: Vulkan ErupteD breaking changes and transition strategy
On Monday, 26 March 2018 at 09:20:13 UTC, ParticlePeter wrote: First of all, don't worry, don't panic, we will figure it out, together ;-). Everything will be alright in the end, and if not, its not the end. On Monday, 26 March 2018 at 07:04:00 UTC, Anton Fediushin wrote: 1. This breaks semver. You shouldn't just use Vulkan's versions. If you release 1.0.69 which contains bindings to Vulkan 1.0.69 and there is a bug in the binding which you want to fix, you have to increase PATCH number which results in 1.0.70 which (obviously) is not a binding to Vulkan 1.0.70. The bug then is not in ErupteD but in its generator. It needs to be fixed there. The plan was to then move the sem vers to the bug fix release. Never done that, wanted to try it. Buuut, got inspired by a great idea 3 min ago (please read on). After generator is fixed it'll produce new binding which should be marked as a new release. Even though you can use PRE-RELEASE part of semver to show users that this is a bugfix release (ie. 1.0.69-bugfix.1) this shouldn't be used because it breaks semver *again* and dub (which follows semver) isn't going to tolerate that. Great idea! Have not considered it. So the Bug fix for version 1.1.70 could be 1.1.71-bugfix.1. How does it screw up dub semver? Dub isn't going to use pre-release version unless it is specified in user's dub.json. So, if user already has erupted 1.1.70 as a dependency, he will *never* receive 1.1.70-bugfix.1 unless he updates his dub.json. Basic 'dub upgrade' won't work in this case. This is a *bad* idea and you shouldn't do that. Why is it a bad idea, could you elaborate? Because it doesn't follow semver meaning that dub won't work correctly. Just increase MAJOR version and start from there: 2.0.0 - Changing how binding works, Vulkan v1.0.69 2.1.0 - Vulkan 1.0.70 ...And so on. This way semver is followed and you don't have to mess with erupted-v1 and erupted-v2 repos. Thought about that, but there is one issue which I mentioned in the announcement. I experience it as a bad idea to have the generator part of the binding. Both of them have different purpose and should have different version numbers. Meta data is nice approach as in GenVer+VulkanVer, but unfortunately dub upgrade is not triggered if Only vulkanVer increments. Hm... Indeed, metadata change isn't going to trigger an update neither does pre-release. My solution: 1. Add generator as a git submodule (generator could be versioned) 2. Start versioning from 2.0.0 increasing MINOR when new Vulkan version is supported and increasing PATCH when bug fixes happen. Metadata can be added too. This way users are going to always get latest version possible. It'll look like this: 2.0.0+1.0.69 2.0.1+1.0.69 - first bugfix 2.1.0+1.0.70 - new vulkan version 2.1.1+1.0.70 - first bugfix ...And so on. Also, if you'll stick to your *bad-in-every-way* plan, you *can't* publish erupted-v2 as erupted package on dub registry. You'd have to remove it from registry first, which will break every single package that depends on it. Thanks for your nice words all over the place, sun is rising in my hart :-). Well, yeah, I didn't. ErupteD-V2 is published as erupted_v2, and Erupted-V1 as erupted_v1. Hey, I have another awesome idea, you are an the safe side, you just change your dependency to erupted_v1. I hope this is not too much of effort on your side? Sorry for inconvenience. Ah, but wait! Fear not, I read ahead and have a solution for your way of using erupted, just read on. I already use erupted-v1. Deprecation messages annoy me. 2. Great! I ended up adding erupted as a git submodule just so Wouldn't it be possible for you to switch your submodule to ErupteD-V1 then? I mean, that's the reason for repo "mess" and gradual transition. I can remove all of the unnecessary dependencies (erupted uses pretty old derelict-util which makes it impossible to use both erupted and last version of derelict-glfw). Ah, but that was one of the two reason for the breaking change. Btw. I am/was using diferent versioned derelict-utils and have no problems other than being informed that xcb-d (on windows!) does not use it. What is the "impossible" part you have to face? Erupted uses derelict-util 2.something.something and derelict-glfw uses 3.0.0-beta. Because of that dub warns about version mismatch every single time I build my program. Well, that's not impossible to use, but pretty annoying. Erupted-V2 doesn't work for me - when compiling on Linux it fails on some Windows-specific code. I'll open an issue as soon as I get home. I am really sorry for that, I have an idea what might be wrong. Please, if you don't min, post an issue with the error. I hope that in this alpha stage of ErupteD-V2, where some poo poo was expected to hit the fan, it would be ok to move the semvers. Actually, if you use ErupteD as a submodule, why do care about semvers at all? Because dub
Re: Vulkan ErupteD breaking changes and transition strategy
On Monday, 26 March 2018 at 07:51:31 UTC, Seb wrote: On Monday, 26 March 2018 at 07:04:00 UTC, Anton Fediushin wrote: This is a *bad* idea and you shouldn't do that. Just increase MAJOR version and start from there: 2.0.0 - Changing how binding works, Vulkan v1.0.69 2.1.0 - Vulkan 1.0.70 ...And so on. This way semver is followed and you don't have to mess with erupted-v1 and erupted-v2 repos. Also note that SemVer allows to attach meta data: 2.0.0+1.0.69 That'll work too, but I'm not sure how dub handles it. Anyway, even a little note in release description "Vulkan API vX.X.X" should be enough.
Re: Vulkan ErupteD breaking changes and transition strategy
On Sunday, 25 March 2018 at 22:23:06 UTC, Peter Particle wrote: ErupteD [0] is deprecated (one of its major modules). The project content is supposed to be replaced completely. Current state was copied into ErupteD-V1 [1] (without deprecation message), neither ErupteD nor ErupteD-V1 will be further developed. The breaking changes and Vulkan 1.1 are implemented in ErupteD-V2 [2]. At some future point ErupteD will be destroyed and recreated with all releases of ErupteD-V2 [3]. Two issues bugged me with the previous design of the binding: 1. versions are not only disconnected from, but also far beyond Vulkan 2. too many dub dependencies - if on windows, than platform foreign ones 1. this is the reason for the involved transition, ErupteD needs to get rid of all releases / version tags to restart with a clean slate. I also extracted the python generator script into its own non-dub project, V-Erupt [5]. It was kind of wired to mix two different purposes into one project version scheme. 2. the new approach does not require dependencies at all (other than phobos / druntime). Platform dependent extensions are implemented in form of a parameterizable mixin template. User is supposed to mix them into his project and take care of the dependencies himself [4]. Platform windows is pre-instantiated, as it relies only on druntime. With this approach dub cache stays clean from foreign platform dependencies and silences version mismatch noise. While at it, I also removed the DerelictUtil dependency and added simple entrypoint loading mechanics. ErupteD-V2 is now fully nothrow @nogc and should be -betterC compatible (not tested yet). Moreover, no requirement for dub configurations any more. [0] : https://github.com/ParticlePeter/ErupteD [1] : https://github.com/ParticlePeter/ErupteD-V1 [2] : https://github.com/ParticlePeter/ErupteD-V2 [3] : https://github.com/ParticlePeter/ErupteD-V2#erupted-deprecation-and-upgrade-process [4] : https://github.com/ParticlePeter/ErupteD-V2#platform-extensions [5] : https://github.com/ParticlePeter/V-Erupt 1. This breaks semver. You shouldn't just use Vulkan's versions. If you release 1.0.69 which contains bindings to Vulkan 1.0.69 and there is a bug in the binding which you want to fix, you have to increase PATCH number which results in 1.0.70 which (obviously) is not a binding to Vulkan 1.0.70. Even though you can use PRE-RELEASE part of semver to show users that this is a bugfix release (ie. 1.0.69-bugfix.1) this shouldn't be used because it breaks semver *again* and dub (which follows semver) isn't going to tolerate that. This is a *bad* idea and you shouldn't do that. Just increase MAJOR version and start from there: 2.0.0 - Changing how binding works, Vulkan v1.0.69 2.1.0 - Vulkan 1.0.70 ...And so on. This way semver is followed and you don't have to mess with erupted-v1 and erupted-v2 repos. Also, if you'll stick to your *bad-in-every-way* plan, you *can't* publish erupted-v2 as erupted package on dub registry. You'd have to remove it from registry first, which will break every single package that depends on it. 2. Great! I ended up adding erupted as a git submodule just so I can remove all of the unnecessary dependencies (erupted uses pretty old derelict-util which makes it impossible to use both erupted and last version of derelict-glfw). Erupted-V2 doesn't work for me - when compiling on Linux it fails on some Windows-specific code. I'll open an issue as soon as I get home.
Re: Why think unit tests should be in their own source code hierarchy instead of side-by-side
On Thursday, 22 March 2018 at 17:15:55 UTC, Anton Fediushin wrote: So? Am I wrong about dub? Let me investigate I'm not wrong! It works as expected: only package you are working with compiles with `-unittest` option. Test repo: https://github.com/ohdatboi/dub-please-be-as-cool-as-i-think-you-are Cd to `app` directory and run: --- $ dub Performing "debug" build using /usr/bin/dmd for x86_64. lib1 ~master: building configuration "library"... lib1: Compiled without -unittest option app ~master: building configuration "application"... app: Compiled without -unittest option Linking... Running ./app --- --- $ dub -b unittest Performing "unittest" build using /usr/bin/dmd for x86_64. lib1 ~master: building configuration "library"... lib1: Compiled without -unittest option app ~master: building configuration "application"... app: Compiled with -unittest option Linking... Running ./app --- Oh heck yeah! I think that dub is only one of the D tools which never disappoints me.
Re: Why think unit tests should be in their own source code hierarchy instead of side-by-side
On Thursday, 22 March 2018 at 17:08:18 UTC, Jonathan M Davis
wrote:
I could be wrong, but I am _quite_ sure that dub builds all
dependencies with their test targets when you build your
project with its test target.
I thought so too, but I just checked and it doesn't do that. I'd
better create a test repository for that, maybe I'm doing
something wrong.
I had to add this to dub.json
"buildTypes":
{
"doTests":
{
"buildOptions": ["unittests", "debugMode",
"debugInfo"],
"versions": ["dxmlTests"]
},
"doCov":
{
"buildOptions": ["unittests", "debugMode",
"debugInfo",
"coverage"],
"versions": ["dxmlTests"]
}
}
Well, that's just ugly. And that `versions` thing looks exactly
like the one from Atila's article.
So? Am I wrong about dub? Let me investigate
Re: Why think unit tests should be in their own source code hierarchy instead of side-by-side
On Thursday, 22 March 2018 at 13:58:50 UTC, Atila Neves wrote: On Thursday, 22 March 2018 at 12:26:14 UTC, Anton Fediushin Tests in their own file is something from 90-s. It's 2018 and I want to be able to write tests anywhere I want. You _can_ write them wherever you want. I'm not arguing for taking any flexibility away, I'm arguing that for most projects it's a bad idea, and I stated the reasons why I think that's the case. Feel free to disagree. Since your article is wrong about dub's way of handling `unittest` configuration (take a look at my last post), the only valid point is "they increase build times". The only choice you have to make is: you take the red pill and choose convenience over compilation speed or you take the blue pill for speed over the convenience. None of the choices is "good" or "bad". They're just slightly different. "They increase build times" - fix compiler, not my code. If by "fix the compiler" you mean "make it so that the compiler knows exactly what files need to be recompiled if I only edited the body of a unittest block" (which is what would be needed), then I don't think that'll happen any time soon. But sure, if the compiler worked that way I'd happily advocate for writing unittests in the same file. But for now, I'd rather spend a lot less time staring at the screen for 2s waiting for my code to be built. That's my trade-off, and reasonable people may (and apparently quite obviously do) disagree. I'm not a compiler developer, so I don't mean anything in particular. Just saying. I didn't knew that change in unittest block causes rebuilding of many modules, so that's good to know. "version(unittest) will cause you problems if you write libraries" - fix dub, not my code. This is _not_ a dub issue. version(unittest) _will_ bite you as soon as you compile foo.d with -unittest because its imports will be parsed differently. This is one to stick in the "fix the compiler" column. See the link to the since-reverted Phobos PR in the blog. Yeah, I was wrong about dub. I'm so sorry since it turned out that dub handles `dub test` in the way that never causes problems with `version(unittest)`. What about `version(unittest)` itself - as any of the conditional compilation features it should be handled with care. Especially when we are talking about cases where dub isn't used.
Re: Why think unit tests should be in their own source code hierarchy instead of side-by-side
On Thursday, 22 March 2018 at 10:59:56 UTC, Atila Neves wrote: Blog post: https://atilanevesoncode.wordpress.com/ Atila I *love* built-in unittests. Putting them right after each function makes things so much easier. Tests in their own file is something from 90-s. It's 2018 and I want to be able to write tests anywhere I want. "They increase build times" - fix compiler, not my code. "version(unittest) will cause you problems if you write libraries" - fix dub, not my code. Built-in unittests are part of D's specification. As long as it allowes to do so, I'll carry on writing unittests in my code and nobody can take it from me.
Re: Ecoji-d v1.0.0 is released - Base1024 using emojis
On Sunday, 18 March 2018 at 11:25:45 UTC, Cym13 wrote: So I think ecoji-d just truncates its input at some point. Indeed, there's an error somewhere. For some reason it stops after 7457792 bytes. I'll create an issue for that and will look into this later
Re: Ecoji-d v1.0.0 is released - Base1024 using emojis
On Friday, 16 March 2018 at 08:25:30 UTC, bauss wrote: Besides your encoding isn't going to work with actual web-pages anyway, because your encoder doesn't have browser support. Well, encoding is not *mine*, only D implementation is. What do you mean by "browser support"? Indeed, ecoji-d cannot be used on the client side, but since algorithm is simple and code is publically available anyone can implement decoding in JavaScript or any other language. Sure you can encode your data and gzip it, but once it reaches the browser and it unzips it, then what? The browser doesn't know what to do with the data. You can't even use base64 for http headers. Then you use client-side decoder, of course!
Re: Ecoji-d v1.0.0 is released - Base1024 using emojis
On Thursday, 15 March 2018 at 09:32:50 UTC, bauss wrote: Fun, but seems pretty useless in practice. I disagree. Ecoji (base1024) has bigger character set meaning that it can encode more information per emoji than base64 can encode per character. For example ecoji encoded "abcde" looks like this: "" And base64 encoded one looks like this: "YWJjZGU=". Even though each emoji is 4 bytes long, there is a noticable difference in size when we are talking about larger chunks of data: --- $ dd if=/dev/urandom bs=4K count=16K of=test.raw 16384+0 records in 16384+0 records out 67108864 bytes (67 MB, 64 MiB) copied, 1.90423 s, 35.2 MB/s $ dd if=test.raw | ./ecoji-d | wc -c 67108864 bytes (67 MB, 64 MiB) copied, 6.7699 s, 9.9 MB/s 71591534 # Size increased just by 6% $ dd if=test.raw | base64 | wc -c 67108864 bytes (67 MB, 64 MiB) copied, 0.750174 s, 89.5 MB/s 90655837 # 35%(!) increase in size --- And if we move to real word scenarios, where web pages are gzip'ped most of the time: --- $ dd if=test.raw | gzip -c | wc -c 67108864 bytes (67 MB, 64 MiB) copied, 5.49022 s, 12.2 MB/s 67119122 # Raw files are terrible for compression $ dd if=test.raw | ./ecoji-d | gzip -c | wc -c 67108864 bytes (67 MB, 64 MiB) copied, 27.9972 s, 2.4 MB/s 32178275 # 48% improvement $ dd if=test.raw | base64 | gzip -c | wc -c 67108864 bytes (67 MB, 64 MiB) copied, 10.3381 s, 6.5 MB/s 68892893 # Pretty bad, yeah --- So yeah, ecoji is better than base64 in everything but speed. Speed will be improved. Later.
Ecoji-d v1.0.0 is released - Base1024 using emojis
, I'm glad to announce that ecoji-d - pure D implementation of ecoji encoding version 1️⃣.0️⃣.0️⃣ is finally released❗ What is ecoji? Ecoji encodes data as base1024 with an emoji character set. It can be used instead of boring and old base64 冷冷冷. Encoding example: --- $ echo "Base64 is so 1999, isn't there something better?" | ecoji-d 論撚若 --- And decoding: --- $ echo -n "論撚若" | ecoji-d -d Base64 is so 1999, isn't there something better? --- Ecoji-d's features: ✔️ Range interface ✔️ Lazy encoding/decoding ✔️ Low memory usage ✔️ @safe and pure when possible ✔️ Many tests ✔️ Can be used as a library and as a CLI utility API consists of just 2️⃣ functions: `encode`, which does encoding `decode`, which does decoding Links: DUB package page: http://code.dlang.org/packages/ecoji-d GitHub repository: https://github.com/ohdatboi/ecoji-d 蘭 GitHub repository of the reference Go implementation: https://github.com/keith-turner/ecoji
Re: Unit Testing in Action
On Friday, 20 October 2017 at 14:04:25 UTC, Mike Parker wrote: After a couple of weeks of quiet on the D blog, it's about to get noisy again. The latest is is a post by Mario Kröplin of Funkwerk describing how the company now uses D's built-in tests in their codebase after several years of using third-party frameworks. Blog: https://dlang.org/blog/2017/10/20/unit-testing-in-action/ Reddit: https://www.reddit.com/r/programming/comments/77m8r8/ds_builtin_unit_testing_in_action/ Yay! My app - covered is in this post! That's so cool, when somebody uses your code. Thank you, Mario.
Re: goinsu - Switch user, group and execute a program - a tiny betterC program
On Wednesday, 27 September 2017 at 12:49:16 UTC, jamonahn wrote: On Saturday, 16 September 2017 at 19:56:14 UTC, Anton Fediushin wrote: Hey-hey-hey, I am so excited to announce a brand-new program I just wrote: goinsu! Just built on my Raspberry Pi 3. Kudos - very fast, not even a warning! Now to get some Docker images and go crazy. Hooray! BTW, I got a 14,116 byte executable image with LDC but 1,958,892 with GDC. The GDC image (stripped) is 324,492. I installed reggae on my laptop (debian) and did a "reggae --export". Then using make (with ldc2) I got image of 13,088. Using "dub -b release --compiler=ldc2" (same build as on Raspbian) I get image of 381,928. Reggae builds goinsu in betterC mode, which removes dependency on the druntime and phobos. Dub can also build betterC programs, but I decided not to add such flag to dub.json, because betterC is a new thing which can cause problems. LDC and GDC could have very limited betterC support, so results may vary. How do I do a static linkage using LDC? I need a static because I want to try and run this with an Alpine (arm) Docker image and Alpine is using muslib-c. I once built an Alpine Docker image by hand that built ldc, but it couldn't survive D version/Alpine Os updates. You don't have to compile LDC for this. It is possible to compile a static musl and link it together with the goinsu. Take a look at `.travis.yml`, since this is exactly what I am doing to build releases. Also, do not forget the `errnofix.c`, which is important for static linking. Reggae does this automatically, you just have to specify static libc you want to link to. Maybe it won't work for RPi though. I've ordered Raspberry Pi recently, so as soon as I get it I can start hacking on it as well) Thank you so much for this tool! You're welcome!
Re: Trial v0.4.0 and visual-trial v0.1.0 are out
On Monday, 18 September 2017 at 20:50:55 UTC, Szabo Bogdan wrote: Hi! I want to announce that I managed to release a new version of Trial, the DLang test runner. Great news, it works just fine now!
goinsu - Switch user, group and execute a program - a tiny betterC program
Hey-hey-hey, I am so excited to announce a brand-new program I just wrote: goinsu! goinsu works like a classic `su` or `sudo`, but meant to be used inside the Docker containers, when you just need to run a program as a specified user. goinsu is a workaround for TTY and signal issues of `su` and `sudo`. It has been written as an example of betterC usage. Check out project on the DUB registry: http://code.dlang.org/packages/goinsu Ask questions in this topic or create an issue on GitHub: https://github.com/ohdatboi/goinsu Make sure to check out reggae, an awesome build tool which is used to build goinsu in betterC mode: https://github.com/atilaneves/reggae
Re: I'm the new package maintainer for D on ArchLinux
On Wednesday, 9 August 2017 at 20:42:48 UTC, Wild wrote: Hi everyone, The D packages for ArchLinux has been orphaned since Dicebot stepped down as the maintainer and no one else stepped up. So I decided to step up and apply to become a Trusted User, and I got accepted yesterday[1]. So from now on I will be the one who maintains all the D packages (in the [community] repo), and it will be my job to fix them if they break. Thank you!
Re: covered - processes output of code coverage analysis performed by the D programming language compiler
On Tuesday, 1 August 2017 at 20:37:16 UTC, Anton Fediushin wrote: Thanks! Yes, module "covered.loader" can be used, but it isn't complete yet. I'll start working on v1.0.0 tomorrow, changing current design (get as much information as possible and store it) to a new one (get only required information). This will increase speed and decrease memory usage. v1.0.0-alpha.1 is released. I'll release v1.0.0 as soon as I add some documentation, but I won't change API again, so it is ready to be used as a library. Also, I've done some benchmarks: https://github.com/ohdatboi/covered/releases/tag/v1.0.0-alpha.1
Re: covered - processes output of code coverage analysis performed by the D programming language compiler
On Tuesday, 1 August 2017 at 08:19:47 UTC, Szabo Bogdan wrote: Nice work! I would like to contribute to such a tool :) I was working at something similar with trial( http://trial.szabobogdan.com/ ), and I would like to include your library if it's possible. Thanks! Yes, module "covered.loader" can be used, but it isn't complete yet. I'll start working on v1.0.0 tomorrow, changing current design (get as much information as possible and store it) to a new one (get only required information). This will increase speed and decrease memory usage. this is a sample code coverage report: http://trial.szabobogdan.com/artifacts/coverage/html/index.html Nice! I'm using unit-threaded, but trial looks even better. I'll try it tomorrow.
covered - processes output of code coverage analysis performed by the D programming language compiler
Hello! I am glad to announce a new command-line tool which should make development a little easier. Program, compiled with `-cov` switch, generates *.lst files. They contain program source, number of executions of each line and total code coverage of the file. Those files are quite useful for small programs/libraries, but not that useful for big ones. Covered processes *.lst files, and reports only useful information. Behaviour can be changed with command-line options: '--coverage' reports code coverage in % for each file. '--blame' shows list of files ordered by code coverage. '--average' reports average code coverage for files. Covered works for lists of files and directories, so '--blame' can be used to find less covered files, and '--average' to compute average code coverage of the project. More documentation is available on project page on GitHub: https://github.com/ohdatboi/covered It is also added to DUB package registry: http://code.dlang.org/packages/covered Also, I am looking for huge projects, so I can test covered on them. Reply here or start an issue on GitHub if you know one.
Re: derelict-git2: A dynamic binding to libgit2 library
On Sunday, 18 June 2017 at 15:47:44 UTC, Sönke Ludwig wrote: But the thing with libgit2 is that it is extremely annoying how quickly they break the API, especially since many different versions have to be supported at the same time as long as using the system packaged version is supposed to be possible. Yes, v0.26.0RC2 is already released and it introduces breaking changes. I'll just release next major version. If they don't care about backwards compatibility, why should I care? Also, it's dynamic binding, so it doesn't require libgit2 during compilation and it throws exception, if there is an error at run time. I can try to add derelict-git2 backend to dlibgit, so it can use both static and dynamic binding, but I don't know if this is a good idea. In this case I have to care about both static and dynamic bindings, which is a humongous amount of work. I also can fork dlibgit and use just dynamic binding.
derelict-git2: A dynamic binding to libgit2 library
I am happy to announce the derelict-git2. derelict-git2 is a dynamic binding to libgit2 v0.25.1 (latest stable release) for the D programming language. I created it because existing binding[1] is dead as well as high-level wrapper[2]. Dynamic bindings are much easier to use, although they are more complex in development. Also, I could help if somebody wants to create a wrapper on top of derelict-git2. Check out project page on dub: http://derelict-git2.dub.pm And create an issue on GitHub: https://github.com/ohdatboi/derelict-git2 [1] http://code.dlang.org/packages/libgit2 [2] http://code.dlang.org/packages/dlibgit
profdump - Converts your 'trace.log' files into dot graphs
profdump parses 'trace.log' (output of default profiler) and converts it to: - Plain text - More readable and user-friendly than raw trace.log - JSON - Can be used if you wanna process it with your scripts - DOT Graph - Nice and colourful graphs You can customize output: --threshold - If time spent on the function is below this threshold, it will be hidden. Takes seconds --pretty - outputs formatted JSON (default: true) --colour - sets colours of nodes. takes string[float] For example: dub run profdump -- --colour=0=gray --colour=50=red --dot trace.log graph.dot Will create 'graph.dot': Functions which takes < 50% of time will be gray Functions which takes >= 50% of time will be red Also, you should use 'dot' tool from graphviz to generate image (because .dot files just contains graph description) Check out profdump at DUB: http://code.dlang.org/packages/profdump And start an issue at GitHub: https://github.com/ohdatboi/profdump Issues: - Functions with long names (like phobos' ones) will take a lot of space on the graph. - profdump doesn't check input trace.log file. If it fails, try to delete your trace.log and generate new one. - Dunno what to do about profilers of other compilers (LDC and GDC). Is format same as in DMD? Let me know.
