Re: Anybody know about SDL and particularly SDL_TTF initialization?
On Sunday, 12 May 2024 at 20:13:04 UTC, WhatMeWorry` wrote: INFO: SDL loaded v2.30.2 INFO: SDL initialized: 0 INFO: TTF loaded: v2.0.14 Error Program exited with code -1073741819 Something hit a null pointer, time to fire up the debugger :)
Re: allocated object address as high as 46th bit (i.e in the 131072 GB range)
The reason high bits are often set is because an address layout is actually 4 indicies into the page table and a page byte offset. So all the way to bit 48 there is index info the cpu uses.
Re: Trying to cross compile from windows to android
On Friday, 21 January 2022 at 09:52:10 UTC, Jerry wrote: On Thursday, 20 January 2022 at 19:31:06 UTC, H. S. Teoh wrote: T Found ld linker as you described. Slapped on the --linker=ld flag and now everything is working. Thanks! :D Or atleast that's what I thought, it links, but won't run, apparently bfd linker is required. So I installed that one.
Re: Trying to cross compile from windows to android
On Thursday, 20 January 2022 at 19:31:06 UTC, H. S. Teoh wrote: T Found ld linker as you described. Slapped on the --linker=ld flag and now everything is working. Thanks! :D
Re: Trying to cross compile from windows to android
On Thursday, 20 January 2022 at 19:31:06 UTC, H. S. Teoh wrote: On Thu, Jan 20, 2022 at 07:10:40PM +, Jerry via Digitalmars-d-learn wrote: You're trying to use bfd as your linker, and I think that only exists on the Linux version of the NDK. Maybe try looking somewhere under ldc_android/android_ndk/toolchains/x86_64-*/prebuilt/windows-x86_64/bin to see what linkers are shipped with your NDK, and specify that instead? On Linux, I see a bunch of binaries named x86_64-linux-android-*, including *-ld, *-ld.bfd, *-ld.gold, which are the 3 linkers that can be used via -fuse-ld=bfd, -fuse-ld=gold, etc.. I'm not sure how it works on Windows, but there should be corresponding binaries that might give a hint as to what's the correct -fuse-ld=... option you need to use. T Thank you mate, got it working now. With the ld linker.
Trying to cross compile from windows to android
Hello, followed the guide at https://wiki.dlang.org/Build_D_for_Android but got stuck on figuring out what linker to use. "../ldc_android/ldc/bin/ldc2.exe" -mtriple=armv7a--linux-andro ideabi main.d clang: error: invalid linker name in argument '-fuse-ld=bfd' Error: ldc_android/android_ndk/toolchains/llvm/prebuilt/windows-x86_64/bin /aarch64-linux-android21-clang.cmd failed with status: 1 Do I need to install a GNU linker with cross compile compatabilities or is my system not configured properly?
Re: How to call stop from parallel foreach
On Thursday, 24 June 2021 at 18:23:01 UTC, seany wrote:
I have seen
[this](https://forum.dlang.org/thread/akhbvvjgeaspmjntz...@forum.dlang.org).
I can't call break form parallel foreach.
Okey, Is there a way to easily call .stop() from such a case?
Here is a case to consider:
outer: foreach(i, a; parallel(array_of_a)) {
foreach(j, b; parallel(array_of_b)) {
auto c = myFunction0(i,j);
auto d = myFunction1(a,b);
auto f = myFunction2(i,b);
auto g = myFunction3(a,j);
if(someConditionCheck(c,d,f,g)) {
// stop the outer foreach loop here
}
}
}
Thank you
Maybe I'm wrong here, but I don't think there is any way to do
that with parallel.
What I would do is negate someConditionCheck and instead only do
work when there is work to be done.
Obviously that may or may not be suitable.
But with parallel I don't see any way to make it happen.
Re: Recommendations on avoiding range pipeline type hell
On Saturday, 15 May 2021 at 11:51:11 UTC, Adam D. Ruppe wrote: Meh, don't listen to that nonsense, just write what works for you. D's strength is that it adapts to different styles and meets you where you are. Listening to dogmatic sermons about idiomatic one true ways is throwing that strength away and likely to kill your personal productivity as you're fighting your instincts instead of making it work. +1
Re: Disallow implicit "conversion" from alias-types
On Tuesday, 10 November 2020 at 11:38:30 UTC, Vladimirs Nordholm wrote: Hello. I am unsure if I am going about this the right way, and if my question even makes sense. In essence what I want is to have two "types" represented by a size_t. Here is an example of what I want think I want (but might be completely off) alias Foo = size_t; alias Bar = size_t; Foo foo = 4; Bar bar = foo; // i want some error like // "cannot implicitly convert from type Foo to Bar" My best solution is to have the types as classes to force type checking. Is there a better way to do what I want here? https://dlang.org/library/std/typecons/typedef.html
Re: Is it possible to modify shared struct array in a function.
On Friday, 8 February 2019 at 04:51:08 UTC, Sudhi wrote:
On Friday, 8 February 2019 at 04:30:23 UTC, Arun Chandrasekaran
wrote:
On Friday, 8 February 2019 at 04:13:39 UTC, Sudhi wrote:
[...]
Works fine for me with DMD64 D Compiler v2.083.1.
https://run.dlang.io/is/RRM8GU
My example code was wrong. Below is the right one.
struct Company
{
string name;
string location;
}
struct Racks
{
int number;
int location;
}
struct Metadata
{
string name;
Company[] companies;
Racks[] racks;
}
struct Item
{
Metadata[] met;
int count;
}
shared (Item) item;
void main()
{
updateMetadata();
}
void updateMetadata()
{
Company company;
company.name = "Hello";
company.location = "Bangalore";
item.met.companies ~= company;
import std.stdio: writeln;
writeln(item);
}
https://run.dlang.io/is/iem0PY
You have to cast away shared:
auto loc_item = cast(Item) item;
loc_item.met ~= m;
item = cast(shared) loc_item;
Just to be clear, this is not threadsafe and require a mutex if
you do this other than as init in main.
Re: Linker error
On Monday, 21 January 2019 at 22:31:15 UTC, H. S. Teoh wrote: On Mon, Jan 21, 2019 at 10:19:00PM +, Jerry via Digitalmars-d-learn wrote: On Monday, 21 January 2019 at 21:37:22 UTC, H. S. Teoh wrote: [...] > Looks like a problem with stale cached object files. Try: > > rm dub.selections.json >dub build --force > > (Be sure to back up dub.selections.json before doing this, > if you > have customized it by hand.) [...] Still same error, on both 2.78 and 2.84. Hmm. OK, then I've no idea what's wrong, sorry. T Thank you for all the effort!
Re: Linker error
On Monday, 21 January 2019 at 21:02:23 UTC, Steven Schveighoffer wrote: On 1/21/19 3:37 PM, Jerry wrote: [...] I had a similar problem that I fixed myself actually last dconf: https://issues.dlang.org/show_bug.cgi?id=17968 This looks almost identical as the issue was in the generated xtoHash function. What version of the compiler are you using? My issue was fixed in 2.080.1, and then a followup fix in 2.081.1. -Steve Ok, I get the same linker error down to version 2.74. Below that my eventcore version does not compile. Atleast LDC can compile so I can move forward. I will try to dustmite this tomorrow.
Re: Linker error
On Monday, 21 January 2019 at 21:37:22 UTC, H. S. Teoh wrote: On Mon, Jan 21, 2019 at 04:02:23PM -0500, Steven Schveighoffer via Digitalmars-d-learn wrote: On 1/21/19 3:37 PM, Jerry wrote: > [...] [...] > [...] [...] Looks like a problem with stale cached object files. Try: rm dub.selections.json dub build --force (Be sure to back up dub.selections.json before doing this, if you have customized it by hand.) T Still same error, on both 2.78 and 2.84.
Re: Linker error
On Monday, 21 January 2019 at 21:02:23 UTC, Steven Schveighoffer wrote: What version of the compiler are you using? My issue was fixed in 2.080.1, and then a followup fix in 2.081.1. -Steve Hello! I am using 2.084. Interestingly it works with LDC 1.9 (frontend 2.79) and that just works fine. Bisecting dmd versions. - Jerry
Linker error
Hello, I am trying to compile a 1 year old project of mine which uses htmld and vibed. But I get this weird linker error which does not make any sense to me atleast. I am using Windows 7 and dub. htmld 0.3.6: target for configuration "library" is up to date. taggedalgebraic 0.10.12: target for configuration "library" is up to date. eventcore 0.8.40: target for configuration "winapi" is up to date. stdx-allocator 2.77.5: target for configuration "library" is up to date. vibe-core 1.5.0: target for configuration "winapi" is up to date. vibe-d:utils 0.8.4: target for configuration "library" is up to date. vibe-d:data 0.8.4: target for configuration "library" is up to date. mir-linux-kernel 1.0.1: target for configuration "library" is up to date. vibe-d:crypto 0.8.4: target for configuration "library" is up to date. diet-ng 1.5.0: target for configuration "library" is up to date. vibe-d:stream 0.8.4: target for configuration "library" is up to date. vibe-d:textfilter 0.8.4: target for configuration "library" is up to date. vibe-d:inet 0.8.4: target for configuration "library" is up to date. vibe-d:tls 0.8.4: target for configuration "openssl-mscoff" is up to date. vibe-d:http 0.8.4: target for configuration "library" is up to date. vibe-d:mail 0.8.4: target for configuration "library" is up to date. vibe-d:mongodb 0.8.4: target for configuration "library" is up to date. vibe-d:redis 0.8.4: target for configuration "library" is up to date. vibe-d:web 0.8.4: target for configuration "library" is up to date. vibe-d 0.8.4: target for configuration "vibe-core" is up to date. my_stuff ~master: building configuration "updater-local"... Linking... vibe-d_web.lib(common.obj) : warning LNK4255: library contain multiple objects of the same name; lin king object as if no debug info eventcore.lib(driver.obj) : warning LNK4255: library contain multiple objects of the same name; link ing object as if no debug info eventcore.lib(driver.obj) : warning LNK4255: library contain multiple objects of the same name; link ing object as if no debug info eventcore.lib(core.obj) : warning LNK4255: library contain multiple objects of the same name; linkin g object as if no debug info my_stuff.obj : error LNK2019: unresolved external symbol _D60TypeInfo_xS4html3dom__T15ChildrenForwar dTCQBfQBd4NodeVnnZQBi6__initZ referenced in function _D8typecons__T11ThrowOnNullTS4html3dom__T15Chil drenForwardTCQBfQBd4NodeVnnZQBiZQCn9__xtoHashFNbNeKxSQDu__TQDoTQDeZQDwZm .dub\build\updater-local-debug-windows-x86_64-dmd_2083-F0ADCB72FF986B7D6354817AF1E3A045\my_stuff.exe : fatal error LNK1120: 1 unresolved externals Error: linker exited with status 1120 dmd failed with exit code 1. I tried to find the typecons.ThrowOnNull thing in the standard library but that one does not exist. So I am pretty confused about what is going on here. Thank you.
Re: DlangUI and android
On Monday, 10 September 2018 at 09:19:52 UTC, Josphe Brigmo wrote: Is there an emulator that can run the apks? Android emulator does not work, I suppose, because it isn't java. Complains about a missing classes.dex file. I'd rather have an emulator version if possible for quicker dev. For APKs I usually use Bluestacks [0]. Works great for Unity builds atleast. 0: https://www.bluestacks.com/
Re: Casting a pointer and length value as a dynamic array
On Monday, 30 July 2018 at 22:22:39 UTC, solidstate1991 wrote:
I need this to port a C++ code to D (a compression algorithm
known as LZHAM), and the easiest way to deal with it would be
that. The ADLER32 and CRC32 algorithms had to be ditched, and
while I could rewrite the former to make sense (used some form
of "vectorization") I would like to use the standard library's
implementation for the latter.
int[] as_array(int* ptr, size_t len) {
return ptr[0 .. len];
}
Re: Call different member functions on object sequence with a generic handler function?
On Friday, 29 June 2018 at 20:23:47 UTC, Timoses wrote:
void handler(alias func, T)(T[] ts) {
}
Btw this is pretty much std.algorithm.each
import std.algorithm;
void main() {
auto cs = [ new C(), new C() ];
cs.each!(o => o.A());
}
https://dlang.org/phobos/std_algorithm_iteration.html#.each
Re: [OT] mobile rising
On Monday, 13 November 2017 at 00:22:46 UTC, codephantom wrote: It's so like people these days, and even on these forums, to attack the ones sticking up for themselves, rather than stopping them from being attacked in the first place, just for having a different opinion - or god forbid...making a joke about MSFT. You weren't attacked and you aren't a victim stop trying to paint yourself one you stated an opinion and a counter argument was made nothing more or less no one called you names or fanboy or whatever and if you wanted it to stop you could have just stopped posting instead of posting your own harassment you aren't defending yourself if you are constantly calling other people "msft fanboys" harassing people isn't defending your argument.
Re: [OT] mobile rising
On Monday, 13 November 2017 at 00:40:29 UTC, codephantom wrote: On Monday, 13 November 2017 at 00:36:17 UTC, Jerry wrote: It's easy to take a single sentence out of context maybe i should just keep everything as one long protruding sentence so that you are forced to quote everything so that you you won't misinterpret what it means by what I don't know maybe you just read the one sentence then decided you didn't feel like reading the rest cause you thought you saw what you wanted and then proceeded to post immediately without thinking as you for some reason needed to make four separate posts anyways have fun reading this sentence without proper punctuation maybe you'll come to appreciate it and actually quote the entire meaningful part of a text. What? I can even understand C# better than this. :) Glad you got the point.
Re: [OT] mobile rising
On Sunday, 12 November 2017 at 00:24:31 UTC, codephantom wrote: On Saturday, 11 November 2017 at 20:35:40 UTC, Jerry wrote: Taking away the start button wasn't that big of a deal. Thanks...another qoute to add to: 'The famous quotes of Jerry the MSFT fanboy'. It's easy to take a single sentence out of context maybe i should just keep everything as one long protruding sentence so that you are forced to quote everything so that you you won't misinterpret what it means by what I don't know maybe you just read the one sentence then decided you didn't feel like reading the rest cause you thought you saw what you wanted and then proceeded to post immediately without thinking as you for some reason needed to make four separate posts anyways have fun reading this sentence without proper punctuation maybe you'll come to appreciate it and actually quote the entire meaningful part of a text.
Re: [OT] mobile rising
On Friday, 10 November 2017 at 22:54:40 UTC, codephantom wrote: On Friday, 10 November 2017 at 22:16:55 UTC, Jerry wrote: On Friday, 10 November 2017 at 01:19:06 UTC, codephantom wrote: On Friday, 10 November 2017 at 01:15:26 UTC, Jerry wrote: Not much of a technie nerd if it "just finished" and you've already exhausted your knowledge and have given up :). Just sayin'. Well, everytime I wanted to find something, I had to google it... Yes, that accurately describes exhausting your knowledge. Then I realised I had to pay for it as well...and, that's when i gave up. Indeed, you could contact Microsoft for support and know you are talking to professional and not some rabid fanatic that will split hairs over the differences between linux and freebsd. MSFT fanboy...at it again... I use all forms of software, as such I don't go around saying Linux and FreeBSD should do things the way Windows is doing things. Or that support for them should be dropped by DMD, like a certain someone is doing. If you don't like Windows don't use it, it's that simple. On Saturday, 11 November 2017 at 00:38:40 UTC, codephantom wrote: On Friday, 10 November 2017 at 22:16:55 UTC, Jerry wrote: Indeed, you could contact Microsoft for support and know you are talking to professional and not some rabid fanatic that will split hairs over the differences between linux and freebsd. Well.. if MSFT stop making stupid design decisions, they could invest their money in more innovation, instead of investing it into supporting and correcting their stupid design decisions. Since Windows XP, what have they done: - they release Vista (people lost their jobs over that, and MSFT had to go back to drawing board and actually consider what their customers want for a change). - have you ever compared opening Event Viewer on windows xp, to opening it on every windows version since xp...it just gets bigger and slower to open. - then they release Windows 7, with its fancy aero interface (which i really liked). - then they took it away. - then they added all this so called 'intelligence' into the o/s, that just bloated it and made it slower. - then they took the start button away - then they thought tiles are a better way to find your programs. - then they though preventing users from customising their system, is something that should be done. - then they thought the boring, plain metro interface - is innovative. - then they thought preventing users from stopping the automatic installation of updates was a good idea - then thought treating the desktop like it's a mobile tablet, is a good idea. - then they thought they'd make it so hard for anyone to find anything, that users would have to revert to using their new little wiget that tracks everything the user does and sends it off to MFST for big data analysis. ..oh man... i could just go on and on. The only innovation in software in the last decade or more, has come from open source projects. So anyone that suggest we look to MSFT for design decisions, better think again. Taking away the start button wasn't that big of a deal. I used Windows 8, the only people affected by it are those who are borderline computer illiterate. The same thing with any kind of change, if people had their way we would still be in the stone age cause they were more comfortable with using stones than having to learn to use something new. Whether to use Visual Studio or not isn't a "design decision". It's not relatable in the slightest bit. It's a tool that generates a binary file, you aren't going to find a better one on Windows that's as stable and has as good support, and the toolchain down the line that has equally good support (such as debuggers). When I joined the forum a little while back, I dared to suggest that D should be able to compile a 64bit binary on Windows, without having to relying on gigabytes of proprietaty, closed source, bloat from MSFT. I stand by that comment, despite the harrassment from the many MSFT fanboys on these forums. Acting as victim, you've done more harassing than anyone. How ironic you label people "MSFT fanboy" in the same sentence you cry harassment.
Re: [OT] mobile rising
On Friday, 10 November 2017 at 01:19:06 UTC, codephantom wrote: On Friday, 10 November 2017 at 01:15:26 UTC, Jerry wrote: Not much of a technie nerd if it "just finished" and you've already exhausted your knowledge and have given up :). Just sayin'. Well, everytime I wanted to find something, I had to google it... Yes, that accurately describes exhausting your knowledge. Then I realised I had to pay for it as well...and, that's when i gave up. Indeed, you could contact Microsoft for support and know you are talking to professional and not some rabid fanatic that will split hairs over the differences between linux and freebsd.
Re: don't answer (possible/likely) spam
On Friday, 10 November 2017 at 16:09:48 UTC, Stefan Koch wrote: please don't answer messages which are possibly spam. Try this by not answering to this thread. I think I know why not every DMD pull request gets a reply now. Some people think they are spam and don't bother replying at all to them. Well I think every pull request deserves a reply, even if it's just stating that it isn't going to be considered.
Re: [OT] mobile rising
On Friday, 10 November 2017 at 01:04:05 UTC, codephantom wrote: On Friday, 10 November 2017 at 00:23:03 UTC, Jonathan M Davis wrote: I don't disagree that there are differences between FreeBSD and Linux, but my point is that for most folks, the differences are small enough that it's not all that different from trying to convince someone to use one Linux distro or another - especially if you're trying to convince a Windows user, since Windows is so drastically different from both. My Windows 10 just finished downloading. I installed it, and even a technie nerd like me couldn't work it out. I think Windows 10 is enough to convince users to switch ... to anything ;-) https://www.youtube.com/watch?v=KHG6fXEba0A Not much of a technie nerd if it "just finished" and you've already exhausted your knowledge and have given up :). Just sayin'.
Re: [OT] mobile rising
On Thursday, 9 November 2017 at 14:42:41 UTC, Joakim wrote: There is some truth to this, but if you cannot compete with a free product- cough, cough, Windows Mobile- I don't know what to tell you. In other words, google cannot afford to spend a fraction of the money on Android that Apple spends on iOS, because google makes so little money off of Android by comparison, so there are disadvantages to their free model too. It is one of the reasons why they have now plunged into the high-end smartphone market with their recent Pixel line. I think the lack of a viable business model for Android vendors, other than Samsung, is a huge problem for the platform, as Apple hoovers up two-thirds of the profit with only a tenth of the phones sold: https://www.counterpointresearch.com/80-of-global-handset-profits-comes-from-premium-segment/ As I said earlier, the mobile OS story is not over yet, there are more changes to come. People that buy Android I find tend to keep their phones for longer. People with Apple phones keep buying new ones. Part of that is how many phone Apple claims are on the latest version. So developers only target the latest one, then their apps don't run on old phone and it encourages people to "upgrade". Android apps tend to support more versions as well, it's a more diverse OS. I've even seen websites that just straight up drop support for old versions of Safari. Can't get the latest version of Safari cause you can't update your phone. Then you go to firefox just to find out you can't install it cause it's no longer support for that iOS version. Can't even download an old version of firefox that did support it cause it's Apple's store and they don't support that.
Re: [OT] Windows dying
On Wednesday, 8 November 2017 at 06:24:38 UTC, Patrick Schluter wrote: On Tuesday, 7 November 2017 at 20:44:57 UTC, Jerry wrote: It's amazing how many people are so lazy to download Visual Studio, and some of the stupidest reason for not wanting to download it to boot. It has nothing to do with lazyness. If you're behind a proxy that abomination of a installer of Visual Studio doesn't work. I tried several times, offline and online setup, read the Studio forums. Studio 2017 installer doesn't work inside our environment at work (EU Commission). Might be an issue with our infrastructure but it's unlikely as I managed to install a lot of things before. Your the first person that's responded to me to have said this. Do you use D at your work anyways? If you require Visual Studio at your work, the free community version probably isn't for you anyways. If you say it's not your infrastructure, then they might very well be blocking the download to your work, knowing that it's a business. But I'd say it's more likely not them blocking it. Contact IT, if you're even suppose to be installing Visual Studio on the computers at work.
Re: [OT] Windows dying
On Tuesday, 7 November 2017 at 23:04:09 UTC, bauss wrote: On Tuesday, 7 November 2017 at 20:44:57 UTC, Jerry wrote: On Tuesday, 7 November 2017 at 19:10:50 UTC, bauss wrote: On Wednesday, 1 November 2017 at 18:59:21 UTC, Adam D. Ruppe wrote: On Wednesday, 1 November 2017 at 18:42:07 UTC, Bo wrote: There is a issue with Windows. The whole attacking the messenger, the whole idiotic argumentation's that Windows is dying, it is all pure useless trolling the people who ask a simple questions: How to solve the D 64bit issue so that like on the Linux or OSx platform, the users can have the SAME level of consistency. Windows 32 bit is the special one - it is the ONLY platform where D works out of the box without additional downloads. That's one reason why I advocate it for just playing around - it just works. Yes i works when toying around, but as soon as you want to write actual software then you can't write 32 bit anymore, because OPTLINK is just too buggy and will end up not being able to link your code correctly. A good example is that mysql-native currently don't link properly with OPTLINK. It might link for some, but at least for me; I'm forced to either use an older compiler or compile to 64 bit. See: https://github.com/mysql-d/mysql-native/issues/100 There's also reported issues like this one: https://issues.dlang.org/show_bug.cgi?id=15183 I'm aware that issues like these should be reported more often and as soon as they're discovered, but they're also hard to report, because you get virtually no information about what's wrong and you can only guess by commenting out sections of your code until it will link. That's not ideal. I'm sure many other similar issues exists. Yes, 32 bit development with D is easy on Windows, but only for toying around; which is no reason to defend it. You can use -m32mscoff for 32-bit, which uses Visual Studio like the 64-bit version. I've been saying OPTLINK should be removed. Even if you report a bug for optlink, it's never going to get fixed. No one's stupid enough to go digging through that spaghetti code dump. If you're luck, some limitation might introduced to DMD that won't cause the bug in OPTLINK to trigger. That's why it shouldn't be supported anymore, it's hindering DMD, not making it better. It's amazing how many people are so lazy to download Visual Studio, and some of the stupidest reason for not wanting to download it to boot. It's not that people don't want to get Visual Studio, but some people have limited space. Ex. until a few months ago I was actually developing all my stuff on a Windows tablet which only had 30gb of space (The OS etc. also took of those 30 gb.) It would have been impossible for me to get Visual Studio on it, at least if I wanted to use it for anything else. Of course it's not a problem for me at the moment as I have a laptop, but at the time it was the only thing I had. At least I didn't get by any bugs in OPTLINK back then, else it would have been impossible for me to actually write D code. Well a tablet isn't really for development. Even a cheap laptop would be better for development. You can't really do much of anything with that little space. I don't think the focus should be people with niche development hardware like tablets. If you do enough CTFE the RAM usage of DMD shoots through the roof and you'd end up not having enough RAM to compile anyways. Let alone if you have enough ram but still use the 32-bit version of DMD and hit that limit.
Re: [OT] Windows dying
On Tuesday, 7 November 2017 at 19:10:50 UTC, bauss wrote: On Wednesday, 1 November 2017 at 18:59:21 UTC, Adam D. Ruppe wrote: On Wednesday, 1 November 2017 at 18:42:07 UTC, Bo wrote: There is a issue with Windows. The whole attacking the messenger, the whole idiotic argumentation's that Windows is dying, it is all pure useless trolling the people who ask a simple questions: How to solve the D 64bit issue so that like on the Linux or OSx platform, the users can have the SAME level of consistency. Windows 32 bit is the special one - it is the ONLY platform where D works out of the box without additional downloads. That's one reason why I advocate it for just playing around - it just works. Yes i works when toying around, but as soon as you want to write actual software then you can't write 32 bit anymore, because OPTLINK is just too buggy and will end up not being able to link your code correctly. A good example is that mysql-native currently don't link properly with OPTLINK. It might link for some, but at least for me; I'm forced to either use an older compiler or compile to 64 bit. See: https://github.com/mysql-d/mysql-native/issues/100 There's also reported issues like this one: https://issues.dlang.org/show_bug.cgi?id=15183 I'm aware that issues like these should be reported more often and as soon as they're discovered, but they're also hard to report, because you get virtually no information about what's wrong and you can only guess by commenting out sections of your code until it will link. That's not ideal. I'm sure many other similar issues exists. Yes, 32 bit development with D is easy on Windows, but only for toying around; which is no reason to defend it. You can use -m32mscoff for 32-bit, which uses Visual Studio like the 64-bit version. I've been saying OPTLINK should be removed. Even if you report a bug for optlink, it's never going to get fixed. No one's stupid enough to go digging through that spaghetti code dump. If you're luck, some limitation might introduced to DMD that won't cause the bug in OPTLINK to trigger. That's why it shouldn't be supported anymore, it's hindering DMD, not making it better. It's amazing how many people are so lazy to download Visual Studio, and some of the stupidest reason for not wanting to download it to boot.
Re: [OT] Windows dying
On Saturday, 4 November 2017 at 02:33:35 UTC, Computermatronic wrote: I, like many other windows users, want to be able to compile 64bit binaries in windows, without having to download and install the bloated and time consuming to download and install Visual Studio. I do most of my programming in Sublime Text, and frequently re-install windows. This may not be the case for many windows users of D, but clearly many windows users of D would like to be able to compile x64 out of the box. So your fine with reinstalling Windows, going through the entire processing to setup and configure. Download all the new updates and install them. Then setup your environment, downloading potentially dozens of applications (git, debuggers, text editors, compilers, etc..) and configuring settings? But downloading Visual Studio is "time consuming".. I don't even. If all you can complain about Visual Studio is its download size then I'd say it's doing pretty good as a development tool.
Re: Link errors when compiling shared lib on windows
On Wednesday, 1 November 2017 at 16:02:37 UTC, Daniel Fitzpatrick wrote: On Wednesday, 1 November 2017 at 15:52:17 UTC, kinke wrote: On Wednesday, 1 November 2017 at 15:15:27 UTC, Daniel Fitzpatrick wrote: I am following this short tutorial on compiling a shared lib: https://wiki.dlang.org/Call_D_from_Ruby_using_FFI Because it's on Windows I am using these compiler options: -shared -m64 -defaultlib=libphobos2.so i.d However, I am receiving rather a lot of linker errors. Not sure what else to provide the compiler. Try less, especially no `-defaultlib` overridden with a Linux shared-object. You'll have to edit the hardcoded `./i.so` in the example as well obviously. Oops, missed that! What i've tried is -shared -m64 i.d -shared -m64 -defaultlib=libphobos2.dll i.d Still seeing a lot of linker errors. Errors for the former: There's no shared library of Phobos for Windows with either DMD or LDC. You have to statically link to it.
Re: Note from a donor
On Sunday, 29 October 2017 at 01:43:46 UTC, codephantom wrote: So I'm executing my right to free speech, and I'm saying that I don't like it, and I wish it was better. Is that so bad? You are doing more than saying you don't like it. You are requesting and advocating for the removal of a feature that has no reason to be removed. I never said you couldn't say you don't like it, you are free and welcome to do so. I never even said you can't request for a feature to be removed. I'm simply making the counter argument for why it shouldn't be, and I'm free to do that as you are free to make horrible requests. Anyways you keep trying to change your argument and make it appear as something else. Your free speech was never in jeopardy from the beginning, I never told you couldn't say anything. It's clear where this is going and it's clear you have no intentions of actually making any attempt to justify your request as it is unjustifiable. Good day.
Re: Note from a donor
On Sunday, 29 October 2017 at 00:45:08 UTC, codephantom wrote: On Saturday, 28 October 2017 at 19:46:00 UTC, Jerry wrote: Start the download when you go to sleep, when you wake up it will be finished. I did this as a kid when I had internet that was probably even slower than yours right now. It'll be like those 4 hours never even happened. That's greate advice Jerry. Perhaps that should go up on the wiki... "NOTE: If you're using Windows, and you want to use the -m64 mode to compile D into 64bit code, you will need to download several GB's of other stuff...and if you have slow internet connection...then just start it when you go to sleep..and when you wake up it will be finished. It'll be like those 4 hours never even happened." Most developers don't have shitty internet though, the one's that do don't go whining about it trying to use something "better", where better is just a substitute for smaller package size. Visual Studio is probably the most reliable and stable toolchain on Windows, the only thing anyone (ehm you) has to say bad about it is it's download size. I'd say that's better damn near the best D can do if the only thing someone has to complain about it is the download size.
Re: Note from a donor
On Sunday, 29 October 2017 at 00:17:10 UTC, codephantom wrote: On Saturday, 28 October 2017 at 19:46:00 UTC, Jerry wrote: It's probably why you shouldn't be on Windows to begin with.. I'm not. I'm on FreeBSD. So why do you care about something that doesn't even affect you? Talk about being narcissistic ;) I wasn't talking about narcissism, I was talking about trolling. Narcissism was not correlated with trolling enjoyment in that study I mentioned. It is when someone is only thinking about themselves, such as yourself and wanting D to not use tools that you aren't even complaining about being good enough. You are just complaining about it cause it's a large download size. I find people always refer to people as trolls instead of creating a counterpoint to their argument. It's a lot easier to just label someone a troll and ignore their arguments than building a case for a baseless request.
Re: Note from a donor
On Saturday, 28 October 2017 at 15:36:38 UTC, codephantom wrote: But if you really are missing my point..then let me state it more clearly... (1) I don't like waiting 4 hours to download gigabytes of crap I don't actually want, but somehow need (if I want to compile 64bit D that is). Start the download when you go to sleep, when you wake up it will be finished. I did this as a kid when I had internet that was probably even slower than yours right now. It'll be like those 4 hours never even happened. (2)I like to have choice. A fast internet might help with (1). (2) seems out of reach (and that's why I dont' and won't be using D on Windows ;-) It's probably why you shouldn't be on Windows to begin with.. (being a recreational programmer, I have that luxury..I understand that others do not, but that's no reason for 'some' to dismiss my concerns as irrelevant. They're relavent to me, and that's all that matters ;-) Talk about being narcissistic ;)
Re: Note from a donor
On Saturday, 28 October 2017 at 14:43:38 UTC, codephantom wrote: I explicitly mentioned that I did ***NOT*** want VS installed. So? If you don't want to use it, then don't use D, or don't use Windows. There's simple solution to your problem. Rust requires VS, you can't build on Windows without it. It's not that big of a deal to require. If you don't want to use it, then go ahead, D is open source see how easy it is to replace with something else. The majority of time spent was downloading the damn thing! Again with the size issue, 3.5 GB isn't that big of a file. Start the download and go do something, time management is a skill. You don't have to sit there and watch it download, even if you have shitty internet.
Re: Note from a donor
On Saturday, 28 October 2017 at 07:39:21 UTC, codephantom wrote: btw. (and I do realise we've gone way of the topic of this original thread)...but... if it interests anyone, this is the outcome of yesterday, where I wasted my whole day trying to get DMD to compile a 64bit .exe on a fresh install of Windows 7. Your own incompetence isn't reason enough for everyone else to suffer. I've never had a problem installing Visual Studio, or getting D to work with it.
Re: Note from a donor
On Saturday, 28 October 2017 at 00:05:53 UTC, codephantom wrote: Is is it problem that D should accept, and just impose on it's users? Or should D find a better way? Which is the worse mentality? There is an afterlife with god. There is nothingness after death. Which is the worse mentality? Yet why is it that the more educated someone is, the more likely they are to be atheist?
Re: Note from a donor
On Saturday, 28 October 2017 at 00:05:53 UTC, codephantom wrote: Rubbish! And get you facts straight! Where did I advocate from the removal of the ability for D to generate 64-bit binaries? So you are saying to not use the platform's tools to generate binaries. That's like saying not to the use linux's tools to generate binaries on that platform and instead D should build it's own tools in order to be able to. D has a small enough community as it is, it isn't capable of developing such tools. You are advocating for the removal of the only way to currently genreate 64-bit binaries in D. The only other solution is mingw, and honestly those tools aren't nearly as polished as one run by a company with almost limitless resources. If you don't want to deal with Visual Studio, I'll deal you one better, why are you bothering to deal with Windows at all? If you don't like Microsoft so much just switch to Linux, there your problem is solved. You can't even install Visual Studio on Linux. At a minimum, I had to download 3.5GB of VS build tools just so I could compile a 64 bit D program (and it took me almost a whole day to work out the correct process). It's really not that difficult, you install it and it pretty much just works. The only problem case is if you install D before you install Visual Studio. Wow 3.5 GB, that's so much! If only there were TB HDDs at an affordable price, oh god why does it have to be so big to install! Anyways maybe I just don't see it as a problem cause I have to download much much bigger files. Good thing you don't play games cause they are getting into the 80 GB range nowadays. Is is it problem that D should accept, and just impose on it's users? Or should D find a better way? Which is the worse mentality? Your on the Windows platform, not support Windows tools is annoying and you aren't going to find better tools. If you don't like the way Microsoft does business, you have 2 other platforms you can go to. Buy a Mac or boot up Linux. Just stop making Windows a worse platform by suggesting to drop support for the official development tools. There is no "better way". Every other way is going to be worse cause Windows doesn't have as big of a community dabbling in building tools like GCC and Clang for Windows. Why? Cause there's Visual Studio. Like I said, ideals are nice and all but people still need to get shit done. That's what your argument boils down to, the ideal of finding a better way than what is currently available. The problem is you aren't even suggestion a better way, you are just trying to sell it on the false belief that there is something better. But there isn't. This is worse than religion.. Why don't you like VS, cause they changed something? Rofl, whenever there is change people hate it. Cause people don't like change, for the only reason that they don't want to learn something new. I don't know how many times I teach someone a hotkey that's way better than their current method and they just keep going with their horribly slow method cause that's what they know. And download size? I could say why are you even on Windows, Linux is like 20 GB smaller download size and takes up less HDD space than Windows. So why the hell are you even on Windows? Oh yah once you install it you don't have to worry about it for years on end. You want to drop support for VS cause of something you spend once doing and then pretty much never have to do again for years to come. Please no, just switch to Linux and let the people that actually need to use the Windows platform, use it effectively.
Re: Note from a donor
On Friday, 27 October 2017 at 13:15:38 UTC, codephantom wrote: The less the D language partakes in that stuff up.. the better D will be for it. This mentality is why D is pretty awful on Windows. It's bad enough that DMD doesn't release a 64-bit version on Windows but now you are advocating for the removal of the ability for it to generate 64-bit binaries as well! Yah that won't bring you 10 steps back. Ideals are nice and all, but some people still need to get shit done. This sort of mentality is hurting D, not helping it.
Re: So why double to float conversion is implicit ?
On Sunday, 22 October 2017 at 10:57:24 UTC, NX wrote: On Sunday, 22 October 2017 at 02:25:44 UTC, codephantom wrote: On Saturday, 21 October 2017 at 20:17:12 UTC, NX wrote: Interestingly enough, I realized that atan() returns double (in this case) but wait, it's assigned to a float variable! Compiler didn't even emit warnings, let alone errors. There a few lessons here. (1) D is not Java ;-) D is not C/C++ either. I fail to see how does it help to be C++ compliant. It's absolutely trivial to tell the compiler that conversion is on purpose by explicitly casting and it immensely helps to reduce bugs (since we are humans after all). It is pretty close, I converted a C++ project by copying and pasting most of the code. A bigger issue is how CTFE uses "real" for everything, even at times you specify it not to use it. If you use an enum and specify "double" or "float", it might very well store it as a "real" in memory. That's the more troubling implicit conversion happening with D that has no real benefit or purpose, other than someone thought it was a good idea cause real's have more precision so they should be the default.
Re: D on quora ...
On Sunday, 15 October 2017 at 16:29:22 UTC, Ecstatic Coder wrote: If all that is already available, perfect :) [snip] And moreover I'd be delighted to start using D instead of Go for my next web server developments. You can start now and get performance later? In fact you may supply important benchmarks from your day to day usage. Ok. Still not convinced to use D instead of C++ for my personal use cases (games and other soft real-time apps), but I get the idea. I switched my personal game to D from C++. Was easy, most of it was just copy paste. I was writing a math library to replace the one I was using to make it a bit more light way and to fit my needs a bit more. I didn't like how some thing were implemented in the library I was using. So I started with templates, I need multiple types and what not for the same purpose. At some point I have a function that needs to take 2 different template types. It starts to get so convoluted, order matters cause C++ still just uses copy-paste-includes and I don't think modules made it into C++17. I wrote the same library in half the code, in a way that's more readable and manageable. I didn't have to define things so that they would work, I could define them logically the way I'd expect them to be. Mixins also reduced code quite a bit, generating functions for different types and dimensions. Even though you have constexpr if statements now you still need to define all the function bodies even if they all can go in one function body now.
Re: debugging in vs code on Windows
On Saturday, 14 October 2017 at 19:01:52 UTC, piotrklos wrote: On Saturday, 14 October 2017 at 13:12:51 UTC, Jerry wrote: On Friday, 13 October 2017 at 12:55:09 UTC, piotrklos wrote: (...) If you use generate a 32-bit binary using DMD, it generates it in a format that the C/C++ extension doesn't understand. You need to compile -m32mscoff or -m64, and you need to make sure the /DEBUG is passed to the linker, as I don't think dmd passes it that. You can do that by passing "-L/DEBUG" to DMD (when using -m32mscoff or -m64). There should be a .pdb file that gets generated, when you start the debugger it should say that symbols were loaded for the exe. I also can't say for certain if debug information is even generated for the unittests, so that might be something worth looking into to make sure it does. I have added this to dub.json: "dmd-flags":[ "-g", "-m64", "-L/DEBUG" ] but I don't see a pdb file generated when I build. What am I doing wrong? Are you sure it's not dflags? I don't use dub but a quick search shows there's dflags, but no flags setting. https://code.dlang.org/package-format?lang=json Also using verbose flag with dub should show you the commands that are executed for building.
Re: debugging in vs code on Windows
On Saturday, 14 October 2017 at 14:23:34 UTC, piotrklos wrote: On Saturday, 14 October 2017 at 13:20:27 UTC, Jerry wrote: On Saturday, 14 October 2017 at 10:15:53 UTC, evilrat wrote: webfreak's NativeDebug extension to be able to click to set breakpoint on lines(only for that). You can just use VS Code setting, put the following into your settings.json: "debug.allowBreakpointsEverywhere": true But I can already click on the edge of editor and red bubble appears. Its just that the execution doesn't stop on those. That comment wasn't for you, the other one was.
Re: debugging in vs code on Windows
On Saturday, 14 October 2017 at 10:15:53 UTC, evilrat wrote: webfreak's NativeDebug extension to be able to click to set breakpoint on lines(only for that). You can just use VS Code setting, put the following into your settings.json: "debug.allowBreakpointsEverywhere": true
Re: debugging in vs code on Windows
On Friday, 13 October 2017 at 12:55:09 UTC, piotrklos wrote: I have windows 10, VS Code with code-d and C/C++ language extensions. I try to debug but it doesn't work. In particular, the debugging doesn't stop on breakpoints. It exits immediately. I recompile with -m64 and -g. I use dub to build the project. I use unit-threaded and I'm trying to debug a unittest build. Has anyone been able to debug in VS code on Windows? What am I doing wrong? (Rhetorical) Why is dlang community provide so many options (see https://wiki.dlang.org/Debuggers) and **every single one** of them is faulty in some way? I tried windbg and mago-mi but didn't gen anywhere. If you use generate a 32-bit binary using DMD, it generates it in a format that the C/C++ extension doesn't understand. You need to compile -m32mscoff or -m64, and you need to make sure the /DEBUG is passed to the linker, as I don't think dmd passes it that. You can do that by passing "-L/DEBUG" to DMD (when using -m32mscoff or -m64). There should be a .pdb file that gets generated, when you start the debugger it should say that symbols were loaded for the exe. I also can't say for certain if debug information is even generated for the unittests, so that might be something worth looking into to make sure it does.
Re: D on quora ...
On Wednesday, 11 October 2017 at 07:33:26 UTC, Laeeth Isharc wrote: You know it's not that hard to be the change you wish to see in the world. That's really the whole point of open source, or at least of at least reasonably or more free software - you're not at the mercy of a paid vendor to whom you pay a fortune for the favour of them closing or otherwise creatively ignoring your tickets. You can pretty easily fix many problems and irritations yourself, and if you're too busy then one can pay someone to do it, and if one is busy and has no money to spend right now one can try to persuade someone to work on it. But if one just grumbles, probably the result will be just what anyone would expect. You still are at the mercy of the people maintaining the project. Which is kind of no different than being at the mercy of a big company from my experience. Some people listen, but a lot of the time they don't if something contradicts their views (having to do anything regarding Windows in this case). I could fork it and then maintain things myself, but that means fixing any pull requests or changes in the future yourself. Which now becomes a full time job, where as using the project to begin with was the point of reducing the workload, not increasing it. 64 bit command line build didn't seem to work for a while. That's been fixed recently, as I recall. One can't really compare Linux and Windows 32 and 64 bit. Those worlds work very differently. Windows is as it is because they are fanatical about maintaining backwards compatibility. So unless you run out of memory then 32 bit compiler isn't much of a restriction. And if you are doing so much ctfe that you run out of memory, chances are you can figure out how to build the 64 bit compiler on Windows! You can easily run out of memory, DMD is a memory hog. Yes that's exactly the problem I run into all the time. It's not even the amount of CTFE you are doing, you can run out of memory by doing something really simple. DMD is just horribly optimized in terms of memory. Yes more work for me when it's something that should be done as part of the build process. Try using digger - might work now that the 64 bit command line build works again. And failing that maybe file a request on bugzilla. For what... ? And I don't know but I guess if you contribute something to the D Foundation, probably - because it's still quite new - it will be easier to get people to listen to a gentle request to have a downloadable 64 bit compiler. These things do cost money, and right now I think somebody is paying for that out of the goodness of their heart... Everything costs money. That's how the world works. If you mean hosting the source code. Well Github hosts the source for open source projects for free. If you mean distributing binaries, well Github allows you to upload binary files for people to download for free as well. If you mean testing, well there are a lot of alternatives that provide free testing for open source projects (like appveyor which isn't currently being used). If you mean this forum board? Well there are a lot of places you have a board for free. There's some 100+ pull requests in DMD alone, just trying to contribute something is a chore in itself. Making a contribution isn't really worth much.
Re: D on quora ...
On Saturday, 7 October 2017 at 06:19:01 UTC, Brad Roberts wrote: As always, focusing on the users of the language tends to pay a lot more dividends than focusing on nay sayers. Luckily, that's how things tend to proceed here, so yay for that. Doesn't feel like that when the views of the people in charge don't align with what people are saying. I can understand people's dissatisfaction with Windows, but some people take it too far. The compiler for Windows is built using 32-bit, not only is the 64-bit version not built it's not even supported or tested. I think someone made a post a little while ago about LDC that 95% or more of downloads for their compiler were for the 64-bit version. If only one version is to be supported then it should be the 64-bit version. I can't even imagine the outrage there would be if 64-bit wasn't supported on Linux. Hell, they haven't even bothered setting up AppVeyor for dmd, free testing on Windows. Niche within a niche, can't expect much I guess.
Iterating over functions in module in order?
Any ideas on how someone could iterate over functions in a module as they appear, rather than any random order, without having to manually label them?
Re: Does D support nested Templates aka Higher Kinded Polymorphism?
On Tuesday, 3 October 2017 at 12:58:47 UTC, sighoya wrote:
On Tuesday, 3 October 2017 at 12:09:04 UTC, rikki cattermole
wrote:
On 03/10/2017 1:05 PM, sighoya wrote:
Especially, I mean something like
T foo(S,T)(T i)
{
   ...
}
struct Foo(T) {
T value;
}
T!S foo(S, alias T)(T!S v) { return v; }
void main() {
import std.stdio;
writeln(foo!(int, Foo)(Foo!int(1)));
}
Cool, but it seems that only a nesting of two is allowed, right?
This one gives an error:
T!S!R bar(alias T,alias S,R)(T!S!R v) {return v;}
Error: multiple ! arguments are not allowed
That is because you have to wrap multiple with ().
Use
T!(S!R)
instead.
Re: Alternatives to pointers?
On Saturday, 30 September 2017 at 08:27:26 UTC, Timon Gehr wrote:
On 29.09.2017 03:51, Jerry wrote:
I miss ref variables, for the simple fact that using the
square brackets with a ref variable doesn't access the
pointer. Don't know how many times I've accidentially used a
pointer as an array. Not very easy to catch especially if the
object has pointers to other objects of the same type.
Possibly adding something like this, if ref variables are off
the table?
@noarray int* value;
value[x] = 10; // compile error, pointer is not an array.
void main()@safe{
int x;
int* value;
value[x]=10;
}
Error: safe function 'D main' cannot index pointer 'value'
Need it in unsafe/trusted code though.
Re: Alternatives to pointers?
On Saturday, 30 September 2017 at 04:15:52 UTC, bitwise wrote:
On Friday, 29 September 2017 at 01:51:36 UTC, Jerry wrote:
[...]
Maybe this?
ref auto at(T : U[], U)(T arr, size_t index) {
return arr[index];
}
int main(string[] argv)
{
int* a = new int(1);
int[] b = [1];
int[1] c = [1];
a.at(0); // won't compile
b.at(0);
c.at(0);
reutnr 0;
}
That is interesting, it would mean not using "[]" or "[..]",
which would kind of suck.
Re: Alternatives to pointers?
On Friday, 29 September 2017 at 03:37:53 UTC, Jonathan M Davis wrote: On Friday, September 29, 2017 01:51:36 Jerry via Digitalmars-d wrote: I miss ref variables, for the simple fact that using the square brackets with a ref variable doesn't access the pointer. Don't know how many times I've accidentially used a pointer as an array. Not very easy to catch especially if the object has pointers to other objects of the same type. Possibly adding something like this, if ref variables are off the table? @noarray int* value; value[x] = 10; // compile error, pointer is not an array. You could always create a wrapper struct for the pointer and then not overload opIndex. - Jonathan M Davis Not the most ideal solution, doesn't work with several other features like auto.
Alternatives to pointers?
I miss ref variables, for the simple fact that using the square brackets with a ref variable doesn't access the pointer. Don't know how many times I've accidentially used a pointer as an array. Not very easy to catch especially if the object has pointers to other objects of the same type. Possibly adding something like this, if ref variables are off the table? @noarray int* value; value[x] = 10; // compile error, pointer is not an array.
Re: Custom Attributes for Function Parameters?
On Sunday, 24 September 2017 at 02:06:50 UTC, Jonathan Marler
wrote:
On Saturday, 23 September 2017 at 23:13:33 UTC, Jerry wrote:
Is there any reason why custom attributes aren't allowed for
function parameters? It'd be useful for my situation to give
the parameter some more information. Seems it is allowed in
some other languages that have attributes, so was just
wondering.
Can you share your use case for them? I'm curious how they
could be useful.
Well for me it's for functions I'm using in my scripting
language. Internally a lot of objects are simply represented as
indices into an array. For the scripting language though they
have their own type defined for them. So it'd be convenient to be
able to add that information into the function signature along
with the index.
void functionForScript(@(ScriptType.name) MyIndexType nameIndex,
@(ScriptType.object) MyIndexType objectIndex)
{
}
There are other ways to do it but they aren't as convenient. If I
just made it an attribute for the function, and manually declared
all the types. I'd have to maintain that when most of the other
types don't need extra data and can be determined just by the
type.
As well for other uses right now you can't pass a function or
delegate that is @nogc through to a function, without first
making it an alias. It's annoying if it's just one function that
needs it, now you need to give it a name somewhere else for a one
off.
I'm sure there's other uses as well. C++ has maybe_unused
attribute, though that doesn't really apply to D as it doesn't
really have any warning messages at all. Being able to put in
that extra information for use is nice, just like it is nice to
be able to attach them to structs and classes. Which is why I was
wondering why it wasn't included, even for special attributes
like @nogc.
Custom Attributes for Function Parameters?
Is there any reason why custom attributes aren't allowed for function parameters? It'd be useful for my situation to give the parameter some more information. Seems it is allowed in some other languages that have attributes, so was just wondering.
Re: scope(exit) and destructor prioity
On Monday, 18 September 2017 at 20:26:05 UTC, Sasszem wrote:
I'm currently working on a project and for that I've created a
thin OO-wrapper on top of derelict-sdl. However, when I close
my app, the program terminates with a segfault. I've managed to
track down the source, and found that the destructors of my
objects are called AFTER the scope(exit) statements. This
causes my program to call TTF_CloseFont() after TTF_Quit(),
resulting in a segfault.
My questions:
- Can I force D to call the destructors BEFORE the scope(exit)
statements?
- If not, is there a way around?
It's called inbetween the destructors of wherever you put the
scope(exit).
import std.stdio;
struct De
{
~this() { writeln("De"); }
}
void main()
{
De a;
scope(exit) writeln("scope exit");
De b;
}
Output:
De
scope exit
De
Re: Editor recommendations for new users.
On Wednesday, 30 August 2017 at 22:42:40 UTC, Moritz Maxeiner wrote: On Wednesday, 30 August 2017 at 21:30:44 UTC, Jerry wrote: On Sunday, 27 August 2017 at 18:08:52 UTC, Moritz Maxeiner wrote: The requirements are rather vague, you can interpret it in a number of ways. The sensible interpretation imho is "as low an install footprint as possible while still fulfilling the other requirements". I'm not aware of anything below ~20MB install footprint that fulfills the other requirements, but I'd be interested if you know any. The install requirement is arbitrary, and why 20MB? It just seems like you are trying to advertise that program for some reason. Because of the programs recommended until that post nothing was below that while meeting the other requirements (there were others in the same range, vim being one). The (later) DlangIDE recommendation, however, lowered that to about ~5MB (beating both my recommendation and vim in the process). It's one of the most useless requirements in that list though. The only reason people mention install size is to boast about it. I think he just didn't want to install something like Visual Studio which takes 10+ GB. I wouldn't consider 200MB gigantic in comparison to 20MB cause there is literally no difference of use for me. The thread is about OP's requirements. So replace me with anyone. You'd have to have a really shitty laptop for it to be an issue. Not relevant. It is relevant, shit, even with a shitty laptop you can upgrade the hdd and then it becomes a non-issue anyways. Your argument implicitly assumed a specific reason (albeit a generally sensible one) as to why low install size was a (must) requirement (physical storage limitations being only one possible reason; shared devices with fixed disk quotas or devices owned by the university with certain policies being other possibilities). That is why I didn't (and don't) think it as relevant to the specific point about being as low as possible I was making. Fancy way of agreeing with me, not sure what you are even going on about anymore if you agree.
Re: Editor recommendations for new users.
On Sunday, 27 August 2017 at 18:08:52 UTC, Moritz Maxeiner wrote: The requirements are rather vague, you can interpret it in a number of ways. The sensible interpretation imho is "as low an install footprint as possible while still fulfilling the other requirements". I'm not aware of anything below ~20MB install footprint that fulfills the other requirements, but I'd be interested if you know any. The install requirement is arbitrary, and why 20MB? It just seems like you are trying to advertise that program for some reason. I wouldn't consider 200MB gigantic in comparison to 20MB cause there is literally no difference of use for me. The thread is about OP's requirements. So replace me with anyone. You'd have to have a really shitty laptop for it to be an issue. Not relevant. It is relevant, shit, even with a shitty laptop you can upgrade the hdd and then it becomes a non-issue anyways.
Re: Editor recommendations for new users.
On Sunday, 27 August 2017 at 15:17:51 UTC, Moritz Maxeiner wrote: On Sunday, 27 August 2017 at 13:15:41 UTC, Ryion wrote: On Sunday, 27 August 2017 at 10:05:29 UTC, Nicholas Wilson wrote: The following are a must: no large install footprint Visual Studio Code seems to be what you need. [...] Relative low memory footprint for the functionality ( compared to several IDEs that do the same ). [...] The (must) requirement was install footprint, not memory footprint, and as Visual Studio code uses the electron framework[1] its install footprint is gigantic (about 180MB vs e.g. TextAdept's 20MB). It isn't that gigantic in comparison. You can say the same thing in comparison with vim which is only a 2MB install size, 20MB in comparison is gigantic. The requirements are rather vague, you can interpret it in a number of ways. I wouldn't consider 200MB gigantic in comparison to 20MB cause there is literally no difference of use for me. You'd have to have a really shitty laptop for it to be an issue.
Re: How to implement Timeout function
On Sunday, 27 August 2017 at 15:56:14 UTC, Saigon wrote: Hi, Can I have Timeout function like this one [1] in Ruby? I want to check if a TCP service is running, and the check would return error if timeout occurs. Thanks a lot [1] https://github.com/ruby/ruby/blob/trunk/lib/timeout.rb Can it be blocking?
Re: Future of export
Export was being implemented as an attribute last I saw of it, by the guy that made that DIP. Looks like he last worked on it some time in July. https://github.com/Ingrater/dmd/commits/DllSupportD2
Re: jai-like CTFE string formating
On Sunday, 13 August 2017 at 19:51:31 UTC, Stefan Koch wrote: On Sunday, 13 August 2017 at 19:47:37 UTC, Jerry wrote: Seems like it'd be a good idea to pre compute all of phobos for compile time computations, as they should be changing. That would drastically reduce using any of phobos for compile time computation. You cannot do that. The point of template code is that the user can change it from the outside. There is no way to precompute the reaction to things that are yet to be realized. The way compile time is saved here is by limiting the flexibility. There are ways to do it, not having to parse the code would make it faster on its own. Compiling 500 source files individually that starts and stops DMD is drastically slower than putting the 500 source files together and running DMD once. The tests that are run for DMD for example could be made to run much faster.
Re: jai-like CTFE string formating
Seems like it'd be a good idea to pre compute all of phobos for compile time computations, as they should be changing. That would drastically reduce using any of phobos for compile time computation.
Re: KissRPC for dlang ver release.(Ultra high performance RPC)
On Wednesday, 9 August 2017 at 09:23:38 UTC, jasonsalex wrote: kiss-rpc-flatbuffer features: Lightweight and easy to use. There are two ways to support IDL and manually write protocols. Analog function call, more in line with the RPC remote call logic, simple, transparent. Easy to change, easy to use, existing code can be used directly The data format supports downward compatibility and uses the flatbuffer protocol, with better compatibility and faster speed. Really interesting! Only great Cassandra support left for me to rewrite my game server to :D.
Re: KissRPC for dlang ver release.(Ultra high performance RPC)
Really interesting! Only great Cassandra support left for me to rewrite my game server to :D.
Re: Problem with integral promotions
On Saturday, 22 July 2017 at 10:51:05 UTC, ketmar wrote: Walter Bright wrote: 2. Codify existing practice, since it has been that way forever. Not matching C has caused problems, see 16997 and 17637. It may cause more serious silent problems for people converting C code to D code. i'd say "codify, and add warning". since i patched the warning into the compiler, i have no more problems with the current rules: compiler tells me about possible incompatibilities with C, and i can either add `()` to silent the warning, or explicitly cast to the type i want. i think most other people will prefer to get warning instead of code breakage too. at least i hope so. ;-) Good luck adding a warning into DMD. After years there still isn't a warning for unsigned/signed comparisons. What code would break? Are there any examples of D code that would break as a result of the change?
Re: VSCode plugins
On Thursday, 6 July 2017 at 16:23:06 UTC, WebFreak001 wrote: While this isn't such a big problem for me because most code was already in workspace-d, How much is actually there though? Going by lines of code, dlang-vscode is a total of ~2000 lines of code *less* than code-d. That's not including workspace-d lines of code for code-d as well. So it can provide the same features in far fewer lines and with a less complex system. Having an extra process just isn't worth it the abstraction you get cause it is so minimal. I wouldn't be trying to abstract it even further, you are just over complicating something for no reason. Keep it simple.
Re: VSCode plugins
On Tuesday, 4 July 2017 at 06:26:52 UTC, Manu wrote: On 4 July 2017 at 14:59, bauss via Digitalmars-d < digitalmars-d@puremagic.com> wrote: On Tuesday, 4 July 2017 at 04:49:29 UTC, Manu wrote: If authors of both plugins are active here, I ask; why have 2 separate The same reason there are multiple editors. Errr. No. I don't think you can make an argument that one plugin performs in a way that conforms to some peoples taste more than others... they do exactly the same things, and even in the same way using the same tooling. There might be implementation quality differences, I don't know, but that leads to the conclusion that merging them would produce the best quality result. Personally I use dlang-vscode because it doesn't tak on an extra process used for communication. I can understand wanting to put common code into one location so that multiple editors can reuse it, but ultimately you end up writing the same code for the editors anyways. Just now instead of communicating with DCD/DScanner/etc it is doing the same thing just communicating with this new process now. It's also really buggy and you don't get any information when something goes wrong. When it does go wrong in code-d, the workspace-d crashes and you now lose access to every feature. Where as in dlang-vscode if something goes wrong with DCD you still have access to features covered by the other processes. So they are different, and I do have my preference after using both of them.
Re: C++ binding issues with C++ function returning a simple POD struct.
On Sunday, 21 May 2017 at 19:58:32 UTC, Stefan Koch wrote: On Sunday, 21 May 2017 at 19:33:06 UTC, ParticlePeter wrote: I am statically linking to ImGui [1] on Win 10 x64, quite successfully till this issue came up. The noticed error so far comes when an ImGui function returns an ImVec2, a simple POD struct of two float members. I can use this struct as argument to functions but when it is returned from a function I get a 0xC005: Access violation reading location 0x. I can even debug the process with Visual Studion, mixed d and c++ sources. The functions I tested return data from some internal global ImGui data, which I can fully examine, the crash happens on the return statement. Moreover, some functions have variations which return only one component from that ImVec2 POD, which do work as expected, e.g.: [...] are you aware of https://github.com/Extrawurst/DerelictImgui ? Not everyone likes the set of 'derelict' libraries. Especially if you need to statically link to a library.
Re: C++ binding issues with C++ function returning a simple POD struct.
Note that you also probably need extern(C++) on the struct ImVec2. https://github.com/ParticlePeter/imgui_lib/blob/master/source/imgui/types.d#L84
Re: C++ binding issues with C++ function returning a simple POD struct.
On Sunday, 21 May 2017 at 19:33:06 UTC, ParticlePeter wrote: I am statically linking to ImGui [1] on Win 10 x64, quite successfully till this issue came up. The noticed error so far comes when an ImGui function returns an ImVec2, a simple POD struct of two float members. I can use this struct as argument to functions but when it is returned from a function I get a 0xC005: Access violation reading location 0x. I can even debug the process with Visual Studion, mixed d and c++ sources. The functions I tested return data from some internal global ImGui data, which I can fully examine, the crash happens on the return statement. Moreover, some functions have variations which return only one component from that ImVec2 POD, which do work as expected, e.g.: ImVec2 GetCursorPos(); // crash float GetCursorPosX(); // works float GetCursorPosY(); // works The latter do basically the same as the first one, but return ImVec.x or .y respectively. How could I further debug this? If somebody would be willing to look at the source, the binding is here [2]. [1] https://github.com/ocornut/imgui [2] https://github.com/ParticlePeter/imgui_lib IIRC the problem is that it isn't a POD type. ImVec2 has its own default constructor. The problem now is that because it no longer is POD, Window's ABI handles it different and doesn't put the value in a register. Now with D is that you aren't allowed to specify your own default constructor, so there's no equivalent way for it to know that it isn't a POD. A way around this is to specify your own destructor or copy constructor in the D ImVec2. I forget what the rules are for it, but I think that should do it.
Re: Atomicity of file-copying/moving
On Tuesday, 16 May 2017 at 08:32:56 UTC, Nordlöw wrote: What's the status of atomicity of file-copying and -moving (renaming) using std.file on different platforms? Niall has a good talk about this on youtube: https://www.youtube.com/watch?v=uhRWMGBjlO8
Re: simple ABI change to enable implicit conversion of functions to delegates?
My understanding is that we want to pass functions to functions which takes delegates transparently, or is it something more involved here? Anyway if that is everything, then why not add a template to the D runtime which casts the function to a delegate? And if that wrapper function is only called by the compiler it does not even have to be a template. Templetation just provides type safety in this case.
Re: What are we going to do about mobile?
On Thursday, 6 April 2017 at 05:24:07 UTC, Joakim wrote: That means this tidal wave of mobile swamping PCs is only going to get worse: https://twitter.com/lukew/status/842397687420923904 D is currently built and optimized for that dying PC platform. There are only two devs working on mobile, Dan and me, I don't think anybody on the core team has even tried our work. "dying". Just cause there aren't a lot of new devices being sold doesn't mean it is dying. There's the used market to consider, and PCs have a long lifespan. I have a 7 year old desktop that still runs perfectly fine and does all the tasks and computing I need to be done. I'll probably be using it for another few years, maybe when zen+ comes out or there's actually a reason to buy a new computer. Even then I won't be buying a prebuilt, not sure if those sales figures includes sales of PC parts. Even though new PC sales are declining, GPU sales are seeing a major increase in sales.
Re: Fantastic exchange from DConf
Anything that goes on the internet already has memory safety. The things that need it aren't written in C, there's a lot of programs out there that just don't require it. C won't be killed, there's too much already written in it. Sure there might be nothing new getting written in it but there will still be tons of software that needs to be maintained even if nothing new is being written in it. D also won't be that far behind it if that's truly the reason C gets 'killed'. Anyways can't watch the discussion as it's private.
Re: alias can't find symbol or can't use symbol
To me this seems like a bug.
Re: Garbage Collector?
On Thursday, 27 April 2017 at 17:31:42 UTC, bachmeier wrote: On Thursday, 27 April 2017 at 15:50:56 UTC, Ben wrote: A few days ago i was reading this topic: https://news.ycombinator.com/item?id=14165198 And the whole GC keeps coming up as a negative ( compared to Rust ). From my understanding there has been a proposal DIP1000 to address this issue. Is there any update on this topic? Is it possible to run D without the GC AND the standard library? There is opposition to the GC from a small but vocal group of mostly C++ developers. Sometimes they even make valid arguments. You can find many threads on the topic here. Citation needed.
Re: Thoughts from newcommer
On Monday, 17 April 2017 at 22:44:52 UTC, Stanislav Blinov wrote: On Monday, 17 April 2017 at 21:20:42 UTC, Jerry wrote: So what happens when the resource outlives the object's lifetime. Then RAII rule is violated. That's exactly what is happening when you are using the garbage collector. Correction, that is what *may* happen in some cases when you are using GC. Not may, will definitely happen. Even if the destructor is called the memory is freed, alas the resource isn't freed and is freed at a later time when the object is destroyed. And as your above statement says, this violates the RAII rule. That's exactly the case with the containers in phobos. So calling them RAII container is just incorrect. I never said they were. Then why are you arguing for Jack.. My argument was, from the start, that assessing the *language* RAII capability has nothing to do with *library* containers or the (lack of) use of @nogc attribute. I never replied to you, you replied to me an my argument. I never said RAII capability has anything to do with, go back and read the comments and user names. You are confusing me for someone else it seems.
Re: Thoughts from newcommer
On Monday, 17 April 2017 at 16:06:20 UTC, Stanislav Blinov wrote: On Monday, 17 April 2017 at 15:24:26 UTC, Jerry wrote: It has everything to do with @nogc, if it isn't @nogc then it is using the garbage collector and even if it is using Destroy() it is still invoking the GC and something is still going to have to be freed by the GC, even if that class is empty. You can't say it is RAII if it is using the GC, that's just nonsense. So it is not just for convenience. On the contrary. All RAII does is establish a relation between resource lifetime and another resource's (e.g. object's) lifetime. It doesn't necessarily have to be limited to any particular scope. So what happens when the resource outlives the object's lifetime. That's exactly what is happening when you are using the garbage collector. That's exactly the case with the containers in phobos. So calling them RAII container is just incorrect. You are using two techniques that do the same thing. Call it pure RAII containers if you want, for containers that only use RAII and the current implementation that is GC'd RAII/deterministic destructor containers. Not to mention for some reason Array's internal implementation is ref counted. If you want ref counted arrays you should do RefCounted!(Array!T). Std.containers is just a giant mess. The "some reason" is mutable slices. Not really, slices aren't included in the ref counting. So if the array object is detroyed, the slices are no longer valid. You have to deal with the same issue, with or without ref counting. You manually have to ensure the array outlives the slice, and that the slices aren't invalidated by an operation like resize. I feel like if your solution is, don't use Phobo's containers here use this person's that isn't updating it anymore of questionable quality. Then I feel like you are agreeing with me that phobos containers suck. Oh and it looks like hackerpilot is responsible for merging pull request, lovely. Yes, std.container does need quite a bit of love. That doesn't mean that D doesn't have RAII or that it's RAII support is somehow deficient. I was never arguing that it didn't. Jack said it had RAII containers, which it doesn't. The standard library containers are shiat.
Re: refRange with non copyable struct
On Monday, 17 April 2017 at 18:07:36 UTC, Jonathan M Davis wrote: In this particular case, it looks like the main problem is RefRange's opAssign. For it to work, the type needs to be copyable. It might be reasonable for RefRange to be enhanced so that it doesn't compile in opAssign if the range isn't copyable, but I'd have to study RefRange in depth to know what the exact consequences of that would be, since it's been quite a while since I did anything with it. My guess is that such a change would be reasonable, but I don't know without studying it. - Jonathan M Davis I took a look on RefRange and the reasoning is clearly explained in the docs like this: This does not assign the pointer of $(D rhs) to this $(D RefRange). Rather it assigns the range pointed to by $(D rhs) to the range pointed to by this $(D RefRange). This is because $(I any) operation on a RefRange) is the same is if it occurred to the original range. The exception is when a $(D RefRange) is assigned $(D null) either or because $(D rhs) is $(D null). In that case, $(D RefRange) longer refers to the original range but is $(D null). But what I do not understand is why this is important.
Re: refRange with non copyable struct
On Monday, 17 April 2017 at 18:07:36 UTC, Jonathan M Davis wrote: Non-copyable types tend to wreak havoc with things - Jonathan M Davis Basicly what I use this for is to combine RAII with ranges. Which I find quite useful when doing DB queries and the data is lazily fetched since this allows me to guarantee that the query is "closed" and another query can take place.
refRange with non copyable struct
Hello guys, so I wanted to have a noncopyable range on the stack.
So my thoughts was to make it non copyable and use refRange
whenever I want to use it with map and others.
But I got a compiler warning when doing so like this:
import std.range;
void main() {
NonCopyable v;
refRange();
}
struct NonCopyable
{
@disable this(this);
int data;
enum empty = false;
void popFront() {}
int front() { return data; }
}
With the error message:
C:\D\dmd2\windows\bin\..\..\src\phobos\std\range\package.d(8941):
Error: struct reproduction.NonCopyable is not copyable because it
is annotated with @disable
C:\D\dmd2\windows\bin\..\..\src\phobos\std\range\package.d(8982):
Error: mutable method reproduction.NonCopyable.front is not
callable using a const object
C:\D\dmd2\windows\bin\..\..\src\phobos\std\range\package.d(9649):
Error: template instance std.range.RefRange!(NonCopyable) error
instantiating
reproduction.d(6):instantiated from here:
refRange!(NonCopyable)
Is there any workaround?
Is this a bug?
Re: Thoughts from newcommer
On Monday, 17 April 2017 at 15:10:59 UTC, Jack Stouffer wrote: On Monday, 17 April 2017 at 02:56:00 UTC, Jerry wrote: Okay, only one container, and happens to be most simple basic one. The others aren't nogc and some of them are even classes. Not only that, Array wasn't @nogc until about a month ago. No idea what you mean about goal posts. Do you mean it's not an issue worth discussing? You made a false claim, and you still you are still persisting in it as if having a single container be @nogc solves the entire issue. The first question was whether D had RAII or not. When it was shown that D does have RAII, then the goal posts were moved back to D needing RAII containers that cleaned up their elements on scope exit. When it was shown that D absolutely has RAII containers (that clean up all resources including GC ones on scope exit) then the goal posts were moved back yet again to the containers needed to be @nogc containers. This is despite the fact that @nogc has nothing to do with RAII and is just something people want for convenience. It has everything to do with @nogc, if it isn't @nogc then it is using the garbage collector and even if it is using Destroy() it is still invoking the GC and something is still going to have to be freed by the GC, even if that class is empty. You can't say it is RAII if it is using the GC, that's just nonsense. So it is not just for convenience. Not to mention for some reason Array's internal implementation is ref counted. If you want ref counted arrays you should do RefCounted!(Array!T). Std.containers is just a giant mess. I wasn't part of the other discussion, what the hell is the point of having a discussion if you can't change the subject. We are now nowhere near the original topic. I'll cut this off at the knees and say If you want @nogc RAII containers that work with std.allocator then just use https://github.com/economicmodeling/containers I feel like if your solution is, don't use Phobo's containers here use this person's that isn't updating it anymore of questionable quality. Then I feel like you are agreeing with me that phobos containers suck. Oh and it looks like hackerpilot is responsible for merging pull request, lovely.
Re: Thoughts from newcommer
On Sunday, 16 April 2017 at 22:18:51 UTC, Jack Stouffer wrote:
On Sunday, 16 April 2017 at 18:36:30 UTC, Jerry wrote:
I wouldn't really call them RAII containers if they aren't
@nogc
Moving the goal posts again. Even still,
void main() @nogc
{
Array!int ai;
ai ~= 1;
assert(ai.front == 1);
ai.reserve(10);
assert(ai.capacity == 10);
static immutable arr = [1, 2, 3];
ai.insertBack(arr);
}
Okay, only one container, and happens to be most simple basic
one. The others aren't nogc and some of them are even classes.
Not only that, Array wasn't @nogc until about a month ago.
No idea what you mean about goal posts. Do you mean it's not an
issue worth discussing? You made a false claim, and you still you
are still persisting in it as if having a single container be
@nogc solves the entire issue.
Re: Thoughts from newcommer
On Sunday, 16 April 2017 at 17:00:25 UTC, Jack Stouffer wrote: Semantic game. D actually has RAII. And D does have RAII containers: https://dlang.org/phobos/std_container.html I wouldn't really call them RAII containers if they aren't @nogc, and especially so if they aren't structs but classes. The container module needs a good rewriting, SList/DList are the most useless POS containers without some concept of iterators.
Re: Update roll-up on my arsd libraries
You have mixed spaces and tabs, not in the good way either. https://github.com/adamdruppe/arsd/blob/master/simpledisplay.d#L3642
Re: Proposal: Exceptions and @nogc
What would happen if the exception gets assigned to a global/TLS variable in a catch block. It would be copied to the GC heap?
Re: const(Class) is mangled as Class const* const
On Sunday, 26 March 2017 at 22:29:56 UTC, deadalnix wrote: It is clear that you won't be able to express 100% of C++ in D, that would require to important all the weird parts of C++ into D, but if we are doing so, why use D in the first place ? Note that using const Class* in C++ is essentially useless. The class remains mutable and the reference is local the the callee anyway, so it doesn't change anything for the caller. Such a pattern is most likely indicative of a bug on the C++ side, or at least of code that do not do what the author intend to. For `const Class*` the Class is not mutable. It is the case of `Class* const` that Class is mutable. I see a lot of people in D say similar things about it. Saying it is a bug, saying it's a good thing that a const pointer with mutable type isn't in D. Yet they always tend to be the people that have never actually used C++. As is indicative of not even knowing the correct syntax to use in C++. A common matter in C++ is to use templates, you may have seen it, it's a really common pattern, `const T&`. The magic that makes this work is that you read it like this: `T const &`. They both mean the samething but I find makes more sense, conceptually to read it like that. Now substitute a type for T, `int* const &`. You see here that int is mutable for this template. You can see my other post about cmp(), and how Phobos avoids usages of const as it just makes writing generic code difficult.
Re: const(Class) is mangled as Class const* const
On Sunday, 26 March 2017 at 15:29:02 UTC, Jonathan M Davis wrote: Personally, I don't think that the fact that you can't use const for head-const in D is really a loss, since it's almost never what you want. Tail-const is _way_ more useful. But it is true that by making D's const fully transitive, there are variations of constness that C++ can do that D can't. immutable pretty much forces that though, and it does simplify the language. There are quite a few things wrong with const, it's so bad phobos isn't even const-correct when it should be. In cmp() for example, if you pass a lambda that takes the parameters by reference. You will be modifying temporary values that cmp() created on the stack. These should be const, but then what if it is a pointer? It is a different situation and you don't really want const cause you are going to be modifying the correct struct (the one pointed to). It is just easier to not use const in D cause it makes your code more difficult to actually use. That's exactly what Phobos does, it ignores const for the most part because it is easier not to use it.
Re: List Comprehension equivalent
On Friday, 17 March 2017 at 17:13:48 UTC, Russel Winder wrote:
I have a bit of code:
string[] returnValue;
foreach(string key, string[] value; groups) {
returnValue ~=
value.sort!debianPackageNumberComparator()[0..$-1].array;
}
return returnValue;
[...]
You forgot a ! on the map call.
.map!((Tuple!(string, string[]) a) =>
a[1].sort!debianPackageNumberComparator()[0..$-1])
Re: Zcoin implementation bug enabled attacker to create 548, 000 Zcoins
On Sunday, 12 March 2017 at 17:33:23 UTC, Jack Stouffer wrote: On Sunday, 12 March 2017 at 08:03:46 UTC, Jerry wrote: What about Ketmar's example? It seems to have been glossed over. It wasn't. It was (by walter). Don't hold your breath. The fix has been approved, but the compiler devs are all working on other things. I don't expect anything less than nothing.
Re: Template specialisation for range of types
On Sunday, 12 March 2017 at 18:49:22 UTC, data pulverizer wrote:
Hello all,
I am attempting to write templates for differently qualified
types using specialisations. Below is an example for const and
non-const outlining my approach:
``
import std.stdio : writeln;
import std.traits : ConstOf;
auto max(T)(T x, T y)
{
writeln("General template");
return x > y ? x : y;
}
auto max(T: ConstOf!U, U)(T* x, T* y)
{
writeln("Const template");
return *x > *y ? x : y;
}
void main(){
const double p = 2.4, q = 3;
writeln(max(, ));
}
``
I get this output:
General template
7FFE5B3759A8
In this case would like to use the ConstOf specialisation
instead of the default implementation for the inputs which are
const.
Thanks for you answers in advance
Wouldn't just putting const infront work?
Re: Zcoin implementation bug enabled attacker to create 548, 000 Zcoins
On Tuesday, 7 March 2017 at 21:34:35 UTC, Walter Bright wrote: On 3/7/2017 9:45 AM, Atila Neves wrote: 1 warning generated. Pretty much all C++ compilers will generate warnings for this. The thing about warnings, though, is they imply that there are situations where the code is acceptable. I can't think of any. It needs to be an error. It should never pass the compiler. What about Ketmar's example? It seems to have been glossed over. Still waiting on D to do something about comparisons between signed and unsigned types, or is having no warning or error the desired behavior?
Re: DMD + Dynamic Library.
You have to use "export" for any symbol to be visible from a dll. On Windows by default nothing is exported.
Re: If you needed any more evidence that memory safety is the future...
On Friday, 24 February 2017 at 14:35:44 UTC, Jack Stouffer wrote: Why is it that test CIs catch bugs when people should be running tests locally? CI tests all platforms, not just the one a user is on. It does it simultaneously as well. In the case of something like DMD, it's a pain in the ass to setup and run. There's no documentation on how to do it either. I think LDC's wiki has some information on how it needs to be setup but it's a bit different as they are providing information on how to run the tests the way LDC has them setup. Which is different to how it is done in DMD.
Re: Debugging D applications from VS code with webfreak.debug
You can use the C++ plugin, which provides a debugger. Just make sure you aren't using optlink, I don't think it generates compatible files. Also you might need to use "-gc" which generates debug names to be in C format. https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools You might also need to enable breakpoints anywhere in VS code user setting file.
Re: Threads not garbage collected ?
Not really by design so much as you can't really guarantee destruction because it is garbage collected. You can use a struct instead or scoped (https://dlang.org/library/std/typecons/scoped.html).
Re: opApply with Type Inference and Templates?
On Thursday, 16 February 2017 at 04:09:18 UTC, Basile B. wrote: No, by any chance do you ask this for the tuple unpacking PR ? If so I've also tried and failed. Was just trying to use a container I created in functions with and without @nogc/nothrow.
opApply with Type Inference and Templates?
I am trying to do opApply to work when the delegate passed when it is and isn't nogc/nothrow. As soon as you involve a template though, type inference goes out the door. I want to be able to use opApply with templates (to get the auto @nogc/nothrow deducation passed on the delegate passed) but still be able to use type inference. Is there any way to do this?
