Profdump with --blame in Text Mode Results in RangeViolation

[vnayar]

Running the command dub run profdump -- --blame trace.log profdump2.txt results in a RangeError which prevents the flag from being used.

Running ../../../../.dub/packages/profdump-0.4.3/profdump/profdump --blame trace.log profdump2.txt
core.exception.RangeError@../../../.dub/packages/profdump-0.4.3/profdump/source/app.d(134): Range violation
----------------
??:? _d_arrayboundsp [0x555bf4a9b30d]
../../../.dub/packages/profdump-0.4.3/profdump/source/app.d:134 _Dmain [0x555bf49ee8f7]
Program exited with code 1

The trace.log file used in this test was produced from DMD with build flags "-release -profile" and is provided as: trace.log

[AntonMeep]

Thank you for your report, Unfortunately I am not programming in D anymore and cannot provide necessary support for my tools as I am not using them anymore myself. With this said, I am glad to know that people are still using my tools and am encouraging anyone to fork the project and modify it as they see fit. I would also be happy to transfer DUB package pages to new committed authors of these forks.

Opening new issues is also highly encouraged as it will prepare a good starting point for forked projects.

[vnayar]

@AntonMeep Oh, if you don't mind me asking, what language are you programming in now and what was the primary driver behind no longer using D?

[AntonMeep]

@vnayar I moved over to Ada for personal projects and Kotlin for more professional kind of things. Main reason I switched over from using D language was my realization of the fact that by giving up real safety and performance (Ada), lots of great libraries and extremely rapid development (Kotlin) I was hardly getting anything in return.

Also, I felt like development of D went in the opposite direction to where I wanted it to go. For example, writing unit-tests in D was always great with the language-defined unittest blocks, but running them always sucked - you either had to rely on included runner or deeply integrate one of the third-party solutions into your project. Because of that one evening I wrote silly, a very deliberate meta-programming hack to make running tests easy and informative, and to this day whenever I open DUB I see it being the no. 1 package there. For over three years nothing has changed and people are still turning to my very hacky solution that was always meant as a temporary fix.

Do not get me wrong of course, I still believe that D is an extremely interesting language, from academic point of view, and it is put together absolutely brilliantly. However, supporting infrastructure always seemed lacking and because of this I can hardly recommend D in the current landscape of programming languages.

Compared to that, Ada has even worse infrastructure - they got an official package manager only last year, but the language itself is a joy to write programs in, it is the good kind of sophisticated, and I hardly need to worry about bugs or problems with organization of my code as the codebase grows. Kotlin on the other hand is a hot mess but magnificent tooling included in the IDE lets me build prototype applications in the matter of days and get things done quick.

Hopefully this explains my decision, I am just not willing to put up with shortcomings of something for no benefit, when better alternatives are available. I really hope my little rant doesn't push you away from D however, it is still an incredible language, and the best implementation of metaprogramming I've ever seen.

[vnayar]

@AntonMeep Very understandable, especially the argument about the availability of a wide selection of libraries. You are also right about there being a lack of well developed development tools and essential libraries for many domains.

For me, I happen to be working on problems that aim for high performance, not for the sake of making something that is bleeding-edge fast, but for the sake of solving known problems with less hardware and at lower cost, thus paying a price for performance is something that benefits me. Another advantage of D is that, due to its similarity in syntax to other languages like Java, C++, and Python, it is significantly easier to port over libraries from those languages when they are needed. The effort becomes largely mechanical, and one does not even have to be an expert in the particular domain the library is for.

But as you stated, a major downside is that you frequently encounter situations where there is nobody else who has ported a library into D, and thus you have to do it yourself, which is a major commitment of time and effort.