Re: How to unit-test a phobos module?
On Thursday, 26 November 2020 at 05:29:16 UTC, Mike Parker wrote: On Wednesday, 25 November 2020 at 21:36:36 UTC, Q. Schroll wrote: [1] https://wiki.dlang.org/Building_under_Windows You might try Digger. That will hide all the tedious bits. https://code.dlang.org/packages/digger I think using digger in principle works and I assume the problems I got aren't Digger's fault, but ae's. Building DMD + DRuntime failed. In my working folder (created by DUB running Digger), there's DMD.exe, but trying compiling anything results in "Error: cannot find source code for runtime library file 'object.d'" I did nothing but follow the instructions on code.dlang.org/packages/digger : dub fetch digger dub run digger -- build I tried building the current version v2.94.2 and tried --model=64, nothing helped. The error I'm presented is when work\build\bin\dmd.exe -lib -ofphobos64.lib -Xfphobos.json -conf= -m64 [..1] -I../druntime\import std\stdio.d [..2] is executed. [..1] IMO unrelated options [..2] following many more std modules, probably all that there are (haven't checked) The error message is: std\stdio.d(16): Error: module stddef is in file 'core\stdc\stddef.d' which cannot be read I have no idea why the import failed. The stdc subfolder isn't in the core folder, but that core folder isn't even in a druntime/import folder anyway. Something's going horribly wrong. It seems something beyond us just doesn't want me to get D stuff done. :( Tomorrow, I'll try setting up a dual boot and give it a shot there. (Not the dub experience but following https://wiki.dlang.org/Building_under_Posix) Thank you all for your answers.
Re: Ways to parse D code.
On 2020-11-25 17:27, Jan Hönig wrote: dmd has to do it somewhere as well. Although I don't know exactly where. I do know ldc uses dmd's frontend for parsing. https://dlang.org/phobos/dmd_parse.html Using DMD as a library will be most accurate and up to date. Because it's the same code as the compiler is using. Here's an example on how to use DMD to parse some code [1]. Here's some more advance usages [2]. [1] https://github.com/dlang/dmd/blob/b35572b07a6994385b6459a430674d32e9a97279/test/dub_package/frontend.d#L10-L24 [2] https://github.com/jacob-carlborg/dlp/blob/master/source/dlp/commands/infer_attributes.d#L61 -- /Jacob Carlborg
Re: Simulating computed goto
On Thursday, 26 November 2020 at 04:42:08 UTC, Dukc wrote: On Wednesday, 25 November 2020 at 18:44:52 UTC, NonNull wrote: Is there a good way to simulate computed goto in D? I haven't used assembly myself, but it's possible that you can define a mixin that does this, using inline assembly. Interesting idea!
Re: Simulating computed goto
On Wednesday, 25 November 2020 at 18:57:35 UTC, Paul Backus wrote: On Wednesday, 25 November 2020 at 18:44:52 UTC, NonNull wrote: How good is optimization in ldc2, gdc, dmd at compiling chained jumps into one jump each time? The easiest way to find the answer to a question like this is to use the compiler explorer: https://d.godbolt.org/ Very good tool! Thanks.
Re: Automatic update system
On Thursday, 26 November 2020 at 12:13:59 UTC, vnr wrote: Hello, I have a program written in D which is open-source on GitHub. I would appreciate it if, when I release a new version, users would be notified by the program and that it offers an automatic update, i.e. the user doesn't have to reinstall the whole repository himself, but that it is updated automatically. I haven't found any packages that directly meet my needs, but in the meantime I imagine that I will have to use the GitHub API, as well as Curl to make such a system. Do you have any resources or suggestions as to how I could implement this? Thank you! This sounds like you and your users want to use dependabot. It is free service of github. Unfortunately someone needs to add support for Dub (ruby coding). Maybe also a good candidate for GSOC21. Kind regards Andre
Re: Automatic update system
On Thursday, 26 November 2020 at 12:13:59 UTC, vnr wrote: Hello, I have a program written in D which is open-source on GitHub. I would appreciate it if, when I release a new version, users would be notified by the program and that it offers an automatic update, i.e. the user doesn't have to reinstall the whole repository himself, but that it is updated automatically. I haven't found any packages that directly meet my needs, but in the meantime I imagine that I will have to use the GitHub API, as well as Curl to make such a system. Do you have any resources or suggestions as to how I could implement this? Thank you! Make it a DUB package. It does not update 100% automatically, but notifies when updates are available. You could also make an auto-updater by hand, but that requires a networking library and won't work anyway if the user does not have permissions to change the executable. This is often the case, as the often recommended places to store the programs are `/usr/bin/` or `c:/program files/`. Neither is accessible by default priviledges. In addition, it is a lot more work to implement than making a dub package. I don't recomment absent a strong reason. If you publish your program in some other package format (apt, rpm, flatpak or nix for example), you can try to get your package into some official repository. There you can publish updates easily, and the program gets updated among the regular software updates the users do.
Re: How to unit-test a phobos module?
On 11/25/20 7:17 PM, Q. Schroll wrote: On Wednesday, 25 November 2020 at 21:57:12 UTC, H. S. Teoh wrote: On Wed, Nov 25, 2020 at 09:49:12PM +, Paul Backus via Digitalmars-d-learn wrote: On Wednesday, 25 November 2020 at 21:16:06 UTC, Q. Schroll wrote: > On Wednesday, 25 November 2020 at 21:11:24 UTC, Paul Backus > wrote: > > On Wednesday, 25 November 2020 at 20:58:20 UTC, Q. Schroll > > wrote: > > > My setup: > > > * A fresh DMD installed a few minutes ago. > > > * Clone of my Phobos fork with up-to-date changes from > > > dlang/phobos/master. > > > > Do you have clones of dmd and druntime too? > > Why would I need those? I haven't needed them back then. copyEmplace isn't in druntime 2.094.2. My guess is that the problem is caused by trying to compile Phobos with a compiler that uses an incompatible version of druntime. One of the issues is, I don't know what DRuntime really is. As far as I understand on the surface-level, it's functionality one would expect to be implemented by the compiler, but actually implemented in plain D code. A low-level Phobos if you want. So I'm a little confused why there's even a need for it to be "built". Isn't it "just code" like Phobos? Druntime is in many respects the library portion of the language. It's the glue that allows some language pieces to work (e.g. Object, associative arrays, TypeInfo, etc.). There are also pieces that are purely independent of the compiler. But it used to be that just Phobos existed, and no Druntime. Druntime is actually the runtime portion of Tango, factored out so that both Phobos and Tango could use the same underlying runtime. It used to be, if you wanted to use a Tango-based library, you couldn't use a Phobos-based one as well. At this point, it's a nice separation of the Language features that must be library implemented from the user library (Phobos). I'm increasingly frustrated because, honestly, it seems I don't know enough about the build processes or build tools used. The Wiki expects Digital Mars make to be there, also says explicitly not to confuse it with GNU make, but in my DMD folder there is none. Since it's a plain install, I suspect the Wiki is outdated. How am I expected to figure things out? It seems like everyone else knows how to do it, just I'm too stupid. Like any projects that are built over decades, Phobos and Druntime have accumulated esoteric build systems, and things you just "have to know". I honestly can't help you with your troubles, because I only ever use Windows when I have to. But I'm sure there are ways to get done what you want to get done. This might involve wrestling with the build system, or figuring out the correct command line based on the build system. -Steve
Re: Simulating computed goto
On Wednesday, 25 November 2020 at 20:05:28 UTC, NonNull wrote: So to simulate computed goto have to 1. wrap switch(x) in a loop [ while(0) ] 2. inside each case recompute x (instead of jump to computed y) 3. jump back to execute switch again [ continue ] It does look as if a nested switch can contain case labels from an outer switch which is very good. Did not try this out. Any more ideas, advice? I quess you could define a string or a template mixin to automate this, if there are many functions doing this. Then again, you probably should NOT have many functions working this way -it is not at all a scalable way to program. It might be good for something that is called very often and thus needs to be fast, but not for regular code. Computed `goto`s are even worse in maintainability than normal `goto`s.
Automatic update system
Hello, I have a program written in D which is open-source on GitHub. I would appreciate it if, when I release a new version, users would be notified by the program and that it offers an automatic update, i.e. the user doesn't have to reinstall the whole repository himself, but that it is updated automatically. I haven't found any packages that directly meet my needs, but in the meantime I imagine that I will have to use the GitHub API, as well as Curl to make such a system. Do you have any resources or suggestions as to how I could implement this? Thank you!
