Re: Rust's simple download script
On Tue, Nov 10, 2015 at 6:56 PM, Steven Schveighoffer via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > > I've been using dvm, and do like it a lot. But I couple issues: > > 1. Every time I type dvm use, my path adds another directory. Couldn't you > just replace the existing dvm path? > 2. Every incorrect command given to dvm results in a stack trace. > > Otherwise, I thoroughly enjoy being able to switch/install compiler > versions on a whim. > > -Steve > I don't use DVM but I do switch compilers fairly easily with: rm /usr/local/dmd/current; ln -s /usr/local/dmd/2.069.0; To install a new compiler I just download the latest .tar.xz and place in /usr/local/dmd/; and then rename "dmd2" directory to version number. Didn't see anyone else post a similar install process. It obviously doesn't have to be installed system wide, I just don't really like installed executables to be writeable by my own user. A bash script based installer for the system I use would be very short and simple.
Re: Deprecating Allocating Functions In std.string
On Thu, Nov 5, 2015 at 2:02 AM, Jonathan M Davis via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > > We've been adding lazy versions of functions for years now, and we've > never removed the eager versions. And I'm pretty sure that Walter and > Andrei have generally been opposed to the idea of doing so precisely > because of the code breakage that it causes. We have been moving towards > using lazy range-based functions as much as possible and avoiding adding > new eager functions, but that doesn't mean that removing the eager > functions is worth the pain that that causes or even that the eager > functions aren't worth having. > > - Jonathan M Davis > Surely the eager functions should at least be using the lazy version internally? "more code, more bugs" is often a true statement (not always, but often).
Re: Playing around with aliasthis
On Tue, Jan 26, 2016 at 8:20 AM, Rory via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > Hi, > > I need some help understanding dmd and I'm wondering where I should ask. > > I have made a multiple aliasthis implementation that currently only works > for structs. If I try to use a class then the compiler segfaults in . > The implementation basically just changes aggregate.aliasthis to be > aggregate.aliasthis(Type expectedType) and then that function picks a > matching aliasthis option and returns it. > > Thanks, > Rory > The segfault was because I forgot to mark one of my new methods as "final", and it was messing with the poffset in baseOf. I think this is relevant to anyone mixing D and C++, not sure if its for everyone because I'm not sure where poffset comes from. Basically if a struct works and a class causes the compiler to segfault in baseOf when compiling your module, its probably this.
Re: DMD front-end can be used as a library with Dub
I didn't see your announcement, but... AWESOME!!
This could be the basis for some really good tutorials on making compiler
backends etc...
We need more little teaser examples like the one you posted in the
beginning of this thread.
PS: I did already check the code out on github because I watch
code.dlang.org (a lot).
Thanks!
On Mon, Aug 29, 2016 at 12:42 PM, Alexander Breckel via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> I just tried to use the DMD frontend as a Dub package in my own project to
> parse and analyze D files and it ... just worked. The dub.json for dmd is
> fairly small and doesn't require any changes to the code. This might be
> common knowledge, but I was completely unprepared for this :)
>
> Please note: This is "only" the dmd frontend (lexer, parser, semantic
> passes, CTFE). Code generation will be more complicated.
>
> The following dub pre-generation hooks were necessary:
>
> - run src/idgen.d to generate src/id.d
> - create verstr.h and SYSCONFDIR.imp
> - create and link source/ddmd/ to src/
>
> The last point makes ddmd modules reside in its correct package. I'm using
> a symbolic link for this, which is the only reason this approach is
> currently limited to Linux. In the long run, I think the cleanest way would
> be to place all ddmd files in src/ddmd/ and just leave mars.d and things
> like idgen.d in the main src/ directory.
>
> For demonstration purposes, here is a dub package to play around with:
> http://code.dlang.org/packages/ddmd-experimental
>
> Here is the dub.json that was used:
> https://github.com/aneas/ddmd-experimental/blob/master/dub.json
>
> And here is an example program using this API, have fun!
> (run with $ chmod +x file.d; ./file.d)
> ---
> #!/usr/bin/env dub
> /+ dub.sdl:
> name "ddmd-example"
> dependency "ddmd-experimental" version="~>2.71.2-b2dub"
> +/
>
> import std.path;
> import std.stdio;
> import std.string;
> import ddmd.builtin;
> import ddmd.dmodule;
> import ddmd.dclass;
> import ddmd.dsymbol;
> import ddmd.expression;
> import ddmd.func;
> import ddmd.globals;
> import ddmd.id;
> import ddmd.identifier;
> import ddmd.mtype;
> import ddmd.visitor;
>
> void main(string[] args) {
> if(args.length != 2) {
> writeln("prints top-level function and class
> declarations");
> writeln("usage: ", args[0].baseName, " d-filepath");
> return;
> }
>
> // Initialization
> global._init();
> global.params.isLinux = true;
> Type._init();
> Id.initialize();
> Module._init();
> Expression._init();
> builtin_init();
>
> // Read and parse specified module
> auto id = Identifier.idPool(args[1].baseName.stripExtension);
> auto m = new Module(args[1].toStringz, id, false, false);
> m.read(Loc());
> m.parse();
>
> // Output
> m.accept(new class Visitor {
> extern(C++):
> alias visit = Visitor.visit;
> override void visit(Module m) {
> foreach(i; 0 .. m.members.dim)
> (*m.members)[i].accept(this);
> }
> override void visit(Dsymbol s) {
> }
> override void visit(FuncDeclaration fd) {
> writeln("function ", fd.ident.toString);
> }
> override void visit(ClassDeclaration cd) {
> writeln("class ", cd.ident.toString);
> }
> });
> }
>
>
Re: DMD front-end can be used as a library with Dub
Thanks, for the GC stub, that will be great for playing with whether or not a little dmd app crashes after gc_annihilate(true). Did I understand that right? R On Thu, Sep 1, 2016 at 6:16 PM, Cauterite via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Monday, 29 August 2016 at 10:42:23 UTC, Alexander Breckel wrote: > >> >> > Because of the poor memory management in the compiler, I included a > modified GC-stub when I compiled the frontend as a library, so that it can > be used in long-running processes: > > https://gist.github.com/Cauterite/4eb74347aea040f5d371fb49054e1819 > > You can call gc_annihilate(true) to delete the entire heap. > > Obviously you need to keep the library in a separate DLL with its own > runtime, and carefully avoid holding references to GC memory across > annihilations. > > This technique is working pretty smoothly for me so far. > > Also to compile it as a DLL you either have to remove main() from mars.d > or play games with the C runtime: https://gist.github.com/Cauter > ite/b190e62891c773703d0de3a1d99df362 >
Re: CompileTime performance measurement
On Tue, Sep 6, 2016 at 7:42 PM, Stefan Koch via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Tuesday, 6 September 2016 at 10:42:00 UTC, Martin Nowak wrote: > >> On Sunday, 4 September 2016 at 00:04:16 UTC, Stefan Koch wrote: >> >>> I recently implemented __ctfeWriteln. >>> >> >> Nice, is it only for your interpreter or can we move >> https://trello.com/c/6nU0lbl2/24-ctfewrite to done? I think __ctfeWrite >> would be a better primitive. And we could actually consider to specialize >> std.stdio.write* for CTFE. >> > > It's only for the current engine and only for Strings! > See: https://github.com/dlang/druntime/pull/1643 > and https://github.com/dlang/dmd/pull/6101 > Seriously Stefan, you make my day! My libraries will be so much easier to write!
Re: Return type deduction
On Mon, Sep 5, 2016 at 11:59 AM, Andrea Fontana via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> I asked this some time (years?) ago. Time for a second try :)
>
> Consider this:
>
> ---
>
> T simple(T)() { return T.init; }
>
>
> void main()
> {
> int test = simple!int(); // it compiles
> int test2 = simple();// it doesn't
> }
>
> ---
>
> Is there any chance to implement this kind of deduction?
> Please notice that it doesn't break any existing code, I guess.
>
> For example using my json wrapper [1] this sounds a bit pedantic:
>
>
> user.name = json.get!string("info/name");
> user.age = json.get!int("info/age");
>
>
> If return type deduction could be implemented it would be:
>
>
> user.name = json.get("info/name");
> user.age = json.get("info/age");
>
>
> [1] https://code.dlang.org/packages/jsonwrap
>
> Andrea
>
user.name = json.get!(info.name);
or
user.name = json!(info.name);
possible right now. No language changes. Shorter. No strings. compile time
type verification.
limitation:
can't do runtime loading of unknown json structure (but then neither does
your proposal).
R
Re: D, ZeroMQ, Nanomsg
I also chose Ilya's nanomsg over zeromq, there were some fundamental flaws in ZMQ that it addresses, and it is more flexible. On Fri, Sep 30, 2016 at 3:42 PM, Laeeth Isharc via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Thursday, 29 September 2016 at 04:18:55 UTC, Nikolay wrote: > >> On Wednesday, 28 September 2016 at 11:53:05 UTC, Russel Winder wrote:e >> >> Has anyone wrapped Nanomsg? >>> >> >> Be aware - Nanomsg project is mostly dead now. See >> http://sealedabstract.com/rants/nanomsg-postmortem-and-other-stories/ >> > > > Nanomsg is not dead. The maintainer tried to introduce a code of conduct > (about which even he was uncertain of the merits of), felt he didn't have > the effective power to do so, and then resigned in frustration. A few > weeks later he was back and it hit 1.0 recently. > Had an exchange with Pieter on Reddit and after looking at commit > history, he took back his suggestion that Nanomsg was dead. > > It's silly to compare the two communities and make any inferences because > Nanomsg has fewer people and the originator has a job and Google and many > interests. > > There are deimos bindings that Ilya wrote for me and I open-sourced, and > a wrapper that I wrote that is also open sourced. There are some bugs in > the deimos binding - haven't yet had time to push my changes. > > The wrapper isn't super well tested but I use it. Will make it more > polished when I have more time. > > > Laeeth >
Re: Examples Wanted: Usages of "body" as a Symbol Name
On Wed, Oct 5, 2016 at 5:32 PM, angel via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Wednesday, 5 October 2016 at 02:11:14 UTC, Meta wrote:
>
>> I'm currently writing up a DIP to propose removing `body` as a keyword to
>> allow it to be used for variable names, functions, etc. I'm looking for
>> examples and contexts where `body` would normally be used as a variable,
>> function name, alias, etc. This is what I have come up with off the top of
>> my head:
>>
>> - In web programming where "body" is a required tag in any valid HTML
>> document. Ex:
>> - It is a name commonly used for XML tags and/or attributes
>> - Physics simulations as well in astronomical contexts ("planetary
>> bodyies", etc.)
>> - Video games, such as referring to the player character's body
>>
>
>
> Really, why do we need a _body_ ?
> We have pre-condition and post-condition (in and out), everything else is
> a body.
> It is simply inconsistent - a regular function with no in and out blocks
> has no body block. Now one adds a pre-condition (and / or post-condition) -
> whoop - one needs to wrap the whole function body ... well in a body
> expression.
>
Recently I've had to use scope_ a lot more often than body_ but reserved
keywords are really annoying, so the less we have the better :D
