Where to buy the official DLang shirt?
Hi, Is there an official DLang shirt, i can buy? I work in a software company and would like to make some advertisement for D. The profit for marketing articles like the shirt e.g. could be used for the DLang foundation. This would be a nice way to donate some money. Kind regards Andre
Re: Marketing for D: Making D an official Cloud Foundry built-in language
On Saturday, 10 October 2015 at 02:49:23 UTC, Rikki Cattermole wrote: [...] Wrong way round. Bundle dub with dmd is already planned. I hoped 2.069 already contains dub, maybe with 2.070 [...] I am sure Walter will have no problem with you creating a custom archive, perhaps with tar? If that suits you better. Check with him however. [...] That may not be possible. Unless you want to make dub dependent upon git. Which it currently isn't. Right now it uses e.g. Github to create an archive of the repository and download that. Although some trade off will be possible. Also it all goes through code.dlang.org the last I remember. yes it would depend on git. I suggest a new dub attribute. The value starts with a protocol. Like file:// if it is a zip on the local pc or a file on a file server. git:// if it is a git repository. [...] It exists, the support is there. Just not in the dub configuration file. It is something that would be nice to have. This feature would also be a "work around" for 4). I will file feature requests
Marketing for D: Making D an official Cloud Foundry built-in language
I want to share my experiences with making marketing for D. At the company I am working for, Cloud and Cloud Foundry is a big thing. At the office github there are several coding examples how to develop applications for the languages Cloud Foundry supports out of box: Java, Node.js, Ruby, Go, PHP and Python. I decided to also develop a coding example in the D Language to make some marketing for D. Unfortunately it was not added directly to the coding examples, because it is not an official Cloud Foundry language. Using a third party buildpack it is possible to also support D but the marketing effect for D would be huge if it would be listed as official supported language. Short explanation for buildpack: Cloud Foundry gives your application an environment which is prepared by using 3 shell scripts called the buildpack. You only upload the D source code to Cloud Foundry. In Cloud Foundry dmd / dub ... are downloaded and executed to compile your application. There are some prerequisites which would maximize the chance for D to become an official CF language: 1. Easy installation: Bundle dmd with dub The buildpack coding should be small and easy. At the moment dmd and dub must be downloaded from different places to different cache folders, extracted with different tools... 2. Stable link to last released dmd Is there an archive link, always pointing to the last released dmd archive? Instead of always adapting the buildpack, a stable link to the recent dmd archive would be a great benefit 3. Fast installation: Currently the dmd zip is about 60 Mb. The download size doesn't matter that much, because it is downloaded once and then cached. But it must be unzipped on every push of the application. This makes the push slow. Could be a minimized archive provided, with only these files absolutely necessary to compile a D application? 4. Dub support for git repositories I wrote a http/OData library in the office and uploaded it to the company internal github. The buildpack shell script loads in addition to the dmd and dub archive also this git repository and added it to DUB with command "add-local". This is a bad hack, but I cannot publish it on code.dlang.org due it is an company internal library. I wish dub would support to specifiy a git repository. With this feature, you could push d applications to Cloud Foundry which either uses a http engine from code.dlang.org (vibe-d with libasync) or in a company scenario, from an internal git repository. 5. Dub support for package registries other than code.dlang.org Either by manipulation a DNS or by taking over code.dlang.org or an github repository, an attacker could insert malicious code into your application. To reduce the attack vector, companies have their own package registries with proven packages. I would like to specify in dub.json which package registries, DUB will load the packages from. Kind regards André
Re: Experience: Developing Cloud Foundry applications with D
On Tuesday, 6 October 2015 at 09:36:42 UTC, Marc Schütz wrote: On Tuesday, 6 October 2015 at 05:45:18 UTC, Andre wrote: vagrant@vagrant-ubuntu-trusty-64:~/projects/tests/vibed_test$ dub Target memutils 0.4.1 is up to date. Use --force to rebuild. Target libasync 0.7.5 is up to date. Use --force to rebuild. Target vibe-d 0.7.25 is up to date. Use --force to rebuild. Building vibed_test ~master configuration "debug", build type debug. Compiling using dmd... Enhanced memory security is enabled. Using Linux EPOLL for events Linking... Running ./bin/app Listening for HTTP requests on :::8080 Listening for HTTP requests on 0.0.0.0:8080 E: Could not mlock 65536 bytes Does it keep running? AFAIK, the last line is just a warning from the botan library that attempts to allocate non-swappable memory for holding secret keys etc. I got it working. *Argh* I forgot the command parameter in the cloud foundry manifest file. vibe-d is working fine, out of the box in cloud foundry with libasync :)
Re: Experience: Developing Cloud Foundry applications with D
On Monday, 5 October 2015 at 15:51:09 UTC, Andre wrote:
On Sunday, 4 October 2015 at 23:34:58 UTC, Rikki Cattermole
wrote:
On 05/10/15 8:13 AM, Andre wrote:
Vibe.d has a provider called libasync. Libasync is fully
implemented in D. You probably should have tried that at least.
Although I still would recommend trying it ;) It's a lot
better then what we have in Phobos.
Looks good, it seems all external dependencies issues are gone
for vibe-d on Cloud Foundry. I haven't a working test
application so far but I think the issue is now releated to the
correct bind address in a Cloud Foundry environment.
As far as I understand vibe-d is not runnable out of the box in
Cloud Foundry.
I cannot point directly to the issue, I just get the information,
that the
test application does not accept connections during a health
check run in the log file.
My simple test application is the example from the homepage
except,
that the port is read from the environment variable PORT.
import vibe.d;
shared static this()
{
import std.process: environment;
auto settings = new HTTPServerSettings;
settings.port = to!ushort(environment.get("PORT", "8080"));
listenHTTP(settings, &handleRequest);
}
void handleRequest(HTTPServerRequest req,
HTTPServerResponse res)
{
if (req.path == "/")
res.writeBody("Hello, World!", "text/plain");
}
I assume some issues with memutils, but have no chance to
validate this.
What I can see, if I run the application in my virtubox (Ubuntu)
instead
of the Cloud Foundry, I get following reponse:
vagrant@vagrant-ubuntu-trusty-64:~/projects/tests/vibed_test$ dub
Target memutils 0.4.1 is up to date. Use --force to rebuild.
Target libasync 0.7.5 is up to date. Use --force to rebuild.
Target vibe-d 0.7.25 is up to date. Use --force to rebuild.
Building vibed_test ~master configuration "debug", build type
debug.
Compiling using dmd...
Enhanced memory security is enabled.
Using Linux EPOLL for events
Linking...
Running ./bin/app
Listening for HTTP requests on :::8080
Listening for HTTP requests on 0.0.0.0:8080
E: Could not mlock 65536 bytes
Re: Experience: Developing Cloud Foundry applications with D
On Sunday, 4 October 2015 at 23:34:58 UTC, Rikki Cattermole wrote: On 05/10/15 8:13 AM, Andre wrote: Vibe.d has a provider called libasync. Libasync is fully implemented in D. You probably should have tried that at least. Although I still would recommend trying it ;) It's a lot better then what we have in Phobos. Looks good, it seems all external dependencies issues are gone for vibe-d on Cloud Foundry. I haven't a working test application so far but I think the issue is now releated to the correct bind address in a Cloud Foundry environment.
Re: Experience: Developing Cloud Foundry applications with D
On Sunday, 4 October 2015 at 22:47:46 UTC, Vladimir Panteleev wrote: On Sunday, 4 October 2015 at 19:13:58 UTC, Andre wrote: I tried different http servers available for D. One more (my own): https://github.com/CyberShadow/ae/tree/master/net ae.net is used on: - http://forum.dlang.org/ - http://dtest.thecybershadow.net/ - Digger's local web UI - (other projects not related to D) Thanks a lot. Unfortunatelly in the office I have to avoid MPL licensed libraries if possible due to legal reasons ):
Experience: Developing Cloud Foundry applications with D
I want to share my experiences with D and the platform as a service solution Cloud Foundry. Cloud Foundry supports any development language as long it is runnable on Linux 64 bit and the application has a http Server listening on a port which Cloud Foundry provides you using system environment variable PORT. I am used to develop on Windows. Using VirtuaBox I created a Linux virtual machine. I defined a shared directory between my windows host system and the Linux virtual machine. In Addition I use Putty as SSH client. In the Putty terminal I execute dub and after that the Cloud Foundry console application to push the binary to the cloud. I tried different http servers available for D. At the end I decided to build my own. vibe-d: The linking time of a vibe-d application on a Linux system is quite high, I think this is due to the dependencies like pthreads and so on. Also the binary size is also quite high. As far as I remember around 20 mb for a test application. The size matters as you have to upload the application again and again. Cloud Foundry provides some shared objects libraries. In case you have special requirements like pthreads you must create a build pack. With a build pack you can download external dependencies and install them while pushing the binary to the cloud. There already exists build packs for vibe-d but they are outdated. They run a long time and then stops. From windows I know vibe-d is a great library but on Linux out of the box it doesn't make fun due to the usage of external dependencies. I also had a look at the arsdnet http server. But I didn't achieved to get my scenario running. In addition to my http server component I have a thread which executes 10 some database calls and some http requests. If I am not completely wrong the scenario of starting a thread in addition to the main server thread is not supported unless I duplicate a big amount of coding from the template "main" of the arsdnet http server component. In the end I build my own very simple http server component. By using the pure phobos library compiling and linking is super fast and the size of the full application is around 8 mb. Compile, link and pushing to the cloud is possible in less than a minute. In sum, it is just fun to develop cloud applications with D!
Re: std.typecons: PrimitiveRef
On Tuesday, 24 March 2015 at 16:58:48 UTC, Gary Willoughby wrote:
On Tuesday, 24 March 2015 at 15:38:04 UTC, Andre wrote:
The use case is a type tuple where you cannot use the keyword
ref.
Could template alias parameters not be used here?
http://dlang.org/template.html#aliasparameters
Event is defined as struct Event(T...){}.
That way the actual number of parameters is very flexible.
I just checked template alias parameters. Also here the ref
keyword
is not allowed:
struct Event(alias x)
{
private void delegate(x)[] _dlgArr;
}
Event!(ref bool) onEvent;
Error is thrown: expression expected not ref.
Kind regards
André
std.typecons: PrimitiveRef
Hi,
Namespace helped me to get following template working.
struct PrimitiveRef(T)
{
private T* _value;
@property
ref inout(T) get() inout pure nothrow {
assert(_value);
return *_value;
}
alias get this;
this(T val) {
_value = new T(val);
}
}
The use case is a type tuple where you cannot use the keyword ref.
Example usage: ( This is an extract from a little event framework)
Event!(Object, BoolRef) onClose;
onClose.attach(&onFormClose); // function or delegate
void onFormClose(Object o, BoolRef canClose)
{
canClose = false;
}
I think it is useful to add to std.typecons as there is no
possibility
to use ref for type tuples.
Kind regards
André
Re: std.typecons: PrimitiveRef
Definition of BoolRef: alias BoolRef = PrimitiveRef!bool;
Re: Problem with coupling shared object symbol visibility with protection
Hi, I also want to say a big thank you to all of you involved in this topic and especially to Benjamin. Proper DLL handling in D I would really appreciate. I think this topic is the break through. Kind regards André On Tuesday, 17 February 2015 at 18:03:06 UTC, Benjamin Thaut wrote: So i looked at the Dll Test within the dmd test framework and when I make export an attribute, like I suggested, this perticular test will compile & run without any code changes. This is another reason why I suspect that making export an attribute will only break very little if any code at all. Am 16.02.2015 um 09:08 schrieb Walter Bright: At this point I suggest simply making those private helper functions public and export them. It gets your project moving without waiting for language changes (and this is a breaking change). I have to big fears with doing this 1) I finish everything up any finally do the pull request. Then the reviewers will realize that using export in all required places will completely undermine D's module level protection system and reject the PR. Then all my work is in vain. 2) Even if 1 does not happen, that means from now on the broken export will be used in _actual_ code. Because it kind of works. Going forward this would mean that changing export into an attribute will break actual production code. So in my opinion we have to implement Dll Support on windows and fix export simulatiously, otherwise fixing export will lead to big breaking changes instead of a few small ones. Kind Regards Benjamin Thaut
Re: D 2.066.1: Assertion failure: '0' on line 2022 in file 'mtype.c'
I will create a issue for this. The minimized version is:
enum DummyStringEnum
{
foo = "bar"
}
class Test
{
@property DummyStringEnum e()
{
return DummyStringEnum.foo;
}
}
void main()
{
import std.json;
JSONValue[string] jsPayload;
jsPayload["A"] = __traits(getMember, new Test(), "e");
}
Kind regards
André
On Monday, 10 November 2014 at 12:34:11 UTC, Daniel Murphy wrote:
"Andre" wrote in message
news:qaknrsxlgbgzkhljv...@forum.dlang.org...
Based on the location of the error, I'd guess it's to do with
passing a delegate to a templated function / as a template
argument. (but it's possible it's not a delegate)
To find the error:
- Run dmd with '-v', it should tell you which function it was
compiling when it crashed (the last one it lists). Once you
know the function it should be easier to determine which bit of
code causes the crash.
- Or use dustmite to reduce the test case.
Re: 'partial' keyword in C# is very good for project , what's the same thing in D?
One requirement for a partial alternative is, that the generated
coding can access private member of the actual class as they are
in most GUI framework private members of the class.
class Example
{
private Button b;
private ComboBox cb;
}
The GUI framework takes care about calling their constructors and
also about persisting their design time values (values you read
and write in the GUI builder).
Is there any possibility to access private members by using
Template Mixins?
As far as I can see only String Mixins are able to access private
members of the scope they are inserted to.
Kind regards
André
On Monday, 10 November 2014 at 14:38:58 UTC, Jacob Carlborg wrote:
On 2014-11-10 11:21, Regan Heath wrote:
Basically it's just a good idea(TM). Unfortunately as many
have said,
it's not something D2.0 is likely to see. String mixins
aren't the
nicest thing to use, but at least they can achieve the
same/similar thing.
Template mixins can be used instead. Looks a lot better.
D 2.066.1: Assertion failure: '0' on line 2022 in file 'mtype.c'
Hi, after the update from 2.066 to 2.066.1 DMD gives following output: Assertion failure: '0' on line 2022 in file 'mtype.c' abnormal program termination Unfortunatelly I do not know how to create a reproducible example as the error occurs in a huge application. DMD doesn't give me more information. I try to find out more (reproducible example). Kind regards André
Re: 'partial' keyword in C# is very good for project , what's the same thing in D?
From some little tests I can say only string mixins are working for the GUI builder scenario. The concrete class contains private ui controls (members). The gui builder framework needs to access these private members to call their constructors, and set their values to the last persisted state. template mixins aren't able to access these private members. I also think alias this and opDispatch do not help here. string mixins working perfectly. partial would be a really nice feature but I also doubt that it will come with D2. Kind regards André On Wednesday, 29 October 2014 at 23:23:40 UTC, Walter Bright wrote: On 10/29/2014 7:01 AM, Gary Willoughby wrote: On Wednesday, 29 October 2014 at 12:55:01 UTC, FrankLike wrote: The same thing in D should be done,now.Otherwise，no big projects can be done like C#. Add another keyword,and update the compiler. Large projects are already being developed using D so your argument is wrong. Also no new keywords are being added to the language because D is trying to achieve stability right now. You can achieve what you desire using mixins. Either string mixins, template mixins, alias this or opDispatch.
Re: Runtime type information
I just saw, there is also dip 8. As a suggestion, instead of a compiler switch , we could introduce an interface IPersistent. By implementing this interface in your actual class, rtti would be available/generated. What do You think? Kind regards André On Thursday, 9 October 2014 at 16:15:08 UTC, andre wrote: Hi, I just stubmled over an enhancement in object_.d and object.di Benjamin Thaut described on his page: http://3d.benjamin-thaut.de/?p=25#more-25. The enhancement looks quite good and handy for me and would be a quick win to have some more runtime type information in the language. Does it worth to create a pull request? Kind regards André
Runtime type information
Hi, I just stubmled over an enhancement in object_.d and object.di Benjamin Thaut described on his page: http://3d.benjamin-thaut.de/?p=25#more-25. The enhancement looks quite good and handy for me and would be a quick win to have some more runtime type information in the language. Does it worth to create a pull request? Kind regards André
Dlls on Windows?
Hi, As far as I know there are some issues with dlls on Windows (D dlls used in D applications) in contrast to linux.There are some (unfinished) pull requests, and some ideas. It would be great if You can give an update on this topic. Maybe the Wiki page for Dlls on Windows can be updated with the current limitations/ updated information. Is there any agenda to support the same functionality like on linux? Kind regards André
Re: Qt Creator and D
Which is the latest Qt Creator version you successfully built the plugins for? Thanks & regards André I built the plugins for QtCreator 3.1.1 and 3.1.2 (Qt >= 5.0.1). Yep, for QtCreator's master (3.2.81) compilation failed and I fixed it. I think the plugins can be successfully built now. I am not able to test it right now, but I will try plugins with master in the nearest future. Before I saw that you already fixed the build I tested your plugins with QtCreator 3.1.1. Nice work so far! I really like that the project manager plugin is based on DUB because it seems to have become the de-facto standard for D. I already have some features on my wish-list ;-) - Enable Locator/Ctrl+K support for quick symbol access - Outline/class view for project and current document - Tooltip with symbol information when hovering in text editor Hopefully I will have some time in the near future to be able to create some pull requests. Currently you have two separate plugins for project manager and editor; what do you think about only one, integrated plugin? It might be easier for users to have one plugin which contains everything. Especially if more parts might be integrated (Locator etc.). Anyway keep up the good work! Regards André
Re: Why no contracts for release build?
Am 04.06.2014 16:23, schrieb Martin Krejcirik: On Wednesday, 4 June 2014 at 13:48:04 UTC, Andre wrote: I currently wonder what is included by adding no switch to DMD? default (no switch) = asserts, contracts, boundscheck=all -debug = include code marked with debug keyword -unittest = include unittests -g = include debug info -release = do not include asserts, contracs, boundscheck=safeonly, some switch optimizations -boundscheck option can override -release option for turning on or off all bounds checking (there is deprecated -noboundscheck in 2.065 or earlier) thanks a lot for these informations, exactly what I need. Kind regards André
Re: Why no contracts for release build?
Am 03.06.2014 23:43, schrieb Sean Kelly: I think the problem is that "release" is a misnomer, because the presence of contracts has nothing to do with whether you're deploying a test or release build. For all the talk of how we should be profiling our code to find the trouble spots instead of prematurely optimizing, the release flag, by virtue of its name, exists as a giant red button we're all expected to press for "performance" or whatever before deploying our software for use in the first instance where safety actually matters. As for the idea that contracts simply aid in finding logic errors during testing... for testing to have any validity the test must be performed on the same build that will be released to the public. And the idea that testing will ever find all the problems that might occur in the field is laughable. In short, pretend "release" says something like "unchecked" and think hard before actually setting it in real code. Yes you are right. For my product "released" to customer, as business application developer, I am more focused on safety and less on performance. If in any case a customer is doing s.th which can be caught by contracts then it should be caught. Therefore the release switch is really dangerous. What I really want is a switch "stable", which contains all safety relevant features like Contracts/Asserts and so on. But this build should exclude debug information etc. I currently wonder what is included by adding no switch to DMD? > dmd main Kind regards André
Re: Why no contracts for release build?
Am 03.06.2014 19:13, schrieb Jonathan M Davis via Digitalmars-d:
On Tue, 03 Jun 2014 16:29:20 +0200
Andre via Digitalmars-d wrote:
Hi,
I currently think about whether or not contracts should be available
in release builds.
Assuming a small example, you have an account class with a deposit
method, the input parameter must always be > 0.
void deposit(int amount)
in
{
enforce(amount > 0);
}
body
{
this.amount += amount;
}
If in release build the Contracts sections is removed, this means, I
also need to add in addition in another place the enforce method.
Otherwise in the productive scenario, this coding isn't secure
anymore. This leads to code duplication.
I think Contracts are not a feature solely for unittests, they are a
fundamental part of classes/interfaces and theirfore should be
available in all builds.
What do you think?
Contracts are specifically intended for validating the input and output
of a function with assertions. So, they're going to go away in any
build that does not have assertions enabled. Contracts are very much
the wrong place to use enforce. enforce throws an Exception and does
not get compiled out. It is intended for error-handling rather than for
validating the correctness of your code.
- Jonathan M Davis
As I known that assertions are only for unittest purposes I hoped,
if I use enforce, this statements will not be removed in release build
and will still be executed - wrong.
I see, the idea of contracts in D differs to the idea of contracts e.g.
in Java (http://c4j-team.github.io/C4J/
Here contracts are used for unittest but also for the productive code
in release builds.
I thought about writing a Contracts library, which works similiar to C4J
but I see no chance to solve this issue without AST.
Kind regards
André
Why no contracts for release build?
Hi,
I currently think about whether or not contracts should be available
in release builds.
Assuming a small example, you have an account class with a deposit
method, the input parameter must always be > 0.
void deposit(int amount)
in
{
enforce(amount > 0);
}
body
{
this.amount += amount;
}
If in release build the Contracts sections is removed, this means, I
also need to add in addition in another place the enforce method.
Otherwise in the productive scenario, this coding isn't secure anymore.
This leads to code duplication.
I think Contracts are not a feature solely for unittests, they are a
fundamental part of classes/interfaces and theirfore should be available
in all builds.
What do you think?
Kind regards
André
Contracts: Potential for improvements
Hi, after I attended a session for C4J (Contracts for Java) I revisited the contracts functionality in D. I tried to develop a very small example and failed early. It seems just by using interfaces for your class, contracts stopped working silently. By reading the bug reports for contracts https://issues.dlang.org/buglist.cgi?quicksearch=in%20contract%20interface it seems there are serious issues when you use interface or inheritance. As Contract Programming is mentioned as the first item in the DLang Reliability feature list there should be a roadmap to get this feature working again. Kind regards André
Re: Mass-enabling D => License question
On Wednesday, 21 May 2014 at 09:25:56 UTC, Jacob Carlborg wrote: On 21/05/14 09:50, Joakim wrote: Yes, but they moved to the UIUC-licensed (basically the BSD license) llvm eventually, partially because they wanted Xcode to directly link against it. I think it's that kind of integration that Andre and Max have in mind, though as John noted, they're not particularly precise about what they want. That's a completely different thing. I would like to see someone try doing that with DMD ;). I assume they didn't want to do that since that feels quite unrealistic at this stage, DMD is not really meant for this type of integration. The delphi ide is able to create components which coding runs during design time in the ide. My idea for s.th. Like that is to compile d code to dll and during runtime load it into the ide. But as far as I understand this could also be made as external toolchain call to DMD which is also allowed with the license. Kind regards andre
Mass-enabling D => License question
Hi, I like D due to its clear syntax and power. For a business application developer what is really missing is a full blown IDE which enables Rapid Application Development. => GUI => Database => Internet components => Refactoring => ... and a lot things more If I compare the time I need to develop a D application and a delphi application there are several weeks between unfortunatelly (my experience). I wonder whether it is possible from a license point of view to develop an IDE for D and sell it? Of course there are license issues due to fact that D must be integrated in the package but someone would only pay for the IDE. On the other side, a good IDE will mass enabled D for business application developer. If someone will create an IDE for D like Borland has done for Delphi this would lead to an huge success for D in my opinion. What do you think? Would you appreciate such an IDE? Kind regards André
Future of D Interface Files?
Hi, what is the future of D interface files? Somehow they work except for new features package.d files or @properties. I got the information that D interface files shouldn't be used anymore as this functionality is outdated/broken (d.D.learn) On the other side this seems like a big missing base feature of D if I cannot create *.lib files and ship the D interface files. (Closed source, payed lib files...) Are there plans to make them fully available again in the future? Kind regards André
