Re: Please vote on std.datetime
On 12/10/10 1:26 AM, Andrei Alexandrescu wrote: It's time to vote. Please vote for or against inclusion of datetime into Phobos, along with your reasons. Yes, it'd totally like to see this library in Phobos, but I think that we need to be aware of a few issues, mainly caused by the sheer amount of source code in a single file/module. The first one is maintainability – if datetime.d was added to Phobos in its current form, about _a quarter of all std.* code_ (LOC-wise) would be concentrated _in a single source file_. I know that this has been discussed before, and that there is no hard limit on file/module size, but in my eyes, 32k lines in a single file are prone to get tedious. This probably isn't really a big problem though, since the code is relatively low in complexity and furthermore probably does not require an exceptionally high amount of maintenance. In my eyes, a much more important issue is that DDoc is hardly up to the task currently. Just open the HTML page from Jonathan's archive and imagine being pointed to datetime.html#toLocalTime, and try finding out to which entity (class, struct or the module itself) this function belongs, then try getting a quick picture of what other functions are offered in the same scope, or jumping to the start or end of the docs on it. A complete discussion would probably belong to a separate DDoc improvements thread, but for example, the »jump to« list at the top is unnecessarily cluttered by a lot of enum itmes, and what's really missing are some aids for navigating on the page, probably also internal references like in Doxygen/Javadoc and a way to divide the page into several sections (though splitting the module instead would be a better choice here, arguably). Oh, I am not at all trying to argue against the inclusion of datetime into Phobos by the way, I just want to point out that it raises a few issues we should probably better be aware of.
Re: Announcing: D support in SWIG
On 12/9/10 10:12 PM, Andrej Mitrovic wrote: I'm curious, can you use SWIG with D2 on Linux as well? From what I've read so far in the docs, SWIG creates an extension module that can be compiled as a dynamic library. But afaik there are some issues with using dynamic libs in Linux with D2, at least that's what I've read a few times in the newsgroups.. What's compiled as a dynamic library is the C/C++ wrapper layer, but the issues are related to writing dynamic libraries in D. By the way, the wrapper library could be linked statically as well (I'll implement that as soon as I have some time to spare), but due to the COFF/OMF issues on Windows, I decided to default to dynamic loading.
Re: Announcing: D support in SWIG
On 12/10/10 12:12 AM, BLS wrote: Vote++ A discussion Forum would be nice too. I am just trying to figure out what to do with : operator HWND() const; Any suggestions on that? The previous attempt for D support in SWIG (which became unmaintained at a rather early stage and didn't make its way into the SWIG core distribution) had a project at DSource [1], but although I really appreciate all the effort that went into it and the great service it has been providing for a really long time now, I am not sure if DSource is the way to go for this kind of effort. For example, DSource seems to be surrounded by a cloud of bad karma lately – lots of dead or obsolete projects, very busy admin(s), server outages, etc. Also, a possible DSource project wouldn't really have a common source code base, at least I wouldn't want to maintain a collection of SWIG interface files for specific libraries I probably don't even use myself. Another thing is that since D support is an official part of SWIG now, there are also the official communication channels (SF.net tracker, the swig-user ML, etc.). These questions make me wonder if it would be a better idea to use separate repositories for each library binding, probably at some DVCS site where projects are easily forkable (like GitHub, Bitbucket and the likes), and keep a central page/thread somewhere with links to the individual projects. Discussing SWIG and D is an entirely different topic, for which there are many possible options: a newly created digitalmars.D.bindings NG, a forum hosted somewhere (DSource, …), Stackoverflow (tagged »swig« and »d« or maybe even »swig-d«), the Swig-user mailing list, and probably a few more I didn't think of right now. Regarding your specific problem: Generally speaking, operator overloading is WIP (hopefully I find time to implement it for D2 during the weekend), but implicit conversions can't really be mapped to D anyway, so just use the %rename directive of SWIG to map the implicit conversion operator to a regular member function like »asHwnd()«. [1] http://dsource.org/projects/swig4d
Re: Announcing: D support in SWIG
On 12/10/10 12:49 AM, Andrej Mitrovic wrote: […] Thanks for writing that D-specific documentation, klickverbot! Well, as for most small-scale OSS projects, writing good docs is pretty boring when you can hack right away on some code as well, so I could really need some suggestions on the D specific parts. For instance, the D chapter desperately needs some small examples that demonstrate how all the customization features of SWIG play together to wrap the most common types of C/C++ APIs, e.g. converting return values to exceptions via custom dptype/dout typemap, renaming cast operators, injecting additional code into the generated D layer to construct more abstract proxy objects of some sorts, etc…
DMD2 .deb fails to install on Ubuntu 10.10 – just remove »shell«?
Currently, this is what happens when you try to install the DMD 2 deb from digitalmars.com on a vanilla Ubuntu 10.10 box: sudo dpkg -i ~/Downloads/dmd_2.050-0_i386.deb Selecting previously deselected package dmd. (Reading database ... 127418 files and directories currently installed.) Unpacking dmd (from .../Downloads/dmd_2.050-0_i386.deb) ... dpkg: error processing ~/Downloads/dmd_2.050-0_i386.deb (--install): trying to overwrite '/usr/bin/shell', which is also in package byobu 3.5-0ubuntu1 dpkg-deb: subprocess paste killed by signal (Broken pipe) Errors were encountered while processing: ~/Downloads/dmd_2.050-0_i386.deb Obviously, the problem is that the package contains the »shell« excecutable – is this really needed, even more so on Linux? Couldn't it simply be removed from the deb? In any case, something should really be done about this as soon as possible – not that one couldn't solve this problem for himself, providing a non-functional »1-click install« (that's how the package is described on http://www.digitalmars.com/d/download.html) is probably one of the worst forms of advertising possible…
Re: Announcing: D support in SWIG
Sorry if this might come a bit late for anybody following SWIG SVN trunk, but I needed to make a breaking naming change to the D module of SWIG to bring it more in line with the C# support. The details, along with a sed script for fixing any custom typemaps: ttp://klickverbot.at/blog/2010/12/swig-d-breaking-name-changes/ This should have been the last major breaking change, at least I hope so. David
Announcing: D support in SWIG
In a nutshell, SWIG is a »glue code« generator, allowing you to access C/C++ libraries from various target languages, including C#, Go, Java, Ruby, Python … and, since I merged my work into SWIG trunk a few days ago, also D, both version 1 and 2. I have put up a short description of it at my blog (http://klickverbot.at/blog/2010/11/announcing-d-support-in-swig/), but to give it a whirl, just head over to the SWIG SVN and build it from there (http://swig.org/svn.html). I would be glad if some brave souls could go ahead and test it in real-world use cases before it is officially released with SWIG for the first time (SWIG 2.0.2, date yet to be determined), so that any major bugs can be ironed out before. If you have any questions or suggestions, feel free to post them here, drop me a line, or ask right away in #D at freenode. While I am quite busy at the moment, I'd be happy to help you with any issues (particularly happy if they concern the SWIG side of implementing enhancements, obviously, but also simple usage questions). Besides that, as always, it would be nice just to hear about what you are using this for. Happy coding, David
Re: [OT] DVCS
On 11/18/10 8:20 PM, Jérôme M. Berger wrote: Performance was actually horrendous on windows last year, not just lower. That's what you say. I say that I've been happily using Git on Windows for over two years without noticing any performance problems. Now what?
Re: [OT] DVCS
On 11/17/10 10:32 PM, Jérôme M. Berger wrote: […] you are not forced into this model when you know you have only worked on a single feature and want to commit it. You are not forced to use the staging area with Git either (although most of the developers I know do use it), it's just the default that is different. If you want to save the extra characters per commit, just add an alias like »ci = commit -a« to your ~/.gitconfig, just like you might want to use »nudge = push --rev .« with Mercurial…
Re: [OT] DVCS
On 11/17/10 10:27 PM, Jérôme M. Berger wrote: […]It might be possible to change the configuration so that this won't happen, but the simple fact that this happens with the *default* config does not fill me with confidence regarding data integrity and Git... This is not exactly true, at least not for the Git on Windows installer, which presents you with the three possible choices for handling line endings. Also, I am not quite sure if this deserves the label »data corruption«, because even if you have auto-conversion of line endings turned on and Git fails to auto-detect a file as binary, no history data is corrupted and you can fix the problem by just switching off auto-conversion (either globally or just for the file in question via gitattributes) – in contrast to actual history/database corruption.
Re: blip 0.5
On 11/18/10 1:12 AM, Bill Baxter wrote: Nice work! Is it for D2 or D1? Or both? --bb I hope you don't mind me answering, Fawzi: Currently, it's D1 only.
Re: Kill implicit joining of adjacent strings
+1 on this. While implicit joining can certainly be useful in C in some cases, D has the ~ operator for such cases. Since compile-time primitives are guaranteed to be folded anyway (IIRC), I can imagine no situation where the benefits of banning implicit joining (reducing the chance for bugs, less special cases) would not outweigh the costs of an additional character to type.
Re: why a part of D community do not want go to D2 ?
On 11/11/10 2:53 AM, Andrew Wiley wrote: Well, my assumption was that Phobos 2 was pretty much complete. […] Hell, no – there currently isn't even a reliable way to load shared libraries in Phobos 2. std.loader doesn't count, it's almost unusable in practice (ExeModule being a scope class – what the …?!) and nowhere solid, idiomatic D.
Re: why a part of D community do not want go to D2 ?
On 11/11/10 8:52 PM, Russel Winder wrote: Using Git is certainly better than using Subversion, but Bazaar and Mercurial are the tools of choice for the discerning developer. Oh, so you really want to start that discussion/flamewar again? -.- As you noted yourself in the thread over at d.D.announce, »[…] no-one to date has objective data so all statements on this are opinion«, so could we please leave it at that, at least for the time being?
Re: why a part of D community do not want go to D2 ?
On 11/10/10 12:00 AM, Walter Bright wrote: […] Producing another incompatible split with D2 will not be of an advantage to anyone, and will just give people reasons not to use D at all. I probably wouldn't get the problem anyway, and I have been using both D1/Tango and, recently, D2/Phobos, and I never understood the reasons for the recent clash in the first place (besides, to me, slightly … childish … behavior on both sides), but: Has anyone actually proposed that? If not, I fear that comments like this just help spreading FUD around the current situation of D, not unlike the (in my eyes) exaggeration of licensing issues…
Re: why a part of D community do not want go to D2 ?
On 11/10/10 1:38 PM, klickverbot wrote: I probably wouldn't get the problem anyway, and[…] Whoops, s/and/as/ there…
Re: [OT] DVCS
On 10/27/10 7:09 PM, Gour wrote: Otoh, Git […] stands too much on the way […] Could you give any examples for this? While I can understand people who think that the raw power Git makes it too easy to shoot yourself in the foot (I personally don't think so, but that's a different topic), I guess I don't really see how it would stand in your way, given that you can do everything you need by just chaining together a few well-known commands…
Re: [OT] DVCS
On 10/27/10 7:40 PM, Jérôme M. Berger wrote: OTOH, Bazaar *is* one of the mainstream DVCSs (along with SVN, Mercurial and Git). I guess it's not really representative (nor scientific, of course), but here are a few numbers: http://stackoverflow.com/questions/995636/popularity-of-git-mercurial-bazaar-vs-which-to-recommend http://www.ohloh.net/repositories/compare
Re: htod feature request: save commands in translated file
On 10/18/10 5:39 PM, Andrej Mitrovic wrote: […] I didn't know there was an active on github. […] That's probably because I haven't officially announced it yet – I am currently trying to get it into SWIG trunk. After this is done (which could take quite some time, since I have not received a real response to my post at the SWIG mailing list yet), I will also try to get all other SWIG-related pages marked as obsolete to avoid confusion. At the moment, you can simply contact me via mail if you hit any bugs or have any related questions. David
Re: Improving version(...)
On 10/18/10 9:56 PM, Simen kjaeraas wrote:
* require declarations for all version identifiers. Versions which are
set from the command line should be explicitly declared, eg:
version Lite = extern;
version Demo = extern;
That would make creating a bird's nest impossible.
And currently, you can make a typo like:
version(Linix) {}
and it compiles happily. I don't like that. Especially when we have
builtin names like D_Inline_Asm_X86_64!
This is an awesome idea. ++votes
+1 from me too, this could be one of the key parts of a long outstanding
version() overhaul.
What also bugs me about the current situation (despite the fact that I
think numeric versions should be removed, but that's another story) is
that the equals sign to define a new version seems very illogical –
»version ~= someUserDefinedVersion« would make much more sense to me…
Re: rationale for function and delegate
On 10/16/10 10:40 AM, Paulo Pinto wrote: while reading TDPL I start wondering what is the background between function and delegate. delegate() is a function pointer amended with a second context pointer, which allows you to have pointers to member functions, closures and so on. function() is a C-style function pointer and can be used to interface with C code, etc., but obviously not for closures, since it its lacking the context part. There is a clear difference between the two types, Ilthough you probably don't need raw function pointers very often if you are working in a D only environment. If you want to have the compiler decide, you could always use auto…
std.algorithm.remove and principle of least astonishment
Hello all,
I decided to have a go at solving some easy programming puzzles with
D2/Phobos to see how Phobos, especially ranges and std.algorithm, work
out in simple real-world use cases (the puzzle in question is from
hacker.org, by the way).
The following code is a direct translation of a simple problem
description to D (it is horrible from performance point of view, but
that's certainly no issue here).
---
import std.algorithm;
import std.conv;
import std.stdio;
// The original input string is longer, but irrelevant to this post.
enum INPUT = 93752xxx746x27x1754xx90x93x238x44x75xx087509;
void main() {
uint sum;
auto tmp = INPUT.dup;
size_t i;
while ( i tmp.length ) {
char c = tmp[ i ];
if ( c == 'x' ) {
tmp = remove( tmp, i );
i -= 2;
} else {
sum += to!uint( [ c ] );
++i;
}
}
writeln( sum );
}
---
Quite contrary to what you would expect, the call to »remove« fails to
compile with the following error messages: »std/algorithm.d(4287):
Error: front(src) is not an lvalue« and »std/algorithm.d(4287): Error:
front(tgt) is not an lvalue«.
I am intentionally posting this to this NG and not to d.…D.learn, since
this is a quite gross violation of the principle of least surprise in my
eyes.
If this isn't a bug, a better error message via a template constraint or
a static assert would be something worth looking at in my opinion, since
one would probably expect this to compile and not to fail within Phobos
code.
David
Re: std.algorithm.remove and principle of least astonishment
In case it was not clear, this is what I want to achive: »tmp = tmp[ 0 .. i ] ~ tmp[ ( i + 1 ) .. $ ];«
Re: std.algorithm.remove and principle of least astonishment
On 10/16/10 9:47 PM, Andrei Alexandrescu wrote: Thanks for the input. This is not a bug, it's what I believe to be a very intentional feature: strings are not ordinary arrays because characters have variable length. As such, assigning to the first character in a string is not allowed because the assignment might mess up the next character. I see that there is a problem due the difference of code units and code points, but why does the following work then? tmp = tmp[ 0 .. i ] ~ tmp[ ( i + 1 ) .. $ ]; This is equivalent to my (naïve?) mental model of remove(), and thus it seems very counter-intuitive to me that one works, but the other doesn't.
Re: Segfault using std.algorithm.map
On 10/16/10 10:13 PM, klickverbot wrote:
---
import std.algorithm;
import std.stdio;
enum INPUT = cqrb lryqna rb fjh, fjh qjamna cqjw axc cqracnnw. qnan,
hxd wnena twxf qxf oja cx bqroc! xq kh cqn fjh, cqn jwbfna rb
mnjmvjwblqnbc.;
void main() {
foreach ( offset; 0..25 ) {
writeln( map!( ( dchar c ) {
if ( c 'a' ) return c;
if ( 'z' c ) return c;
return cast( dchar )( ( ( ( c - 'a' ) + offset ) % 26 ) + 'a' );
} )( INPUT ) );
}
}
---
Okay, after experimenting for a bit, I found that this works:
writeln( map!( ( c ){
return offset;
} )( INPUT ) );
While this segfaults:
writeln( map!( ( c ){
return cast( dchar )( offset );
} )( INPUT ) );
I guess this should go to bugzilla, right?
Re: Segfault using std.algorithm.map
Forget it, I took this directly to bugzilla: http://d.puremagic.com/issues/show_bug.cgi?id=5064
Re: Visual D Build + DMD Bugginess = Bad
On 10/14/10 8:28 AM, Benjamin Thaut wrote: I'm also having problems with VisualD + DMD, I made a posting in the bugs forums about it, but unfortunately no one did answer yet: Uh, afaik the digitalmars.D.bugs forum just mirrors the changes from the puremagic D bugzilla, and thus is not quite the best place for discussions.
Re: Is D right for me?
On 10/13/10 6:56 PM, Jonathan M Davis wrote: I wouldn't think that it would be a problem, but I'm no expert, and we've had problems in the past because Tango devs thought that proposed Phobos code was too similar to Tango. So, as I understand it, unless we get specific permission from the Tango devs which wrote a particular module, we're trying to not have code in Phobos which is an API which is at all close to Tango's. That way we can avoid potential conflicts with the Tango devs. - Jonathan M Davis We had this over and over again, but I still think it should be noted that the disaster around SOHO's code was not entirely made up by »the Tango devs«, but originated from a single developer's phone call to Walter Bright and was then exaggerated by large parts of the D community, including both »sides« – your statement(s) makes it look a bit as if it was all Tango at fault there…
Re: is D too modern for Emacs?
On 10/9/10 12:33 PM, Russel Winder wrote: So putting a Mercurial repository with this source code on dsource.org is the thing that is agreed? I guess this means making a new project? Well, not really agreed – recently, a few large projects (LDC, QtD) have migrated their sources away from DSource because of the constant stability troubles with DSource…
Re: CMake for D2 ready for testers
On 10/9/10 11:40 AM, Russel Winder wrote: Well KDE was about to choose bksys (the immediate ancestor of Waf) until some nasty politiking went on and all of a sudden they chose CMake. I don't know all the details, but I know enough to say that that decision was not made based on a proper study. If you accuse someone of not basing the decision »on a proper study«, I am sure you have some references on hand for that? Usually, a lot of decisions regarding KDE is made based on a meritocracy-like system, »nasty politiking« isn't something I'd expect to see very often… This article[1] from the KDE build system maintainer paints quite a different picture. It seems that they indeed tried to use SCons, even actively worked at the SCons extension bksys (as in »Build Kde System«). Apparently, however, a number of not quite easily resolvable problems popped up (including missing support by the SCons upstream), so they ditched SCons/bksys and went with CMake. Later on, somebody decided to do a complete rewrite of bksys/SCons, because some of the problems were apparently related so closely to the internals of SCons that there was no other feasible way of fixing them. I agree that the macro language of CMake is probably not the most beautiful solution (a port to Lua is planned, IIRC), but it has been proven to work almost flawlessly on huge projects. Even for the build system cracks of the KDE project, autotools was a constant source of trouble back when they used it – CMake apparently has solved most of the problems, while SCons/bksys failed at it. [1] http://lwn.net/Articles/188693/
Re: New home page
On 10/4/10 7:23 PM, Andrei Alexandrescu wrote: Hm, looks like only on my machines the page looks broken (see http://img96.imageshack.us/img96/4693/screenshot20101004at122.png). This occurs on FF/OSX and Chrome/Ubuntu. On my other two combos, the DMDScript column is not misaligned, but the whole thing is still too narrow and doesn't fill the width of the browser window. Could someone post a screen capture so I can figure how the site is meant to look? Thanks. Andrei It looks like this here: http://img838.imageshack.us/img838/816/screenshot20101004at742.png Have you modified the default font size setting of the browser? If the page uses mixed em/pixel units, layout bugs like this could occur, although there is quite a lot of other possible causes for that. By the way, I don't quite see how the vegetation-at-the-beach picture would qualify as background for a programming language news feed (http://twitter.com/D_Programming) – oh, and that file is about as big byte-wise as the rest of the page…
Re: Fedora 14 will integrate D into the distribution
On 9/29/10 1:29 PM, Daniel Gibson wrote: On Wed, Sep 29, 2010 at 1:20 PM, bioinfornatics bioinfornat...@fedoraproject.org wrote: And gdc is not a gcc project So? It's licensed under GPL, isn't that sufficient? (Besides the doesn't-support-gcc-4.5/4.6 issue) No, because in order to include your code with mainline GCC, you have to reassign the copyright to the Free Software Foundation…
Re: Fedora 14 will integrate D into the distribution
On 9/28/10 5:37 PM, Paulo Pinto wrote: Hi, it seems that Fedora will provide D out of the box in their distribution. But they seem to be providing an old version of it. https://fedoraproject.org/wiki/Features/D_Programming Cheers, Paulo Well, as far as I can tell, it's not exactly an old version – there is simply no Open Source (in capital letters) compiler for D2, and so they have to stick with D1 (where there is LDC). Yes, there would be GDC for D2 too, but even if it has been resurrected lately, it lags behind DMD more than a few versions…
Re: [OT] Google search restricted to a directory?
On 9/22/10 6:48 AM, Nick Sabalausky wrote: Simen kjaeraassimen.kja...@gmail.com wrote in message news:op.vjernw2lvxi...@biotronic-pc.lan... On Wed, 22 Sep 2010 02:28:25 +0200, Nick Sabalauskya...@a.a wrote: Anyone know if there's a way to do a google search restricted to not just a domain (as with site:whateversiteblahblah.com), but also to a particular directory? I've searched around but didn't see anything. Actually, come to think it of it, it doesn't strictly need to be google, just as long as it isn't total garbage. site:example.com inurl:your/path That good enough? Perfect :) You can even use the shorter »site:digitalmars.com/d/2.0« form – if you know the exact directory (and not just what's part of the url), you don't have to use inurl.
Re: Proposal: Relax rules for 'pure'
On 9/22/10 4:21 AM, Don wrote: PROPOSAL: Drop the first requirement. Only one requirement is necessary: A pure function does not read or write any global mutable state. If a pure function has parameters that are all immutable or are implicitly convertible to immutable, then the compiler is permitted to cache the results. I also support this proposal. In its current state, pure is pretty much useless, since you almost can't do anything serious with pure functions, let alone generic programming – it seems more like an excuse for not adding logic to determine whether a result can be cached to the optimizer than a true language feature…
Template parameter shadowing
In short, should the following be allowed?
---
class Class(T) {
string foo(T)(T arg) {
return T.stringof;
}
string bar() {
return T.stringof;
}
}
unittest {
auto c = new Class!int;
assert(c.foo(asdf) == string);
assert(c.bar() == int);
}
---
Note that the T type parameter to the template function shadows the one
from the template class, which might be a source of confusion since T
refers to class template parameter in other member functions.
Re: Proposal: Relax rules for 'pure'
On 9/22/10 7:10 PM, Steven Schveighoffer wrote: But the compiler will be able to tell. I think adding a __traits(isStronglyPure, symbol) will be good for those rare occasions where you really want to ensure purity. static assert(__traits(isStronglyPure, foo)); -Steve Shouldn't it be possible to implement that in a library template, not requiring any additions to the compiler at all?
Re: Proposal: Relax rules for 'pure'
On 9/22/10 9:14 PM, Steven Schveighoffer wrote:
Hypothetical counter-case
struct S
{
version(stronglypure)
string s;
else
char[] s;
}
pure foo(S s); // changes strength depending on S' contents
-Steve
This is a change to the signature of foo – S with the stronglypure
version defined and S without it are two completely distinct types.
Re: Andrei's Google Talk
On 9/21/10 3:55 PM, Steven Schveighoffer wrote: People seem to think that an accusation is proof. If someone says you stole their code, because you read it, it's not always true. It's just much easier to prove you didn't steal it if you didn't read it. And how exactly are you going to prove that you didn't read it?
Re: Andrei's Google Talk
And how exactly are you going to prove that you didn't read it? I should add that the whole situation seems like a paranoid's man version of »a burnt child dreads the fire« to me, but I guess Walter has his reasons…
Re: Andrei's Google Talk
On 9/21/10 4:31 PM, Steven Schveighoffer wrote: Huh? Look, this isn't an issue of being deceitful, it's an issue of the defensible strength of yes, I read it, but I didn't copy anything vs. no I didn't read it, so I couldn't have copied anything. If you don't believe the person, then it's up to you to prove they're lying. […] It's even possible to read code, understand the ideas, and write your own code to implement the ideas (commonly done via a clean-room implementation). I guess I don't quite understand US copyright laws here: Here in Europe, if somebody accuses you of copying their work, they have to prove that you in fact did copy it. Let's assume that person manages to convince a judge that your code is in fact a copy of theirs. To defend yourself, it should not really make a difference whether you claim that you read that code or not. Even if it mattered whether you looked at the code or not (at least for Europe, I'm reasonably sure that it does not), how are you going to convince the judge that you didn't look at the source code? After all, for Open Source projects, the source code is publicly available at the internet, and if you did not write your program in jail or deep down in the ocean in a submarine, there is always the possibility that you could have looked at the code. As I said, I don't really know much about the US copyright laws, but if you are used to common European jurisdiction, this situation seems pretty bizarre…
Re: Andrei's Google Talk
On 9/21/10 5:01 PM, Steven Schveighoffer wrote: People aren't convicted on possibilities they are convicted on proof. Okay, I suppose I was not as clear about my point as I hoped I would be: This is exactly what I wanted to say – if you want to sue somebody for copying your code, it has to be proven that they took your code, not just possible. But I don't see how just reading other people's code would affect that – either you copied it, or you didn't. My point about the source being freely available on the internet was just to illustrate that claiming »But, your honor, I didn't even read that other piece of code« does not seem like a very strong defense to me *if the court has already been convinced that you copied other code*, e.g. by an expert's opinion. I should also add that I am no lawyer, and I am generally only very modestly experienced in legal issues, so please bear with me if my questions don't make much sense – I just want to understand the reason why Walter is so exceptionally afraid of looking at other projects. To me, it seems a bit as if a researcher refused to keep himself informed about scientific progress in the field he is working on, just because he could be accused of stealing from other people (yes, that's a weak analogy, I know). Oh, and I am perfectly aware of the fact that there is no common European jurisdiction in these matters, but to the best of my knowledge, the laws regarding intellectual property are quite similar from a high-level point of view in many European countries – and probably in large contrast with US copyright laws, which is what I intended to hint at.
Re: Andrei's Google Talk
On 9/21/10 10:58 PM, Walter Bright wrote: klickverbot wrote: On 9/20/10 5:10 PM, Bruno Medeiros wrote: I find myself wishing some more OSS projects had commercial-friendly licenses. :-/ In particular LLVM, as I do agree it might have been great if Walter were able to work with it without these IP worries. You want something even more liberal than BSD? The Boost license we use in Phobos is more liberal than BSD. And that's exactly why we picked it. It was the most liberal one we could find that was in wide use. Yes, and I agree that Boost was and is a good choice for a standard library – binary attribution is a no-go for many applications. But Bruno was referring to LLVM, and for a compiler, BSD seems like a reasonable choice to me (parties like Apple and Adobe are free to use it, but cannot claim they wrote it themselves). Oh, by the way, none of my comments were intended to be an insult against you, I were really just curious why you have an exceptionally defensive opinion on possible copyright infringements (well, for the Open Source world, at least)…
GC- and thread-related deadlock
Hi all,
any idea why the following sample deadlocks on Linux x86_64?
(GDB stacktraces: http://gist.github.com/587964)
---
module test;
import core.thread;
import std.conv;
import std.range;
import std.string;
enum THREADS = iota(0, 9);
enum WORK_RANGE = iota(0, 3);
void main() {
Thread[] threads;
// Invoke the threads.
foreach (i; THREADS) {
auto thread = new Thread(run);
threads ~= thread;
thread.start();
}
// Wait for the threads to finish.
foreach (i, thread; threads) {
thread.join(true);
}
}
void run() {
foreach (i; WORK_RANGE) {
string data = to!string(toStringz(Some random string which
contains some random words.));
}
}
Re: GC- and thread-related deadlock
Might possibly be related: http://d.puremagic.com/issues/show_bug.cgi?id=4890,
Re: Andrei's Google Talk
On 9/20/10 5:10 PM, Bruno Medeiros wrote: I find myself wishing some more OSS projects had commercial-friendly licenses. :-/ In particular LLVM, as I do agree it might have been great if Walter were able to work with it without these IP worries. You want something even more liberal than BSD?
Re: Language features and reinterpret casts
On 9/20/10 11:52 PM, bearophile wrote: Recently Bradley Mitchell in D.learn newsgroup has tried to implement the Quake fast inverse square root algorithm in D, and has found D lack the C++ reinterpret cast: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learnarticle_id=21901 Are there any cases where (*cast(int*)someFloat) does not fit the bill?
Re: QtD is suspended
On 9/17/10 12:25 AM, Lutger wrote: Is the most recent flavor of QtD the repositoy at bitbucket? Yes, it is. Reminds me that someone should probably update the Wiki page at dsource…
Re: string to char*
On 9/11/10 3:00 PM, shd wrote: Hello, I'm having a problem in passing a value to char* expecting function in D 2.0. Already tried: to!(char*)(my string); but it seems like there (Phobos) is no template like this. Then, tried: cast(char*)to!(char[])(my string) which looked ok, but i think it's not a proper way to do that. Most strings converted this way works properly, but once: char* string1 = cast(char*)to!(char[])(my string 1); char* string2 = cast(char*)to!(char[])(my string 2); resulted: string1 = my string 1 string2 = my string 1my string 2 I can't manage this problem, could You hint me? Use std.string.toStringz to convert a D string to a C null-terminated one. This asymmetry (no to!(char*)(string)) has been discussed once, but I can't remember the reason why it was not implemented right now.
Re: D1/D2: How to check if a method has been overridden
Thanks a lot, Max, for some reason this works, while my own, very similar solution doesn't. Unfortunately, however, this exposes yet another DMD bug: http://d.puremagic.com/issues/show_bug.cgi?id=4860.
Re: D1/D2: How to check if a method has been overridden
On 9/8/10 8:25 AM, Kagamin wrote: Isn't this info available through classinfo? How exactly would you look this up using classinfo? Maybe it's the lack of documentation, but I didn't see a way to achieve that with Classinfo and friends…
D2: immutable/const and delegates
I always thought I had understood the new const/immutable system of D2.
But now this:
---
import std.stdio;
class A {
void setI( int newI ) {
i = newI;
}
int i;
}
void main() {
immutable a = new immutable(A);
writefln( Before: %s, a.i );
( a.setI )( 42 );
writefln( After: %s, a.i );
}
---
I would expect this not to compile, but for some reason it does (and the
assignment works, a.i is 42 after the call to setI).
Am I severely misunderstanding something here, or is this a rather big
hole in the type system?
Re: D2: immutable/const and delegates
On 9/8/10 11:46 AM, klickverbot wrote: Am I severely misunderstanding something here, or is this a rather big hole in the type system? Ah, never mind, there is even a (more than two years old!) bug report about it: http://d.puremagic.com/issues/show_bug.cgi?id=1983
D1/D2: How to check if a method has been overridden
Hello all,
as some of you might know, I have started working on a D module for SWIG
quite some time ago. In the meantime, the project is almost ready for
inclusion in SWIG trunk as a full-fledged language module supporting
D1/Tango and D2/Phobos.
However, there is one major blocker left: I need to check if a method
has been overridden for this in a potential subclass (obviously at
runtime), as illustrated below.
---
class A {
void foo( float a ) {}
void foo( int a ) {}
final void bar() {
// Determine whether this.foo( 1 ) and this.foo( 1f ) really refer
// to A.foo( float ) and A.foo( int ) or if they point to a subclass
// implementation – how?
}
}
class B : A {
override void foo( float a ) {}
}
class C : A {
override void foo( int a ) {}
}
class D : B {
override void foo( int a ) {}
}
---
Until DMD 1.047, I have used a piece of code shown in
http://d.puremagic.com/issues/show_bug.cgi?id=4835, but the casts in
there are no longer enough for DMD to determine which overload is being
referred to.
Now, please tell me that there _is_ a way to do this (D1 and D2, but I
don't mind if have to generate different code for the both)…
Re: D1/D2: How to check if a method has been overridden
On 9/7/10 11:12 PM, dsimcha wrote: One way to test for overriding at runtime is to compare the function pointer of a delegate obtained at runtime to the function pointer obtained from the compile time type. That's basically the same idea I were already using, but have you tried implementing it for overloaded functions? I have not gotten this to work since there is seemingly no way to do a.foo then.
Re: D1/D2: How to check if a method has been overridden
On 9/7/10 11:07 PM, Mafi wrote: I'm not sure if the right isn't an shortcut for the left […] Unfortunately, the right indeed is a shortcut for the left – the lookup is performed using the vtbl. Furthermore, this would not solve my problem with overloaded functions.
Re: D1/D2: How to check if a method has been overridden
On 9/7/10 11:31 PM, bearophile wrote:
Have you tried to compile that code with -w?
See also:
http://d.puremagic.com/issues/show_bug.cgi?id=4216
Bye,
bearophile
Well, I guess I should have wrote the following instead:
---
class A {
void foo( float a ) {}
void foo( int a ) {}
final void bar() {
// Determine whether this.foo( 1 ) and this.foo( 1f ) really refer
// to A.foo( float ) and A.foo( int ) or if they point to a subclass
// implementation – how?
}
}
class B : A {
alias A.foo foo;
override void foo( float a ) {}
}
class C : A {
alias A.foo foo;
override void foo( int a ) {}
}
class D : B {
alias B.foo foo;
override void foo( int a ) {}
}
---
Re: D1/D2: How to check if a method has been overridden
s/have wrote/have written/
Re: D1/D2: How to check if a method has been overridden
Putting the overloading issue aside for a moment, how would you
implement it inside a member function of a (which is required for
various reasons?
The following does *not* work, because A.foo also performs a vtbl
lookup when put inside A…
---
class A {
void foo() {}
void bar() {
auto thisDg = this.foo;
writeln(A.foo is thisDg.funcptr);
}
}
---
Besides, it also returns a delegate because of this, which is why the
code does not even compile, but that would be worked around easily.
Re: CMake for D2 ready for testers
Thanks a lot – I was just thinking about writing something like that myself when I stumbled over this post! I have just switched to OS X, so I probably will be able to help you out in that regard. I'll report back when I have found time to have a look on it.
Re: Bikeshedding fun: suggest a name for 64 bit Phobos library
Please, please just call it libphobos2.a on Linux and move it to the 64bit library directory. On OS X, one might want to build it as universal binary, so no special casing needed there either. On Windows it is installed to the DMD directory anyway, so this is probably no issue either (3d-bit-dmd/lib = 32 bit Phobos, 64-bit-dmd/lib = 64 bit Phobos), but I am no Windows guy.
Re: Please comment on http://d-programming-language.org/
On http://d-programming-language.org/memory-safe-d.html, the menu sidebar (which is a bit on the long side for the language reference in my mind) extends below the footer, which looks awkward. Also, I personally think that the logo header in its current state is plain ugly – maybe making the font larger and putting the DigitalMars logo to the right side of it would be an idea?
Type inference in array literals
I was really surprised by the fact that the following code does not work
(DMD 2.048 infers the type of the array literal to B[], not Object[]):
---
class A {}
class B {}
void main() {
Object[] foo = [ new A, new B ];
}
---
Is this by design? If so, what are the reasons for not using the first
common supertype of all the elements as type for the array literal?
This is quite irritating, since there apparently is no direct way of
specifying the array literal save for casting the first element to
Object (or whatever base class/interface you actually use in your code),
which looks quite strange.
D1: accepts-invalid?
Hello all,
currently, DMD accepts the following code, but the resulting binary
bus-errors at runtime:
---
import std.stdio;
void foo( string str ) () {
writefln( str );
}
void bar( string text ) {
foo!( text );
}
void main() {
bar( asdf );
}
---
Shouldn't this be a compile-time error?
Thanks,
klickverbot
Re: yank unary '+'?
Mike Parker wrote: […] I think C programmers are smart enough to figure things out without the language keeping around old syntax. If they want C, they can stick with C. I think so too – the »new«, D function pointer syntax is much more readable and intuitive than the C one which is widely regarded as being quite messy, especially in more complex declarations. Please do not even start to think about removing elements with valid use- cases (even if there were hardly any) in the name of reducing language complexity (note aside: I do not really see how one more unary operator could really make a difference here) before removing redundancies…
Re: dmd 1.053 and 2.037 release
Max Samukha wrote:
I think the following real-world code is a good argument against comma
operators:
template typename T
Q_INLINE_TEMPLATE void QListT::node_destruct(Node *from, Node *to)
{
if (QTypeInfoT::isLarge || QTypeInfoT::isStatic)
while(from != to) --to, delete reinterpret_castT*(to-v);
else if (QTypeInfoT::isComplex)
while (from != to) --to, reinterpret_castT*(to)-~T();
}
I have never used the comma operator in my own code, but in my opinion this
particular piece of code is really easy and fluent to read.
»Maintainability« is admittedly, however, a different topic.
Re: lazy redux
Denis Koroskin wrote: Although I believe it is implementable and worth the trouble, there is a little gain in this feature and that's probably why it is low in the list. I think that Walter will give a green light if someone implements the feature and provides a complete patch. Any volunteers? If someone should step forward to implement this: I would really like to be able to omit the semicolon inside one-statement delegates/lambdas. It makes using them feel much more natural (at least to me) – just look at some Ruby code.
Re: Tagging
Sean Kelly wrote: It's easier because it could be built into the Druntime/Phobos makefiles and not rely on a release script or manual effort to actually happen. Are you saying that a SVN one-liner once per release requires too much effort on Walter's side? Apart from that, I don't quite see how you proposed solution would solve the orginal problem – the whole point behind having tagged releases is having _SCM_ support for comparing versions, etc…
D1: Member function delegate issues
(This would probably fit better on bugzilla, but for whatever reason I
cannot access it at the moment. Please feel free to move this to the tracker
and CC me if it is really a bug.)
As you might remember from #d and d.D.learn, I want to check if a given
member function has been overridden (at runtime, of course). A simple test
using delegates looks promising:
---
class A {
public:
void foo() {
Stdout( I am in A. ).newline;
}
}
class B : A {
public:
override void foo() {
Stdout( I am in B. ).newline;
}
}
void main() {
auto baseMethod = A.foo;
A a = new A();
a.foo();
auto aMethod = a.foo;
Stdout.formatln( foo overridden in a: {},
( baseMethod !is aMethod.funcptr ) );
A b = new B();
b.foo();
auto bMethod = b.foo;
Stdout.formatln( foo overridden in b: {},
( baseMethod !is bMethod.funcptr ) );
}
---
For use in my application, I tried to move the checking code to A, which
should be no problem, at least according to the principle of least surprise:
---
class A {
public:
void foo() {
Stdout( I am in A. ).newline;
}
bool isFooOverridden() {
auto methodThis = foo;
auto methodBase = A.foo;
return ( methodThis.funcptr !is methodBase.funcptr );
}
}
class B : A {
public:
override void foo() {
Stdout( I am in B. ).newline;
}
}
void main() {
A a = new A();
a.foo();
Stdout.formatln( foo overridden in a: {}, a.isFooOverridden() );
A b = new B();
b.foo();
Stdout.formatln( foo overridden in b: {}, b.isFooOverridden() );
}
---
However, this does not work because the address of A.foo is looked up at
runtime via the vtable in this case, effectively defeating the intent behind
the pointer comparison.
Have I hit a bug here or is it written somewhere in the spec? If this should
really be the intended behavior, I would strongly suggest altering it
because it seems highly counterintuitive to me. Moveover, I cannot really
see that the current behavior would have any benefits.
Sorry if this has already been discussed, but as I mentioned before, I
cannot access the D bugzilla at the moment…
Re: removal of cruft from D
Nick Sabalausky wrote: Yes! Capitalization consistency in the predefined versions! /agree Altough this is only a minor itch, I would really like to scratch it – following consistent capitalization rules would probably make it more intuitive to a much larger user group than coinciding with the usage by some C compiler…
