Re: Upcoming ACCU 2024 Talk: How DLang Improves my Modern C++ and Vice Versa
My favorite example is glibc implementation of `putenv` function: it first finds the '=' character and takes a temporary slice of the variable name and then employs a tortured null terminated string cope trying to allocate a string with alloca or malloc, then copies the slice there and passes the resulting null terminated string to common `setenv` implementation, then cleanups the allocated string. And there I thought: "ugh, dude, what are you doing, just pass the slice as is".
Re: LDC 1.30.0
On Thursday, 21 July 2022 at 10:18:22 UTC, Christian Köstlin wrote: On a sidenote I am having problem downloading any 2.100.1 dmd version from dlang.org. A great moment, ldc is released before dmd :D
Re: DIP1000: Memory Safety in a Modern System Programming Language Pt.1
On Wednesday, 22 June 2022 at 20:48:13 UTC, Steven Schveighoffer
wrote:
Sometimes algorithms require manipulation of structure, such as
sorting arrays, or using linked lists, and sometimes it's nice
to be able to point at things on the stack, temporarily. This
is one of the things I was looking forward to with dip1000,
since it does allow pointing at the stack when it can work out
the details.
This works:
```
struct S
{
int[] a;
int[] get() return scope @safe { return a; }
void set(return int[] b) return scope @safe
{ a=b; }
}
int[] f() @safe
{
int[2] a;
scope S t;
int[] b=t.get;
t.set=a;
return b; //no
}
```
Re: D Language Foundation Quarterly Meeting, October 2021
On Friday, 5 November 2021 at 11:57:40 UTC, Mike Parker wrote: `-preview=in` will not be killed. It needs to be changed such that: * `in` always means `const scope ref`; the compiler will not attempt to pass by value based on platform-specific heuristics. What about C functions? The ABI changes.
Re: trash-d: Replacement for rm that uses the trash bin
On Tuesday, 24 August 2021 at 02:19:58 UTC, rushsteve1 wrote: https://github.com/rushsteve1/trash-d You marked all functions inline?
Re: D Language Foundation Monthly Meeting Summary
On Wednesday, 2 June 2021 at 14:02:29 UTC, Mike Parker wrote: On Wednesday, 2 June 2021 at 11:10:36 UTC, Dukc wrote: Phobos v2 is an official plan? That was news for me! Any chance to get a glimpse of what's planned for it? The overall goal is that it doesn't replace the current Phobos, but sits alongside it. Changed/improved/new functionality goes in the std.v2 namespace (or whatever it looks like in the end) and you can import that alongside existing std packages. I thought v2 is what it currently is, so the next would be v3.
Re: Dr Callahan ports D compiler to OpenBSD
While we're at it, can I has SOCK_CLOEXEC and SOCK_NONBLOCK flags?
Re: Visual D 1.1.0 released
On Thursday, 4 March 2021 at 13:42:47 UTC, Imperatorn wrote: https://filebin.net/19gupoeedfdjx5tx One GIF is the behaviour in C# I would like to have in D as well with static if, and the other is displaying typeid on hover. The second is a debug session. Visual Studio doesn't show type information in debug session for C# either, only variable name and value.
Re: mir-stat
On Tuesday, 13 October 2020 at 10:30:41 UTC, jmh530 wrote: The difference is that MIT says you can use it without restriction, including a few things, while Boost says you can do some things. I only meant that MIT license was more permissive in that if there are other things you want to do with it that are not listed on Boost (I don't know what that would be), then MIT would allow it. Just make sure you don't grant exclusive rights :)
Re: LDC 1.24.0-beta1
On Monday, 26 October 2020 at 07:14:55 UTC, Patrick Schluter wrote: You underestimate how spoiled windows developer are. Even these simple step are completely out of character for most software on the platform. 20 years ago it wasn't a problem, now on Windows 10 it's a whole other story. How many clicks to get the dialog to set PATH? On NT4 it was 2 clicks, now on Windows 10 I still haven't figured out how to do it without searching like a madman. To make it short. The Windows platform is getting more and more hostile to manual tuning. I use set PATH=%SystemRoot%\system32;%SystemRoot%
Re: LDC 1.24.0-beta1
On Tuesday, 20 October 2020 at 20:09:58 UTC, aberba wrote: Supposing I'm new to D, I have previous experience with LLVM-based compilers so I prefer to use LDC. How am I supposed to know what to do? Where is the information on how to get it on my system through visualD installer? The LDC experience needs some improvement here. Supposedly they will want an IDE with everything included in one installer, like Visual Studio, and that's what VisualD installer apparently does.
Re: LDC 1.23.0-beta1
Just found an old bug. Atomics modify immutable data:
---
import ldc.intrinsics;
void f(immutable int* a)
{
llvm_atomic_rmw_add(a,1);
}
---
Re: Tracing D Applications
On Friday, 13 March 2020 at 19:00:01 UTC, Mike Parker wrote: Blog: https://dlang.org/blog/2020/03/13/tracing-d-applications/ The term "production" there seemingly means "the developer that wrote the program is also an administrator of all production systems" :)
Re: Release D 2.087.0
On Monday, 15 July 2019 at 19:20:27 UTC, Johannes Pfau wrote: I wonder how you can advertise this as a good idea: You have to manually keep declarations in sync, you have to be very careful to get the attributes right, module constructor evaluation order guarantees don't hold, no mangling (no type safety), you pollute the C namespace, no inlining, no templates. This is an established workaround at best, in no way it's a good solution. Was there an agreement that arbitrary amount of code imported in object.d doesn't impact compilation speed or such impact is unimportant?
Re: I was able to write some D last week!
From an earlier post: In particular, nginx can do a scgi proxy with a unix socket and this may be easier to use with your firewall and filesystem permissions. Oh, I tried it. First nginx didn't find the socket. Guess why? Because nginx runs in a virtualized filesystem. Relocated the socket, now nginx says access denied, sure nginx and your server can run under different accounts, permissions should be tweaked accordingly, tweaked them, still access denied, relocated the socket a bit more, still access denied. Guess why? I turned out to be some kind of audit, selinux or something like that, it just fails with generic access denied error. Ok, FHS recommends /var/run, but it's rwxr-xr-x root root. Wut? Run a network server as root? Tried tcp, it just works.
Re: Priority DIP for Draft Review: Argument Ownership and Function Calls
On Friday, 28 June 2019 at 07:22:56 UTC, Olivier FAURE wrote: I'm particularly interested in flow analysis features, and I think I have something to contribute, but I don't want to spend a large amount of effort debating and suggesting alternatives if I expect to be stonewalled. It seems general fear of flow analysis is that people will ask it to be perfect and it would be difficult to stop it from growing in complexity.
Re: Phobos is now compiled with -preview=dip1000
On Thursday, 16 May 2019 at 05:22:42 UTC, Seb wrote: Yes that sounds like the culprit. Btw as mentioned on DConf, the dip1000 switch contains a few other breaking changes which will make it even harder to adopt too. Well, it's an inherent property of DIP1000 to not compile code that previously compiled. Though safety of tupleof shouldn't depend on DIP1000.
Re: Phobos is now compiled with -preview=dip1000
On Wednesday, 15 May 2019 at 07:56:48 UTC, Walter Bright wrote: Maybe the clock is not synchronized somewhere. It's off by one hour.
Re: bool (was DConf 2019 AGM Livestream)
On Sunday, 12 May 2019 at 06:27:21 UTC, Nick Sabalausky (Abscissa) wrote: All this effort strongly implies that there's no such thing as a satisfactory bool type *in languages which conflate booleans with integers* FWIW I write C# for food and to me D bool is better than C# bool. Didn't watch, but if it's about the DIP I think of, its rationale was overload rules, Walter said he's not opposed to tune them. It was derailed into discussion about strong bool?
Re: DIP 1018--The Copy Constructor--Formal Review
On Tuesday, 26 February 2019 at 05:38:01 UTC, Manu wrote: I'm talking about this DIP. Allowing a mutable copy argument feels super weird. The problem was out of place mutation, which can't happen with copy constructor, because initialization from rvalue is a move, so the copy constructor won't be called.
Re: GtkD Blog Now Up and Running
On Friday, 1 February 2019 at 07:43:23 UTC, Petar Kirov [ZombineDev] wrote: So, assuming you have the MSVC C++ toolchain installed, just build with dub by specifying either the --arch=x86_mscoff or --arch=x86_64 flags. But no one should ever need to modify their dmd installation, in order to use gtkd. I don't think you still need ms toolchain installed: dmd comes with lld linker and mingw libs.
Re: DIP 1016 should use expression lowering, not statement lowering
On Tuesday, 29 January 2019 at 11:52:40 UTC, Andrei Alexandrescu wrote: Where should the temporary go? Doesn't D already specify allocation and lifetime of temporaries? AIU the DIP doesn't invent the notion of a temporary.
Re: GtkD Blog Now Up and Running
On Friday, 25 January 2019 at 21:16:59 UTC, Ron Tarrant wrote: My approach is to lay out a firm foundation for both imperative and object-oriented paradigms, then build from there, taking things one step at a time. By OOP you mean user controls? Hmm... I'd say, user control is an advanced topic. In most cases each form is written in isolation with little code sharing, and classes provided by gtkd as is (that imperative way) should work fine. If you notice a recurring pattern and want to reuse it among different forms, a user control can be used to abstract it, but it also has a higher design quality requirement, because now it's going to be reused and thus needs to work in different mostly unforeseen contexts. Just writing a one-off user control is an overkill.
Re: Blog post: What D got wrong
On Monday, 17 December 2018 at 11:04:13 UTC, Atila Neves wrote: Why @safe? Can't you just write "@safe:" on top and switch to @system/@trusted as needed? Not quite. It doesn't work the way most people expect for member functions and causes problems for templates. Don't templates infer attributes? @safe didn't work well for trusted aggregates (including inference), not sure if dip1000 fixes that.
Re: Blog post: What D got wrong
On Tuesday, 18 December 2018 at 10:19:14 UTC, Russel Winder wrote: Clojure is but you have to work hard for that, the initial language is effectively pure. https://ideone.com/y8KWja clearly it isn't, its site only claims that most code happens to be pure, but it looks like it's not checked in any way and not sure if purity can be even checked there.
Re: Blog post: What D got wrong
On Tuesday, 18 December 2018 at 08:17:28 UTC, Russel Winder wrote: Rust I feel has a pivotal role in all this. By emphasising the ML view on mixed declarative and imperative programming, it has found an interesting middle ground that seems to work very well. Many of the C programmers who though C++ overcomplicated and not worth looking at, are taking to Rust and in doing so leaving C behind. AIU rust, clojure and prolog are impure.
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 12:57:03 UTC, Atila Neves wrote: @property is useful for setters. Now, IMHO setters are a code stink anyway but sometimes they're the way to go. I have no idea what it's supposed to do for getters (nor am I interested in learning or retaining that information) and never slap the attribute on. Imagine you have void delegate() prop() and use the property without parentheses everywhere then suddenly m.prop() doesn't call the delegate. So it's mostly for getters and should be used only in edge cases, most code should be fine with optional parens. inout Template this can accomplish the same thing and is more useful anyway. "Everything is a template" is a spiritual successor to "everything is an object" hype :) Returning a reference It’s practically pointless. See https://github.com/dlang/druntime/blob/master/src/core/stdc/errno.d#L66 Also AFAIK alias this doesn't dereference pointers automatically, and retaining the pointer may be not desirable. I think there’s a general consensus that @safe, pure and immutable should be default. I can agree there are at least 5 people holding that firm belief, but that's hardly a consensus. I’ve lost count now of how many times I’ve had to write @safe @nogc pure nothrow const scope return. Really. If immutable was default, wouldn't you still need to write const attribute everywhere, and @nogc, and nothrow? Strings are like the only relevant immutable data structure (and they are already immutable), everything else is inherently mutable except for use cases with genuine need for immutability like a shared cache of objects.
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
That's strange, I thought polysemous literals prefer default type, not tightest type. --- auto b=1; static assert(is(typeof(b)==bool)); --- Error: static assert: is(int == bool) is false
Re: LDC 1.13.0-beta1
On Saturday, 3 November 2018 at 16:33:36 UTC, kinke wrote: I figured it'd be for a lot of Windows users. Why not explicitly express your gratitude with a little 'thank you' then? After all, that little bullet point in the release notes easily took some 40 hours of my spare time, and some appreciation can work wonders to keep motivation up. Can send you some cryptocurrency if you want.
Re: New Initiative for Donations
On Friday, 26 October 2018 at 02:38:08 UTC, Joakim wrote: In the US maybe Well yeah, online commerce is USA-centric because anything else doesn't generate revenue.
Re: Beta 2.082.0
On Saturday, 18 August 2018 at 16:51:18 UTC, Martin Nowak wrote: Beta is 2 weeks sounds fine then. So please download and install the beta, sth. you should always do ;). The download should probably happen through Edge too: it runs SmartScreen on the downloaded file. OT: more news: https://medium.com/@airflow.matt/globalsign-will-revoke-your-codesign-certificate-no-questions-asked-f6ac2bca02c5
Re: Beta 2.082.0
On Saturday, 18 August 2018 at 16:51:18 UTC, Martin Nowak wrote: I understand that common Windows users have a very different thread model than linux developers, hence the crappy Anti-Virus rootkits. I'd expect the Windows dev audience we're targeting with D to be a bit more capable than common Windows users though. Since introduction of UAC in Vista viruses became a non-issue and the theme lost buzz, that can foster ignorance.
Re: I have a plan.. I really DO
On Friday, 13 July 2018 at 19:30:07 UTC, RhyS wrote: If there is a language out there that gaps that C/Java/dynamic fast and easy feel, and offers the ability to compile down with ease. I have not seen it. There's no silver bullet, you can choose from what exists or create your own. Recently we got a CI service that tests some packages from dub, that should deal with regressions.
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 15:19:33 UTC, Ecstatic Coder wrote: Actually you answer was right even if the point count was not stored as an integer ;) For C++, the answer is : never. Two small memory blocks will have to be allocated from the memory pool, which is not smart, obviously, but apart of that, nothing to worry about. Because there is no garbage collector in C++, memory has to be allocated and deallocated in a continuous manner... Recently it got somewhat pushed by Electron applications :)
Re: DasBetterC: Converting make.c to D
What I had with actually modern C: 1) narrowing conversions 2) not only arrays decay to pointers, C happily allows the opposite too, eww 3) looks like C code loves to have function arguments named `in` and `out` Also difficulties with transpiling to C don't look that big: errno is the first glaring example TLS usage in C, glibc even tunes TLS model for it; AFAIK, C++ stores current exception in some sort of static storage and provides a function to retrieve it from there, a similar approach can be used for C target, though betterc shouldn't use exceptions.
Re: GitHub could be acquired by Microsoft
On Sunday, 10 June 2018 at 00:29:04 UTC, bauss wrote: And then Microsoft acquires both and everyone moves to Bitbucket. Endless cycle :) Until people figure out decentralization. AIU scuttlebutt server provides only discovery service, these proved to be able to run at little cost. And as tox shows, even discovery can be decentralized too.
Re: GitHub could be acquired by Microsoft
On Saturday, 9 June 2018 at 07:06:23 UTC, Nick Sabalausky (Abscissa) wrote: Whether web API or web scraping: Either way, you still have to submit an HTTP request, parse the results according to the format the server has chosen to spit out, and possibly follow up with additional HTTP requests. https://docs.gitlab.com/ee/user/project/import/github.html done?
Re: GitHub could be acquired by Microsoft
On Monday, 4 June 2018 at 20:00:45 UTC, Maksim Fomin wrote: Just as rough estimate: to support $7.5 bl valuation Microsoft must turn -$30 ml. net loss company into business generating around $750 ml. for many years. There is no way to get these money from the market. Alternatively, the project can have payoff if something is broken and Microsoft cash flows increase by $750 ml. This is more likely... MS aims for cloud market, and github is a strategic asset there, as long as it helps the cloud business, it doesn't matter that github in isolation is not profitable. After MS takes over webdev and monopolizes the cloud market they can pull effective management again, but it will be a long way to go, but webdev being webdev can make it a little shorter. They were already kicked out of mobile market, it was reasonably unexpected, but it doesn't look like they plan to fall for it again.
Re: GitHub could be acquired by Microsoft
On Monday, 4 June 2018 at 05:50:26 UTC, Anton Fediushin wrote: I can think of hundreds of things what can go wrong including: forcing users to use Microsoft accounts That didn't happen to skype yet. MS recently tries to mend its reputation, though the past will linger for a while.
Re: iopipe v0.0.4 - RingBuffers!
On Thursday, 10 May 2018 at 23:22:02 UTC, Steven Schveighoffer wrote: However, I am struggling to find a use case for this that showcases why you would want to use it. While it does work, and works beautifully, it doesn't show any measurable difference vs. the array allocated buffer that copies data when it needs to extend. Depends on OS and hardware. I would expect mmap implementation to be slower as it reads file in chunks of 4kb and relies on page faults.
Re: dxml 0.3.0 released
On Friday, 20 April 2018 at 08:45:45 UTC, Dejan Lekic wrote: Jonathan, are the interfaces in the dom module generated from the IDL code from W3C? It's not W3C DOM :)
Re: DIP 1009 (Add Expression-Based Contract Syntax) Accepted
On Wednesday, 11 April 2018 at 20:45:15 UTC, Dmitry Olshansky wrote: * Templates kind of muddy the waters being conpiled with the flags of caller (another reason why they are a mess). Meaning they will work with contracts if caller choses to have debug build. Template can call user code, but it wasn't tested for it, so the contract should be checked.
Re: #include C headers in D code
On Wednesday, 11 April 2018 at 09:45:07 UTC, Jonathan M Davis wrote: It's one thing for someone who is familiar with D to weigh the options and decide that being tied to ldc is okay. It's quite another to tell someone who isn't familiar with D that in order to use D, they have to use a feature which only works with a specific compiler that is not the reference compiler and which will likely never work with the reference compiler. I'd say, you can focus on negative aspects if the auditory will analyze them, but it's a bad strategy if you only want to overcome prejudice.
Re: #include C headers in D code
On Wednesday, 11 April 2018 at 12:22:56 UTC, bachmeier wrote: It also wouldn't work with GDC. Given that GDC has been added to GCC, it would be a bad idea to tell people they need to use LDC to work with C code. Currently porting a project to linux, stuff is so severely outdated, pretty much no dependency was satisfied by the distro, in wich case for D it would be better to install ldc just to not touch gdc :) Granted, it's only a problem for active projects, but what projects are inactive?
Re: #include C headers in D code
On Monday, 9 April 2018 at 19:36:23 UTC, Atila Neves wrote: If you add to all that "No, really, it's ok, there's this project that forked one of the compilers. No, it's not the reference compiler. There's just this bit of non-standard syntax to learn that's neither C nor D", then the chances of convincing any "normal" engineer are 0. It is the reference compiler though (which is the frontend), the backend is different, but they don't want the dmc backend do they? Also recently it started to use pragma and import syntax, which are both D.
Re: Beta 2.079.0
On Saturday, 31 March 2018 at 00:25:47 UTC, Seb wrote:
AFAICT Rust now has introduced the exactly same feature. It's
quite interesting to see that there was no outcry by the
community and it was universally liked:
https://blog.rust-lang.org/2018/03/29/Rust-1.25.html
https://github.com/rust-lang/rust/issues/44494
use std::sync::{Arc, atomic::{AtomicBool, Ordering}};
Well, sifting through such imports is tame compared to what they
have to do, so they will barely notice it :) rust is
tinkering-oriented after all.
Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome
Did they figure out how to pass data between threads?
Re: Vision document for H1 2018
On Friday, 16 March 2018 at 21:38:30 UTC, rumbu wrote: Do you know anything else in the .net library than LINQ where extension methods (somehow equivalent to UFCS) are abused? I thought that something happened in the .net world while I was asleep, that's why I just searched my local copy of .net core and there are exactly 198 extension methods. I would not call these "big". It's big because linq is perceptionally big in itself similar to how std.algorithm is big. It's also design pattern in C#: if you want a complex interface method with simplified overloads, you don't declare interface with many overloads, you declare one interface method that takes all parameters and a number of simplified extension methods that forward to interface, Unity container and Rhino mocks are designed this way. Last time I checked, .net Console was an enormous static class with three Stream objects behind the scenes. That's also how D console IO works. When I said that phobos looks like a mess compared to .net lib I referred especially to the poor choice of names (eg. RedBlackTree vs SortedDictionary) and lack of essential stuff (eg. happy to have levenshteinDistance built in, but I cannot sort correctly two strings in any other language than English). That's true, naming is a little complex.
Re: Vision document for H1 2018
On Friday, 16 March 2018 at 18:35:14 UTC, Tony wrote: I thought C# was like Java and does not allow free procedures. Can you give an example of C# procedural-style IO? All methods of Console class.
Re: Vision document for H1 2018
On Thursday, 15 March 2018 at 16:03:14 UTC, rumbu wrote: Are you sure that you are talking about phobos and not tango? :) I'm eager to find how I'm uninformed. Tango doesn't use UFCS, while phobos and .net framework are big on extension methods. Also tango uses object oriented console IO, while phobos and .net framework use procedural style for it.
Re: Vision document for H1 2018
On Monday, 12 March 2018 at 03:31:36 UTC, Laeeth Isharc wrote: C# slices look great. Dunno, when I wanted a slice in C#, I wrote a prettier one. C# could get stuff done 20 years ago already, ugly slices and native compilation won't add anything to it. If Phobos looks like a mess to C# programmers, so much the worse for C# programmers. No, FWIW phobos uses more or less the same programming solutions as .net framework, the claim that they are different is an uninformed opinion.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 04:06:13 UTC, Nick Sabalausky (Abscissa) wrote: First of all, betterC is about far more than interfacing with C. In fact, interop with C isn't really what betterC is about at all - that's a separate aspect of the language. (And those C/C++ users who still haven't come to D - for many of them the holdout is *because* of the issues betterC aims to address. What is that issue? Runtime? It can be solved with minimal runtime that one can write in an evening, compare it to betterC effort that has no end in sight. Make no mistake, for all the stockholm syndrome in the C and C++ worlds, there *are* a lot people openly wanting to jump ship but don't have a sufficient option yet. I'm afraid a sufficient option for them is proper C++ superset, betterC is only the first excuse, but not last. Personally, better DLL support have little to no impact on me. Obviously it does for you, and I sympathise. FWIW DLL support was always good enough for me.
Re: State of D 2018 Survey
On Monday, 5 March 2018 at 20:52:10 UTC, Russel Winder wrote: I do not see your reasoning here. Has the core D computational model changed? I think not. Major number per semver increases when interface changes, D does it pretty often, it is the fastest moving language I know. Does D issue bugfix releases? Those are point releases. 2.79.0 seems like a perfectly reasonable semantic version number for D. It's a reasonable version number, but doesn't follow semantics of semver. You can't blindly assume that different versioning schemes advertize the same things.
Re: State of D 2018 Survey
On Sunday, 4 March 2018 at 17:26:50 UTC, bauss wrote: It's also very strict and probably have of the posts within Learn here wouldn't be allowed there. It's the most hilarious aspect. Apparently questions about design don't belong there. As if the moderators don't even know about the concept.
Re: State of D 2018 Survey
On Friday, 2 March 2018 at 12:01:33 UTC, Russel Winder wrote: So having D2.999 is fine per se, but advertises a lack of change and a lack of ambition since the language name is D not D2. D just doesn't follow semver. If it did, we would have D79 now, nothing else even comes close to this. And I suspect it won't adopt semver because major number would be so ridiculously high and will advertize something else. Fortran, C++, and Java show an obsessive adherence to backward compatibility and yet they increase their major numbers to give the appearance at least of forward progress. C++ and Fortran don't have version numbers, those are brand numbers.
Re: State of D 2018 Survey
But seriously, Stack overflow is a reputation-based system, it very hostile from the very start, when you don't have enough reputation for pretty much everything, and SO vehemently nags you about this on every possible occasion, even baiting you to use functionality only to later tell that you don't have enough reputation to use it. How can anyone like it is beyond me.
Re: Beta 2.079.0
auto result = foo(), bar();
Doesn't look like it works.
---
int f(int a){ return a; }
int main()
{
int a=f(0),f(1); //doesn't compile
return 0;
}
---
int f(int a){ return a; }
int main()
{
int a;
a=f(0),f(1);
assert(a==1); //fails
return 0;
}
---
https://run.dlang.io/is/IgArs0
Re: Beta 2.079.0
https://github.com/dlang/druntime/pull/1282 github shows me just two changes in makefiles and nothing else, need to find where the code comes from.
Re: Beta 2.079.0
On Friday, 23 February 2018 at 01:02:59 UTC, Martin Nowak wrote: Also https://en.wikipedia.org/wiki/Law_of_triviality, because this is certainly easier to grasp than https://github.com/dlang/druntime/pull/1282 (https://forum.dlang.org/post/mjsma6$196h$1...@digitalmars.com) If nobody opposes, commit it to experimental. What an AA can have beside getter and setter?
Re: Beta 2.079.0
On Friday, 23 February 2018 at 00:05:59 UTC, Martin Nowak wrote: The main use-case for craming multiple imports into a line is not libraries but scripting, examples, and maybe unit tests. Those are cases when selective imports shouldn't be used. experimental.scripting was introduced to reduce import length to absolute minimum - 11 characters. That's your opinion, my opinion is that importing 6 symbols from 6 different modules for a tiny cli tool sucks and bloats code example. So the alternative is to not use selective imports, but only those and static imports have a clear path to become lazy (https://issues.dlang.org/show_bug.cgi?id=13255). Are renamed imports already lazy? Tiny cli tool uses all its imports and doesn't benefit from laziness, only libraries do. - use std.experimental.scripting Indeed an alternative with a similar goal, reducing the amount of typing/noise for hacking. Importing all phobos modules will lead to a couple of symbol conflicts (e.g. write), It's perfectly thinkable to use both `write` functions, and selective imports won't help you there, but renamed imports will. Is it just me or people ignore existence of renamed imports? #RenamedImportsMatter and it still increases compile times and binary sizes noteably (though compile time is a lot better than it used to be). Is it because of dead templates? As a temporary solution you can compile the code to a library, this way the linker will be able to skip unreferenced code. - why hasn't this been a DIP Because it looked primarily like a minor grammar rectification that doesn't break anything and is entirely optional. Also DIPs are a crucial process for our language, and it seems problematic to clog it with trivialities. Though the feature met skepticism from the start. Maybe voting can be used as a simplified DIP process, just needs more people. - it's useful for talks, posts, code puzzles or on a repl where code is size constrained Non-selective always win in terms of size. - we're currently proliferating selective imports which cause a lot of D code to become very brittle (https://github.com/andralex/phobos/blob/cd3152c7bf4466e74b7fb9bd43d47e996caf5918/std/datetime/systime.d#L10076-L10083) I'd convert those to non-selective imports. import std.algorithm.iteration, std.ascii, std.exception, std.format, std.meta, std.range, std.stdio, std.string; (well, my editor has decent word wrapping)
Re: Beta 2.079.0
auto result = foo(), bar(); Does this compile? In variable declaration statement comma already has meaning as separator of declarators. Does it apply to enums too? This is difficult to parse.
Re: Beta 2.079.0
On Tuesday, 20 February 2018 at 22:54:43 UTC, H. S. Teoh wrote: Yeah, personally I'd avoid writing it that way too. There's no other way to use this feature though.
Re: Beta 2.079.0
On Tuesday, 20 February 2018 at 08:43:50 UTC, Martin Nowak wrote: If you prefer java-like 50 lines import manifests, then by all means keep using those. Imports can be written on one line. import std.stdio; import std.range; It only needs one more word.
Re: Beta 2.079.0
On Monday, 19 February 2018 at 18:50:47 UTC, Dukc wrote: Huh? Did I understand right? Just add an empty object.d into your project and --BetterC is now basically needless, plus the executable is most likely even smaller? And more functions to std.range, my favorite module, yes! FWIW I used ldc with minimal runtime since 2013 or so, 2.079 is if you want to use dmd and classes.
Re: dxml 0.2.0 released
On Tuesday, 13 February 2018 at 22:29:27 UTC, H. S. Teoh wrote: - provide some way of hooking into non-default entities so that DTD-defined entities can be expanded by the DTD implementation. The parser now returns raw text, entity replacement can be done by DTD processor without any modification of API. So it's good for experimental if there's incentive to maintain it, but it's purely PR problem: there's nothing wrong in having xml support in dub registry and std.xml in phobos, if phobos is ok with it, it can stay as is. It looks like EntityRange requires forward range, is it ok for a parser?
Re: dxml 0.2.0 released
On Tuesday, 13 February 2018 at 02:53:21 UTC, Nick Sabalausky (Abscissa) wrote: On 02/12/2018 11:15 AM, rikki cattermole wrote: dxml 7.5k LOC std.xml 3k LOC dxml would make the situation a lot worse. 4.5k LOC == "a lot worse"? Uuuuhhh...WAT? And it's like 2k LOC of code and 5.5k LOC of tests and docs.
Re: dxml 0.2.0 released
On Monday, 12 February 2018 at 16:50:16 UTC, Jonathan M Davis wrote: The core problem is that entity references get replaced with more XML that needs to be parsed. So, they can't simply be passed on for post-processing. As I understand it, they have to be replaced while the parsing is going on. And that means that you can't do something like return slices of the original input that don't bother with the entity references and then have a separate parser take that and process it further to deal with the entity references. The first parser has to deal with them, and that means not returning slices of the original input unless you're dealing purely with strings and are willing to allocate new strings in the cases where the data needs to be mutated because of an entity reference. Standard entities like have the same problem, so the same solution should work too.
Re: LDC 1.7.0
On Tuesday, 30 January 2018 at 19:57:39 UTC, aberba wrote: now it seem abandoned after such an effort. Can you confirm it for Ubuntu 17?
Re: LDC 1.7.0-beta1
On Sunday, 10 December 2017 at 18:11:46 UTC, Suliman wrote: Is it's possible to produce x64 binaries on Windows x64 without installing Visual Studio? DMD do not have linker for x64. Beside linker you will need C startup code. Where do you plan to get it?
Re: ASDF v0.1.5-beta0: new parser is ~40% faster
On Sunday, 1 October 2017 at 14:38:04 UTC, Ilya Yaroshenko wrote: [1] https://github.com/tamediadigital/asdf/tree/master/benchmarks/sajson AFAIK, ldc translates dmd's -O option to llvm's -O3.
Re: D as a Better C
On Monday, 28 August 2017 at 22:45:01 UTC, Parke wrote: When I write "hello world" in C, the executable is 8,519 bytes. When I write "hello world" in D, the executable is 100 times larger: 865,179 bytes. Interestingly, "hello world" in C, compiled statically, yields 908,608 bytes. And "hello world" in assembly yields 368 bytes. https://forum.dlang.org/post/tmofjecvnqdthvete...@forum.dlang.org - an example for elf target.
Re: D as a Better C
On Wednesday, 30 August 2017 at 02:19:21 UTC, Michael V. Franklin wrote: As you can see it is not a polished experience and gets much worse when you start employing more features of D. This could be improved, and in fact, with GDC you need even less useless boilerplate in object.d and may end up with an even smaller executable. (Maybe I'll follow up later with GDC illustration. Right now I don't have a computer with the latest GDC installed). If you try this experiment with LDC, you may end up with a multi-gigabyte file and crash your PC due to https://github.com/ldc-developers/ldc/issues/781 I use stock object.d, just don't link it.
Re: D as a Better C
On Wednesday, 30 August 2017 at 00:29:19 UTC, Parke wrote: But my original question was about what you (Kagamin) called "intermediate D". I was trying to understand what "intermediate D" is, and whether or not I could use "intermediate D" (whatever it is) to produce small(er) executables. I rely on llvm tooling to remove unused stuff, build process is a bit lengthy, I didn't write a step by step guide for it. Also linux might need different approach depending what code compiler generates.
Re: D as a Better C
On Monday, 28 August 2017 at 22:45:01 UTC, Parke wrote: When I write "hello world" in C, the executable is 8,519 bytes. When I write "hello world" in D, the executable is 100 times larger: 865,179 bytes. You mean the examples from the blog post https://dlang.org/blog/2017/08/23/d-as-a-better-c/ give you 800kb executables?
Re: D as a Better C
On Friday, 25 August 2017 at 18:08:06 UTC, Parke wrote: Is there any documentation on how to access and use the minimal runtime? Runtime implements language features like boundschecking, it's not used explicitly in the code.
Re: D as a Better C
On Thursday, 24 August 2017 at 19:09:58 UTC, Parke wrote: What is "intermediate D"? D with minimal runtime.
Re: D as a Better C
On Wednesday, 23 August 2017 at 17:43:27 UTC, Steven Schveighoffer wrote: I thought "closure" means allocating the stack onto the heap so you can return the delegate with its context intact. I understood closure as capture of variables from external context. They are divided into upward closures and downward closures, the former needs heap allocation.
Re: D as a Better C
On Wednesday, 23 August 2017 at 22:45:27 UTC, sarn wrote: I haven't tried the latest iteration of betterC yet, but the longstanding problem is that the compiler generates TypeInfo instances for structs LDC doesn't generate TypeInfo for structs until it's required for some features like array comparison.
Re: D as a Better C
On Wednesday, 23 August 2017 at 14:00:34 UTC, Walter Bright wrote: One of the reasons people use C is to get that small footprint. This has been a large barrier to C programs making use of D. Not a better C, but intermediate D has small footprint for me too. 7.5kb totext.exe (encodes stdin to base64 and writes to stdout) - wrote it to put images in xml for opensearch descriptions. 12.5kb retab.exe (retabifies source code with various features) 5.5kb keepower.exe (manages screen saver and power settings because of obnoxious domain policy) 14.5kb fsum.exe (computes various hash sums of a file) Additional features: string switch, array cast. Also how assert failure works in C? Mine shows a nice formatted message.
Re: Hiring D programmers (with cryptography and blockchain knowledge are preferred)
On Wednesday, 12 July 2017 at 14:27:41 UTC, István wrote: These are still centralized services which any time might decide to change to censorship or forced to shut down, then you lose access to your content the same way. I saw 4 such cases and it was always easier to setup a replica. And those replacements are already made with replication in mind.
Re: Hiring D programmers (with cryptography and blockchain knowledge are preferred)
On Wednesday, 12 July 2017 at 11:11:20 UTC, Steven Schveighoffer wrote: Have you heard of https://gab.ai ? They are doing something similar (in terms of providing an uncensored platform). Another one is dreamwidth.org, it started as a reaction to tighter control too and has a permissive content policy.
Re: Hiring D programmers (with cryptography and blockchain knowledge are preferred)
On Wednesday, 12 July 2017 at 04:40:16 UTC, Vitor Rozsas wrote: The server should be somewhat easy, afterall... it should receive posts that are signed by the user, and store the post (with signature) if the signature corresponds to post's message and public key of the user. From what I know about bitcoin, block computation is somewhat expensive there. How do you plan to reward the miners?
Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator
On Wednesday, 12 April 2017 at 13:32:36 UTC, Stanislav Blinov
wrote:
Syntax is not the core of the issue, it's not about just
marking a destructor as shared. Making RefCounted itself shared
would require implementing some form of synchronization of all
the 'dereference' operations, including assignments. I.e. if we
have some shared(RefCounted!T) ptr, what should happen when two
threads simultaneously attempt to do ptr =
shared(RefCounted!T)(someNewValue) ? Should a library
implementation even consider this? Or should such
synchronization be left to client's care? It seems like in this
regard shared(RefCounted!T) would be no different from
shared(T*), which brings me to the next point.
If we can control memory layout, we can do what shared_ptr does
and couple the reference counter with the object, then we can
have just one pointer:
struct RefCounted(T)
{
struct Wrapper
{
int count;
T payload;
}
Wrapper* payload;
}
Re: Amper audio player for GNU/Linux and X11
dmd -m64 -c amper.d should work on 32-bit system too and compile to 64-bit code.
Re: Snowflake Strings
In case strings hash to the same value, the linkers (ld and ms) have an option to detect discrepancy in content.
Re: tanya library 0.2.0
On Sunday, 19 February 2017 at 11:41:44 UTC, Eugene Wissner wrote: realloc() can move memory and if an object of type A has references to other objects in the array, the objects will be corrupted. "A" should be a POD-type. Otherwise you have to allocate new memory, initialize it, copy the objects by one and deallocate the old memory. Now there is IAllocator.expand(). What's the difference between realloc+postblit and copy one by one? Postblit is called only after copy, it's not a constructor.
Re: vibe.d 0.8.0 and 0.7.31 beta releases
On Wednesday, 8 February 2017 at 15:18:34 UTC, Sönke Ludwig wrote:
The problem is that there are two affected call stacks - the
@system API function that registers the @system callback,
wrapping/casting it as @trusted, and the event handler that
later on actually calls the callback. The latter place is where
the hidden violation of the @safe guarantees happens.
Hidden from whom? Since it's user, who supplies @system code to
vibe, he knows that the resulting program doesn't provide @safe
guarantees.
It can be communicated at the API level:
int f(@safe void delegate() dg) @safe
{ code }
int f(@system void delegate() dg) @system
{ return f(cast(@safe void delegate())dg); }
So that unsafe overload would be only callable from unsafe code.
Re: vibe.d 0.8.0 and 0.7.31 beta releases
On Friday, 3 February 2017 at 13:21:18 UTC, Sönke Ludwig wrote: Keeping the system overloads would break the safety guarantees at a relatively deep level and would render the whole effort rather useless (this is the case for non-scope callbacks only, so if you stumble over a deprecated function with a scope callback, then it should be fixed). That's kind of intended: the system would inherit safety of the code it calls. If the user code is not safe, there's no safety guarantee. First, it actually has helped to detect some rather subtle issues in the past that have gone unnoticed for a long time otherwise. Being @safe-compatible and provide @safe guarantees are different issues. The latter follows from the former if user code is @safe and doesn't follow otherwise. And, maybe more importantly, annotating code as safe is the only way to guarantee proper bounds checks, which is critical for a server component. -boundscheck=on should do it, ldc provides even more control how code is compiled. And finally, I feel that if nobody starts to embrace this on a broader level now, it will never reach a truly mature state. Fake @trusted annotations don't count as adoption of safety. Pedantically speaking @safe loses its purpose if @trusted code is not verified. Especially if fake @trusted becomes a habit. That's why safety can't be forced and is opt-in.
Re: Release D 2.073.0
On Friday, 27 January 2017 at 11:12:22 UTC, Dicebot wrote: And also stuff like https://github.com/dlang/druntime/pull/1740 Why it would break code if `in` meant `scope`?
Re: DIP 1003: remove `body` as a keyword
As to contracts without body we have https://issues.dlang.org/show_bug.cgi?id=4720
Re: DIP 1003: remove `body` as a keyword
On Wednesday, 23 November 2016 at 20:24:13 UTC, Timon Gehr wrote: Technically, there is an ambiguity (technically, ambiguity means that there are multiple grammar derivations resulting in the same sentence). Pragmatically, the greedy parse-the-body-if-possible-approach will work. I see no ambiguity even if parsing is not greedy.
Re: DIP 1003: remove `body` as a keyword
Must be T!( lots and lots of stuff ) f( lots and lots of stuff )( lots and lots of stuff ) if ( lots and lots of stuff )
Re: DIP 1003: remove `body` as a keyword
int div(int a, int b)
in { assert(b != 0); }
do
{
return a / b;
}
Re: DIP 1003: remove `body` as a keyword
On Tuesday, 22 November 2016 at 22:37:03 UTC, Timon Gehr wrote:
The more important point is that there is no precedent where
{...}{...} are two components of the same entity, it looks ugly
even with the space-wasting convention where '{' is put on its
own line. Not all contracts are one-liners like in your example
above (which looks almost tolerable).
Templated functions have
T!( lots and lots of stuff ) f!( lots and lots of
stuff )( lots and lots of stuff ) if ( lots
and lots of stuff )
And yes, it's ugly.
Re: Formal review of DIP1002
On Thursday, 17 November 2016 at 11:37:09 UTC, Dicebot wrote: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1002.md#review We do exception tests like this: http://dpaste.com/0EAZQE4
Re: Dynamic Bindings to libui (x-platform GUI)
On Wednesday, 25 May 2016 at 16:47:30 UTC, Nick Sabalausky wrote: Drives me nuts when people count "Always uses GTK on Linux" as "Native UI". It's like those programs that do everything completely Ubuntu-centric whenever possible and then advertise "Linux Support". I *really* wish GTK would just die already. https://github.com/andlabs/libui/pull/80
Re: Release D 2.072.0
On Thursday, 10 November 2016 at 13:58:56 UTC, Steven Schveighoffer wrote: Only possibility is just to ignore ALL cycles, and print them if any are detected. Run the new detector and if it fails, run the old one, if it succeeds, print a message.
Re: Battle-plan for CTFE
On Wednesday, 26 October 2016 at 15:02:28 UTC, Stefam Koch wrote: bLength = cast(uint)a.length; Reads past the end of b if b is shorter than a.
Re: On the future of DIP1000
On Monday, 22 August 2016 at 06:44:11 UTC, Jacob Carlborg wrote: It would be nice to have the whole picture now, before implementing DIP1000. It can be reviewed after the spec is inferred from implementation. But yes, it can be unclear how the implementation can affect the review process. Do you have an alternative design for scope?
Re: Battle-plan for CTFE
1. You said CTFE engine can be ctfeable itself? But it uses unions in BCValue - it's not going to work in CTFE, is it? Just wondering myself what's the way to have polymorphism at compile time. 2. The byte code generator interface has no mean to declare functions? In case of LLVM jit one would want to declare functions so that jit can use registers to pass parameters for a bit more extra speed, though it's probably not worth it.
