The tools DCD 0.11.1, D-Scanner 0.7.1 and dfmt 0.10.0 are released
DCD[1], D-Scanner[2] and dfmt [3] got updated today. You're invited to update them or wait that the plugin of your editor get a new release. See the links for changelog and binaries. Note that DCD, when build with DMD 2.085.0 will likely crash a lot due to a bug in DMD backend. I've managed to fix it earlier this month unfortunately we're still waiting for 2.085.1 to be released. If you want to say thanks, here is a link [4] for financial support of contributors of this releases (only). [1] https://github.com/dlang-community/DCD/releases/tag/v0.11.1 [2] https://github.com/dlang-community/D-Scanner/releases/tag/v0.7.1 [3] https://github.com/dlang-community/dfmt/releases/tag/v0.10.0 [4] https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=AQDJVC39PJF7J Have fun Baz.
Re: The tools DCD 0.11.1, D-Scanner 0.7.1 and dfmt 0.10.0 are released
On Monday, 1 April 2019 at 07:22:52 UTC, Basile B. wrote: Note that DCD, when build with DMD 2.085.0 will likely crash a lot due to a bug in DMD backend Sorry this was inexact, DMD 2.085 + DUB. The versions build with make or the bat script work.
Re: GDB + ddemangle
On Friday, 26 April 2019 at 07:08:45 UTC, Arun Chandrasekaran wrote: On Friday, 20 April 2018 at 17:55:12 UTC, Iain Buclaw wrote: On 20 April 2018 at 17:40, drug via Digitalmars-d-announce wrote: 20.04.2018 16:49, Iain Buclaw пишет: [...] it works, thank you. But not in all cases. For example when gdb stops on breakpoint it demangle, but if I do `bt` - backtrace isn't demangled. Using a compiler that implements 2.077 or later (IIRC) probably won't, due to gdb being too old. They broke ABI by introducing back referencing, no release of gdb supports that yet. This stays broken after 1 year. How do we fix this? I recognize your name from IRC, where you posted a related question yesterday. The person in charge for D in GDB had answered: The problem is that the mangling scheme has changed (to produce shorter mangles). Demangling will be eventually supported when D will be in GCC for good (GCC 10) and then he would port the demangling from GCC to GDB. So for now demangling of D in GDB only work if the binary is compiled with a very old version of the compiler, i.e prior to the new mangling method.
Re: libfirm-d - D bindings of Firm, a compiler IR based on the SSA form
On Sunday, 1 July 2018 at 12:04:06 UTC, Basile B. wrote: I've recently ported libfirm to D. This nice C library, developed at the Karlsruhe university, allows to build compiler back-ends, using the SSA intermediate representation. In theory it could even be used to make a new D compiler version, e.g "FDC", although this is obviously of no interest ;) So this is mostly to make JIT scripting engines or back-ends for toy languages... See: - https://github.com/BBasile/libfirm-d - https://code.dlang.org/packages/firm-d - https://pp.ipd.kit.edu/firm/ Note that unfortunately this library is LGPL2 licensed, so much less usable than LLVM-d, which is a similar but a more mainstream library. With the recent release of dstep 1.0.0 I've managed to make a new minor release that only auto generate the sources (v0.1.0). It was obviously not a good idea to maintain all the headers up to date manually, although this permitted to learn a bit the API. Note that building must be done at least twice the first time because of a DUB limitation. other changes : - dub package on code dlang is gone, it must really be a git stuff now - it's much faster because build is optimized using git hashes. - location changed due to GH account renaming https://github.com/Basile-z/libfirm-d
Re: D GUI Framework (responsive grid teaser)
On Tuesday, 21 May 2019 at 14:04:29 UTC, Robert M. Münch wrote: On 2019-05-19 21:21:55 +, Ola Fosheim Grøstad said: Interesting, is each cell a separate item then? So assuming 3GHz cpu, we get 0.23*3e9/1600 = 431250 cycles per cell? That's a lot of work. Here is a new screencast: https://www.dropbox.com/s/ywywr7dp5v8rfoz/Bildschirmaufnahme%202019-05-21%20um%2015.20.59.mov?dl=0 I optimized the whole thing a bit, so now a complete screen with layouting, hittesting, drawing takes about 28ms, that's 8x faster than before. Drawing is still around 10ms, layouting around 16ms, spatial index handling 2ms. So this gives us 36 FPS which is IMO pretty good for a desktop app target. There might be some 2-3ms speed-up still possible but not worth the effort yet. openGL backend I presume ?
Re: D GUI Framework (responsive grid teaser)
On Sunday, 19 May 2019 at 21:01:33 UTC, Robert M. Münch wrote: Hi, we are currently build up our new technology stack and for this create a 2D GUI framework. https://www.dropbox.com/s/iu988snx2lqockb/Bildschirmaufnahme%202019-05-19%20um%2022.32.46.mov?dl=0 The screencast shows a responsive 40x40 grid. Layouting the grid takes about 230ms, drawing it about 10ms. The mouse clicks are handled via a reactive message stream and routed to all graphical objects that are hit using a spatial-index. The application code part is about 50 lines of code, the rest is handled by the framework. With all this working now, we have all necessary building blocks working together. Next steps are to create more widgets and add a visual style system. The widgets themself are style-free and wire-frame only for debugging purposes. What kind of layouting ? GTK-like ? DelphiVCL-like ? Flex-like ?
Re: Let's celebrate Dlang on D day
On Saturday, 25 May 2019 at 03:22:50 UTC, Murilo wrote: On the 6th of June(6/6) we celebrate the D day on Normandy, but I have decided to turn it into our own holiday to celebrate the D language. So on this day please take the time to tell the world about this language and to invite more people into our community. I will try to give some talks at universities in order to get the attention of the people. I suggest you all do similar stuff. In the Dlang facebook group https://www.facebook.com/groups/662119670846705/ which has already reached 135 members, we will be doing lots of fun stuff. Please show up and join the group to participate. I will try to turn this into an actual holiday. I hope you can all help me out. I dont think it's a good idea. One of mine grandpa served in the french Marine when they destroyed the ships at Toulon. The other went from algeria, from a spanish colony, to here... This D day idea is completly stupid.
Re: The D Blog in 2018
On Sunday, 2 June 2019 at 20:08:28 UTC, Murilo wrote: Hi everyone. I don't mean to spam Sure otherwise you would not post this 3 times in a row: - https://forum.dlang.org/post/tjoipokamsvpbemzd...@forum.dlang.org - https://forum.dlang.org/reply/hebsehdcxhlhkzwxh...@forum.dlang.org
D IDE dexed - v3.7.10 available
A small update of this IDE dedicated to the D languages and its tools [1]. Only some small fixes and adjustments, see [2] for details and pre-compiled binaries. [1] https://github.com/Basile-z/dexed [2] https://github.com/Basile-z/dexed/releases/tag/v3.7.10
Re: D IDE dexed - v3.7.10 available
On Thursday, 13 June 2019 at 05:09:34 UTC, gleb.tsk wrote: On Monday, 10 June 2019 at 20:34:14 UTC, Basile B. wrote: [1] https://github.com/Basile-z/dexed [2] https://github.com/Basile-z/dexed/releases/tag/v3.7.10 Thank you, very interesting. But... lazbuild -B -r dexed.lpi TEditorToolBarOptions.Load: Using old configuration in editortoolbar.xml. Hint: (lazarus) [RunTool] /usr/bin/fpc "-iWTOTP" Hint: (lazarus) [RunTool] /usr/bin/fpc "-va" "-Fr/usr/lib64/fpc/msg/errore.msg" "compilertest.pas" Error: (lazbuild) Broken dependency: DexedDesignControls See https://github.com/Basile-z/dexed/issues/456. Unfortunately the reporter never gave any feedback so I had closed. All I know is that installing the package in Laz, then rebuilding Laz then building the project will work.
Re: D IDE dexed - v3.7.10 available
On Tuesday, 11 June 2019 at 21:05:05 UTC, Kaylan Tussey wrote: On Monday, 10 June 2019 at 20:34:14 UTC, Basile B. wrote: A small update of this IDE dedicated to the D languages and its tools [1]. Only some small fixes and adjustments, see [2] for details and pre-compiled binaries. [1] https://github.com/Basile-z/dexed [2] https://github.com/Basile-z/dexed/releases/tag/v3.7.10 I tried this ide. Best one aside from vd+vs imo. But it has one problem. It's written in a language i'm not familiar with :(. I can't add any functionality I wanted, such as a really nice directory/file manipulator. I found myself getting down and dirty in windows explorer then directing dexed to the folders/files. Unless I missed something? There's not much to add to the mini explorer anymore but shell actions (rename, delete, etc.). It looks easy at first glance but a naive implementation will not allow to undo/redo from the Windows file explorer. You can suggest changes here : https://github.com/Basile-z/dexed/issues. The suggestion for the shell actions is already opened.
Re: D IDE dexed - v3.7.10 available
On Thursday, 13 June 2019 at 20:12:41 UTC, Machine Code wrote: On Monday, 10 June 2019 at 20:34:14 UTC, Basile B. wrote: A small update of this IDE dedicated to the D languages and its tools [1]. Only some small fixes and adjustments, see [2] for details and pre-compiled binaries. [1] https://github.com/Basile-z/dexed [2] https://github.com/Basile-z/dexed/releases/tag/v3.7.10 You're the author? Thank you very much! When I was working on project on linux, this was the best I could find. It has a issue with crashing but deleting a temporary file (sorry don't remeber name now...) fixed the issue. So you've written this IDE by youtself? I was interesting in building a small IDE. Do you have any books (not sure if exists) on topic? or links/resource that might be helpful? I don't think there's anything on the topic because this is not technical: UX best practices (the way the toolkit is made should enforce that automatically), observer pattern, mediator pattern, processes and standard streams, much serialization too, and you're good.
Re: my first kernel in betterC D
On Sunday, 16 June 2019 at 16:14:26 UTC, Laeeth Isharc wrote: https://github.com/kaleidicforks/mkernel-d I spent a few minutes on just turning the C code to betterC D - was curious to see if it would work. It seems to. I didn't try loading with GRUB. The dub.sdl isn't quite right, so best run ./build.sh Cannot push to code.dlang.org - it complains about registering a forked package, even after renaming. IIRC there used to be a protection supposed to prevent hijacking of package names, e.g someone that would register from a fork before the original package, blocking the original author, considered as more legit. But https://github.com/dlang/dub-registry/pull/425/files seems to say that it should work now.
Re: argument parsing into structure
On Wednesday, 26 June 2019 at 09:40:06 UTC, JN wrote:
On Wednesday, 26 June 2019 at 05:38:32 UTC, Jesse Phillips
wrote:
Sometimes a good API isn't the right answer. I like getopt as
it is but I wanted a little different control. So I wrote up
an article on my work around.
https://dev.to/jessekphillips/argument-parsing-into-structure-4p4n
I have another technique for sub commands I should write about
too.
http://code.dlang.org/packages/argsd
I think we are several having written alternative getopt()
systems.
I made one too last year, it allows to write tools very nicely.
Recent example for a device flasher:
---
module app;
import
iz.options;
struct Handler
{
private:
public:
/// Handle the "--help" command.
@Argument("--help", "prints the command line usage",
ArgFlags(ArgFlag.allowShort))
static void getHelp();
/// Handle the "--info" command.
@Argument("--info", "prints the list of connected mods",
ArgFlags(ArgFlag.allowShort))
static void getInfo();
/// Handle the "--readFlash" command.
@Argument("--readFlash", "read the firmware from the mod and
save it to the specified file")
static void readFlash(string fname);
/// Handle the "--writeFlash" command.
@Argument("--writeFlash", "read the firmware from the
specified file and send it to the mod")
static void saveFlash(string fname);
/// Handle the "--reset" command.
@Argument("--reset", "reset to factory state",
ArgFlags(ArgFlag.allowShort))
static void reset();
}
void main(string[] args)
{
if (!handleArguments!(CanThrow, Handler)(args[1..$]) ||
args.length == 1)
writeln(help!Handler);
}
---
https://github.com/Basile-z/iz/blob/master/import/iz/options.d#L379
Though I've detected several little flaws since it was written,
but I don't care much anymore about my own stuff these days...
Re: argument parsing into structure
On Wednesday, 26 June 2019 at 23:35:59 UTC, Jesse Phillips wrote: On Wednesday, 26 June 2019 at 14:58:08 UTC, Basile B. wrote: On Wednesday, 26 June 2019 at 09:40:06 UTC, JN wrote: On Wednesday, 26 June 2019 at 05:38:32 UTC, Jesse Phillips wrote: Sometimes a good API isn't the right answer. I like getopt as it is but I wanted a little different control. So I wrote up an article on my work around. https://dev.to/jessekphillips/argument-parsing-into-structure-4p4n I have another technique for sub commands I should write about too. http://code.dlang.org/packages/argsd I think we are several having written alternative getopt() systems. I made one too last year, it allows to write tools very nicely. Recent example for a device flasher: The thing is, I didn't write an alternative, mine utilizes getopt which was the point of the article. I could build out new functionality onto a standard API which didn't support it. It isn't as robust as it could be. Sorry budy, I didn't want to ruin your announce. Hold on ;)
Re: Bison 3.5 is released, and features a D backend
On Wednesday, 1 January 2020 at 09:47:11 UTC, Akim Demaille wrote: Hi all! GNU Bison 3.5 was released with a D backend (https://savannah.gnu.org/forum/forum.php?forum_id=9639). This backend is functional, and you can get a sense of its current shape by looking at the shipped example (a calculator, what did you expect?): https://github.com/akimd/bison/blob/master/examples/d/calc.y. Bison is an LR parser generator. It supports not only Yacc's original LALR(1) parsers, but also canonical LR and IELR(1) which are strictly more powerful (meaning: they accept wider classes of languages). It also features Generalized LR, which can even parse ambiguous grammars. The D backend currently does not support the full range of Bison features. We desperately need some skilled D programmer(s) to support this backend. It was first contributed by Oliver Mangold, based on Paolo Bonzini's Java backend. It was cleaned and improved thanks to H. S. Teoh, yet it's certainly not yet fitting perfectly the D spirit. Since the backend is still experimental, there is flexibility: it can be changed and improved until it meets the D community standards. If you would like to contribute, please reach out to us via bison-patc...@gnu.org, or help-bi...@gnu.org. Best wishes for 2020. Cheers! nice, thanks
Re: DIP 1027---String Interpolation---Format Assessment
On Monday, 24 February 2020 at 10:02:26 UTC, Mike Parker wrote: I mean, people spend a lot of time thinking, making suggestions, etc. and the end result is: we now have nothing. Which, IMO is the worst result for all. Not at all. In this case, as the DIP author, Walter could have chosen to revise the DIP with a new implementation. He chose not to. He wasn't persuaded by the arguments in the thread. Yeah, not to mention that in first place I think that he made a DIP for named args because the commuity was unable to formulate a good propostion, while he was himself not "pro-named args"... (maybe, I think i read this in the past)
DDOC generator Harbored-Mod - v0.3.4
Harbored-Mod is a lesser known documentation generator for the D programming language. Since the last release several old bugs have been fixed. The location[1] has changed too. - added support for anchors via anchor.js - enum member attributes are displayed (they didn't exist when the soft was created). - comments for enum members were not displayed. - fix a problem when collapsing the TOC in index.html - the template param for typed and templated enum was not displayed. - empty headers were generated, which has been revealed by the addition of anchors. [1] https://gitlab.com/basile.b/harbored-mod Note that I don't have access to the DUB registry to update the location so Ilya Y. if you read this maybe you can do that [2] ;). [2] https://code.dlang.org/packages/harbored-mod
D IDE Dexed - v3.9.0
Despite of the mini drama last year I've continued developping dexed. The changelog since last announce here is a bit long, check https://gitlab.com/basile.b/dexed/-/releases for more information and get the releases (linux only).
Re: DDOC generator Harbored-Mod - v0.3.4
On Saturday, 25 April 2020 at 08:36:40 UTC, 9il wrote: On Saturday, 25 April 2020 at 06:50:07 UTC, Basile B. wrote: [1] https://gitlab.com/basile.b/harbored-mod Note that I don't have access to the DUB registry to update the location so Ilya Y. if you read this maybe you can do that [2] ;). [2] https://code.dlang.org/packages/harbored-mod done thanks Ilya.
Re: D IDE Dexed - v3.9.0
On Sunday, 3 May 2020 at 18:40:37 UTC, notna wrote: On Saturday, 25 April 2020 at 06:55:19 UTC, Basile B. wrote: Despite of the mini drama last year I've continued developping dexed. The changelog since last announce here is a bit long, check https://gitlab.com/basile.b/dexed/-/releases for more information and get the releases (linux only). On Win10 64Bit, after compiling as described in https://basile.b.gitlab.io/dexed/build.html, I have a "dexed.exe" but if I run it, I get "couldn't find dexed-d.dll" ... It should be in the same folder as dexed.exe. If it's not there this means that the preprocess has failed. You must have ldc2 visible in the PATH variable. For now I can only advice you tobuild libdexed-d.dll manually to see what the problem is. in the repository, sub folder dexed-d, try $ dub.exe --compiler=ldc2 and tells me what's happening. dexed-d.dll should be created in the same folder as dexed.exe. TBH I don't know if Windows is still supported. As a user I have totally dropped this system, since I didn't use it since years but only to build dexed.
Re: D IDE Dexed - v3.9.0
On Sunday, 3 May 2020 at 18:40:37 UTC, notna wrote: On Saturday, 25 April 2020 at 06:55:19 UTC, Basile B. wrote: Despite of the mini drama last year I've continued developping dexed. The changelog since last announce here is a bit long, check https://gitlab.com/basile.b/dexed/-/releases for more information and get the releases (linux only). On Win10 64Bit, after compiling as described in https://basile.b.gitlab.io/dexed/build.html, I have a "dexed.exe" but if I run it, I get "couldn't find dexed-d.dll" ... Can you give a try again after pulling latest changes ? Actually the library indicated as missing was build by calling bash which obviously could not work on Windows. I have pushed a change that replaces this by a direct call to dub since the script was essentially used to "cd" and that's not required as dub has "--root"
Re: D IDE Dexed - v3.9.0
On Tuesday, 5 May 2020 at 20:05:25 UTC, notna wrote: On Tuesday, 5 May 2020 at 20:03:38 UTC, notna wrote: On Tuesday, 5 May 2020 at 12:53:29 UTC, Basile B. wrote: On Win10 64Bit, after compiling as described in https://basile.b.gitlab.io/dexed/build.html, I have a "dexed.exe" but if I run it, I get "couldn't find dexed-d.dll" ... Can you give a try again after pulling latest changes ? Actually the library indicated as missing was build by calling bash which obviously could not work on Windows. I have pushed a change that replaces this by a direct call to dub since the script was essentially used to "cd" and that's not required as dub has "--root" Thanks for your changes. Seems like linking take a bit longer now but the DLL is still not build. The log from DUB tends to say the opposite. The dll should be in "C:\Temp\Git\dexed\bin". Maybe the extension is missing then ? Another change => calling "dexed.exe" doesn't shop the error popup as it did before... grrr... doesn't _SHOW_ the error popup as it did before... Try the default procedure now. i.e using lazbuild as explained in the documentation. As the library is statically linked this is mandatory anyway.
Re: D IDE Dexed - v3.9.0
On Thursday, 7 May 2020 at 23:50:51 UTC, notna wrote: On Tuesday, 5 May 2020 at 22:00:30 UTC, Basile B. wrote: Try the default procedure now. i.e using lazbuild as explained in the documentation. As the library is statically linked this is mandatory anyway. pull'ed incl submodules again... re-build everything, DLL is there BUT... - starting dexed.exe in PowerShell doesn't show anything - starting dexed.exe in CMD brings up an error window, saying something like "application couldn't be started, (0xc07b) ..." Sorry, I'm tempted to drop official Windows support good. I have an old win7 DVD but I'd prefer if someone who actually uses Windows could fix this. For now let's talk here https://gitlab.com/basile.b/dexed/-/issues/37, as it is very specific.
Re: [OT] What do you guys think of dark comedy channel on IT sh.. stuff?
On Tuesday, 12 May 2020 at 07:52:29 UTC, Dmitry Olshansky wrote: I find that I can vaguely amusing 100% of the day and I love standup comedy... So I thought maybe I can give it a shot with a youtube channel? I already invent a cool personality - think Dirk Gently in computer science setting;) If that seems cool to you shoot me an email, or reply in this thread ... I need to the count to have a rough estimate of how low the size of my initial audience is.. I rarely watch videos about programming (even talk) but I'd certainly take a look if you start something. It cant be worst than one of these tutorial produced by random Indian guys.
Re: D IDE Dexed - v3.9.0
On Saturday, 9 May 2020 at 11:33:08 UTC, notna wrote: On Friday, 8 May 2020 at 00:46:04 UTC, Basile B. wrote: Sorry, I'm tempted to drop official Windows support good. I have an old win7 DVD but I'd prefer if someone who actually uses Windows could fix this. For now let's talk here https://gitlab.com/basile.b/dexed/-/issues/37, as it is very specific. Thanks... seems like I was the only one interested in using it on Windows, so... most of the time I use VSCodium with the great code-d plugin by now anyhow, so I will survive also without dexed ;) I've fixed it yesterday (https://gitlab.com/basile.b/dexed/-/commit/730c2a4e6e1ae18d603d91c471bf3b6459ce7b52) using my mom's laptop ^^. Fortunately I've found an old post from p0nce (https://forum.dlang.org/post/mscgsclxwtjcferfx...@forum.dlang.org) that explained in detail how to make dll on win and the error has become obvious. IMPORTANT: Use `export` for any call you want exported in your DLL! Also in IDA the list of the exports showed nothing... that was a huge f**ing clue. anyway the Windows version is verified to work now. Only thing is that a msvc140.dll might be necessary, but this is not a dexed problem. In this case people can just get it from the official microsoft website.
Re: LDC 1.23.0
On Wednesday, 19 August 2020 at 17:45:46 UTC, kinke wrote: Glad to announce LDC 1.23 - some highlights: - Based on D 2.093.1+. - LLVM for prebuilt packages bumped to v10.0.1; min version raised to 6.0. - Cross-compiling to the iOS/x86_64 simulator now works out-of-the-box with the prebuilt Mac package. - Windows: New -gdwarf command-line option for debugging with gdb/lldb. - Fix linker errors for -betterC wrt. cleanups (structs with dtor, `scope(exit)`). Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.23.0 Thanks to all contributors! gdwarf really ? this is possible ? Not that this is not a great news but you told me once this was not quite possible (https://forum.dlang.org/post/ttblgcwiwmdhyukzp...@forum.dlang.org).
Re: LDC 1.23.0
On Wednesday, 19 August 2020 at 23:47:34 UTC, kinke wrote: On Wednesday, 19 August 2020 at 23:30:30 UTC, Basile B. wrote: gdwarf really ? this is possible ? Not that this is not a great news but you told me once this was not quite possible (https://forum.dlang.org/post/ttblgcwiwmdhyukzp...@forum.dlang.org). I said that LDC/LLVM generate CodeView, but knew that clang can emit it. Shortly after your post, another guy asked for DWARF on Windows, so I did a little bit of digging. I haven't properly tested it (no working gdb/lldb on my Windows box), You can get gdb for windows by installing Lazarus or even more simply try one of the alternative version that they propose [1]. feedback is appreciated. I will test the feature soon, since now I want to see if the GDB GUI of my IDE can be activated or not on windows. [1] https://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2064%20bits/Alternative%20GDB/
Re: Release D 2.094.0
On Tuesday, 29 September 2020 at 13:38:58 UTC, apz28 wrote: On Saturday, 26 September 2020 at 21:45:09 UTC, Martin Nowak wrote: Glad to announce D 2.094.0, ♥ to the 49 contributors. This release comes with faster compiler binaries (built with ldc), direct git dependencies in dub, better type checking of vectors, and improved template instantiation diagnostics. http://dlang.org/download.html http://dlang.org/changelog/2.094.0.html -Martin Look like this build does not have ASSERT on. I have a VisualD project that build successfully in release but fail in debug without any error message - it fails in "semantic3" step on one of the module. Only the version build during continuous have assert on since a few weeks [1]. The PR that should have allowed the same in the official release [2] has been closed by error, hence the changelog lead to a wrong idea about the current state of assert in the compiler itself. [1] https://github.com/dlang/dmd/pull/11523 [2] https://github.com/dlang/dmd/pull/10679
Re: Release D 2.094.0
On Wednesday, 30 September 2020 at 18:38:25 UTC, Basile B. wrote: On Tuesday, 29 September 2020 at 13:38:58 UTC, apz28 wrote: On Saturday, 26 September 2020 at 21:45:09 UTC, Martin Nowak wrote: Glad to announce D 2.094.0, ♥ to the 49 contributors. This release comes with faster compiler binaries (built with ldc), direct git dependencies in dub, better type checking of vectors, and improved template instantiation diagnostics. http://dlang.org/download.html http://dlang.org/changelog/2.094.0.html -Martin Look like this build does not have ASSERT on. I have a VisualD project that build successfully in release but fail in debug without any error message - it fails in "semantic3" step on one of the module. Only the version build during continuous *integration,
Re: LDC 1.24.0-beta1
On Monday, 19 October 2020 at 20:49:14 UTC, Andre Pany wrote: On Monday, 19 October 2020 at 18:48:11 UTC, notna wrote: On Sunday, 18 October 2020 at 22:40:53 UTC, aberba wrote: It would be convenient if you provided a .exe installer as well. Not sure what to do with the .7z file without manual tinkering. use scoop for Windows package mgmt in a user context. build with developers in mind. for installation see: https://scoop.sh/ simple as: * scoop install dmd * scoop install ldc stay always up to date: * scoop update * scoop update * ... and MUCH more, see https://github.com/lukesampson/scoop/wiki Also Microsoft is working on a package manager which might be an option in the future https://docs.microsoft.com/de-de/windows/package-manager/ Kind regards Andre Looks a bit like "classic MS". Instead of buying something similar that exists they do their own.
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Wednesday, 6 January 2021 at 09:24:28 UTC, Mike Parker wrote: On Wednesday, 6 January 2021 at 09:21:53 UTC, Mike Parker wrote: However, if you have any specific feedback on how to improve the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary that I will write at the end of this review round. I will post a link to that thread immediately following this post. The Feedback Thread is here: https://forum.dlang.org/post/qglydztoqxhhcurvb...@forum.dlang.org Before posting a review, I have a question: What was the problem exactly with Kenji H.'s work ? How is the same problem addressed ? I presume this is by forbidding the new syntax in templates decl ? (nothing is explained here https://github.com/dlang/dmd/pull/4373)
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Wednesday, 6 January 2021 at 09:55:34 UTC, Basile B. wrote: On Wednesday, 6 January 2021 at 09:24:28 UTC, Mike Parker wrote: On Wednesday, 6 January 2021 at 09:21:53 UTC, Mike Parker wrote: [...] The Feedback Thread is here: https://forum.dlang.org/post/qglydztoqxhhcurvb...@forum.dlang.org Before posting a review, I have a question: What was the problem exactly with Kenji H.'s work ? How is the same problem addressed ? I presume this is by forbidding the new syntax in templates decl ? (nothing is explained here https://github.com/dlang/dmd/pull/4373) well never mind, I've mentioned in the review that nothing is explaiend about the old attempt.
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Wednesday, 6 January 2021 at 10:55:39 UTC, Ola Fosheim Grøstad wrote: I am in favour of more controlled type inference in general, but perhaps this one is a bit specific. What if you defined "_" to mean "deduce whatever should be in this spot", not only for static arrays, but for all types? Then you could do: int[_] = … or _[_] … etc '$' is not an ident char, that's why that works
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Wednesday, 6 January 2021 at 11:11:41 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 6 January 2021 at 10:55:39 UTC, Ola Fosheim
Grøstad wrote:
int[_] = …
or
_[_] …
To expand on this with more examples, you might want to
constrain "auto" in various ways with pattern matching:
// ensure static array of something with length 4
_[4] v = f();
// ensure that I get a MyContainer with some unspecified type
elements
MyContainer<_> c = g();
// define a function that swaps the content of an array of
length 2
void swap(ref _[2] a){ … }
// it would also be shorter than auto, but not sure if that is
a good thing
_ x = 3 // same as "auto x = 3"
I thought about auto when reading the DIP too, but auto is more
used like a Type (although being a storage class ;) ). It's never
used to infer a value, i.e an expression. While I understand what
you mean this is unrelated. Dollar is very well suited.
Maybe you could create the underscore-lang to showcase the idea ;)
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Wednesday, 6 January 2021 at 11:29:42 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 6 January 2021 at 11:18:22 UTC, Basile B. wrote: I thought about auto when reading the DIP too, but auto is more used like a Type (although being a storage class ;) ). It's never used to infer a value, i.e an expression. While I understand what you mean this is unrelated. Dollar is very well suited. Hmm... My take is that this proposal is auto with a constraint, except it will also do implicit conversion. yeah the split of DIP feedbacks and DIP discussions was clearly not a bad thing ^^
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Wednesday, 6 January 2021 at 11:55:12 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 6 January 2021 at 11:39:08 UTC, Basile B. wrote: Hmm... My take is that this proposal is auto with a constraint, except it will also do implicit conversion. yeah the split of DIP feedbacks and DIP discussions was clearly not a bad thing ^^ Do you disagree? No. I agree. Do you imagine if this conversation was in the offical DIP review. E.g those two a**holes who troll the review process /s
styx, a programming languange written in D, is on the bootstrap path
This is the last[1] occasion to speak about a programming language initiatly made in D, as the bootstrap phase is very near. I'd like to thank the D compiler developers, that let me work on DMD even if I borrow another path. [1] : https://gitlab.com/styx-lang/styx
Re: styx, a programming languange written in D, is on the bootstrap path
On Thursday, 14 January 2021 at 20:21:42 UTC, Daniel N wrote: On Thursday, 14 January 2021 at 17:51:51 UTC, Basile B. wrote: This is the last[1] occasion to speak about a programming language initiatly made in D, as the bootstrap phase is very near. I'd like to thank the D compiler developers, that let me work on DMD even if I borrow another path. [1] : https://gitlab.com/styx-lang/styx Love the design FWIW. Initially I wanted something like libdparse + dsymbol, i.e a clean split of the AST the semantic phase, semi-success. There's still a Symbol class but the types have been moved to the AST. Another design idea is that I wanted to have useful visitors, i.e that always process a whole compilation unit, but that did not work well so now visitors are pretty much state-less and when a "state" is required it is stored in scopes, "like in dmd". I quote that because many times I've discovered that, in dmd, if things are done in a way and not another, it's not arbitrary. The main reason for that is that if you want to support out of order declarations and "auto" you have to drive the semantics like in dmd, declaration -> bodies -> statements -> expressions, and when you reach something that is not known you launch this chain...
Re: styx, a programming languange written in D, is on the bootstrap path
On Friday, 15 January 2021 at 09:54:59 UTC, Ola Fosheim Grøstad wrote: On Thursday, 14 January 2021 at 17:51:51 UTC, Basile B. wrote: This is the last[1] occasion to speak about a programming language initiatly made in D, as the bootstrap phase is very near. Interesting project! How did you move from D to Styx? (I assume bootstrapping means a self hosting compiler?) Did you write some scripts to translate? self-hosting is not started yet, maybe next month, classes are still to be implemented. I plan to use dparse for the most part, not only to convert but also to detect non bootstrapable code or missing features. Then, feature freeze, convert, catch and fix bugs as they will appear when feading the compiler with real food. I've found myself to sketch new programming languages whenever I hit things in existing languages that I find annoying over the past decade or so. This is a noble reason. Styx has no such motivations. It is simpler than D1 for example and has no killer feature, just 3 or 4 creative things are - optional break/continue expression - explicit overloads - DotExpression aliases (they have been proposed to DMD this summer when I worked "under cover" as Nils.) - pointers to member function is very different from what I have seen so far (no fat pointer) I finally decided to start on a lexer for it... How long did it take you to get where you are now? The project exists since several years (2017-04-13 20:05:51) but is only actively developed since july 2020. The game changers were: - to use LLVM instead of libfirm - to that some part of the initial design were bad - proper lvalue implementation
Re: styx, a programming languange written in D, is on the bootstrap path
On Friday, 15 January 2021 at 19:25:38 UTC, Per Nordlöw wrote: On Friday, 15 January 2021 at 19:18:09 UTC, Basile B. wrote: - DotExpression aliases (they have been proposed to DMD this summer when I worked "under cover" as Nils.) Can you give examples of what a DotExpression alias is? They allow to pull heavily nested members, similarly as getters are sometime used and are supposed to make object composition easier. This [1] is the test file used to develop the feature. [1] https://gitlab.com/styx-lang/styx/-/raw/51611f2d5c023c0edfe97968b543660ae2e89c26/tests/backend/dotexp_alias.sx
Re: styx, a programming languange written in D, is on the bootstrap path
On Friday, 15 January 2021 at 19:40:11 UTC, Ola Fosheim Grøstad wrote: On Friday, 15 January 2021 at 19:18:09 UTC, Basile B. wrote: I plan to use dparse for the most part, not only to convert but also to detect non bootstrapable code or missing features. Ah, smart. I've been thinking about using an existing d-parser to convert unit tests from D to my Dex syntax (experimental project). Modifying the compiler is fun, but writing unit tests is not... This is a noble reason. Styx has no such motivations. It is simpler than D1 for example and has no killer feature, What made D1 attractive to many C++ programmers was that it was stripped down. Also, many language designers get tempted to add many features that are hollow, then they regret it and rip it all out again (lots of wasted effort and source code). So, being very restrictive and patient is a good thing, I believe. The truly good ideas takes time to "grow" (in ones mind). just 3 or 4 creative things are - optional break/continue expression - explicit overloads - DotExpression aliases (they have been proposed to DMD this summer when I worked "under cover" as Nils.) - pointers to member function is very different from what I have seen so far (no fat pointer) "Nils" is a very scandinavian name? :-) Yeah, in addition to my real name, I've been invovled in dmd as "Nils Lankila" and "Stian Gulpen" which are names generated using specialized services. You can choose to have a swedish name for example.
Re: styx, a programming languange written in D, is on the bootstrap path
On Monday, 18 January 2021 at 17:45:16 UTC, Basile B. wrote: On Friday, 15 January 2021 at 19:40:11 UTC, Ola Fosheim Grøstad wrote: [...] Yeah, in addition to my real name, I've been invovled in dmd as "Nils Lankila" and "Stian Gulpen" which are names generated using specialized services. You can choose to have a swedish name for example. on the internet nobody knows you're a dog ;)
Re: styx, a programming languange written in D, is on the bootstrap path
On Monday, 18 January 2021 at 17:51:16 UTC, Basile B. wrote: On Monday, 18 January 2021 at 17:45:16 UTC, Basile B. wrote: On Friday, 15 January 2021 at 19:40:11 UTC, Ola Fosheim Grøstad wrote: [...] Yeah, in addition to my real name, I've been invovled in dmd as "Nils Lankila" and "Stian Gulpen" which are names generated using specialized services. You can choose to have a swedish name for example. on the internet nobody knows you're a dog ;) https://de.fakenamegenerator.com/
Re: styx, a programming languange written in D, is on the bootstrap path
On Monday, 18 January 2021 at 18:03:12 UTC, IGotD- wrote: On Thursday, 14 January 2021 at 17:51:51 UTC, Basile B. wrote: This is the last[1] occasion to speak about a programming language initiatly made in D, as the bootstrap phase is very near. I'd like to thank the D compiler developers, that let me work on DMD even if I borrow another path. [1] : https://gitlab.com/styx-lang/styx Interesting project. A few questions. I see that you use "var auto name" in order to automatically infer the type. Would it be possible just using "var name" for that, similar to other popular languages. There is currently no information about memory management, is this something you have an idea how to design right now? yes, it would be possible, but it wont be done. In Styx "auto" is a type joker and that's it.
Re: styx, a programming languange written in D, is on the bootstrap path
On Tuesday, 19 January 2021 at 12:50:40 UTC, Max Haughton wrote: On Friday, 15 January 2021 at 19:18:09 UTC, Basile B. wrote: On Friday, 15 January 2021 at 09:54:59 UTC, Ola Fosheim Grøstad wrote: [...] self-hosting is not started yet, maybe next month, classes are still to be implemented. I plan to use dparse for the most part, not only to convert but also to detect non bootstrapable code or missing features. Then, feature freeze, convert, catch and fix bugs as they will appear when feading the compiler with real food. [...] Thoughts on libfirm? I am thinking about writing an online book about compiler backends so I'm curious what it's like to work with. There is this small wiki page https://proglangdesign.net/wiki/firm written by myself, so I have not much to add, as I've dropped FIRM at the very beginning of the backend exprimentation.
Re: Beta 2.097.0
On Thursday, 13 May 2021 at 15:26:59 UTC, Berni44 wrote: On Thursday, 13 May 2021 at 13:38:44 UTC, jmh530 wrote: "11. Floating point numbers don't allocate with the GC anymore." Should this be "11. Formatting floating point numbers doesn't allocate with the GC anymore." Probably my fault. Is it possible to still change this? What do I have to do? Just edit this file : https://github.com/dlang/phobos/blob/master/changelog/formatting_floats_nogc.dd and you're good.
Re: Bugzilla Reward System
On Thursday, 16 September 2021 at 11:56:21 UTC, Mike Parker wrote: In my summary of last month's D Language Foundation meeting, I mentioned that we discussed a system intended to reward contributors who contribute pull requests that fix Bugzilla issues. This was Razvan Nitu's baby from conception to implementation, and we all think it is a great idea. The system has been running in the background for a few weeks now, quietly gathering data and awarding points, proving that the programming side works as intended. Our first round of point scoring kicks off on September 20th. Razvan has put together a blog post explaining how the system works. We'll revise and adapt the system as needed as time goes by. In the meantime, happy bug fixing! The blog: https://dlang.org/blog/2021/09/16/bugzilla-reward-system/ Reddit: https://www.reddit.com/r/d_language/comments/ppbp7d/bugzilla_reward_system/ This is a good move, I hope it will work so that D will keep contributors that are not already gone and gain new talented ones. Another answer mentions that the lack of "issue triage" might cause problems. I think to the opposite that this system could encourage 1. better triage 2. better reviews But well, we'll see if this works next year. Let's not be negative ;)
Dexe-ide 3.9.12
# v3.9.12 - editor: a new option, _textCompletion_, sets if the completion menu includes the identifiers obtained by word-splitting the whole document. (#85) - editor: prevent completion menu to show on fast enough (< to the _autoDotDelay_ setting) `..`. - Halstead metrics: show full function signatures. - projects: added the _Check semantics_ to the menu. (#83) - DUB projects: added support for the _syntax_ build type. (#83) - GDB commander: arguments of the _Debugee Options_ can be temporarily deactivated by prepending `//`. - GDB commander: add an option allowing to set the path to the gdb binary. (#73) - GDB commander: the context menu of the ASM view allows to resume execution until the selected instruction. (#71) - Search results: use GNU style messages. (#84) ## Regressions fixed - editor, _closeCompletionCharsWithSpace_ broken by [git b65bb860](https://gitlab.com/basile.b/dexed/-/commit/b65bb860e45c47e3c48bf513aeafd9968daa2482). ## Bugs fixed - D2 highlighter: for `Call()`, `Call` wont be considered anymore as a type. (#69) - GDB commander: 5 empty arguments were passed to the main function called by libc. (#86) - Symlist: errors were not visible enough since moved to the top. (#92) ## Other - can be build with Lazarus 2.2 but backward compatible 2.0.z. - provided binaries are build with Lazarus 2.0.12 due to 2.2 not being released. --- To get a release [see here](https://gitlab.com/basile.b/dexed/-/releases). Note that the appveyor build has failed this time so no offical windows binaries.
Re: Release 2.098.0
On Sunday, 10 October 2021 at 14:10:53 UTC, Martin Nowak wrote: Glad to announce D 2.098.0, ♥ to the 62 contributors. This release comes with template alias assignments, ImportC, a forking parallel GC for POSIX systems, and many more changes. http://dlang.org/download.html http://dlang.org/changelog/2.098.0.html -Martin The most important fix in this version for me is not well exposed in the changelog. With https://github.com/dlang/dmd/pull/12978, finally all inherited fields of a class are displayed, e.g when using `p *instance` in gdb, which painfully missed before (unless you used GDB or LDC of course). Thanks in particular to Rainers for that fix !
dexed-ide v3.9.13
## Enhancements - messages, search results: exclude backticks if the option _backTicksHighlight_ is enabled. - GDB commander: double click on the call stack to select a frame and refresh the different views. This is especially useful to go back to the frame where a D Exception is thrown. (#52) - completion: partial support for dependencies of type _package:subpackage_. ## Bugs fixed - diff dialog: the content reloaded matched to the state when the dialog was shown, not when closed. (#97) - editor, debugging: during a debugging session, wrong icon displayed when a breakpoint is removed. - DUB project inspector: the tree was empty if the project is moslty organized in subpackages. - DUB projects: version number without the patch component were not accepted. ## links - [homepage](https://gitlab.com/basile.b/dexed) - [assets](https://gitlab.com/basile.b/dexed/-/releases). Note that the automated Windows build is still broken.
Re: dexed-ide v3.9.13
On Monday, 11 October 2021 at 07:42:12 UTC, Imperatorn wrote: On Monday, 11 October 2021 at 06:58:18 UTC, Basile B. wrote: ## Enhancements - messages, search results: exclude backticks if the option _backTicksHighlight_ is enabled. - GDB commander: double click on the call stack to select a frame and refresh the different views. This is especially useful to go back to the frame where a D Exception is thrown. (#52) - completion: partial support for dependencies of type _package:subpackage_. [...] 😍 I'm on Windows though, but thanks for maintaining dexed it's easy to build. If a script can do it on appveyor, a human can do it on its windows box. Actually if the appveyor build fails it's because of d-scanner, not dexed.
Re: dexed-ide v3.9.13
On Monday, 11 October 2021 at 09:52:14 UTC, Basile B. wrote: On Monday, 11 October 2021 at 07:42:12 UTC, Imperatorn wrote: On Monday, 11 October 2021 at 06:58:18 UTC, Basile B. wrote: ## Enhancements - messages, search results: exclude backticks if the option _backTicksHighlight_ is enabled. - GDB commander: double click on the call stack to select a frame and refresh the different views. This is especially useful to go back to the frame where a D Exception is thrown. (#52) - completion: partial support for dependencies of type _package:subpackage_. [...] 😍 I'm on Windows though, but thanks for maintaining dexed it's easy to build. If a script can do it on appveyor, a human can do it on its windows box. Actually if the appveyor build fails it's because of d-scanner, not dexed. mmmh lmao actually. The build fails because the checkout is done before entering the repo dir: https://gitlab.com/basile.b/dexed/-/blob/master/.appveyor.yml#L52
Re: dexed-ide v3.9.13
On Monday, 11 October 2021 at 06:58:18 UTC, Basile B. wrote: [...] - [assets](https://gitlab.com/basile.b/dexed/-/releases). Note that the automated Windows build is still broken. Windows assets are now live [here](https://ci.appveyor.com/project/BBasile/dexed/builds/41098624/artifacts).
Re: Gordon programming language
On Sunday, 24 October 2021 at 10:13:14 UTC, Tero Hänninen wrote: Hello, decided I'd post about my primarily D-influenced programming language here. Nice work. It's data oriented, compact and despite D's influence, has a very different personality with no emphasis on metaprogramming – albeit having simple polymorphism and even compile time execution. Stability is something I care about deeply so you can expect few to no deprecations over time after some initial instability perhaps. Feature set is not large and I'm not willing to add a whole lot of "cool" convenience features besides what there already is, and there is no support for either OO or functional style programming. However, I'm rather open to adding features that unlock great performance benefits, such as intrinsics support. Support for LLVM intrinsics should be indeed of a great value added. That could work by adding a new attribute with a string exp to recognize it. without that the oprations that are done in the FPU can only be based on assembly and less inlinable. The module system is similar to Rust and works nicely with conditional compilation in that you can exclude entire modules and directories and, unlike in Rust, use conditional symbols that are automatically visible to all submodules. The compiler frontend is about 34k lines of code, self hosting and very fast. LLVM is the backend, but with the MIR used in the compiler, it's fairly straight forward to bolt on other backends. Congrats for reaching self-hosting. Once thing I notice is that there does not seem to be a way to generate debug info. You really should support them (LLVM C api has a whole header with everything you need to achieve that), because not only this allows to debug the compiler more easily but also can be used to easily instrument code in a generic way. With debug info, you can of course debug but also profile (valgrind --tool=calgrind), find leaks (valgrind), cover (kcov), etc. Compiler source code: https://github.com/tjhann/gordon Website: https://tjhann.github.io/gordon-web/ I don't know how to make websites... and I want a much lighter background actually. Take a look! :)
Re: styx, a programming languange written in D, is on the bootstrap path
On Friday, 15 January 2021 at 09:54:59 UTC, Ola Fosheim Grøstad wrote: On Thursday, 14 January 2021 at 17:51:51 UTC, Basile B. wrote: This is the last[1] occasion to speak about a programming language initiatly made in D, as the bootstrap phase is very near. Interesting project! How did you move from D to Styx? (I assume bootstrapping means a self hosting compiler?) Did you write some scripts to translate? It turns out that finally everything was translated manually. This was a bit painful but also an opportunity to review older parts and to change a details that otherwise would not have been done.
Re: styx, a programming languange written in D, is on the bootstrap path
On Monday, 18 January 2021 at 18:03:12 UTC, IGotD- wrote: On Thursday, 14 January 2021 at 17:51:51 UTC, Basile B. wrote: This is the last[1] occasion to speak about a programming language initiatly made in D, as the bootstrap phase is very near. I'd like to thank the D compiler developers, that let me work on DMD even if I borrow another path. [1] : https://gitlab.com/styx-lang/styx Interesting project. A few questions. I see that you use "var auto name" in order to automatically infer the type. Would it be possible just using "var name" for that, similar to other popular languages. There is currently no information about memory management, is this something you have an idea how to design right now? It has a memory management system very comparable to older Delphi (<= 2007) or current FreePascal. So dynamic arrays are reference counted and automatically managed when used a local var. Classes and structures are manually managed but the dtor is automatically called when the instance is a local. This system is proven to work as the compiler itself is now rewritten in styx. (example, the valgrind report after running the compiler with the equivalent of D "-unittest" CLI option : https://gitlab.com/styx-lang/styx/-/jobs/1980055910#L110. To be honest I already knew it will work before implementing ref counting. This has been used for something like 30 years by hundreds and hundreds of programmers.
Re: styx, a programming languange written in D, is on the bootstrap path
On Sunday, 16 January 2022 at 18:53:45 UTC, Brian Callahan wrote: I was able to make a quick port to OpenBSD; works fine there too. Thanks for your work on this! ~Brian holly s**t ! I'm a bit surprised that it works, especially because of the way linking is done.
Re: Beta 2.099.0
On Tuesday, 15 February 2022 at 13:06:47 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.099.0 release, ♥ to the 99 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.099.0.html As usual please report any bugs at https://issues.dlang.org -Martin Issue 3 is wrongly [referenced]. I will not create a bugzilla entry because I think this is not fixable [referenced]: https://dlang.org/changelog/2.099.0.html#bugfix-list
Re: Beta 2.099.0
On Tuesday, 15 February 2022 at 16:12:25 UTC, Iain Buclaw wrote: On Tuesday, 15 February 2022 at 13:27:18 UTC, Basile B. wrote: On Tuesday, 15 February 2022 at 13:06:47 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.099.0 release, ♥ to the 99 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.099.0.html As usual please report any bugs at https://issues.dlang.org -Martin Issue 3 is wrongly [referenced]. I will not create a bugzilla entry because I think this is not fixable [referenced]: https://dlang.org/changelog/2.099.0.html#bugfix-list Maybe an issue could be raised against the [dlang-bot](https://github.com/dlang/dlang-bot) to request better handling of ambiguous commit messages? Yes but in the meantime I find strange that you have just approved a PR that will have the same effect [with issue 2]. [with issue 2]: https://github.com/dlang/dmd/pull/13663
Dexed-ide 3.9.18
This update allows to open makefiles as language-agnostic projects. For example The sortcut for "Compile project" will have the same effect as make -f Not very interesting for D one would say, however as this feature is useful for another of my project that addition gives strong guarantees that dexed will not be abandoned. Otherwise the release comes with a few fixes: - The lack of maintenance of dparse lead to use a derived Parser class to fix crashes that can happen with incomplete code. - Projects groups and workspace persistence was broken - Packagers wont have to deal with my old, unmaintained "iz" D library. Links: - [release](https://gitlab.com/basile.b/dexed/-/releases) - [homepage](https://gitlab.com/basile.b/dexed)
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote: I submitted DIP1044, "Enum Type Inference", to Walter and Atila on April 1. I received the final decision from them on April 18. They have decided not to accept this proposal. [...] While I was rather "pro" I think that D lacked an absolute necessity for that. As explained earlier on IRC, enum type inference is also very intersting when the language has a bitfield type based on an enum, like the `Set Of` pascal construct, which makes enum member something really commonly used, much more than in D.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Thursday, 27 April 2023 at 00:16:10 UTC, Walter Bright wrote: This also works: alias F = MySuperLongNameFlag; auto flag = F.A | F.B | F.C | F.D; set_flags(F.A | F.B | F.C | F.D); It's similar to setting a local variable to some complex expression, just so you don't have to repeat that expression multiple times. It's a misconception of the problem that the DIP tried to solve. What the DIP tried to solve is that the compiler should know that you are using an enum member. Actually I even think this should work without any special syntax, as a "last resort", let's say. But as you've explained, through Mike's report, this causes problems for D because the identifier resolution is tied to a particular implementation, i.e your fast symtabs.
Re: Beta 2.104.0
On Tuesday, 2 May 2023 at 08:47:35 UTC, Iain Buclaw wrote: On Tuesday, 2 May 2023 at 03:08:00 UTC, zjh wrote: On Tuesday, 2 May 2023 at 00:34:45 UTC, Iain Buclaw wrote: Glad to announce the first beta for the 2.104.0 release, ♥ to the 36 contributors. [104](https://dlang.org/changelog/2.104.0.html) ```d alias Tint = int; @Tint void f(); ``` Here says not to use basic types as attributes, but the following example give it another basic type? ```d @int void f(); ``` The keyword here in the changelog is: **would**; that is to say, the compiler previously rejected basic types, but now they are accepted. It was already allowed to put types in UDAs, but the parser would reject basic types written directly, requiring the use of an alias. I'll have a think about how that entry could be rephrased to avoid confusion, though you are welcome to raise your own pull request to clarify the wording. That's a half baked change, it would have been better to go a bit further: previously ```d alias Tint = int; @Tint void f(); ``` now ```d @int void f(); ``` nice. But previously ```d alias Tint = int; @Tint(1) void f(); ``` now ```d @int(1) void f(); // Not Good ``` that's unfortunately still an error.
Re: Release D 2.073.0
On Sunday, 22 January 2017 at 17:55:03 UTC, Martin Nowak wrote: Glad to announce D 2.073.0. This release comes with a few phobos additions, new -mcpu=avx and -mscrt switch, and several bugfixes. http://dlang.org/download.html http://dlang.org/changelog/2.073.0.html -Martin Thanks for this release and especially for having handled the new regressions.
D IDE Coedit - version 3 beta 3
This would probably have been a RC or even the final version if I hadn't to wait for the development platform I use to reach its next milestone, which may not happen before the next spring, so another beta is worth. All important information, links and other downloads are here: https://github.com/BBasile/Coedit/releases/tag/3_beta_3 You can report any problem here: https://github.com/BBasile/Coedit/issues If you have questions, exactly today, I'll probably be there: irc://irc.freenode.net/d as "DotBatch"
Re: D IDE Coedit - version 3 beta 3
On Saturday, 28 January 2017 at 22:18:52 UTC, dminded wrote: On Friday, 27 January 2017 at 04:48:56 UTC, Basile B. wrote: This would probably have been a RC or even the final version if I hadn't to wait for the development platform I use to reach its next milestone, which may not happen before the next spring, so another beta is worth. All important information, links and other downloads are here: https://github.com/BBasile/Coedit/releases/tag/3_beta_3 You can report any problem here: https://github.com/BBasile/Coedit/issues If you have questions, exactly today, I'll probably be there: irc://irc.freenode.net/d as "DotBatch" I am new to dlang and wanted to try out Coedit. But it does not run on my platform... I tried the zip archive and the installer for the 64-bit version. I am running Linux Mint 18 Cinnamon x86_64. Running "coedit" will log me out of the current session!? Any idea whats going on? Yes. 1/ Do you have a proper GTK2 runtime environment ? Try to verify with this command: pkg-config --modversion gtk+-2.0 2/ If you replace dastworx by this new version, does it still crash ? new version: https://github.com/BBasile/Coedit/releases/download/3_beta_3/dastworx.linux.x86_64.zip 3/ You can try to log the output by launching from a console: coedit > cecession.txt Do 1/ Do 2/, if it still crashes then do 3/
Re: D IDE Coedit - version 3 beta 3
On Sunday, 29 January 2017 at 01:06:32 UTC, dminded wrote: On Saturday, 28 January 2017 at 23:55:58 UTC, Basile B. wrote: On Saturday, 28 January 2017 at 22:18:52 UTC, dminded wrote: On Friday, 27 January 2017 at 04:48:56 UTC, Basile B. wrote: This would probably have been a RC or even the final version if I hadn't to wait for the development platform I use to reach its next milestone, which may not happen before the next spring, so another beta is worth. All important information, links and other downloads are here: https://github.com/BBasile/Coedit/releases/tag/3_beta_3 You can report any problem here: https://github.com/BBasile/Coedit/issues If you have questions, exactly today, I'll probably be there: irc://irc.freenode.net/d as "DotBatch" I am new to dlang and wanted to try out Coedit. But it does not run on my platform... I tried the zip archive and the installer for the 64-bit version. I am running Linux Mint 18 Cinnamon x86_64. Running "coedit" will log me out of the current session!? Any idea whats going on? Yes. 1/ Do you have a proper GTK2 runtime environment ? Try to verify with this command: pkg-config --modversion gtk+-2.0 2/ If you replace dastworx by this new version, does it still crash ? new version: https://github.com/BBasile/Coedit/releases/download/3_beta_3/dastworx.linux.x86_64.zip 3/ You can try to log the output by launching from a console: coedit > cecession.txt Do 1/ Do 2/, if it still crashes then do 3/ Thank you. I got it working and Hello World compiles and runs :D. ... I followed the 'Setup program' instructions, but skipped the important point above the heading: "In all the cases, the DMD D2 compiler must setup and its location has to match to one of the directory of the PATH environment variable.". I only had ldc2 installed. After installing dmd coedit did work. After playing around a bit i noticed, that something is wrong with the project management. While the single Hello world compiles and runs, I can not compile a project. i get the following messages: - compiling - has been successfully compiled - output executable missing: /tmp/app I found the compiled 'app' file next to the coedit executable. Also the 'project inspector' seems not to work. When i add files, they are not listed there. Something seems not to be setup properly on my machine. I'm on IRC right now. Communication on the forum is really painfull, it looks like I need to explain a few things. Also you can ask questions on the bugtracker, although it's the same problem as here (not real time...).
Re: D IDE Coedit - version 3 beta 3
On Monday, 30 January 2017 at 23:32:12 UTC, dminded wrote: Ok, the debugger also works if i write a bit more then just a 'writeln' into main. How can i set breakpoints? If i click on the left side of a row, a little red dot appears. This means that GDB cannot set the breakpoint. checkout options/debugger to enable all the options starting with "show..." You'll get the raw GDB output in the messages and you'll see what happens under the hood when you click in the gutter. But the debugger seems to ignore it and instead every statement is a breakpoint. I also can not find a "step out of function" button. Commands that are not in the toolbar can be typed in the field at the bottom. So check out the manual an for the MI syntax to do this and type it. Normally all break reasons are handled by the interpreter.
Re: D IDE Coedit - version 3 beta 3
On Monday, 30 January 2017 at 19:45:38 UTC, dminded wrote: On Sunday, 29 January 2017 at 02:56:53 UTC, Basile B. wrote: I'm on IRC right now. Communication on the forum is really painfull, it looks like I need to explain a few things. Also you can ask questions on the bugtracker, although it's the same problem as here (not real time...). Seems we live in different time zones, i could not find you on the chat. I got the project management to work, by creating a project with the coedit native format. Seems my trouble did come from trying to open/creating dub projects. DUB projects are well handled: http://bbasile.github.io/Coedit/widgets_dub_project_editor - the project file must be saved after each important modifications. - the "update" button must be clicked if you saved a source in one of the folder that's auto detected (e.g "src") or one of the item in "sourcePaths", so that the project inspector is notified of new sources. I think that it's a matter of habits since I use DUB projects some time to time I'd detected major issues.
Re: D IDE Coedit - version 3 beta 3
On Tuesday, 31 January 2017 at 07:23:24 UTC, Basile B. wrote: On Monday, 30 January 2017 at 23:32:12 UTC, dminded wrote: Ok, the debugger also works if i write a bit more then just a 'writeln' into main. How can i set breakpoints? If i click on the left side of a row, a little red dot appears. This means that GDB cannot set the breakpoint. checkout options/debugger to enable all the options starting with "show..." You'll get the raw GDB output in the messages and you'll see what happens under the hood when you click in the gutter. But the debugger seems to ignore it and instead every statement is a breakpoint. I also can not find a "step out of function" button. Commands that are not in the toolbar can be typed in the field at the bottom. So check out the manual an for the MI syntax to do this and type it. Normally all break reasons are handled by the interpreter. By the way there can be a syncronization issue between the breakpoint database and the editor cache (both store the breakpoints). In this case open /home//.config/Coedit/breakpoints.txt and delete the right item. For example now mine is object TPersistentBreakPoints items = < item filename = '/home/basile/Dev/dproj/kheops/runnable/default_alignment.d' line = 187 kind = bpkBreak end item filename = '/home/basile/Dev/dproj/kheops/runnable/default_alignment.d' line = 191 kind = bpkBreak end> end let's say that the second break is invalid: object TPersistentBreakPoints items = < item filename = '/home/basile/Dev/dproj/kheops/runnable/default_alignment.d' line = 187 kind = bpkBreak end> end _ Also don't miss the cool feature: runnables modules can be debugged. In the toolbar there's a menu attached to the "power switch" icon. You can select in this menu if GDB has to start the runnable for the source that has the focus or the project. _ GDB commander doc is not yet written.
Re: unDE 0.2.0 - unusual command line and keybar
On Sunday, 29 January 2017 at 19:00:30 UTC, unDEFER wrote: unDE's not DE which in the future must be replacement for all programs in OS. But today is very original file manager, image and text viewer and (what discovered with 0.2.0 version) command line and keybar. More information: http://unde.sourceforge.net/en/ch25.html Video with English subtitles: https://youtu.be/XY7Jegxq6vg What is the name of the static lib we have to install for for "DB" ? /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: ne peut trouver -ldb collect2: error: ld returned 1 exit status Error: linker exited with status 1
Re: unDE 0.2.0 - unusual command line and keybar
On Friday, 3 February 2017 at 13:48:39 UTC, Basile B. wrote: On Sunday, 29 January 2017 at 19:00:30 UTC, unDEFER wrote: unDE's not DE which in the future must be replacement for all programs in OS. But today is very original file manager, image and text viewer and (what discovered with 0.2.0 version) command line and keybar. More information: http://unde.sourceforge.net/en/ch25.html Video with English subtitles: https://youtu.be/XY7Jegxq6vg What is the name of the static lib we have to install for for "DB" ? /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: ne peut trouver -ldb collect2: error: ld returned 1 exit status Error: linker exited with status 1 Isee it's BDB, never mind but now on OpenSuse I got a SEGFAULT during BDB init ~"#0 0x in ?? ()\n" #0 0x in ?? () ~"#1 0x0071ee68 in berkeleydb.dbenv.DbEnv.set_memory_max(uint, uint) (this=0x77ec5100, bytes=16777216, gbytes=0) at ../../../.dub/packages/bdb2d-5.3.28/bdb2d/source/berkeleydb/dbenv.d:757\n" ~"#2 0x0071ef20 in berkeleydb.dbenv.DbEnv.set_memory_max(ulong) (this=0x77ec5100, bytes=16777216) at ../../../.dub/packages/bdb2d-5.3.28/bdb2d/source/berkeleydb/dbenv.d:765\n" ~"#3 0x0065a636 in unde.global_state.GlobalState.__mixin109.initBDB(bool) (this=0x76571000, force_recover=false) at source/unde/global_state.d:117\n" ~"#4 0x0065baf8 in unde.global_state.GlobalState.this(bool) (this=0x76571000, force_recover=false) at source/unde/global_state.d:972\n" ~"#5 0x006f16d6 in D main (args=...) at source/unde/main.d:25\n" auto ret = dbenv.set_memory_max(dbenv, gbytes, bytes);
Re: unDE 0.2.0 - unusual command line and keybar
On Friday, 3 February 2017 at 14:05:58 UTC, Basile B. wrote: On Friday, 3 February 2017 at 13:48:39 UTC, Basile B. wrote: On Sunday, 29 January 2017 at 19:00:30 UTC, unDEFER wrote: unDE's not DE which in the future must be replacement for all programs in OS. But today is very original file manager, image and text viewer and (what discovered with 0.2.0 version) command line and keybar. More information: http://unde.sourceforge.net/en/ch25.html Video with English subtitles: https://youtu.be/XY7Jegxq6vg What is the name of the static lib we have to install for for "DB" ? /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: ne peut trouver -ldb collect2: error: ld returned 1 exit status Error: linker exited with status 1 Isee it's BDB, never mind but now on OpenSuse I got a SEGFAULT during BDB init ~"#0 0x in ?? ()\n" #0 0x in ?? () ~"#1 0x0071ee68 in berkeleydb.dbenv.DbEnv.set_memory_max(uint, uint) (this=0x77ec5100, bytes=16777216, gbytes=0) at ../../../.dub/packages/bdb2d-5.3.28/bdb2d/source/berkeleydb/dbenv.d:757\n" ~"#2 0x0071ef20 in berkeleydb.dbenv.DbEnv.set_memory_max(ulong) (this=0x77ec5100, bytes=16777216) at ../../../.dub/packages/bdb2d-5.3.28/bdb2d/source/berkeleydb/dbenv.d:765\n" ~"#3 0x0065a636 in unde.global_state.GlobalState.__mixin109.initBDB(bool) (this=0x76571000, force_recover=false) at source/unde/global_state.d:117\n" ~"#4 0x0065baf8 in unde.global_state.GlobalState.this(bool) (this=0x76571000, force_recover=false) at source/unde/global_state.d:972\n" ~"#5 0x006f16d6 in D main (args=...) at source/unde/main.d:25\n" Also before that there's two FileException thrown because you use mkdir() systematically with a silent try catch. You should rather test if the the directories exist (when you create ~/.unde/ and ~/.unde/bdb/, global_state.d) because it tends to be annoying when trying to get that stack trace for the real exception !
Re: D IDE Coedit - version 3 beta 3
On Monday, 30 January 2017 at 23:32:12 UTC, dminded wrote: Ok, the debugger also works if i write a bit more then just a 'writeln' into main. How can i set breakpoints? If i click on the left side of a row, a little red dot appears. But the debugger seems to ignore it and instead every statement is a breakpoint. I also can not find a "step out of function" button. I was writing the manual page for the debugger then I remembered your Q. I bet that you used to wrong toolbar icon. ▷: is for resuming (e.g until next breakpoint/watchpoint/signal) ↓: is for stepping. (http://bbasile.github.io/Coedit/widgets_gdb_commander) If you stepped it's normal that it broke at each line ;]
Re: D IDE Coedit - version 3 beta 3
On Friday, 27 January 2017 at 04:48:56 UTC, Basile B. wrote: This would probably have been a RC or even the final version if I hadn't to wait for the development platform I use to reach its next milestone, which may not happen before the next spring, so another beta is worth. All important information, links and other downloads are here: https://github.com/BBasile/Coedit/releases/tag/3_beta_3 You can report any problem here: https://github.com/BBasile/Coedit/issues If you have questions, exactly today, I'll probably be there: irc://irc.freenode.net/d as "DotBatch" Yet another update...should be of interest for those who tried D for the first time, using CE and experienced a crash https://www.reddit.com/r/d_language/comments/5t5oum/d_ide_coedit_version_3_beta_4/
Typed D allocator based on jemalloc
Nothing huge here. The package[0] provides the bindings, JEMallocator (like Mallocator) and JEAlignedAllocator (like AlignedAllocator). All of them use jeallocator[1], which is actually the default implementation of malloc in the FreeBSD system. In a future update I may add another D alloc which would be specific to each thread. Another allocator, tcmallocd[2] already does this. [0] http://code.dlang.org/packages/jemallocd [1] https://github.com/jemalloc/jemalloc [2] http://code.dlang.org/packages/tcmallocd
D IDE Coedit - version 3 released.
Finally, after four betas, the third version of my D IDE [0] is available. The change log for this new version quite important. Major additions: - GDB commander, a GDB UI, only under linux. - Project groups. - Compiler paths, defines and select several D compilers. Picked among the other additions: - support for the DUB scripts (in addition to my runnable module system). - support for DUB SDL projects in read-only mode. - Halstead metrics for D. But there is really much more [1]. As usual, I provide binaries for linux and Windows. [0]: https://github.com/BBasile/Coedit [1]: https://github.com/BBasile/Coedit/releases/tag/3_gold
Re: D IDE Coedit - version 3 released.
On Wednesday, 15 March 2017 at 22:09:07 UTC, aberba wrote: On Monday, 13 March 2017 at 17:43:32 UTC, Basile B. wrote: Finally, after four betas, the third version of my D IDE [0] is available. Good Intellescense is the only missing piece for me. - IDE-grade features are provided by DCD, so they are standard (to the extent that most of the editor plugins and other IDEs use it). - Static analysis (Dscanner) must be launched by hand and results are displayed in the messages. I assume you'd like more to have waves under the matching tokens. Why not. - Grammar errors are displayed in the symbol list, shortly after the last keystroke (depending on the settings). It works like this because when the AST is retrieved, errors are found too. Here I also assume you'd like more to have red waves under the tokens. I think that the error text is more useful. - Very few syntactical errors are displayed (numbers only). They could be retrieved with the AST and the grammar errors unfortunately a small flaw in libdparse prevents this (https://github.com/Hackerpilot/libdparse/issues/109). Plus UI theme. This will never be done. But this is clearly a recurring remark, not to say that it appears at each new release. The UI theme is managed by the OS. In the 2000's, during the Windows XP golden years the uxtheme.dll could be patched and there was tons of user-made theme that changed the native UI elements...Unforunately I don't think it exists anymore. Under linux you can have a dark UI: http://imgur.com/a/ubeLq
Re: sdpc - Simple/Stupid D parser combinator
On Thursday, 23 March 2017 at 22:55:10 UTC, Yuxuan Shui wrote: GitLab: https://gitlab.com/yshui/sdpc Documents: https://yshui.gitlab.io/sdpc Dub: http://code.dlang.org/packages/sdpc I started this project ~1.8 years ago. It only took me a couple of weeks to write, and I learned a lot about D's template system (and its limitations) by writing it. But back then I wasn't confident with the code quality and documentation enough to make it public. Then life caught up with me and I can't spend time on it. Recently I finally got some time and decided to cleanup the code and make it available to more people. Now I'm comfortable with it enough to have more eyes on it. sdpc is a very simple parser combinator library. So it lacks some bells and whistles like left recursion or memoization. But it should be able to handle a lot of the simpler use cases. (I know we have pry now. A bit of competition won't hurt =] ). Thanks for sharing this but your project is not visible! Gitlab is a bit confusing because by default repositories are private. Go to your project setting(should be https://gitlab.com/yshui/sdpc/edit): - set "Project Visibility" to "public". - set "Repository" to "everyone with access".
Re: dmd Backend converted to Boost License
On Friday, 7 April 2017 at 15:14:40 UTC, Walter Bright wrote: https://github.com/dlang/dmd/pull/6680 Yes, this is for real! Symantec has given their permission to relicense it. Thank you, Symantec! Good news. Question: Does this apply from now or can the previous DMD releases also be considered as 100% Boost licensed ?
Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator
On Sunday, 9 April 2017 at 08:56:52 UTC, Atila Neves wrote: Using std.experimental.allocator? Tired of writing `scope(exit) allocator.dispose(foo);` in a language with RAII? Me too: http://code.dlang.org/packages/automem I think that the Array misses - a reservation strategy, something like reserve() and allocBy(). - dup / idup that return new distinct and deep copies. - maybe .ptr at least for reading with pointer arithmetic. - opBinary for "~" . Also you have bugs with operators: ```d import std.experimental.allocator.mallocator; UniqueArray!(int, Mallocator) a; a ~= [0,1]; ``` crashes directly.
Re: Update roll-up on my arsd libraries
On Thursday, 13 April 2017 at 16:04:18 UTC, Adam D. Ruppe wrote: I haven't posted in announce for a while, so I figured I'd give you guys an update on what's been happening in my libs. This message is a big long, so feel free to just skim to see if you are interested in anything. [...] * simpledisplay.d has gotten a LOT of work lately. Thanks particularly for this one, which is certainly a reference about how to use the nightmare-ish X11 API in D.
D IDE Coedit - released version 3 update 1
Hello, The latest major release does not contain any critical issue known at this day so this is a minor update that brings a few improvements mostly related to the edition: DDOC and completion (including an automatic mode, as suggested many times after latest release). - Changelog and dolwonad links: https://github.com/BBasile/Coedit/releases/tag/3_update_1 - Homepage: https://github.com/BBasile/Coedit - Manual:http://bbasile.github.io/Coedit/
Re: DMD now has colorized syntax highlighting in error messages
On Sunday, 14 May 2017 at 17:54:38 UTC, Jacob Carlborg wrote: On 2017-05-14 18:25, Walter Bright wrote: 1. print out the offending line I hope this one will be optional/configurable. I don't think it necessary to print the offending line within an editor/IDE. They usually can already map the error to the offending line. Yes +1 for configurable. IDEs already parse and make things clickable. It's not just +1, it's mandatory. If you implement this you must add a new compiler switch.
Re: DMD now has colorized syntax highlighting in error messages
On Sunday, 14 May 2017 at 23:17:42 UTC, Vladimir Panteleev wrote: On Sunday, 14 May 2017 at 19:11:32 UTC, Basile B. wrote: Yes +1 for configurable. IDEs already parse and make things clickable. It's not just +1, it's mandatory. If you implement this you must add a new compiler switch. No problem, it could only print out the line if the output is a terminal, same as for how it decides whether to output colors by default. Yes that another option. But maybe my answer was a bit excessive. Let's wait and see how it looks.
Harbored-mod 0.2.1 and DYaml 0.6.1 at dlang-community
Following Brian Schott Announce [1] about the migration of his projects to the dlang-community, I'm pleased to announce that the most popular repository from Ferdinand Majerech are now also hosted there. - D-YAML, a YAML parser and emitter for D (native D implementation) is at https://github.com/dlang-community/D-YAML - harbored-mod, a D documentation generator based on harbored is at https://github.com/dlang-community/harbored-mod So far we pushed the commits done in several forks and the two projects are up to date, tested by TravisCI, buildable with either make or DUB. Note about D-Yaml: People who forked D-Yaml for their projects are encouraged to push their change to dlang-community and give up their fork ! [1]: http://forum.dlang.org/post/abbprxuwgqlmuuwdf...@forum.dlang.org
Re: Harbored-mod 0.2.1 and DYaml 0.6.1 at dlang-community
On Tuesday, 16 May 2017 at 20:46:44 UTC, Basile B. wrote: Following Brian Schott Announce [1] about the migration of his projects to the dlang-community, I'm pleased to announce that the most popular repository from Ferdinand Majerech are now also hosted there. - D-YAML, a YAML parser and emitter for D (native D implementation) is at https://github.com/dlang-community/D-YAML - harbored-mod, a D documentation generator based on harbored is at https://github.com/dlang-community/harbored-mod So far we pushed the commits done in several forks and the two projects are up to date, tested by TravisCI, buildable with either make or DUB. Note about D-Yaml: People who forked D-Yaml for their projects are encouraged to push their change to dlang-community and give up their fork ! [1]: http://forum.dlang.org/post/abbprxuwgqlmuuwdf...@forum.dlang.org BTW, forgot to say: thanks to Ferdinand for giving the ownership to the organization and thanks to those who continued to maintain the forks, notably Sociomantic D developers for harbored-mod and ZombineDev for D-YAml.
Re: Faster Command Line Tools in D
On Thursday, 25 May 2017 at 22:04:36 UTC, Ali Çehreli wrote: On 05/24/2017 06:39 AM, Mike Parker wrote: Reddit: https://www.reddit.com/r/programming/comments/6d25mg/faster_command_line_tools_in_d/ Inspired Nim version, found on Reddit: https://www.reddit.com/r/programming/comments/6dct6e/faster_command_line_tools_in_nim/ Ali Wow, the D blog post opened Pandora's box.
D IDE Coedit, version 3 update 2 released
Very small update. The Changes won't be noticeable unless you're an hardcore user like me. https://github.com/BBasile/Coedit/releases/tag/3_update_2 https://github.com/BBasile/Coedit off topic: == I've recently discovered that CE downloads for linux are now more important than Windows's one. For example if you look at the "3_gold" count on this page: http://www.somsubhra.com/github-release-stats/?username=BBasile&repository=Coedit, there are about 1000 dls for linux vs 500 for Windows ! Times change.
Re: D IDE Coedit, version 3 update 2 released
On Friday, 2 June 2017 at 07:24:02 UTC, Basile B. wrote: Very small update. The Changes won't be noticeable unless you're an hardcore user like me. https://github.com/BBasile/Coedit/releases/tag/3_update_2 https://github.com/BBasile/Coedit off topic: == I've recently discovered that CE downloads for linux are now more important than Windows's one. For example if you look at the "3_gold" count on this page: http://www.somsubhra.com/github-release-stats/?username=BBasile&repository=Coedit, there are about 1000 dls for linux vs 500 for Windows ! Times change. Sorry but i've forgotten to remove a SLOC written for debugging: https://github.com/BBasile/Coedit/commit/5fc8ea57b34e91e31e901559e40f8ddd74cec873#diff-3fccc6fc5d25b2ff883979f6bfcd04adR2624 Gotta update everything (Sh*t).
Re: D IDE Coedit, version 3 update 2 released
On Friday, 2 June 2017 at 10:03:25 UTC, Basile B. wrote: On Friday, 2 June 2017 at 07:24:02 UTC, Basile B. wrote: Times change. Sorry but i've forgotten to remove a SLOC written for debugging: https://github.com/BBasile/Coedit/commit/5fc8ea57b34e91e31e901559e40f8ddd74cec873#diff-3fccc6fc5d25b2ff883979f6bfcd04adR2624 Gotta update everything (Sh*t). Done. Unfortunately anyone who's updated during the last 4 hours has to reinstall. If not what will happen is that you'll get an exception after pressing ENTER inside a DDOC comment and if an option is activated to auto insert leading */+s.
Re: DCD 0.9.0 released
On Monday, 3 July 2017 at 12:39:16 UTC, Nordlöw wrote: Nice. Are there any plans on adding any (limited) kind of auto-completion of UFCS-calls? I think that you have the answer https://github.com/dlang-community/DCD/issues/13. Now that i read my proposal again i have to say that i don't like it anymore. Since i started to be involved i'll look how hard it would be to do but since Hackerpilot didn't implement the feature i bet there must be a kind of problem with that.
D IDE Coedit - version 3, update 3 released
Better integration of D-Scanner. D-Scanner binary is itself included from now, in addition to DCD. See https://github.com/BBasile/Coedit/releases/tag/3_update_3 for the download links and a complete changelog.
Re: D IDE Coedit - version 3, update 3 released
On Saturday, 15 July 2017 at 23:37:51 UTC, Gunther Klawa wrote: On Friday, 14 July 2017 at 06:10:08 UTC, Basile B. wrote: Better integration of D-Scanner. D-Scanner binary is itself included from now, in addition to DCD. See https://github.com/BBasile/Coedit/releases/tag/3_update_3 for the download links and a complete changelog. I have no idea what strange versions of dcd-server you always include in your Windows packages, but everytime avast! behaviour detection deletes them which doesn't happen to my self compiled ones. Nothing special about it. Build with DMD 2.074.1. I think that it's the setup program that triggers avast. To be sure download the zip file (the one that doesn't have "setup" in the file name) and extract. I bet avast won't complain. By the way you can build the setup program yourself. I bet you'll also have the fake heuristic detection. See https://github.com/BBasile/Coedit/tree/master/cesetup.
Re: D IDE Coedit - version 3, update 3 released
On Sunday, 23 July 2017 at 06:01:23 UTC, Alonso Cárdenas wrote: On Friday, 14 July 2017 at 06:10:08 UTC, Basile B. wrote: Better integration of D-Scanner. D-Scanner binary is itself included from now, in addition to DCD. See https://github.com/BBasile/Coedit/releases/tag/3_update_3 for the download links and a complete changelog. Hi Basile I have added Coedit to FreeBSD ports tree. Look it at http://www.freshports.org/editors/coedit/. Maybe you could add some entry about that on Coedit webpage Greetings Thanks. I'll maybe add a paragraph for the 3rd part packages. There's another one (for ArchLinux). I can read Configuration Options ===> The following configuration options are available for coedit-3.u.3_1: > Options available for the single LCL: you have to select exactly one of them GTK2=on: Use gtk20 interface QT4=off: Use qt4 interface ===> Use 'make config' to modify these settings What does that mean exactly ? Do you propose to the user to build Coedit themselves with optionally the QT interface ?
Re: D IDE Coedit - version 3, update 3 released
On Sunday, 23 July 2017 at 19:11:24 UTC, Alonso Cárdenas wrote: On Sunday, 23 July 2017 at 18:10:25 UTC, Basile B. wrote: [...] What does that mean exactly ? Do you propose to the user to build Coedit themselves with optionally the QT interface ? Yes, I do. Coedit can be compiled with gtk2 or qt4 interface from FreeBSD ports. For the while just one of them can be selected. I'm thinking split lazarus based ports to app-gtk2 and app-qt4 respectively (It will generate binary packages too on FreeBSD package servers). Maybe after of lazarus 1.8 release. Take care because i don't plan to support Lazarus 1.8 to build Coedit. It's 1.6.4 only. The coming version breaks things in my software.
Re: static foreach is now in github master
On Monday, 17 July 2017 at 18:14:35 UTC, Andrei Alexandrescu wrote: For those who want to play with our new static foreach feature and are willing to take the steps to building their own dmd, the feature is now merged in master: https://github.com/dlang/dmd/pull/6760 Happy hacking! Andrei I cant find the matching dlang.org pull request. The one that specifies the changes applied to the grammar.
Re: D IDE Coedit - version 3, update 3 released
On Friday, 25 August 2017 at 04:29:51 UTC, user1234 wrote: On Friday, 14 July 2017 at 06:10:08 UTC, Basile B. wrote: Better integration of D-Scanner. D-Scanner binary is itself included from now, in addition to DCD. See https://github.com/BBasile/Coedit/releases/tag/3_update_3 for the download links and a complete changelog. update 4 is available too: indeed. https://github.com/BBasile/Coedit/releases/tag/3_update_4 mostly fixes at first glance. ~~mostly~~ only.
Re: D as a Better C
On Friday, 25 August 2017 at 09:50:39 UTC, Suliman wrote:
On Friday, 25 August 2017 at 08:54:02 UTC, Kagamin wrote:
On Thursday, 24 August 2017 at 19:09:58 UTC, Parke wrote:
What is "intermediate D"?
D with minimal runtime.
How to pass to dub -betterC flag?
{
...
"dflags" : ["betterC"],
...
}
