Re: Bug in -J
On Saturday, 12 August 2017 at 06:02:57 UTC, Vladimir Panteleev
wrote:
Sounds reasonable, the compiler could check if paths start with
a -J path.
There is a potential ambiguity here:
dmd -Jsomedir test.d
test.d: import("somedir/file.txt");
Does the user mean to import "somedir/file.txt" or
"somedir/somedir/file.txt"? Currently the latter is understood.
Simply checking for path prefix would break this case. I guess
this could be done only with absolute paths, but that introduces
an inconsistency with relative paths. I'm not sure it's worth it,
considering it's easy to work around.
Re: Bug in -J
On Saturday, 12 August 2017 at 05:42:21 UTC, Mr. Pib wrote:
I'm pretty sure that on no OS does the same location mean
different things?
I understand what you mean, but just to clarify on the .. thing:
$ mkdir d d/x d/z
$ ln -s d/z x
$ echo foo > d/z/y
$ echo bar > d/x/y
$ cat x/y
foo
+ cat x/../x/y
bar
I am not talking about strange stuff but simple stuff.
I have code that loads a file at runtime and requires the
absolute path. This is only for debugging purposes. When built
in release, everything is switched over to use imports and
embed the files in the binary. The same path is used for other
things like caching/uniqueID but are never actually read from.
You see this sort of stuff a lot when you open an executable
and see hard coded paths but obviously never used for file
system purposes.
Sounds like you can also work around it using e.g.
enum appRoot = `C:\Temp\`;
debug
string data = readText(appRoot ~ "a.dat");
else
enum data = import("a.dat");
(and build with -JC:\Temp).
That should now also work if a.dat is in a subdirectory relative
to the -J path.
The files and paths are all the same but import doens't seem to
think so. Adding baseName solves the problem immediately but
that is a hack. import should know that the path is the same as
the one specified by -J. The whole point of -J is to specify
the path for security purposes, right? So why does it matter if
I use path\filename or baseName(filename)? Both point to the
same location and both are consistent with -J, import should
understand that. It is an obvious oversight. But there is an
obvious programmatic difference between the two versions.
Luckily, using baseName does fix the problem so it is not a
huge deal but it is still a bug/issue with import for being
ignorant of what it is actually doing.
Sounds reasonable, the compiler could check if paths start with a
-J path.
Re: Jetbrains announce support for rust plugin, show them we want one too!
On Friday, August 11, 2017 08:13:07 SC via Digitalmars-d wrote: > On Wednesday, 9 August 2017 at 22:17:42 UTC, Jonathan M Davis > > Regardless, we're here because we want a quality language, not > > because we want a popular one. We just hope that those two > > things aren't mutually exclusive. > > i agree about quality part, but you mix two things, popularity > and the need of tooling > > the point of my post was to gather community in hope for better > tooling, not popularity > > having great tooling might increase popularity, but for me it'll > improve my productivity, and that's all i care about, popularity > is next, quality is already nice for me Good tooling is important, but it differs significantly from person to person which sets of tools matter or would be useful, and I think that to a great extent, the core developers have the tooling that they're looking for. I'm sure that if we had to come up with a list of things that we'd like to see improved with regards to tooling, we'd be able to, but something like IDE support? Most of us don't use or care about IDEs. Rather, we just use text editors like vim and emacs - or sublime. It does come up periodically that someone thinks that an IDE is critical to developing in D, but most of the folks who are involved enough to be contributing don't think that way. There are definitely some folks around here who care about IDEs, and there are several projects that bring D support to IDEs (such as Visual-D for Visual Studio), so I'm sure that some folks would care about whatever Jetbrains or anyone else is up to with IDEs and D, but most of us really don't care. If they have great D support, and that helps someone, then great. I don't think that you'll find anyone here who's against that, but most of us simply are not going to put time and effort into trying to improve IDE support or trying to get someone else to, because we wouldn't use any of it. So, feel free to point out what Jetbrains has done with regards to Rust and encourage anyone who cares to speak up and tell Jetbrains that they want something similar for D - having that sort of support certainly would not be detrimental to the D community - but a large percentage of the folks around here really aren't going to care, because it wouldn't help them at all. Most of the tooling stuff that folks around here are likely to care about has more to do with building software or finding bugs in it, not writing code. For most of us, that's what programs like vim and emacs are for. Historically, something like writing a D plugin for IDE has happened because someone who wanted that support for themselves has stepped up and provided it to the community. The same goes for most standard library additions. Standing up and saying that you want someone else to do something rarely gets anything done around here. It's almost always about someone contributing what they think is important and are able and willing to spend the time to implement and contribute. - Jonathan M Davis
Re: Bug in -J
On Saturday, 12 August 2017 at 03:58:30 UTC, Vladimir Panteleev wrote: On Saturday, 12 August 2017 at 03:52:25 UTC, Mr. Pib wrote: You are making assumptions about me making assumptions... please don't make any more assumptions or we will be in an infinite regression ;/ Sorry, maybe I don't understand the question. Maybe you could explain in broader terms the higher-level goal or problem you're trying to solve, and maybe we can recommend a better way? If are aware, it has nothing to do with absolute paths as the bug should also be exhibited with relative paths. It is a comparison issue of the strings rather than checking to see if they represent the same physical location. It would be like saying that \x\y is different from \x\..\x\y. Dmd does a blind comparison, I bet, rather than what it should be doing. Obviously \x\y are different strings but they are not different file locations. Fairly sure we forbid .. out of security considerations. I don't think this applies to Windows, but on POSIX, depending on how .. is interpreted, \x\y x/y actually can mean a different file from x/../x/y. It has taken a lot of consideration and research until we even allowed path separators in import paths. For a very long time, they were completely forbidden, and a long time after that, they were forbidden on Windows (because on Windows things can be more complicated due to the various kinds of reparse points and things such as short filenames). If that is not the case, then a better error message should be given. Feel free to file a diagnostic enhancement request if you have specific suggestions. I'm pretty sure that on no OS does the same location mean different things? I am not talking about strange stuff but simple stuff. I have code that loads a file at runtime and requires the absolute path. This is only for debugging purposes. When built in release, everything is switched over to use imports and embed the files in the binary. The same path is used for other things like caching/uniqueID but are never actually read from. You see this sort of stuff a lot when you open an executable and see hard coded paths but obviously never used for file system purposes. The files and paths are all the same but import doens't seem to think so. Adding baseName solves the problem immediately but that is a hack. import should know that the path is the same as the one specified by -J. The whole point of -J is to specify the path for security purposes, right? So why does it matter if I use path\filename or baseName(filename)? Both point to the same location and both are consistent with -J, import should understand that. It is an obvious oversight. But there is an obvious programmatic difference between the two versions. Luckily, using baseName does fix the problem so it is not a huge deal but it is still a bug/issue with import for being ignorant of what it is actually doing.
Re: Bug in -J
On Saturday, 12 August 2017 at 03:52:25 UTC, Mr. Pib wrote: You are making assumptions about me making assumptions... please don't make any more assumptions or we will be in an infinite regression ;/ Sorry, maybe I don't understand the question. Maybe you could explain in broader terms the higher-level goal or problem you're trying to solve, and maybe we can recommend a better way? If are aware, it has nothing to do with absolute paths as the bug should also be exhibited with relative paths. It is a comparison issue of the strings rather than checking to see if they represent the same physical location. It would be like saying that \x\y is different from \x\..\x\y. Dmd does a blind comparison, I bet, rather than what it should be doing. Obviously \x\y are different strings but they are not different file locations. Fairly sure we forbid .. out of security considerations. I don't think this applies to Windows, but on POSIX, depending on how .. is interpreted, \x\y x/y actually can mean a different file from x/../x/y. It has taken a lot of consideration and research until we even allowed path separators in import paths. For a very long time, they were completely forbidden, and a long time after that, they were forbidden on Windows (because on Windows things can be more complicated due to the various kinds of reparse points and things such as short filenames). If that is not the case, then a better error message should be given. Feel free to file a diagnostic enhancement request if you have specific suggestions.
Re: Bug in -J
On Saturday, 12 August 2017 at 03:02:31 UTC, Vladimir Panteleev wrote: On Saturday, 12 August 2017 at 02:45:30 UTC, rikki cattermole wrote: On 12/08/2017 3:34 AM, Mr. Pib wrote: I have -J added to the command line like -JC:\Temp I then use import(r"C:\Temp\a.dat"); and I get an error about the file not existing in the main.d: Error: file "C:\\Temp\\a.dat" cannot be found or not in a path specified with -J It seems dmd does internally compare the paths to see if they are identical. No, it just prefixes the given import() path will all those given by -J. Of course, removing the C:\Temp\ part of import works fine. The problem with that approach is it then is not consistent with other code. I need to specify the full path because sometimes it is used. essentially version(X) import(path) else load(path); I don't understand why you would want to do that. Using absolute paths makes assumptions about the system your software is being built on. Even if you never plan to build the software on any computer but your own, it still seems like a questionable design decision. You are making assumptions about me making assumptions... please don't make any more assumptions or we will be in an infinite regression ;/ while I could do something like import(baseName(path)) it seems kinda clunky, in any case. It's pretty obvious that one excepts the same behavior so it could create bugs in code that except the behavior to work correctly. You could also use -J/ and import(path[1..$]) (or the Windows equivalent). Still a bad idea. Most likely related or is the issue[0]. [0] https://issues.dlang.org/show_bug.cgi?id=3420 Nope. If are aware, it has nothing to do with absolute paths as the bug should also be exhibited with relative paths. It is a comparison issue of the strings rather than checking to see if they represent the same physical location. It would be like saying that \x\y is different from \x\..\x\y. Dmd does a blind comparison, I bet, rather than what it should be doing. Obviously \x\y are different strings but they are not different file locations. If that is not the case, then a better error message should be given.
Re: Bug in -J
On Saturday, 12 August 2017 at 02:45:30 UTC, rikki cattermole wrote: On 12/08/2017 3:34 AM, Mr. Pib wrote: I have -J added to the command line like -JC:\Temp I then use import(r"C:\Temp\a.dat"); and I get an error about the file not existing in the main.d: Error: file "C:\\Temp\\a.dat" cannot be found or not in a path specified with -J It seems dmd does internally compare the paths to see if they are identical. No, it just prefixes the given import() path will all those given by -J. Of course, removing the C:\Temp\ part of import works fine. The problem with that approach is it then is not consistent with other code. I need to specify the full path because sometimes it is used. essentially version(X) import(path) else load(path); I don't understand why you would want to do that. Using absolute paths makes assumptions about the system your software is being built on. Even if you never plan to build the software on any computer but your own, it still seems like a questionable design decision. while I could do something like import(baseName(path)) it seems kinda clunky, in any case. It's pretty obvious that one excepts the same behavior so it could create bugs in code that except the behavior to work correctly. You could also use -J/ and import(path[1..$]) (or the Windows equivalent). Still a bad idea. Most likely related or is the issue[0]. [0] https://issues.dlang.org/show_bug.cgi?id=3420 Nope.
Re: Bug in -J
On 12/08/2017 3:34 AM, Mr. Pib wrote: I have -J added to the command line like -JC:\Temp I then use import(r"C:\Temp\a.dat"); and I get an error about the file not existing in the main.d: Error: file "C:\\Temp\\a.dat" cannot be found or not in a path specified with -J It seems dmd does internally compare the paths to see if they are identical. Of course, removing the C:\Temp\ part of import works fine. The problem with that approach is it then is not consistent with other code. I need to specify the full path because sometimes it is used. essentially version(X) import(path) else load(path); while I could do something like import(baseName(path)) it seems kinda clunky, in any case. It's pretty obvious that one excepts the same behavior so it could create bugs in code that except the behavior to work correctly. Most likely related or is the issue[0]. [0] https://issues.dlang.org/show_bug.cgi?id=3420
Bug in -J
I have -J added to the command line like -JC:\Temp I then use import(r"C:\Temp\a.dat"); and I get an error about the file not existing in the main.d: Error: file "C:\\Temp\\a.dat" cannot be found or not in a path specified with -J It seems dmd does internally compare the paths to see if they are identical. Of course, removing the C:\Temp\ part of import works fine. The problem with that approach is it then is not consistent with other code. I need to specify the full path because sometimes it is used. essentially version(X) import(path) else load(path); while I could do something like import(baseName(path)) it seems kinda clunky, in any case. It's pretty obvious that one excepts the same behavior so it could create bugs in code that except the behavior to work correctly.
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. 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 Why do you think it can't be scaled? We have vibe.d on EC2 hosting. Common advice: get the same distribution as on the working machine where you are producing binaries to avoid problems with .so. First, we get default centos-based VM, and after some wasted time, it was easier to change it to Ubuntu VM to run the application, compiled on my working Ubuntu machine.
Re: Dynamic array leak?
On Friday, 11 August 2017 at 19:01:44 UTC, Yuxuan Shui wrote:
On Friday, 11 August 2017 at 18:44:56 UTC, bitwise wrote:
[...]
My guess is a pointer to the array still lives somewhere on the
stack. This gives the expected output:
void f()
{
S[] x = [S(1), S(1)];
writeln("GC allocated: ", (GC.addrOf(x.ptr) !is null));
x = null;
}
int main(string[] argv)
{
f();
GC.collect();
writeln("live objects: ", S.count);
return 0;
}
Makes sense. I was uncommenting unit tests one-by-one after
making some changes when I triggered this. I guess they were
passing before because subsequent unit tests cleared the pointers
off the stack. I guess I can just call a function that allocates
a large zeroed-out array on the stack in the last unit test
before checking the count if this happens again.
Thanks
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: newCTFE Status August 2017
On Friday, 11 August 2017 at 20:13:04 UTC, Dominikus Dittes Scherkl wrote: On Friday, 11 August 2017 at 09:27:47 UTC, Stefan Koch wrote: On Tuesday, 1 August 2017 at 21:27:32 UTC, Stefan Koch wrote: [ ... ] Hey guys, I just finished &&. Hooray! So what's still missing? Or is this now complete enough to release? it's almost at the point where I am okay with making a newCTFE-1.0 release. it will correctly coexist with the old engine such that the things it currently cannot do are still taken care of by the old engine. Things left to do : - Deal with more void initialization correctly. - Unions - Classes - Exceptions - some complex types such as int[][3][] - string-decoding foreach. like: (foreach(dchar utf32; uft8someString)) - associative arrays (though we may change druntime to a ctfe-able version, which would also allow having aa-literals computed at ctfe usable at runtime) There are a few corner-cases in the supported feature set where it will fallback to the old interpreter but fixing those is a matter of hand-work not head-work (as they _should_ not impact the design):)
Re: newCTFE Status August 2017
On Friday, 11 August 2017 at 09:27:47 UTC, Stefan Koch wrote: On Tuesday, 1 August 2017 at 21:27:32 UTC, Stefan Koch wrote: [ ... ] Hey guys, I just finished &&. Hooray! So what's still missing? Or is this now complete enough to release?
Re: Dynamic array leak?
On Friday, 11 August 2017 at 18:44:56 UTC, bitwise wrote:
struct S {
static int count = 0;
this(int x) { ++count; }
this(this) { ++count; }
~this() { --count; }
}
int main(string[] argv)
{
S[] x = [S(1), S(1)];
writeln("GC allocated: ", (GC.addrOf(x.ptr) !is null));
x = null;
GC.collect();
writeln("live objects: ", S.count);
return 0;
}
output:
GC allocated: true
live objects: 2
expected:
GC allocated: true
live objects: 0
Is this a bug?
I thought that the first writeln() may be leaving a copy of the
pointer lingering on the stack somewhere, but the output is
still "live objects: 2" with that line commented out.
Thanks
My guess is a pointer to the array still lives somewhere on the
stack. This gives the expected output:
void f()
{
S[] x = [S(1), S(1)];
writeln("GC allocated: ", (GC.addrOf(x.ptr) !is null));
x = null;
}
int main(string[] argv)
{
f();
GC.collect();
writeln("live objects: ", S.count);
return 0;
}
Dynamic array leak?
struct S {
static int count = 0;
this(int x) { ++count; }
this(this) { ++count; }
~this() { --count; }
}
int main(string[] argv)
{
S[] x = [S(1), S(1)];
writeln("GC allocated: ", (GC.addrOf(x.ptr) !is null));
x = null;
GC.collect();
writeln("live objects: ", S.count);
return 0;
}
output:
GC allocated: true
live objects: 2
expected:
GC allocated: true
live objects: 0
Is this a bug?
I thought that the first writeln() may be leaving a copy of the
pointer lingering on the stack somewhere, but the output is still
"live objects: 2" with that line commented out.
Thanks
Re: DIP 1011-extern(delegate)--Formal Review
On Friday, 11 August 2017 at 10:45:03 UTC, Mike Parker wrote: The first stage of the formal review for DIP 1011 [1], "extern(delegate)", is now underway. I see no problem with this DIP. And even if the usecase is rare, I think it is worth the new syntax (and thereby increased complexity of the language) to be able to do this in a type-safe way. So: +1
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). heroku is a bit more expensive. for starters, you could have a vps on digitalocean and let your application run on there. google cloud is an excellent platform that i run my company on. it is a lot cheaper than aws.
Re: Jetbrains announce support for rust plugin, show them we want one too!
On Friday, 11 August 2017 at 03:16:17 UTC, Dmitry wrote: On Thursday, 10 August 2017 at 19:44:35 UTC, 12345swordy wrote: On Thursday, 10 August 2017 at 05:55:59 UTC, Dmitry wrote: On Wednesday, 9 August 2017 at 20:29:07 UTC, 12345swordy wrote: You edit the json file of course. That how DUB generates solution files for visual D and other IDE's. This breaks changes that was done in the VS project. What changes are talking about? You typically make changes in the json file. https://forum.dlang.org/thread/olfrkycsfukvipeoh...@forum.dlang.org The person that you reply appears to be uncertain as he/she admits that he/she never use dub themselves. BTW if you want to add a dependency to the project you have to modify the json file.
Re: Jetbrains announce support for rust plugin, show them we want one too!
On Friday, 11 August 2017 at 12:11:13 UTC, Vadim Lopatin wrote: E.g. DlangIDE is written in D, uses cross-platform GUI library DlangUI which is written in D, and is cross-platform. May work even as console app. First, you are to be saluted (luimarco style*) for your effor on DlangIDE and DlangUI And I wish you continued growth and success But if you may accept some advice from me, I think, re branding the DlangIDE to something more generic and adding C support specifically and allowing to add support for other languages is the right thing to do IDEs take years to mature, you need to be more inclusive, only supporting D isnt very inclusive Most people program in more than one language, and like to use one toolset/ide C specifically, because there is a large C community out there that is under served, most C programmer use advanced text editors Vim/Emacs/SlickEdit In other word, you need to be more inclusive and inviting, IDEs are big and the D community is small A re-branding (Call it Dice IDE, for example) Pluggin support And a solid C plugin are my recommendations -- * luimarco is a fitness and body building youtuber
Re: Who here uses vibe-s3 from code.dlang.org?
On Friday, 11 August 2017 at 13:11:36 UTC, aberba wrote: After comparing Google's object storage platform with Amazon, I found Google's to be much simpler and straight forward plus it uses a json based api which is much simple to parse and understand. Maybe, but some people have to or prefer to use Amazon services, ideally we'd have libraries for both ecosystems. No ones software is an island, we have to talk other programs and services.
Re: Who here uses vibe-s3 from code.dlang.org?
On Thursday, 10 August 2017 at 15:49:35 UTC, Andres Clari wrote: 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". Last time I tested it around Nov, 2016, it was very buggy. I'm using an in-house deimos wrapper for "libs3". I would be awesome to have some native library for S3, and other AWS stuff, but I'm very thrown back by having it depend on vibe.d. Nothing against it, but say you just want to make a simple upload utility specialized, having to depend on vibe.d for that really is something unacceptable. Ideally we'd wanna have a library for the whole Amazon auth stuff wrapped, and libraries for the specific services you want to use, being as standalone as possible. After comparing Google's object storage platform with Amazon, I found Google's to be much simpler and straight forward plus it uses a json based api which is much simple to parse and understand.
Need some vibe.d hosting advice
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).
Re: Jetbrains announce support for rust plugin, show them we want one too!
On Friday, 11 August 2017 at 11:34:44 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 9 August 2017 at 07:59:46 UTC, Ryion wrote: this here because its obvious pattern. I agree that this seems to be a very small community and it is hard to get things done in a small community. But it is counter productive to constantly tell people that there is no solution, they need to do it or pay for it. Its like hearing a broken record that keeps skipping to the same beat. It's a sign of a lack of strategy. Other languages such as Dart had an IDE strategy from the start. Dart even provided a full Eclipse based IDE until JetBrains included support (then the Dart team dropped their own IDE). Without a central organized IDE project it will be hard to reach maturity for any such effort (unless the language is popular to sustain the development of a commercial IDE). I think having IDE for some language written in the same language may show power and usability of this language. E.g. DlangIDE is written in D, uses cross-platform GUI library DlangUI which is written in D, and is cross-platform. May work even as console app. For D programmers, it's easy to contribute something to IDE written in D than to some Java or C++/C# project. Active contributing to DlangIDE can make it really useful tool. So far, it's less usable than Visual-D or Mono-D. So far, I myself use Visual-D to develop D projects (including DlangIDE), but I hope there will be a point when it would be possible to switch to DlangIDE. I'm thinking about killer feature - adding Delphi like UI designer for writing DlangUI/DML apps. Having IDE similar to Delphi or Lazarus would be great advantage of D.
Re: Jetbrains announce support for rust plugin, show them we want one too!
On 11/08/2017 12:46 PM, HyperParrow wrote: On Friday, 11 August 2017 at 08:13:07 UTC, SC wrote: [...] having great tooling might increase popularity, but for me it'll improve my productivity, and that's all i care about, popularity is next, quality is already nice for me The language itself should improve your productivity: meta programming, embedded unittests, static assertions. Good tooling won't subtract from a good language, it will only improve upon it. Its the icing on the already delicious cake.
Re: Jetbrains announce support for rust plugin, show them we want one too!
On Friday, 11 August 2017 at 08:13:07 UTC, SC wrote: [...] having great tooling might increase popularity, but for me it'll improve my productivity, and that's all i care about, popularity is next, quality is already nice for me The language itself should improve your productivity: meta programming, embedded unittests, static assertions.
Re: Jetbrains announce support for rust plugin, show them we want one too!
On Wednesday, 9 August 2017 at 07:59:46 UTC, Ryion wrote: this here because its obvious pattern. I agree that this seems to be a very small community and it is hard to get things done in a small community. But it is counter productive to constantly tell people that there is no solution, they need to do it or pay for it. Its like hearing a broken record that keeps skipping to the same beat. It's a sign of a lack of strategy. Other languages such as Dart had an IDE strategy from the start. Dart even provided a full Eclipse based IDE until JetBrains included support (then the Dart team dropped their own IDE). Without a central organized IDE project it will be hard to reach maturity for any such effort (unless the language is popular to sustain the development of a commercial IDE).
DIP 1011-extern(delegate)--Formal Review
The first stage of the formal review for DIP 1011 [1], "extern(delegate)", is now underway. From now until 11:59 PM ET on August 25 (3:59 AM GMT on August 26), the community has the opportunity to provide last-minute feedback. If you missed the preliminary review [2], this is your chance to provide input. I'd like to remind you of the purpose of the formal feedback period. The preliminary review was for general discussion and the correction of major flaws. The formal review feedback should be focused on uncovering any flaws that were overlooked in previous stages. This is not the place to debate the merits of the DIP. Feel free to make your opinions known for the benefit of Walter and Andrei, but if you feel the need to debate any points of the DIP, or any of the comments made in this thread, please create a new thread for it. Please consult the 'Review Process' section of the DIPs README [3] for more details. At the end of the feedback period, I will submit the DIP to Walter and Andrei for their final decision. Thanks in advance to those of you who participate. [1] https://github.com/dlang/DIPs/blob/615d621636e081af9b18566e9b3dffd9c2f7a14b/DIPs/DIP1011.md [2] http://forum.dlang.org/post/topmfucguenqpucsb...@forum.dlang.org [3] https://github.com/dlang/DIPs/blob/master/README.md
Re: newCTFE Status August 2017
On Tuesday, 1 August 2017 at 21:27:32 UTC, Stefan Koch wrote:
[ ... ]
Hey guys,
I just finished &&.
The following test works now:
int[2] aaa2(bool b1, bool b2, bool b3, bool b4)
{
int x = 0;
if (b1 && ++x && b2 && x++ && b3 && (b4 || x++))
{
return [x, 1];
}
else
{
return [x, 0];
}
}
static assert(aaa2(0, 0, 0, 0) == [0, 0]);
static assert(aaa2(0, 1, 0, 0) == [0, 0]);
static assert(aaa2(0, 0, 1, 0) == [0, 0]);
static assert(aaa2(1, 0, 1, 0) == [1, 0]);
static assert(aaa2(1, 1, 1, 0) == [3, 1]);
static assert(aaa2(1, 1, 1, 1) == [2, 1]);
After a year of development we are finally able to keep all the
side effects :)
Whoohoo!
Cheerful,
Stefan
Re: Jetbrains announce support for rust plugin, show them we want one too!
On Wednesday, 9 August 2017 at 22:17:42 UTC, Jonathan M Davis wrote: On Wednesday, August 09, 2017 17:13:37 Timon Gehr via Digitalmars-d wrote: It is also a common pattern for the complainers to point out how not fixing their pet peeve will result in negative PR or reduced popularity. As if everyone here was somehow more deeply invested in D's popularity than in its quality. I find that to be a bit irritating. If anything, most of us are more invested in its quality than its popularity. Those of us who spend our time contributing to the code base or writing our personal projects in D care a great deal about its quality, and while we may care about how popular it is, that obviously wasn't what brought us here. Having D popular would be nice, but it's not necessary for us to be doing what we've been doing. And the reality of the matter is that most of us don't have the proper skillset for improving D's popularity. We're engineers, not marketing people. If someone has an issue that prevents them from using D, then that matters, but it needs to be taken in the context of everything else, and honestly, if doing something to make the language more popular means reducing its quality, I'd rather that it have higher quality. Ideally, having higher quality would help improve its popularity, but unfortunately, things don't always work that way. Regardless, we're here because we want a quality language, not because we want a popular one. We just hope that those two things aren't mutually exclusive. - Jonathan M Davis i agree about quality part, but you mix two things, popularity and the need of tooling the point of my post was to gather community in hope for better tooling, not popularity having great tooling might increase popularity, but for me it'll improve my productivity, and that's all i care about, popularity is next, quality is already nice for me
