Re: Binary Literals Not Going Anywhere
On Monday, 26 September 2022 at 06:19:05 UTC, Max Samukha wrote: Please do not take the backlash against the removal of binary literals as general aversion to breaking changes/deprecations. D has plenty to remove/deprecate (and it is NOT `alias this`, unless that is replaced with a more general mechanism, such as `using` in Jai). +1 on Jai's `using` feature! `alias this` should definitely be more appreciated.
Re: Comping a Musl-linked druntime & phobos?
On Thursday, 25 August 2022 at 01:52:15 UTC, Mathias LANG wrote: (snip) Hmmm... Maybe I don't understand. What exactly *is* Alpine Linux doing? That .patch file didn't contain anything substantial. It looks like it has some version of LDC on hand to use, probably already set up properly to use Musl. You're saying that you shouldn't need to pass in `-target` because if the compiler was compiled with `CRuntime_Musl`, it will just use that automatically. But that requires exactly what I don't have: a compiler that uses Musl. Am I missing something?
Comping a Musl-linked druntime & phobos?
Hi, all. Has anyone had any success compiling a Musl-linked druntime and phobos? I haven't had any luck so far. I'm running Linux Mint x64. Somewhat related - using `-target=x86_64-linux-musl` with dmd master doesn't even set the version `CRuntime_Musl`. I asked about this in the Discord, and I was told by Horo: dmd 2.096 worked well for me. Same for gdc, haven't tried ldc. There is/was a bug that was introduced recently in druntime that broke musl but the older versions should work fine 2.096 doesn't have the `-target` option, and 2.097.0-2.098.0 don't even build properly for me. Using LDC to build works of course, but only with `-betterC` (i.e. no druntime/phobos).
Re: dlang vs crystal-language
On Friday, 30 April 2021 at 14:16:16 UTC, Vinod K Chandran wrote: On Wednesday, 28 April 2021 at 22:41:03 UTC, Alain De Vos wrote: What are the strengths and weaknesses comparing the two languages ? I can name a strength of dlang is the working binding to tk and gtk. Pros of **Crystal** 1. Attractive syntax. I like Ruby like syntax. It's really expressive. Cons of Crystal 1. It doesn't have a compiler for Windows. It uses WSL based compiler and I think it's a bad idea. I don't think I need to tell the pros & cons of **D lang** in it's own forum. BTW, I wonder to see someone says that they have succeeded in compiling a **tkD** example code. I tried it with no luck. So I gave up that idea. I used tkD a long time ago. Look through [this repo](https://github.com/thegag96/codewrite) - maybe something in there will help you.
Re: Idioms for the D programming language
On Friday, 12 February 2021 at 11:19:26 UTC, Guillaume Piolat wrote: On Friday, 12 February 2021 at 00:26:09 UTC, H. S. Teoh wrote: On Thu, Feb 11, 2021 at 12:12:36PM -0800, Walter Bright via Digitalmars-d-announce wrote: [...] https://p0nce.github.io/d-idioms/ Not bad, but it seems to be missing some of the newer idioms. It's because I lack the time to update it. It was always a page to let _me_ understand the language better, and then I got to a point where I wasn't following the D development enough. I'd love if you'd pick up again. Years ago, when it was a bit more active, I'd check it all the time. I've learned a lot from the page. Thanks for all your work on it!
Re: What kind of Editor, IDE you are using and which one do you like for D language?
On Sunday, 22 December 2019 at 17:20:51 UTC, BoQsc wrote: There are lots of editors/IDE's that support D language: https://wiki.dlang.org/Editors What kind of editor/IDE are you using and which one do you like the most? I've loved Sublime for years. I use it for everything, really. So pretty, so fast.
Re: D code running on the Nintendo 3DS
On Monday, 21 October 2019 at 19:03:00 UTC, Iain Buclaw wrote: (snip) Yeah, I just learned you could do this not long after I posted - when I tried, I had a gdc from around the time of 9.0.1 instead of 9.2, so I just had to rebuild. I'm currently attempting to get a devkitARM based off of 9.2 going since I thought it'd be simple - that may go a long way to making no-runtime/betterC work better!
Re: D code running on the Nintendo 3DS
On Sunday, 20 October 2019 at 20:31:04 UTC, Johan wrote:
(snip)
Awesome, I just might try to get LDC working with this...
On a different note, I'd really like a critique on a decision I
made. Creating the bindings for libctru and citro3d was really
tedious, partly because I made the decision to change every named
enum from stuff like...
enum GPU_TEXTURE_WRAP_PARAM
{
GPU_CLAMP_TO_EDGE = 0x0, ///< Clamps to edge.
GPU_CLAMP_TO_BORDER = 0x1, ///< Clamps to border.
GPU_REPEAT = 0x2, ///< Repeats texture.
GPU_MIRRORED_REPEAT = 0x3, ///< Repeats with mirrored texture.
}
...to...
enum GPUTextureWrapParam
{
clamp_to_edge = 0x0, ///< Clamps to edge.
clamp_to_border = 0x1, ///< Clamps to border.
repeat = 0x2, ///< Repeats texture.
mirrored_repeat = 0x3 ///< Repeats with mirrored texture.
}
...in order to fit the D naming style, since the semantics for
the enum was changing anyway. But of course, every struct must
keep its old name... Is this alright? Should I add aliases for
every struct for a better naming style, or maybe go back on my
decision before, or...?
Re: D code running on the Nintendo 3DS
On Sunday, 20 October 2019 at 17:40:04 UTC, Meta wrote: Awesome work. I used to hack around on my original NDS and thought about maybe trying to get D working on it, but didn't have sufficient time or motivation. I'll definitely play around with this. Last year I was able to get some C very simple code running on the DS, hacked into Pokemon Platinum... I imagine it could be done with -betterC, I guess! Following this tutorial might do a good chunk of the work to setting it up. You'd just need to copy similar stuff I did in 3ds_rules and my (horrific) Makefile in nds_rules. You could get by converting an example DS hello world and declaring any functions/structs needed in your main file as a start.
Re: D code running on the Nintendo 3DS
On Sunday, 20 October 2019 at 15:27:35 UTC, Iain Buclaw wrote:
Great stuff! Though I don't think you'll find much improvement
in gdc 10 regarding switching off D features. Backported
patches to make gdc on parity with dmd as of April 2019 was
done prior to the gdc 9 release. I'm not aware of much more
being done regarding that other than some extern(C) library
functions being converted into templates, and the C main
function being moved to a common location in D runtime (C main
is not "compiled into" gdc unlike previous versions of dmd).
Darn... Are there any plans at some point in the future to add a
real -betterC sort of flag? It would be really really nice to be
able to compile something like...
import std.bitmanip : bitfields;
struct Stuff {
mixin(bitfields!(
uint, "x",2,
int, "y",3,
uint, "z",2,
bool, "flag", 1));
}
extern(C) void main() {
Stuff x;
}
...just as in DMD or LDC.
Re: D code running on the Nintendo 3DS
On Sunday, 20 October 2019 at 09:36:17 UTC, Johan Engelen wrote: Did you try with LDC? Just a wild guess but perhaps this triple will work: `-mtriple=armv6k-unknown-eabi`. -Johan I haven't yet, but I've been told also by someone else to try! It would certainly be nice to have a true -betterC going with this. Does LDC have equivalent flags for what devkitARM wants passed into GCC, like: -march=armv6k -mtune=mpcore -mfloat-abi=hard -mtp=soft -mword-relocations -fomit-frame-pointer -ffunction-sections ?
D code running on the Nintendo 3DS
Hi, all. I wanted to get into the world of 3DS homebrew, but I really didn't feel like coding in C or C++. So, through an effort of sheer will, I somehow got a hello world example written in D up and running, along with bindings for most of libctru and citro3d. https://github.com/TheGag96/3ds-hello-dlang Included are instructions on how to set this up (although it's pretty hacky). I imagine one could easily start writing Switch homebrew in D by following most of these steps as well. Once GCC 10 comes out with an updated GDC, it might become a pretty attractive alternative to C/++ for such projects if some work is put into bindings and stuff. Hope someone finds this interesting!
Details of the inline import idiom
I was looking back at the inline import idiom article[1]. One of the purported benefits of doing something like from!"std.datetime".SysTime was that doing so wouldn't go and import the entirety of the module into the namespace and slow down compile time / bloat the binary. But how is this so? When the template ends up doing import from = std.datetime, doesn't that go and import everything, not just SysTime? Or is there some detail I'm missing? Thanks! [1]: https://dlang.org/blog/2017/02/13/a-new-import-idiom/
Is DWT busted?
I'm sorry about bringing this into here instead of DWT's subforum, but it's somewhat dead and hasn't been getting a lot of attention. I decided to finally play around with DWT today and tried to build the example. I got this: Performing "debug" build using /usr/bin/dmd for x86_64. dwt:base 1.0.1+swt-3.4.1: target for configuration "library" is up to date. dwt 1.0.1+swt-3.4.1: target for configuration "linux-gtk" is up to date. main ~master: building configuration "application"... Linking... To force a rebuild of up-to-date targets, run again with --force. Running ./main Program exited with code -11 I'm on Pop!_OS (basically Ubuntu), x64, DMD 2.079.0. Every library they ask for is installed. I tried cloning the source and building their snippets, and none of them work. Other people have apparently had this same problem for the past few months, and none of them find a solution. What's going on here? IDK if this is any help, but here's the backtrace according to gdb: https://pastebin.com/Xd46YwwP
Re: sumtype 0.3.0
On Sunday, 6 May 2018 at 19:18:02 UTC, Paul Backus wrote: snip Wow.. without comments and unittests, the implementation is only 116 lines. Awesome job. Even now I still find it incredible what D can do. Is Algebraic in the standard library really that bad? And if so, why aren't implementations like this being accepted?
Re: Favorite GUI library?
On Tuesday, 24 April 2018 at 14:30:07 UTC, Thomas Brix Larsen wrote: I'd recommend dqml[1] or full Qt using Calypso[2] instead of QtE5. I'm currently using dqml in a project and it is working out great. Awesome, thank you! I'll keep that in mind! On Tuesday, 24 April 2018 at 13:08:24 UTC, Chris wrote: In my experience, if you stick to plain JS+CSS+HTML things don't break that often. ...If you can get things written in the first place. Over the summer I interned at a place where they taught me how to write a web app, and I very quickly learned that unless you're using TypeScript or something, it's nearly impossible to write clean, well-structured JavaScript code, just by the nature of language itself. And even then it's still kinda gross. My whole point with what I said earlier was that there's no reason to be greedy about resources for your app unless it's specifically needed. If you're trying to deploy on every imaginable platform, I could absolutely see the benefit of being able to develop one app for all of them at once through the web - but that's even assuming there's no major quirks/concerns between all browsers. Uknown's point about Moore's Law, I think, is the one we should be paying attention to. A while back, I saw a talk by Jonathan Blow called "Making Game Programming Less Terrible"[1], and lately it's been on my mind a ton. I've begun to think that by going straight to web/Node stuff is just contributing to the degeneration of software/computing. Things are so much slower than they should be nowadays because programmers either A) didn't know any better how to write software that's as snappy as it should be, or B) wanted to make things easier/cheaper for themselves. A bit off-topic I suppose lol, but I hope this kind of outlines why I follow D so much in the first place and why I want something lightweight but workable if I can find it. [1] https://www.youtube.com/watch?v=gWv_vUgbmug
Re: Favorite GUI library?
On Monday, 23 April 2018 at 11:26:30 UTC, Chris wrote: On Monday, 23 April 2018 at 09:50:21 UTC, Zoadian wrote: i'm happy with: vibe.d + CEF + vue.js Good point. I've been thinking about vibe.d + HTML/JS based UIs too. I think that's where UIs are increasingly moving towards: HTML+CSS + some sort of web-based backends. That's definitely what I'm trying to avoid... I feel those kinds of interfaces are 99% of the time mega bloated for what they are. Discord is the only one that seemed big enough for the britches of an entire browser instance. Absolutely not a fan of Electron and the like. I have never tried dwt! I should give that a shot. And I was trying gtkd once, and I should probably try again. Back then, I had to compile with --build=plain due to some weird linker issues.
Favorite GUI library?
Heya guys. For my projects that use a GUI library, I've tried both tkd and DlangUI. Both I feel have their drawbacks, and I'd like to know if any of you are using anything you find better. In my case, my ideal choice would be: - Nice bindings/API, friendly to idiomatic D - Cross platform - Can compile to a standalone binary (no shared libraries or extra files) - Reasonably efficient - Support for a good amount of well-working widgets Although quite a cool library, my biggest issue with DlangUI was that it was a little mind-bending at times to keep track of multiple widgets that view/modify the same data without screwing things up. I saw QtE5 recently and have been thinking about trying it out. What do you all recommend? Thanks!
Re: d_to_html.d
On Saturday, 5 August 2017 at 19:07:50 UTC, WebFreak001 wrote: snip Man, this is absolutely nuts. Overriding opBinary to catch hyphens, aliasing opAssign to opCall... Just evil, haha! Amazing job!
Re: What are your hopes for the future D GC
On Thursday, 29 June 2017 at 19:19:47 UTC, Random D user wrote: *snip* I was actually about to make a thread about this comment: https://www.reddit.com/r/programming/comments/2g03af/ds_garbage_collector_problem/ckent8c/ Did Andrei ever end up doing this GC rewrite, or did all of this work go into the custom allocators? I suppose my hope for the GC is for it to be so darn fast next to nobody complains about it. :V
Re: Dealing with the interior pointers bug
On Wednesday, 21 June 2017 at 15:42:22 UTC, Adam D. Ruppe wrote: This comes from the fact that D's GC is conservative - if it sees something that *might* be a pointer, it assumes it *is* a pointer and thus had better not get freed. So is the GC then simply made to be "better-safe-than-sorry" or is this a consequence of how the GC does things? Or rather, does the GC know the type of any references to its memory at all? I suppose I should really ask if there's a document other than druntime's source that describes how the GC really works under the hood haha.
Dealing with the interior pointers bug
I saw this Tip of the Week a while ago (http://arsdnet.net/this-week-in-d/2017-mar-12.html) and was kind of perplexed at it. It seems like a crazy potential bug... How exactly is the GC implemented that causes this problem to crop up? Does the GC just blindly scan memory until it finds pointers to heap memory to mark as "don't delete"? Could it ever be fixed?
Re: Porting Java code to D that uses << and >>> operators
On Tuesday, 2 May 2017 at 07:42:45 UTC, Jacob Carlborg wrote: From that link: "Note that dmd currently does not comply with left to right evaluation of function arguments and AssignExpression". This is something I've never understood. Why doesn't DMD implement the behavior their own language reference specifies? It seems like a very nice guarantee to have...
Re: BinaryHeap crashes upon insertion if heapified with an array of length 1?
On Sunday, 9 April 2017 at 13:31:05 UTC, Michael Coulombe wrote: This is a bug in the insert method. I created a bug report for you and submitted a pull request for a fix: https://issues.dlang.org/show_bug.cgi?id=17314 Ah, so it is. Thanks!!
BinaryHeap crashes upon insertion if heapified with an array of length 1?
I'm trying to use a binary heap initialized with one element.
However, this always seems to cause a range violation for some
reason. This small example will do it:
import std.stdio, std.container;
void main() {
auto pq = heapify([5]);
pq.insert(8);
}
...And it produces this error: https://pastebin.com/dyLNRz2W
Oddly enough, if I heapify an array with any other length than 1,
I can insert as much as I want (that includes an empty array!).
Is this a bug in Phobos or some odd expected behavior? Thanks
guys!
Re: Policy-based design in D
On Tuesday, 14 February 2017 at 10:05:19 UTC, TheFlyingFiddle wrote: (snip) Oh, I didn't know you could name mixin template instantiations like that! Thanks for the tip, that makes things work nicely!
Policy-based design in D
Tonight I stumbled upon Andrei's concept of policy-based design (https://en.wikipedia.org/wiki/Policy-based_design) and tried to implement their example in D with the lack of multiple inheritance in mind. https://dpaste.dzfl.pl/adc05892344f (btw, any reason why certificate validation on dpaste fails right now?) The implementation isn't perfect, as I'm not sure how to check members of mixin templates so that you could verify whether print() and message() are actually where they should be. How would you do that? Is there any use for this kind of thing in D, and if so, what would it be? I've hardly dabbled in OOP patterns, but the abstraction seems kinda interesting.
Re: Name That Technique!
On Monday, 6 February 2017 at 11:03:32 UTC, Walter Bright wrote: On 2/6/2017 12:45 AM, Dominikus Dittes Scherkl wrote: But is this really worth an article? It's ideally suited for an article. It's easy to grasp, and enables a very interesting idiom. I personally think the idiom is neato and think it'd be a neat article! It could potentially inspire wonder in some non-D-users about the limitless possibilities of the language... Or scare some away. :V The idiom would pretty bizarre for newcomers lol.
Re: A safer File.readln
On Monday, 23 January 2017 at 13:18:57 UTC, Andrei Alexandrescu wrote: On 1/23/17 5:44 AM, Shachar Shemesh wrote: If, instead of increasing its size by 100%, we increase it by a smaller percentage of its previous size, we still maintain the amortized O(1) cost (with a multiplier that might be a little higher, but see the trade off). On the other hand, we can now reuse memory. Heh, I have a talk about it. The limit is the golden cut, 1.6180339887498948482... The proof is fun. Anything larger prevents you from reusing previously used space. -- Andrei Andrei, could you link this talk? Thanks!
Re: Strange memory corruption / codegen bug?
On Sunday, 11 December 2016 at 11:58:39 UTC, ag0aep6g wrote: Try putting an `assert(childCrossPoint !is otherCrossPoint);` before the assignment. If it fails, the variables refer to the same node. That would explain how otherCrossPoint.left gets set. Ahh... This led me to it. I was about to say "That wouldn't be possible, childCrossPoint is part of a clone of the original caller!" But then I realized I did "this.getNodeList" towards the beginning instead of "child.getNodeList". I feel very silly right now, haha. Thanks for the help and your patience, guys.
Re: Strange memory corruption / codegen bug?
On Sunday, 11 December 2016 at 11:17:50 UTC, rikki cattermole wrote: Not public, please pastebin. https://github.com/TheGag96/evo-pacman/blob/master/source/pacman/tree.d#L135 I just put it on GitHub. No idea why the repo wasn't public even after I set it to be public...
Strange memory corruption / codegen bug?
I was porting my Evolutionary Computing homework written in Python over to D, and I've come across this bug I cannot for the life of me figure out. https://gitlab.com/TheGag96/evo-pacman/blob/master/source/pacman/tree.d#L139 I don't think I could cut this down to a smaller reproducible scenario due to how bizarre and specific this problem is, so I apologize in advance if this is hard to follow. Basically, imagine that I have a binary tree class where, due to how my program is set up, each node will have either children on both the left and right side or no children at all (the latter represented by a value of null for Tree's left and right member). I have a member function called "dup" -- marked const, mind you -- that just returns a deep copy of the tree and SHOULDN'T make any changes to the calling object. I call this function a couple different places and it appears to function okay, but at the spot I linked, if I call .dup here, it will corrupt one of the tree's nodes and put something in its left member for no apparent reason. This oddly doesn't happen on every Tree calling this function. This could definitely be some stupid mistake on my part, but the fact that calling a const-marked function changes the state of the calling object makes me think something else is afoot here... I would greatly appreciate anyone who would be willing to take a look at this. This bug is driving me absolutely nuts.
Re: A simplification of the RvalueRef idiom
On Tuesday, 22 November 2016 at 13:06:27 UTC, Nordlöw wrote:
On Monday, 21 November 2016 at 20:04:51 UTC, Ali Çehreli wrote:
mixin template RvalueRef()// <-- DOES NOT TAKE A PARAMETER
ANY MORE
{
alias T = typeof(this);
static assert (is(T == struct));
@nogc @safe
ref const(T) byRef() const pure nothrow return
Why do you need to qualify `byRef` as pure nothrow when it's a
template?
The thing that gets me more is "return" as a function attribute.
I see it under "MemberFunctionAttribute" in the grammar but I
can't find an explanation for its use anywhere...
Re: strange -fPIC compilation error
On Monday, 31 October 2016 at 07:16:50 UTC, Sebastien Alaiwan wrote: Hello, From GCC 6.2, -fpie is becoming the default setting at compile and at link time. As dmd uses GCC to link, now the code needs to be compiled with a special option. Which means you need, at the moment, to add the following options to your dmd.conf: -defaultlib=libphobos2.so -fPIC (the change from GCC is related to security and address space randomization). So does this mean it's now impossible to compile statically until this gets fixed?
Re: gdc in Linux distros recommended?
On Wednesday, 19 October 2016 at 03:29:10 UTC, Marco Leise wrote: On the other hand LDC subjectively offers a couple more D specific enhancements, like turning GC allocations into stack allocations in trivial cases Whoa, seriously? I know it's a bit off-topic, but do you have a code example of where this would happen? That's amazing!
Re: Why can't static arrays be sorted?
On Saturday, 8 October 2016 at 21:14:43 UTC, Jon Degenhardt wrote: This distinction is a bit on the nuanced side. Is it behaving as it should? --Jon I think so? It's not being modified in the second case because the array is being passed by value... "x" there is a reference to an element of the copy created to be passed to each(). I assume there's a good reason why ranges in general are passed by value into these functions -- except in this one case, the stuff inside range types copied when passed by value won't be whole arrays, I'm guessing.
Re: Why can't static arrays be sorted?
On Wednesday, 5 October 2016 at 19:30:01 UTC, Jonathan M Davis wrote: It doesn't even make conceptual sense for a static array to be a range, because you can't remove elements from it. - Jonathan M Davis Interestingly enough, I found that using .each() actually compiles without the [] but (as expected) creates a copy... So, these output different values: thing.each!((ref x) => writeln()); thing[].each!((ref x) => writeln()); Should there me a more consistent behavior here? Even if the behavior is pretty undesired, why can the compiler consider it a range here but not .sort()?
Re: Why can't static arrays be sorted?
On Wednesday, 5 October 2016 at 02:19:13 UTC, Jonathan M Davis wrote: The problem is that static arrays aren't ranges (calling popFront on them can't work, because their length isn't mutable). However, you can slice a static array to get a dynamic array which _is_ a range. e.g. thing[].sort(); Just make sure that such a dynamic array does not outlive the static array, or it will refer to invalid memory (which would not be a problem in this case). - Jonathan M Davis Ah thanks guys. I think I just got used to thinking arrays would always be found to be ranges by the compiler. Good to know!
Why can't static arrays be sorted?
I was writing some code today and ran into this oddity that I'd never come across before: import std.algorithm : sort; int[10] arr = [0, 3, 4, 6, 2, 1, 1, 4, 6, 9]; thing.sort(); This doesn't compile. Obviously the .sort property works, but what about static arrays makes them unable to be sorted by std.algorithm.sort? Thanks.
Re: Countries where D is used
On Friday, 16 September 2016 at 11:34:31 UTC, Chris wrote: I've noticed that there is a lot of enthusiasm for D in France, Germany and Russia (alphabetic order) where it is also used for production. I see there's a company in Belarus that uses D, and D is also used in Italy, Austria and the Czech Republic. Where else is D used for production? I for my part can add Ireland to the list. I don't know if it's used in production there, but all the time I'll see Japanese coders post in the #dlang Twitter sidebar on the homepage.
Re: Commercial video processing app in D (experience report)
On Wednesday, 27 April 2016 at 12:42:05 UTC, thedeemon wrote: (snip) Sorry to bump this thread, but how did you handle multiple windows using DlangUI? (As in, were you able to prevent input on the main window while another one was open, etc.) I know Vadim/buggins is working on improving that right now but I'd like to know if there's a clean way to handle more than one window already.
Re: Can't use std.algorithm.remove on a char[]?
On Sunday, 1 May 2016 at 09:11:22 UTC, ag0aep6g wrote: It's because of auto-decoding. char[] is an array of chars, but it's been made a range of dchars. Calling front on a char[] decodes up to four chars into one dchar. Obviously you can't take the address of the dchar, because it's just a return value. You can't assign through front, because the number of chars could be different from what's currently there. The whole array would have to be re-arranged then, which would be unexpectedly costly for the user. The auto-decoding behavior was chosen to make dealing with char[] less bug-prone. With auto-decoding you don't have to worry about cutting a multibyte sequence in half (can still cut a grapheme cluster in half, though). However, as you see, it creates other headaches, and it's considered a mistake by many. Getting rid of it now would be a major breaking change. Could be worthwhile, though. That's a shame. I'd really like to be able to remove a character from a character array... I supplier I just have to get used to casting to ubyte[] or maybe just using dchar[] instead. I'm honestly surprised I haven't encountered this behavior sooner. It's interesting - as I keep coding in D and learning about how amazing it is to use, I always find these weird quirks here and there to remind me that it isn't flawless... I guess it can't be perfect, haha.
Re: Can't use std.algorithm.remove on a char[]?
On Saturday, 30 April 2016 at 19:21:30 UTC, ag0aep6g wrote: On 30.04.2016 21:08, Jon D wrote: If an initial step is to fix the documentation, it would be helpful to include specifically that it doesn't work with characters. It's not obvious that characters don't meet the requirement. Characters are not the problem. remove works fine on a range of chars, when the elements are assignable lvalues. char[] as a range has neither assignable elements, nor lvalue elements. That is, lines 3 and 4 here don't compile: import std.range: front; char[] a = ['f', 'o', 'o']; a.front = 'g'; auto ptr = Why exactly is it like this? I would understand why strings (immutable character arrays) behave like this, but I feel like plain old character arrays should work the same as an array of ubytes when treated as a range... Or is there some other string-related behavior that would get broken by this?
Can't use std.algorithm.remove on a char[]?
I was just writing some code trying to remove a value from a character array, but the compiler complained "No overload matches for remove", and if I specifically say use std.algorithm.remove() the compiler doesn't think it fits any definition. For reference, this would be all I'm doing: char[] thing = ['a', 'b', 'c']; thing = thing.remove(1); Is this a bug? std.algorithm claims remove() works on any forward range...
Re: So, to print or not to print?
On Tuesday, 26 April 2016 at 14:33:42 UTC, tn wrote: Maybe the name of the function should then be "writes" and/or "writesln" (instead of "print"), so that it can at least be found from the same place in the documentation as other related functions. The naming scheme would then also be consistent with the rest of the write/writef-family. (Here -s stands for "separated/spaced" just as -f stands for "formatted" etc.) I really like this idea. Much better than just "print", and maybe even better than "dump".
Re: DlangUI on Android
On Thursday, 21 April 2016 at 13:28:18 UTC, Vadim Lopatin wrote: (snip) Wow, really nice stuff! I wasn't even aware we could write D for Android at all...
Re: D and devkitARM
On Thursday, 10 March 2016 at 14:36:26 UTC, Nicholas Wilson wrote: Hmm. I apologise that this post is not in any logical order. dmd can only compile for x86 so you will have to use ldc or gdc makefiles are generally not used in d. you should be able to use the dub project settings file (dub.json or dub.sdl) to do most of the standard linking, as for some of the deeper magic I'm not sure. versioning: i'm not sure that d has a 3ds target version but it has an arm one. includes should not be an issue. If you cannot find bindings for ctru see if dstep can do it for you. I don't know what .v.pica or .shlist files are but you can use string imports to reference the data looks like the same idea can be used for the shader rule. However you may need to use a prehook script to call whatever "picassso" does first. Thanks for the suggestions. I know I need to use gdc, specifically the one found at ftp://ftp.gdcproject.org/binaries/devkitARM/ (or build it myself if this doesn't work for whatever reason). I'm starting to think a bigger problem aside from the Makefiles is just getting any D to compile with that gdc version at all. I'm pretty sure I need some sort of bare metal runtime. Would this be something that could work, or should I look elsewhere? https://bitbucket.org/timosi/minlibd ...This probably really is above my knowledge level, but I suppose I'll never learn if I don't give it a shot. Like I said, if anyone has any sort of advice on how I should approach this, I'd be happy to hear it.
D and devkitARM
Hi guys, for a possibly-in-over-my-head project I'd like to get working a simple "Hello World" type program in which I call a D function from C in a 3DS homebrew app (or maybe even have it all in plain D with bindings to libctru). The thing is, I'm not skilled with Makefiles so I don't have a clue on how to correctly set up the toolchain for linking everything. I can compile some D-calling C code just fine with dmd and gcc on Linux (though I can't get anything working with gdc for whatever reason). Would anyone be able to point me in the right direction? This is the example Makefile for a 3DS homebrew app: http://pastebin.com/fcJrrMg9 It seems like there would be issues differentiating the .d build definition files from D source files... Thanks!
Re: Sublime Text 3 Gets Better D Support
Just got the new update, and when I reloaded my files, any source code inside a class has every variable name and all punctuation colored according to my theme: http://i.imgur.com/RxqTqoP.png If I'm remembering right Java files look like the right half of the image as well, though I'm not sure what parameter in my theme I'm supposed to change to make this go back to what it was before, though... As it is it's a little eye-searing. Is this just a result of Sublime parsing D better now?
TreeViews in tkd
I've been trying to get into tkd to make some GUI apps, since it looked like the simplest/intuitive library out there so far. I've been attempting to use their TreeViews to make interactable lists of things, but it almost looks like there's some missing functionality. For example, I'm not sure there are any ways to delete individual rows from one. You can clear them all entries, but there doesn't look to be a method for just getting rid of one row - if there is, I can't find it. Calling destroy() on an individual row does not remove it either (yet apparently destroy() effects the GUI in tkd, not just finalizing the object). It also doesn't look like there's a way to get a row by an index or ID, either. You can get columns... But the only way you can a row object is through getSelectedRows(). Am I missing something here? I made an issue on GitHub but I'm not sure I'll get anything back, it's been 9 months since the last commit. Has anyone worked with this before and could give me some tips? Thanks!
Re: TreeViews in tkd
On Thursday, 17 December 2015 at 11:33:31 UTC, Gary Willoughby wrote: On Thursday, 17 December 2015 at 09:47:42 UTC, TheGag96 wrote: I've been trying to get into tkd to make some GUI apps, since it looked like the simplest/intuitive library out there so far. I've been attempting to use their TreeViews to make interactable lists of things, but it almost looks like there's some missing functionality. I made an issue on GitHub but I'm not sure I'll get anything back, it's been 9 months since the last commit. Has anyone worked with this before and could give me some tips? Thanks! Calm down, lol. There have been no commits for 9 months because as far as i'm aware it's finished and stable. I got your issue this morning and will take a look tonight after work. Ah thanks, sorry for my impatience. I guess it's good the D community is so tight-knit that everyone lurks these forums, haha.
Re: We need a good code font for the function signatures on dlang.org
On Thursday, 17 December 2015 at 15:43:22 UTC, qznc wrote: I don't think listening to random forum opinions (Inconsolata!!1) is a good process. ...And I was about to say Source Code Pro and Inconsolata are my favorite fonts to use. >_> I think they fit the "nice" quality Andrei is looking for.
Re: conver BigInt to string
On Thursday, 5 November 2015 at 16:45:10 UTC, Meta wrote: The second issue is that using .sort instead of .sort() (note the parentheses) calls the built-in sort instead of std.algorithm.sort, which is strongly discouraged. You should always use std.algorithm.sort over the built-in sort, which you can do just by appending those parentheses. Whoa whoa whoa... This is the first time I've heard about this difference, and I've used .sort plenty of times... That seems like really, REALLY bad design, especially considering the language allows functions to be called without parentheses. I thought I was using std.algorithm's version the whole time. What's the difference between the implementations of arrays' .sort property and std.algorithm.sort()? And does sort() throw out that "unable to deduce function argument" error for a character array of all things?
Re: Array of BitArrays definition compiles in DMD but not in GDC.
On Friday, 9 October 2015 at 07:08:15 UTC, John Colvin wrote:
On Thursday, 8 October 2015 at 21:40:02 UTC, TheGag96 wrote:
[...]
gdc is a bit out of date at the moment. If you do something
like this:
auto bitArray(bool[] ba) pure nothrow
{
BitArray tmp;
tmp.init(ba);
return tmp;
}
auto bitArray(void[] v, size_t numbits) pure nothrow
{
BitArray tmp;
tmp.init(v, numbits);
return tmp;
}
then replace all your calls to the constructor BitArray with
bitArray, things should work OK for you.
That appears to work, although the compiler was complaining that
the calls to init were not pure nor nothrow. Thanks! Hopefully
they'll update GDC soon.
Array of BitArrays definition compiles in DMD but not in GDC.
In my code I'm passing an array of BitArrays to a constructor like this (though mostly as a placeholder): Terrain t = new Terrain(1, 15, [ BitArray([1, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1]), BitArray([1, 1, 1, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1]), BitArray([0, 0, 1, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1]), BitArray([0, 0, 1, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1]), BitArray([0, 0, 0, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1]), BitArray([1, 1, 1, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1]), ]); The code compiles fine when using DMD 2.068.1 but GDC 5.2.1, I get this error for every line: error: cannot implicityly convert expression ([stuff]) of type int[] to ulong Why does this compiler difference exist and how do I get around it? Thanks!
I can't get passing an array by reference to work anymore...
So I'm just doing a small test program here: http://pastebin.com/UYf2n6bP (I'm making sure I know quicksort for my algorithms class, I know functionally this won't work as-is) I'm on Linux, 64-bit, DMD 2.068.1, and when I try to compile this I'm getting: quicksort.d(18): Error: function quicksort.quickSort (ref int[] arr) is not callable using argument types (int[]) quicksort.d(19): Error: function quicksort.quickSort (ref int[] arr) is not callable using argument types (int[]) No matter how I attempt to define the array test, it will never allow me to pass it by reference no matter what. I even copy-pasted some example code from here (https://en.wikibooks.org/wiki/D_(The_Programming_Language)/d2/Pointers,_Pass-By-Reference_and_Static_Arrays#Pass_By_Reference, bottom of the page), and it gave the same error. What's the problem here? I SWEAR I've passed arrays by reference before just like this. Thanks guys.
Re: Example from d-idioms is incorrect
On Thursday, 30 April 2015 at 22:01:43 UTC, Justin Whear wrote: On Thu, 30 Apr 2015 21:30:34 +, TheGag96 wrote: Was the behavior of the remove() function changed recently? Thanks guys. I believe remove has always worked this way. What you're seeing is explained by this note in the documentation for remove: The original array has remained of the same length because all functions in std.algorithm only change content, not topology. The value 8 is repeated because std.algorithm.move was invoked to move elements around and on integers move simply copies the source to the destination. To replace a with the effect of the removal, simply assign a = remove(a, 1). The slice will be rebound to the shorter array and the operation completes with maximal efficiency. Ah... This is all a lot clearer now. Thanks guys!
Example from d-idioms is incorrect
I was looking at the d-idioms website today and saw this code
example:
http://p0nce.github.io/d-idioms/#Adding-or-removing-an-element-from-arrays
And I was kind of irked. I just recently working with removing an
element from an array in a small project I worked on two weeks
ago, and I had to learn the hard way that to properly remove an
element from an array in the way this example describes, you have
to do array.length--; as well.
This code:
import std.stdio, std.algorithm;
void main() {
int[] arr; //ensuring it's dynamic
arr ~= 1;
arr ~= 5;
arr ~= 10;
arr.remove(1);
writeln(arr);
writeln(arr == [1, 10]);
arr.length--;
writeln(arr);
writeln(arr == [1, 10]);
}
produces this output:
[1, 10, 10]
false
[1, 10]
true
Compiled and ran on Windows, dmd v2.067.0. Unless I'm totally
missing something here, that website is giving some pretty wrong
information... Was the behavior of the remove() function changed
recently? Thanks guys.
Re: Reading whitespace separated strings from stdin?
On Tuesday, 21 April 2015 at 03:44:16 UTC, weaselcat wrote: snip Wow, that's a damn good solution... I didn't know that readln() could take an argument that it stops at once it finds. Now the thing is, this program is supposed to be a reverse Polish notation calculator. A human using this program would probably be confused as to why nothing happens when they hit enter after a line -- it only really works in the context of copying and pasting the whole input in. Still a really neat solution to know anyhow. Thanks!
Reading whitespace separated strings from stdin?
Hi guys! I had this homework assignment for data structures that
has a pretty easy solution in C++. Reading input like this...
1 2 3 # $
4 3 * ! #
20 3 / # $ #
62 # $
2 3 8 * + #
4 48 4 2 + / #
SUM # $
1 2 3 4 5 #
R #
@
...where @ denotes the end of input is fairly simple in C++:
string token = ;
while (token != @) {
//handle input
}
Note that having newlines doesn't matter at all; every token is
just assumed to be separated by whitespace. However in D, I
looked around could not find a solution better than this:
foreach (line; stdin.byLine) {
foreach (token; line.split) {
//handle input
}
}
Is there any way to do this without two loops/creating an array?
readf( %d, token); wasn't cutting it either.
Thanks.
Re: Reading whitespace separated strings from stdin?
On Tuesday, 21 April 2015 at 01:46:53 UTC, Adam D. Ruppe wrote:
I think this should work:
import std.stdio;
void main() {
string token;
while(readf(%s , token))
writeln(token);
}
Have you tried that? What is wrong with it if you have?
It'll just leave some trailing whitespace, which I don't want.
And somehow doing token = token.stip STILL leaves that whitespace
somehow...
Linking C++ standard library works with GDC... but not DMD. (Linux)
Hi, I've got this project that requires me to link into a C++ backend. It works just fine when using GDC: gdc *.d [client libraries] However, this command using DMD does not work: dmd -L-lstdc++ *.d [client libraries] I still get errors involving the standard library not being added like: /usr/include/c++/4.8/iostream:74: undefine reference to `std::ios_base::Init::Init()' (etc.) What do I need to do to make this work? Thanks.
Re: Linking C++ standard library works with GDC... but not DMD. (Linux)
On Thursday, 16 April 2015 at 09:46:40 UTC, John Colvin wrote: On Thursday, 16 April 2015 at 08:51:15 UTC, TheGag96 wrote: Hi, I've got this project that requires me to link into a C++ backend. It works just fine when using GDC: gdc *.d [client libraries] However, this command using DMD does not work: dmd -L-lstdc++ *.d [client libraries] I still get errors involving the standard library not being added like: /usr/include/c++/4.8/iostream:74: undefine reference to `std::ios_base::Init::Init()' (etc.) What do I need to do to make this work? Thanks. I don't know why that's happening, but you can explicitly link using gcc (or ld/gold directly) if you need to. E.g. dmd -c myFile.d gcc myFile.o -lphobos2 or whatever is necessary on your project/system. I had wanted to try this too, but I wasn't sure if the linker knew where phobos2 was on my system. I just tried this now for funsies: dmd -c *.d g++ main.o [client files] -lphobos2 With or without that -lphobos2 flag, I get errors like these: main.d(.text._Dmain+0x18e): undefined reference to `D3std5stdio16__T7writeln(TAyaZ7writeFAyaZv'
Re: Linking C++ standard library works with GDC... but not DMD. (Linux)
On Thursday, 16 April 2015 at 12:57:12 UTC, Steven Schveighoffer wrote: /usr/include/c++/4.8/iostream:74: undefine reference to `std::ios_base::Init::Init()' (etc.) Try dmd -v to tell you exactly what command it is running for link. Then play around with the link line to see if you can figure out a way to link it correctly. We can work on fixing the situation from there. Maybe there's a way to link using dmd, maybe we have to fix dmd so it allows the correct link call. -Steve Got it!! This is what helped me the most. I compiled a regular C++ program with the -v flag, found where my libstdc++.a was, added it to the command and bam. I really should have thought of this one earlier... Thanks for the quick support, everyone!
