Re: Note from a donor
On Friday, 27 October 2017 at 02:20:54 UTC, Jonathan M Davis wrote: Well, if it's possible to use an SDK instead of VS, then ideally, we'd support with the installer that rather than requiring that VS be there, but obviously, someone will have to do the work to improve the installer. Personally, I'm really not a Windows dev, though I've had to use Visual Studio for work often enough, so my understanding of what other SDKs might exist from Microsoft is quite poor. I've only ever used Windows for development when I've had to. - Jonathan M Davis A while back I played with the idea of a VS replacement for D and I made some progress using this: http://www.smorgasbordet.com/pellesc/ I managed to swap out the VS linker and use the included linker to build a 64-bit D binary, but that was as far as I got at the time. It's not open source, but the terms of use are pretty permissive. Maybe it's worth taking another look.
Re: RFC: Implementation of binary assignment operators (e.g s.x += 2) for @property functions
On Tuesday, 15 August 2017 at 03:53:44 UTC, Michael V. Franklin wrote: An implementation of binary assignment operators for @property functions has been submitted to the DMD pull request queue at https://github.com/dlang/dmd/pull/7079. It addresses the following issues: Issue 8006 - Implement proper in-place-modification for properties https://issues.dlang.org/show_bug.cgi?id=8006 -- This is the primary issue motivating the pull request. The pull request is only a partial resolution of this issue; it implements binary assignment operators (e.g. `s.x += 2`), but not unary assignment operators (e.g. `s.x++`). The plan is to implement unary assignment operators in a separate pull request after the fate of the binary assignment operators pull request is decided. I'm a huge fan of this, but then I am of the mindset that @property functions should act like variables much in the way that they do for C# properties.
Re: cost of calling class function
On Thursday, 23 February 2017 at 01:48:40 UTC, Seb wrote: AFAICT though it was approved, the switch to final by default has never happened. I believe Andrei made an executive decision to shut down final by default.
Re: Auto-testing issue on FreeBSD
I apologize as this might be better in the learn section, but I'm having another issue trying to run tests on FreeBSD. On a 64 bit system (tests ran just fine on a 32 bit system) I'm getting this error on the first test ran: Running runnable tests ... runnable/issue8671.d (-inline -release -g -O -fPIC) Error: module is in file '.d' which cannot be read Any idea what's going on here? I've never seen anything like this before.
Auto-testing issue on FreeBSD
Hey All. I'm trying to track down an auto-tester failure on FreeBSD, so I decided to run the same tests myself locally. I encountered the following error: runnable/extra-files/cppb.cpp:297:37: error: 'va_list' has not been declared void myvprintfx(const char* format, va_list); I added #include to the file, and then everything ran fine. Should I have set up my system differently so that I didn't need to edit anything or should this be added to the file anyway? Jeremy
Re: Some questions on latest work
On Wednesday, 27 April 2016 at 17:57:55 UTC, Bill Hicks wrote: On Wednesday, 27 April 2016 at 15:28:37 UTC, Meta wrote: On Tuesday, 26 April 2016 at 21:49:33 UTC, Bill Hicks wrote: On Tuesday, 26 April 2016 at 02:33:41 UTC, Andrei Alexandrescu wrote: That's a pretty awesome rant! Bill, could you please email me your mailing address? I'd be glad to send you a DConf T-shirt. Thanks! -- Andrei Quitting a well paying job at Facebook to peruse a hobby sounds like something a person going through midlife crisis would do. You may keep the T-shirt. I suggest you smoke some DMT (and have a breakthrough), or have a few Ayahuasca sessions. If that doesn't set you off on a path to the greatest positive impact, then nothing ever will. Everything you've desired to achieve with D is a construct of your ego, and nothing more. This is completely over the line. Personal attacks of this nature are absolutely unwarranted and unwelcome here. He started it. If I get up on a stage with a grin splitting my face and talk about how great D is, I'm considered a hero. But if I criticize D for it's flaws, then I'm a troll or someone who is just ranting. Anybody has the right to criticize D, just as people have the right to praise it. If D is part of your identity to the point where you can't stand hearing people criticize it and then get offended, then you have issues. Grow up. Look, no one here thinks D is perfect. There are some things that I don't like about it myself, but I like it more than everything else. Unless you have criticism that you want to bring up for the sake of discussion, then you *are* ranting. If you take your first post in this thread and rewrite it so that it starts discussion about those topics, it could be valuable. Nothing is going to be changed unless people start talking about them.
Re: Potential GSoC project - GC improvements
On Friday, 18 March 2016 at 16:41:21 UTC, Rainer Schuetze wrote: On 15.03.2016 02:34, Jeremy DeHaan wrote: [...] Being always way behind reading the forum these days, I'm a little late and have not read all the messages in this thread thoroughly. Here are some thoughts: [...] Thank you for the feedback. I'm still working on my proposal so nothing is set in stone just yet. I'm very interested in working on the GC for this GSoC, so what would you suggest be my main focus? It sounds like you already have a GC that is more or less what I was planning on implementing...
Re: Potential GSoC project - GC improvements
I haven't had power for a couple of days, but it looks like the discussion has gone along pretty ok. After reading everything, I think I'm inclined to agree with Adam and the main focus of my proposal will be a precise GC (or as precise as we can get). I'll definitely need some guidance, but I'll be learning everything I can about GC's and precision until the start of the project. On Monday, 14 March 2016 at 05:28:13 UTC, Adam Wilson wrote: Maybe ... why don't instead of trying to compete with everybody else, we do our own thing, and do it very well. As long as we're just another "me too" operation people will treat us like we are. Let's focus on being the best D language out there. And D needs a GC, so let's build the best damn garbage collector the natively-compiled world has every seen. That is what I hope to work towards. Hopefully next year I can work on making a generational GC, or something else depending on how much time I could dedicate between when this GSoC is finished and the next begins. Adam, can you reach out to Craig and let him know you're willing to mentor this project if it get's accepted? I talked with him a few days ago via email and he said that someone would need to take it on but he wasn't sure who.
Re: Potential GSoC project - GC improvements
On Saturday, 12 March 2016 at 08:50:06 UTC, Adam Wilson wrote: If I may make a suggestion. The lock free work is unlikely to require the entirety of GSoC. And the precise GC is the next most important thing on your list and will have the biggest impact on GC performance. Rainer has two different precise GC's in pull requests right now and both are slower than the current one unless there are false pointers. I would expect anything I come up with to largely act the same. The reason I keep pushing for a generational garbage collector is because I think it would be where we would see the most benefit in terms of general performance. Once the GC is fully precise we can implement a fully compacting GC, which improves the usefulness of generational collection. Additionally, precision allows a significant amount of work to be done in improving the performance of the GC in multi-threaded scenarios. It should be quite possible to avoid needing fork() or anything like it altogether. I know that the .NET GC doesn't need to use anything like it. A compacting GC could be built on top of a generational GC without much difficulty I would think, if we wanted to go that route. The compaction would just happen as part of a collection cycle when things are moved into the next generation. I have concerns about doing any compaction though, mostly because D can have both references and pointers to objects, and I don't know how we would want to go about updating pointers. Especially since pointers to D objects can exists in C and C++ code. Another reason I want to work on a generational GC is because this can also lead into a concurrent GC without trying to emulate fork() on windows. The .Net GC has 3 generations with the last one having its collections running concurrently because it is unlikely to affect anything else going on. They don't bother running the other generations concurrently because their collections are really short. We could do something similar. Perhaps someone more intimate with GC's than I am can speak up, but I think that a generational GC would be the best use of time in relation to performance gains. Other things can then be implemented on top of it later. Also, I would strongly recommend getting this book and reading it cover to cover before starting: http://www.amazon.com/gp/product/1420082795/ref=pd_lpo_sbs_dp_ss_1?pf_rd_p=1944687562&pf_rd_s=lpo-top-stripe-1&pf_rd_t=201&pf_rd_i=0471941484&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=0QD9X3E5QATSBCBT6BMM Thank you for the link to the book. I was planning on this one http://www.amazon.com/gp/product/0471941484/ , but maybe I will buy them both.
Re: Potential GSoC project - GC improvements
Thank you all for the feedback. I think I might still need a little more feedback as to what the project should actually entail, but here's what it's looking like so far: Implement lock free allocation using std.experimental.allocator's freelists (SharedFreeList? It was the only thing in the documentation that specifically mentions lock free allocation) Implement a generational garbage collector Implement precise garbage collection (possibly piggybacking off of Rainer's work) Does anyone think that might be too much to take on or does it sound pretty good? I have other garbage collector things I'd like to explore, but I they should probably go in the "if time allows" category at this point. Jeremy
Re: Potential GSoC project - GC improvements
On Thursday, 10 March 2016 at 15:24:48 UTC, Andrei Alexandrescu wrote: On 3/9/16 10:40 PM, NX wrote: I think the best possible improvement for GC is making it lock-free. Currently, GC lock cause some serious performance penalties for multithreaded code when frequent allocations take place. I agree. A first step would be easy to do with std.allocator's thread-local freelists. -- Andrei I was looking into this, but I am slightly hesitant. Should the gc use something in std.experimental? Or should we think that's ok? I also know that there are some people that think we should avoid using Phobos in druntime.
Potential GSoC project - GC improvements
Hey all, I'm trying to think of good project ideas for this years GSoC, and one in particular I thought would be a great was working on and improving the GC. I'm not sure what the scope of this project would be like, but at the moment I am thinking writing a generational collector would be a good place to start. I have more ideas, but I don't have a proposal yet. I just wanted some initial feedback on the idea, perhaps some advice for scope with the time frame in mind, and hopefully someone on the mentor list willing to take this on if it were to be accepted. Jeremy
Re: GSoC Project Feedback - iOS and Android versions of DSFML
On Monday, 7 March 2016 at 05:40:01 UTC, Joakim wrote: On Monday, 7 March 2016 at 02:34:41 UTC, Jeremy DeHaan wrote: For those interested in seeing the actual proposal I am working on, I have provided the link below. Just know that this is my first draft and *a lot* of revising and editing still needs to be done. https://github.com/Jebbs/DSFML/files/160669/DSFML.Summer.of.Code.Proposal.-.FirstDraft.pdf Please let me know if you think this is worth the effort and would make a good GSoF project. Certainly worth the effort but I'm not sure it's a good GSoC project, as I wonder if this is the kind of grunt work that they want to sponsor and if it's enough work for a whole summer. That would all depend on more details about what you think needs to be done. Yeah, that's a pretty fair assessment I think. Not being sure if this would be good for GSoC is the reason I asked and it's also the reason why I am considering other projects as well. I just wanted to start with something I know I could do within the given time frame and something that I thought would be really useful for the D language and community. If I get similar feedback from other people, I will probably work on a different proposal.
GSoC Project Feedback - iOS and Android versions of DSFML
Hi all, I have been working on a proposal for the upcoming GSoC, and its to a point where I wanted to get some feedback on things. I maintain DSFML, a wrapper and binding to the C++ game library SFML. Essentially the core of my proposal is to add the ability for binding to build iOS and Android versions which can then leverage recent work on LDC to build and run on these mobile systems. SFML can already target these OS's, so most of the work is done there. Barring anything extreme, this would allow D programmers to easily work on games for mobile devices pretty much as soon as that functionality is officially released in the LDC compiler. I think that's pretty damn awesome. There are a few other things in my proposal, like updating some things and fixing some bugs, but Android and iOS support is pretty much the meat and potatoes. For those interested in seeing the actual proposal I am working on, I have provided the link below. Just know that this is my first draft and *a lot* of revising and editing still needs to be done. https://github.com/Jebbs/DSFML/files/160669/DSFML.Summer.of.Code.Proposal.-.FirstDraft.pdf Please let me know if you think this is worth the effort and would make a good GSoF project.
Re: Any actively maintained qt bindings for D?
On Wednesday, 17 February 2016 at 20:56:27 UTC, Rishub Nagpal wrote: Qtd hasn't been updated in 3 years Does anyone know of anactively maintained qt library? I think QML bindings exists, but as far as I know direct Qt bindings don't exist/aren't updated. I want to do a GSoC proposal for direct bindings to Qt, though. I have a lot of ideas for doing a binding to Qt proper, but the only way I can do it is if I have time.
Re: DConf keynote speaker ideas
On Saturday, 21 November 2015 at 22:21:48 UTC, Walter Bright wrote: On 11/17/2015 10:48 AM, Andrei Alexandrescu wrote: I'm thinking of inviting a notable industry luminary to deliver a conference keynote. Please reply to this with ideas! -- Andrei Maybe someone from JPL who can talk about software on space probes. Sounds like someone just watched The Martian.
Re: Here's looking at you, kid
On Sunday, 15 November 2015 at 13:50:36 UTC, Warwick wrote: On Sunday, 15 November 2015 at 11:46:54 UTC, Saurabh Das wrote: On Friday, 13 November 2015 at 22:34:18 UTC, Andrei Alexandrescu wrote: [...] This is slightly off-topic, but: I've been encouraging my friends and colleagues to use Dlang over the last year and the one pain point they constantly tell me about is that the documentation website is "difficult to use" and "looks intimidating". The problem is you click on "Language Reference" and what you actually get is a "Language Specification". Which is funny, because I think the specification page is actually a decent reference. http://dlang.org/spec.html
Re: Is D so powerfull ??
On Monday, 9 November 2015 at 06:51:03 UTC, Jeremy DeHaan wrote:
On Monday, 9 November 2015 at 06:27:22 UTC, Daniel Murphy wrote:
On 9/11/2015 4:26 PM, Jeremy DeHaan wrote:
What is the correct way to use C++ class instances in D? Can
you by
chance give an example?
extern (C++) class X
{
...
}
extern (C++) void func(X x);
void main(string[] args)
{
func(new X());
}
etc
Didn't you say constructors and destructors are missing? What
should one do in those cases?
Additionally, should we use new in this case? Wouldn't new create
a pointer to a C++ class? Or does it work differently for
extern(c++) classes?
Re: Is D so powerfull ??
On Monday, 9 November 2015 at 06:27:22 UTC, Daniel Murphy wrote:
On 9/11/2015 4:26 PM, Jeremy DeHaan wrote:
What is the correct way to use C++ class instances in D? Can
you by
chance give an example?
extern (C++) class X
{
...
}
extern (C++) void func(X x);
void main(string[] args)
{
func(new X());
}
etc
Didn't you say constructors and destructors are missing? What
should one do in those cases?
Re: Is D so powerfull ??
On Monday, 9 November 2015 at 05:16:50 UTC, Daniel Murphy wrote: On 9/11/2015 4:05 PM, Jeremy DeHaan wrote: Because that's what this page says: http://dlang.org/cpp_interface.html That page is out of date. Virtual and non-virtual member functions, static member functions, and free functions all work since ~2.066. The biggest missing thing is special member functions, ie ctor/dtor/operators. > Declaring it as a struct in D code is freaking genius. I wonder if > that works across the board with other compilers and OS's though. Mixing struct/class will only work properly with ABIs that mangle them the same way, so it's not portable. We should really update that page then. What is the correct way to use C++ class instances in D? Can you by chance give an example?
Re: Is D so powerfull ??
On Sunday, 8 November 2015 at 23:43:42 UTC, ZombineDev wrote: On Saturday, 7 November 2015 at 21:02:26 UTC, Jeremy DeHaan wrote: On Saturday, 7 November 2015 at 14:49:05 UTC, ZombineDev wrote: On Saturday, 7 November 2015 at 14:25:01 UTC, ZombineDev wrote: What standard C does not provide and D does: calling C++ free functions nested in namespaces, creating objects of C++ classes (with single inheritance), ... ... calling virtual and non-virtual methods on C++ classes from D Actually, you can only call virtual methods on classes. Using non-virtual methods isn't supported. Why do you think so? See: https://gist.github.com/ZombineDev/19f966273b4a82a5c2f1 Output: $ g++ --version g++ (Ubuntu 4.9.2-10ubuntu13) 4.9.2 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ dmd --version DMD64 D Compiler v2.069.0-b2 Copyright (c) 1999-2015 by Digital Mars written by Walter Bright $ ./build.sh $ ./d_class cpp.add(40, 2): 42 cpp.mul(1.5, 2f, 'B') 198 $ ./cpp_main d.add(7, 8): 15 d.mul(3.0, 2.0f, 'A'): 390 Because that's what this page says: http://dlang.org/cpp_interface.html It's about halfway down, but here's the section I am referring to says: Note: non-virtual functions, and static member functions, cannot be accessed. That's awesome if I am wrong, but that is what the C++ interfacing page says. Declaring it as a struct in D code is freaking genius. I wonder if that works across the board with other compilers and OS's though.
Re: Is D so powerfull ??
On Saturday, 7 November 2015 at 14:49:05 UTC, ZombineDev wrote: On Saturday, 7 November 2015 at 14:25:01 UTC, ZombineDev wrote: What standard C does not provide and D does: calling C++ free functions nested in namespaces, creating objects of C++ classes (with single inheritance), ... ... calling virtual and non-virtual methods on C++ classes from D Actually, you can only call virtual methods on classes. Using non-virtual methods isn't supported.
Re: -> and :: operators
On Friday, 9 October 2015 at 21:21:10 UTC, deadalnix wrote: On Friday, 9 October 2015 at 19:54:19 UTC, Jeremy DeHaan wrote: On Friday, 9 October 2015 at 18:44:50 UTC, Freddy wrote: On Friday, 9 October 2015 at 04:15:42 UTC, Ali Çehreli wrote: [...] Stole from D? You mean java right? Java doesn't have pointers. -_- Yeah reference are definitively not pointer. No they aren't. No I told you they aren't. Nope. Not even a little ! No way ! That's not true ! I told you that's not true. Nope ! I guess you could argue it that way, but I don't see references and pointers as the same. Similar, yes, but not the same.
Re: -> and :: operators
On Friday, 9 October 2015 at 18:44:50 UTC, Freddy wrote: On Friday, 9 October 2015 at 04:15:42 UTC, Ali Çehreli wrote: Semi-relatedly, a colleague who has heard many D sales pitches from me over the years is recently "looking at Go" and liking it very much. He came to me today telling me about this awesome Go feature where you just type a dot after a pointer and the language is so great that it works! You don't need to type (*p).member. Isn't Go awesome! I responded "yep, it's a great feature and those gostards will never admit that they took that feature from D." (There is probably earlier precedence but it felt great to say it to my friend. :) ) Ali Stole from D? You mean java right? Java doesn't have pointers.
Re: Anyone working on updated Qt bindings?
On Saturday, 3 October 2015 at 08:25:25 UTC, Manu wrote: On 3 October 2015 at 11:58, Jeremy DeHaan via Digitalmars-d wrote: I know a lot of people wish they had new bindings for Qt, so I was going to> give it a go soon. Is anyone currently working on such a thing? I'd rather help someone than compete with them. I've spent about 2 weeks trying to get the latest Qt bound up... it's a LOT of work, but I have done a fair bit of core stuff. I can commit it somewhere if you wanna hack at it too... Yeah,that'd be great. I'm only interested in working on the latest Qt. You said two weeks and that's just been the core stuff. Are you doing the binding by hand?
Re: Anyone working on updated Qt bindings?
On Saturday, 3 October 2015 at 06:33:32 UTC, Israel wrote: On Saturday, 3 October 2015 at 01:58:01 UTC, Jeremy DeHaan wrote: I know a lot of people wish they had new bindings for Qt, so I was going to give it a go soon. Is anyone currently working on such a thing? I'd rather help someone than compete with them. btw i see youve made some changes to DSFML. DSFML master is broke with symbol and linking problems. I dont know how to fix. A little off topic to my question, don't you think? :P Yes I did make a bunch of changes to DSFML, and unfortunately I got ahead of myself when I pushed the code back into master. I had some issues packaging stuff, and I couldn't finish so I didn't make an announcement like I had planned. Basically there is a new back end that fixed a bunch of stuff, so that is your issue. You'll need to build it yourself, but it is super easy. See build tutorial here: http://dsfml.com/docs/buildingfromsource.html
Anyone working on updated Qt bindings?
I know a lot of people wish they had new bindings for Qt, so I was going to give it a go soon. Is anyone currently working on such a thing? I'd rather help someone than compete with them.
Re: Interface file
On Thursday, 1 October 2015 at 01:41:22 UTC, Jan Johansson wrote: Thanks Jeremy, Do you spot a weakness in your proposed code snip? The declaration for interface is done in two separate files, both test.d and test.di. Scattered declarations has never been a good idea. I know that I can ask the DMD to do declaration files for me, but the use case for that is to speed up building of executable. But is it that the separation of declaration and implementation was never the intention in the design of D? //Jan Having the declarations in both files is the point though. If you notice, the only difference between my test.d and test.di files is that test.di is only the declarations. The speed increase for compiling happens because of this. You still need all declarations to be there when you build, or at least the ones you use. You build the library with test.d and then build using test.di when you use the library. You never use both test.d and test.di together. Double check my build commands.
Re: Interface file
On Wednesday, 30 September 2015 at 17:51:50 UTC, Jan Johansson
wrote:
Hello all,
I'm testing D language, and the first thing I want to do is to
separate declaration from implementation. I was happy to find
support of interfaces in the D language, and set out to do a
basic test. However, this test failed, and I want some newbie
help to understand how it should be done in D language.
--
The interface file (I called it test.di):
// Interface
interface IMyTest {
void Write(string message);
}
// Factory for type implementing IMyTest
IMyTest createInstance();
--
The library file (I called it test.d):
import std.stdio;
class MyTest : IMyTest {
void Write(string message) {
writeln(message);
}
}
IMyTest createInstance() {
return new MyTest;
}
--
And finally the main file (I called it main.d):
import test;
import std.stdio;
void main() {
auto p = createInstance();
p.Write("Hello, World!");
}
--
The assumption was that I could do:
dmd test.d test.di -lib -oftest
and next do:
dmd main.d test.di test.a
The shared information is in the test.di file.
However, this failed, since the first statement generates the
following:
dmd test.d test.di -lib -oftest
Error: module test from file test.di conflicts with another
module test from file test.d
I guess it is because the file name test.d and test.di creates
conflict, surfaced as module test.
How can I accomplish what I want to do?
Kind regards,
Jan Johansson
Like Adam said, the real difference between a .d and a .di file
is that the .di file has all the guts removed and is just the
declarations.
If using a .di file is really what you want, you could try
something like this?
test.d:
module test;
interface IMyTest {
void Write(string message);
}
IMyTest createInstance() {
class MyTest : IMyTest {
void Write(string message) {
import std.stdio;
writeln(message);
}
}
return new MyTest;
}
---
test.di:
module test;
interface IMyTest {
void Write(string message);
}
IMyTest createInstance();
---
main.d:
import test;
void main() {
auto p = createInstance();
p.Write("Hello, World!");
}
--
and then
dmd test.d -lib -oftest
and
dmd main.d test.di test.a
Also like Adam said, dmd can create these .di files for you so
you don't have to!
(This is untested, but should work/be close to working)
Re: 64bit linking on Windows without Visual Studio
On Monday, 20 April 2015 at 04:32:32 UTC, Joakim wrote: There are three aspects of Visual Studio used for D's Win64 support: the Microsoft C compiler to compile a few C files in COFF64 format, the Microsoft COFF64 linker, and the Microsoft C library in COFF64 format. Replacing only one will not get you very far. As ifor the C compiler, wth DDMD around the corner that seems like it well be a non issue very soon. Really, all we would need are the linker and the libraries, right? I could still do more fiddling, but when I used this linker I used the library files that came with it almost exclusively. There was only one that I needed to add, and I'm sure that it can be figured out. I just really like the idea of a self contained D compiler set up that doesn't need any other downloads to get working.
Re: DDMD just went green on all platforms for the first time
On Saturday, 21 February 2015 at 14:02:41 UTC, Daniel Murphy wrote: https://auto-tester.puremagic.com/?projectid=10 This is a pretty big milestone for the project. For the first time, an unpatched dmd can build ddmd, and that ddmd can build druntime and phobos and pass all the test suites. Hopefully in the next couple of weeks the remaining minor issues will be fixed (eg makefile changes, ddmd runs out of memory compiling std.algorithm unittests on win64) and we can start adding ddmd to master alongside the C++ compiler. A big thanks to Brad for upgrading the autotester, and to everyone who has helped fix bugs and get patches merged over the last couple of years. Github shows 376 closed DDMD pull requests, which is about 8% of all dmd pull requests ever. This is awesome! Does that mean we're going to see a DDMD release for 2.067?
Re: Are there any 2D games libraries available for D2?
On Friday, 20 February 2015 at 18:23:09 UTC, Gan wrote: On Friday, 20 February 2015 at 15:15:36 UTC, Jeremy DeHaan wrote: On Friday, 20 February 2015 at 07:12:34 UTC, Gan wrote: On Friday, 20 February 2015 at 04:52:29 UTC, Jeremy DeHaan Chiming in with my own library. https://github.com/Jebbs/DSFML Things are a bit of a mess, but I'm gearing up for a release soon and things will be all nice and tidy and structured. I really want to check out DGame but I suggest withholding from it until it becomes actively maintained again. I'm using DSFML and it is one of the easiest. Though I had strange issues like high ram usage and text not rendering. Though the ease of use and performance is phenomenal. Thanks for the heads up. I'll open an issue to inspect RAM usage, but can you let me know when you were having Text rendering issues so I can inspect that too? This link can give you more information about it: http://en.sfml-dev.org/forums/index.php?topic=17550.0 I started getting text rendering issues when I was playing with my space background render textures. It's kinda strange cause they seem unrelated. I'll check it out, thanks!
Re: Are there any 2D games libraries available for D2?
On Friday, 20 February 2015 at 07:12:34 UTC, Gan wrote: On Friday, 20 February 2015 at 04:52:29 UTC, Jeremy DeHaan Chiming in with my own library. https://github.com/Jebbs/DSFML Things are a bit of a mess, but I'm gearing up for a release soon and things will be all nice and tidy and structured. I really want to check out DGame but I suggest withholding from it until it becomes actively maintained again. I'm using DSFML and it is one of the easiest. Though I had strange issues like high ram usage and text not rendering. Though the ease of use and performance is phenomenal. Thanks for the heads up. I'll open an issue to inspect RAM usage, but can you let me know when you were having Text rendering issues so I can inspect that too?
Re: Are there any 2D games libraries available for D2?
On Friday, 20 February 2015 at 00:07:20 UTC, Kingsley wrote: On Thursday, 19 February 2015 at 23:59:14 UTC, Kingsley wrote: I use Dgame which has a really nice and simple interface http://rswhite.de/dgame4/ From the web page: Dgame is a 2D framework which is based on the SDL and OpenGL, and is designed for the D programming language. The design is based on Pygame and as well on the SFML from the C++ programming language. Cheers, Stew I'm looking at DGame - I'm on osx - so I guess I have to build all the dependencies myself - Once I get it installed and working - it looks like it may be enough for what I want. I guess I'll have to make it work with dub myself to make it easier to get started with. DGame has a dependency on Derelict 3 - but going to the link provided says that project is no longer maintained and doesn't work with the latest DMD compiler. It points to a new location where there are multiple different Derelict libraries - I'm hoping DGame will work with one of those still. Chiming in with my own library. https://github.com/Jebbs/DSFML Things are a bit of a mess, but I'm gearing up for a release soon and things will be all nice and tidy and structured.
Re: Window creation, for phobos?
What about that Aurora project? Wasn't that supposed to fill this kind of role?
Re: We need a DConf 2015 logo
On Thursday, 8 January 2015 at 22:40:41 UTC, ponce wrote: There: http://ovh.to/GAYPaom - same vector logo but with text and gray background - a render in 500x150 (I've used Firefox) - instructions on how to render again Let me know if you need any change. I think that is a pretty sweet logo.
Re: i want my bounty!
On Monday, 15 December 2014 at 18:05:22 UTC, ketmar via Digitalmars-d wrote: i will not use github under any circumstances, but this will be one little step along the long "consistency road". at least nobody will be blamed for using bugzilla according to it's disclaimer. and surely i will stop ranting about that, 'cause i deliberately chose GTFO instead of github, according to rules. I don't understand your desire to avoid github, but what ever your reasons if you are willing to write updates for D there should be a way for you to get that into a pull request. Perhaps you could find a surrogate? That would allow you to stay github free but also allow your code to be up for inclusion.
Re: D3
On Tuesday, 9 December 2014 at 03:52:01 UTC, ketmar via Digitalmars-d wrote: On Mon, 08 Dec 2014 21:08:03 + Brad Anderson via Digitalmars-d wrote: On Monday, 8 December 2014 at 20:21:51 UTC, Andrej Mitrovic via Digitalmars-d wrote: > On 12/8/14, Russel Winder via Digitalmars-d > wrote: >> It seems that D3 is already available: >> >> https://github.com/mbostock/d3 > > Guess we'll just have to skip a number and call the next D - > D4. :) Major version numbers are actually in the letter so we should go to E1. there was E language too: http://en.wikipedia.org/wiki/Amiga_E with only 26 letters it's hard to be original. i'm voting for using Japan or Chineese hieroglyphs, as there are plenty of them. For Japanese it would be "ディ" which is pronounced the same as the name of the letter D.
Re: Function with same name as a module name
On Monday, 1 December 2014 at 20:29:48 UTC, Daniel Kozak via Digitalmars-d wrote: Dne Mon, 01 Dec 2014 18:10:35 +0100 Jeremy DeHaan via Digitalmars-d napsal(a): I don't think you can specify look ups with the name of the module in the same module like you can with imported ones. If you want to specify that it is a variable in module scope, use the module scope operator. writeln(.a); // the leading '.' specifies module scope You can. It doesn't work only when there is a another symbol with same name as a module. But it makes a sense. I don't see it mentioned at all in this: http://dlang.org/module.html It sounds like something was over looked. Either you shouldn't be able to specify with the module name in the same module, or you shouldn't be getting this error.
Re: Function with same name as a module name
I don't think you can specify look ups with the name of the module in the same module like you can with imported ones. If you want to specify that it is a variable in module scope, use the module scope operator. writeln(.a); // the leading '.' specifies module scope
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Tuesday, 18 November 2014 at 12:33:52 UTC, FrankLike wrote: If you migrate your projct from x86 to x64,you will find the length is error,you must modify it ,such as: int i= (something).length to size_t i = (something).length but now ,'int' is enough for use,not huge and not small,only enough. 'int' is easy to write,and most people are used to it. Most importantly easier to migrate code,if 'length''s return value type is 'int'. Thank you all. This is a weird thing to argue. just because an int is good enough for you does not mean that it is the best thing for all people.
Re: example of pointer usefulness in D
On Tuesday, 21 October 2014 at 12:40:57 UTC, w0rp wrote: On Tuesday, 21 October 2014 at 12:22:54 UTC, edn wrote: Could someone provide me with examples showing the usefulness of pointers in the D language? They don't seem to be used as much as in C and C++. You can use C libraries in D, and pointers will surely come into regular use there. You could also heap allocate structs and end up with pointers to structs. Can you do the same with classes if you wanted to avoid a GC allocation? Just wondering.
Re: Website listing both 2.065 and 2.066?
On Tuesday, 19 August 2014 at 02:35:22 UTC, Andrei Alexandrescu wrote: On 8/18/14, 7:21 PM, Jeremy DeHaan wrote: Not sure where to mention this, but I noticed that at http://dlang.org/ the compiler version is still listed as 2.065. http://dlang.org/index.html however correctly lists 2.066. worksforme It was my cahce. I cleared it and it works now. Never mind me!
Website listing both 2.065 and 2.066?
Not sure where to mention this, but I noticed that at http://dlang.org/ the compiler version is still listed as 2.065. http://dlang.org/index.html however correctly lists 2.066.
Re: Bottom line re GC in D
On Tuesday, 8 July 2014 at 03:37:51 UTC, Adrian wrote: + Has the GC been dropped? Nope, still there and probably always will be. I think I read on the forums that people are working on a better/more precise GC though. From what I understand the current one could stand a lot of improvement. + If not, can it be disabled entirely/completely? It can be, but you would also lose some features, though I'm not entirely sure which things exactly. I remember that slices was one thing you would no longer have if you disable the GC, but I can't think of any others. The GC isn't really something you would need to disable though. I have never had any issues with it, and unless you're doing something that might have it run a lot, it shouldn't affect you in any way.
Re: Is D production-ready?
On Monday, 16 June 2014 at 10:24:46 UTC, John Petal wrote: I mean, I spent a whole day trying to make DSFML work. Might I ask what issues you had getting it up and running? Things have been a little hectic for DSFML because of school, but with summer coming up I'll be able to work on fixing a bunch of things and I feel as though I am always lacking in the feedback department.
Re: Out of sight out of mind
On Sunday, 15 June 2014 at 15:37:22 UTC, Andrew Edwards wrote: Observe the following truths: 1) Issue tricking and resolution are kept separate in our community 2) That which is not visible garners no attention Presently, we file bugs/issues through issues.dlang.org, the maintenance of which is no small task and is certainly appreciated. However, it is an environment completely detached from where the actual work is performed. As such, it breeds neglect on the part of the developers: not because they do not care, but rather because they do not see. Take issue #143 for instance. It is the oldest open issue on the DLang Issue Tracking System. Submitted by Jarrett Billingsley on May 17, 2006, it received one comment two days later but was ignored for four years before Michal Minich made the second comment. Another two years went by before Martin Nowak addressed the issue, which Walter promptly reverted (reason unknown). The end result? Eight years flew by and the issue remains unresolved. This happens because we have two separate systems (one tracking problems, another tracking the resolution), both of which compete for the same precious and extremely limited resource: the volunteer time of developers. Already proven a valuable resource, GitHub offers the tools necessary to resolve this problem. The "issues" feature (not currently activated for any D-Programming-Language repo) allows us to set milestones (with due dates), assign tasks, and create and apply labels (multiple where required). Observe the following: https://github.com/AndrewEdwards/druntime/issues?state=open Note how quickly you can see the total number of open issues, traverse to any category, and identify what is important for a given milestone. We can even track our progress toward a specific milestone in seconds, or which issues we created or was assigned to us. By using this feature, we will eliminate the fire and forget problem currently observed with Bugzilla. We will be able to automatically link resolution to issue, by a mere mention of the issue number within the resolution. Issues become far more visible and, consequently, are not so easily forgotten. A complete win in my book. -Andrew I agree with this quite a lot. If for nothing else, I agree with this because I think it makes the most sense to have the place we do pull requests be the same place we track issues. There are a few other reasons I agree with this, but the point is that I would very much like to see this happen.
Re: Strange issue on OSX
On Saturday, 14 June 2014 at 02:30:56 UTC, Chris Cain wrote: On Saturday, 14 June 2014 at 02:12:45 UTC, Jeremy DeHaan wrote: I agree. Also, this page (http://dlang.org/dmd-osx.html) says that the base requirement is a 32 bit OSX. Why is the DMD version that is released 64 bit? That seems very counter intuitive. Honestly, I feel like it should be noted that you need to build from source to get the 32-bit version... but I don't see why it should be included in the actual binary release. Not even Apple supports the 32-bit hardware anymore. AFAIK, 64-bit Macs came out in late 2006, so we're talking about 8 year old hardware at this point. I didn't realize that was the case. Like I said in my original post, I haven't used a mac before this so I am pretty new to them. It definitely would have been nice if it said something about needing to build it for 32 bit OSX though. I think that would have saved me a lot of time.
Re: Strange issue on OSX
On Friday, 13 June 2014 at 15:14:00 UTC, Tolga Cakiroglu wrote: On Friday, 13 June 2014 at 07:13:36 UTC, Jacob Carlborg wrote: On 13/06/14 07:26, Tolga Cakiroglu wrote: In the download page, table shows for which CPU type they are available. dmd.2.065.0.zip shows i386 and x86_64. So, this should run on 32 and 64-bits. dmd.2.065.0.dmg shows only x86_64 which is for 64-bit CPU only. That's not correct. The zip file only contains 64bit. DMD for OS X has only been released as 64bit for quite a while now. Just run the "file" command on the dmd executable to see which platforms it supports. Well, then somebody should update what the download page lists there. At least make it clear and "correct". If I and others think or cannot understand which one to download correctly, that means there is a problem. I agree. Also, this page (http://dlang.org/dmd-osx.html) says that the base requirement is a 32 bit OSX. Why is the DMD version that is released 64 bit? That seems very counter intuitive.
Re: Strange issue on OSX
So building from source seemed to work. Is it possible that the OSX version of DMD was released as a 64 bit version? On Friday, 13 June 2014 at 03:53:30 UTC, Jeremy DeHaan wrote: Just tried downloading the .zip instead of using the installer. I got the same problem. I also tried downloading 2.064, and again I got the same error message. I did notice that not everything give me the Bad CPU Type error message. I'll try building from source and see how that goes. On Thursday, 12 June 2014 at 23:12:38 UTC, Jeremy DeHaan wrote: I wanted to try out OSX to make sure all my stuff was working fine there as well, but after downloading DMD and then running it in the terminal to make sure everything was good it gives me this error: /usr/bin/dmd: Bad CPU type in executable This is my first time using a Mac, so I could very well be doing something wrong. I didn't want to spend a lot of money, so it is a slightly older machine currently running OSX 10.6.8. It is an Intel Core Duo, which apparently won't let me upgrade to Mavericks, so I'm stuck with Snow Leopard. Any advice for what I should do? Anyone seen this error before? Thanks in advance, Jeremy
Re: Strange issue on OSX
Just tried downloading the .zip instead of using the installer. I got the same problem. I also tried downloading 2.064, and again I got the same error message. I did notice that not everything give me the Bad CPU Type error message. I'll try building from source and see how that goes. On Thursday, 12 June 2014 at 23:12:38 UTC, Jeremy DeHaan wrote: I wanted to try out OSX to make sure all my stuff was working fine there as well, but after downloading DMD and then running it in the terminal to make sure everything was good it gives me this error: /usr/bin/dmd: Bad CPU type in executable This is my first time using a Mac, so I could very well be doing something wrong. I didn't want to spend a lot of money, so it is a slightly older machine currently running OSX 10.6.8. It is an Intel Core Duo, which apparently won't let me upgrade to Mavericks, so I'm stuck with Snow Leopard. Any advice for what I should do? Anyone seen this error before? Thanks in advance, Jeremy
Strange issue on OSX
I wanted to try out OSX to make sure all my stuff was working fine there as well, but after downloading DMD and then running it in the terminal to make sure everything was good it gives me this error: /usr/bin/dmd: Bad CPU type in executable This is my first time using a Mac, so I could very well be doing something wrong. I didn't want to spend a lot of money, so it is a slightly older machine currently running OSX 10.6.8. It is an Intel Core Duo, which apparently won't let me upgrade to Mavericks, so I'm stuck with Snow Leopard. Any advice for what I should do? Anyone seen this error before? Thanks in advance, Jeremy
What can I do?
Hey all, I've been using D for a while now and I would very much like to contribute to the development of the language. Here's the problem: I know next to nothing about compilers or anything related to language design. So, my question is, how can someone like me help? Jeremy
Re: Distributing implib?
On Monday, 28 April 2014 at 03:09:32 UTC, Trent Forkert wrote: On Sunday, 27 April 2014 at 17:53:18 UTC, Jeremy DeHaan wrote: Hi all, I am doing some updates to the C back end of my binding, and I wanted to know what it would entail to be able to distribute implib along with my CMake things. I was just thinking that it would be nice to automatically produce .lib files when it builds 32bit libs on Windows systems. According to the license it comes with, I would need to obtain a redistribution license for this. Anyone else had any experience with that? Thanks much! Jeremy Nick already answered your question, but I have another suggestion for you. Set things up to look for implib (or perhaps coffimplib[1]), and complain if CMake can't find it. This tool should be part of the user's tools and environment, not part of your project. This may be my Linux bias talking, but I would tend to not want to ship binaries as part of my source. The good thing about CMake is that it can help you deal with your dependencies in a sane way. - Trent [1]ftp://ftp.digitalmars.com/coffimplib.zip That's not a bad idea, but it would suck for people that might not know what the heck implib even is and make them have to search for it. I'd like them to be able to build the library with the right import libraries right out of the box.
Distributing implib?
Hi all, I am doing some updates to the C back end of my binding, and I wanted to know what it would entail to be able to distribute implib along with my CMake things. I was just thinking that it would be nice to automatically produce .lib files when it builds 32bit libs on Windows systems. According to the license it comes with, I would need to obtain a redistribution license for this. Anyone else had any experience with that? Thanks much! Jeremy
