Re: Anyone using DMD to build 32bit on OS X?
On Monday, 11 January 2016 at 07:44:18 UTC, Jacob Carlborg wrote: I doesn't solve the problem but it's a prerequisite for solving dynamic libraries. That's why I started working on this :) Great!
Re: I hate new DUB config format
On Thursday, 26 November 2015 at 09:04:27 UTC, Ilya Yaroshenko wrote: Single language, json based configuration engine is simpler for IDE development and configuration tools. For example, Sublime Text.This is very important to make language used by big amount of users. Ilya Sublime Text configuration has no comments and this kind of sucks compared to eg. a webserver key-value configuration file, or sc.ini, so I'm not sure you chose the best example.
Re: Swift is coming, Swift is coming
On Tuesday, 24 November 2015 at 17:59:35 UTC, Joakim wrote: A Wired article about Swift coming to the server, particularly after the imminent open-sourcing, that also mentions D as an alternative, especially since it's written by the same guy who wrote about D for Wired last year: http://www.wired.com/2015/11/apples-swift-ios-programming-language-is-being-remade-for-data-centers/ Will be interesting to see how Swift does, a good natural experiment for those pushing D to focus on one niche before expanding, as Swift is doing really well on one of the most important development platforms today, iOS, before expanding onto the server. Of course, Apple is unlikely to really push it on the server, other than open-sourcing and accepting patches, so they have a built-in excuse if it doesn't do well. ;) Maybe we have a good opportunity to compete with Swift at home. Avoiding XCode, not being tied to a particular SDK, being able to target very ancient systems are some of the pluses I've found when using D with OS X. I'd bet using D for iOS can entail similar gains, and avoid being tied to an Apple language.
Re: I hate new DUB config format
On Wednesday, 25 November 2015 at 10:17:02 UTC, Suliman wrote: Also I do not see any projects that are migrate to SDL. Everybody continue to use JSON. So please, return JSON back as default, or very soon we will see that nobody do not submit packages to code.dlang.org and nobody do not use DUB for their own projects. No hate for the new format there, have not switched because I extended dub.json for the purpose of a build system that is calling DUB itself. And there is no SDL parser in the standard library. No gain, no pain.
Re: Scott Meyers wants to bring default zero-initialization to C++, mentions TDPL for precedent
On Wednesday, 18 November 2015 at 15:12:27 UTC, Joakim wrote: He advocates for a tool like gofix, to automatically convert such features to be deprecated: http://scottmeyers.blogspot.com/2015/11/breaking-all-eggs-in-c.html Good to see C++ finally trying to deprecate more, long overdue. I doubt anything will get done even in 10 years. The average C++ industrial codebase don't build with the latest compiler, or even any static analyzer, and has its own particular build system. It is already a big trouble to upgrade C++ compilers even if nothing in the language is changing. D numerous, tiny interchangeable releases are a big asset when compared to the whole compiler-tied-to-IDE-tied-to-OS-releases which is what things are in C++ land. The idea that you could bring the C++ community to use an automatic upgrade tool, or to get everyone to follow optional "Core Guidelines" is optimistic.
Re: DConf keynote speaker ideas
On Wednesday, 18 November 2015 at 10:40:47 UTC, Frank Fuente wrote: On Tuesday, 17 November 2015 at 18:47:58 UTC, Andrei Alexandrescu wrote: I'm thinking of inviting a notable industry luminary to deliver a conference keynote. Please reply to this with ideas! -- Andrei Niklaus Wirth... :-) That would be beyond awesome
Re: DConf keynote speaker ideas
On Tuesday, 17 November 2015 at 18:47:58 UTC, Andrei Alexandrescu wrote: I'm thinking of inviting a notable industry luminary to deliver a conference keynote. Please reply to this with ideas! -- Andrei Fabrice Bellard is a programming star that never ever gives talks. But it would probably be interesting.
Re: Is dlangui dead?
On Wednesday, 11 November 2015 at 07:18:21 UTC, Vadim Lopatin wrote: On Wednesday, 11 November 2015 at 06:56:10 UTC, Vadim Lopatin wrote: On Wednesday, 11 November 2015 at 06:25:35 UTC, Suliman wrote: [...] I'm not going to use native controls, only native way to create window, draw bitmap on it (or draw using OpenGL). Look and feel may be changed by correction of theme and resource files. [...] I don't see native OSX window implementation here. Implementation of OSX API accessors may be shared between different projects, and put to separate library in DUB registry. [...] It looks like DQuick uses SDL, as DlangUI does currently. I'm looking for native Cocoa based implementation. UPD: found interesting library - https://github.com/p0nce/DerelictCocoa I hope it would help It was used to implement the Cocoa windowing for dplug: https://github.com/p0nce/dplug/blob/master/window/dplug/window/cocoawindow.d It's likely you will miss some stuff, use PRs.
Re: Rust's simple download script
On Monday, 9 November 2015 at 23:15:56 UTC, Dicebot wrote: - teaches people `curl X | sh` is fine and normal and not security abomination There is even a tumblr for that :) http://curlpipesh.tumblr.com/
Re: Lifetime study group
On Tuesday, 27 October 2015 at 02:45:24 UTC, Andrei Alexandrescu wrote: Lifetime study group Ain't nobody got time for a lifetime of study? ;)
Re: DMD is slow for matrix maths?
On Tuesday, 27 October 2015 at 11:23:37 UTC, burjui wrote: On Tuesday, 27 October 2015 at 05:27:22 UTC, Jack Stouffer wrote: My intentions are to call things as they are. If people are demoralized after learning that one person working in his spare time can't match the productivity of several people working full time, then they need a reality check. Can't agree more. It's unrealistic to expect Walter work on the backend full-time just to catch up with GCC and LLVM teams, let alone support architectures other than x86 as well. Moreover, given the frequent backend regressions it might be better not to touch it too much. As of now relying on DMD for optimized builds gives constant work.
Re: Vision
On Wednesday, 21 October 2015 at 20:50:29 UTC, Andrei Alexandrescu wrote: Better late than later. http://wiki.dlang.org/Vision/2015H2_(draft) Destroy. After we make this good I'll rename it and make it official. Andrei Somehow the link isn't recognized by DFeed. Let me try with http://wiki.dlang.org/Vision/2015H2_(draft%29
Re: Kinds of containers
On Wednesday, 21 October 2015 at 11:05:12 UTC, Andrei Alexandrescu wrote: The question here is what containers are of interest for D's standard library. I think the ones in the STL work well. So I'd like something along these lines. Something like std::vector would fit 90% of my needs (eg: a slice using allocators). No interest in lock-free or immutable containers from here.
Re: Natural language parsing (NLP) with D
On Tuesday, 20 October 2015 at 12:01:44 UTC, Eliatto wrote: Why is this field unpopular among (D)evelopers? We aren't numerous, so there hasn't been anyone to tackle the NLP problems now (and many other domains). There is plenty of space to start domain-specific libraries. You could do it :)
Re: The new core.sys.windows
On Thursday, 15 October 2015 at 01:51:50 UTC, Mike Parker wrote: I think named enums are a bad idea. For one thing, it's inconsistent with the other system modules. For another, it's a pain point for porting existing C code to D. If they are kept, then at the very least aliases ought to be provided. +1 there is a lot of example code and documentation out there using the original names.
Re: Synchronized classes have no public members
On Tuesday, 13 October 2015 at 10:57:55 UTC, Marco Leise wrote: Yep, I prefer to think it sets of variables that need mutex protection. And these are not generally the set of member fields in a class. Exactly. And that makes things using synchronized prone to longer and more frequent locks.
Re: Synchronized classes have no public members
On Tuesday, 13 October 2015 at 09:07:54 UTC, Chris wrote:
On Tuesday, 13 October 2015 at 08:55:26 UTC, Benjamin Thaut
wrote:
I have to agree here. I think synchronized classes are of very
little use, especially because they don't "cast away" shared
in a useful way. It still has to be done manually. I think we
should remove them. Synchronized methods should also be
removed in my eyes. Making each and every object bigger by one
pointer just for the sake of a few synchronized methods
doesn't seem to be a good trade off to me. The entire
synchronized methods give the user the feeling that he simply
slaps synchronized on his class / method and then its thread
safe and he doesn't have to care about threads anymore. In the
real world this is far from true however. So synchronized
methods and classes just give a false sense of thread safety
and should rather be removed.
Actually, I once fell foul of this wrong impression of thread
safety via 'synchronized'. I found a different solution and
dropped synchronized.
I also dropped synchronized and use @nogc mutexes instead. I also
think synchronized methods should be removed. It's also difficult
to explain: what is a "monitor"? when you write a synchronized {
} block, which monitor is taken?
Re: D 2015/2016 Vision?
On Wednesday, 7 October 2015 at 07:24:03 UTC, Paulo Pinto wrote:
That no, but this yes (at least in C#):
using (LevelManager mgr = new LevelManager())
{
//
// Somewhere in the call stack
Texture text = mgr.getTexture();
}
--> All level resources gone that require manual management gone
--> Ask the GC to collect the remaining memory right now
If not level wide, than maybe scene/section wide.
However I do get that not all architectures are amendable to be
re-written in a GC friendly way.
But the approach is similar to RAII in C++, reduce new to
minimum and allocate via factory functions that work together
with handle manager classes.
--
Paulo
This is similar to Scoped!T in D. But this is not composable
either.
You cannot have a "using()" field in a class object, much like
you cannot have a Scoped!T field in D. In C#, you still have to
implement IDispose interface AFAIK.
Re: D 2015/2016 Vision?
On Tuesday, 6 October 2015 at 20:43:42 UTC, bitwise wrote: So, you're saying you want me to just revert back to manual resource management and accept that huge resources like textures and such may just leak if someone doesn't use them right? or throws an exception? in a language like D that is supposed to be safe? Yes. It seems everyone has this epiphany at one point in their D adventures. D is similar to Java and C# in that regard, and more manual than C++. On the plus side, you get freedom from thinking about ownership for the 30% or so of resources who only owns memory.
Re: D 2015/2016 Vision?
On Tuesday, 6 October 2015 at 20:43:42 UTC, bitwise wrote: I want polymorphism AND deterministic destruction, and the least you could do is just admit that it's a downside to D not having it, instead of trying to tell me that everything I know is wrong.. This problem comes up again and again, here is an ugly trick to ease the pain: http://p0nce.github.io/d-idioms/#GC-proof-resource-class
Re: D 2015/2016 Vision?
On Tuesday, 6 October 2015 at 17:20:39 UTC, Jonathan M Davis wrote: But in general, at this point, with D, if you want deterministic destruction, then you use structs. Classes are not the appropriate place for it. If they were ref-counted, then they could be, but as long as they're not, then classes are not the place to have stuff that cares about deterministic destruction. And if you're stuck with stuff in classes that do care about deterministic destruction, then you have to use the sort of solutions that C# and Java use where you don't rely on the destructor/finalizer to clean anything up except for the cases where you screw up and forget to manually call the function that does the cleanup. Unfortunately, it is quite common to need both virtual functions and deterministic destruction. It isn't helpful to disregard the problem by saying "you should have used a struct", in many cases it's not any easier.
Re: Looking for someone that could work on 32 bits support for SDC
On Friday, 2 October 2015 at 22:35:51 UTC, BBasile wrote: Tu arrives encore à porter des boots ? au niveau des chevilles enflées ca passe encore ? Keep it civil please.
Re: Is Anything Holding you back?
On Friday, 2 October 2015 at 18:56:32 UTC, deadalnix wrote: On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote: Are there any critical frameworks or libraries that are holding you back in fully investing in D? Obviously I think D is an awesome language, but some frameworks/libraries hold me back, wish I could do everything in D. 1/ Debug support. It is truly bad. Does not work on OSX as far as I know how, and works tediously on linux (line numbers are often wrong in GDB and do not appear ins tack trace, need to use specific linkers flags for this to work at all). On OSX I've used lldb + LDC and stack traces and line numbers are there. Symbols are not demangled though.
Re: Compile failing with D 2.068.2 works with 2.068.1
On Thursday, 1 October 2015 at 23:01:59 UTC, Zz wrote:
Can you post the code that causes the error?
I traced it to when JSONValue get is being used.
{
import stdx.data.json;
string str = `{"a": true, "b": "test"}`;
auto v = parseJSONValue(str);
// The following line causes the problem in 2.068.2
auto obj = v.get!(JSONValue[string]);
}
Zz
Please enter a bugzilla issue, else it will be forgotten.
Re: Is Anything Holding you back?
On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote: Are there any critical frameworks or libraries that are holding you back in fully investing in D? Obviously I think D is an awesome language, but some frameworks/libraries hold me back, wish I could do everything in D. I'd say kickass codegen from DMD but it seems it's getting improvements. Nothing held me back :) Now writing D full-time.
Re: Moving back to .NET
On Wednesday, 30 September 2015 at 04:59:22 UTC, H. S. Teoh wrote: I find these kinds of comments rather humorous, actually. Every once in a while, somebody would barge into the forum and decry the current state of things, bemoaning that D is too Linux-centric and that Windows gets no love. Then some time later, somebody else barges in, complaining about why he failed to install D on his Linux box and that the D developers must therefore be Windows people and D needs more Linux love. I've seen both types of complaints. So which is it? Is D Windows-centric or Linux-centric? Maybe the answer is neither, it's the PBCAK problem. ;-) D is complaints-centric :)
Re: zip packages to pack modules
On Tuesday, 29 September 2015 at 14:24:03 UTC, tcak wrote: ZIP packages in no way make any change in the language. There is no need for pragmas even. There is no this simple (e.g. dmd main.d library.zip) substitute for it at the moment. You can do it with a dmd frontend, if an argument finish in .zip, then unzip it in a temporary directory, then call dmd. Passthrough all other flags. On the other hand, I can only recommend you to use DUB. It made things way more simpler than they were, but you do need to learn it.
Re: Indicators and traction…
On Wednesday, 23 September 2015 at 15:09:53 UTC, Nick Sabalausky wrote: This is engineering, not fucking fashion. Popularity has no place in decision making here. From everything I've seen, 90% of the problems that exist in computing technology today can be traced back directly to some jackass(es) weighing popularity higher than actual technical merit. Companies use whatever the money-making competition use, and often bias their evaluations to favor doing things in the same way. Look at all these stories about Twitter/Facebook/WebStartup technology stack. They wouldn't be anything interesting if they weren't famous. But they are visible and make money, so what they use must be the right thing.
Re: GuiDub
On Tuesday, 29 September 2015 at 07:43:10 UTC, Sönke Ludwig wrote: I'd say that there simply are version conflicts within this huge dependency graph (e.g. "meatbox" requires "gl3n" 1.1.0, but another dependency requires 1.0.0). The current dependency resolution algorithm (which is planned to be revamped) is quite bad at outputting good error messages in many situations (technically there often isn't an unambiguous error message, but then it often picks one of the less helpful ones). I think you said once that the dependency resolution is NP-complete. Could you provide a layman description of what is this particular problem? Just curiosity.
Re: GuiDub
On Tuesday, 29 September 2015 at 05:17:42 UTC, Jacob wrote: "dsfml": "~master", "std_event": "~master", "derelict_extras-glib": "~master", "netstack": "~master", "luad": "~master", "three-d": "~master", "grape": "~master", "civge": "~master", "nitro": "~master", "nitro-gen": "~master", "process-stats": "~master", "llvm-d": "~master", Packages that don't have one version tag are probably unmaintained.
Re: GuiDub
On Tuesday, 29 September 2015 at 05:17:42 UTC, Jacob wrote: Does anyone actually maintain all this or use it? Cause surely I shouldn't be getting errors like this? I have about 50 packages in my dub.json and they all came from copying the dependency directly(so no mistake on my part). Some advices: - do not use the "umbrella" packages like "dplug" but rather the sub-packages like "dplug:dsp". This will reduce the number of dependencies. - cut the number of dependencies to the minimum. For example you have freeimage AND imaged who overlap quite a bit. More dependencies = more problems. Add them one by one IF they are needed and after evaluating them. - before relying on a dependency, check that it looks maintained, has travis-ci integration, and build. Without editing anything, you can do: dub test thatpackage anywhere and it should download and build the tests. - if given the choice, use a derelict binding vs a statically linked dependency. This will make things a tad easier.
Re: Moving back to .NET
On Friday, 25 September 2015 at 07:26:13 UTC, rumbu wrote: I don't buy this, command line is something obsolete compared to any gui/web interface, at least in Windows world. I don't get this, Windows shops have programmers and the command-line is used as much as everywhere.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Friday, 25 September 2015 at 00:25:54 UTC, Manu wrote: I update DMD yesterday, it couldn't work out where it was installed and the uninstall fails, then complains and errors when trying to install over the failed uninstall, requiring manual intervention. I don't use the D installer because I don't trust it to deal with PATH correctly.
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Friday, 25 September 2015 at 00:25:54 UTC, Manu wrote: As a rule, no tool should ever require a windows user to interact with their path variable. It's a colossal mess, windows doesn't do 'PATH'. Mine has an endless list of bin directories, and many/most of them provide duplicates of the same programs. A robust program can never rely on PATH. I also got the same problems. For LDC is is currently necessary to have VS2015 and fix-up paths like that: The PATH varible should preferably omit the DMD path and include: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE The LIB env-variable should have the paths: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\LIB\amd64 C:\Program Files (x86)\Windows Kits\10\lib\10.0.10150.0\ucrt\x64 C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6\lib\um\x64 C:\Program Files (x86)\Windows Kits\8.1\lib\winv6.3\um\x64 Super-annoying to do so I have a tool that call DUB frontend to do that (it also build Mac bundles). I'm not sure whose job it is to put things in PATH or LIB. But as it is, everyone that tries will stumble onto this.
Re: Moving back to .NET
On Friday, 25 September 2015 at 03:00:12 UTC, Jonathan M Davis wrote: Unfortunately, at my current job, we're entirely Windows, so everything's a huge mess in VS rather than using cmake, and most of the devs are totally Windows devs, so they'd probably freak out at the idea that the .vcproj files are generated, and you don't edit any settings inside of VS. When we had around 100+ .vcxproj, I started making a static analyzer to check them. At 150+, someone made a build tool with versionned dependencies that also generated .vcxproj. It was remarkably similar to DUB.
Re: Indicators and traction…
On Wednesday, 23 September 2015 at 18:57:21 UTC, Ola Fosheim Grostad wrote: Except D2's already surpassed D1 :) That's true, although D1 had a more active library producing community? I think it was way worse than today, because of the Tango/Phobos split, few people using DSSS, or "bud", or other build tools.
Re: Moving back to .NET
On Wednesday, 23 September 2015 at 10:03:28 UTC, Ola Fosheim Grøstad wrote: Another question is: what kind of competing solutions are emerging. Herb Sutter seems to have focused his cppcon talk on Rust style memory management in C++. The adoption of Rust does force the C++ designers to switch gears and hopefully the competition will create a push for better solutions. Nitpick: "Rust style memory management" aka scoped ownership originated in C++ AFAIK, with auto_ptr and Boost containers of owned objects. Rust enforces it but did not invent it.
Re: Stroustrup is disappointed with D :(
On Wednesday, 23 September 2015 at 08:27:43 UTC, ponce wrote: On Tuesday, 22 September 2015 at 18:58:31 UTC, Tourist wrote: "D disappointed me so much when it went the Java way". https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#to-do-unclassified-proto-rules It just is very simple in D: first assign .init, then call the destructor, virtual calls allowed (of course!). the call the *constructor*
Re: Stroustrup is disappointed with D :(
On Tuesday, 22 September 2015 at 18:58:31 UTC, Tourist wrote: "D disappointed me so much when it went the Java way". https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#to-do-unclassified-proto-rules It's something about virtual calls, but I didn't understand what he means. What does he mean? I fail to see how the multi-part C++ object initialization is any better than the one of D. It just is very simple in D: first assign .init, then call the destructor, virtual calls allowed (of course!). The weird rules of virtual functions in ctor/dtor in C++ just feel like one more special case. It doesn't even seem more efficient, quite the contrary. But it makes good interview questions I guess.
Jai Primer
Something written down about the Jai language. https://sites.google.com/site/jailanguageprimer/
Re: Desperately looking for a work-around to load and unload D shared libraries from C on OSX
On Thursday, 17 September 2015 at 21:13:46 UTC, bitwise wrote:
On Thursday, 17 September 2015 at 20:47:49 UTC, Jacob Carlborg
wrote:
On 2015-09-17 21:42, bitwise wrote:
Ok, but this kinda defeats the purpose, as the op wants to
unload the
library ;)
He said he doesn't want dlopen to crash, if it doesn't unload
it fixes the problem ;)
True. Looking at his bug report now, it seems his dylib is a
VST plugin. Had he just said that to begin with, this
conversation would have been a lot easier -_-
The op shouldn't have to actually modify druntime in this case.
He shouldn't have to replace
"_dyld_register_func_for_add_image".
He can simply create a second empty callback in VSTPluginMain
which will pin his library:
static bool didInitRuntime = false;
const char* ignoreImageLoad(
enum dyld_image_states state,
uint32_t infoCount,
const struct dyld_image_info info[])
{
// ignore.
}
extern(C) void* VSTPluginMain(void* hostCallback)
{
import core.runtime;
if(!didInitRuntime)
{
Runtime.initialize();
dyld_register_image_state_change_handler(
dyld_image_state_initialized,
&ignoreImageLoad);
didInitRuntime = true;
}
import std.stdio;
import core.stdc.stdio;
printf("Hello !\n");
// Runtime.terminate();
return null;
}
Bit
Much success.
Not only did this work, it worked (around) right away!
Final patch here:
https://github.com/p0nce/dplug/commit/7dc6385ebb8147cc53cfe69bfd54e41f5341e158
Thanks to you all and I will for sure include your name in the
release notes.
You removed a huge roadblock on my path to being relevant.
Re: Desperately looking for a work-around to load and unload D shared libraries from C on OSX
On Thursday, 17 September 2015 at 20:47:49 UTC, Jacob Carlborg wrote: On 2015-09-17 21:42, bitwise wrote: Ok, but this kinda defeats the purpose, as the op wants to unload the library ;) He said he doesn't want dlopen to crash, if it doesn't unload it fixes the problem ;) Yes, it would help.
Re: Desperately looking for a work-around to load and unload D shared libraries from C on OSX
On Thursday, 17 September 2015 at 16:42:52 UTC, bitwise wrote: One solution which could work is to disallow static linking of druntime on OSX completelymeaning, either don't even distribute a static druntime for OSX, or make shared druntime the default. This way, druntime would only ever be initialized once per process. Knowing this, linux ctors/dtors could be added to druntime to initialize it, eliminating the need to call rt_init/rt_term before and after main(). Also, if druntime were loaded into a C-hosted binary, druntime would automatically be initialized by the ctors/dtors. Also, for the ctors/dtors, they could be added to the druntime build, and wouldn't having to be compiler generated. I'm not sure about the difference in performance cost over static vs shared druntime, but it seems that this is the way things are done on OSX. If you look in /usr/lib/ on a mac, practically everything is a shared lib. Bit I use static linking of druntime already all the time and rely on it to be able to do something instead of nothing (where would I even found that shared druntime?). Apart from this one horrible bug, static runtime seems very much working. Remove possibilities to do work would make my situation worse. I can call rt_init / rt_term at the right place with LDC global constructor/destructors no problem. The problem is this callback that cannot be removed. Don't know why it's there in the first place since by definition a shared library can't control when it's unloaded.
Re: Desperately looking for a work-around to load and unload D shared libraries from C on OSX
On Thursday, 17 September 2015 at 15:12:43 UTC, Jacob Carlborg wrote: Easiest would be to not unload the library. I don't control what the host program does. If that doesn't work, replace "_dyld_register_func_for_add_image" [1] with "dyld_register_image_state_change_handler" [2]. [1] https://github.com/D-Programming-Language/druntime/blob/master/src/rt/sections_osx.d#L76 [2] http://www.opensource.apple.com/source/dyld/dyld-353.2.3/include/mach-o/dyld_priv.h Looks good.
Re: Desperately looking for a work-around to load and unload D shared libraries from C on OSX
On Wednesday, 16 September 2015 at 23:24:29 UTC, bitwise wrote:
I was trying to solve this one myself, but the modifications to
DMD's backend that are needed are out of reach for me right now.
If you're willing to build your own druntime, you may be able
to get by.
I'd prefer a solution that works with existing compilers, but
maybe building a custom LDC is possible if I figure it out.
If I understand correctly, you want to repeatedly load/unload
the same shared library, correct? I ask because druntime for
osx only supports loading a single image at a time:
https://github.com/D-Programming-Language/druntime/blob/1e25749cd01ad08dc08319a3853fbe86356c3e62/src/rt/sections_osx.d#L26
In practive I've found that the D shared libraries I produce can
be dlopen/dlclose any number of times, simultaneous too. Using
both LDC and DMD, don't know why it works.
The thing that doesn't work is the C host program dlopen'ing the
shared library, dlclose it, then dlopen another shared library
written in C.
Anyways, when main() of a D program runs, it calls rt_init()
and rt_term(). If you don't have a D entry point in your
program, you have to retrieve these from your shared lib(which
has druntime statically linked) using dlsym() and call them
yourself.
I don't control the host program. My shared libs do have an
entrypoint, from which I call Runtime.initialize().
I can also use LDC global constructor/destructor to call
Runtime.initialize / Runtime.terminate, but it doesn't work any
better because of the callback.
https://github.com/D-Programming-Language/druntime/blob/478b6c5354470bc70e688c45821eea71b766e70d/src/rt/dmain2.d#L158
Now, initSections() and finiSections() are responsible for
setting up the image. If you look at initSections(), the
function "_dyld_register_func_for_add_image" is the one that
causes the crash, because there is no way to remove the
callback, which will reside in your shared lib.
https://github.com/D-Programming-Language/druntime/blob/1e25749cd01ad08dc08319a3853fbe86356c3e62/src/rt/sections_osx.d#L76
So what happens is, when you call
_dyld_register_func_for_add_image, dyld will call your callback
for every shared-library/image(including the main application's
image) that is currently loaded. However, you can skip the
callback and just call "sections_osx_onAddImage" yourself.
You would have to add something like this to sections_osx.d,
and call it instead of adding the callback:
void callOnAddImage()
{
// dladdr() should give you information about the
// shared lib in which the symbol you pass resides.
// Passing the address of this function should work.
Dl_info info;
int ret = dladdr(cast(void*)&callOnAddImage, &info);
assert(ret);
// "dli_fbase" is actually a pointer to
// the mach_header for the shared library.
// once you have the mach_header, you can
// also retrieve the image slide, and finally
// call sections_osx_onAddImage().
mach_header* header = cast(mach_header*)info.dli_fbase;
intptr_t slide = _dyld_get_image_slide(header);
sections_osx_onAddImage(header, slide);
}
Now, if you look at finiSections(), it seems to be incomplete.
There is nothing like sections_osx_onRemoveImage, so you'll
have to complete it to make sure the library is unloaded
correctly:
https://github.com/D-Programming-Language/druntime/blob/1e25749cd01ad08dc08319a3853fbe86356c3e62/src/rt/sections_osx.d#L83
You'll may have to make other mods here and there to get this
working correctly, but this is the bulk of it.
Bit
Thanks for your answer. This is really helpful, though I don't
understand the first thing about what images, headers and
sections are in this context.
Desperately looking for a work-around to load and unload D shared libraries from C on OSX
Context: On OSX, a C program can load a D shared library but once unloaded the next dlopen will crash, jumping into a callback that doesn't exist anymore. I've filed it here: https://issues.dlang.org/show_bug.cgi?id=15060 It looks like this was known and discussed several times already: http://forum.dlang.org/post/vixoqmidlbizawbxm...@forum.dlang.org (2015) https://github.com/D-Programming-Language/druntime/pull/228 (2012) Any idea to work-around this problem would be awesome. I'm not looking for something correct, future-proof, or pretty. Any shit that still stick to the wall will do. Anything! The only case I need to support is: C host, D shared library, with runtime statically linked. Please help!
Re: Implement the "unum" representation in D ?
On Tuesday, 15 September 2015 at 09:35:36 UTC, Ola Fosheim Grøstad wrote: http://sites.ieee.org/scv-cs/files/2013/03/Right-SizingPrecision1.pdf That's a pretty convincing case. Who does it :)?
Re: Implement the "unum" representation in D ?
On Tuesday, 15 September 2015 at 07:57:01 UTC, deadalnix wrote: On Tuesday, 15 September 2015 at 07:07:20 UTC, ponce wrote: On Tuesday, 15 September 2015 at 05:16:53 UTC, deadalnix wrote: The guy seems to have good credential. Why should I read that book ? The sample chapter dissipates a bit the marketing cloud. One of the ideas is that the imprecise bit encode an interval between 2 values, hence automatically computing the "precision" of a computation without analysis. Read it. That is suddenly much less impressive, but much more sensible. I can see this being useful since nowadays in the native space we often choose between single and double precision with ad-hoc oral rules and learned habits rather than measuring precision. However if unum aren't fast, they will be only for prototyping and the real algorithm would rely on IEEE floats with different precision characteristics, so yeah hardware is critical.
Re: Implement the "unum" representation in D ?
On Tuesday, 15 September 2015 at 05:16:53 UTC, deadalnix wrote: The guy seems to have good credential. Why should I read that book ? The sample chapter dissipates a bit the marketing cloud. One of the ideas is that the imprecise bit encode an interval between 2 values, hence automatically computing the "precision" of a computation without analysis.
Re: DUB release candidate 0.9.24-rc.3 ready for testing
On Monday, 14 September 2015 at 11:45:13 UTC, Sönke Ludwig wrote: If no regressions show up in this RC, the final release will be made on the upcoming Sunday. The main additions are support for SDLang [1] package recipes [2] and a vastly improved "dub describe". Download: http://code.dlang.org/download Change log: https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md [1]: http://sdl.ikayzo.org/display/SDL/Home [2]: http://code.dlang.org/package-format?lang=sdl It would be great if https://github.com/D-Programming-Language/dub/pull/638 would be merged, it contains multiple fixes for being able to use LDC. One of the commit here is controversial, but it wouldn't happen if DUB wouldn't pass multiple -march flags to compilers (DMD support redundant -m32/-m64, LDC doesn't).
Re: dmd codegen improvements
On Sunday, 13 September 2015 at 17:30:12 UTC, BBasile wrote: It seems that since the Pentium I, ENTER is always slower. But i don't know if it's used as a kind of optimization for the binary size. Actually before using DMD I had **never** seen an ENTER. Same here, I thought nobody used this one instruction.
Re: A collection of DIPs
On Friday, 11 September 2015 at 01:04:56 UTC, Brandon Ragland wrote: And @nogc is just a band-aid fix. Might as well go back to C or C++ and leave the silly @nogc behind with all it's weird integration rules when working around managed memory. Some of us use and need @nogc all the time. The other parts of an application can use the GC: best of both worlds.
Re: A collection of DIPs
On Wednesday, 9 September 2015 at 18:21:32 UTC, NX wrote: If I had the time and knowledge I would spend them to make D better, but you can't expect a teenager (tip: me) to help making DMD front-end better or to implement a precise GC... I guess? You wouldn't know what people have done with D while being students. For example, std.regex.
Re: Compile all-of-dub?
On Wednesday, 9 September 2015 at 13:48:16 UTC, qznc wrote: On Wednesday, 9 September 2015 at 12:02:55 UTC, Jacob Carlborg wrote: I think it's a great idea. This has been suggested before. The objections were that: * If you do find a problem who should be responsible for figuring out if it's a regression or an intended change? It does raise the bar for language changes. Most changes should be backwards compatible. For intended changes it forces us to come up with a way to automatically detect and ideally fix it (dfix?). In an ideal world, I would imagine it like this: Tester finds a package breaks. Package is on Github, so Tester can file an issue there. Tester checks out the source from repo, runs dfix, sends pull request referencing the issue. * Not all packages are maintained enough to keep up with all compiler changes Then it would be quite interesting to know about this and provide this information at code.dlang.org, like "broken for 2.068.0 and above". There was a thread in announce in the last 12 months that announced a site (was it ddocs.org?) that had documentation for every package in the DUB registry, for each tag. I think it also reported build problems. Don't know why it went offline.
Re: A collection of DIPs
On Wednesday, 9 September 2015 at 06:48:45 UTC, NX wrote: Woah! I didn't know about private members are visible in it's module, but to me it feels much cleaner if it was achieved by something similar to what I suggested... Isn't it? never mind... Everything in the same module is friend to everything. That's D take on friendship.
Re: Can we have strcu with destructor have postblit disabled if none is provided ?
On Saturday, 5 September 2015 at 22:22:03 UTC, deadalnix wrote: Can we have strcu with destructor have postblit disabled if none is provided ? I also feel like post-blit should be opt-in.
Re: Interesting user mistake
On Friday, 4 September 2015 at 18:55:03 UTC, Mint wrote: On Friday, 4 September 2015 at 17:17:26 UTC, Andrei A simple solution would be to just have unary + perform integer promotion, as it does in C. Wait, what? Is this another secret difference from C integer promotion rules?
Re: A Small Enhancement Idea
On Wednesday, 2 September 2015 at 16:28:12 UTC, Jack Stouffer wrote: I wanted some second opinions on an idea I had for D before I made a bugzilla issue. Currently in D, to have a statement run only in debug mode, you can mark it with the debug keyword. But, there is currently no way to mark a statement so that it only runs in release. So what I propose is a release statement like so: -release and -debug are decorrelated. Your program can have both switch or none of them.
Re: A Small Enhancement Idea
On Wednesday, 2 September 2015 at 16:40:04 UTC, ponce wrote: On Wednesday, 2 September 2015 at 16:28:12 UTC, Jack Stouffer wrote: I wanted some second opinions on an idea I had for D before I made a bugzilla issue. Currently in D, to have a statement run only in debug mode, you can mark it with the debug keyword. But, there is currently no way to mark a statement so that it only runs in release. So what I propose is a release statement like so: -release and -debug are decorrelated. Your program can have both switch or none of them. And here is the answer to your next question: so what does -release do exactly? http://p0nce.github.io/d-idioms/#So-what-does--release-do,-exactly?
Re: GC-proof resource classes
On Tuesday, 1 September 2015 at 08:26:02 UTC, cym13 wrote: By the way, why not add this to your idiom page? I think it would be valuable information. Already there! http://p0nce.github.io/d-idioms/#GC-proof-resource-class
Re: GC-proof resource classes
On Monday, 31 August 2015 at 14:18:43 UTC, byron wrote:
```
class MyResource
{
void* handle;
this()
{
handle = create_handle();
}
close()
{
if (handle !is null)
{
synchronized {
if (handle !is null) {
free_handle(handle);
}
}
handle = null;
}
}
~this()
{
close();
}
}
```
Used to do like that modulo the synchronized (which makes sense
considering destructors are run after all threads are unpaused).
The problem is that relying on GC destructors tends to come bite
later imho.
Re: Dazz new description for D
On Monday, 31 August 2015 at 13:22:16 UTC, CraigDillabaugh wrote: This one gets my vote ... however did you mean 'crack cocaine'? Thought that one existed!
Re: GC-proof resource classes
On Monday, 31 August 2015 at 12:54:05 UTC, Sebastiaan Koppe wrote:
What about:
```
class MyResource
{
void* handle;
this()
{
handle = create_handle();
}
close()
{
if (handle)
free_handle(handle)
handle = null;
}
~this()
{
enforce(!handle,"Resource leak");
}
}
```
Unique!T destructor calls delete which calls ~this() not close()
RefCounted!T and scoped!T call .destroy which calls ~this() not
close()
We really want one thing there.
Re: GC-proof resource classes
On Saturday, 29 August 2015 at 13:14:26 UTC, ponce wrote: Looks ugly? Yes, but it makes the GC acts as a cheap leak detector, giving accurate messages for still opened resources. So, let me tell a little success story while using the "GC-proof" resource classes. I tested the above idiom on some code I was a bit liberal with and with no thought gone into clean-up. I found all resource leaks in ~1 hour, and there was several of them. The open question that remains is: "can ~this() really be called multiple times?", that would made the idiom less ugly (had to add boolean flags for most resources).
Re: Dazz new description for D
On Monday, 31 August 2015 at 07:38:18 UTC, Enamex wrote: Some posters on reddit remarked that D's sales pitch on the website is unnecessarily long and unindicative. I'm only making a suggestion; suggest others or comment on this one: D is a multiparadigm systems programming language with excellent static introspection that lets you choose exactly what to pay for. D is a joy to write and easy to maintain: it's systems scripting with native performance. Turned out too long :/ "D is the crack heroin of programming language. The first dose is free."
Re: GC-proof resource classes
On Sunday, 30 August 2015 at 21:52:37 UTC, ZombineDev wrote: On Sunday, 30 August 2015 at 20:44:17 UTC, ponce wrote: In the case the destructor isn't called by the GC, the call must succeed. GC.malloc(1) fits the bill but it's a waste of time and memory indeed. GC.free() would fail in both cases if I understand correctly. As you can see from the output (http://dpaste.dzfl.pl/aa004554034a), when GC.free(cast(void*)1) is called in main() it doesn't throw. It only throws in the destructor of A, because a GC collection is taking place. If you look at the implementation, it is more or less guaranteed that: a) GC.free() during collection -> InvalidMemoryOperationError [1] b) GC.free() with invalid pointer -> no-op [2] Cool thing. Perhaps as a getter like GC.isRunning()? Yeah, that's what I had in mind. But maybe it also makes sense to provide a way to take the GC lock? Of course, such method should definitely be marked as @system. [1]: https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L879 [2]: https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L888 I'm not sure there is even a need for synchronization since other threads that wan't to allocate try to take the GC lock while the GC-hijacked thread calls destructors. And if the destructor isn't called by the GC, I don't see a problem either.tre
Re: GC-proof resource classes
On Sunday, 30 August 2015 at 17:00:23 UTC, ZombineDev wrote:
On Saturday, 29 August 2015 at 13:14:26 UTC, ponce wrote:
ensureNotInGC() is implemented like this:
void ensureNotInGC(string resourceName) nothrow
{
debug
{
import core.exception;
try
{
import core.memory;
void* p = GC.malloc(1); // not ideal since it
allocates
return;
}
catch(InvalidMemoryOperationError e)
{
import core.stdc.stdio;
fprintf(stderr, "Error: clean-up of %s incorrectly
depends on destructors called by the GC.\n", resourceName.ptr);
assert(false); // crash
}
}
}
--
...
BTW, you can use GC.free, instead of GC.malloc, with any
non-zero invalid memory address, for example:
http://dpaste.dzfl.pl/af0dc9aaa29d
In the case the destructor isn't called by the GC, the call must
succeed.
GC.malloc(1) fits the bill but it's a waste of time and memory
indeed. GC.free() would fail in both cases if I
understand correctly.
A more robust solution would be to check if the gcx.running
flag is raised, or if the GC lock is taken, like this:
https://gist.github.com/ZombineDev/14076777dff7d879d659,
however this is not currently possible, because the _gc
variable in gc.proxy is private and by default gc.proxy is not
part of the include files.
Those two would work better than GC.malloc indeed. A nice thing
is that it seems we don't need synchronization so _gc.gcx.running
would be ideal.
Since it's really straightforward to expose the information to
the user, I think this would an easy enhancement.
Perhaps as a getter like GC.isRunning()?
Re: GC-proof resource classes
On Sunday, 30 August 2015 at 11:45:36 UTC, skoppe wrote: On Sunday, 30 August 2015 at 09:54:31 UTC, ponce wrote: On Saturday, 29 August 2015 at 16:12:52 UTC, skoppe wrote: I don't think it is a good idea to call create_handle() in the constructor. Why not just pass a handle into the Resource? This isn't related to the topic. By putting create_handle in the constructor, you inevitably end up putting free_handle in some (destructor) function. The problems you are having might be different/easier when you make something else do the (de)construction. Like, say, a ResourceManager. The handle is not important, the idiom applies equally to any class with a non-trivial destructor.
Re: GC-proof resource classes
On Saturday, 29 August 2015 at 16:12:52 UTC, skoppe wrote: I don't think it is a good idea to call create_handle() in the constructor. Why not just pass a handle into the Resource? This isn't related to the topic.
Re: GC-proof resource classes
On Saturday, 29 August 2015 at 14:17:10 UTC, rsw0x wrote: All of this could be fixed by not letting the GC call destructors. It's a bad, error-prone design to begin with and I guarantee any semi-large D program is probably abusing undefined behavior due to it. Indeed.
Re: GC-proof resource classes
On Saturday, 29 August 2015 at 13:43:33 UTC, cym13 wrote: But nobody's linking the destructor to it because of the separation of concerns principle: we release what has to be released and only that: freeing the object is the realm of the GC. I see what you mean, but Unique!T, RefCounted!T and scoped!T call the destructor, not the release() function you just defined. So separating concerns break those.
Re: GC-proof resource classes
On Saturday, 29 August 2015 at 13:43:33 UTC, cym13 wrote:
But that introduce accidentally correct design when the
destructor is called by GC, and avoids a leak. This is
arguably worse than the initial problem.
I'd like to see a concrete example of this, it seems I'm
missing something...
Example 1:
You forget to release Resource A. The GC happen to call A
destructor that releases it. But GC destructors are not
guaranteed to happen.
See http://dlang.org/class.html ("The garbage collector is not
guaranteed to run the destructor for all unreferenced objects").
Example 2:
Resource A depends on Resource B. You forget to release either.
The GC happens to call A and B destructors in the right order, by
chance. A new D release changes this order later.
GC-proof resource classes
As a library writer I've struggled a bit with to provide easy
resource clean-up despite using class objects.
Is there reasons to use class objects that hold resources in the
first place vs Unique!T or RefCounted!T structs?
I think yes:
- classes have reference semantics without naming or runtime
overhead: you read Resource and not RefCounted!Resource
- no need to disable the postblit or have a valid .init is
another thing
That's about it from the top of my head and it may not be good
reasons!
As you probably know GC-called destructors enjoy a variety of
limitations:
- can't allocate,
- can't access members,
- aren't guaranteed to happen at all.
This makes GC-called destructors mostly useless for non-memory
resource release. IIRC Andrei suggested once that destructors
shouldn't be called at all by the GC, something that I agree with.
As such, some of us started providing a
release()/dispose()/close() method, and have the destructor call
it to support both scoped ownership and manual release.
But that introduce accidentally correct design when the
destructor is called by GC, and avoids a leak. This is arguably
worse than the initial problem.
It turns out separating calls of ~this() that are called by the
GC from those that are called for a deterministic reason is
enough, and support all cases I can think of:
Unique!T/scoped!T/.destroy/RefCounted!T/manual/GC-called
It works like this:
class MyResource
{
void* handle;
this()
{
handle = create_handle();
}
~this()
{
if (handle != null) // must support repeated calls for
the case (called by .destroy + called by GC later)
{
ensureNotInGC("MyResource");
free_handle(handle);
}
}
}
ensureNotInGC() is implemented like this:
void ensureNotInGC(string resourceName) nothrow
{
debug
{
import core.exception;
try
{
import core.memory;
void* p = GC.malloc(1); // not ideal since it
allocates
return;
}
catch(InvalidMemoryOperationError e)
{
import core.stdc.stdio;
fprintf(stderr, "Error: clean-up of %s incorrectly
depends on destructors called by the GC.\n", resourceName.ptr);
assert(false); // crash
}
}
}
--
Looks ugly? Yes, but it makes the GC acts as a cheap leak
detector, giving accurate messages for still opened resources.
Re: string <-> null/bool implicit conversion
On Thursday, 20 August 2015 at 16:45:18 UTC, Márcio Martins wrote: Hi! string a = ""; string b; writeln(a ? "a" : "null"); writeln(b ? "b" : "null"); This program outputs: a null What? I suppose this is by design, but are there any plans to deprecate this? Sounds correct to me.
Re: Object.factory() and exe file size bloat
On Friday, 21 August 2015 at 05:06:47 UTC, Walter Bright wrote: What do you think? Do function pointer types also have TypeInfo? Derelict libraries has hundreds of them and my belief is that they are related. There were complaints about bloat at times. Those function pointer types typically don't need anything that TypeInfo provides.
Re: dmd codegen improvements
On Wednesday, 19 August 2015 at 10:16:18 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 19 August 2015 at 10:08:48 UTC, ponce wrote: Even in video codec, AVX2 is not that useful and barely brings a 10% improvements over SSE, while being extra careful with SSE-AVX transition penalty. And to reap this benefit you would have to write in intrinsics/assembly. Masked AVX instructions are turned into NOPs. So you can remove conditionals from inner loops. Performance of new instructions tend to improve generation by generation. Loops in video coding already have no conditional. And for the one who have, conditionals were already removeable with existing instructions. For AVX-512 I can't even imagine what to use such large register for. Larger registers => more spilling because of calling conventions, and more fiddling around with complicated shuffle instructions. There is a steep diminishing returns with increasing registers size. You have to plan your data layout. Which is why libraries should target it, so end users don't have to think too much about it. If your computations are trivial, then you are essentially memory I/O limited. SOA processing isn't really limited by shuffling. Stuff like mapping a pure function over a collection of arrays. I stand by what I know and measured: previously few things are speed up by AVX-xxx. It almost always better investing this time to optimize somewhere else.
Re: dmd codegen improvements
On Wednesday, 19 August 2015 at 09:55:19 UTC, Dmitry Olshansky wrote: On 19-Aug-2015 12:46, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= " wrote: On Wednesday, 19 August 2015 at 09:29:31 UTC, Dmitry Olshansky wrote: I do not. I underestime the benefits of tons of subtle passes that play into 0.1-0.2% in some cases. There are lots and lots of this in GCC/LLVM. If having the best code generated out there is not the goal we can safely omit most of these focusing on the most critical bits. Well, you can start on this now, but by the time it is ready and hardened, LLVM might have received improved AVX2 and AVX-512 code gen from Intel. Which basically will leave DMD in the dust. On numerics, video-codecs and the like. Not like compilers solely depend on AVX. Even in video codec, AVX2 is not that useful and barely brings a 10% improvements over SSE, while being extra careful with SSE-AVX transition penalty. And to reap this benefit you would have to write in intrinsics/assembly. For AVX-512 I can't even imagine what to use such large register for. Larger registers => more spilling because of calling conventions, and more fiddling around with complicated shuffle instructions. There is a steep diminishing returns with increasing registers size.
Re: dmd codegen improvements
On Tuesday, 18 August 2015 at 10:45:49 UTC, Walter Bright wrote: Martin ran some benchmarks recently that showed that ddmd compiled with dmd was about 30% slower than when compiled with gdc/ldc. This seems to be fairly typical. I'm interested in ways to reduce that gap. There are 3 broad kinds of optimizations that compilers do: 1. source translations like rewriting x*2 into x<<1, and function inlining 2. instruction selection patterns like should one generate: SETC AL MOVZ EAX,AL or: SBB EAX NEG EAX 3. data flow analysis optimizations like constant propagation, dead code elimination, register allocation, loop invariants, etc. Modern compilers (including dmd) do all three. So if you're comparing code generated by dmd/gdc/ldc, and notice something that dmd could do better at (1, 2 or 3), please let me know. Often this sort of thing is low hanging fruit that is fairly easily inserted into the back end. For example, recently I improved the usage of the SETcc instructions. https://github.com/D-Programming-Language/dmd/pull/4901 https://github.com/D-Programming-Language/dmd/pull/4904 A while back I improved usage of BT instructions, the way switch statements were implemented, and fixed integer divide by a constant with multiply by its reciprocal. I've often looked at the assembly output of ICC. One thing that was striking to me is that it by and large it doesn't use PUSH, POP, and SETcc. Actually I don't remember such an instruction being emitted by it. And indeed using PUSH/POP/SETcc in assembly were often slower than the alternative. Which is _way_ different that the old x86 where each of these things would gain speed. Instead of PUSH/POP it would spill all registers to an RBP-based location the (perhaps taking advantage of the register renamer?). --- That said: I entirely agree with Vladimir about the codegen risk. DMD will always be used anyway because it compiles faster.
Re: Matrix API support - start with formats?
On Friday, 14 August 2015 at 18:51:51 UTC, David Nadlinger wrote: On Friday, 14 August 2015 at 15:11:39 UTC, ponce wrote: Are sparse matrices a common scenario? Yes. They tend to pop up in virtually all "serious" numerical problems in science and engineering, particularly when partial differential equations are involved. If anything I think small vectors, non-sparse matrixes and rectangles/AABB could be part of Phobos before that. If you just had a go at it from the CG/gamedev perspective, you'd probably end up with an API that is entirely unsuitable for larger problems. This might not be a big issue (just have two separate APIs), but we'd need to make it a conscious decision. One single API would be great in that case. If someone can pull it off.
Re: Matrix API support - start with formats?
On Friday, 14 August 2015 at 14:57:19 UTC, Andrei Alexandrescu wrote: I stumbled upon https://software.intel.com/en-us/node/471374 which gives good detail on Intel's Math Kernel Library's data formats for sparse matrices. No doubt other popular linear algebra libraries have similar documentation. I was thinking we could start with adding these layouts to std, along with a few simple primitives (construction, element/slice access, stride etc). Then, people may just use those as they are or link with the linalg libraries for specific computations. Thoughts? Andrei Are sparse matrices a common scenario? If anything I think small vectors, non-sparse matrixes and rectangles/AABB could be part of Phobos before that.
Re: D for Game Development
On Monday, 10 August 2015 at 14:44:42 UTC, Jacob Carlborg wrote: Shared libraries are not supported on OS X, at least not with DMD, not sure about LDC. Shared libraries works well here on OS X with LDC 0.15.2-beta2 (and only with LDC).
Re: D for Game Development
On Monday, 10 August 2015 at 01:26:44 UTC, Walter Bright wrote: On 8/9/2015 2:03 PM, ponce wrote: Once I get back to Windows I will post the report. Thank you. https://issues.dlang.org/show_bug.cgi?id=14896
Re: D for Game Development
On Sunday, 9 August 2015 at 20:24:47 UTC, Walter Bright wrote: On 8/9/2015 12:59 PM, ponce wrote: Well, for Win64 the codegen is simply wrong. I don't even care if the codegen is fast or not, but correct should be a given. Biggest problem for me so far. There's nothing I nor anyone else can do with comments like this. It passes the executable part of the test suite on Win64. If there are bugs in the Win64 code generation, I don't see any on Bugzilla. Please post incorrect codegen bugs to bugzilla. If they are already on bugzilla, please post the bug numbers. Once I get back to Windows I will post the report. The problem is that from a selfish point of view I can better optimize for my time and just disable optimizations in the faulty code, moving on to the next task. A Tragedy of the commons situation.
Re: D for Game Development
On Sunday, 9 August 2015 at 05:18:33 UTC, rsw0x wrote: On Sunday, 9 August 2015 at 02:41:00 UTC, Manu wrote: ... This pretty much hit the nail on the head on why dmd needs deprecated. I'm tired of seeing 'BUT IT WORKS ON WINDOWS' as an excuse. I don't care if it works on windows, it produces code slower than interpreted lua. Exactly what use is that? It may as well not work on windows at all as far as release builds are concerned. Well, for Win64 the codegen is simply wrong. I don't even care if the codegen is fast or not, but correct should be a given. Biggest problem for me so far. Aggravated by the time it takes to isolate such bugs.
Re: D for Game Development
On Saturday, 8 August 2015 at 08:05:27 UTC, lobo wrote: Sorry I don't mean to sound harsh but that's the reality I'm in right now pushing D on teams in my workplace. It would be much simpler if there were quality (idiomatic) D interfaces to existing quality C/C++ libraries. Have you looked at http://code.dlang.org/packages/gfm%3Afreeimage ?
Re: D for Game Development
On Friday, 7 August 2015 at 05:08:27 UTC, Rikki Cattermole wrote: Ok, here is what I'm willing to do. If you are willing to get Derelict-Util into Phobos and create the bindings for what ever (appropriate) c-library. I'm willing to create the wrappers around it to make it work with the interfaces. Well we already have DerelictFI (FreeImage), but I completely disagree with the premise than having image loaders/savers is unworthy NIH. Dropping the number of dependencies is almost always worth it in my opinion.
Re: Rant after trying Rust a bit
I've not used Rust, but don't plan to. On Wednesday, 22 July 2015 at 18:47:33 UTC, simendsjo wrote: While code.dlang.org has 530 packages, crates.io has 2610 packages, I think this tells something foremost about the size of the community. More people leads to more code. Traits -- I think the ability to express an interface without buying into inheritance is the right move. The alternative in D is specifying the behavior as a template and verifying the contract in a unittest for the type. Traits can't do Design by Introspection aka compile-time duck. C++ can on the other hand. Algebraic data types Haven't looked into `Algebraic!`, so I won't start bashing D here :) But given the lack of pattern matching, I doubt it will be as pretty as Rust. You can pattern-match with visit. Macros -- I haven't written more than extremely simple macros in Rust, but having macros that is possible for tools to understand is a win. Templates and string mixins is often used for this purpose, but trying to build tools when string mixins exists is probably extremely hard. If D had hygenic macros, I expect several features could be expressed with this instead of string mixins, making tooling easier to implement. There is a difference though: Rust forces macros on you on the get go, while in D string mixing are quite a rare occurence thanks to other meta things and don't have a weird separate syntax. Regular templates + tuple foreach + static if is just easier to debug. Borrowing - This is probably the big thing that makes Rust really different. Everything is a resource, and resources have an owner and a lifetime. As a part of this, you can either have multiple aliases with read-only references, or a single reference with a writeable reference. I won't say I have a lot of experience with this, but it seems like it's not an extremely unergonomic trade-off. I cannot even remotely imagine the amount of possible compiler optimizations possible with this feature. The problem I see with this is that it is exactly like C++ scoped ownership except enforced. Even in Rust meeting they said they were converging on C++. It remotely feels like the same language to me. I've worked in fully scoped ownership codebases, it's very nice and consistent, and you don't feel like you would need anything else while doing it. You must train everyone to do it. Enforcing it in the language? I'm not sure about this. There are time where you debug and you have to comment stuff out wildly. Also if you are going to replace C++, it is a given to at least compile faster, make solve problem #1.
Re: Initial feedback for std.experimental.image
On Tuesday, 21 July 2015 at 16:27:33 UTC, Rikki Cattermole wrote: So in your view, I should ask the compiler devs of e.g. ldc/gdc of what would be the better way to go for production code in this instance? Why not, this wasn't about std.experimental.image specifically. I just wanted to point out something that is counter-intuitive (of course this need to be cross-checked). We discussed signed vs unsigned and I think Vladimir made compelling arguments about signed integers. 32-bit vs 64-bit vs machine-size words is another to choose and I'd better complain now than at vote time :).
Re: Initial feedback for std.experimental.image
On Friday, 10 July 2015 at 05:27:21 UTC, rikki cattermole wrote: What we need is a unsigned integer type **of word size** Sorry for being picky there. At least in x86, machine word size aka 64-bit integers in 64-bit are generally not faster. - first, all operations are operating on 32-bit integers by default, unless those with a REX prefix. The important part is that _those instructions with a REX prefix take more bytes_. This has 2 effects, one on the size of the code itself (expect more icache usage), and one on the instruction decoding queue (processor can't process out of order too much long instruction, I believe the limit is a 16-byte lookahead or something). - secondly to avoid false dependencies, the upper 32-bit of registers are cleared. mov ECX, 0; // will clear the whole RCX register. So while the code size may not be a big deal in the general scheme, it has literally no downsides to use as much 32-bit operations as possible even in 64-bit modes on x86. I don't know with ARM or others.
Re: DUB RC 0.9.24-rc.1 ready for testing
On Tuesday, 21 July 2015 at 08:46:49 UTC, John Colvin wrote: On Monday, 20 July 2015 at 23:18:34 UTC, Andrei Alexandrescu wrote: On 7/20/15 5:30 PM, Martin Nowak wrote: On Thursday, 16 July 2015 at 08:28:08 UTC, Suliman wrote: In what version of DMD do you plan to include dub and vibe? It doesn't make sense to include vibe.d. I think it does - this has been discussed before. -- Andrei Have you used dub and vibe.d extensively yourself? I'm seeing quite a lot of pushback on this idea from people who do. Granted, I'm on a forked DUB master but I think it absolutely belongs to the standard language distribution. The downside of not having people discover it is just too huge.
Re: Mitigating the attribute proliferation - attribute inference for functions
On Friday, 17 July 2015 at 16:40:56 UTC, Jonathan M Davis wrote: @nogc is mostly a PR thing IMHO. It has value in that it helps you find places where you accidentally used the GC (though if you really care, you can always use the profiler as you point out), and if @nogc is marked explicitly, it makes it easier to see which functions can be used in @nogc code, but ultimately, it really seems like it's there simply to appease the folks who don't want any GC usage at all. I thought it was a PR thing, but because few things use malloc implicitely and @nogc enforce no GC, I find it actually useful to check if a function does zero allocations. Not the worst attribute. Honestly, what we should do if we don't care about code breakage is make pure and @safe the default, since they really should be the rule rather than the exception. That would reduce the problem considerably. But the problem is that that breaks code, and without @safe whitelisting stuff instead of blacklisting it, it would probably make the breakage related to fixing @safe holes even worse. So, I very much doubt that we can do it at this point, much as that's really where we want to be. Please no. Code is born ugly and then gets better and attributed. For scripting and peace of mind, D gets every default right; it's just that some attributes are not really worth it and should be killed imho.
Re: Where will D sit in the web service space?
On Thursday, 16 July 2015 at 10:58:08 UTC, rsw0x wrote: On Thursday, 16 July 2015 at 10:29:54 UTC, Kagamin wrote: Like minecraft? Minecraft runs absolutely horrible, the earlier versions of minecraft used to allocate 2-300mb of data per second that was near instantly marked garbage. OTOH, Minecraft Desktop benefits from a single build that work in Linux/Mac/Windows, has a web start page, and Notch goes pretty fast with Eclipse.
Re: Implement the "unum" representation in D ?
On Saturday, 11 July 2015 at 03:02:24 UTC, Nick B wrote: If you are at all interested in computer arithmetic or numerical methods, read this book. It is destined to be a classic. Sample chapter here: http://radiofreehpc.com/tmp/TheEndofErrorSampleChapter.pdf
Re: Initial feedback for std.experimental.image
On Tuesday, 7 July 2015 at 14:02:53 UTC, David Nadlinger wrote: Only in C/C++. In D, they are defined to overflow according to two's complement. — David Thanks for the correction.
Re: Initial feedback for std.experimental.image
On Tuesday, 7 July 2015 at 08:50:45 UTC, Manu wrote: Most iterators are already size_t. .length should have been int but it's too late. It's not because it's a "size" that it should be size_t. Indexes shoulds be size_t for conventions sake, otherwise you cast everywhere. Disagree. I think it's the other way around. And image coordinates are not especially indices. Indices should be unsigned, otherwise you need to do 2 tests for validity, rather than just one; (x >= 0 && x < length) rather than just (x < length). You can force an unsigned comparison with (cast(uint)x < length). Signed indices optimize better in loops because signed overflow is undefined behaviour. http://stackoverflow.com/questions/18795453/why-prefer-signed-over-unsigned-in-c
Re: Initial feedback for std.experimental.image
On Monday, 6 July 2015 at 13:48:53 UTC, Rikki Cattermole wrote: If reviewing the code itself is too much of a hassel, please review the specification document. http://cattermole.co.nz/phobosImage/docs/html/std_experimental_image_specification.html Use the Cartesian coordinates system using two (X and Y) size_t integers Why not just int? There is preciously little addressable images beyond 2^31. size_t has a variable size and is a source of build breaking. Also, please no unsigned integers! This create all manners of bugs because of how integer promotion work. A major concern for D is templated code. Template bloat as it is known is when there is large amounts of templates being initiated with vast array of compile time arguments. For this very reason, template usage must be constrained to the bare minimum. Keeping in line with other D code of highly reusable code, templates will be used. Be constrained to colors (usage not definition) and constructors as much as possible. I don't think there is so much problems with Phobos levels of meta-programming. There are also way to reduce template instantiation with type-punning. To me an image library should be based on a static interface with optionally a wrapper to auto-generate the dynamic interface much like in std.allocator. Is it the case? Your library seem to be based around the dynamic 'interface' instead.
Re: D on Windows Phone
On Wednesday, 1 July 2015 at 10:49:03 UTC, jd wrote: are you kidding? it doesn't even work on win 8.1 desktop, can't do dll's etc.. I've been making DLL in Windows 8.1 all day.
Re: End of life for Windows Server 2003 R2 is July 14, 2015
On Wednesday, 24 June 2015 at 16:10:44 UTC, Iain Buclaw wrote: http://www.microsoft.com/en-us/server-cloud/products/windows-server-2003/ Which means that (strictly speaking), in 3 weeks time, there will be *no* operating system that supports CodeView debugging. This is an elongated way of asking "Can I remove -gc yet?" But as I'm not a Windows user, I'll have to ask how you guys deal with debugging, and if you still rely on CV being emitted from DMD, you must hurry up to implement an alternative! Iain. Can't speak for all Windows users, but I think we mostly let cv2pdb convert CV into something other tools understand.
Re: Suggested enhancement: New basic datatype: 'dec'.
On Thursday, 25 June 2015 at 09:24:28 UTC, DLearner wrote: A signed decimal datatype to support writing userland accounting programs (major business application area), without loss of accuracy (including losses caused by not all 'decimal decimals' having exact 'binary decimal' representation). Not very interesting from a theoretical viewpoint (just COBOL or PL/I datatype), but (I think) of practical value in encouraging D adoption. D has excellent support for user-defined numerical data types, so you can write such as a library. You too can do it, especially if you have experience with such accounting applications.
Re: Phobos addition formal review: std.experimental.allocator
On Tuesday, 23 June 2015 at 19:16:33 UTC, Andrei Alexandrescu wrote: The case with std.allocator is not everything is imported in it, so no bloating no nothing. -- Andrei My assumption with D libraries is that "import std.thing;" imports everything in the the whole package. Not that I've a strong opinion on it either.
