Re: Updating D beyond Unicode 2.0
On Monday, 24 September 2018 at 14:34:21 UTC, Steven Schveighoffer wrote: On 9/24/18 10:14 AM, Adam D. Ruppe wrote: On Monday, 24 September 2018 at 13:26:14 UTC, Steven Schveighoffer wrote: Part of the reason, which I haven't read here yet, is that all the keywords are in English. Eh, those are kinda opaque sequences anyway, since the meanings aren't quite what the normal dictionary definition is anyway. Look up "int" in the dictionary... or "void", or even "string". They are just a handful of magic sequences we learn with the programming language. (And in languages like Rust, "fn", lol.) Well, even on top of that, the standard library is full of English words that read very coherently when used together (if you understand English). I can't imagine a long chain of English algorithms with some Chinese one pasted in the middle looks very good :) I suppose you could alias them all... -Steve You might get really funny error messages. 🙂 can't be casted to int. :-) And if you have to increment the number of cars you can write: 🚗++; This might give really funny looking programs!
Re: dlang download stat should be updated
On Tuesday, 11 September 2018 at 07:25:22 UTC, Suliman wrote: On Sunday, 9 September 2018 at 09:05:33 UTC, Suliman wrote: Last update was long time ago http://erdani.com/d/downloads.daily.png UP +1
Re: This is why I don't use D.
On Wednesday, 5 September 2018 at 05:44:38 UTC, H. S. Teoh wrote: On Wed, Sep 05, 2018 at 01:18:17AM +, James Blachly via Digitalmars-d wrote: [...] [...] [...] To me, this strongly suggests the following idea: - add *all* dlang.org packages to our current autotester / CI infrastructure. - if a particular (version of a) package builds successfully, log the compiler version / git hash / package version to a database and add a note to dlang.org that this package built successfully with this compiler version. - if a particular (version of a) package fails to build for whatever reason, log the failure and have a bot add a note to dlang.org that this package does NOT build with that compiler version. - possibly add the package to a blacklist for this compiler version so that we don't consume too many resources on outdated packages that no longer build. - periodically update dlang.org (by bot) to indicate the last known compiler version that successfully built this package. - in the search results, give preference to packages that built successfully with the latest official release. [...] I think this idea was suggested before and I hope this will be done. And when the compilation yield some warnings, about deprecation, the owner of the package should be notified and asked for update, too. Regards MT.
Windows dev anyone? [was: Re: Signed DMD binaries]
On 08/17/2018 01:24 AM, Mike Franklin wrote: > On Thursday, 16 August 2018 at 17:06:27 UTC, Martin Nowak wrote: > >> A review would be helpful. > > It looks fine to me, though, that's not saying much. If you need > someone to test something, contact me on Slack. > >> And more Windows dev-volunteers for upcoming features. > > To do what exactly? Well from my point of view the most important outstanding Windows tasks are: - help to test, debug, and fix the experimental lld/mingw toolchain (https://dlang.org/changelog/2.079.0.html#lld_mingw) Once this is ready for production use it would simplify the Windows installation and allowed us to drop optlink and OMF. - help Benjamin Thaut with the export feature This is intended to cover dllimport/dllexport, but in a single keyword without macros (more info https://dconf.org/2016/talks/thaut.html). It's a necessity for full DLL support on Windows and we also want to use explicitly exported symbols to speed up Posix binaries (by avoiding PLT indirections). - get a 64-bit VC dmd.exe into the release 64-bit builds should be fully CI-integrated (mostly already done via AppVeyor AFAIK). Integrate build script/makefile with existing Windows release build (https://github.com/dlang/installer/blob/f7ee5aeab79a800317d875b5ee2e34ec2ad8803c/create_dmd_release/build_all.d#L41-L43, and https://github.com/dlang/installer/blob/f7ee5aeab79a800317d875b5ee2e34ec2ad8803c/create_dmd_release/create_dmd_release.d#L444). I'd be happy to add anyone remotely interested in Windows-support to our #Windows channel on slack (https://dlang.slack.com/messages/C6D5FEJ78). It's unfortunately fairly quiet atm. -Martin
Re: Signed DMD binaries
On 08/16/2018 04:13 PM, Andrei Alexandrescu wrote: > On 8/15/18 7:44 PM, Manu wrote: >> Indeed, it's the installer that's in critical need of being signed... >> but all the binaries are worth signing if that's convenient. >> But the installer is definitely priority #1!:) > > Any chance we could delegate some of the effort of working on this to > you? > > Are other Windows users interested in helping? > > Martin has spent a fair amount of time dealing with this, and he's not > a Windows expert. We could definitely use some help here. > A review would be helpful. https://github.com/dlang/installer/pull/339 And more Windows dev-volunteers for upcoming features.
Re: DMD, Vibe.d, and Dub
On Wednesday, 18 July 2018 at 15:21:29 UTC, Russel Winder wrote: On Wed, 2018-07-18 at 14:20 +, Seb via Digitalmars-d wrote: On Wednesday, 18 July 2018 at 12:56:05 UTC, Russel Winder wrote: > [...] You have openssl 1.1 installed, but vibe.d tries to link with openssl 1.0 by default. See https://github.com/vibe-d/vibe.d#switching-between-openssl-versions tl;dr: use dub --override-config vibe-d:tls/openssl-1.1 I went for the: dependency "vibe-d:tls" version="*" subConfiguration "vibe-d:tls" "openssl-1.1" in the dub.sdl file. I now have a build. I believe 1.1 should be the default if available, falling back to 1.0, 0.9,… It would be very useful if dub would be able to check for missing libs. It seams stupid, that after successful compilation you get the linker error. Even if the needed libs are named different on different systems, it would be cool to collect the information what is needed in the dub.sdl/dub.json file. So directly at the beginning you get a hint what is missing. And how to fix it, especially if you use a system like Debian (/Ubuntu) I ran into the exactly same chain of error messages, fixing them with the help of others, and some search, this is not the most convenient experience if you start with vibe.d. Regards mt.
Re: DIP 1015--removal of implicit conversion from integer and character literals to bool--Community Review Round 1
On Wednesday, 20 June 2018 at 08:16:21 UTC, Mike Parker wrote: This is the feedback thread for the first round of Community Review for DIP 1015, "Deprecation and removal of implicit conversion from integer and character literals to bool": https://github.com/dlang/DIPs/blob/7c2c39243d0d747191f05fb08f87e1ebcb575d84/DIPs/DIP1015.md The arguments are clear and convincing, so: Yes!
Any comments about the new Ruby JIT Compiler
The compilation is done by using the C compiler in the background. https://www.ruby-lang.org/en/news/2018/05/31/ruby-2-6-0-preview2-released/ Could D be an better choice for that purpose? Any comment?
Re: dub subpckages and how to depend on them internally
On Tuesday, 29 May 2018 at 23:41:59 UTC, aliak wrote:
Hi, I'm trying to get dub working with subpackages and I just
can't quite seem to hit the nail on the head. Any help would be
greatly appreciated.
This is the current setup is like this, and there's a shared
source folder as well called "common" and "sub2" depends on
"sub1".
lib
|-- dub.json
|-- source/
| -- sub1/
| -- package.d
| -- dub.json
| -- sub2/
| -- package.d
| -- dub.json
| -- common/
[...]
Halp!
I had a similar struggle, may be the version is the missing hint:
"dependencies": {
"diet-ng": "~>1.4",
,
mylib":{
"versions": "~master",
"path": "/home/mt/d/mylib"
},
}
Try to place "versions": "~master", beside your path.
Re: ! No alerts ! code.dlang.org
On Monday, 14 May 2018 at 08:24:37 UTC, Martin Tschierschke wrote: Pingdom Weekly Report 2018-04-30 to 2018-05-06 CHECK NAME UPTIME DOWNTIMEOUTAGES RESPONSE TIME code.dlang.org 99.95% 0h 05m 00s 1 524 ms Last week (2018-05-07 to 2018-05-13) again: Uptime 100%!
Re: ! No allerts ! code.dlang.org
On Friday, 11 May 2018 at 12:13:49 UTC, Sönke Ludwig wrote: @Martin Nowak, please make a post about the new server infrastructure @ announce! Hi Martin, just wanted to note that the registry currently still runs on a VPS of mine, although on a different one that has a lot more free resources (memory). Martin Nowak's setup is still work in progress, but at least we have something stable until then. Yes, it is quite stable now, so I thought the new proposed infrastructure was already in place. => Thank you Sönke! Pingdom Weekly Report 2018-04-30 to 2018-05-06 CHECK NAME UPTIME DOWNTIMEOUTAGES RESPONSE TIME code.dlang.org 99.95% 0h 05m 00s 1 524 ms
! No allerts ! code.dlang.org
I just want to send a big thank you to Martin Nowak and Sönke Ludwig and every one else running the infrastructure of DUB behind the scene! This is the list of Weekly Reports from pingdom.com for code.dlang.org: Pingdom Weekly Reports 2018-04-02 to 2018-04-08 (partly) CHECKS WITH DOWNTIME UPTIME DOWNTIMEOUTAGES RESPONSE TIME Code90.00% 2h 45m 00s 9 725 ms 2018-04-09 to 2018-04-15 CHECKS WITH DOWNTIME UPTIME DOWNTIMEOUTAGES RESPONSE TIME Code94.49% 9h 15m 00s 43 694 ms 2018-04-16 to 2018-04-22 CHECKS WITH DOWNTIME UPTIME DOWNTIMEOUTAGES RESPONSE TIME Code97.12% 4h 50m 00s 4 571 ms 2018-04-23 to 2018-04-29 OUTAGES: None CHECKS WITHOUT DOWNTIME UPTIME DOWNTIMEOUTAGES RESPONSE TIME Code100.00% 0h 00m 00s 0 564 ms ^^^ @Martin Nowak, please make a post about the new server infrastructure @ announce!
Re: DIP 1013: The Deprecation Process -- Community Review Round 1
On Tuesday, 24 April 2018 at 17:02:50 UTC, Jonathan M Davis wrote: Honestly, I'd hate to have major releases be that infrequent. It can already be annoying enough when something that doesn't get added doesn't end up being released for a two or three months, depending on the timing. The slower the turnaround time, the longer it is before we can take advantage of any improvements. If we were going to do fewer releases, I'd much rather see us do less with minor releases than spread out major releases more. Please read all the info, in particular semver.org. I'd argue for strictly non-breaking backwards-compatible additions in minor releases, which should (could) be most phobos additions. Not breaking anything with an addition is of course a double-edged sword. Still it would give us a cleaner distinction where deprecations et.al. are only to be expected every 6 months with a major release, while bi-monthly minor releases remained fully backwards compatible. This seems to hit a better balance between regularly releasing new stuff and causing update churn. In particular since deprecations are on a much longer schedule, it makes sense to batch them anyhow. TL;DR same rate of improvements, less frequent rate of deprecations and required code changes
Re: DIP 1013: The Deprecation Process -- Community Review Round 1
On Monday, 2 April 2018 at 07:05:45 UTC, Mike Parker wrote: DIP 1013 is titled "The Deprecation Process". https://github.com/dlang/DIPs/blob/d8f6bfa1810c9774bd7d3b3dc6a7a6776ed5e17e/DIPs/DIP1013.md It's good to have this formalized as relying on authoritative review on a per-case basis doesn't scale. - I'd urge you to make this process as simple as possible, and plan for managing and automation. Right now it involves several steps over ~2 years requiring updates to separate repos. In particular for language changes that require specialized compiler changes, such changes cannot be easily done by anyone but the original author. Similarily for library changes we're mostly relying on a single person to manage deprecations. - It seems that the language features section does not yet mention https://dlang.org/spec/spec.html updates. https://github.com/dlang/DIPs/blob/d8f6bfa1810c9774bd7d3b3dc6a7a6776ed5e17e/DIPs/DIP1013.md#language-features
Re: DIP 1013: The Deprecation Process -- Community Review Round 1
On Wednesday, 18 April 2018 at 12:40:44 UTC, Jonathan M Davis wrote: 2. Somewhere, it should state that the goal is for the typical deprecation cycle for a symbol to last approximately two years and that the number of releases was picked on the assumption that we would have approximately 5 - 6 major releases a year. So, if at some point in the future, the typical number of releases in a year changes for whatever reason, the number of releases of the deprecation cycle should then be adjusted so that the deprecation cycle stays approximately two years long. At the moment we have a clear bi-monthly release cycle (1st of every odd month). In the long-run I'd like to transition to one major releases every 6 months and strictly non-breaking, non-deprecating point releases every 2 months. So far there wasn't much interest in the necessary development adjustments though. https://forum.dlang.org/thread/drcekmxvfszpwifbu...@forum.dlang.org
Re: Is it a bug that a parent class that access its own private members from derived classes gets deprecation warning?
On Monday, 9 April 2018 at 17:16:56 UTC, bauss wrote: On Monday, 9 April 2018 at 17:05:45 UTC, martin wrote:>> Actually, this behaves as i would expect. `_baz` is a private member of Foo (to be precise: it belongs to module `a`) in handleBar(), you iterate `Bar[]` - which is in module `b`. By casting it to Foo, you are accessing the wanted module (`a`) again. but handleBar() is in a. This behavior is allowed in ex. C# `_baz` is a member of `module a : Foo` - `_baz`, as is `handleBar()`. `protected` is the Access specifier you want. If i understand you correctly, you want it to behave as if `_baz` would be a member of `handleBar()` If this is really possible in C#, it lets my eyebrow raise.
Re: Is it a bug that a parent class that access its own private members from derived classes gets deprecation warning?
On Sunday, 8 April 2018 at 13:00:02 UTC, bauss wrote:
I think it's better demonstrated like this, because to me the
behavior makes no sense.
Especially since you can just cast "Bar" to "Foo" and then
you're allowed to do it.
Since we're inside Foo then it shouldn't care whether "_baz" is
private or not.
I could understand if the function was located within Bar, but
it's not.
It's perfectly normal in other languages that supports classes
to access private members of parent's as long as you're within
the parent's encapsulation.
// a.d
module a;
class Foo
{
private:
bool _baz;
public:
void handleBar(T : Foo)(T[] foos)
{
foreach (child; foos)
{
child._baz = true; // Not ok.
(cast(Foo)child)._baz = true; // Ok.
}
}
}
// b.d
module b;
import a;
class Bar : Foo
{
}
// main.d
module main;
import b;
void main()
{
auto bars = [new Bar, new Bar];
auto bar = new Bar;
bar.handleBar(bars);
}
Actually, this behaves as i would expect.
`_baz` is a private member of Foo (to be precise: it belongs to
module `a`)
in handleBar(), you iterate `Bar[]` - which is in module `b`.
By casting it to Foo, you are accessing the wanted module (`a`)
again.
Re: code.dlang.org having problems?
On Saturday, 24 March 2018 at 20:31:48 UTC, H. S. Teoh wrote: On Sat, Mar 24, 2018 at 04:59:49PM +, Russel Winder via Digitalmars-d wrote: On Sat, 2018-03-24 at 09:45 -0700, H. S. Teoh via Digitalmars-d wrote: > […] > > That is why a sane build system should always cache > dependencies locally, and not have to rely on network > servers being always available. Dub does exactly that, so not a problem. Dub even has the --skip-registry option to avoid the network access at all. My problem is that this is effectively a first build and Dub repository access is mandatory or no build can start using Dub. [...] Well, if you don't have dependencies installed locally (via dub or otherwise), then obviously it's impossible to build anything. :-D That's hardly a dub problem, right? T You could go to knock on the devs door of a dependency and ask for a copy of the code (e.g. on a floppy :) ). It is possible to add "a local package directory (e.g. a git repository)" in dub - so no need for hipster-WWW ;P btw: The vibe repo seems to be up and running again.
Re: D, Parasail, Pascal, and Rust vs The Steelman
On Wednesday, 21 March 2018 at 16:19:35 UTC, H. S. Teoh wrote: [...] I do not understand the meaning of "subscript ranges"? Isn't this slicing? AFAICT, "subscript" in the spec just means the range of valid array indices (it's old terminology from the 70's / 80's). In which case, it is not true that subscript ranges are not accessible in D (I don't know about Rust); all D arrays have indices from 0 to .length-1, so the callee can always access the range of allowed indices, and the caller never has to pass .length explicitly. T With this D fulfills, 95% of the "Steelman requirement" partially or better :-)
Re: D, Parasail, Pascal, and Rust vs The Steelman
On Wednesday, 21 March 2018 at 12:52:19 UTC, Paulo Pinto wrote: An article comparing the above languages as per the DoD language requirements [0]. http://jedbarber.id.au/steelman.html [0] - https://en.wikipedia.org/wiki/Steelman_language_requirements Interesting! Do you understand this: 7H. Formal Array Parameters. The number of dimensions for formal array parameters must be specified in programs and shall be determinable during translation. Determination of the subscript range for formal array parameters may be delayed until invocation and may vary from call to call. Subscript ranges shall be accessible within function and procedure bodies without being passed as explicit parameters. Subscript ranges are not accessible in D or Rust. I do not understand the meaning of "subscript ranges"? Isn't this slicing?
Re: D-dll support: testers needed round 2
On Friday, 9 February 2018 at 20:34:33 UTC, Benjamin Thaut wrote: My work on dll support for D continues. There is another iteration I need help testing with. Getting started tutorial: http://stuff.benjamin-thaut.de/D/getting_started.html The DIP can again found be here: https://github.com/Ingrater/DIPs/blob/ReviveDIP45/DIPs/DIP45.md The DIP is not up to date. The tutorial is more recent. If the DIP and the tutorial contradict each other trust the tutorial. Its still useful to read the dip for context, especially as how to use "export" in code. Glad to see some progress. Given that the goal of DIP45 was seemless DLL support given just export annotations, the need for explicit -import module lists indeed requires an explanation. Looks like a classical dllexport/-import scheme now.
Re: D-dll support: testers needed round 2
On Saturday, 10 February 2018 at 02:24:58 UTC, rikki cattermole wrote: -import switch makes me a little concerned, what exactly is it changing that makes it required? I remember that we figured out that the MS Linker can optimize away the indirection when linking statically, so the paragraph seems a bit alarming https://github.com/Ingrater/DIPs/blob/ReviveDIP45/DIPs/DIP45.md#-useshared-compiler-flag.
Re: Bachelor level projects
On Tuesday, 20 March 2018 at 14:44:39 UTC, Alexandru Jercaianu wrote: Hello, At the Polytechnic University of Bucharest we are organizing a special program called CDL[1], where Bachelor students are mentored to make their first open source contributions. I think it's a great idea to involve D in this program, but for this to be successful, I need your help in finding ideas for Bachelor level projects, which can be solved until the end of May (anything from new features to more impactful bugs). If there is anything on your wish list which matches the criteria above, feel free to share. Thanks, Alex J Make a complete analysis of all existing database connectors for D. https://code.dlang.org/?sort=updated&limit=40&category=library.database And propose a std.database solution, derived of the existing ones allowing to connect to Mysql/MariaDB,Postgres,SQlite and probably more. With a certain focus on not blocking i/o to keep it vibe.d compatible. I just realized again how important an "official" D database connector is. Regards mt.
Re: D course material
On Wednesday, 14 March 2018 at 08:53:17 UTC, Andre Pany wrote: On Tuesday, 13 March 2018 at 12:39:24 UTC, Dmitry Olshansky wrote: [...] 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; [...] Just came across this: It has been changed to: std.experimental.all https://dlang.org/changelog/2.079.0.html#std-experimental-all Regards mt.
Re: Do we need Mat, Vec, TMmat, Diag, Sym and other matrix types?
On Tuesday, 13 March 2018 at 14:13:02 UTC, jmh530 wrote: [...] https://en.wikipedia.org/wiki/Row-_and_column-major_order I think for mathematics it is more important for easy handling, to be able to get the element of a matrix a_ij by a(i,j) and not only by a[i-1,j-1]. The underlying storage concept is less important and depends just on the used libs, which should be the best (fastest) available for the purpose.
Re: Do we need Mat, Vec, TMmat, Diag, Sym and other matrix types?
On Tuesday, 13 March 2018 at 03:37:36 UTC, 9il wrote: [...] 5. Clever `=` expression based syntax. For example: // performs CBLAS call of GEMM and does zero memory allocations C = alpha * A * B + beta * C; [...] My answer is: Yes. If D with Lubeck would have such a convenient way to write matrix algebra, using well designed operator overloading, this might attract more users. Unfortunately my own time using this kind of math daily is long ago, but I would like to help as a tester. I will look in my master thesis and see if I may use Lubeck for the calculation done. I was doing eigenvalue with FEM and in an other project partial differential equation with a matrix based approximation schema... so this may bring my "gray cells" to work again :-) I was using a C++ lib with operator overloading resulting in quite convenient expressions. The point that Java has no operator overloading, was the trigger for me to dislike the language. :-)
Re: DConf hotel poor QoS
On Saturday, 10 March 2018 at 04:55:02 UTC, Mike Parker wrote: On Friday, 9 March 2018 at 18:08:58 UTC, Ali Çehreli wrote: [...] I booked both legs directly through Lufthansa and decided to fly into Frankfurt since it's cheaper than the direct flight to Munich. The flight there is costing us about $450 ea. for Basic Economy, non-stop. The BE seats on the way back are $600+, so we booked premium economy for a little over $800 ea. instead. For my wife and I together, $2700 round trip. Then I planned our trip around that: 5 nights in Frankfurt, 7 in Munich, and 3 in Berlin, with two Deutsche Bahn rides and an EasyJet flight in between. Sorry to say this, but you are missing the most beautiful German city: Hamburg :-) Have a got journey! p.s. I am dreaming of the day DConf being in Hamburg... This is the location of our annual event: http://www.hotel-hafen-hamburg.de/uploads/pics/hhh_tagungsraeume_elbkuppel_visual_03.jpg
Re: Embedded Linux really needs Dlang for the IOT market
On Friday, 9 March 2018 at 12:41:52 UTC, Binghoo Dang wrote: On Friday, 9 March 2018 at 09:12:28 UTC, Radu wrote: [...] I'm working in BAS(Building Automation System) sector, and I use Dlang daily for some advance products targeting ARM/Mips boards. [...] That's great, it looks that what I need to do is just try! And, I would write a paper after I get everything working. thanks! Yes, please write down your steps to success and place it somewhere it can be found :-) (https://wiki.dlang.org/) There is not to much documentation!
Re: DIP 1006 - Preliminary Review Round 1
On Sunday, 26 November 2017 at 11:59:28 UTC, Joseph Rushton Wakeling wrote: One suggestion: replace -release=assert with -release=body, so in the above, you would have: -release=body,in,out,invariant Doesn't really work that way, we can disable assertions, in contracts, out contracts, and invariants. But not assertions in some contexts while leaving them enabled in other contexts. At least not without modifying all related codegen and introducing context queries (e.g. think mixin templates). FWIW -release=assert,in,out,invariant fits out needs well enough. Just the use-case that someone wants to disable asserts in functions but still wants to use contracts, required to use a replacement for assert in contracts and invariants.
Re: DIP 1006 - Preliminary Review Round 1
On Wednesday, 12 April 2017 at 11:25:09 UTC, Mike Parker wrote: DIP 1006 is titled "Providing more selective control over contracts". Possible implementation https://github.com/dlang/dmd/pull/7980 FYI
Re: Slow code, slow
On Tuesday, 27 February 2018 at 13:35:14 UTC, ketmar wrote: Martin Tschierschke wrote: On Tuesday, 27 February 2018 at 08:49:15 UTC, Stefan Koch wrote: On Monday, 26 February 2018 at 21:38:09 UTC, ketmar wrote: H. S. Teoh wrote: On Mon, Feb 26, 2018 at 10:12:25PM +0200, ketmar via Digitalmars-d wrote: [...] When looking at the problem of compilation times I think: Wouldn't it speed up the development process, if spiting your code in modules would automatically results in creating small libs which are - if possible - compiled only once? The idea of using a caching mechanism, is an other general way not to compile the same over and over again. Part of the discussion is here: https://github.com/dlang/dmd/pull/7239#issuecomment-340256110 basically, compilation of a code without templates is FAST. 500+ KB of source almost without templates often compiles in less than a second (on not-so-bleeding-edge i3, not even i7). but throw templates in a mix, and BOOM! coffee and cigarettes. My negative experience was, when using ctRegex and normal regex. But it was no problem to separate the functions using regex in a lib and compile them separately. (app saving 3 seconds) The same approach was working with .dt (diet template in vibe.d) and the function(s) instantiating it, put both together in an own lib. And define it as a local external dependency. In the moment I am thinking about a way to do this automatically. So that every new build of my vibe.d app, only needs to compile the changes. (p.s. I am aware of this: https://github.com/rejectedsoftware/diet-ng#experimental-html-template-caching)
Re: Slow code, slow
On Tuesday, 27 February 2018 at 08:49:15 UTC, Stefan Koch wrote: On Monday, 26 February 2018 at 21:38:09 UTC, ketmar wrote: H. S. Teoh wrote: On Mon, Feb 26, 2018 at 10:12:25PM +0200, ketmar via Digitalmars-d wrote: [...] When looking at the problem of compilation times I think: Wouldn't it speed up the development process, if spiting your code in modules would automatically results in creating small libs which are - if possible - compiled only once? The idea of using a caching mechanism, is an other general way not to compile the same over and over again. Part of the discussion is here: https://github.com/dlang/dmd/pull/7239#issuecomment-340256110
Re: Postgres and other database interfaces
On Saturday, 24 February 2018 at 15:44:49 UTC, Paolo Invernizzi wrote: On Saturday, 24 February 2018 at 15:32:32 UTC, Adam D. Ruppe wrote: On Saturday, 24 February 2018 at 14:13:18 UTC, Joe wrote: [...] You can try going to http://any-dub-package.dpldocs.info [...] :-O Adam, you are the man! I'll never stop of being surprised by your way of coding! Great Job! +1 Fascinating! Please make a post to announce and place the direct link to it inside code.dlang.org :-) Would it be possible to use it for calculating/evaluating a measure for inlined documentation?
Re: Postgres and other database interfaces
On Saturday, 24 February 2018 at 14:13:18 UTC, Joe wrote: On Saturday, 24 February 2018 at 10:13:35 UTC, Paolo Invernizzi [...] As I said, I'm new and still not familiar with those facilities although I saw those things and they looked like embedded HTML and was wondering what they were for. Again, coming from Python, I'm familiar with RTD (https://readthedocs.org, my own open source Python/Postgres project is hosted there) and Sphinx (http://www.sphinx-doc.org/en/master/). Although it started with Python, RTD now hosts many other kinds of projects (Javascript, PHP, Ruby, etc.). There's even a project named 'dlang' (it's not what you expect!), but I did find "D Tips" and "Quick Start with D" which appear to be standalone Markdown. In any case, it would be nice to have such automatically generated docs available in a public site/repo of some kind, like RTD, so a potential user doesn't have to clone the code and run the compiler to see it. +1 I would even go so far 'force' people publishing to dub, to provide documentation. If no docs, present, than the libs should be marked as *docs missing*. (Beside the number of Github stars)
Re: Postgres and other database interfaces
On Saturday, 24 February 2018 at 07:57:47 UTC, aberba wrote: On Saturday, 24 February 2018 at 05:33:56 UTC, Joe wrote: Back on 13 January, I posted in the Learn forum some questions regarding using Postgres and got a reply that stated the following: On Monday, 15 January 2018 at 02:28:29 UTC, Matthias Klumpp wrote: In any case, please don't start another Postgres library and consider contributing to one of the existing ones, so that we maybe have one really awesome, 100% complete library at some point. I'm revisiting this because I now have had the chance to look at the various libraries and IMHO the "really awesome, 100% complete library" depends on the users' goals and their definition of awesome and complete. Aside from ddbc which is like ODBC/JDBC and thus supports multiple db's (not my interest), I've found five Postgres-specific libraries worthy of further exploration: 1. derelict-pq. This is the most downloaded one and is simply a binding over libpq, so AFAICT it's nearly 100% complete. It's also well-documented, in part because the Derelict libraries provide overall guidance, but mainly because a D user can refer directly to the comprehensive libpq documentation and (C) examples. The only strange fact is that it's been stuck in a beta.3 release for the last five months. 2. dpq2. Second most downloaded and built on top of derelict-pq. The "documentation" consists of a README listing the features and a single example, which appears to focus on support for JSON/BSON. 3. vibe-d-postgresql. Third most downloaded and built on top of dpq2. Docs consist of a single example program. 4. ddb. About the same number of downloads as the above. Implemented on top of front/backend protocol. No documentation although repository has a folder with two sample programs. 5. dpq. Implements its own wrapper over libpq and has some ORM functionality. Docs are a README with example program. The main issue is that, other than derelict-pq, using any of these libraries involves reading the library code and understanding the sui generis interfaces implemented by each. I'm new to the D community, but coming from Python, the contrast is significant. First there is the well-documented PEP 249 (https://www.python.org/dev/peps/pep-0249/) promulgated by the Python DB-SIG (and note that 249 is v.2), which led to the implementation of psycopg (also well-documented including various extensions to the API) and many other adapters to Postgres and other databases. Some developers spend hours writing code but don't feel the need to speed minutes documenting or at least showing how to use their code. Part of the reason others roll their own (one they will understand). Goes on and on. If its for their personal use, then they shouldn't put it on dub to saturate the ecosystem. I sometimes go around sending pull requests to some with sample I got from their unittests or "example" folder. Worst case, they send you a link to the C library they wrote bindings for... "oh its easy to know by looking at the C docs". Some don't even border... this is common with C libraries. C has libs but hard to figure out how to use without going through code. Laugh at, as one may, Javascript npm libraries are well documented so there's high adoption. OP even agrees derelict-pq is well documented so it has a higher usage. All Dub libraries with good docs are those that are downloaded. Most importantly, a description of package and a sample/demo is the README.md file. A link to generated docs may follow to more info. Only generated docs don't cut it. If you document your code well, others will use and contribute to it without rolling their own. Docs on library purpose and sample usage at least. "The most used Dub libraries are those well documented." +1 I want to subscribe to this. To improve the D ecosystem it would be a plus point to mark all libs at code.dlang.org having documentation with a special sign. Most people want a solution for their problems, they don't want to make an analysis, which of n available libs is best to use. Most more widely adopted languages offer the needed DB connectors in their std. The medium step between expanding the std lib and having nothing official might be, to try to adopt more for the dlang git repro. (https://github.com/dlang-community) (As mentioned before) Even if the first choice might be not the best of all available libs for one problem, if the community has started to develop _one_ solution for a problem, the value of contributing to this increases dramatically. I think the community is not big enough to support five different well documented, well designed and understood libs for solving the same problem. Regards mt.
Re: Status of @nogc with the runtime
On Sunday, 18 February 2018 at 22:28:48 UTC, Peter Campbell wrote: Indeed, very interesting read and exactly the information I was looking for! Thanks a lot Martin, I'm excited to see this progress. It's good to know it's still being worked on and progress is being made. Yes, it's just crazy how much work and expertise is involved with a programming language ecosystem, so things always go much slower than intended. In case someone wants to help, I currently have to divert a lot of time into https://github.com/dlang/dub. Package managers are suprisingly complex pieces of software. We have some basic architecture https://github.com/dlang/dub/blob/master/ARCHITECTURE.md and would benefit a lot from a few more contributors getting familiar with the implementation.
Re: How to represent multiple files in a forum post?
On Sunday, 18 February 2018 at 04:04:48 UTC, Jonathan Marler wrote: If there is an existing standard that's great, I wasn't able to find one. If you find one let me know. Found ptar (https://github.com/jtvaughan/ptar) and shar (https://linux.die.net/man/1/shar), both aren't too good fits, so indeed a custom format might be in order.
Re: Anybody still using the chm docs
On 02/17/2018 10:19 PM, Manu wrote: > I like the CHM docs. > I have encountered the same maintenance problem before, where build infra > is linux based, and the CHM docs need a windows machine to build... I > solved this problem by building the CHM via WINE ;) > Maybe this is a possible solution? Yes might be an option, but I have little experience with Wine, and adding more complexity to an already complex tool seems problematic. We obviously do build releases on Windows (VirtualBox) and also have Windows CIs, but Vladimir's doc tester is linux-only atm. I mainly don't want to spent more resources to work on this, hence it's offered for adoption. You might want to collaborate with Vladimir to integrate this with dlang.org's appveyor. It can easily test every build and upload artifacts for git tags. -Martin
Re: Anybody still using the chm docs
On 02/18/2018 02:05 AM, Walter Bright wrote: > On 2/17/2018 7:04 AM, Martin Nowak wrote: >> Let's pull the plug, I think everybody agrees that we have more >> important issues than maintaining d.chm and dman (which hasn't been >> shipped since 2.076 anyhow). >> Consider both tools as offered for adoption (as an external service or >> download). >> >> https://github.com/dlang/installer/pull/298 >> > > I find dman very useful, as I'm a command line sorta guy. In fact, I > wrote it because it's a major convenience for me. I know, but I think you are one of the very users though. On my shell it's simple to add an alias that would invoke https://duckduckgo.com/?q=popFrontN+site%3Adlang.org%2Flibrary. Personally I do have a browser shortcut 'd' for my Brower's omnibox, so I can just type 'd popFrontN' in FireFox to find docs. The essence here is that while dman might be useful, it's foundation is very complex and fragile, using ddoc JSON macros :o (https://github.com/dlang/dlang.org/blob/cb44110267d0b5d2e139909c47fa00924ac1cb24/chm-nav.dd) and a self-written html/link processor to gather tags. Sure Vladimir is great at maintaining tools and very responsive, but still any issue with this tool blocks our releases and wastes my time. Same as for d.chm, I'd favor if that tool would be build and distributed separately from our dmd releases, and if the actual users would maintain it. This could be setup on Travis-CI using ldc to cross-compile for all target platforms or so. -Martin
Re: Annoyance with new integer promotion deprecations
On 02/18/2018 08:26 PM, Manu wrote: > If change the behaviour (is done), then just let the code be broken! > Emitting these terrible noises, and encouraging people to make their code > even noisier than the compiler output is much worse than broken code. > There are hundreds of lines I need to molest to make the compiler shut up. > I won't type another line of code on my colour library until this noise is > gone... I will not maintain it. I am emotionally incapable of assaulting my > code with those casts. Best solution, write a custom Int type that doesn't use C's horrible promotion rules. I've long wanted some SafeInt library that doesn't silently promote and supports saturation, overflow, and errors. -Martin
Re: Status of @nogc with the runtime
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/17/2018 07:03 PM, Peter Campbell wrote: > My understanding from the vision documents and what Andrei > mentioned at his DConf presentations is that the runtime itself > will be modified to not rely on the GC, allowing for you to > continue using features such as associative arrays and array > concatenation, but without requiring the garbage collector. Is my > understanding correct? If so is work still being done to make this > happen and is there an easy way to follow the progress? @nogc containers will most likely come in the form of a library. We plan to move built-in hashes to a templated druntime implementation (https://github.com/dlang/druntime/pull/1282), and at best make array and hash literal syntax available for user defined types (w/ an approach similar to C++'s initializer_list). Our current std.container package does not use the GC (https://dlang.org/phobos/std_container.html), but isn't really up to par. Your best options atm. would be [emsi_containers](http://code.dlang.org/packages/emsi_containers) for containers and [automem](http://code.dlang.org/packages/automem) for smart pointers. Both libraries support custom allocators (https://dlang.org/phobos/std_experimental_allocator.html). Writing containers and smart pointers isn't rocket science, so it's the least of our worries. While heading for @nogc we've decided that we don't want to give up @safe-ty (remember that GC based allocations don't suffer from memory corruptions). Walter has spent a lot of effort on preventing escaping of aliases (DIP1000). I'm currently working on a proposal (DIP) and implementation called "limited lifetimes" that is targeted at preventing use-after-free bugs at compile time without impeding usability too much. We hopefully will have at least a prototype implementation for this year's DConf in May. This should become the foundation for `@safe @nogc` RC/Uniq/Weak primitives, onto which we can layer `@safe @nogc` libraries. In parallel Andrei and his students are investigating alternative approaches to reduce GC overhead or prevent use-after-free errors at runtime. We've somewhat stopped to work on our GC, to focus on unique/ref-counted memory management. Though soon the GC implementation can be replaced with custom GCs from our package manager dub (https://github.com/dlang/druntime/pull/1924). This should open the door for low-latency GCs, based on CoW and dirty page flags. We don't want to add write-barriers to the language due to the ~5% overall slowdown, so generational GCs are out of reach, but there is an interesting paper on using type information to perform partial collections ([Connectivity-Based Garbage Collection](https://www.cs.purdue.edu/homes/hosking/690M/cbgc.pdf)). At the moment there is no good way to track progress, as a lot is being worked on behind the scenes by many distributed actors. I think we are the ones most annoyed that this transition takes so long, but our plans are also very ambitious, targeting minimal memory footprint, optimal performance while supporting a @safe language subset and advanced features like custom allocators or region based allocations. - -Martin -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEpzRNrTw0HqEtE8TmsnOBFhK7GTkFAlqJ7CsACgkQsnOBFhK7 GTnTyQ//axaUtY8B1VhjW3Y/cMs4GESDmwa68r3IU/3XnyUelZfbMhAnA14aQh23 7y9D9MpPLYbgRQDbsrbUU7BoXMIiguFDQmR/265I7ZlhugVbG8VerQv+cIfXjiz9 fNKNgZHjp6hBPDIcHruiOcFNmqg73ymSg/9VWmEIzS1HUSMtZpBslz9uPWwKCacV axv8a/oPOBo5C8WcHqwtXHPeNZYKiwAcBaE6cXordN9r0dK1OC/JtvbjLRQnbv72 d0Xifdj4IkLM4krJvEZVX7jEPOvq15P48ns/gxMiem8e2qn6pHW+FIPHRx/y9Wv0 K5RGsivkBETDX6xrohwKdSEf5vIx4qQavI1pAA/8NIVsI2AlBs0OYivUnd+pTHA6 mLLI/Ask8NmWoA4FNFdWI0+zC/zTs1e06sTl1nsMs2NHCCaRL3CSTJmExeLVDrYD iz/5XvKMsZUh1wSlFvoqFX4UvmjZH3HseZfh1WhKaYnSculc0RzhDIYzbftCKqJR 1nCOnNyhS8kuxGT881oYZmbTyevoy2uU3tBStmXcGcRTfpHkd9xaFY7vlqF0Aa41 eUI0z6r4SG+ZmDmwHlnZD58kcIvBVvWZaAoo4hz0138LW0LNd9tRiBPTyUfE9PJL qCmEbVvB25nz2yge9iEOGERJYRI8P1fssfUX3bjNcDoeLTMokPo= =wnx7 -END PGP SIGNATURE-
Re: How to represent multiple files in a forum post?
On Wednesday, 14 February 2018 at 18:33:23 UTC, Jonathan Marler wrote: @timotheecour and I came up with a solution to a common problem: How to represent multiple files in a forum post? Oh, I thought it already was a standard, but [.har](https://en.wikipedia.org/wiki/.har) is JSON based and very different, so the name is already taken. Have you done some proper research for existing standards? There is a 50 year old technique to use ASCII file separators (https://stackoverflow.com/a/18782271/2371032). Sure we can find some existing ones. We recently wondered how gcc/llvm test codegen, at least in gcc or gdb I've seen a custom test case format.
Re: Anybody still using the chm docs
On Wednesday, 15 June 2016 at 10:58:04 UTC, Martin Nowak wrote: It's a huge maintenance effort for us to produce the chm files. We no longer generate documentation on Windows, but just for the chm generation we have dedicated tools [¹] to create an index (from a json generated via ddoc) and copy the html files. So I'm wondering if in 2016 someone really needs an offline copy of a website shipped with a binary release? Let's pull the plug, I think everybody agrees that we have more important issues than maintaining d.chm and dman (which hasn't been shipped since 2.076 anyhow). Consider both tools as offered for adoption (as an external service or download). https://github.com/dlang/installer/pull/298
Re: Tuple DIP
On 01/14/2018 12:21 AM, Timon Gehr wrote:
>> what would be the equivalent of this ?
>> ` writeln(tuple!("x", "y", "z")(2, 3, 4).y); `
>
> It would continue to work the same way.
>
> I did consider adding a proposal for built-in named tuple syntax:
>
> writeln((x: 2, y: 3, z: 4).y);
>
> (int a, double b) t = (a: 1, b: 2.0);
> int x = t.a;
> double y = t.b;
Tuples are anonymous bundles, when you want a product type with field
names use a struct.
Re: Tuple DIP
On 01/14/2018 07:41 PM, Timothee Cour wrote: > Should definitely be mentioned in the DIP to open that up for discussion; > it breaks assumptions like sizeof(Tuple)=sum_i : tuple (sizeof(Ti)); That doesn't hold for all cases anyhow, as it seems were talking about closed tuples that are contiguous in memory and follow struct layout and alignment rules.
Re: Tuple DIP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/12/2018 11:44 PM, Timon Gehr wrote: > As promised [1], I have started setting up a DIP to improve tuple > ergonomics in D: > > https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md Pardon me if things have been said already, can't really read through all the thread. - - Regarding underscore as placeholder. https://issues.dlang.org/show_bug.cgi?id=13522 - - Regarding the "limitation" Maybe you want some auto-packing feature there? Doesn't seem too bad, we could come up with sth. when this turns out to become a common nuisance. Have you considered to lower (1, 2, 3)[0 .. 2] to tuple(tuple(1, 2, 3)[0 .. 2]) or using a non-std.typecons tuple where slicing does not expand? - - closed tuples? The reference to std.typecons.tuple implies contiguous struct memory layout (closed tuples). This is a bit subtle for unpacking assignments which lower to AliasSeq!(x, y) = tuple(y, x)[]; so on the left-hand side of an assignment, the syntax refers to a non-contiguous (open) tuple. Declarations like auto (a, b) = (1, 2); also seem to declare an open tuple (non-contiguous memory). I assume that unpacking function arguments behaves similarly, i.e. on ABI level, each argument is passed separately. Overall looks really good. I think that would make for a great addition to the language. - -Martin -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEpzRNrTw0HqEtE8TmsnOBFhK7GTkFAlqHNkgACgkQsnOBFhK7 GTka+A/9HVHrawW5XyqzpGnT+qkyaG3a4dZdVvHbs9gJ0x7SHDyBgjKs576dW7g5 GEfGFjPkEZqKGvbtWgSicRV01qNmyGfVsgmWestK59niQAHLMUYx8PBsmeX/1CP9 MxLPMx9a0Z+h0D1z8sCLjHV5NcVZLziP3lnuUUvVXLUEv/gBZV52Eu++/iJmqKaj K9Boyv2+IrTTkv426PNxCy1iblMVi7B2bP44HErwij9+si8Zby3O8ExAh97MOBdH eoPT6TzmJxpExUfdiXcJ26HFxa4V8WhB/YaS50uYoUUYbaj0njtLwLyCkzUsjGzb JV32ZI7ncfHmMHCaJ09SGHfvh2dHKHa/VHU5ar3ivnzAXBLjdoe7MNi3QGH+zi6M U+RtY6WBkiVnYcLmanmMJKhyRsj3k3qT1I4zmVm6kbrs/oBqegtQcFoiQxm/DNMc LKLlNTEWuWIFquA6rd5OJ7kxhdbv5dE9vAgDNYcPP8GOB78sbZMQKxBTcI0a1EQC JYYvICiI9+CqjIeOU0F/LDv48JIk5BGSrh8m0cjwUtq4ivGEKo4V6Oc+1smsXmAo +XpSyyQi/t8pj037w0zSS0KA88qL4Fc4fvuujNnr5a9AkiV7zrMb9oyM00+F7cgo UApw3Lpr9g8GBKKu8HcbzGQMq86TYq/unSsD3ZFJEA3PCz8/5aY= =VB2T -END PGP SIGNATURE-
Re: Multiple Alis
On Tuesday, 13 February 2018 at 11:05:03 UTC, Andrea Fontana wrote: On Tuesday, 13 February 2018 at 00:47:42 UTC, Ali Çehreli wrote: Nothing serious but in case you are confused, there are at least three separate and awesome Alis frequenting these newsgroups. :) From: Ali Çehreli Email: acehr...@yahoo.com Almost always ends posts simply with "Ali" From: Ali Email: fakeem...@example.com Usually does not use any signature From: aliak Email: someth...@something.com Usually ends with "Cheers", occasionally with an added "- Ali" Ali "me" I read this thread just because it was so strange that Ali was calling "Multiple Alias This" in this way. LOL +1, + @ Ali Çehreli (trying to use a Gravatar picture would be cool, you may use a picture of your wonderful book, if you are to shy :-)
Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests
On Friday, 9 February 2018 at 03:06:56 UTC, Timothee Cour wrote: same exact idea as motivation for delimited strings (https://dlang.org/spec/lex.html#delimited_strings) ``` auto heredoc = q"EOS This is a multi-line heredoc string EOS" ; /"EOC This is a multi-line heredoc comment allowing /+ documented unittests containing nesting comments +/ and weird urls like https://gcc.gnu.org/onlinedocs/libstdc++/faq.html EOS"/ ``` I thought about it, what if you define, that the /+ +/ comment, is not started by '/+' alone but by '/+ ' that means that the char behind the plus defines the ending of the comment. So that /+my_special_block has to end with my_special_block+/ And '/+ ' with ' +/' where all whitespace characters should be allowed (\newline \tab \space). I know that this might be a somehow breaking change, but it would not require a totally different kind of syntax. And the mentioned URL-Strings lib++/ will not match for '/+ ' . Would be interesting how often people write /+directly followed by the comment, without a space or the same at the end+/
Re: Quora: Why hasn't D started to replace C++?
On Thursday, 8 February 2018 at 15:29:08 UTC, Ralph Doncaster wrote: On Wednesday, 7 February 2018 at 22:31:58 UTC, John Gabriele wrote: I'm not sure how long dub has been around, but having an easy to use CPAN-alike (online module repo) is HUGE. Dub is great for sales. The better dub and the repo gets, the more attractive D gets. I completely agree that the availability of libraries is a huge factor. I almost gave up on D because of the limited amount of 3rd party libs. I think just improving the search function would help. http://code.dlang.org/search?q=keccak Comes up with nothing, so I started porting a sha3/keccak lib from C to D. Then someone pointed out botan has sha3 support, which can be found if you search for "crypto" http://code.dlang.org/search?q=crypto The opposite situation you may see, when searching for mysql: You will get 9 packages listed. Which should I take? If you click on everyone, you will realize, that some of them are forks of other. And the version number of mysql-native at the top, just recently increased so strong, that it makes a different. The minimum additional information which should be listed - I think - is the number of downloads and GitHub stars. I know that there is work behind the scene to find some kind of weighted sort, this would be cool, but just displaying the GitHub voting might help a lot.
Re: Bye bye, fast compilation times
On Monday, 5 February 2018 at 21:27:57 UTC, H. S. Teoh wrote:
One of my D projects for the past while has been taking
unusually long times to compile. This morning, I finally
decided to sit down and figure out exactly why. What I found
was rather disturbing:
--
import std.regex;
void main() {
auto re = regex(``);
}
--
Compile command: time dmd -c test.d
Output:
--
real0m3.113s
user0m2.884s
sys 0m0.226s
--
Comment out the call to `regex()`, and I get:
--
real0m0.285s
user0m0.262s
sys 0m0.023s
--
Clearly, something is wrong if the mere act of compiling a
regex causes a 4-line program to take *3 seconds* to compile,
where normally dmd takes less than a second.
Thank you for this finding!
I was wondering why my little vibe.d project started to take
approximately twice the
time to compile, and because of making a mistake in my test
setup, even my minimal
program still included the file containing the regex. So that
even reducing the used
code to a minimum the compilation time was ~7 sec compared to
less than 4 seconds.
Would be cool if we could get fast compilation of regex.
I am coming from using scripting languages (perl and ruby) using
regex a lot, so that this is really disappointing for me.
Beginner question:
How to split my project, to compile the regex part separately as
a lib and just link them?
Re: !Alert! dlang.org SSL Error
On Tuesday, 6 February 2018 at 14:57:27 UTC, Jan Knepper wrote: [...] Will keep an eye on it. Everybody else who hits the website regularly who experiences the problem, please report ASAP. Thanks! Jan Thank you, no SSL error! But some missing text: In the News section: Stay updated with lastest article in the Official D Blog from : by . From : by . + my browser just highlights "lastest" .
Re: !Alert! dlang.org SSL Error
On Tuesday, 6 February 2018 at 13:42:18 UTC, Martin Tschierschke wrote: Please contact the owner of the website to inform him of this issue. Same for me. I don't have any issues on my machine with Chrome and Firefox.. Hmm, my phone with chrome on android7 and chrome on ipad2 no problems,too. @forum.dlang.org and @code.dlang.org everything ok.
Re: !Alert! dlang.org SSL Error
On Tuesday, 6 February 2018 at 13:31:23 UTC, Seb wrote: On Tuesday, 6 February 2018 at 13:18:26 UTC, Jakub Łabaj wrote: On Tuesday, 6 February 2018 at 10:05:52 UTC, Martin Tschierschke wrote: Chromium: ERR_SSL_PROTOCOL_ERROR [...] Please contact the owner of the website to inform him of this issue. Same for me. I don't have any issues on my machine with Chrome and Firefox.. Hmm, my phone with chrome on android7 and chrome on ipad2 no problems,too.
!Alert! dlang.org SSL Error
Chromium: ERR_SSL_PROTOCOL_ERROR With Firefox and Chomium and with different Ubuntu Versions (17.10 and 16.04.) Firefox - Google translated: Error: Secure connection failed An error occurred while connecting to dlang.org. SSL has received an entry that has exceeded the maximum allowed length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG The website can not be displayed because the authenticity of the received data could not be verified. Please contact the owner of the website to inform him of this issue.
Re: Quora: Why hasn't D started to replace C++?
On Friday, 2 February 2018 at 08:39:58 UTC, Paolo Invernizzi wrote: On Friday, 2 February 2018 at 08:21:33 UTC, Martin Tschierschke [...] Maybe there should be a blog post, with some kind of status report every .. weeks or .. month? Telling more about the focus of the D foundation, statistics of downloads, number of fixed bugs, partly similar to Adams week in D but more official. I think the content of such a post may find its way into more mainstream IT magazines, if marked as official d foundation press release even more. The best status report I've met is definitely the FreeBSD quarterly status report: https://www.freebsd.org/news/status/status.html I suggest to take a look at that, as an inspiration and yes, a quarterly report is enough. /Paolo Yes, looks very good!
Re: Quora: Why hasn't D started to replace C++?
On Thursday, 1 February 2018 at 22:38:36 UTC, Walter Bright wrote: On 2/1/2018 3:11 AM, Martin Tschierschke wrote: Idea: There should be some kind of news ticker for all enhancements and important decisions, maybe at first just via twitter with a special #tag beside #dlang where all updates are announced. And a place on the homepage, where this feed is displayed separately. It's already there on the right side of https://dlang.org/ with a special #tag beside #dlang The focus was on a feed with _two_ tags #dlang and #dfoundation for example. In the feed on the homepage everything is mixed up and I am feeling a lot information about progress - made in the background - is missing. Maybe there should be a blog post, with some kind of status report every .. weeks or .. month? Telling more about the focus of the D foundation, statistics of downloads, number of fixed bugs, partly similar to Adams week in D but more official. I think the content of such a post may find its way into more mainstream IT magazines, if marked as official d foundation press release even more.
Re: Quora: Why hasn't D started to replace C++?
On Wednesday, 31 January 2018 at 18:35:50 UTC, Seb wrote: [...] Like: https://github.com/adamdruppe/arsd/blob/master/simpledisplay.d And the examples from D-Lang Tour. So you only push a button [try D], and get a running environment to play around. Like this? https://tour.dlang.org/tour/en/dub/mir It's a small series since today. Any help with filling the blank content or new pages is welcome. See https://forum.dlang.org/post/acovehcwaxjykmhek...@forum.dlang.org for adding new libraries to run.dlang.io This looks very promising! Have not been on the dang tour page for several month, it shows an amazing progress!! Idea: There should be some kind of news ticker for all enhancements and important decisions, maybe at first just via twitter with a special #tag beside #dlang where all updates are announced. And a place on the homepage, where this feed is displayed separately. On the other side a voting mechanism in the forum would be very useful, so readers can mark a post as valuable maybe to be be displayed in a special feed. I know this is difficult because the forum has more than only the web frontend. But why not translate the [I recommend to read this]-Button into a mail or post, with the content ... **recommend** this. And probably back? from short mail only with **KEYWORD**. It would fill up the mailboxes of the readers, but it would be easier to count than this "me too ++" posts.
Re: Quora: Why hasn't D started to replace C++?
On Wednesday, 31 January 2018 at 11:42:14 UTC, Seb wrote: [...] This is about to change soon for D. There's WIP to use OpenCollective The announcement should happen soon. Stay tuned! [...] Here's a spoiler: 1) Andrei does an excellent job at managing his students [1] and there work over the last couple of months has been tremendous. As the experiment with UPB was very successful, there will be more projects like this one and global scholarship 2) The vision document will finally get updated (there have been a few delays due to holiday, illnesses etc.) https://wiki.dlang.org/Vision/2017H2 3) More community input (I'm preparing a State of D survey atm) 4) More active voting by the community on important issues 5) Better documentation and overview on what the foundation is doing Currently under discussion/work: 6) Using OpenCollective for tracking expenses openly 7) Offering membership packages for companies 8) Doing bi-annual Kickstarter compaigns for important issues to the community (e.g. "fix shared") [...] As mentioned above, there's. However, it's not very visible as a lot of work happens in stealth-mode atm and only a tiny bit makes it to the DBlog: https://dlang.org/blog/category/core-team https://dlang.org/blog/category/d-foundation Thank you for your post, very interesting background information. I like 7) and 8) very much! ( 8) needs 4) )
Re: Quora: Why hasn't D started to replace C++?
On Wednesday, 31 January 2018 at 12:03:22 UTC, rjframe wrote: On Wed, 31 Jan 2018 10:55:56 +, Benny wrote: [...] Anyway, mostly because of your recent posts I'm going to take a look at DlangIDE. If we can package a cross-platform IDE+compiler+dub as a single download and you're ready to go, that might make it easier to give D a try, even if most people would later set up something else; at least you'd only deal with the problems after you've decided it's worth it. Yes, would be very good! And than ad a series of short example programs, to this one-stop-download, maybe party from Adam's arsd. Like: https://github.com/adamdruppe/arsd/blob/master/simpledisplay.d And the examples from D-Lang Tour. So you only push a button [try D], and get a running environment to play around.
Has any body taken a look at monetdb?
An old friend of mine is working in the database research group in Amsterdam, they have developed monetdb: From https://www.monetdb.org/Home The column-store pioneer The column store technology of MonetDB has found its way into the product offerings of all major commercial database vendors. Its pioneering role has been internationally recognized with the prestigious ACM SIGMOD Edgar F. Codd Innovation Award and ACM SIGMOD Systems Award. The market for applications empowered by these techniques provide ample space for further innovation, e.g. as demonstrated by our ongoing projects. At the same time, the landscape for major innovations remain wide open. A peek preview is given in the award winning paper titled: The Researcher's Guide to the Data Deluge: Querying a Scientific Database in Just a Few Seconds. I just found that there everything is now on Git hub, with clients written for: Ruby, Perl, PHP, Python and Java. https://www.monetdb.org/blog/monetdb-on-github I just took a short look into the Ruby client code, I have not used Monetdb yet, but is there anybody interested in trying to make a D client? I think it might give an interesting storage concept especially for people using D for Big Data. Any comment? Regards mt.
Re: Bump the minimal version required to compile DMD to 2.076.1
On Friday, 12 January 2018 at 16:13:39 UTC, Seb wrote: Motivation -- 1) It's required for Walter's work on using -betterC for the backend conversion: https://github.com/dlang/dmd/pull/6907 That is only a putative dependency. Indeed the -mv== feature is useful. If it's just about the backend though, there is a straightforward solution. If we insist on having a backend package (not under dmd) ``` module backend.cod1; ``` then we can simply move the package to the right place ``` mv src/dmd/backend src/backend ``` . Imports of dmd from backend obviously forbidden (should be enforced by separate compilation). 2) We start to run into random failures lately, e.g. https://github.com/braddr/d-tester/issues/63 https://github.com/dlang/dmd/pull/7569#issuecomment-356992048 3) There's also WIP to move dmd-cxx to 2.076.1: https://github.com/dlang/dmd/pull/7595 We've been through bootstrapping discussions a couple of times, so let me repeat what was decided when we made the frontend switch from C++ to D. - Other platforms are bootstrapped by cross-compilation. - DMD must be compilable with the latest stable/major release of dmd, ldc, and gdc. To enforce this policy the Travis-CI test was set up. Hopefully this original purpose of the Travis-CI hasn't been forgotten in the meantime. - No other guarantees were negotiated. Sticking to an ancient compiler defeats the eat your own dogfood goal underlying the C++ -> D transition. The latest released frontend versions are at the moment: 2.078 - dmd (2.078.1) 2.077 - ldc (1.7.0) 2.068 - gdc (6.3.0+2.068.2) So technically we could only upgrade to 2.068 atm. Would be good to hear some release plans from the GDC team for this year. == Just in case this is what dmd's schedule looks like for 2018. 2.078.0 - 2018-01-01 2.079.0 - 2018-03-01 2.080.0 - 2018-05-01 2.081.0 - 2018-07-01 2.082.0 - 2018-09-01 2.083.0 - 2018-11-01 2.084.0 - 2019-01-01 I wished the semver discussion¹ would have been a bit more decisive and we'd started out the year with 8.0.0 (majors every 6 months, minors every 2 months). Hopefully we take the chance of relabeling 2.080.0 to 8.0.0. [¹]: http://forum.dlang.org/post/eghpfllbnvvlskbdp...@forum.dlang.org
Re: !Alert! code.dlang.org down
On Wednesday, 10 January 2018 at 23:25:16 UTC, Guillaume Piolat wrote: On Wednesday, 10 January 2018 at 10:10:22 UTC, Martin Tschierschke wrote: In the moment I don't have access, hopefully this is only temporal problem and the rescue team for fixing is already on the way... Tips from the folks on Discord, for DUB outages: 1. If you have all required dependencies in your cache, and just want to avoid the network: dub --skip-registry=all Very useful on slow networks. However this won't help if you don't have the libraries in your cache. 2. If you wish to use a mirror dub --skip-registry=standard -v --registry=http://code-mirror.dlang.io 3. If you need to fetch packages and mirror are down too - git clone every repositery you need from GitHub - $ dub add-local in every of these repositery You might want to checkout older tags if you are not using the latest version of these repositeries. Thank you for the hints, actually my problem was, that I wished to access the DUB docs. And the strange thing was, that even the google cache tried to connect to code.dlang.org during delivery of the cached page, so that even looking on the cached google content took quite a long time before there was a timeout. Therefore we should think about placing these kinds of infos about DUB not on the DUB server at code.dlang.org.
!Alert! code.dlang.org down
In the moment I don't have access, hopefully this is only temporal problem and the rescue team for fixing is already on the way...
Re: vibe.d Error only with Firefox
On Friday, 5 January 2018 at 16:47:53 UTC, Steven Schveighoffer wrote: On 1/5/18 11:30 AM, Martin Tschierschke wrote: Hello, when starting my vibe.d service I get the message of failed address binding: Failed to listen on 127.0.0.1:8030 Failed to listen on 10.0.0.1:8030 object.Exception@../../.dub/packages/vibe-d-0.8.2-rc.2/vibe-d/http/vibe/http/server.d(2035): Failed to listen for incoming HTTP connections on any of the supplied interfaces. It's attempting to listen on localhost:8030, and 10.0.0.1:8030, but can't bind to either address. Then it looks like you get an exception. Does it actually continue running? Yes it works, the only strange thing is, that firefox seams to handle the direct use of the ip-address in a strange way. sudo netstat -nlp | grep 8030 tcp0 0 10.0.0.1:8030 0.0.0.0:* LISTEN 31181/mysql-browse tcp0 0 127.0.0.1:8030 0.0.0.0:* LISTEN 31181/mysql-browse looks o.k., (mysql-browse is my program). I will try to minimize my program, to see if it has anything to do with my coding or if the error is caused by something else. Thank you all (Steven, Webfreak and Crimaniak). As mentioned before in "normal" environments, when using a name based request, there is no error, so I can work around it, but for people just starting with vibe + Firefox the first impression should not be: Oh, what the ... is that ... :-)
vibe.d Error only with Firefox
Hello, when starting my vibe.d service I get the message of failed address binding: Failed to listen on 127.0.0.1:8030 Failed to listen on 10.0.0.1:8030 object.Exception@../../.dub/packages/vibe-d-0.8.2-rc.2/vibe-d/http/vibe/http/server.d(2035): Failed to listen for incoming HTTP connections on any of the supplied interfaces. This has been mentioned here: http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/3480/ The strange thing is now, that when using Chromium http://10.0.0.1:8030 works! But with Firefox http://10.0.0.1:8030 gives the long Error: 400 - Bad Request Bad Request Internal error information: object.Exception@../../.dub/packages/vibe-d-0.8.2-rc.2/vibe-d/stream/vibe/stream/operations.d(363): Reached maximum number of bytes while searching for end marker. ... truncated ./../.dub/packages/vibe-d-0.8.2-rc.2/vibe-d/core/vibe/core/core.d:1269 void vibe.core.core.CoreTask.run() [0x94574a] ??:? void core.thread.Fiber.run() [0xa3c7ff] ??:? fiber_entryPoint [0xa3c562] ??:? [0x] On the other side, when using http://localhost:8030/ or any other domain mapped to to 10.0.0.1 (in /etc/hosts) even Firefox works. The error is relatively new since one of the last Firefox updates.
Re: SDL2 texture blend help
Dne 13.12.2017 v 4:03 Ivan Trombley via Digitalmars-d napsal(a): > On Wednesday, 13 December 2017 at 01:44:33 UTC, Dmitry wrote: >> On Tuesday, 12 December 2017 at 23:28:23 UTC, Ivan Trombley wrote: >>> Here's the code that produces the correct results (exactly the same >>> as GIMP): >> Share images you used, please. > > Background image: > http://a4.pbase.com/o10/09/605909/1/166706859.XKZZCnSO.background.png > > Foreground image: > http://a4.pbase.com/o10/09/605909/1/166706860.c1yD4VWp.image.png > > Composited through SDL: > http://a4.pbase.com/o10/09/605909/1/166706869.wLt9RofY.sdl.png > > Composited in GIMP 2.9: > http://a4.pbase.com/o10/09/605909/1/166706870.S01BIhVG.gimp.png > > When composited using the code I posted looks exactly like the GIMP 2.9 > image. I am not sure, about the tool you use to view the images, but on my side (Firefox browser) the sdl and gimp output are very different. Maybe some gamma shenanigans going on? Maybe related to PNG Gamma correction...
Re: Google alert for "dlang"
On Sunday, 3 December 2017 at 05:12:44 UTC, Ex Nihilo wrote: Google Search and its proxies (e.g. startpage) have also stopped trying to correct dlang as golang. This is a welcome change! YES!!!
Re: DIP 1006 - Preliminary Review Round 1
On Wednesday, 12 April 2017 at 11:25:09 UTC, Mike Parker wrote: DIP 1006 is titled "Providing more selective control over contracts". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md Has come up a couple of times and it's a good idea to allow more control over which checks are enabled. I find the suggested switch levels a bit counter-intuitive and would suggest -release=assert,in,out,invariant to be the equivalent of the current -release while allowing to enable any subset, e.g. -release=assert,in. The effect of -release=assert -release=in would be to enable both. Using -release= also avoids any confusion about the interaction of -release and -contracts=.
Re: DIP 1006 - Preliminary Review Round 1
On Wednesday, 12 April 2017 at 15:02:49 UTC, Mathias Lang wrote: I would say that `-contracts=none` and `-unittest` should behave the same as `-release` and `-unittest`, and currently it only turns asserts on ( https://github.com/dlang/dmd/blob/ac3225a025b578d45ff39a40dda35006fb455a37/src/ddmd/mars.d#L1100-L1109 ). I'll add a note about it in the DIP. As said above, asserts in unittests are different, so we could separate enabling asserts in unittests and in the rest of the program.
Re: My two cents
On Monday, 23 October 2017 at 11:58:14 UTC, Laeeth Isharc wrote: Bountysource went quiet, though I started contributing to it. I wonder if there is a better way for commercial users to say what they might be willing to pay for and how much. At best talk to Andrei, maybe you have a good idea to do this over the Foundation.
Re: My two cents
On Monday, 23 October 2017 at 13:18:21 UTC, Guillaume Piolat wrote: By any means, if someone wants to help here, get in touch with Benjamin Thaut and me. This has been lingering around for way to long, and Benjamin alone has a hard time pushing this. Would Bountysource help be adequate? Not sure about Benjamin, but on my side it's time limited. I'd Bountysource didn't work out too well for us.
Re: My two cents
On Tuesday, 24 October 2017 at 09:56:50 UTC, rikki cattermole wrote: scope+ref+out as arguments would be a no-no. Now if we could ditch registers usage crossing before/after yield, we wouldn't need to do 'patching' like fibers do. That's basically what asnyc/await does, some implementations as continuation (callback) some as jump rewrite.
Re: My two cents
On Monday, 23 October 2017 at 09:13:45 UTC, Satoshi wrote:
On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
Hi,
I had been using D for almost 6 years and I want to share my
opinion with you.
I don't want to blame anyone but I'll focus more on bad things
and possible improvements.
And this is just how I see D from my perspective.
(Sorry for my English, I'm too lazy to take the lessons).
[...]
Whats about this one?
auto foo = 42;
auto bar = "bar";
writeln(`Foo is {foo} and bar is {bar}`);
String interpolation could be done in a library.
fmt!("Foo is ${foo} and bar is ${bar}", foo, bar)
At the moment you'd just use format.
format!"Foo is %1$s and bar is %2$s"(foo, bar);
While both are a bit more verbose, it seems to me that
interpolated strings aren't that big a deal.
Collecting arguments and design ideas in a DIP would still be
worthwhile and very welcome.
Even if ends up not being approved, it would ensure a good
decision base and avoid future discussions.
Sth. like
s"Foo is ${foo} and bar is ${bar ~ `bla`}"
to be lowered to
format!"Foo is %1$s and bar is %2$s"(foo, bar ~ `bla`).
could be a feasible approach on a first thought.
Re: My two cents
On Monday, 23 October 2017 at 11:23:18 UTC, Guillaume Piolat wrote: Not anymore, you can use the "export" keyword for Windows (eg with LDC >= 1.2). With what semantic? Every-symbol-public-by-default in Posix is annoying though :) We agreed on hidden visibility by default for everything that's not exported. This requires export to be fixed on non-Windows machines first. By any means, if someone wants to help here, get in touch with Benjamin Thaut and me. This has been lingering around for way to long, and Benjamin alone has a hard time pushing this.
Re: My two cents
On Saturday, 21 October 2017 at 18:52:15 UTC, bitwise wrote: On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote: async/await (vibe.d is nice but useless in comparison to C# or js async/await idiom) Reference counting when we cannot use GC... If I understand correctly, both of these depend on implementation of 'scope' which is being worked on right now. Scope is about preventing pointer escaping, ref-counting also needs to make use-after-free safe which is currently in the early spec phase. Whether or not that is going to be a compile-time or runtime check has yet to be figured out. If you have a great idea that we should consider, let us know. The recent IOPipe window invalidation discussion was a good example of what such a mechanism would hopefully be able to handle (https://gist.github.com/MartinNowak/b406a6b7aa6d0964147c107771b64333#file-safety_dance-d-L43-L45). I think reference counting needs 'scope' to be made safe. RC also benefits from scope in that many of the increments/decrements of the ref count can be elided. The performance gain can be significant, and even more so when you use atomic reference counting (like C++ shared_ptr) for thread safety. Well, there can be RC and shared(RC), only the latter would need to do atomic ref-counting. Async/Await needs to allocate state for the function's local variables. When it's detected that the function's state/enumerator won't escape it's current scope, it can be put on the stack, which is a pretty big optimization. We should figure out how to allocate RC/unique delegate contexts. Not that with async/await you always escape the local context, as it's the callback in the returned Promise/Task.
Re: My two cents
On Sunday, 22 October 2017 at 22:00:19 UTC, bitwise wrote: I hope resumable functions for for generator/coroutine style usage are also part of the plan. Allocator support would be nice too. Please see https://forum.dlang.org/post/pbnthucxpvbgzzuig...@forum.dlang.org for how this could be implemented and why this is not much of a priority right now. If someone wants to pull this off, the effort would be very welcome.
Re: My two cents
On Monday, 23 October 2017 at 11:02:41 UTC, Martin Nowak wrote: In C++ incremental rebuilds are simple as you compile each file individually anyhow, but that's the crux for why C++ compilations are so slow in the first place. Compiling multiple modules at once provides lots of speedups as you do not have to reparse and analyze common/mutual imports, but on the downside it cannot be parallelized that well. dub supports --buildMode=singleFile --parallel to mimic that, but it's very wasteful. For example gtk-d took way over a minute with single file compilation, but only a few seconds when being compiled at once
Re: My two cents
On Monday, 23 October 2017 at 06:05:50 UTC, drug wrote: 20.10.2017 17:46, Martin Nowak пишет: My 2 cent: 1. dub needs ability to work with other repository than standard ones. You mount or clone whatever you want and use `dub add-local`. 2. multicore building - entire project in D builds faster than C++ one (I have two implementation of the same), but in case of incremental building C++ faster. I always assumed this to be the main point why people are asking for a better build tool, but it's not sth. dub can do atm. It's a limitation of the compiler that requires various changes and a slight redesign of our build model. In C++ incremental rebuilds are simple as you compile each file individually anyhow, but that's the crux for why C++ compilations are so slow in the first place. Compiling multiple modules at once provides lots of speedups as you do not have to reparse and analyze common/mutual imports, but on the downside it cannot be parallelized that well. Dub could parallelize building individual packages/sub-packages (target + dependencies) right now though. 3. dub single build mode does not caches builds so it builds entire project every time. Could you please file an issue with a test case for that. Why do you use single build mode in the first place?
Re: My two cents
On Monday, 23 October 2017 at 10:42:35 UTC, drug wrote: Also such build system should provide a way to build C/C++ (and others) codebase or let other build systems build D codebase, using generated makefile for example. In fact dub can generate cmake files, more generators for e.g. ninja or meson could be added.
Re: My two cents
On Friday, 20 October 2017 at 22:25:20 UTC, Adam Wilson wrote: For example, ?? and ?. are ridiculously common idioms that we all perform every day in our D code. And as Mr. Ruppe rightly pointed out, it'd probably take about an hour each to knock together a complete PR for these features. Well, ignoring communication doesn't make it unnecessary. It just means that the communication has to happen after throwing a drive-by PR at us. Would be great if we could adequately capture arguments to facilitate those discussions. Seems like there wasn't even an ER for that https://issues.dlang.org/show_bug.cgi?id=17924.
Re: My two cents
On Friday, 20 October 2017 at 18:11:50 UTC, Adam D. Ruppe wrote: On Friday, 20 October 2017 at 16:36:28 UTC, jmh530 wrote: It might help to have some sense of how the main devs time on D is being used. Definitely, I currently have no clue what they are on. Tried that, didn't resonate that much, and is also quite some work. So we mostly stick to internal discussions atm. https://forum.dlang.org/post/o2g7mg$12oa$1...@digitalmars.com Timelines and planning also don't work too well with volunteering.
Re: My two cents
On Friday, 20 October 2017 at 20:05:51 UTC, jmh530 wrote:
Interesting proposals, but IMHO, the only ESSENTIAL feature
missing in D is the possibility to program in D using a
built-in reference-counting based variant of the standard
library.
Look at the goals for H2 2017
https://wiki.dlang.org/Vision/2017H2
The top three things: 1) @safety, 2) @nogc, 3) betterC. Under
#2, it specifically says safe reference counting. It's getting
worked on...
Yes, it's being worked on, but it's also a huge topic to come up
with @safe memory management approach. It's literally about
eradicating one of the biggest security bug classes,
use-after-free.
Currently I'm working towards an ORM library starting at I/O
(https://github.com/MartinNowak/io) to better inform the
necessary design.
We already found couple of interesting litmus tests, like the
window in iopipe.
auto window = iopipe.window;
iopipe.extend(512); // invalidates window :/
window[0]; // use after-free
Another thing that Walter previously found out is that exceptions
are a major hassle for @nogc. I don't like the RC Exception
solution much though, as it's a fairly specific workaround
(https://github.com/dlang/druntime/pull/1804).
Towards that goal, making exception nesting optional and
providing access to the current Exception in flight would allow
to use the staticError approach in most places.
https://github.com/dlang/druntime/blob/bc832b18430ce1c85bf2dded07bbcfe348ff0813/src/core/exception.d#L683
Recently I wondered why we cannot semantically transform
exceptions to the equivalent of function calls.
- throw Uniq!Exception; // ctor, some struct that's implicitly
convertible to a Throwable
- catch (scope Exception e) // handler 1
{
throw e; // basically continue to unwind
}
- catch (scope Exception e) {} // handler 2
- done unwinding, destroy thrown value
We still support gotos in catch handlers, but should be possible
to call destructors in catch handlers anyhow.
https://github.com/dlang/druntime/pull/1804/files#diff-f3953348bb302c27a8cea926c62c02e6R69
Re: My two cents
On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
First, D started as a great new language with the best from all
languages. But now D seems more and more conservative. New
syntactic sugars aren't added just because they can be found in
phobos. (this was Walter's answer when I asked for maybe monad
syntactic sugar).
OK, what I'm missing in D and what I think is wrong?
syntactic sugar for:
tuples
maybe monad (why we cannot have same syntax as in C#?)
conditional dereferencing and stuff about that (same as in C#)
foo?.bar;
foo?[bar];
return foo ?? null;
With much stronger typing it's a bit trickier, most things in D
are not classes/pointers, hence there is no universal null/nil.
async/await (vibe.d is nice but useless in comparison to C# or
js async/await idiom)
I want to create function returning Promise/Task and await
where I want to.
e.g.
auto result = device.start(foo, bar); // This is RPC to remote
server returning Task!Bar
// do some important stuff
return await result; // wait for RPC finish, then return it's
result
I want to do this and not any ugly workaround about that.
It's not that hard to add full async/await support to the
compiler. The code for capturing upvalues is already there to
support foreach opApply callbacks. We still don't have @nogc
delegates, but that's also not too much of a hassle.
While it could be implemented, priority isn't too high. At least
for I/O-bound workloads, the performance gains over stack based
async is rather small. Would be different for using async/await
for parallel HPC (http://stellar-group.org/libraries/hpx/).
If you want to run 2 async tasks concurrently with Fibers, just
use e.g. http://vibed.org/api/vibe.core.core/runTask.
@trusted, @safe, @system - why we have 3 keywords instead of
one? And why it's so complicated to use?
First, we should have one 'unsafe' keyword.
Second, everything should be safe by default.
3rd, if we want to declare @system func, use 'void foo()
unsafe;'
if we want to declare @trusted func, use
void foo() {
unsafe {
}
}
Sounds easy and nice, but isn't compatible with separate
compilation and headers, which in fact are key to good compile
times.
C# properties instead of existing ones.
function and property should be two different things.
Calling function without () or assigning to it by = is a ugly
behavior and should be avoided.
Different folks, different strokes. Lots of people seem to like
optional parens, in particular for `arr.map!(e => e ^^
2).each!writeln` chains.
Maybe you just need to get used to them. Otherwise write a Linter
that slaps you whenever you forget them.
implement this thing from C# (just because it's cool)
new Foo() {
property1 = 42,
property2 = "bar"
};
Reference counting when we cannot use GC...
WIP
Commercial usage, shared libraries and stuff
There isn't any handy tool to download, manage and publish
closed source stuff.
dub is great for simple solutions but useless in big projects
with multiple targets, configurations, etc.
Everything is primary focused on opensource development (but
everyone here wants to see D as a next successor of C++ in
commercial sphere).
Well, dub is a package manager to share code, so obviously OSS it
the main target. You can easily `dub add-local` packages or run
your private registry.
And of course there are various other options like Make, CMake,
Meson, or Raggae.
Still cannot easily develop closed source dlls on Windows. On
Linux every symbol is public by default, but on Windows not so
it's needed to export them manually.
WIP
(https://github.com/dlang/DIPs/blob/master/DIPs/archive/DIP45.md)
Cannot is quite strong, it just requires a bit of work.
Unable to publish closed source library without workaround and
ugly PIMPL design.
Why is that?
For templates and inference the compiler needs to see stuff in
order to compile them.
This is the same contradiction as with you unsafe block
suggestion above.
If you know sth. really smart here, make sure to let us know :).
Add dll/so usage without header files
(export enums, templates and stuff right into dll/so and let D
compiler to import these stuff from it)
like return ref parameters and return functions but is unable
to add some basic stuff.
We could do better on communicating our plans. Return ref and
scope are part of a major effort to transition to manual memory
management (RC et.al.) without buying into the associated memory
corruptions (and security issues) that plague C/C++.
As unfortunately with almost any OSS project, we're not that many
people, and each of us is investing a huge amount of time into
this.
OTOH we're getting tons of requests, which are often hard to
prioritize. Most of them are particular interests as well (you
seem to have an edge for C#).
Would be great if you could attach some estimated costs to each
of your points, i.e. how much effort does this or that cause for
you.
Re: My two cents
On Friday, 20 October 2017 at 08:09:59 UTC, Satoshi wrote: > return foo ?? null; would be so much easier. Definitely the Elvis operator is a small and sometimes useful addition. https://en.wikipedia.org/wiki/Elvis_operator Your best bet on getting it, is writing a small DIP, the organize consensus for the exact semantics to get it approved. https://github.com/dlang/DIPs/ It's seems far from being a high priority though. Actually quite a pity that of the many valid points you mentioned, the majority of the discussion focuses on this triviality. But as usual, when it's cheap to have an opinion, everyone affords one. Hence if you want to change sth. get your DIP approved. I'd even volunteer for the compiler implementation of `?:`.
Re: My two cents
On Thursday, 19 October 2017 at 06:50:12 UTC, Fra Mecca wrote: We miss a build system that is tailored towards enterprises Anything more specific on that?
Re: [your code here] HexViewer
On Thursday, 3 August 2017 at 08:47:12 UTC, Martin Tschierschke
wrote:
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;
}
Very cool!
Now you can remove: std.format,
and I would substitute: byChunk(16) with byChunk(col)
Error should be cols: byChunk(cols)
Can you point me to the explanation of this: %(%02X %)%*s %s ?
Ah I found it myself:
https://dlang.org/library/std/format/formatted_write.html
The %( %) called "nested array formatting" was new for me.
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;
}
Very cool!
Now you can remove: std.format,
and I would substitute: byChunk(16) with byChunk(col)
Can you point me to the explanation of this: %(%02X %)%*s %s ?
Best regards mt.
Re: Dlang + compile-time contracts
On Monday, 31 July 2017 at 17:54:04 UTC, Marco Leise wrote: Coming from D.learn where someone asked for some automatism to turn runtime format strings to `format()` into the equivalent `format!()` form automatically to benefit from compile-time type checks I started wondering... The OP wasn't looking for other benefits of the template version other than argument checking and didn't consider the downsides either. So maybe there is room for improvement using runtime arguments. So let's add some features: 1) compile-time "in" contract, run on the argument list 2) functionality to promote runtime arguments to compile-time This was the more precise question: How to "promote runtime arguments to compile-time". I forgot the exact error, but it was during using vibe.d, that there was an error popping up at runtime, which I thought should have been detected as simple syntax violation already during compile time. Making me feeling for some seconds being back at .php. :) I think it was in a regex, where the use of ctRegex would have prevented me from the runtime error. And last but not least: Thank you Marco for sharing your thoughts and expertise! Regards mt.
Re: The X Macro using D
On Saturday, 22 July 2017 at 11:50:40 UTC, Stefan Koch wrote: tuple map and array are all pretty expensive. please profile. Well a bit more compile time isn't the end of the world, and by far not the only metric (e.g. readability and maintainability also rank high). You're slightly obsessed with the template compile-time topic ;). BTW, the term expensive is fairly subjective easily misunderstood. Sth. more specific would reduce the chance for confusion, e.g. "tuple map and array require longer to compile"
Re: D easily overlooked?
On Friday, 14 July 2017 at 13:29:30 UTC, Joakim wrote: On Friday, 14 July 2017 at 09:29:27 UTC, Wulfklaue wrote: On Friday, 14 July 2017 at 09:02:58 UTC, Stefan Koch wrote: The beauty of D lies in it's holistic approach. [...] But with tech nowadays, you need a good foundational design before all else. Yes, someone else may get out of the gate faster with the bicycle they built out of spare parts, but once you get the Millenium Falcon going, it will blast by them. ;) Off topic - but do you know this https://lilium.com/ :-)
Re: D Milestones
On Wednesday, 12 July 2017 at 14:16:48 UTC, rikki cattermole wrote: On 12/07/2017 3:14 PM, Martin Tschierschke wrote: Please post events (even without date) you think are important. First release of your IDE/Plugin or whatever made you more comfortable using D. Since when is the IRC channel in use? Since like 2003 when it was registered on Freenode. Thanks. Just inserted it into the draft.
Re: D Milestones
On Wednesday, 12 July 2017 at 13:18:54 UTC, jmh530 wrote: On Wednesday, 12 July 2017 at 12:40:21 UTC, Martin Tschierschke wrote: On Monday, 26 June 2017 at 18:16:12 UTC, Patrick Schluter wrote: On Monday, 26 June 2017 at 12:58:00 UTC, Andrea Fontana wrote: On Monday, 26 June 2017 at 10:14:08 UTC, Martin Tschierschke [...] So the first version 0.0.1 of this in the Wiki, please help to update! https://wiki.dlang.org/Language_History_and_Future I would recommend going through the changelogs and picking out some key developments. At a minimum, it provides information like D 2.0 was released June 17, 2007 (D 1.001 Jan. 23, 2007). I don't see much on the prior history. http://dlang.org/changelog/ http://www.digitalmars.com/d/1.0/changelog.html Thank you, will do so. Please post events (even without date) you think are important. First release of your IDE/Plugin or whatever made you more comfortable using D. Since when is the IRC channel in use?
Re: D Milestones
On Wednesday, 12 July 2017 at 13:11:47 UTC, Nicholas Wilson wrote: On Wednesday, 12 July 2017 at 12:40:21 UTC, Martin Tschierschke wrote: On Monday, 26 June 2017 at 18:16:12 UTC, Patrick Schluter wrote: On Monday, 26 June 2017 at 12:58:00 UTC, Andrea Fontana wrote: On Monday, 26 June 2017 at 10:14:08 UTC, Martin Tschierschke [...] So the first version 0.0.1 of this in the Wiki, please help to update! https://wiki.dlang.org/Language_History_and_Future If you're looking for more info Leandro's Keynote (DConf 2016?) has lots of history. Yes, thanks: http://dconf.org/2016/talks/lucarella.pdf
Re: D Milestones
On Monday, 26 June 2017 at 18:16:12 UTC, Patrick Schluter wrote: On Monday, 26 June 2017 at 12:58:00 UTC, Andrea Fontana wrote: On Monday, 26 June 2017 at 10:14:08 UTC, Martin Tschierschke [...] So the first version 0.0.1 of this in the Wiki, please help to update! https://wiki.dlang.org/Language_History_and_Future
Re: CTFE Status 2
On Wednesday, 12 July 2017 at 07:58:30 UTC, Stefan Koch wrote: On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: [ ... ] long story short: This is now fixed. and ABI bugs are HELL! Cheers, Stefan As being a newbie, could you please point to a post describing what you are doing in more general terms. Answering the question, what will the new CTFE bring to us all and when should we start preparing a big celebration for the time it gets part of DMD?
Re: version=D_16
On Monday, 10 July 2017 at 23:01:50 UTC, Luís Marques wrote: On Monday, 10 July 2017 at 22:39:22 UTC, Petar Kirov [ZombineDev] wrote: The problem Walter pointed to is that due to integer promotion, arithmetic operands of types smaller than int are converted to int, hence even if you use bytes and shorts you would end up using ints, which are expensive on CPUs with no native 32-bit registers. In theory, you could write your code so that it's easy for the optimizer to prove that you're only using 8 or 16 bits and variables would fit in single registers, so you would be able to get away without a performance penalty for using a language where ints are 32-bit. Ah, that makes sense. Thanks for clarifying. For me it hasn't proved a problem, but I could see it being if you do a lot of arithmetic with 16-bit integers. I just want to point out, that my impression is that the maker scene using all this 16 bit Arm Arduino and what ever micro controllers, would be happy to have D as an alternative for coding in C. So BetterC and D_16 might attract a way bigger community than many other might think. Even if this reduced language might need to be named D-- :-).
Re: Types: The Next Generation (Was: Why is phobos so wack?)
On Sunday, 9 July 2017 at 20:22:16 UTC, Nick Sabalausky
(Abscissa) wrote:
SomeString fizzbar(RandomAccessRange!SomeNumeric r) {...}
Looks like concepts.
We've settled on leveraging the already useful template
constraints (at best in CNF [¹]) for better error messages. It's
on the Agenda for later this year [²].
[¹]: https://github.com/dlang/phobos/pull/5461
[²]: https://wiki.dlang.org/Vision/2017H2_draft
Re: Why is phobos so wack?
On Sunday, 9 July 2017 at 14:22:45 UTC, John Colvin wrote: That said, it would be nice if the errors were less daunting somehow. Better template constraint errors are on our Agenda for later this year. https://wiki.dlang.org/Vision/2017H2_draft
Re: proposed @noreturn attribute
On Saturday, 8 July 2017 at 12:17:57 UTC, Andrei Alexandrescu
wrote:
struct None
{
@disable this();
@disable this(this);
@disable @property None init();
}
None ThisFunctionExits();
The compiler detects (without having anything hardwired about
the particular type "None") that the type None is impossible to
create and copy/move from a function, and therefore decrees the
function will never return.
That's a lot more complex (for the compiler and to explain) than
using a simple magic @noreturn attribute.
Agreed that this is rarely needed but sometimes nice to have. Far
from being important though ;).
regressions
DMD, Phobos and Druntime open regressions over time: http://bid.iline.cz/~mk/tmp/regs.png Used to be stable, but seems to be getting worse since 2016.
