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: Beta D 2.070.0-b1
On Sunday, 10 January 2016 at 23:58:38 UTC, Martin Nowak wrote: In case you don't already use Travis-CI or something similar, you should start doing so. Testing the latest beta in Travis-CI is as simple as adding dmd-2.070.0-b1 to your .travis.yml [³] (and we'll soon make it even easier adding support for dmd-beta and dmd-nightly). I fear there are more regressions that people can test for. Currently we can't "dub test" release builds trough DUB. If you do: dub test mypackage it builds with flags -g -unittest -w -debug. (like a -b debug build + the -unittest flag) But if you do: dub test mypackage -b release it builds with flags -release -inline -O -w BUT NOT -unittest Currently we can only "dub test" debug builds without anything dangerous. Since a number of regressions are in the backend, that could be useful if DUB would let us test release builds in Travis-CI.
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: Creating D bindings for a C library
On Tuesday, 24 November 2015 at 23:22:24 UTC, Joseph Rushton Wakeling wrote: On Tuesday, 24 November 2015 at 23:14:14 UTC, Joseph Rushton Wakeling wrote: I'm considering creating some D bindings for a C library. I should probably clarify that I know what to do assuming I have to write all the bindings manually. However, as the library has quite a lot of header files, I'd really much rather auto-convert as much as possible, hence the questions above :-) If doing it by hand, some tips here: http://p0nce.github.io/d-idioms/#Porting-from-C-gotchas
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: How to use readText to read utf16 file?
On Tuesday, 17 November 2015 at 05:37:55 UTC, Domain wrote: Thank you! Now another question: how to handle endianness? If your file follow a file format: the endianness should be defined there. else it's a random text file: either it will have a BOM with endianness, or you will have to guess.
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: OSX Foundation framework D binding
On Wednesday, 11 November 2015 at 16:06:57 UTC, Jacob Carlborg wrote: On 2015-11-11 10:29, Daniel Kozak via Digitalmars-d-learn wrote: I find only this one: http://code.dlang.org/packages/derelict-cocoa Also, there's no point in complicate the bindings by using function pointers like this. Opinion. I only ever got problems with bindings that aren't dynamic. For example that problem would not happen with dynamic loading. https://github.com/nomad-software/x11/issues/11
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: Feature for paranoids
On Tuesday, 10 November 2015 at 13:09:09 UTC, Fyodor Ustinov wrote: Hi! Is it possible when using the "-release" indicate that this one in/out/invariant/assert should not to be disabled? WBR, Fyodor. Since assert(false) is special (cf. http://p0nce.github.io/d-idioms/#assert%28false%29-is-special) you can use the following construct to have always-on assertions: if (!cond) assert(false); instead of: assert(cond); But -release will still remove your in/out/invariant blocks.
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: Feature for paranoids
On Tuesday, 10 November 2015 at 20:37:00 UTC, Fyodor Ustinov wrote: assert(false) AKA assert(0) - is a part of this language that I think it is absolute evil. WBR, Fyodor. I would say it's a minor evil, that create problems by needing an explanation. At this point it has been discussed to death already.
Re: Why my app require MSVCR120.dll?
On Friday, 6 November 2015 at 13:16:46 UTC, Suliman wrote: I wrote Application in D. That use next components: "colorize": ">=1.0.5", "ddbc": ">=0.2.11", "vibe-d": "~>0.7.26" On Windows 7 it's work fine. On Windows 10 (clean install) it's do not start and require MSVCR120.dll And I can't understand what component is pulling this lib as dependence. What would be if I am try to port my App to Linux? What compiler are you using?
Re: Please vote for the DConf logo
On Wednesday, 4 November 2015 at 09:45:08 UTC, ponce wrote: 3 but not with this font! On second thought, I had looked at the SVG not PNG. The font is OK. Don't look at the SVG if you don't have the same font installed.
Re: Please vote for the DConf logo
On Wednesday, 4 November 2015 at 15:22:41 UTC, Wyatt wrote: On that note, I like how 1.2 incorporates the colours of the German flag and evokes the moons at the same time, but it ends up being too busy and doesn't draw the eye well, IMO. Hard edges are fine, but the angles don't give me a good feeling. (Also, the zero in the year seems strangely wide.) I have this problem that I like fairly crowded logos https://github.com/p0nce/dplug/blob/master/logo.svg :)
Re: Please vote for the DConf logo
On Wednesday, 4 November 2015 at 09:30:30 UTC, Andrei Alexandrescu wrote: Reply to this with 1.1, 1.2, 2, or 3: 1) by ponce: Variant 1: https://github.com/p0nce/dconf.org/blob/master/2016/images/logo-sample.png Variant 2: https://raw.githubusercontent.com/p0nce/dconf.org/4f0f2b5be8ec2b06e3feb01d6472ec13a7be4e7c/2016/images/logo2-sample.png 2) by Jonas Drewsen: https://dl.dropboxusercontent.com/u/188292/g4421.png 3) by anonymous: PNG: http://imgur.com/GX0HUFI SVG: https://gist.github.com/anonymous/4ef7282dfec9ab327084 Thanks, Andrei 3 but not with this font!
Re: DConf 2016, Berlin: Call for Submissions is now open!
On Sunday, 1 November 2015 at 02:41:37 UTC, Andrei Alexandrescu wrote: There's been considerable back and forth between Sociomantic and ourselves before choosing this path. One concern was that corporate intervention risks to stifle individual contributions such as Jonas' and ponce's. We concluded that we've been roughing it long enough so a bit of structured help is welcome. Thanks, Andrei Hey, no problem. The site wasn't quite good enough anyway and it's good to see Sociomantic endorsing D to that extent.
Re: DConf 2016, Berlin: Call for Submissions is now open!
On Thursday, 29 October 2015 at 11:19:16 UTC, Rory McGuire wrote: Most, if not all the logos that have stood the test of time are simple, clean and are easily recognizable in almost any size. The base of the current D logo fits these specs I think. Unless I'm misunderstanding, DConf logo aren't intended to be reused over years. They don't need to stand the test of time like the D logo (which is a topic already discussed at length, let's not derail), so it was my understanding it could be a bit more "unsafe".
Re: DConf 2016, Berlin: Call for Submissions is now open!
On Thursday, 29 October 2015 at 10:41:42 UTC, Iain Buclaw wrote: Not saying you should re-use this design, but notice how the 'DConf' logo is the most unremarkable part of it. :-) I'm aware my proposal is too over-the-top, detracts from the point being made (what? where? when?). It will get patched.
Re: DConf 2016, Berlin: Call for Submissions is now open!
On Thursday, 29 October 2015 at 08:41:53 UTC, Iain Buclaw wrote: I think simplicity works better for a logo, moving any small details into the background. Using this kind of tactic I think works well - for instance, a lot of people still wear their DConf 2012 shirts on a weekly basis. What do these shirts look like?
Re: DConf 2016, Berlin: Call for Submissions is now open!
On Thursday, 29 October 2015 at 06:43:25 UTC, Walter Bright wrote: Please don't be discouraged over what I wrote. You've got talent for this. No worries, I'll get back to it :) geod24 on IRC had an interesting idea.
Re: DConf 2016, Berlin: Call for Submissions is now open!
On Monday, 26 October 2015 at 10:12:30 UTC, ponce wrote: On Sunday, 25 October 2015 at 23:59:16 UTC, Andrei Alexandrescu wrote: Yes please! Forgot to mention that. Many thanks!! -- Andrei Added to my TODO list :) So I've made a logo here: https://github.com/p0nce/dconf.org/blob/master/2016/images/logo.svg If you like it tell and I'll make the usual dconf.org integration. What needs to be written next to it?
Re: DConf 2016, Berlin: Call for Submissions is now open!
On Wednesday, 28 October 2015 at 19:24:13 UTC, Andrei Alexandrescu wrote: On 10/28/2015 02:57 PM, ponce wrote: On Wednesday, 28 October 2015 at 18:10:04 UTC, Andrei Alexandrescu wrote: What needs to be written next to it? Looks interesting but I fail to see "DConf". The text should read "DConf 2016/May 4-6/Berlin, Germany" -- Andrei That would give something like: https://github.com/p0nce/dconf.org/blob/master/2016/images/logo-sample.png Nice, thanks. What is the meaning of the "E" or "m"? -- Andrei It is supposed to refer to the Bundestag like in http://www.catherinefeff-studio.com/references/39636641Berlin_logo.gif But I guess this part isn't working too well.
Re: DConf 2016, Berlin: Call for Submissions is now open!
On Wednesday, 28 October 2015 at 18:10:04 UTC, Andrei Alexandrescu wrote: What needs to be written next to it? Looks interesting but I fail to see "DConf". The text should read "DConf 2016/May 4-6/Berlin, Germany" -- Andrei That would give something like: https://github.com/p0nce/dconf.org/blob/master/2016/images/logo-sample.png
Re: DConf 2016, Berlin: Call for Submissions is now open!
On Wednesday, 28 October 2015 at 23:02:59 UTC, Walter Bright wrote: On 10/28/2015 11:57 AM, ponce wrote: On Wednesday, 28 October 2015 at 18:10:04 UTC, Andrei Alexandrescu wrote: What needs to be written next to it? Looks interesting but I fail to see "DConf". The text should read "DConf 2016/May 4-6/Berlin, Germany" -- Andrei That would give something like: https://github.com/p0nce/dconf.org/blob/master/2016/images/logo-sample.png The logo looks nice, but it doesn't seem to be evocative of D. I think there needs to be a theme to it, like "D saves the world", "D is cool tech", "D makes money for business", "D is the choice of cutting edge programmers", "D is the latest technology", etc. Something like that. There is a D right there in the logo. It think I'll let others step up with other designs.
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: Playing audio files and related functions?
On Monday, 26 October 2015 at 21:25:58 UTC, Cleverson wrote: Hello, Is there any library or module for easily managing basic audio functions, e.g., play/pause/stop a sound? I can't find it amongst the standard library and the packages colection, or maybe I don't know how to search properly, since I'm new to D and its ecosystem. Thank you, Cleverson There doesn't seem to be a pure D solution but bindings to existing C or C++ libraries do exist. - SDL_mixer through DerelictSDL2: http://code.dlang.org/packages/derelict-sdl2 (is an extension of SDL). - FMOD through DerelictFMOD: http://code.dlang.org/packages/derelict-fmod (not free for commercial use) - BASS through DerelictBASS: http://code.dlang.org/packages/derelict_extras-bass (not free for commercial use)
Re: DConf 2016, Berlin: Call for Submissions is now open!
On Friday, 23 October 2015 at 16:37:20 UTC, Andrei Alexandrescu wrote: http://dconf.org/2016/index.html Do you need a new logo this year? I would be happy to make another, better one.
Re: inout, delegates, and visitor functions.
On Saturday, 24 October 2015 at 11:28:17 UTC, Sebastien Alaiwan
wrote:
Hi ponce,
Thanks for your suggestion.
I think I may have found the beginning of a solution:
class E
{
import std.traits;
void apply(this F, U)(void delegate(U e) f)
if(is(Unqual!U == E))
{
f(this);
}
int val;
}
int main()
{
void setToZero(E e)
{
e.val = 0;
}
void printValue(const E e)
{
import std.stdio;
writefln("Value: %s", e.val);
}
E obj;
obj.apply();
obj.apply();
const(E) objConst;
//objConst.apply();
objConst.apply();
return 0;
}
Clever. It works because of const inference on template functions.
Didn't know you could use 'this' as a type.
Re: inout, delegates, and visitor functions.
On Saturday, 24 October 2015 at 08:51:58 UTC, Sebastien Alaiwan
wrote:
Hi all,
I'm trying to get the following code to work.
(This code is a simplified version of some algebraic type).
Is it possible to only declare one version of the 'apply'
function?
Or should I declare the const version and the non-const version?
I tried using "inout", but I got the following error:
test.d(28): Error: inout method test.E.apply is not callable
using a mutable object
class E
{
void apply(void delegate(inout(E) e) f) inout
{
f(this);
}
int val;
}
void m()
{
void setToZero(E e)
{
e.val = 0;
}
void printValue(const E e)
{
import std.stdio;
writefln("Value: %s", e.val);
}
E obj;
obj.apply();
obj.apply();
}
Thanks!
Hi Sebastien,
That was an interesting question and I didn't succeed with
'inout' either without duplicating apply.
I have a partial solution here:
http://dpaste.dzfl.pl/b5ec7f16b912 which templatizes the delegate
type, but is probably not what you want.
The qualifier is not carried on to the apply() function. When
taking a const delegate it will still not be const.
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: 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: 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: Beta D 2.069.0-b2
On Wednesday, 14 October 2015 at 13:53:17 UTC, Martin Nowak wrote: Second beta for the 2.069.0 release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.069.0.html Please report any bugs at https://issues.dlang.org -Martin Apart from https://issues.dlang.org/show_bug.cgi?id=15207, I'm seeing a huge +170% speed-up in 32-bit mode for optimized builds vs 2.068, something that is well appreciated :) 64-bit performance is mostly the same. What changed in the backend?
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 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: 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: Beta D 2.069.0-b1
On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote: First beta for the 2.069.0 release. Weren't there codegen improvements in DMD?
Re: Beta D 2.069.0-b1
On Thursday, 8 October 2015 at 04:14:59 UTC, extrawurst wrote: On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote: First beta for the 2.069.0 release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.069.0.html Please report any bugs at https://issues.dlang.org -Martin `The -property switch has been deprecated.` Does that mean @property has no effect anymore ? --Stephan Now it would be great if @property was removed. It is just one more attribute that brings nothing to the table and take valuable space on the screen.
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 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: 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: 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: 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: 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: Interval Arithmetic
On Thursday, 1 October 2015 at 21:13:30 UTC, Marco Leise wrote: Nice to have in Phobos. I assume you have to set the correct control word depending on whether you perform math on the FPU or via SSE (as is standard for x86_64)? And I assume further that DMD always uses FPU math and other compilers provide flags to switch between FPU and SSE? I don't know which compiler use which. On x86_64, a compiler is in practice free to mix-and-match FPU and SSE, the instructions are still there and working.
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: Interval Arithmetic
On Thursday, 1 October 2015 at 11:40:28 UTC, Marco Leise wrote: Note that the FP control word is per thread and any external code you call or even buggy interrupt handlers could change or reset it to defaults. Known cases include a faulty printer driver and Delphi's runtime, which enables FP exceptions to throw exceptions on division by 0. Just saying this so if it ever happens you have it in the back of your mind. Against interrupt handlers you probably cannot protect, but when calling other people's code it would be best not depend on what the FP control word is set to on return. `FloatingPointControl` is nice here, because you can temporarily set the rounding mode directly for a block of FP instructions where no external libraries are involved. I have a RAII struct to save/restore the FP control word. It also handle the SSE control word which unfortunately exist. https://github.com/p0nce/dplug/blob/master/plugin/dplug/plugin/fpcontrol.d
Re: Announcing dplug, a toolkit for making audio plugins with D
On Wednesday, 9 September 2015 at 07:51:19 UTC, ponce wrote: - Mac VST support for 64-bit is there, with the exception of a weird scanning bug in Reaper and Studio One (#62). The interface use Cocoa through DerelictCocoa. 32-bit plugins would require a Carbon UI and I don't think it's clever to focus time on it. More dplug news: 32-bit Mac OS X VST support is complete with the help of an ad-hoc, Derelict-style Carbon binding. Actually it was way easier than binding to Cocoa. Using DMD one can target as low as OS X 10.6, if ever needed ;) https://github.com/p0nce/dplug https://github.com/p0nce/DerelictCarbon
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: 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: 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 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: Do users need to install VS runtime redistributable if linking with Microsoft linker?
On Monday, 28 September 2015 at 16:01:54 UTC, Sebastiaan Koppe wrote: I could not find out which redistributable I had to install (what version of VS did you have installed / on what version of windows are you?). I decided to install them all, but couldn't install the one for 2015 (due to Windows6.1-KB2999226-x64.msu). After trying some workarounds I gave up. You need the VC++ 2015 64-bit redistributable.
Re: Do users need to install VS runtime redistributable if linking with Microsoft linker?
On Tuesday, 29 September 2015 at 09:44:58 UTC, Sebastiaan Koppe wrote: On Tuesday, 29 September 2015 at 09:15:29 UTC, ponce wrote: On Monday, 28 September 2015 at 16:01:54 UTC, Sebastiaan Koppe wrote: I could not find out which redistributable I had to install (what version of VS did you have installed / on what version of windows are you?). I decided to install them all, but couldn't install the one for 2015 (due to Windows6.1-KB2999226-x64.msu). After trying some workarounds I gave up. You need the VC++ 2015 64-bit redistributable. Can you either link statically or try an older version of VC, one that is more likely to be found in the wild? (or does ldc require 2015?) No, not without rebuilding Phobos/druntime as it stands. https://github.com/ldc-developers/ldc/issues/1133 I really want to try your game :) Version 1.7 is still available and is compiled with DMD for 32-bit Windows. You can also clone the repo and type "dub": https://github.com/p0nce/Vibrant Given the general speed up with LDC, it would need more profiling/optimizing to get back to DMD. Maybe next release.
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: Vibemail - extensions for vibe's Mail class to send multi-part emails with attachments
On Tuesday, 29 September 2015 at 16:22:43 UTC, Adam D. Ruppe
wrote:
But, how do you express the half-dependency of
characterencodings in a dub.json dependencies list?
optional dependencies + version tags produced by DUB in the form
of
version (Have_packagename)
{
}
(never tried)
Re: Vibemail - extensions for vibe's Mail class to send multi-part emails with attachments
On Tuesday, 29 September 2015 at 16:22:43 UTC, Adam D. Ruppe wrote: I copy/pasted your arsd/dom.d code in a couple of projects. But none of them will receive updates unless I do 'm manually. That means you don't have to put up with me randomly breaking your code! You don't have to wait for me to publish a bug fix. You aren't locked in to the way I did things and are free to customize it as you wish. But this encourage to create tiny little forks everywhere. So everyone is getting less bugfixes: if I have my local copy, nothing encourages me to contribute the fix. This is the strength of versionned dependencies: - one master tree - get bugfixes automatically before you are aware they even exist - do not close the door to breaking changes in the form of a major version bump. - open/closed principle for packages: if you use devisualization:window, the X11 package is pulled and linked without anymore work. This sub-dependency doesn't leak into your project, it's only a property of the primary dependency you used. So I'd DUB strive to make dependencies composable, where they were previously a leaky abstraction. It's like calling a function and not having to know what it does inside. Of course this implies there is no bad-fixes or SemVer misuse :) But I've found this to work reasonably well in practice.
Re: Do users need to install VS runtime redistributable if linking with Microsoft linker?
On Monday, 28 September 2015 at 15:10:25 UTC, ponce wrote: Does it also affect executable made with DMD and linked with MS linker? Just tested: no.
Re: Do users need to install VS runtime redistributable if linking with Microsoft linker?
On Monday, 28 September 2015 at 16:01:54 UTC, Sebastiaan Koppe wrote: On Monday, 28 September 2015 at 15:10:25 UTC, ponce wrote: On Tuesday, 22 September 2015 at 09:38:12 UTC, thedeemon wrote: On Monday, 21 September 2015 at 15:00:24 UTC, ponce wrote: All in the title. DMD 64-bit links with the VS linker. Do users need to install the VS redistributable libraries? I think they don't. Generated .exe seems to depend only on kernel32.dll and shell32.dll, i.e. things users already have. So I've released software with LDC 0.16.0-alpha4 Win64, and one user send me that http://i.imgur.com/xbU1VeS.png I thought it was only used for linking :( Does it also affect executable made with DMD and linked with MS linker? Basically you executable is bound to whatever runtime you had installed when linking the thing. If those aren't installed on the end user's machine, you get that error. Pretty neat huh? OK, but why does that need to happen? I don't get why does linking with MS linker implies a runtime dependency. I thought we would be left out of these sort of problems when using D :(
Re: Do users need to install VS runtime redistributable if linking with Microsoft linker?
On Tuesday, 22 September 2015 at 09:38:12 UTC, thedeemon wrote: On Monday, 21 September 2015 at 15:00:24 UTC, ponce wrote: All in the title. DMD 64-bit links with the VS linker. Do users need to install the VS redistributable libraries? I think they don't. Generated .exe seems to depend only on kernel32.dll and shell32.dll, i.e. things users already have. So I've released software with LDC 0.16.0-alpha4 Win64, and one user send me that http://i.imgur.com/xbU1VeS.png I thought it was only used for linking :( Does it also affect executable made with DMD and linked with MS linker?
Re: A new article about working with files in D
On Monday, 28 September 2015 at 11:41:37 UTC, Gary Willoughby wrote: Article: http://nomad.so/2015/09/working-with-files-in-the-d-programming-language/ Reddit link: https://www.reddit.com/r/programming/comments/3mosw7/working_with_files_in_the_d_programming_language/ Great article, I can see this become a reference link whenever one need a quick answer about files. I also like how readable your blog is.
Re: Threading Questions
Sorry I don't know the answers but these questions are
interesting so BUMP ;)
On Friday, 25 September 2015 at 15:19:27 UTC, bitwise wrote:
1) Are the following two snippets exactly equivalent(not just
in observable behaviour)?
a)
Mutex mut;
mut.lock();
scope(exit) mut.unlock();
b)
Mutex mut;
synchronized(mut) { }
Will 'synchronized' call 'lock' on the Mutex, or do something
else(possibly related to the interface Object.Monitor)?
Don't know.
Is this Object monitor a mutex or something else?
6) Does 'shared' actually have any effect on non-global
variables beside the syntactic regulations?
Don't think so.
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: 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 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 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.
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: 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: Do users need to install VS runtime redistributable if linking with Microsoft linker?
On Tuesday, 22 September 2015 at 09:38:12 UTC, thedeemon wrote: I think they don't. Generated .exe seems to depend only on kernel32.dll and shell32.dll, i.e. things users already have. Great then.
OS minimum version
1. What is the minimum Windows version required by programs created with DMD? 2. What is the minimum Windows version required by programs created with LDC? 3. What is the minimum OS X version required by programs created with LDC? You would believe such information would be easy to find, but it's not.
Do users need to install VS runtime redistributable if linking with Microsoft linker?
All in the title. DMD 64-bit links with the VS linker. Do users need to install the VS redistributable libraries?
Re: OS minimum version
On Monday, 21 September 2015 at 18:47:10 UTC, anonymous wrote: On Monday 21 September 2015 14:47, ponce wrote: 1. What is the minimum Windows version required by programs created with DMD? http://dlang.org/dmd-windows.html says: "Windows XP or later, 32 or 64 bit". Thanks to all.
Re: Question about Object.destroy
On Sunday, 20 September 2015 at 17:43:01 UTC, Lambert Duijst wrote: Is it because: - The GC did decide to run and cleanup memory straight after the call to s.destroy() - An object being in an invalid state means the program segfaults when the object is used ? - Another reason.. All methods are virtual by default. My guess would be that the invalid state implies that the virtual table pointer is not valid anymore, hence the crash.
Re: Debugging D shared libraries
On Saturday, 19 September 2015 at 17:02:37 UTC, Russel Winder wrote: English and Spanish meanings of the word are very different. In UK (not sure about Canada, USA, Australia, New Zealand, South Africa,…) it is generally a somewhat derogatory term. In French it means "to rub down with abrasive paper".
Re: Tried release build got ICE, does anyone have a clue what might cause this?
On Friday, 18 September 2015 at 22:54:43 UTC, Random D user wrote: So I tried to build my project in release for the first time in a long while. It takes like 25x longer to compile and finally the compiler crashes. It seems to go away if I disable the optimizer. I get: tym = x1d Internal error: backend\cgxmm.c 547 Does anyone have a clue what might trigger this? I'm asking because my project has grown a bit and I don't really have any good way of isolating this. I'm using dmd 2.068.1 and msvc x64 target. As a backend ICE is is very important that you report this. To workaround, try disabling inlining or -O selectively.
Re: How do you get the min / max of two numbers a, b?
On Saturday, 19 September 2015 at 03:53:12 UTC, Enjoys Math wrote: I know there's fmax for floats, but what about ints? Thanks. http://p0nce.github.io/d-idioms/#Minimum-or-maximum-of-numbers
Re: broken program, silly error messages, dub
On Saturday, 19 September 2015 at 01:54:08 UTC, Joel wrote: I accidentally wiped off a small source file. I've been trying to put it back together. Now I get unrelated errors. I've tried resetting dub. To reset DUB state completely: - remove .dub/ directory in the project directory - remove dub.selections.json - remove the ~/.dub directory
Re: Get AA key and value type
On Saturday, 19 September 2015 at 12:50:51 UTC, Pierre wrote:
So how can I get types without instance ?
Thanks for help.
-->8-
template AATypes(T)
{
// todo: static assert if T is no AA type here
alias ArrayElementType!(typeof(T.init.keys)) key;
alias ArrayElementType!(typeof(T.init.values)) value;
}
-->8-
Should work.
Re: Debugging D shared libraries
On Saturday, 19 September 2015 at 10:45:22 UTC, Russel Winder
wrote:
Calling D from Python. I have two functions in D, compiled to a
shared object on Linux using LDC (but I get same problem using
DMD).
The sequential code:
extern(C)
double sequential(const int n, const double delta) {
Runtime.initialize();
const pi = 4.0 * delta * reduce!(
(double t, int i){ immutable x = (i - 0.5) * delta;
return t + 1.0 / (1.0 + x * x); })(
0.0, iota(1, n + 1));
Runtime.terminate();
return pi;
}
works entirely fine. However the "parallel" code:
extern(C)
double parallel(const int n, const double delta) {
Runtime.initialize();
const pi = 4.0 * delta * taskPool.reduce!"a + b"(
map!((int i){ immutable x = (i - 0.5) * delta; return
1.0 / (1.0 + x * x); })(iota(1, n + 1)));
Runtime.terminate();
return pi;
}
causes an immediate segfault (with LDC and DMD. I am assuming
that the problem is the lack of initialization of the
std.parallelism module and hence the use of taskPool is causing
a problem. I am betting I am missing something very simple
about module initialization, and that this is not actually a
bug.
Anyone any proposals?
Try using an explicit TaskPool and destroying it with scope(exit).
Also if using LDC, you can use global ctor/dtor to deal with the
runtime.
--->8-
extern (C) {
pragma(LDC_global_crt_ctor, 0)
void initRuntime()
{
import core.runtime;
Runtime.initialize();
}
pragma(LDC_global_crt_dtor, 0)
void deinitRuntime()
{
import core.runtime;
Runtime.terminate();
}
}
--->8-
Re: Debugging D shared libraries
On Saturday, 19 September 2015 at 16:32:18 UTC, Russel Winder wrote: (*) ponce is arguably not the most positive or constructive name to go by. Friend call me like this IRL since forever. It seems to be a swear word in english?
Re: Debugging D shared libraries
On Saturday, 19 September 2015 at 15:42:15 UTC, Russel Winder wrote: Hummm… I now do not get a segfault, and the code runs as expected : -) but the program never terminates. :-( Where is it stuck? Also, what would I need to cover the DMD and the GDC situations? I don't know. :(
Re: Debugging D shared libraries
On Saturday, 19 September 2015 at 16:25:28 UTC, Laeeth Isharc wrote: What is the difference between shared static this and the global constructor ? Russell, if you use shared static this for dmd does it work ? Laeeth. Would like to know too. On OSX I've found that shared static this() was called by Runtime.initialize(), maybe it's different on Linux.
Re: How not to run after a DUB build ?
On Thursday, 17 September 2015 at 19:44:36 UTC, BBasile wrote: On Thursday, 17 September 2015 at 19:36:10 UTC, BBasile wrote: Each time I execute `dub.exe --build=release` (or any other the build type) DUB tries to run the project after the build. This generates often generates an error when dub process returns (and even if the build is OK) but actually I don't want DUB to run after building. Is there a switch to avoid the exexution after the build ? NVM, just get that 'build' and '--build=' are two different things. with `dub.exe build --build=release` nothing is executed... Yes, the default command is "dun run"
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,
);
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 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*), );
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.
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: LDC 0.16.0 alpha3 is out! Get it, test it, give feedback!
On Thursday, 17 September 2015 at 14:51:32 UTC, Jack Stouffer wrote: On Wednesday, 16 September 2015 at 20:03:15 UTC, Kai Nacke wrote: Hi everyone, LDC 0.16.0 alpha3, the LLVM-based D compiler, is available for download! Is there anyway to get dub to use this as a compiler so I can test this out? Put the compiler in your PATH, and use the --compiler=ldc2 flag in DUB
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 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.
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!
