Re: Garbage Collectors
On 7/19/23 10:46 AM, Johan wrote: On Wednesday, 19 July 2023 at 11:27:14 UTC, Richard (Rikki) Andrew Cattermole wrote: [...] you would have to do a new build of druntime/phobos special which isn't the easiest thing to do. Side remark: LDC ships with the ldc-build-runtime tool which should help the user a lot in building druntime/phobos. (downloads the correct source belonging to the specific compiler version, and then builds the libraries with user-specified flags, compilers, etc.) This is very cool to know, I wasn't aware! -Steve
Re: array index out of bound may not throw exception?
On Friday, 21 July 2023 at 23:40:44 UTC, mw wrote: Is there a way to let it report on the spot when it happens? The best way is to wrap your thread's main function in a try-catch block and just print whatever error/exception is caught.
Re: Recommendation on plotting library
On Thursday, 20 July 2023 at 02:37:54 UTC, Chris Piker wrote: Hi D One of my jobs is to release and maintain public data archives from long-running scientific instruments. In order to help people understand how to process the data, sample code is often included with the archive. Recently this has been in the form of short programs that generate a plot of a representative time period. Python works well for this task as matplotlib support is pretty much universal. Matlab is also a reasonable choice for many. [...] https://forum.dlang.org/post/mgxcrmjcgasbdaipd...@forum.dlang.org
Re: Recommendation on plotting library
Thanks for the both of the long replies. I've ready them twice and will do so again. To focus in on one aspect of D package support: On Saturday, 22 July 2023 at 02:24:08 UTC, Greggor wrote: In general whenever possible I think its better for everyone that stuff is built from source. It ensures that builds can be re-produced by anyone and that issues with building are caught fast by anyone consuming the library. I agree 100%. I've run into similar python package hell dealing with Tensor flow on Rocky Linux 8, since it wasn't Ubuntu. The problem is we're small, and many dependencies are already written in C, and dub is not setup to handle C dependencies. If I could turn my legacy C projects (pre-processor macros and all) into dub projects I'd do so as fast as possible. If dub supported two things: 1. Building C projects 2. Installing the resulting binaries in "site-packages" or similar. many, many project kickstart issues would be solved. Like C++, D is designed as a successor to C. It would be nice to bring C into the party with full dub support.
