Re: D Binding to GUI libraries [was Interesting Observation from JAXLondon]
On Sunday, 21 October 2018 at 01:32:22 UTC, Nick Sabalausky (Abscissa) wrote: On 10/20/18 6:28 AM, Gregor Mückl wrote: Even though web and mobile UIs seem to be the rage at the moment, I believe a solid support for desktop UIs is very important for a general purpose language, if it wants to be successful in the market. I think that may be doubly true in the case of D, given D's focus on efficiency. HTML-based interfaces (whether web or app) are notoriously rife with inefficiencies: That's likely to be a major turn-off for exactly the very same audiences that D would appeal to most. While talking about bindings, do not forget Delphi. It has still a good eco system. Combining Delphi's advanced Runtime reflection capabilities with D's advanced compile reflection capabilities opens this eco system. I created a proof of concept and the results were really promising. Using Delphi components is very easy and the wrapper code on D side is very thin. Even clicking together a Firemonkey ui in Delphi and writing all code in D works fine. Delphi is available for windows, Mac os, Android and IPhone. Linux support is somehow planned. It is free for personal use. See an example here https://github.com/andre2007/delta-fmx-10-2-1/blob/master/examples/gui1/source/app.d Due to very limited time resources I have no time to work on this specific topic at the moment but everyone is free to use these base research results. Side remark: Lazarus (free pascal) is planning to add the same advanced Runtime reflection capabilities as Delphi. Kind regards Andre
Re: DMD Linker Issue on Windows
On Thursday, 18 October 2018 at 00:24:29 UTC, Kai wrote: On Wednesday, 17 October 2018 at 17:44:34 UTC, Adam D. Ruppe wrote: [...] Hmm - wish it was so. When architecture not specified, the linker crashes. When it's given, this happens (seems to be a vibe issue?): [...] As far as I can see, there are some Windows libraries missing. These libraries are part of the Windows sdk (You can use the vs build tools installer). Maybe we can include at least the libraries needed for vibe.d into the dmd Windows package? Kind regards Andre
Re: What's going on with the DMD nightlies releases ?
On Wednesday, 19 September 2018 at 12:51:25 UTC, Basile B. wrote: The downloads of nightlies is broken since at least 2 weeks now. What's going on ? Unfortunately it is still broken that is the reason why all dub pull requests are marked as failed. Example https://ci.appveyor.com/project/s-ludwig/dub/build/1.0.636 Does someone knows what the reason is? Kind regards Andre
Re: phobo's std.file is completely broke!
On Friday, 14 September 2018 at 19:06:14 UTC, Josphe Brigmo wrote: For very long file names it is broke and every command fails. These paths are not all that long but over 256 limit. (For windows) The problem this causes can be disastrous. If some check fails and runs code that isn't mean to run if the file exists, it could destroy data. I replaced many of the std.file functions with executeShell(...) and using command line functions and they work. But then my code was still failing and it was because exist was returning false even though the file exists. I'm sure this is not a big deal to some... Without knowing the issue in detail, is this maybe related to https://www.google.de/amp/s/www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/amp/ ? Kind regards Andre
Re: rund users welcome
On Saturday, 8 September 2018 at 04:24:20 UTC, Jonathan Marler wrote: I've rewritten rdmd into a new tool called "rund" and have been using it for about 4 months. It runs about twice as fast making my workflow much "snappier". It also introduces a new feature called "source directives" where you can add special comments to the beginning of your D code to set various compiler options like import paths, versions, environment variable etc. Feel free to use it, test it, provide feedback, contribute. https://github.com/marler8997/rund It would be great if you could create a pull request for rdmd to add the missing -i enhancement. Kind regards Andre
Re: Static foreach bug?
On Wednesday, 5 September 2018 at 12:05:59 UTC, rikki cattermole wrote: Indeed. scope enum would make much more sense. scope enum sounds a lot better for me than static enum or even __local. The __ words looks a little bit like compiler magic as the __ words are reserved for the compiler. Kind regards Andre
Re: This is why I don't use D.
On Wednesday, 5 September 2018 at 06:47:00 UTC, Everlast wrote: On Wednesday, 5 September 2018 at 01:39:04 UTC, Paul Backus wrote: On Wednesday, 5 September 2018 at 00:49:36 UTC, Everlast wrote: [...] If you don't want to use D, then don't use D. No one is holding a gun to your head. It seems to me like what D needs, right now, is people who are willing to roll up their sleeves and get to work when they see something that needs fixing. If that's something you're either unable or unwilling to do, for whatever reason, then D probably isn't a good choice for you right now. And that's ok. We all have our own goals and priorities, and no single programming language is going to be a perfect fit for everybody. I'm not going to sit here and spend have my time fixing shit that should have never broke in the first place. Thanks, you've made a great decision for me, I'm not longer using D for anything. The only reason I used it was for it's binary support and meta programming... no longer. Screw performance, non one else really cares and one doesn't necessarily need meta programming. Thanks, see you in another life! You showed as a painful issue in our eco system which we can work on, thank you. You do not need to work on this but do you have a proposal for a solution? What would you help (ranking according to last update, ...) Kind regards Andre
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Sunday, 2 September 2018 at 14:48:34 UTC, lurker wrote: after the beta i tried it the final again - just to be fair. 1.) install d, install visual d. 2.) trying to to look at options under visual d without a project crashes VS2017 - latest service pack. 3.) VS2017 - displays a problem on startup 4.) creating the dummy project - compile for x64. error something is missing. 5.) deinstall everything and wait for another year this crap does not even work out of the box - what else is not tested in D? i guess you don't intend to draw crowds to D and just keep talking on how to this and that a little better in the compiler pet project. is D that dead that the releases are not tested or do you want to keep all windows users out? There are a lot of motivated people here willing to help you to get your issue solved if you provide the details. I can confirm that DMD is working like a charm for me (different visual studio versions on build servers, MS build tools on local pc). I use IntelliJ instead of Visual Studio, but that is only my personal preferation. Kind regards Andre
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Monday, 27 August 2018 at 00:35:12 UTC, tide wrote: On Sunday, 26 August 2018 at 23:39:32 UTC, Manu wrote: [...] It's not just VisualD, the debug info DMD produces just doesn't include things like global variables for some reason. I use VS Code to debug, I get around it by using -gc (which is now deprecated) and adding the variable to the watch list with the full name. It's a pain in the ass though. Please see this SAoC https://forum.dlang.org/thread/wnjccfdfcptsfefaf...@forum.dlang.org Kind regards Andre
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Sunday, 26 August 2018 at 13:40:17 UTC, Chris wrote: On Sunday, 26 August 2018 at 08:40:32 UTC, Andre Pany wrote: [...] No. Nobody forces you to use the latest version that may have an improved GC, new library functions or bug fixes. In fact, why bother with improving the language at all? But how do you feel about code that you've been compiling with, say dmd 2.071.2 for years now - including workarounds for compiler bugs? Doesn't the thought of having to upgrade it one day bother you at all? What if your customer said that 2.08++ had better features asking you to use them? The burden of finding paths to handle deprecations etc. is on the user, not the language developers. And this is where the psychological factor that Laeeth was talking about comes in. If you're constantly programming thinking "Whatever I write today might break tomorrow, uh, and what about the code I wrote in 2016? Well, I'll have to upgrade it one day, when I have time. I'll just keep on using an older version of dmd for now. Yeah, no, I cannot benefit from the latest improvements but at least it compiles with dmd2.st0neage. But why worry, I'll just have to get used to the fact that I have different code for different versions, for now...and forever." You can get used to anything until you find out that it doesn't need to be this way. You write unexciting Java code and hey, it works and it always will. It took me a while to understand why Java has been so successful, but now I know. It's not write once, run everywhere. It's write once, run forever. Stability, predictability. And maybe that's why Java, Go and once C++ prefer a slower pace. I just don't understand why it is so hard to understand the points I and others have made. It's not rocket science, but maybe this is the problem, because I already see, the point to take home is: There are no real problems, we are just imagining them. Real world experience doesn't count, because we just don't see the bigger picture which is the eternal glory of academic discussions about half baked features of an eternally unfinished language that keeps changing randomly. Not practical, but intellectually satisfying. I reaĺly like new features, for new projects I also consider to use the latest stable dmd version (2.xx.1 or 2.xx.2) if there aren't any known issues. For legacy coding I do the math: does the new features, gc improvements,... worth the time = money. I can also decide to upgrade every 5 releases, but only if it worth the investment. I want to stress, the upgrade is fully in the hand of the developer and the decision can be made on costs and benefits. My opinion might be very optimistic, but I feel some opinions in this thread are rather pessimistic. Kind regards Andre
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Saturday, 25 August 2018 at 20:52:06 UTC, Walter Bright wrote:
On 8/25/2018 3:52 AM, Chris wrote:
On Friday, 24 August 2018 at 19:26:40 UTC, Walter Bright wrote:
Every programmer who says this also demands new (and
breaking) features.
"Every programmer who..." Really?
You want to remove autodecoding (so do I) and that will break
just about every D program in existence. For everyone else,
it's something else that's just as important to them.
For example, Shachar wants partially constructed objects to be
partially destructed, a quite reasonable request. Ok, but
consider the breakage:
struct S {
~this() {}
}
class C {
S s;
this() nothrow {}
}
I.e. a nothrow constructor now must call a throwing destructor.
This is not some made up example, it breaks existing code:
https://github.com/dlang/dmd/pull/6816
If I fix the bug, I break existing code, and apparently a
substantial amount of existing code. What's your advice on how
to proceed with this?
In the whole discussion I miss 2 really important things.
If your product compiles fine with a dmd version, no one forces
you to update to the next dmd version. In the company I work for,
we set for each project the DMD version in the build settings.
The speed of DMD releases or breaking changes doesn't affect us
at all.
Maybe I do not know a lot open source products but the amount of
work which goes into code quality is extremely high for the
compiler, runtime, phobos and related products. I love to see how
much work is invested in unit tests and also code style.
DMD (and LDC and GDC) has greatly improved in the last years in
various aspects.
But I also see that there is a lot of work to be done. There are
definitely problems to be solved. It is sad that people like
Dicebot leaving the D community.
Kind regards
Andre
Re: How possible is it to put DWARF debug infos in MSCOFF objects ?
On Friday, 17 August 2018 at 19:35:40 UTC, Basile B. wrote: On Friday, 17 August 2018 at 19:28:47 UTC, Basile B. wrote: Now that -m64 + LLD + MINGW works, the question is obvious. The background idea is of course to allow the use of GDB under Windows. At first glance the debug info API is not uniform. This is visible if you compare dmd.backend.dwarf and dmd.backend.cgcv and the naive idea which would be to replace all the calls starting with 'cv8_' with their "dwarf_" equivalent won't work (let's say to test in a first time, later a new compiler switch could be added to select the debug info format). Just to make sure, do you know Mago-Mi? It is the Mago debug engine with a GDB compatible interface. That means at every place GBD is supported, also Mago-Mi can be used. For example IntelliJ D Language plugin or Visual Studio Code or DlangIDE... Unfortunately Mago-Mi has some issues, written down here https://wiki.dlang.org/SAOC_2018_ideas#Multi_IDE_debugger_support_.28for_windows.29 Kind regards André
Re: Faster printing of floats; is this something that D could benefit from?
On Saturday, 28 July 2018 at 16:02:22 UTC, Gary Willoughby wrote: I just saw this on hacker news: We present Ryū, a new routine to convert binary floating point numbers to their decimal representations using only fixed-size integer operations, and prove its correctness. Ryū is simpler and approximately three times faster than the previously fastest implementation. Links: https://pldi18.sigplan.org/event/pldi-2018-papers-ry-fast-float-to-string-conversion https://www.youtube.com/watch?v=kw-U6smcLzk https://github.com/ulfjack/ryu Added to the list of SAOC 2018 ideas https://wiki.dlang.org/SAOC_2018_ideas#Implementation_of_RYU_to_convert_floats_to_strings Kind regards André
Re: So what is the state of cross-compilation in D?
On Saturday, 28 July 2018 at 08:56:30 UTC, Mike Franklin wrote: On Wednesday, 17 January 2018 at 13:24:37 UTC, Andre Pany wrote: On Wednesday, 17 January 2018 at 12:06:23 UTC, Rel wrote: Well, to be completely honest with you the only one thing I like about the Go programming language is the ability to easily cross-compile your Go program from any supported OS to any supported OS. So I was wondering what is the story of cross-compilation for different D language compilers? Is it possible to some extent now? Do you guys have interest in it? Basically as far as I understood what makes Go suitable for cross-compilation is their own linker implementation, and D compilers use current system linker. Cross compiling from Windows to raspberry pi: http://d-land.sepany.de/einstieg-in-die-raspberry-pi-entwicklung-mit-ldc.html Kind regards Andre Andre, That link appears to be dead. It was actually quite a nice resource. Any chance you can republish it or something? Thanks, Mike While changing the tool to generate the site, the urls changed. New link is http://d-land.sepany.de/tutorials/einplatinenrechner/einstieg-in-die-raspberry-pi-entwicklung-mit-ldc/ I need to update the article, I wrote it while LDC 1.5.0 was actual. Kind regards Andre
Re: Struct Initialization syntax
On Monday, 23 July 2018 at 16:26:42 UTC, Seb wrote:
tl;dr: the currently proposed syntax options are:
---
struct S
{
int a = 2, b = 4, c = 6;
}
void foo()
{
bar(S({c: 10})); // Option 1
bar(S(c: 10)); // Option 2
bar(S{c: 10}); // Option 3
}
---
So the struct-initialization DIP has been stalled for too long
and I think it's time we finally get this story done.
I personally prefer option 2, but this might be in conflict to
named arguments which we hopefully see in the near future too.
Hence, I'm leaning forward to proposing Option 1 as the
recommended Option for the DIP (that's also what the PoC DMD PR
implements). What's your take on this?
DIP: https://github.com/dlang/DIPs/pull/71
Rendered view:
https://github.com/wilzbach/DIPs/blob/struct-initialization/DIPs/DIP1xxx-sw.md
I also prefer option 3. From a readability point of view it is
the most pleasant one (my personal opinion). I also like it due
to the already existing struct initialization syntax I am using a
lot.
Kind regards
Andre
Re: gRPC, Better C and D
On Monday, 2 July 2018 at 18:06:43 UTC, bpr wrote: On Monday, 2 July 2018 at 10:25:07 UTC, Andre Pany wrote: Small update. With the help of evilrat I was able to translate the C headers to D. https://github.com/andre2007/grpc/tree/feature/d/src/d/source/grpc/c While the source code compiles without errors, everything is completely untested. As next step I will try to rewrite the python grpc code with D: https://github.com/andre2007/grpc/tree/feature/d/src/python/grpcio/grpc/_cython/_cygrpc That's really interesting! Are you thinking about translating some part of gRPC to DasBetterC? At the moment, no. Foremost priority is building a wrapper for D to open the gRPC ecosystem for D. Kind regards André
Re: gRPC, Better C and D
On Friday, 22 June 2018 at 18:10:54 UTC, Andre Pany wrote: Hi, the core of gRPC is written in C. I asked the developers whether they considered rewriting the core with Better C (https://github.com/grpc/grpc/issues/15786). They answered that they won't rewrite it with Better C but they are open for including D into their ecosystem. They have support for different languages and most of them are wrappers around the C Core functionality (C++, C#, Objective C, PHP, Python, Ruby). As far as I know there is no gRPC wrapper for D at the moment and if I remember correctly on DConf München there was a speaker talking about the need of a D wrapper for gRPC. My idea was to translate the C++ (https://github.com/grpc/grpc/tree/master/src/cpp) coding to D coding but my C++ knowledge is very limited. Is someone interested in adding D to gRPC? Kind regards André Small update. With the help of evilrat I was able to translate the C headers to D. https://github.com/andre2007/grpc/tree/feature/d/src/d/source/grpc/c While the source code compiles without errors, everything is completely untested. As next step I will try to rewrite the python grpc code with D: https://github.com/andre2007/grpc/tree/feature/d/src/python/grpcio/grpc/_cython/_cygrpc
gRPC, Better C and D
Hi, the core of gRPC is written in C. I asked the developers whether they considered rewriting the core with Better C (https://github.com/grpc/grpc/issues/15786). They answered that they won't rewrite it with Better C but they are open for including D into their ecosystem. They have support for different languages and most of them are wrappers around the C Core functionality (C++, C#, Objective C, PHP, Python, Ruby). As far as I know there is no gRPC wrapper for D at the moment and if I remember correctly on DConf München there was a speaker talking about the need of a D wrapper for gRPC. My idea was to translate the C++ (https://github.com/grpc/grpc/tree/master/src/cpp) coding to D coding but my C++ knowledge is very limited. Is someone interested in adding D to gRPC? Kind regards André
Re: Binderoo additional language support?
On Sunday, 6 May 2018 at 15:28:11 UTC, Ethan wrote: https://goo.gl/forms/DtKpuwOWR9V2TCnP2 Rapidly iterating my D code from C++ or .NET is great, but these are only two use cases that I know of. So. Let's see what other use cases are out there, and what are the most common ones. The link above goes to a Google Form where you can answer a bunch of questions that will give me an idea of what other languages I should account for. It doesn't require you to sign in, so all data is anonymous (to me anyway). There's only six multiple choice questions, so if you have a minute go head and fill it out. Cheers. Attending your session on DConf was great and a lot of fun. I do not know how it fits into your scenario but some months ago I created Delta [1] which is a bridge between D and Delphi. In case you do s.th. for Delphi, maybe Delta can leverage from or the other way around, you got some ideas how Binderoo can be enhanced by looking at Delta. The current plan for Delta is to create a Delphi Pascal parser which generates a Json for a given Delphi unit (the public interface). A second program will generate out of the Json D modules containing wrapper classes. The files you found on github are all hand written. https://github.com/andre2007/delta-core-10-2-1 Kind regards Andre
Re: DUB: Only fetch and cache packages in dub.json without running build
On Tuesday, 10 April 2018 at 13:50:38 UTC, Clinton wrote: Hi all, I'm setting up a CircleCI config for my project. Right now I'm trying to cache dependencies before running builds. This way I can run "dub build --nodeps" immediately after the packages are cached to avoid extra network calls and speed it up. [...] If I remember correctly I used dub upgrade exactly for this purpose. Kind regards Andre
Re: code.dlang.org having problems?
On Saturday, 24 March 2018 at 16:14:20 UTC, rikki cattermole wrote: On 25/03/2018 5:10 AM, Russel Winder wrote: On Sun, 2018-03-25 at 04:50 +1300, rikki cattermole via Digitalmars-d wrote: On 25/03/2018 4:48 AM, Russel Winder wrote: It seems Dub is dead, and thus so are new Dub builds. code.dlang.org appears to be having a 500 problem. I think the website is recovering as I write, but still no Dub builds so the point remains: no code.dlang.org, no Dub builds. :-( Tip: $ dub --skip-registry=all Not useful just no, I need new versions. Two reasons: 1. I didn't have the latest version locally; and 2. I deleted ~/.dub as a clean up measure to get rid of all the crap accrued over the years. $ git clone https:///xx/zz $ dub add-local zz These are workarounds, to keep you going. Preferable no, but what else can you do really? The only thing comes to mind is allow dub itself to retrieve the projects zip and cache the database locally. There are currently 2 interesting dub pull requests. First one allows you to specify git dependencies. Second one allows you to connect to maven repositories. If e.g. the dub packages also beeing cloned to a maven repository this would increase the safety net. Next step of course would be a pull request to allow url (zip) dependencies. May someone is so kind to create a pr. Kind regards Andre
Re: Please vote for Dub integration into Sonatype Nexus
On Wednesday, 21 March 2018 at 15:30:57 UTC, Russel Winder wrote: On Wed, 2018-03-21 at 11:49 +, Andre Pany via Digitalmars-d wrote: [...] […] [...] JFrog have Artifactory yes, but I do not know if Bintray is actually something different or just a public instance of Artifactory. In any event Bintray is a public repository of stuff, with JCenter being the bit for Maven type artefacts – most of the people I know publish to Maven Central via JCenter so as to avoid Sonatype's Nexus. I believe Maven is the wrong model for D, it is all about artefacts for use in JVM-based language builds. Conan (C/C++ repository) is a much better model for D, as is crates.io (Rust/Cargo repository), and indeed Dub :-). [...] I don't feel it is a hard one or the other decision but possibilities. In this direction Sönke made a very good proposal how to support different repositories using the existing registry attribute. Kind regards Andre
Re: Please vote for Dub integration into Sonatype Nexus
On Wednesday, 21 March 2018 at 09:37:15 UTC, Russel Winder wrote: On Tue, 2018-03-20 at 18:55 +, Dmitry Olshansky via Digitalmars-d wrote: On Tuesday, 20 March 2018 at 06:48:15 UTC, Andre Pany wrote: > Hi, > > if you have by chance a Sonatype account please vote for > this issue to get Dub integrated into Sonatype Nexus: > https://issues.sonatype.org/browse/NEXUS-15560. If we plan to extend DUB registry file format and the like this may be premature. But I like the initiative. Perhaps making use of Bintray would be a better route. I suspect hosting D-Apt on Bintray would also be possible. I wonder if creating a Fedora RPM package repository analogous to D-Apt on Bintray would be feasible. If I understand correctly, Bintray == JFrog Artifactory. Yes it would be also nice if dub support is added to both solutions. If JFrog accepts PR on Github we could even add dub support on ourselfs. One side information. I also created a pr for dub to support maven repositories as dub registries. https://github.com/dlang/dub/pull/1415 With this pull request we can use many repository solutions (Nexus, Artifactory, ...) as dub registries. Kind regards André
Please vote for Dub integration into Sonatype Nexus
Hi, if you have by chance a Sonatype account please vote for this issue to get Dub integrated into Sonatype Nexus: https://issues.sonatype.org/browse/NEXUS-15560. Kind regards André
code.dlang.org: 500 - Internal Server Error
Hi, while searching, there is an internal server error raised: http://code.dlang.org/search?q=d-unit 500 - Internal Server Error Internal Server Error Internal error information: vibe.db.mongo.connection.MongoDriverException@../vibe.d/mongodb/vibe/db/mongo/cursor.d(304): Query failed. Does the database exist? Kind regards André
Re: D course material
On Tuesday, 13 March 2018 at 12:39:24 UTC, Dmitry Olshansky wrote:
Hi, folks!
I’m testing waters for a D course at one University for first
time it’ll be an optional thing. It’s still discussed but may
very well become a reality.
Before you ask - no, I’m not lecturing and in fact, I didn’t
suggest D in the first place! Academics are finally seeing
light in the gloom of 1 year OOP in C++ course having
underwhelming results.
Now to the point, I remeber Chuck Allison (pardon if I
misspelled) doing D lectures at Utah Valley University, here:
https://dconf.org/2014/talks/allison.html
There is also Ali’s book. But anything else easily adoptable as
course material?
—
Dmitry Olshansky
Hi Dmitry,
for presenting D to my team I used following example. It
highlights
some features of D: Meta programming, templates, CTFE, UFCS, OOP
in D,
Functional programming in D and ...
It is a compile time i18n library in ~50 lines.
import std.experimental.scripting;
const devBundle = import("messagebundle.properties");
const identifiers = getIdentifiers(devBundle);
const languages = ["en", "de"];
void main()
{
auto t = new TextBundle("en");
writeln( t.text!"task.isNotARegisteredCommand"("lala"));
}
string[] getIdentifiers(string s)
{
return s.split("\n").filter!(l => l.canFind(" = ")).map!(l =>
l.split(" = ")[0]).array;
}
class TextBundle
{
private string _language;
alias TextKeyValue = string[string];
private static const TextKeyValue[string]
_languageTextKeyValue;
this(string language)
{
assert(language in _languageTextKeyValue);
_language = language;
}
string text(string s)(string[] params...)
{
static assert(identifiers.canFind(s));
string content = _languageTextKeyValue[_language][s];
foreach(i, param; params)
content = content.replace("{"~i.to!string~"}", param);
return content;
}
static this()
{
static foreach(language; languages)
{
static if( __traits(compiles,
import("messagebundle_"~language~".properties")))
{
string s =
import("messagebundle_"~language~".properties");
foreach(a; s.split("\n").filter!(l => l.canFind("
= ")).map!(l => l.split(" = ")))
{
_languageTextKeyValue[language][a[0]] = a[1];
}
}
}
}
}
The property files:
-messagebundle.properties-
task.isNotARegisteredCommand = `{0}` is not a registered command.
-messagebundle_en.properties-
task.isNotARegisteredCommand = `{0}` is not a registered command.
The property file for DE does not exist for showing
__traits(compiles,...) functionality.
I does fit in a 60 minute lecture.
Kind regards
André
#dbugfix Issue 17607
The minimized example from John Colvin is more easily to understand the issue: https://issues.dlang.org/show_bug.cgi?id=17607#c1 Current assumption: Due to a compiler bug, superfluous () are needed. This becomes a readability issue if you have a struct initialization for complex structures like in my initial request example. Kind regards André
Re: Embedded Linux really needs Dlang for the IOT market
On Friday, 9 March 2018 at 03:09:16 UTC, dangbinghoo wrote: hi all, I think the D community should make more effort to make Dlang more easier to use on embedded Linux(mostly are arm and mips, powerpc). currently, LDC seems to be more complete, but we can only see a hundred words on the wiki about the cross-compiling for arm. I'm working in a company now for IOT market. We have a lot of things like embedded linux systems: has a basic linux kernel, uclibc/eglibc system, built using buildroot or yocto. for such a device, we need to write lost of code for dealing networking, web interface, database storage and sometimes data algorithm. And, For most of the devices on the market, like routers, fiber-port routers, ethernet switches, and most of the termination system made by Cisco, Broadcom, Huawei and others running at least millions of lines of C code on the embedded linux system. So, We have very big chance for spreading to these market. D is really syntax-clean and provides more productive. We need tutorial for cross-compiling a whole d project for the ARM, MIPS linux systems, and we need the cross-compile toolchain ready to download. so, any ideas? I have a tutorial for raspberry py cross compilation from windows. It is on german but Google translator does give you a good English translation. http://d-land.sepany.de/einstieg-in-die-raspberry-pi-entwicklung-mit-ldc.html Kind regards André
Re: Which language futures make D overcompicated?
On Tuesday, 13 February 2018 at 11:14:25 UTC, rikki cattermole wrote: On 13/02/2018 11:11 AM, Russel Winder wrote: On Tue, 2018-02-13 at 10:45 +, aberba via Digitalmars-d wrote: […] I wish complaints about Dub would include exactly what was impossible with it. There's no reason to throw dub away and start something new. If one can run cmake before build in dub, then a lot is possible. Those edge cases can be ironed out. I think there have been many actual complaints made in detail in this thread. There is always a reason to replace, because you can build on what has gone before and do better. CMake is part of the problem. Dub fulfills all my use cases so I don't complain. Those here with not much issue with dub will also not complain. And that does not make it a minority opinion without stats to prove dub usage. No problem, and I guess you'll be happy to carry on using Dub after something new and better appears. In the case of Maven → Gradle, many people still use Maven even though it is provably inferior to Gradle simply because they cannot be bothered to change. At point, dub will likely remain the default package management tool. The build functionality can be improved for those who deal with such stuff often. Manpower is what remains. […] Why should Dub remain the one true way? Just because it was the first doesn't mean it is the best. It wasn't the first and it was the best in over a 10 year period. While I am really suffer from some painful behavior of dub, in my opinion it is a great tool and it would damage the D ecosystem to go away from dub. Companies already starting investing into this tool. In my case, without dub it would not be possible at all to use D at work. The involved developers doing a great job. Kind regards André
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Thursday, 25 January 2018 at 15:20:15 UTC, Benny wrote: After months doing a different project, i need a programming language for a new client with specific needs. D comes to mind. As usual that involves downloading the compiler (dmd and ldc). [...] While the several tools out of the box do not work well together, the involved developers did a great job (without any payment in contrast to Go/C#, Delphi...). I also struggled with the problem how to configure DCD in the DLang plugin for IntelliJ today. This might be the reason for the items marked as unknown. I created an issue here https://github.com/intellij-dlanguage/intellij-dlanguage/issues/356 The DLang ecosystem is getting better and better and you also can help by testing, writing constructive issues or even providing fixes. Kind regards André
Please provide a channel for D ecosystem ideas
Hi, the GSOC wiki page inspired me to write this request. If I have an idea how the improve the D ecosystem but cannot do it myself, there is at the moment no good channel to provide this idea to someone other in the D community. Maybe someone other is searching for an opportunity to help the D ecosystem but does not know how. - Implement support for D in another tool: E.g. it would be great if someone could create a Jenkins D plugin similar to https://wiki.jenkins.io/display/JENKINS/NodeJS+Plugin - Maybe you do not even have to develop something but convince other projects / companies to integrate D into their tools: Fortify, Sonatype OSS, Cloud Foundry, ... - Implement something in D It would be really great if there would be a place someone can easily put an idea and other can see the ideas and can pick one. The channel could be a new group "Ecosystem projects" in the forum, a Trello board, ... My preference would be a github repository with an issue per idea. What do you think? Kind regards André
Re: So what is the state of cross-compilation in D?
On Wednesday, 17 January 2018 at 12:06:23 UTC, Rel wrote: Well, to be completely honest with you the only one thing I like about the Go programming language is the ability to easily cross-compile your Go program from any supported OS to any supported OS. So I was wondering what is the story of cross-compilation for different D language compilers? Is it possible to some extent now? Do you guys have interest in it? Basically as far as I understood what makes Go suitable for cross-compilation is their own linker implementation, and D compilers use current system linker. Cross compiling from Windows to raspberry pi: http://d-land.sepany.de/einstieg-in-die-raspberry-pi-entwicklung-mit-ldc.html Kind regards Andre
Re: Dll support: testers needed
On Tuesday, 9 January 2018 at 18:32:24 UTC, Benjamin Thaut wrote: Am 09.01.2018 um 16:03 schrieb Andre Pany: [...] First let me say that what you are describing is a very uncommon and ill-advised use case. As such there is not going to be any nice to use workflow to acieve what you are trying to do. Still this doesn't mean that it won't be possible. Why ill-advised? What you're describing is a cyclic dependency between your main executable and your dll written in delphi. If you google for "cyclic dependency dll" you will usually get the advice to break your cylic dependency by splitting your code into more dlls. My personal experience shows the same. Cyclic dependencies in dlls are usually not worth the additional effort and hassle. Also you want to export things from your executable, which is also very uncommon. What you should be doing is having 2 dlls and one executable. You have one common library written in D that is build into a dll. Then you have your delphi library which uses the common.dll. Finally you have your main executable written in D which uses both the common.dll and your delphi.dll. This should make it possibly to break the cycle and get you an easy setup. If you absolutley must do it the way you describe it, its still possible. You will have to compile all modules that export something from your executable with the "-c -shared" parameters. E.g. dmd -m64 -c -shared moduleThatExports1.d moduleThatExports2.d -ofexports.obj Now you link the resulting exports.obj file into your executable by calling dmd again dmd -m64 restOfModules.d exports.obj delphi.lib -ofmain.exe Finally you have to get the handle to your main executable by calling HMODULE handle; GetModuleHandleExA(0, null, &handle); in your delphi dll and then fetching the function pointer for each and every function you want to call from delphi via: GetProcAddress(handle, "mangeledFunctionSymbol") Now finally you can call these functions pointers from delphi and they will call into the D code within your executable. Instead of all that hassle you could instead just have a function in your delphi dll: void recieveFunctionPointer(const(char)* name, void* ptr); which you call for every function that you want to make available from D to delphi. Your delphi code then stores away these pointers depending on the name. That way you don't need to export anything from your executable and can build it normally. Instead of having a function call per function you could obviosuly also use a struct that is defined the same way in D and delphi and contains all relevant functions pointers. Thanks for your deep analysis. There are several reasons I want to have the exe as Delphi application: 1) I faced some minor (Delphi) IDE/Libraries bugs with having the Delphi gui within a dll. 2) The Delphi IDE provides you the possibility to e.g. easily change the exe icon/attach additional resources to the exe, ... 3) Delphi lets you also create android/iPhone applications. I assume there will be no other way than place the D coding within a shared object for this scenario. I completely agree with you, it is mad. My gut feeling is, you have the greatest benefit from the IDE and convenience if the executable is written in Delphi. I try to support both ways in my library, so the developer can decide. Kind regards Andre
Re: Dll support: testers needed
On Tuesday, 9 January 2018 at 14:43:43 UTC, Benjamin Thaut wrote: Am 09.01.2018 um 12:02 schrieb MrSmith: Is it possible to put common code in exe, and use that code from dlls? Or anything can be exported only by dll? You can only export from dlls. I don't know of any use case where exporting from a executable would make sense. No, you can't put common code into a executable and use that code from dlls. Thats not how dlls are designed to work on windows. If you absoutely still want to export from an executable you can still use -L/EXPORT:"mangledSymbolName" Is it possible to have circular dependencies between dlls? No. You will get linker errors. Same as in C/C++. Tips for doing dlls with dub? Well, first my PR will have to get merged. Then you'll have to wait until a release exists that actually has my changes and then maybe there is support added in dub. Before that I think trying to use dub to create dlls is wasted effort. I am building a bridge between Delphi and D. At the moment the executable is written in D and the Dll (Firemonkey UI) is written in Delphi. But I think I want to enable also the other way around. The D coding which is then located in the Dll should be able to call Delphi methods located in the executable. The whole idea idea is that all logic is written in D and you only use the Framework (ui) and libraries Delphi provides. I think this might be a valid use case for a Dll calling functionality located in the exe. Kind regards Andre
Re: How do you use D?
On Thursday, 4 January 2018 at 15:52:15 UTC, Andre Pany wrote: On Friday, 28 July 2017 at 14:58:01 UTC, Ali wrote: 3) It is not possible to run DMD with the microsoft linker and libs without adapting the sc.ini. That is a pain! In the build infrastructure I can only use the dmd zip archive and not the setup routine. Also the adapation of the sc.ini I need to automate in a python script (XMake build plugin). Python does not like the sc.ini... due to duplicate keys... Just compare with LDC windows 64. You only have to extract the zip archive, call vcvarsall batch file which sets the environment variables and thats it! https://issues.dlang.org/show_bug.cgi?id=17967 It seems with the recent version of DMD (2.078.0) there is new feature which solves this problem (https://dlang.org/changelog/2.078.0.html#vs-auto-detection) That's fantastic! Thanks a lot! I will try it and then close the issue. Also the new options for customizing the code coverage seems like you heard my wishes within my mind;) Great work! Kind regards André
Re: How do you use D?
On Friday, 5 January 2018 at 00:38:05 UTC, Laeeth Isharc wrote: On Thursday, 4 January 2018 at 15:52:15 UTC, Andre Pany wrote: On Friday, 28 July 2017 at 14:58:01 UTC, Ali wrote: [...] I am working for a german software company. There are various programming languages used. I created several non customer facing tools in D for the projects I am involved. Also I tried to make advertisements for the D Programming Language by creating internal wiki pages, recordings, video channel with screencams and telling everyone about that nice programming language called D. [...] Very interesting. Have a look at pegged and the work done by Bastian who has also been building a pascal parser - for a different dialect. Thanks for the info, I try to make my parser easiliy replacable by a better solution like pegged. For the moment I try to get the generator working and cleanup things later. I will also have a look at the work of Bastian. Kind regards André
Re: How do you use D?
On Friday, 28 July 2017 at 14:58:01 UTC, Ali wrote: While the Orgs using D page is very nice ... I hoping to hear more personal stories ... So How do you use D? In work, (key projects or smaller side projects) in your side project, (github, links please) just to learn something new? (I would easily argue that learning D will make you a better C++ programmer, maybe not the most efficient way, but I a sure it i very effective) Did you introduce D to your work place? How? What challenges did you face? What is you D setup at work, which compiler, which IDE? And any other fun facts you may want to share :) I am working for a german software company. There are various programming languages used. I created several non customer facing tools in D for the projects I am involved. Also I tried to make advertisements for the D Programming Language by creating internal wiki pages, recordings, video channel with screencams and telling everyone about that nice programming language called D. To be able to write customer facing software in D I have to integrate the D programming language into the existing build landscape (Jenkins/XMake). It was possible to integrate D but there are rough edges. Before I start I want to say a big thank you to Sönke and everyone involved in the Dub project. Without Dub, the usage of D would not be possible at all! 1) There is a deprecated "version" attribute in dub.json. Dub now forces you to specify the application version using git tags. As the build landscape itself creates git tags which aren't Semver compatible, the deprecation of the "version" attribute is a great pain for me. I solved the problem by "inventing" an own way to specify a version (version.txt file), which is a bad solution. https://github.com/dlang/dub/issues/1301 2) During the official build no connection to the internet is allowed (e.g. code.dlang.org). For the moment I have no possibility to run an inhouse dub repository. This forces me to include source code of the dub packages I want to use, in my applications. The company is running a big Maven repository in which I could store the dub packages as zip files and which has http access to these artefacts. I would like to specify in my dub.json the url address to the zip file stored in the maven repository. https://github.com/dlang/dub/issues/1134 3) It is not possible to run DMD with the microsoft linker and libs without adapting the sc.ini. That is a pain! In the build infrastructure I can only use the dmd zip archive and not the setup routine. Also the adapation of the sc.ini I need to automate in a python script (XMake build plugin). Python does not like the sc.ini... due to duplicate keys... Just compare with LDC windows 64. You only have to extract the zip archive, call vcvarsall batch file which sets the environment variables and thats it! https://issues.dlang.org/show_bug.cgi?id=17967 4) Every open source software I want to use, needs to go through an open source process before I can use it in customer facing software. Dub has a very annoying behavior. If I want to use a package A and it has an optional dependency to be package B, Dub fails if B is not available. That leads to the issue that even I do not want to use B, I need to go through the open source process for B due to the behavior of Dub. I had this issue with the unit test frame work D-Unit. Fortunatelly the developer of D-Unit was kind and removed the optional dependency completely! https://github.com/dlang/dub/issues/1272 I have also to say a big thank you to Adam D. Ruppe. He has created a great library with very helpful functionality like database access, http server, terminal, ... and he is a very helpful and kind person. My hobby project is to create a bridge between the Embarcadero RAD Studion (Delphi) and D. The idea is to use all functionality from Delphi and RAD Studio (GUI designer, thousands of libraries) without writing one 1 line Pascal but write everything in D. At the moment I have already a windows demo application running, but I hope I can extend it to MacOS/Android/IPhone... https://github.com/andre2007/delta-core-10-2-1 The package you see on github is written by hand. At the moment I am writing a Pascal Parser to have everything generated by the Pascal Source files (VCL/Firemonkey/Indy/...) automatically. Kind regards André
Re: Best SQL library to use with local desktop app
On Wednesday, 3 January 2018 at 12:14:19 UTC, wakhshti wrote: what is best (SQLite?) @small @local @offline database library to use in D? and also what about a simple GUI library ? (once there was a library named DFL, but i never could get it to run). As you proposed SQLite makes sense. My personal preference is the wrapper from Adam you can find here https://github.com/adamdruppe/arsd/blob/master/sqlite.d Do you want to run on a specific OS only or should it run on multiple OS? There is also the Learn forum which fits better for beginner questions. Kind regards Andre
Re: code.dlang.org name collision
On Thursday, 21 December 2017 at 20:13:21 UTC, Steven Schveighoffer wrote: I think currently on code.dlang.org, if you create a library/program for use, it uses the name you choose as a unique identifier for your project. However, this seems rather open to abuse, or to unnecessary conflicts. An example, I plan to have iopipe depend (eventually) on Martin Nowak's new io library listed here: https://github.com/MartinNowak/io But, there is already an "io" library in dub: http://code.dlang.org/packages/io This links to a stale project, https://github.com/jasonwhite/io, not updated since June 2016. So what does this mean? Jason White's library gets to own the name "io" forever? It's not fair to Jason, or anyone who links to his project to take it down or change it, but this also seems unfair to anyone who is willing to publish and maintain an io package of their own. One of the most annoying things I found is that even if I add-local Martin's io repository to dub, it *still* wants to compile against the code.dlang.org library (this makes sense as we don't want hijacking, but the solution sucks, I have to use a modified version of Martin's dub.sdl file). Regardless of this example, I'm sure you can see the dilemma here. Should we have an application/approval process for package names? Should we allow the same named packages on dub, but provide a way to disambiguate when specifying dependencies? Other ideas? What do you all think? -Steve P.S. maybe there is already a solution in place for this, but I'm not seeing it. Great you brought this to attention. During a technical code review for a XMake build plugin for D I was asked how a company can set the organization name in dub.json to avoid name clashes with Dub package names. Maybe we could also have a look how this is done in other languages npm/python,... Kind regards Andre
Re: Question on Dual-Licensing Some Code for Phobos
On Thursday, 30 November 2017 at 19:17:32 UTC, Jack Stouffer wrote: I'm starting work on a proposal for stdx.decimal, and one of the clearest implementations to work off of is the Python implementation. This however, poses a problem because Python's source is under the PSFL, a BSD-like permissive license. Any derivative work, such as a D conversion, must have the original copyright notice, a copy of the PSFL, as a well as a summary of changes. This is simple enough to do, but the resulting code would be dual-licensed with the PSFL and the BSL 1.0 (dual-licensing being relatively common in other OSS projects). My question is there any reason this could pose a problem? Could this interfere with something like distribution or company adoption? Also note, one of the existing Phobos modules, std.net.isemail, is supposed to be dual-licensed because it's derived from an existing BSD work. But, it's missing the BSD license from the top (and is technically breaking the license because of that). That s great that you have a look at this area. Maybe the developers of the Python Decimal Module could be asked whether they allow us to license the derived work as BSL similar to isemail. Do you know there is already a similar attempt to bring decimal to phobos: https://github.com/andersonpd/eris This work could also be a starting point... Kind regards Andre
Re: String import an entire directory
On Monday, 13 November 2017 at 09:27:10 UTC, Adrian Matoga wrote: On Saturday, 11 November 2017 at 14:11:50 UTC, Neia Neutuladh wrote: At my job, I put together a database migration tool for our services. It scans for resources in your JAR file with an appropriate path, interprets them as SQL scripts, and applies them to the database if it hasn't been done yet. I want to implement this in D. However, while D allows you to import individual files, it doesn't let you import an entire directory. I can make a prebuild script to generate code for this, but I'm wondering: do other people find themselves needing this periodically? If so, I can write a DIP for it, or at least publish a codegen tool that other people can use. Why do you want to import files at compile time? Why can't it be done in run time, by simply reading directory with dirEntries and opening std.stdio.File for each one? Three is a use case. I have an application which should be translated into different languages. I created a texts.prop file. The language department will create texts_en.prop, texts_de.prop and so on. The language department will create GIT pull requests which will cause the build infrastructure to recompile my application. Any new text_**.prop should be automatically included in the build process. There is an advantage and a disadvantage of using import for this scenario. The advantage is, it was really easy to implement and in case I use non existing text keys in the coding, there is a compiler time error. But there is a major downside, although nothing is changed in any file, dub will every time recompile my application. Also my rather small application takes 4 seconds to compile due to this logic. Therefore I tend to reimplement the logic using a dub pre build script. Kind regards Andre
Re: Project Elvis
On Saturday, 11 November 2017 at 11:18:24 UTC, codephantom wrote: Yeah, integrating gui's into a programming language is complexthere are some gui kits for D in github, but none I find compelling at this stage - even though they're authors are doing a great job. It's not that it's too complex technically, but the corporates I've done work for would never allow you to bring in your own gui anyway. Everything has to be standardised, and look familiar to users. If you target windows and you do not mind to install a free version of Delphi on your pc, you can use the Delphi VCL/Firemonkey gui toolkit, create your ui forms in the Delphi editor while implementing the program logic in D. https://forum.dlang.org/thread/fwsbrmkbqkolrsztx...@forum.dlang.org Kind regards Andre
Re: Anticipate the usage of Visual Studio 2017 Developer Command Prompt?
On Saturday, 4 November 2017 at 09:39:02 UTC, Rainer Schuetze wrote: On 03.11.2017 21:51, Andre Pany wrote: On Friday, 3 November 2017 at 11:52:10 UTC, Andre Pany wrote: [...] I have an idea which solves several problems. Current state: The dmd windows archive has a folder "bin" with a 32 bit dmd compiler which is able to create x86 and x86_64 applications. By default the dmd compiler creates 32 bit applications using the optlink link.exe contained also in this folder. Idea: Within the folder "bin64" the 64 bit dmd compiler could be shipped within the dmd windows archive. I assume the 64 bit dmd compiler is able to create x86 and x86_64 applications. In folder "bin64" no optlink link.exe should be available. The usage of either the microsoft link.exe or another linker (maybe the one from LDC) is anticipated. The 64 bit dmd compiler could have the option -m64 set as default. The user can decide whether he wants to use the "stable" dmd compiler with usage of optlink or he want to use the 64 bit dmd compiler which is open for other linkers than optlink by simply setting his path variable to bin or to bin64. Using this approach: - DMD compiler is working out of the box for the VS Developer Command Prompt - no need to rename the optlink link.exe - A 64 bit dmd compiler is shipped which solves issues on large D projects What do you think? Kind regards André Finding the wrong linker seems to happen quite often, but I wonder why: sc.ini usually has the absolute path to the linker set via the LINKCMD variable, so finding the correct executable should not be a problem if the installer has set things up correctly. If extracted from the zip there are also defaults that might not work but should not find the wrong linker. Is it the result of trying to fix the sc.ini manually? The problem with overriding the LIB environment variable is that optlink and the MS linker both use it, but stumble over the libraries for the other linker due to different file formats. I think the best option forward is to not rely on the installer to find the correct setup at installation time, but detect the available linker and its environment before invoking it: - if the environment is already set up via vcvarsall, i.e. VCINSTALLDIR set, use that to call the approriate linker - if VCINSTALLDIR is not set, use the registry to find the best fit, i.e. highest available VS version - some way to override the automatism should be available, too. We might also be able to provide some fallback if no VS installation is found, based on the LLVM linker, but with limited C runtime/platform library support. I would say, by executing vcvarsall the user showed his intention to use the coff libraries and the Microsoft linker for the actual console session instead of the omf libraries. I see a disadvantage by detecting the vc installation directory / lib directories. All paths are specific for the vs version. If there is x new vs version we are always behind. But Microsoft has a solution for this problem. Vcvarsall sets the linker as first element of the path variable and the lib env variable points to the right folder. This solution will work for old vs version and any upcoming version. I set linkcmd to "link.exe". Unfortunately the link.exe in the dmd bin folder has precedence over the path env variable. Kind regards Andre
Re: Anticipate the usage of Visual Studio 2017 Developer Command Prompt?
On Friday, 3 November 2017 at 11:52:10 UTC, Andre Pany wrote: Hi, Visual Studio has a batch file which sets all needed environment variables for the Microsoft linker (LIB environment variables points to all necessary folders). Even the folder containing the link.exe for the specified architecture (x86, amd64) is added to the path variable as first path. vsdevcmd -arch=amd64 As the sc.ini targets the windows development (visuals studio) after calling the developer command prompt, dmd should be able to compile -m32mscoff, -m64 out of the box without the need to change anything within sc.ini. There is even a comment in sc.ini which points in this direction: ; Add the library subdirectories of all VC and Windows SDK versions so things ; just work for users using dmd from the VS Command Prompt Unfortunately it does not work for various reasons: - optlink has the filename link.exe which conflicts with the filename of the microsoft linker - from my investigation I have the assumption that even if an environment variable LIB exists, the value is discarded by the sc.ini logic. I tried hard, but it seems existing environment variable LIB cannot be used in sc.ini If you can use the windows installer, it will set the right values in sc.ini. But there are scenarios in which you cannot use the windows installer but have to use the dmd zip archive (build infrastructure scripts). In my scenario it seems the only possibility is to adapt my build infrastructure scripts to: - extract dmd archive - delete link.exe (optlink) - modify the sc.ini That is a solution for my case, but my gut feeling is, it should be solved in general to ease the usage of the microsoft linker. I thought it was planned to rename the optlink link.exe to optlink.exe? Kind regards André I have an idea which solves several problems. Current state: The dmd windows archive has a folder "bin" with a 32 bit dmd compiler which is able to create x86 and x86_64 applications. By default the dmd compiler creates 32 bit applications using the optlink link.exe contained also in this folder. Idea: Within the folder "bin64" the 64 bit dmd compiler could be shipped within the dmd windows archive. I assume the 64 bit dmd compiler is able to create x86 and x86_64 applications. In folder "bin64" no optlink link.exe should be available. The usage of either the microsoft link.exe or another linker (maybe the one from LDC) is anticipated. The 64 bit dmd compiler could have the option -m64 set as default. The user can decide whether he wants to use the "stable" dmd compiler with usage of optlink or he want to use the 64 bit dmd compiler which is open for other linkers than optlink by simply setting his path variable to bin or to bin64. Using this approach: - DMD compiler is working out of the box for the VS Developer Command Prompt - no need to rename the optlink link.exe - A 64 bit dmd compiler is shipped which solves issues on large D projects What do you think? Kind regards André
Anticipate the usage of Visual Studio 2017 Developer Command Prompt?
Hi, Visual Studio has a batch file which sets all needed environment variables for the Microsoft linker (LIB environment variables points to all necessary folders). Even the folder containing the link.exe for the specified architecture (x86, amd64) is added to the path variable as first path. vsdevcmd -arch=amd64 As the sc.ini targets the windows development (visuals studio) after calling the developer command prompt, dmd should be able to compile -m32mscoff, -m64 out of the box without the need to change anything within sc.ini. There is even a comment in sc.ini which points in this direction: ; Add the library subdirectories of all VC and Windows SDK versions so things ; just work for users using dmd from the VS Command Prompt Unfortunately it does not work for various reasons: - optlink has the filename link.exe which conflicts with the filename of the microsoft linker - from my investigation I have the assumption that even if an environment variable LIB exists, the value is discarded by the sc.ini logic. I tried hard, but it seems existing environment variable LIB cannot be used in sc.ini If you can use the windows installer, it will set the right values in sc.ini. But there are scenarios in which you cannot use the windows installer but have to use the dmd zip archive (build infrastructure scripts). In my scenario it seems the only possibility is to adapt my build infrastructure scripts to: - extract dmd archive - delete link.exe (optlink) - modify the sc.ini That is a solution for my case, but my gut feeling is, it should be solved in general to ease the usage of the microsoft linker. I thought it was planned to rename the optlink link.exe to optlink.exe? Kind regards André
Re: Note from a donor
On Wednesday, 25 October 2017 at 22:46:27 UTC, Adam Wilson wrote: On 10/25/17 11:23, H. S. Teoh wrote: On Wed, Oct 25, 2017 at 08:17:21AM -0600, Jonathan M Davis via Digitalmars-d wrote: [...] [...] Yeah. There have been timing attacks against otherwise-secure crypto algorithms that allow extraction of the decryption key. And other side-channel attacks along the lines of CRIME or BREACH. Even CPU instruction timing attacks have been discovered that can leak which path a branch in a crypto algorithm took, which in turn can reveal information about the decryption key. And voltage variations to deduce which bit(s) are 1's and which are 0's. Many of these remain theoretical attacks, but the point is that these weaknesses can come from things you wouldn't even know existed in your code. Crypto code must be subject to a LOT of scrutiny before it can be trusted. And not just cursory scrutiny like we do with the PR queue on github; we're talking about possibly instruction-by-instruction scrutiny of the kind that can discover vulnerabilities to timing or voltage. I would not be comfortable entrusting any important data to D crypto algorithms if they have not been thoroughly reviewed. T I am one-hundred-ten percent in agreement with Mr. Teoh here. Even .NET Framework and Core forward to the highly vetted system crypto API's (SChannel on Windows and OpenSSL on Linux/macOS). If you need RSA crypto in D, pull in OpenSSL. Period. Everything else is a good way to run afoul of a security audit, and potentially expose yourself. Phobos could forward to these system provided API's like .NET does and provide an idiomatic D interface, but Phobos itself should absolutely and 110% stay out of the crypto implementation business. I think you made a very good point, it was also mentioned by someone else in this thread. Phobos could provide a crypto interface with implementions for SChannel, mbedtls, openssl. On Windows SChannel would be used as default implementation and on the other operation systems either openssl or mbedtls. This would be very convenient and we would avoid opening the Pandora box. I will close my issue and create a new one with the request for a crypto interface in Phobos. Kind regards Andre
Re: Note from a donor
On Thursday, 26 October 2017 at 15:50:07 UTC, Andrei Alexandrescu wrote: On 10/26/2017 08:36 AM, jmh530 wrote: [...] I am preparing a request for Microsoft to allow us to redistribute some of their binaries. Of course we want to do that only if deemed necessary (they are not available easily from their site etc). Any help building an exact list of requisites would be great. Thanks! -- Andrei Thanks a lot Andrei. At my working environment I advertise the use of DLang. Major competitors are python, nodejs, java and go. Everything which makes the installation and use of DLang more easy makes it easier to advertise D. Kind regards Andre
Re: Note from a donor
On Wednesday, 25 October 2017 at 04:55:16 UTC, Walter Bright wrote: On 10/24/2017 6:20 AM, Andrei Alexandrescu wrote: * better dll support for Windows. It's been there, but it breaks repeatedly because it is not in the test suite. Yes that is right. One of these issues is the Runtime.unload bug https://issues.dlang.org/show_bug.cgi?id=15443 The wiki page https://wiki.dlang.org/Win32_DLLs_in_D has an example in which the function gc_getProxy and gc_setProxy is used the inject the garbage collector. The example shows only this behavior in the static linked case but not in the dynamically linked case. For the dynamically linked case, there is an error. Ian Hatch found out same more information http://forum.dlang.org/post/nteskpizpsnxrulcs...@forum.dlang.org In general the "export" work of Benjamin Thaut is also highly interesting (D's Import and Export Business, DConf2016) Kind regards André
Re: Note from a donor
On Tuesday, 24 October 2017 at 20:27:26 UTC, Adam Wilson wrote: On 10/24/17 07:14, Kagamin wrote: On Tuesday, 24 October 2017 at 13:20:10 UTC, Andrei Alexandrescu wrote: * RSA Digital Signature Validation in Phobos https://issues.dlang.org/show_bug.cgi?id=16510 the blocker for botan was OMF support. IMO, the correct solution here is to deprecate OMF and use the System linker for 32-bit on Windows as that is already the default behavior on 64-bit Windows So instead of -m32 and -m32mscoff, we would have -m32 and -m32omf. I think that this is a reasonable tradeoff. We could leave -m32mscoff in for a while, for backwards compat. In general I agree with you that coff is the way to go. I just dislike the consequences. Today you just download the dmd Windows zip, extract it and you have a running compiler. Nice, self contained and a good advertisement for D. On the other side if the user is forced to install Visual Studio / C++ build pack, this might distract first time D users... If the Microsoft linker could be added to dmd that would be the best solution. Just dreaming :) Kind regards Andre
Re: AWS SDK
On Wednesday, 18 October 2017 at 20:19:20 UTC, ikod wrote: Hello, On Wednesday, 18 October 2017 at 20:05:28 UTC, Andre Pany wrote: On Wednesday, 18 October 2017 at 19:28:30 UTC, aberba wrote: The implementation is straight forward. For every api definition (e.g. https://github.com/aws/aws-sdk-js/blob/master/apis/iam-2010-05-08.normal.json) create a module with a class. Read the json file with std.json and for every operation in the json create a method with the same name in the class. For every shape in the json create a struct with the same name. Every operation defines either an input shape, output shape, or both. During the method call serialize the input struct to json, call the aws client with the json and deserialize the output json to the output struct. Kind regards André Is there any docs from Amazon on this, beside json's itself? I will be very grateful for link. I think as a starting point the console client help is very interesting. http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-using.html Especially these two topics -Generate CLI Skeleton and CLI Input JSON Parameters -Controlling Command Output from the AWS Command Line Interface Kind regards André
Re: AWS SDK
On Wednesday, 18 October 2017 at 19:28:30 UTC, aberba wrote: What's up with proprietary stuff in this? At least give us the setup for us to generate the apis on our own if you have your private stuff in there. I have been waiting for a D AWS SDK for "years"... At least any cloud SDK. The generated api approach seem like the way to go cus its a lot of work to build and maintain a D API by hand. I wanted to just do an S3 api plus some few services to use in some of our microservices. We opted to use Nodejs because it already has all the Cloud SDK for almost every provider. Technically D is much better... You know, cloud and microservices is the way to build any "scalable" server-side services in 2017 yet it seem those using D for server-side dev are still writing monoliths. Although I wrote the generator, it is property of my employer. I am unfortunately not allowed to make it public. The implementation is straight forward. For every api definition (e.g. https://github.com/aws/aws-sdk-js/blob/master/apis/iam-2010-05-08.normal.json) create a module with a class. Read the json file with std.json and for every operation in the json create a method with the same name in the class. For every shape in the json create a struct with the same name. Every operation defines either an input shape, output shape, or both. During the method call serialize the input struct to json, call the aws client with the json and deserialize the output json to the output struct. Kind regards André
Re: AWS SDK
On Wednesday, 18 October 2017 at 01:32:51 UTC, Ky-Anh Huynh wrote:
On Tuesday, 28 June 2016 at 00:36:31 UTC, Brad Roberts wrote:
On 6/27/16 10:53 AM, Brad Roberts via Digitalmars-d wrote:
On 6/26/2016 4:06 PM, Jadbox via Digitalmars-d wrote:
[...]
I have some old code here:
https://github.com/braddr/downloads.dlang.org/tree/master/src
It has sig v2 signing and some s3 object related code. Super
minimal and sig v2 is out of date
(though still very usable, in most aws regions).
Ideally, someone would partner with aws -- there's a
developer tools forum -- to add D to the suite
of languages. I'm fairly sure they code generate at least a
large part of the tool kits from the
api definitions for each of the tons of services. Trying to
manage them all by hand is a loosing
battle.
I've been tempted to do this a couple times, but the time
investment would likely be more than I'm
willing to spend.
I've started talking with a few of the aws sdk engineers (some
of who I worked with when I was there) today about their sdk
and the tooling involved. It might not be a horrible job to
add another language to the mix. I'm going to meet with them
and dig through some of the tooling to get a better feel for
it.
Later,
Brad
Hi Brad,
Do we have any good update on this?
I'm writting my devops tools in Dlang now (Golang is too hot to
use, isn't it:D). It's a great win if we can have AWS SDK
support.
I'm not a master however if there is any thing I can help,
please let me know.
Thanks for your reading.
Hi,
for an inhouse project I developed a generator which generates
based on the API definitions from here
https://github.com/aws/aws-sdk-js/tree/master/apis
classes for the services and structures for the input/output
requests.
auto client = new AwsClient();
auto dynamoDBService = new DynamoDBService(client);
CreateTableInput request = {
tableName: "zapp-test1",
provisionedThroughput: {
readCapacityUnits: 1,
writeCapacityUnits: 1
},
attributeDefinitions: [
{attributeName: "A", attributeType:
ScalarAttributeType.S},
{attributeName: "B", attributeType:
ScalarAttributeType.S}
],
keySchema: [
{attributeName: "A", keyType: KeyType.HASH}
]
};
dynamoDBService.createTable(request);
Actually the generated classes do not call AWS directly but uses
the AWS console client.
Unfortunately the generator is proprietary.
The good thing is, it was easily written within 4-5 hours.
PS. Almost every service was working out of the box except EMR.
There is a difference between the EMR commands / parameters in
the API definitions and in the AWS console client.
Kind regards
André
[your code here] Print Hex Dump issue
Hi, I just tried the print hex dump example. The output is: Application output (1: ) Compilation output: Program's output exceeds limit of 4096 bytes. Program's output exceeds limit of 4096 bytes. Maybe a smaller file could be used (currently the exe file itself is used). Or the limit could be residered for this example. Kind regards André
Re: D-Man emoji
On Monday, 11 September 2017 at 23:01:06 UTC, Walter Bright wrote: Here are some D-Man cartoons: https://github.com/dlang/dlang.org/pull/1648 which we sometimes use to decorate D related web pages: http://dlang.org/safed.html http://dlang.org/dstyle.html It seems we are under-utilizing our mascot, D-Man. Wouldn't it be nice to have a set of D-Man emojis that can be linked to? or that we can use in the D forums? Anyone want to contribute some? No drawing talent required! I drew some, and I have the talent of a second-grader. [I know that because my mom saved some of my 2nd grade art, and things haven't improved.] Nice:) Could you also include into the dmd2 package an icon file. I would be nice if I could set an icon for the *.d files. The dmd installer for windows has a nice icon which could be included for example. There is an icon d002.ico in html\d\images. But it is low resolution and the background is not transparent. Kind regards André
Re: Need some vibe.d hosting advice
On Saturday, 12 August 2017 at 08:49:44 UTC, Paolo Invernizzi wrote: On Friday, 11 August 2017 at 13:06:54 UTC, aberba wrote: So I'm into this platform with a vibe.d api server + back-end and I'm confused/curious to know the hosting package to use. I will have a lot of images uploaded by users. [...] We are using dockerized vibe.d containers in a docker swarm hosted on DigitalOcean. /Paolo Your scenario sounds like a very interesting and helpful D blog;) Kind regards André
Re: Need some vibe.d hosting advice
On Friday, 11 August 2017 at 13:06:54 UTC, aberba wrote: So I'm into this platform with a vibe.d api server + back-end and I'm confused/curious to know the hosting package to use. I will have a lot of images uploaded by users. 1. For sometime, I've been looking at heroku which is fine with its load balancer, easily scaling etc. But the hosting cost for a startup is high and (most importantly) requires an external storage either s3 or cloudinary which no lib in D currently exist for them (stable). 2. Get an EC2 instance from Amazon or Vultr and install everything yourself and save images on disc (potentially problematic). This can not be scaled easily 3. use a self-hosted PaaS like Flynn (aka self hosted heroku) ...but you still have to store images in an object storage and a D api is needed for this. Which links back to point 1 but less costly and more control. How would you do it if you were using vibe.d? (With node.js, all these are solved). On cloud foundry you have the possibility to push a pre compiled binary and use the binary buildpack or to use a D buildpack and push the D source code. There is an issue with vibe.d if your CF ram is limited to 1024 MB. This is not enough to compile vibe.d. You have to change the compilation mode to single file. On Aws you can also use Lambda (nodejs), as Nodejs is able to start your D binary. Someone has written a D blog about this topic. I think it was about Amazon Alexa. There are obvious costs and also hidden costs on Aws. You have to run your scenario for an month and then check the actual costs... Kind regards André
Re: DMD license question
On Tuesday, 8 August 2017 at 14:28:30 UTC, meppl wrote: On Monday, 7 August 2017 at 21:28:52 UTC, Andre Pany wrote: Hi, as DMD is now under Boost Software License, can I distribute it as part of my commercial product? I want to provide script support within my application. The idea is to compile the scripts (D coding) to shared libraries and load the shared libraries into the main program. Kind regards André in case your main application is written in D, too: how do you avoid symbol name collisions? I think it would be nice to load shared libraries while runtime, but i cant, because the symbol names of the imports get duplicated which is not allowed. And D intentionally has no namespace-feature for this Yes, the main program is in D too. I haven't started prototyping yet, but as far as I know there are some limitations with D calling conventions. Therefore I plan to use Std calling convention instead. Kind regards André
Re: Who here uses vibe-s3 from code.dlang.org?
On Monday, 7 August 2017 at 22:46:57 UTC, aberba wrote: vibe-s3 (https://code.dlang.org/packages/vibe-s3) is an Amazon s3 object storage API for D. Has anyone here used or tested it? What was your experiences? It has the tagline "this library is highly alpha and mostly untested. use at your own risk". I created a generator which uses the JS Api definitions https://github.com/aws/aws-sdk-js/tree/master/apis to create D structs and classes. Instead of calling the rest interfaces the generated code is calling the AWS console client, which is available for most operation systems. Unfortunatelly I do not have the property on this library and therefore I am not allowed to release it. But I can say it was an matter of some hours to implement it and you have immediatelly access to all AWS services. Kind regards André
Re: DMD license question
On Monday, 7 August 2017 at 21:56:01 UTC, Joakim wrote: On Monday, 7 August 2017 at 21:28:52 UTC, Andre Pany wrote: [...] Yes, the idea of the Boost Software License is that you don't have to ask such questions. Boost allows you to do anything you want with the source, whether embedding, modifying, etc. and you don't have to ask anyone for permission or even mention that you're using someone else's software to your users, as the BSD advertising clause requires. [...] Thanks a lot for the information. Kind regards André
DMD license question
Hi, as DMD is now under Boost Software License, can I distribute it as part of my commercial product? I want to provide script support within my application. The idea is to compile the scripts (D coding) to shared libraries and load the shared libraries into the main program. Kind regards André
Re: [your code here] HexViewer
On Wednesday, 2 August 2017 at 22:02:49 UTC, Vladimir Panteleev
wrote:
On Wednesday, 2 August 2017 at 21:59:23 UTC, Vladimir Panteleev
wrote:
Good idea! But I think it needs more ranges:
The format call can be substituted with writefln directly:
void main(string[] args)
{
import std.algorithm, std.format, std.stdio;
enum cols = 16;
args[1].File("rb").byChunk(16).each!(chunk =>
writefln!"%(%02X %)%*s %s"(
chunk,
3 * (cols - chunk.length), "",
chunk.map!(c =>
c < 0x20 || c > 0x7E ? '.' : char(c;
}
Really cool:)
Kind regards
André
[your code here] HexViewer
This application opens the file passed as argument and display
the content in hex and text format:
00 00 03 00 00 00 64 00 00 00 FF 56 01 00 00 70
.....d... V..p
02 00 FF A6 00 00 00 20 02 00 00 00 00 00 00 00. ª...
...
00 00 00 00 00 00 00 00 00 00 00 00
void main(string[] args)
{
import std.file, std.string, std.range, std.array,
std.algorithm, std.digest, std.conv;
import std.stdio: writeln;
enum cols = 16;
auto data = cast(const(ubyte)[]) read(args[1]);
foreach(g; data.chunks(cols))
{
string hex = g.toHexString.chunks(2).join(" ").to!string;
string txt = g.map!(b => b == 0 ? '.' : char(b)).array;
writeln(hex.leftJustify(cols * 2 + (cols - 1), ' '), "",
txt);
}
}
Re: Annoying module name / typename conflict
On Sunday, 16 July 2017 at 09:01:46 UTC, kdevel wrote:
On Monday, 2 April 2012 at 22:20:13 UTC, bearophile wrote:
For DMD choosing one or the other is arbitrary. It's a defect
of the way the D module system is designed.
Ran into that problem with a Module S containing
module S;
import std.stdio;
struct S {
this (string s)
{
writeln ("S: " ~ s);
}
}
This code
// auto s1 = S("X"); // useS.d(6): Error: function expected
before (), not module S of type void
would not compile while
S s3 = "X"; // OK
works. Has this issue been filed in bugzilla?
You can avoid this issue at all by using lowercase characters in
module name only. This is also the offical naming guideline for
modules.
https://dlang.org/dstyle.html#naming_modules
Kind regards
André
Re: Dub
On Friday, 23 June 2017 at 10:38:23 UTC, Russel Winder wrote: 350 issues, 42 pull requests. I have to admit I am shocked. After looking at the dub code I have to say the code is well written and well structured. That makes it easy for the community to help solving bugs. My gut feeling is some features does not play well with other features. For example sub packages, path dependencies and the --single are essential features but do not play well together. Also people with NodeJS background demanding the same features NPM provides. As dub is now an essential part of DLang I hope the DLang Foundation could also spend some money to make dub even better. Kind regards André
Re: Please provide DMD as 64 executable
On Sunday, 21 May 2017 at 01:29:58 UTC, Laeeth Isharc wrote: On Friday, 19 May 2017 at 10:38:56 UTC, Andre Pany wrote: Should I file an issue for providing the 64 build of dmd on windows? As 64 bit is the default on the other platforms it should be available for windows too by default. Kind regards André We would find this useful too because we run out of memory on Windows. There may be a way to build dmd for win 64 as a script, but it wasn't obvious to me when I looked at it. There is a Visual D script, but I do not know how to use that using msbuild. Digger fails. I mentioned to Vladimir and Martin at dconf, but haven't had time to file an issue. Laeeth. I filed an issue https://issues.dlang.org/show_bug.cgi?id=17414 Kind regards André
Re: Please provide DMD as 64 executable
On Thursday, 18 May 2017 at 17:05:49 UTC, Vladimir Panteleev wrote: On Thursday, 18 May 2017 at 13:41:21 UTC, Andre Pany wrote: One issue is that digger does not support proxies If the problem is about git:// URLs, you can configure Git to use https:// instead of git:// globally: https://github.com/CyberShadow/Digger/issues/8 Otherwise, please file an issue at https://github.com/CyberShadow/Digger and the second issue is, there is an error while processing the VS community packages. VS integration is tested by CI: https://ci.appveyor.com/project/CyberShadow/digger/build/1.0.107#L1436 If you think there is indeed a problem there, please file an issue. I solved this issue by deleting the temp folders. Should I file an issue for providing the 64 build of dmd on windows? As 64 bit is the default on the other platforms it should be available for windows too by default. Kind regards André
Please provide DMD as 64 executable
Hi, is it possible to provide dmd as 64 download too for windows? I generated out of the Amazon Web Services API definitions D source code and always get this error message: "Fatal Error: Out of memorydmd failed with exit code 1." (There is really a space missing in the error text). I already split the source code files into several dub packages but still there are some really huge modules.. Also the tip to use digger to create it on my own does not work. One issue is that digger does not support proxies and the second issue is, there is an error while processing the VS community packages. I think the 64 bit version of dmd should be the default these days;) Kind regards André
Re: Low hanging fruit: dub git integration
On Wednesday, 17 May 2017 at 01:54:20 UTC, rikki cattermole wrote:
I've built a prototype UI[1] for some code[0] to solve this
exact problem.
It may seem complex, but you can't rely on HTTP download
options for easy access to repositories.
I would appreciate anyone taking the time to do the survey[1]
(the question mark) which has a couple of tasks to do. It'll
give you the basic idea of what I'm thinking UI wise.
[0]
https://gist.github.com/rikkimax/4718740223748256d94b3b1474525012
[1] http://cattermole.co.nz/comp626/
Same for me;) I build a little console application (100 lines of
coding) which I call instead of dub. It allows me to have
following dub.json
{
"name": "test",
"dependencies": {
"sample1": {"url": "http://localhost:8080/zapp-sample1.zip"},
"sample2": {"path": "C:\\D\\projects\\test\\zapp-sample2.zip"},
}
}
The console application downloads/extracts the zip files, makes a
backup of the original dub.json, creates a new dub.json with the
adapted path attributes, calls dub and after that restoring the
original dub.json.
If you want to use dub with git repositories and you can't for
one or the other reason use the public github / public dub
registry this feature is really nice.
Kind regards
André
Re: Low hanging fruit: dub git integration
On Tuesday, 16 May 2017 at 19:41:32 UTC, Brad Anderson wrote: On Tuesday, 16 May 2017 at 18:10:52 UTC, Andre Pany wrote: Hi, While integrating the git protocol into dub is complex, there is a much much easier solution. Github and bitbucket provides access to the source code, including releases, branches and commits as archive files using the http protocol. Without counting the actual unzip/untar coding I assume more or less 100 lines of additional coding is needed in dub. In dub.json in addition to the existing path attribute of the dependeny object a new attribute "url" has to be added. You can specify here an url to a zip/tar.gz. This file has to be downloaded and extracted. The extract path is then filled into the existing path attribute of the dependency object. The only issue is the untar/unzip logic... This little tweak would make dub a lot more flexible like npm. Kind regards André This is actually exactly how dub fetches source code but the registry does it rather than dub itself (I'm not sure why)[1]. A bare URL dependency may be controversial though because it makes versioning more difficult to ensure. 1. https://github.com/dlang/dub-registry/blob/d825840770bb29356495f265480035ed7e3321b8/source/dubregistry/repositories/github.d#L89 In my scenario I have github repositories stored on the company github server but not on the public github server. Also running an own dub registry server is not an option as I would have to adapt the source code (settings are hard coded) and the license type of dub registry is lgpl. Kind regards André
Low hanging fruit: dub git integration
Hi, While integrating the git protocol into dub is complex, there is a much much easier solution. Github and bitbucket provides access to the source code, including releases, branches and commits as archive files using the http protocol. Without counting the actual unzip/untar coding I assume more or less 100 lines of additional coding is needed in dub. In dub.json in addition to the existing path attribute of the dependeny object a new attribute "url" has to be added. You can specify here an url to a zip/tar.gz. This file has to be downloaded and extracted. The extract path is then filled into the existing path attribute of the dependency object. The only issue is the untar/unzip logic... This little tweak would make dub a lot more flexible like npm. Kind regards André
Re: Concerns about using struct initializer in UDA?
On Friday, 12 May 2017 at 19:33:52 UTC, ag0aep6g wrote:
On 05/12/2017 09:01 PM, Andre Pany wrote:
[...]
[...]
[...]
[...]
[...]
You can create the attribute separately:
enum Field a = { locationName: "B" };
@a int c;
Or if avoiding the extra symbol is more important than beauty,
call a function literal:
@((){ Field a = { locationName: "B" }; return a; }()) int c;
That's not as succinct as the syntax you propose, of course.
But your syntax (`@A = {locationName: "B"} int c;`) misses an
important detail: There's no indication what the type of the
attribute is (or is `A` supposed to be the type?). To make it
work, you will have to add that. Something like
`@Field(locationName: "B")` or `@Field{locationName: "B"}` or
whatever works.
At that point, why limit it to attributes? Constructors like
that would be nice everywhere. I remember such syntax being
discussed repeatedly, but I don't know where we stand. Maybe
there's a DIP already?
Yes, A is supposed to be the type. I have included the equal sign
to to match the existing struct initializer as far as possible.
I would like to limit the dip to increase the chances the dip is
accepted.
Kind regards
André
Re: Concerns about using struct initializer in UDA?
On Friday, 12 May 2017 at 10:25:07 UTC, Seb wrote: On Friday, 12 May 2017 at 10:13:02 UTC, Andre Pany wrote: Does it make sense to open a DIP? It would make UDA quite nice to use if you can group several attributes into a struct. Or someone know whether there are already known issues why it isn't possible? The entire point of a DIP is to do this research for everyone and summarize it an easy-to-access and easy-to-find fashion ;-) FWIW there is an abandoned DIP for in-place struct initialization (https://github.com/dlang/DIPs/pull/22) - it might make sense to invest the effort to revive it from the dead... If I find time I will create a new dip. The dip you mentioned is about a different usage scenario. My proposal is only about sructures used as UDA. As far as I remember the old dip was not possible due to comma syntax which is now in deprecation phase. Kund regards André
Re: Concerns about using struct initializer in UDA?
On Friday, 12 May 2017 at 10:23:34 UTC, Nicholas Wilson wrote:
On Thursday, 11 May 2017 at 10:49:58 UTC, Andre Pany wrote:
Hi,
I know there are concerns about struct initialization in
method calls but what is about struct initializer in UDA?
Scenario: I want to set several UDA values. At the moment I
have to create for each value a structure with exactly 1
field. But it would be quite nice if I could use struct
initialization to group these values:
struct Field
{
string location;
string locationName;
}
struct Foo
{
@A = {locationName: "B"} int c; // <--
}
void main() {}
Of course the syntax is questionable, it is just a proposal.
What do you think?
Kind regards
André
I'm not sure if it isi what you're looking for but you can do
struct Field
{
string location;
string locationName;
}
struct Foo
{
@Field("","B") int c;
}
We use this for our compiler recognised attributes in LDC, see
llvmAttr for an example
(https://github.com/ldc-developers/druntime/blob/ldc/src/ldc/attributes.d#L108)
I think there are cases where this syntax is more readable and
there are cases where struct initialization is more readable. In
the example you gave, I do not know what is the second field
about and having to mention the first field feels like a burden.
As developer I want the choice to decide between these 2 syntax
options.
Kind regards
André
Re: Concerns about using struct initializer in UDA?
On Thursday, 11 May 2017 at 11:57:01 UTC, Stefan Koch wrote: On Thursday, 11 May 2017 at 11:36:17 UTC, Andre Pany wrote: On Thursday, 11 May 2017 at 10:51:09 UTC, Stefan Koch wrote: On Thursday, 11 May 2017 at 10:49:58 UTC, Andre Pany wrote: [...] We have that syntax already. I do not understand. Should the syntax I have written already work as I expect or do you mean my proposal is not possible as the syntax is ambiguous? Kind regards André I thought it should have worked already. My apologies the struct literal initialization syntax is unsupported because of the parser implementation. I don't know if you would introduce new ambiguities; I suspect that you wouldn't. Does it make sense to open a DIP? It would make UDA quite nice to use if you can group several attributes into a struct. Or someone know whether there are already known issues why it isn't possible? Kind regards André
Re: Concerns about using struct initializer in UDA?
On Thursday, 11 May 2017 at 10:51:09 UTC, Stefan Koch wrote:
On Thursday, 11 May 2017 at 10:49:58 UTC, Andre Pany wrote:
Hi,
I know there are concerns about struct initialization in
method calls but what is about struct initializer in UDA?
Scenario: I want to set several UDA values. At the moment I
have to create for each value a structure with exactly 1
field. But it would be quite nice if I could use struct
initialization to group these values:
struct Field
{
string location;
string locationName;
}
struct Foo
{
@A = {locationName: "B"} int c; // <--
}
void main() {}
Of course the syntax is questionable, it is just a proposal.
What do you think?
Kind regards
André
We have that syntax already.
I do not understand. Should the syntax I have written already
work as I expect or do you mean my proposal is not possible as
the syntax is ambiguous?
Kind regards
André
Concerns about using struct initializer in UDA?
Hi,
I know there are concerns about struct initialization in method
calls but what is about struct initializer in UDA?
Scenario: I want to set several UDA values. At the moment I have
to create for each value a structure with exactly 1 field. But it
would be quite nice if I could use struct initialization to group
these values:
struct Field
{
string location;
string locationName;
}
struct Foo
{
@A = {locationName: "B"} int c; // <--
}
void main() {}
Of course the syntax is questionable, it is just a proposal.
What do you think?
Kind regards
André
Re: dubs: Getting into the Node scripts market
On Wednesday, 3 May 2017 at 12:16:30 UTC, rikki cattermole wrote: Actually there is a special syntax that is also used for shebang style scripts: `dub app.d arg1 arg2` is equivalent to `dub --quiet --temp-build --single app.d -- arg1 arg2`. It seems like the command line help wasn't really updated to reflect that, though. The only catch is that the .d extension is still required to make it possible to tell a script file name apart from a regular command. Well you could look for the normal command, if not found, try isFile with the extension if needed. Just a thought. Fantastic. The isFile enhancement is a minor thing but it would be great if this also could be added. Thanks:) Kind regards André
dubs: Getting into the Node scripts market
Hi,
it would be great if we can position D as replacement of Node
scripts. With the --single argument of Dub we have almost
everything we need in this scenario.
But one thing is very odd. If you want to execute the app.d
source file with dub you have to write: dub --single app.d
- You have to remember the argument --single
- You have to add the .d extension
- You do not like to have the binary created, therefore you have
to add --temp-build
- You do not like to have too much output, therefore you have to
add --quiet
- If you have application arguments you have to know to add -- at
the end followed by the application arguments.
With these limitations I cannot convince a Node developer to
switch to D.
I created a very small batch file dubs.bat which would have a
huge impact in this scenario.
You can execute the D source file with: dubs app
Application arguments are just appended: dubs app --PORT 8080
-- dubs.bat
@echo off
set _filename=%~n1
set _extension=%~x1
for /f "tokens=1,* delims= " %%a in ("%*") do set
_args_without_filename=%%b
IF "% _extension%" == ".d" (
set _sourceFile=%_filename%
) else (
set _sourceFile=%_filename%.d
)
dub run --temp-build --quiet --single %_sourceFile% --
%_args_without_filename%
-- dubs.bat
Do you think it makes sense to add this batch file and a linux
equivalent shell script to the D compilers?
Kind regards
André Pany
Re: DConf Hackathon Ideas
On Thursday, 27 April 2017 at 22:57:48 UTC, Moritz Maxeiner wrote: On Thursday, 27 April 2017 at 19:55:44 UTC, Andre Pany wrote: On Thursday, 27 April 2017 at 17:47:19 UTC, Moritz Maxeiner wrote: [...] As workaround this is possible. Every developer and in every continious integration build step, dub is used, you have to remember to use these arguments. Defining it one time in dub.json would be great. Alright, I take your point. Since the internal functionality itself is already there, this seems like an easy fix (just add a new field to the json/sdlang parsing of dub and bind it to what the CLI arguments already do). Have you opened a dub issue about this (first step to getting an issue fixed and so on), I wasn't able to find one on first glance? I created an issue in the dub github repository https://github.com/dlang/dub/issues/1119 Kind regards André
Re: DConf Hackathon Ideas
On Thursday, 27 April 2017 at 17:47:19 UTC, Moritz Maxeiner wrote: On Thursday, 27 April 2017 at 17:06:39 UTC, Andre Pany wrote: Another big issue for me is using dub in a company. Big companies do not want to use the official dub repository due to security issues. They want to run their own dub repository with dub packages they have done code checks. That means also the git projects are mirrored in git repositories within the company. First step into this direction is to have the possibility to specify the dub repository address within the dub.json. Is there a problem with just using the dub command line arguments for this? # cat > /usr/local/bin/company-dub #! /bin/sh /usr/bin/env dub --skip-registry=standard --registry=YOUR_COMPANYS_REGISTRY As workaround this is possible. Every developer and in every continious integration build step, dub is used, you have to remember to use these arguments. Defining it one time in dub.json would be great. Kind regards Andre
Re: DConf Hackathon Ideas
On Thursday, 27 April 2017 at 14:53:02 UTC, Mike Parker wrote: This year, DConf has an extra day tacked on for problem solving in the form of a hackathon. The intent is to work on issues people find frustrating in the D ecosystem. While there will be time given at the event for proposals, and those involving third-party projects are welcome, it will help speed things along for the organizers to come in with a list of big issues to get the ball rolling. To help in compiling the list, what are some major issues from the ecosystem that you'd like to see fixed? I would vote for getting the std.decimal proposal from the review queue into a good shape for std.experimental. Another big issue for me is using dub in a company. Big companies do not want to use the official dub repository due to security issues. They want to run their own dub repository with dub packages they have done code checks. That means also the git projects are mirrored in git repositories within the company. First step into this direction is to have the possibility to specify the dub repository address within the dub.json. Kind regards Andre
Re: Decimal/Currency Type
On Tuesday, 9 August 2016 at 10:48:50 UTC, Zane wrote: Is there such a thing build into D? If not, is there any plans to add it? It seems like this would be something needed by many applications (especially anything dealing with currency). Hi, the lack of a decimal type in Phobos is known and it is added to the vision list [1]. In addition to the dub package there is one in the review queue [2]. Also it seems there is a C package from IBM?, which could might be included into phobos via a binding. [1] https://wiki.dlang.org/Vision/2016H2 [2] https://wiki.dlang.org/Review_Queue Kind regards André
Re: Call to Action: making Phobos @safe
On Saturday, 25 June 2016 at 22:44:37 UTC, Walter Bright wrote: Andrei identified a key blocker for D adoption is the incomplete implementation of @safe. I'm working on the compiler end. But Phobos has a lot of code that is pointlessly not @safe, making it frustrating to write @safe code that calls Phobos. Some are listed in Bugzilla, most are not. So here's what to do: 1 Could we have a wiki page for this call to action? It would be much easier if there is a list of the modules and their current state like: completed or who is working on this module. In general the call to actions topics disappears too fast in a forum. Maybe it worths to add them to the contributions group in the wiki? Kind regards Andre
Re: Cross platform android ldc compiler
On Saturday, 18 June 2016 at 11:05:58 UTC, Jacob Carlborg wrote: On 2016-06-17 13:48, Andre Pany wrote: I think of a docker image containing ldc and all necessary dependencies for compiling an android/ios application. I think it's only possible to compile iOS applications on OS X and it's not possible to run OS X inside a docker container. You are right. I thought it would be possible to create ios applications also from a linux system. But as you need OS X, the docker approach isn't possible. Kind regards Andre
Re: Cross platform android ldc compiler
On Friday, 17 June 2016 at 12:26:18 UTC, Gerald wrote: On Friday, 17 June 2016 at 11:48:23 UTC, Andre Pany wrote: Hi, I want to share an idea with you. I do not know how far I will come myself with this idea due to my lack of linux and ldc knowledge. There is a great virtualization tool called docker. With this tool it is possible to create images of software tools. This images will run out of the box on every system (mac/linux/windows). I think of a docker image containing ldc and all necessary dependencies for compiling an android/ios application. The D source code you can store in a shared directory between your host system and the docker virtual system. The docker image could in addition provide a web interface to start the compilation/linking process. In the end, if you have the docker image, you will have s.th. like a "D android compiler as a service" which works on every major operation system. Just install docker and select the image from the free docker marketplace. Docker doesn't run natively on Windows and OSX, it requires a VM such as VirtualBox, since it depends on linux kernel features like cgroups. IMHO, a better solution for a development environment then docker would be Vagrant (https://www.vagrantup.com) as this is the sort of use case it is designed around and it is based on VMs from the get-go (though it can work with docker as a provider as well), For windows and mac VirtualBox is included in the docker installation routine. Most users won't even notice Virtual Box is working behind the scene of docker. Last time I checked vagrant, I thought vagrant is a generator for virtual box images, but i will check again and include it into my research. Kind regards Andre
Cross platform android ldc compiler
Hi, I want to share an idea with you. I do not know how far I will come myself with this idea due to my lack of linux and ldc knowledge. There is a great virtualization tool called docker. With this tool it is possible to create images of software tools. This images will run out of the box on every system (mac/linux/windows). I think of a docker image containing ldc and all necessary dependencies for compiling an android/ios application. The D source code you can store in a shared directory between your host system and the docker virtual system. The docker image could in addition provide a web interface to start the compilation/linking process. In the end, if you have the docker image, you will have s.th. like a "D android compiler as a service" which works on every major operation system. Just install docker and select the image from the free docker marketplace. Kind regards André
Re: 10 lesser known languages, but no dlang?
On Wednesday, 8 June 2016 at 10:08:11 UTC, Ola Fosheim Grøstad wrote: http://programmingzen.com/2016/06/07/10-lesser-known-programming-languages-worth-exploring/ Maybe someone feel the inspiration to add a thoughtful comment in the comment-section on the article with a pointer to dlang.org? On the other side, maybe D is not mentioned, because it belongs in the meantime to the more known languages :) That would be a good sign. Kind regards André
Re: Andrei's list of barriers to D adoption
On Tuesday, 7 June 2016 at 05:38:25 UTC, H. S. Teoh wrote: On Tue, Jun 07, 2016 at 05:39:37AM +, ketmar via Digitalmars-d wrote: On Monday, 6 June 2016 at 05:49:53 UTC, Ethan Watson wrote: > Echoing the need for decimal support. I won't use it myself, > but I know it's critical for finance. funny thing: those "financial sector" most of the time doesn't give anything back. adding special decimal type complicating the compiler and all backends. i myself never needed that for my whole lifetime (and this is more than two decades of programming, in various free and commercial projects). [...] A Decimal type isn't hard to implement as a user-defined type. I don't understand the obsession with some people that something must be a built-in type to be acceptable... user-defined types were invented for a reason, and in D you have the facilities of making user-defined types behave almost like built-in types in a way no other language I know of can. Same thing goes with a fixed point type. People keep complaining about it, but honestly if I were in the finance sector I'd implement the type myself in a couple o' days and put it up on code.dlang.org or something. It's not *that* hard. T In my opinion passionate D developer will build the missing parts themselves. I also developed my own decimal library. But the developers starting with D and which rather want to build content instead of the missing parts won't. Also there is a much higher trust if a library is provided within phobos than provided from a single person in terms of long time support. Kind regards Andre
Re: Andrei's list of barriers to D adoption
On Monday, 6 June 2016 at 22:21:45 UTC, jmh530 wrote: On Monday, 6 June 2016 at 21:28:14 UTC, Walter Bright wrote: The reason is that otherwise, you've just limited your apps to handling a maximum amount of $21,474,836.48. I wouldn't mind running into that problem :-) It's really not that hard when you consider that many institutional investors wouldn't even consider investing in mutual funds with that amount under management. Vanguard has mutual funds with 100+ billion. I imagine their NAV (net asset value) calculations have to be exact to dollars/cents too. In addition to the finance sector there are also a lot of other industries which depends on decimals, e.g. all industries dealing with sensors and measurements. The requirements for them (precision and scale) are very different. There could be very small values with a lot of numbers after the decimal separator, which needs to be exact. Kind regards André
Re: Andrei's list of barriers to D adoption
On Monday, 6 June 2016 at 06:29:27 UTC, Andrei Alexandrescu wrote: On 6/6/16 6:17 AM, Andre Pany wrote: to be usable for companies which want to create economic software, in my opinion D lacks std.decimal. Do C, C++, Java, Go, or Rust have a standard decimal type? -- Andrei With java 7 there is the big decimal library in java: https://docs.oracle.com/javase/7/docs/api/java/math/BigDecimal.html Kind regards André
Re: Andrei's list of barriers to D adoption
On Monday, 6 June 2016 at 02:20:52 UTC, Walter Bright wrote: Andrei posted this on another thread. I felt it deserved its own thread. It's very important. - I go to conferences. Train and consult at large companies. Dozens every year, cumulatively thousands of people. I talk about D and ask people what it would take for them to use the language. Invariably I hear a surprisingly small number of reasons: * The garbage collector eliminates probably 60% of potential users right off. * Tooling is immature and of poorer quality compared to the competition. * Safety has holes and bugs. * Hiring people who know D is a problem. * Documentation and tutorials are weak. * There's no web services framework (by this time many folks know of D, but of those a shockingly small fraction has even heard of vibe.d). I have strongly argued with Sönke to bundle vibe.d with dmd over one year ago, and also in this forum. There wasn't enough interest. * (On Windows) if it doesn't have a compelling Visual Studio plugin, it doesn't exist. * Let's wait for the "herd effect" (corporate support) to start. * Not enough advantages over the competition to make up for the weaknesses above. Hi, to be usable for companies which want to create economic software, in my opinion D lacks std.decimal. Maybe some companies will develop their own decimal libraries but for the others they won't. There is some great work, but currently it seems to be blocked by std.bigint https://github.com/andersonpd/eris/issues/6 For the tooling I can only speak for windows environment. To have a sophisticated IDE, the DLL topic needs some love. DLL are a major topic on windows and without sophisticated DLL support, it is hardly possible to build an integrated IDE similar to the well known like Visual Studio/Delphi/... One major issue I faced, I create a class in a DLL and cannot cast the class in my main application to another type due to the missing type info. The workaround would be to have massive code duplication, which makes the code more complex. Also here some great work are already done but blocked by the "export semantic" topic. Kind regards André
Benjamin Thaut's talk: D's Import and Export Business
Hi, after looking Benjamins talk I took some time to think about it. Benjamin made some effort towards a sophisticated DLL suppport for D. What I understand: He won't push his changes until "export" will become an attribute. But without his changes there is no need to change the semantic of "export". It seems like a deadlock. I tried to find a solution to this problem. For the moment I ignore the export issue and have a look at linux. I understand in linux everything is exported by default. If it is decided, that this default behavior is changed in the long term, there needs to be a way to switch batch to the old behavior. Therefore a compiler switch "exportAll" will be necessary. So why do not start with this compiler switch, which will also export all symbols on windows. If the changes of Benjamin are adapted to this switch we can already get the sophisticated dll support and can later decide on the semantic change of export. Does this make sense? Kind regards André
