Texas LinuxFest 2011 call for papers now open
http://www.texaslinuxfest.org/callforpapers/ One topic of interest is Open Source Programming Languages. If someone could explain to me the various subtle nuances of what an open source programming language is, I'll try to make a D-related submission and of course I recommend anyone else to do the same. Andrei
Re: Texas LinuxFest 2011 call for papers now open
Andrei Alexandrescu wrote: http://www.texaslinuxfest.org/callforpapers/ One topic of interest is Open Source Programming Languages. If someone could explain to me the various subtle nuances of what an open source programming language is, I'll try to make a D-related submission and of course I recommend anyone else to do the same. Andrei This is a matter of perspective, I think these are the possibly interesting angles and issues for D: - availability and development of Open Source compilers (OSI compatible license) - cross-platform design, this extends beyond linux but is often a concern and goal in the Open Source world - development process of the language (and std lib) itself: here the community participation is important. For D it's an interesting (and ongoing) story to tell. - usefulness and place in the open source ecosystem: I believe D has a potential here as a serious alternative for both mono and java. Mono, the open source implementation of .net, has loads of potential patent issues and for this reason is not supported by some distro's. Java also has it's issues. Positioning D as a solution to those problems (rather than an alternative for C++ or dynamic languages) will please the crowd, for sure :) Interoperability with C is also important here.
Re: Texas LinuxFest 2011 call for papers now open
Andrei Alexandrescu seewebsiteforem...@erdani.org http://www.texaslinuxfest.org/callforpapers/ One topic of interest is Open Source Programming Languages. If someone could explain to me the various subtle nuances of what an open source programming language is, I'll try to make a D-related submission and of course I recommend anyone else to do the same. Andrei See:http://en.wikipedia.org/wiki/Open-source_software Some may considers D is Open Source. Some others may consider it's not. Many uses the following definition for Open Source. I think it means that DMD (the reference implementation) would not be considered as Open Source. The Open Source Definition is used by the Open Source Initiative to determine whether or not a software license can be considered open source. The definition was based on the Debian Free Software Guidelines, written and adapted primarily by Bruce Perens. They are by no means definitive even as applied to software. Clause 3 is the primary legal difference between free software and open source software as such, free software is stricter in interpreting 3. Clauses 5 and 6 are not a condition of any major open content license regimes, which commonly do restrict types of uses and users; for instance, Creative Commons has open content licenses that explicitly forbid commercial use. Introduction Open source doesn't just mean access to the source code. The distribution terms of open-source software must comply with the following criteria: 1. Free Redistribution The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale. 2. Source Code The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed. 3. Derived Works The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. 4. Integrity of The Author's Source Code The license may restrict source-code from being distributed in modified form only if the license allows the distribution of patch files with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software. 5. No Discrimination Against Persons or Groups The license must not discriminate against any person or group of persons. 6. No Discrimination Against Fields of Endeavor. The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research. 7. Distribution of License The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties. 8. License Must Not Be Specific to a Product The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution. 9. License Must Not Restrict Other Software The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software. 10. License Must Be Technology-Neutral No provision of the license may be predicated on any individual technology or style of interface.
Re: Texas LinuxFest 2011 call for papers now open
Am 20.01.2011 19:58, schrieb Lutger Blijdestijn: Andrei Alexandrescu wrote: http://www.texaslinuxfest.org/callforpapers/ One topic of interest is Open Source Programming Languages. If someone could explain to me the various subtle nuances of what an open source programming language is, I'll try to make a D-related submission and of course I recommend anyone else to do the same. Andrei This is a matter of perspective, I think these are the possibly interesting angles and issues for D: - availability and development of Open Source compilers (OSI compatible license) (x) we have gdc and ldc (check how well current versions with D2 work before talking about them, though ;)) - cross-platform design, this extends beyond linux but is often a concern and goal in the Open Source world (x) Windows, Linux, OSX, FreeBSD are supported, with gdc/ldc probably more - development process of the language (and std lib) itself: here the community participation is important. For D it's an interesting (and ongoing) story to tell. (x) agree. Also: The std lib is under a very free license (unlike for example suns/oracles classpath.. OpenJDK seems to be GPLed, but that still sucks for a std lib) - usefulness and place in the open source ecosystem: I believe D has a potential here as a serious alternative for both mono and java. Mono, the open source implementation of .net, has loads of potential patent issues and for this reason is not supported by some distro's. Java also has it's issues. Positioning D as a solution to those problems (rather than an alternative for C++ or dynamic languages) will please the crowd, for sure :) You can never be sure with patents, as someone else in another thread already pointed out: it's virtually impossible to write a piece of software that doesn't infringe patents. Of course, the situation is worse with Java (as seen in Oracle suing Google for using a Java-derivate in Android) and Mono (you never know if Microsoft will tolerate this forever. Even if they promised not to sue for current .net related patents, you never know about patents applying to features in future versions of .net). With D at least people still would have to find patents that are infringed - and even then the case isn't as clear as with Java/mono, where it's obvious that the Java/.net related patents are infringed. So yes, the point that D may cause less trouble than Java/.net can be made, but you probably shouldn't claim that D doesn't infringe any patents, because you can't possibly know (nobody can, there are just too many software patents to check, even for big companies). Interoperability with C is also important here. Yeah, it's a killer-feature. Being able to just call C functions and link objects produced by gcc objects (foo.o) is *really* helpful, especially in the Linux world. I think D (with gdc/ldc) qualifies as an Open Source Programming Language, but you should probably ask the texaslinuxfest guys for their personal definition. Cheers, - Daniel
Re: Texas LinuxFest 2011 call for papers now open
Daniel Gibson wrote: ... You can never be sure with patents, as someone else in another thread already pointed out: it's virtually impossible to write a piece of software that doesn't infringe patents. Yes, it's like bugs: you can tell when you found one, but never know your software is free of it. (well, that is almost true) Of course, the situation is worse with Java (as seen in Oracle suing Google for using a Java-derivate in Android) and Mono (you never know if Microsoft will tolerate this forever. Even if they promised not to sue for current .net related patents, you never know about patents applying to features in future versions of .net). With D at least people still would have to find patents that are infringed - and even then the case isn't as clear as with Java/mono, where it's obvious that the Java/.net related patents are infringed. So yes, the point that D may cause less trouble than Java/.net can be made, but you probably shouldn't claim that D doesn't infringe any patents, because you can't possibly know (nobody can, there are just too many software patents to check, even for big companies). Technically that is right, but I find it a bit of an understatement because every non trival software project has potential issues. With .NET and Java you *know* you have patent issues, with D any potential patent issue is a tragic mistake that still has to be proven to exist. Those are not on the same scale, so I wouldn't use the term 'less trouble' You also have ownership to take into account, I would rather trust Walter Bright not using submarine patent traps than MS or Oracle :)
Re: Texas LinuxFest 2011 call for papers now open
Daniel Gibson wrote: ... So yes, the point that D may cause less trouble than Java/.net can be made, but you probably shouldn't claim that D doesn't infringe any patents, because you can't possibly know (nobody can, there are just too many software patents to check, even for big companies). Perhaps I should elaborate a bit. mono is simply out of the question in a large part of linux. Fedora for example, has D as a feature for its 14 release but doesn't support mono. Java is more complex, but if we take it out of the picture it leaves (some of) linux with C / C++ on the one hand and a lot of higher level dynamic languages on the other. In between are some more 'exotic' languages such as haskell. Perhaps I'm wrong, but I see a big void there where D can step in, mostly because of its set of features. In the non-open-source world, Java and .NET are already taking care of much of this void.
Re: Texas LinuxFest 2011 call for papers now open
Am 20.01.2011 21:15, schrieb Lutger Blijdestijn: Daniel Gibson wrote: ... So yes, the point that D may cause less trouble than Java/.net can be made, but you probably shouldn't claim that D doesn't infringe any patents, because you can't possibly know (nobody can, there are just too many software patents to check, even for big companies). Technically that is right, but I find it a bit of an understatement because every non trival software project has potential issues. With .NET and Java you *know* you have patent issues, with D any potential patent issue is a tragic mistake that still has to be proven to exist. Those are not on the same scale, so I wouldn't use the term 'less trouble' You also have ownership to take into account, I would rather trust Walter Bright not using submarine patent traps than MS or Oracle :) I mostly agree with you :-) Maybe less trouble is not the right word.. my point is: I guess Walter did not explicitly try to avoid patents when developing D (and, as mentioned before, you can't be sure anyway), so you probably can't advertise D as a patent-free language (like ogg vorbis is claimed to be a patent-free audio codec). And I don't believe Walter is using any patent traps (Does he hold any patents? I wouldn't be surprised, and I don't really care because I don't believe he'd use it offensively) - but once D is popular you never know if a third party starts trolling. But of course, this may happen with any language or software in general. Furthermore, there was this thread in d.D about two Borland patents that are now owned by M$ that *may* be infringed by D... Perhaps I should elaborate a bit. mono is simply out of the question in a large part of linux. Fedora for example, has D as a feature for its 14 release but doesn't support mono. Java is more complex, but if we take it out of the picture it leaves (some of) linux with C / C++ on the one hand and a lot of higher level dynamic languages on the other. In between are some more 'exotic' languages such as haskell. Perhaps I'm wrong, but I see a big void there where D can step in, mostly because of its set of features. In the non-open-source world, Java and .NET are already taking care of much of this void. I agree. A free language that works well with C and is at least as user-friendly as Java definitely has a lot of potential in the open source and esp. Linux/*BSD world. Many Open Source developers will prefer it to Java/Mono, because it doesn't use a VM (some may still complain about the garbage collector, though, but in the end they'd benefit from it, because it mostly prevents the quite common memory leaks). Another thing that should be considered: For D2 to be really interesting in the Linux world, stream and socket handling needs to improve. But it seems like this will happen, Andrei started a discussion about a new std.stream in d.D recently. Cheers, - Daniel
Re: boxen - an audio player written in D
Why is there no advertisement for D, the MagicCounter page lists C# right at the top ;) The directory tree sorts everything by name, would be cool if listing directories first was possible as well. It really needs a proper icon, looks shitty in the taskbar ;) Nice tool!
Re: boxen - an audio player written in D
Oh, I forgot to mention D! I'll edit it in ASAP :) And you're right about the directory thing, I'll put it on my TODO list. Thanks!
Re: boxen - an audio player written in D
Also playback stops when a directory is reached in the list.
Re: Potential patent issues
On Wed, 2011-01-19 at 22:37 +0100, Simen kjaeraas wrote: Nick Sabalausky a@a.a wrote: retard r...@tard.com.invalid wrote in message news:ih7jv4$q49$7...@digitalmars.com... Wed, 19 Jan 2011 15:44:38 -0500, Nick Sabalausky wrote: Andrej Mitrovic andrej.mitrov...@gmail.com wrote in message news:mailman.724.1295465996.4748.digitalmar...@puremagic.com... Or pack your bags and move to Europe. :p I thought Europe was getting software patents? It's the US intellectual property mafia pushing software patents to EU via WIPO, bribes, and extortion. Well yea, but whatever the source of it, I was under the impression that it was succeeding, or had already succeeded. In the EU, it is succeeding at least to an extent. However, many EU members do not want software patents, and few European countries outside EU would consider it. (about half of Europe is not part of the EU) The EU Patent Office is trying hard to succumb to the US pressure to start issuing software patents in the same way USPTO does. It will be a disaster if they are allowed to get away with this. So anyone in the EU, make sure your MEP (or whatever you label your elected representative) knows what is going on, knows that this is a land grab by the US corporates to stiffle competition and innovation in EU. The problem here is ACTA. The software patents advocates (via USTR) have managed to infiltrate this global agreement so as to force all signatories to follow US rules on software patents. This will force EU members to do the unthinkable and honour all US software patents. If this happens we might all as well give up writing software unless we work for a huge corporation who can play the patent cross-licencing game. If the populace doesn't act, they will be shafted. PS Read the relevant articles at http://webmink.com/ especially http://webmink.com/?s=ACTA. Simon Phipps is 110% correct on the issues associated with ACTA. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: What Makes A Programming Language Good
On 2011-01-19 21:13, Adam Ruppe wrote: Vladimir Panteleev wrote: Your tool will just download the latest version of Y and the whole thing crashes and burns. My problem is I don't see how that'd happen in the first place. Who would distribute something they've never compiled? If they compiled it, it would have downloaded the other libs already, so any sane distribution *already* has the dependent libraries, making this whole thing moot. The build tool is meant to help the developer, not the user. If the user needs help, it means the developer didn't do his job properly. I would say it's for the user of the library. He only cares about the library he wants to use and not its dependencies. That said, the configuration file, as described in my last post, seems like it can solve this easily enough. -- /Jacob Carlborg
Re: What Makes A Programming Language Good
In digitalmars.D, you wrote: The two most frustrating aspects were documentation and deployment. The documents were sparse and useless and deployment was the hugest headache I've ever experienced, in great part due to Rubygems not working properly! They've probably improved it a lot since then, but it reinforced my long-standing belief that third party libraries are, more often than not, more trouble than they're worth anyway. I only poked into RubyGems briefly and I had the same impression at the time. Perl's CPAN is much more mature. Much of the time, I feel as you do about 3rd party libraries. They try to do too much, are inflexible and not customizable. But many of the perl packages on CPAN are written to address a single task, are flexible and easy to use. I use several and have my favorites. Others are not worth the trouble. But this problem is going to happen to any system. Some of the packages are simply useless, poorly designed, too specific, not supported, out of date, etc. But other packages are well designed, well supported, work great. Some haven't changed in ages and work well. I think counters can help -- how many downloads, indicating popularity. How many _recent_ downloads, or a histogram of downloads by month so the user can tell if the package is out of date. Don't like the rating systems much, but that's also a possibility. An integrated bug database and forums similar to sourceforge would be very useful. You can check activity and see if the author of the package is active and keeps on top of problems. -- Brad
Re: What Makes A Programming Language Good
On Wed, 19 Jan 2011 19:40:49 +0100 Jacob Carlborg d...@me.com wrote: 1. it uses python, yet another dependency True, but it brings more features over e.g. cmake 'cause you have full language on disposal. 2. it seems complicated Well, build systems are complex... ;) Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: What Makes A Programming Language Good
I missed a lot of this thread and coming in part way through may miss lots of past nuances, or even major facts. On Thu, 2011-01-20 at 10:19 +0100, Gour wrote: On Wed, 19 Jan 2011 19:40:49 +0100 Jacob Carlborg d...@me.com wrote: 1. it uses python, yet another dependency True, but it brings more features over e.g. cmake 'cause you have full language on disposal. Waf and SCons (both Python based) are top of the pile in the C/C ++/Fortran/LaTeX build game, with CMake a far back third and everything else failing to finish. In the Java/Scala/Groovy/Clojure build game Gradle beats Maven beats Gant beats Ant, for the reason that Groovy beats XML as a build specification language. Internal DSLs using dynamic languages just win in this game. (Though the Scala crew are trying to convince people that SBT, a build tool written such that you use Scala code to specify the build is good. It is a priori but it has some really critical negative design issues.) 2. it seems complicated Well, build systems are complex... ;) Definitely. Well at least for anything other than trivial projects anyway. The trick is to make it as easy as possible to specify the complexity easily and comprehensibly. Make did this in 1978, but is not now the tool of choice. Autotools was an heroic attempt to do something based on Make. CMake likewise. SCons, Waf, and Gradle are currently the tools of choice. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Another task
Simen kjaeraas:
byKey is essentially an opApply. You have to wrap it in a fiber to make it
work with the range interface:
Thank you for all your code and work.
I have found a bug (it's not a bug of yours): if I compile your code with
-release, DMD prints:
test.d(45): Error: function D main is a nested function and cannot be accessed
from array
test.d(45): Error: function D main is a nested function and cannot be accessed
from array
Where the line 45 is the one that starts with: auto o = map!(...
I use D associative arrays often (it comes from my Python practice), I suggest
to modify AAs to change byKey() and byValue() into ranges usable with
std.algorithm.
AAs may become iterable with zero method calls too (this is equivalent to byKey
or byValue):
map!q{a*10}([1:2, 3:4])
And I suggest to add a third associative array member function that returns a
range of key,value tuples, as in Python3. This allows to solve the task like
this:
auto r = map!q{ tuple(a[0]*10, a[1]~a[1]) }(aa.byPair());
Bye,
bearophile
Re: Potential patent issues
On 01/19/2011 10:09 PM, retard wrote: Wed, 19 Jan 2011 15:44:38 -0500, Nick Sabalausky wrote: Andrej Mitrovicandrej.mitrov...@gmail.com wrote in message news:mailman.724.1295465996.4748.digitalmar...@puremagic.com... Or pack your bags and move to Europe. :p I thought Europe was getting software patents? It's the US intellectual property mafia pushing software patents to EU via WIPO, bribes, and extortion. Don't put everything on the back of the US ;-) We in Europe have our own financial mafia pushing for the same kind of extortion system as in the US! Deins _ vita es estrany spir.wikidot.com
Re: xxxInPlace or xxxCopy?
Andrej Mitrovic:
I think what might help out in D is if we had a way to mark some
functions so the compiler guarantees that their return values *are
not* to be discarded. For example, this code will compile:
import std.stdio;
import std.string;
void main()
{
string s = Mary has a lil lamb.;
replace(s, lil, li'l); // returns a copy, but discards it
}
If the replace function is marked with some kind of @nodiscard
annotation, then his would be a compile error since it doesn't make
sense to construct a new string, return it, and discard it.
But maybe that's going overboard. How often do these kinds of bugs creep in?
Such bugs are common enough. GNU C has the warn_unused_result attribute (that
is like your @nodiscard if you use -Werror to turn warnings into errors):
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html
Some C lints require a void cast where you don't want to use a function result:
cast(void)replace(s, lil, li'l);
In a language the default is different and where you don't want to use a
function result you have to add an annotation:
unused replace(s, lil, li'l);
Something like @nodiscard is more useful in C than D because in C there are no
true built-in exceptions, so error return values are common, and ignoring them
is a mistake. In some cases like replace() or the C realloc() ignoring a result
is always a programmer error. So something like @nodiscard is useful in D too.
Bye,
bearophile
Re: Potential patent issues
Am 20.01.2011 11:19, schrieb spir: On 01/19/2011 10:09 PM, retard wrote: Wed, 19 Jan 2011 15:44:38 -0500, Nick Sabalausky wrote: Andrej Mitrovicandrej.mitrov...@gmail.com wrote in message news:mailman.724.1295465996.4748.digitalmar...@puremagic.com... Or pack your bags and move to Europe. :p I thought Europe was getting software patents? It's the US intellectual property mafia pushing software patents to EU via WIPO, bribes, and extortion. Don't put everything on the back of the US ;-) We in Europe have our own financial mafia pushing for the same kind of extortion system as in the US! Deins _ vita es estrany spir.wikidot.com Yes. Of course it's also US companies like Microsoft who want software patents here - but we've got a few ones ourselves, for example SAP and Siemens. Don't know if there are many more european companies who want this, though.
Re: What Makes A Programming Language Good
On Thu, 20 Jan 2011 10:13:00 + Russel Winder rus...@russel.org.uk wrote: SCons, Waf, and Gradle are currently the tools of choice. Gradle is (mostly) for Java-based projects, afaict? Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: DVCS
On 01/20/2011 12:24 AM, Gour wrote: I've feeling that you just copied the above from FAQ and never actually tried Archlinux. No, I haven't tried it. I'm not going to try every OS that comes down the pike. If the FAQ says that you're going to have to be more of an expert with your system, then I believe it. If it's wrong, then maybe you can push them to update it. The do-it-yourself from the above means that in Arch user is not forced to use specific DE, WM etc., can choose whether he prefers WiCD over NM etc. So instead of giving you a bunch of sane defaults, you have to make a bunch of choices up front. That's a heavy investment of time, especially for somebody unfamiliar with Linux. That's not true...In Arch there is simply no Arch-8.10 or Arch-10.10 which means that whenever you update your system package manager will simply pull all the packages which are required for desired kernel, gcc version etc. The upgrade problems are still there. *Every package* you upgrade has a chance to be incompatible with the previous version. The longer you wait, the more incompatibilities there will be. Otoh, with Ubuntu, upgrade from 8.10 to 10.10 is always a major undertaking (I'm familiar with it since '99 when I used SuSE and had experience with deps hell.) Highlighting the problem of waiting too long to upgrade. You're skipping an entire release. I'd like to see you take a snapshot of Arch from 2008, use the system for 2 years without updating, and then upgrade to the latest packages. Do you think Arch is going to magically have no problems?
Re: xxxInPlace or xxxCopy?
If you have replace(str, hello, world); you don't know whether it's changed the value in place or if you're throwing away a return value. However, if you have auto newStr = replace(str, hello, world); replaceInPlace(newStr, world, hello); it's quite clear that the first one returns a value and the the second one does it in place. Very true. Imho function names would also be more understandable this way cause xInPlace is unambiguous while xCopy might lead to confusion (at least I could imagine a stranger misinterpreting replaceCopy etc.)
Re: xxxInPlace or xxxCopy?
If such an annotation was introduced, it should be the other way around. But imo discarding a return value should always result in a warning, the function returns something for a reason.
Re: xxxInPlace or xxxCopy?
On Thursday 20 January 2011 03:51:48 Trass3r wrote: If such an annotation was introduced, it should be the other way around. But imo discarding a return value should always result in a warning, the function returns something for a reason. Actually, there are plenty of cases where you throw away the return value. A number of overloaded operators are prime examples - such as opAssign. std.algorithm.sort both sorts in place _and_ returns a sorted range (so that other algorithms can then know that the range is sorted). It's really quite easy to get legitimate cases where throwing away the return value makes perfect sense. Now, if you're dealing with a strongly pure function which throws away its return value, then yes, that's definitely bug, since the only effect of the function is its return value. Frequently however, that's not the case. Yes, you can have bugs because you didn't actually use the return value of a function, but it's that necessarily uncommon to have function calls which legitimately throw away their return value. - Jonathan M Davis
Re: What Makes A Programming Language Good
On Thu, 2011-01-20 at 12:32 +0100, Gour wrote: On Thu, 20 Jan 2011 10:13:00 + Russel Winder rus...@russel.org.uk wrote: SCons, Waf, and Gradle are currently the tools of choice. Gradle is (mostly) for Java-based projects, afaict? It is the case that there are two more or less distinct domains of build -- JVM-oriented, and everything else. There is though nothing stopping a single build system from trying to be more universal. Sadly every attempt to date has failed for one reason or another (not necessarily technical). Basically there seems to be a positive feedback loop in action keeping the two domains separate: basically the tools from one domain don't work well on the opposite domain and so no-one uses them there, so no evolution happens to improve things. In this particular case, Gradle has great support for everything JVM-related and no real support for C, C++, Fortran, etc. All attempts to raise the profile of the Ant C/C++ compilation tasks, which Gradle could use trivially, have come to nothing. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: DVCS
On Thursday 20 January 2011 03:39:08 Jeff Nowakowski wrote: On 01/20/2011 12:24 AM, Gour wrote: I've feeling that you just copied the above from FAQ and never actually tried Archlinux. No, I haven't tried it. I'm not going to try every OS that comes down the pike. If the FAQ says that you're going to have to be more of an expert with your system, then I believe it. If it's wrong, then maybe you can push them to update it. The do-it-yourself from the above means that in Arch user is not forced to use specific DE, WM etc., can choose whether he prefers WiCD over NM etc. So instead of giving you a bunch of sane defaults, you have to make a bunch of choices up front. That's a heavy investment of time, especially for somebody unfamiliar with Linux. That's not true...In Arch there is simply no Arch-8.10 or Arch-10.10 which means that whenever you update your system package manager will simply pull all the packages which are required for desired kernel, gcc version etc. The upgrade problems are still there. *Every package* you upgrade has a chance to be incompatible with the previous version. The longer you wait, the more incompatibilities there will be. Otoh, with Ubuntu, upgrade from 8.10 to 10.10 is always a major undertaking (I'm familiar with it since '99 when I used SuSE and had experience with deps hell.) Highlighting the problem of waiting too long to upgrade. You're skipping an entire release. I'd like to see you take a snapshot of Arch from 2008, use the system for 2 years without updating, and then upgrade to the latest packages. Do you think Arch is going to magically have no problems? There is no question that Arch takes more to manage than a number of other distros. However, it takes _far_ less than Gentoo. Things generally just work in Arch, whereas you often have to figure out how to fix problems when updating on Gentoo. I wouldn't suggest Arch to a beginner, but I'd be _far_ more likely to suggest it to someone than Gentoo. Arch really doesn't take all that much to maintain, but it does have a higher setup cost than your average distro, and you do have to do some level of manual configuration that I'd expect a more typical distro like OpenSuSE or Ubuntu to take care of for you. So, I'd say that your view of Arch is likely a bit skewed, because you haven't actually used it, but it still definitely isn't a distro where you just stick in the install disk, install it, and then go on your merry way either. - Jonathan M Davis
Re: What Makes A Programming Language Good
Am 20.01.2011 00:54, schrieb Adam D. Ruppe: Jesse Phillips wrote: You can have the author release packaged libraries for developers to use and the author should do this. So this begs the question of what is the repository for? It's so you have a variety of libraries available at once with minimal hassle when you are originally writing something. I really don't care about those libraries' implementation details. I just want it so when I type import something.lib; in my program it actually works. If something.lib's author wants to use other.thing, great, I just don't want to think about it anymore than I think about his private classes or functions. Why is the tool going out to different URLs and downloading files when you are supposed to use the pre-built lib? Pre-built libs aren't all that useful anyway, for several reasons: 1. Templates 2. different operating systems: there would have to be pre-built libs for Windows, OSX, Linux and FreeBSD (if not even more) 3. different architectures: there would have to be pre-built libs for x86, AMD64 and, thanks to GDC and LDC, for about any platform supported by Linux.. Just provide source, so people can build their own libs from it or just compile the sources like their own source files. This can still be done automagically by the build-tool/package management. Cheers, - Daniel
Re: xxxInPlace or xxxCopy?
Andrej Mitrovic: If the replace function is marked with some kind of @nodiscard annotation, then his would be a compile error since it doesn't make sense to construct a new string, return it, and discard it. http://d.puremagic.com/issues/show_bug.cgi?id=5464 Bye, bearophile
Re: DVCS
On Thu, 20 Jan 2011 06:39:08 -0500 Jeff Nowakowski j...@dilacero.org wrote: No, I haven't tried it. I'm not going to try every OS that comes down the pike. Then please, without any offense, do not give advises about something which you did not try. I did use Ubuntu... So instead of giving you a bunch of sane defaults, you have to make a bunch of choices up front. Right. That's why there is no need for separate distro based on DE user wants to have, iow, by simple: pacman -Sy xfce4 you get XFCE environment installed...same wit GNOME KDE. That's a heavy investment of time, especially for somebody unfamiliar with Linux. Again, you're speaking without personal experience... Moreover, in TDPL's foreword, Walter speaks about himself as ..of an engineer.., so I'm sure he is capable to handle The Arch Way (see section Simplicity at https://wiki.archlinux.org/index.php/Arch_Linux) which says: The Arch Way is a philosophy aimed at keeping it simple. The Arch Linux base system is quite simply the minimal, yet functional GNU/Linux environment; the Linux kernel, GNU toolchain, and a handful of optional, extra command line utilities like links and Vi. This clean and simple starting point provides the foundation for expanding the system into whatever the user requires. and from there install one of the major DEs (GNOME, KDE or XFCE) to name a few. The upgrade problems are still there. *Every package* you upgrade has a chance to be incompatible with the previous version. The longer you wait, the more incompatibilities there will be. There are no incompatibilities...if I upgrade kernel, it means that package manager will figure out what components has to be updated... Remember: there are no packages 'tagged' for any specific release! Highlighting the problem of waiting too long to upgrade. You're skipping an entire release. I'd like to see you take a snapshot of Arch from 2008, use the system for 2 years without updating, and then upgrade to the latest packages. Do you think Arch is going to magically have no problems? I did upgrade on my father-in-law's machine which was more then 1yr old without any problem. You think there must be some magic to handle it...ask some FreeBSD user how they do it. ;) Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: DVCS
On Thu, Jan 20, 2011 at 5:39 AM, Jeff Nowakowski j...@dilacero.org wrote: On 01/20/2011 12:24 AM, Gour wrote: Otoh, with Ubuntu, upgrade from 8.10 to 10.10 is always a major undertaking (I'm familiar with it since '99 when I used SuSE and had experience with deps hell.) Highlighting the problem of waiting too long to upgrade. You're skipping an entire release. I'd like to see you take a snapshot of Arch from 2008, use the system for 2 years without updating, and then upgrade to the latest packages. Do you think Arch is going to magically have no problems? Ironically, I did this a few years back with an Arch box that was setup, then banished to the TV room as a gaming system, then reconnected to the internet about two years later (I didn't have wifi at the time, and I still haven't put a wifi dongle on the box). It updated with no problems and is still operating happily. Now, I was expecting problems, but on the other hand, since *all* packages are in the rolling release model and individual packages contain specific version dependencies, problems are harder to find than you'd think.
Re: xxxInPlace or xxxCopy?
auto newStr = replace(str, hello, world); replaceInPlace(newStr, world, hello); it's quite clear that the first one returns a value and the the second one does it in place. Whereas if you have auto newStr = replaceCopy(str, hello, world); replace(newStr, world, hello); the first one is clear, but the second one is only clear because seeing the first one makes it obvious that the second one must be doing something different. I don't understand how the first two are clear and the last two are not so. Where both have the name replace for different things, and replace to me means replace in place. With this in hand, how is the first replace is quite clear? I am sure this is the case for many people. Problem is the naming here. If you have named it something like replaced and return a copy, it would be obvious and clear. Here, aren't you just dictating functional language rules to a multi-paradigm language, implicitly? In a fully functional language replace(something) might mean replace and give me a copy, but it is not what we have.
Re: What Makes A Programming Language Good
Pre-built libs aren't all that useful anyway, for several reasons: By pre-built I mean all the source is in one place, so the compile Just Works, not necessarily being pre-compiled. So if you downloaded mylib.zip, every file it needs is in there. No need to separately hunt down random.garbage.0.5.3.2.tar.xz as well. Bascially, the developer can compile it on his machine. He sends me the files he used to build it all in one place. That way, it is guaranteed to work - everything needed is right there.
Re: What Makes A Programming Language Good
Am 20.01.2011 14:48, schrieb Adam Ruppe: Pre-built libs aren't all that useful anyway, for several reasons: By pre-built I mean all the source is in one place, so the compile Just Works, not necessarily being pre-compiled. So if you downloaded mylib.zip, every file it needs is in there. No need to separately hunt down random.garbage.0.5.3.2.tar.xz as well. Bascially, the developer can compile it on his machine. He sends me the files he used to build it all in one place. That way, it is guaranteed to work - everything needed is right there. Ah, ok. I'd prefer a dependency-system though, so if mylib needs random.garbage.0.5.etc it should fetch it from the repository as well. So when there's a non-breaking security update to random.garbage, mylib automatically gets it upon rebuild. However, when there are breaking changes, random.garbage needs a new version (e.g. 0.6.etc instead of 0.5.etc).
Re: xxxInPlace or xxxCopy?
You have to think of the normal sort as a performance hack, something that is good because copying data wastes a lot of time, if the array is large or if you have to sort an many small arrays. Normally in Python you prefer sorted(), that returns a sorted copy, unless performance is important. I'd like something like sorted() in D too. I didn't know that, this solution is what i meant. So, they didn't blindly enforce functional language rules to a non-functional language.
Re: DVCS
On 01/20/2011 07:33 AM, Gour wrote: On Thu, 20 Jan 2011 06:39:08 -0500 Jeff Nowakowskij...@dilacero.org wrote: No, I haven't tried it. I'm not going to try every OS that comes down the pike. Then please, without any offense, do not give advises about something which you did not try. I did use Ubuntu... Please yourself. I quoted from the FAQ from the distribution's main site. If that's wrong, then Arch has a big public relations problem. I can make rational arguments without having used a system. That's a heavy investment of time, especially for somebody unfamiliar with Linux. Again, you're speaking without personal experience... From Jonathan M Davis in this thread: There is no question that Arch takes more to manage than a number of other distros. [..] Arch really doesn't take all that much to maintain, but it does have a higher setup cost than your average distro, and you do have to do some level of manual configuration that I'd expect a more typical distro like OpenSuSE or Ubuntu to take care of for you. Moreover, in TDPL's foreword, Walter speaks about himself as ..of an engineer.., so I'm sure he is capable to handle The Arch Way You're talking about somebody who is running a nearly 3 year old version of Ubuntu because he had one bad upgrade experience, and is probably running software full of security holes. If he can't spend a day a year to upgrade his OS, what makes you think he wants to spend time on a more demanding distro? There are no incompatibilities...if I upgrade kernel, it means that package manager will figure out what components has to be updated... And what happens when the kernel, as it often does, changes the way it handles things like devices, and expects the administrator to do some tweaking to handle the upgrade? What happens when you upgrade X and it no longer supports your video chipset? What happens when you upgrade something as basic as the DNS library, and it reacts badly with your router? Is Arch going to maintain your config files for you? Is it going to handle jumping 2 or 3 versions for software that can only upgrade from one version ago? These are real world examples. Arch is not some magic distribution that will make upgrade problems go away. Remember: there are no packages 'tagged' for any specific release! Yeah, I know. I also run Debian Testing, which is a rolling release. I'm not some Ubuntu noob.
Re: xxxInPlace or xxxCopy?
On 20/01/11 10:33, Andrei Alexandrescu wrote: I'm consolidating some routines from std.string into std.array. They are specialized for operating on arrays, and include the likes of insert, remove, replace. One question is whether operations should be performed in place or on a copy. For example: Though your question has already prompted a number of answers, are you sure that your question *saliently* poses the problem to be answered? In short, work on stating the problem as succinctly as you can, rather than asking for answers that shoot from the hip. Cheers, Justin Johansson
Re: xxxInPlace or xxxCopy?
In the meantime the world is going more functional... :-) I love how they solve this problem, but if you go on that path while ignoring the reality there wouldn't be much of a reason using D, no? :)
Re: What Makes A Programming Language Good
However, when there are breaking changes, random.garbage needs a new version (e.g. 0.6.etc instead of 0.5.etc). IMO the best way to do that would be to get everyone in the habit of including the version in their modules. module random.garbage.0.6; import random.garbage.0.6; That way, it is explicit, in the code itself, what you need and what the library provides. This also lets the two versions reside next to each other. Say I import cool.stuff.1.0. cool.stuff imports useless.crap.0.4. But I want useless.crap.1.0 in my main app. If they were both called just plain old useless.crap, the two imports will probably break something when we build the whole application. But if the version is part of the module name, we can both import what we need and use it at the same time. There would be no import useless.crap module provided that actually does work. At best, it'd say pragma(msg, useless.crap.1.0 is the most recent, please use it); If the thing without version annotation actually compiles, it'll break eventually anyway, so forcing something there ensures long term usefulness. The bug fix version wouldn't need to be in the module name, since they are (ideally) forward and backward compatible. Unit tests could probably confirm that automatically.
Re: Another task
On 01/20/2011 11:12 AM, bearophile wrote:
And I suggest to add a third associative array member function that
returns a range of key,value tuples, as in Python3. This allows to solve
the task like this:
auto r = map!q{ tuple(a[0]*10, a[1]~a[1]) }(aa.byPair());
Yes, this is the only nice looking, high-level, and D-style solution.
While I by far prefer avoiding stringcode:
auto r = map!((p) (tuple(p[0]*10, p[1]~p[1])) (aa.byPair());
where p means pair; should be correct, should'nt it?
I think for a newcomer the most difficult part is related to tuples:
* find them (in std.typecons!!!)
* catch after much time, pains, research, they should not even try to
construct a tuple using Tuple!, but using the convenience tuple() func
instead.
And also that map expects a range, which an AA is not according to my
trials (code rejected at link time until I used byKey). Or am I wrong?
PS: sh*t, I cannot have this work, what's wrong?
auto pairs = map!
((int i) {return tuple(10*i, aa[i]~aa[i]);})
(aa.byKey());
Denis
_
vita es estrany
spir.wikidot.com
Re: filter!(not!(predicate))(someInputRange) does not compile
On 01/20/2011 02:19 AM, Jens Mueller wrote: Thanks. Can you elaborate a bit please? I wonder why the alias won't work. Because in your original version the alias line does not define a func, but a kind of constant symbol. A higher order func like filter expects a func as first arg, not a constant. (my 2 c) denis _ vita es estrany spir.wikidot.com
Re: What Makes A Programming Language Good
On Thu, 20 Jan 2011 16:30:40 +0200, Adam Ruppe destructiona...@gmail.com wrote: IMO the best way to do that would be to get everyone in the habit of including the version in their modules. module random.garbage.0.6; import random.garbage.0.6; Even better, we could enforce this to only module writers. module random.garbage.0.6; import random.garbage; When you compile, you have to provide a path anyhow, less hostile to user and you don't have to change the code.
Re: DVCS
On Thu, 20 Jan 2011 09:19:54 -0500 Jeff Nowakowski j...@dilacero.org wrote: Please yourself. I quoted from the FAQ from the distribution's main site. If that's wrong, then Arch has a big public relations problem. Arch simply does not offer false promises that system will Just work. Still, I see the number of users has rapidly increased in last year or so...mostly Ubuntu 'refugees'. You're talking about somebody who is running a nearly 3 year old version of Ubuntu because he had one bad upgrade experience, and is probably running software full of security holes. If he can't spend a day a year to upgrade his OS, what makes you think he wants to spend time on a more demanding distro? My point is that due to rolling-release nature, distro like Archlinux require less work in the case when one 'forgets' to update OS and has to do 'major upgrade'. It was my experience with both SuSE and Ubuntu. And what happens when the kernel, as it often does, changes the way it handles things like devices, and expects the administrator to do some tweaking to handle the upgrade? What happens when you upgrade X and it no longer supports your video chipset? What happens when you upgrade something as basic as the DNS library, and it reacts badly with your router? In the above cases, there is no distro which can save you from some admin work...and the problem is that people expect such system where, often, the only admin work is re-install. :-) These are real world examples. Arch is not some magic distribution that will make upgrade problems go away. Sure. But upgrade in rolling-release distro is simpler than in Ubuntu-like one. Yeah, I know. I also run Debian Testing, which is a rolling release. I'm not some Ubuntu noob. Heh, I could imagine you like 'bleeding edge' considering you lived with ~x86 and 'unstable' repos. ;) Now we may close this thread...at least, I do not have anything more to say. :-D Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: What Makes A Programming Language Good
When you compile, you have to provide a path anyhow, less hostile to user and you don't have to change the code. One of the things implicit in the thread now is removing the need to provide a path - the compiler can (usually) figure it out on its own. Try dmd -v and search for import lines. But requiring it on the user side just makes sense if versioning is important. Your program won't compile with a different version - you aren't importing a generic thing, you're depending on something specific. It should be explicit. (Btw, this is the big failure of Linux dynamic libraries. They started with a decent idea of having version numbers in the filename. But then they ruined it by having generic symlinks that people can use. They start using libwhatever.so when they really wanted libwhatever.so.4.2. It's a symlink on their system, so Works for Me, but if they give that binary to someone with a different symlink, it won't work. Gah.)
Re: What Makes A Programming Language Good
On Thu, 20 Jan 2011 09:58:17 -0500, Adam Ruppe destructiona...@gmail.com wrote: When you compile, you have to provide a path anyhow, less hostile to user and you don't have to change the code. One of the things implicit in the thread now is removing the need to provide a path - the compiler can (usually) figure it out on its own. Try dmd -v and search for import lines. But requiring it on the user side just makes sense if versioning is important. Your program won't compile with a different version - you aren't importing a generic thing, you're depending on something specific. It should be explicit. (Btw, this is the big failure of Linux dynamic libraries. They started with a decent idea of having version numbers in the filename. But then they ruined it by having generic symlinks that people can use. They start using libwhatever.so when they really wanted libwhatever.so.4.2. It's a symlink on their system, so Works for Me, but if they give that binary to someone with a different symlink, it won't work. Gah.) Hm... I thought the symlink was meant to point to binary-compatible bug-fix releases. So for example, if you need libwhatever.so.4.2, you have a symlink called libwhatever.so.4 which points to the latest point revision that is binary compatible with all 4.x versions. I think you still simply link with -lwhatever, but the binary requires the .so.4 version. I have seen a lot of libs where the symlink version seems to have nothing to do with the linked-to version (e.g. /lib/libc.so.6 - libc-2.12.1.so), that doesn't really help matters. Given that almost all Linux releases are compiled from source, it's quite possible that one OS' libwhatever.so.4 is not compiled exactly the same as your libwhatever.so.4 (and might be binary incompatible). This is definitely an issue among linuxen. -Steve
Re: xxxInPlace or xxxCopy?
Jonathan M Davis Wrote: On Thursday 20 January 2011 03:51:48 Trass3r wrote: If such an annotation was introduced, it should be the other way around. But imo discarding a return value should always result in a warning, the function returns something for a reason. Actually, there are plenty of cases where you throw away the return value. A number of overloaded operators are prime examples - such as opAssign. std.algorithm.sort both sorts in place _and_ returns a sorted range (so that other algorithms can then know that the range is sorted). It's really quite easy to get legitimate cases where throwing away the return value makes perfect sense. Now, if you're dealing with a strongly pure function which throws away its return value, then yes, that's definitely bug, since the only effect of the function is its return value. Frequently however, that's not the case. Yes, you can have bugs because you didn't actually use the return value of a function, but it's that necessarily uncommon to have function calls which legitimately throw away their return value. - Jonathan M Davis You brought up an interesting idea: D already supports purity and as you said it doesn't make sense to discard return values of such functions. Therefore, it makes sense that for pure functions, this would result in a compile time error.
Re: xxxInPlace or xxxCopy?
On Thu, 20 Jan 2011 10:36:00 -0500, foobar f...@bar.com wrote: Jonathan M Davis Wrote: On Thursday 20 January 2011 03:51:48 Trass3r wrote: If such an annotation was introduced, it should be the other way around. But imo discarding a return value should always result in a warning, the function returns something for a reason. Actually, there are plenty of cases where you throw away the return value. A number of overloaded operators are prime examples - such as opAssign. std.algorithm.sort both sorts in place _and_ returns a sorted range (so that other algorithms can then know that the range is sorted). It's really quite easy to get legitimate cases where throwing away the return value makes perfect sense. Now, if you're dealing with a strongly pure function which throws away its return value, then yes, that's definitely bug, since the only effect of the function is its return value. Frequently however, that's not the case. Yes, you can have bugs because you didn't actually use the return value of a function, but it's that necessarily uncommon to have function calls which legitimately throw away their return value. - Jonathan M Davis You brought up an interesting idea: D already supports purity and as you said it doesn't make sense to discard return values of such functions. Therefore, it makes sense that for pure functions, this would result in a compile time error. Pure functions no longer have that requirement. You can pass mutable references to pure functions, which makes them weak-pure. -Steve
Re: xxxInPlace or xxxCopy?
Steven Schveighoffer wrote: On Thu, 20 Jan 2011 10:36:00 -0500, foobar f...@bar.com wrote: Jonathan M Davis Wrote: On Thursday 20 January 2011 03:51:48 Trass3r wrote: If such an annotation was introduced, it should be the other way around. But imo discarding a return value should always result in a warning, the function returns something for a reason. Actually, there are plenty of cases where you throw away the return value. A number of overloaded operators are prime examples - such as opAssign. std.algorithm.sort both sorts in place _and_ returns a sorted range (so that other algorithms can then know that the range is sorted). It's really quite easy to get legitimate cases where throwing away the return value makes perfect sense. Now, if you're dealing with a strongly pure function which throws away its return value, then yes, that's definitely bug, since the only effect of the function is its return value. Frequently however, that's not the case. Yes, you can have bugs because you didn't actually use the return value of a function, but it's that necessarily uncommon to have function calls which legitimately throw away their return value. - Jonathan M Davis You brought up an interesting idea: D already supports purity and as you said it doesn't make sense to discard return values of such functions. Therefore, it makes sense that for pure functions, this would result in a compile time error. Pure functions no longer have that requirement. You can pass mutable references to pure functions, which makes them weak-pure. -Steve If you don't use the return value of a strongly pure, nothrow function, you could be given a 'expression has no effect' error. Currently the function call is silently dropped.
Casting between delegates with qualified value type parameters
Delegates cannot be cast from one type to another, even if the only difference
in type is the qualifiers on value type parameters. However, the same code
works fine with functions instead of delegates, as such:
import std.stdio;
void foo(void function(int) bar)
{
bar(5);
}
void foobar(void delegate(int) bar)
{
bar(5);
}
void main()
{
foo (function(int i) { writeln(i); }); // OK
foo (function(immutable int i) { writeln(i); }); // OK
foobar(delegate(int i) { writeln(i); }); // OK
foobar(delegate(immutable int i) { writeln(i); }); // error
}
Is there a reason for this, or is it a bug?
Re: xxxInPlace or xxxCopy?
Don: If you don't use the return value of a strongly pure, nothrow function, you could be given a 'expression has no effect' error. Currently the function call is silently dropped. I have added this at the end of the enhancement request 5464 (but the error message is different). Bye, bearophile
Re: xxxInPlace or xxxCopy?
so: I didn't know that, this solution is what i meant. So, they didn't blindly enforce functional language rules to a non-functional language. Python was designed lot of time ago by Guido that I think didn't know much about functional programming. So they have first added an in-place sort() and later they have added a more functional sorted(). D2 is more functional than Python2, and I think the behaviour of sorted() is better to be the default one in D2 :-) Bye, bearophile
Re: xxxInPlace or xxxCopy?
so: I don't understand how the first two are clear and the last two are not so. Where both have the name replace for different things, and replace to me means replace in place. With this in hand, how is the first replace is quite clear? In Python I am used to immutable strings, so string methods like replace return a modified copy. D1 string functions are similar. I'd like D2 to be like Python here, but in practice an in-place replace procedure and a strongly-pure replace function that returns a modified copy are about equally clear :-) Yet, if you perform many in-place operations on strings you may get confused (it happened to me), such confusion is less common with functional-style string functions. Bye, bearophile
Re: Another task
spir:
Yes, this is the only nice looking, high-level, and D-style solution.
I have added:
http://d.puremagic.com/issues/show_bug.cgi?id=5466
While I by far prefer avoiding stringcode:
auto r = map!((p) (tuple(p[0]*10, p[1]~p[1])) (aa.byPair());
where p means pair; should be correct, should'nt it?
If you use a lambda template you need braces and the return statement:
auto r = map!((p){ return tuple(p[0]*10, p[1]~p[1]); })(aa.byPair());
I think for a newcomer the most difficult part is related to tuples:
* find them (in std.typecons!!!)
* catch after much time, pains, research, they should not even try to
construct a tuple using Tuple!, but using the convenience tuple() func
instead.
I agree that like dynamic arrays, tuples are better as built-ins, in D too.
Another very useful thing is tuple unpacking syntax:
http://d.puremagic.com/issues/show_bug.cgi?id=4579
And also that map expects a range, which an AA is not according to my
trials (code rejected at link time until I used byKey). Or am I wrong?
You aren't wrong.
PS: sh*t, I cannot have this work, what's wrong?
auto pairs = map!
((int i) {return tuple(10*i, aa[i]~aa[i]);})
(aa.byKey());
Look at the answers by Simen kjaeraas in this thread, he has explained the
situation.
Bye,
bearophile
Build tools (was: What Makes A Programming Language Good)
Russel Winder wrote: On Thu, 2011-01-20 at 12:32 +0100, Gour wrote: On Thu, 20 Jan 2011 10:13:00 + Russel Winder rus...@russel.org.uk wrote: SCons, Waf, and Gradle are currently the tools of choice. Gradle is (mostly) for Java-based projects, afaict? It is the case that there are two more or less distinct domains of build -- JVM-oriented, and everything else. There is though nothing stopping a single build system from trying to be more universal. Sadly every attempt to date has failed for one reason or another (not necessarily technical). Basically there seems to be a positive feedback loop in action keeping the two domains separate: basically the tools from one domain don't work well on the opposite domain and so no-one uses them there, so no evolution happens to improve things. In this particular case, Gradle has great support for everything JVM-related and no real support for C, C++, Fortran, etc. All attempts to raise the profile of the Ant C/C++ compilation tasks, which Gradle could use trivially, have come to nothing. Do you have an opinion for the .NET world? I'm currently just using MSBuild, but know just enough to get it working. It sucks.
Re: DVCS
Thu, 20 Jan 2011 13:33:58 +0100, Gour wrote: On Thu, 20 Jan 2011 06:39:08 -0500 Jeff Nowakowski j...@dilacero.org wrote: No, I haven't tried it. I'm not going to try every OS that comes down the pike. Then please, without any offense, do not give advises about something which you did not try. I did use Ubuntu... So instead of giving you a bunch of sane defaults, you have to make a bunch of choices up front. Right. That's why there is no need for separate distro based on DE user wants to have, iow, by simple: pacman -Sy xfce4 you get XFCE environment installed...same wit GNOME KDE. It's the same in Ubuntu. You can install the minimal server build and install the DE of your choice in similar way. The prebuilt images (Ubuntu, Kubuntu, Xubuntu, Lubuntu, ...) are for those who can't decide and don't want to fire up a terminal for writing down bash code. In Ubuntu you have even more choice. The huge metapackage or just the DE packages, with or without recommendations. A similar system just doesn't exist for Arch. For the lazy user Ubuntu is a dream come true - you never need to launch xterm if you don't want. There's a GUI for almost everything. That's a heavy investment of time, especially for somebody unfamiliar with Linux. Again, you're speaking without personal experience... You're apparently a Linux fan, but have you got any idea which BSD or Solaris distro to choose? The choice isn't as simple if you have zero experience with the system. Moreover, in TDPL's foreword, Walter speaks about himself as ..of an engineer.., so I'm sure he is capable to handle The Arch Way (see section Simplicity at https://wiki.archlinux.org/index.php/Arch_Linux) which says: The Arch Way is a philosophy aimed at keeping it simple. I think Walter's system isn't up to date because he is a lazy bitch. Has all the required competence but never bothers to update if it just works (tm). The same philosophy can be found in dmd/dmc. The code is sometimes hard to read and hard to maintain and buggy, but if it works, why fix it? The Arch Linux base system is quite simply the minimal, yet functional GNU/Linux environment; the Linux kernel, GNU toolchain, and a handful of optional, extra command line utilities like links and Vi. This clean and simple starting point provides the foundation for expanding the system into whatever the user requires. and from there install one of the major DEs (GNOME, KDE or XFCE) to name a few. I'd give my vote for LFS. It's quite minimal. The upgrade problems are still there. *Every package* you upgrade has a chance to be incompatible with the previous version. The longer you wait, the more incompatibilities there will be. There are no incompatibilities...if I upgrade kernel, it means that package manager will figure out what components has to be updated... Remember: there are no packages 'tagged' for any specific release! Even if the package manager works perfectly, the repositories have bugs in their dependencies and other metadata. Highlighting the problem of waiting too long to upgrade. You're skipping an entire release. I'd like to see you take a snapshot of Arch from 2008, use the system for 2 years without updating, and then upgrade to the latest packages. Do you think Arch is going to magically have no problems? I did upgrade on my father-in-law's machine which was more then 1yr old without any problem. You think there must be some magic to handle it...ask some FreeBSD user how they do it. ;) There's usually a safe upgrade period. If you wait too much, package conflicts will appear. It's simply too much work to keep rules for all possible package transitions. For example libc update breaks kde, but it's now called kde4. The system needs to know how to first remove all kde4 packages and update them. Chromium was previously a game, but now it's a browser, the game becomes chromium-bsu or something. I have hard time believing the minimal Arch does all this.
Struct constructors
In code like this:
import std.stdio;
struct foo
{
int val;
static immutable bar = foo(1);
this(int val)
{
this.val = 50;
}
}
void main()
{
writeln(foo.bar.val);
}
The user-defined struct constructor is not called, because it's overridden by
a built-in constructor which treats it like an initializer list. Shouldn't
constructors in structs either generate errors/warnings, or work as they would
appear to?
Re: filter!(not!(predicate))(someInputRange) does not compile
Andrei Alexandrescu wrote:
On 1/19/11 7:19 PM, Jens Mueller wrote:
Andrei Alexandrescu wrote:
Place the call to not!alwaysTrue in a local function inside main:
bool alwaysFalse(uint a) { return not!alwaysTrue(a); }
Thanks. Can you elaborate a bit please? I wonder why the alias won't
work.
I thought of it for a bit. It's a limitation of the compiler that's
worth a bug report. The explanation is a bit involved. Let me start
by remarking that if you prepend static to alwaysTrue, the alias
works as expected:
static bool alwaysTrue(uint a) { return true; }
alias not!(alwaysTrue) alwaysFalse;
Without static, alwaysTrue has access to a hidden pointer to the
stack frame of the function is in.
Yeah. That makes sense.
It has this hidden pointer to access variables from the function it is
defined in.
In theory a template should be unable to manipulate alwaysTrue
because of that frame pointer. But Walter has had this great idea of
instantiating templates in the context of the function they're in,
so they gain access to the frame pointer too. However, that
instantiation mechanism still has a few limitations. I think the
code above runs into one of them.
I see.
I can file a bug report if it is considered important and should not be
forgotten.
Jens
Re: Struct constructors
Am 20.01.2011 19:42, schrieb Sean Eskapp:
In code like this:
import std.stdio;
struct foo
{
int val;
static immutable bar = foo(1);
this(int val)
{
this.val = 50;
}
}
void main()
{
writeln(foo.bar.val);
}
The user-defined struct constructor is not called, because it's overridden by
a built-in constructor which treats it like an initializer list. Shouldn't
constructors in structs either generate errors/warnings, or work as they would
appear to?
See http://d.puremagic.com/issues/show_bug.cgi?id=3863.
Re: Another task
bearophile bearophileh...@lycos.com wrote: I think for a newcomer the most difficult part is related to tuples: * find them (in std.typecons!!!) * catch after much time, pains, research, they should not even try to construct a tuple using Tuple!, but using the convenience tuple() func instead. I agree that like dynamic arrays, tuples are better as built-ins, in D too. Another very useful thing is tuple unpacking syntax: http://d.puremagic.com/issues/show_bug.cgi?id=4579 And if not necessarily being built-ins, they are useful enough to warrant inclusion in object.d rather than std.typecons. -- Simen
Re: Struct constructors
Probably related to http://d.puremagic.com/issues/show_bug.cgi?id=5460
Re: What Makes A Programming Language Good
On 2011-01-20 10:19, Gour wrote: On Wed, 19 Jan 2011 19:40:49 +0100 Jacob Carlborgd...@me.com wrote: 1. it uses python, yet another dependency True, but it brings more features over e.g. cmake 'cause you have full language on disposal. I would go with a tool that uses a dynamic language as a DSL. I'm assuming you can embed the the dynamic language completely without the need for external dependencies. 2. it seems complicated Well, build systems are complex... ;) Sincerely, Gour Hm, right. I was actually kind of thinking about a build tool, not a package system/tool. But it seemed complex anyway, it should be able to be quite simple. -- /Jacob Carlborg
Re: What Makes A Programming Language Good
On 2011-01-20 13:12, Daniel Gibson wrote: Am 20.01.2011 00:54, schrieb Adam D. Ruppe: Jesse Phillips wrote: You can have the author release packaged libraries for developers to use and the author should do this. So this begs the question of what is the repository for? It's so you have a variety of libraries available at once with minimal hassle when you are originally writing something. I really don't care about those libraries' implementation details. I just want it so when I type import something.lib; in my program it actually works. If something.lib's author wants to use other.thing, great, I just don't want to think about it anymore than I think about his private classes or functions. Why is the tool going out to different URLs and downloading files when you are supposed to use the pre-built lib? Pre-built libs aren't all that useful anyway, for several reasons: 1. Templates 2. different operating systems: there would have to be pre-built libs for Windows, OSX, Linux and FreeBSD (if not even more) 3. different architectures: there would have to be pre-built libs for x86, AMD64 and, thanks to GDC and LDC, for about any platform supported by Linux.. And then one library for each of the compilers (ldc, gdc and dmd), do the math and one will soon realize that this won't work. Although pre-built libraries that only work for a given platform might work. Just provide source, so people can build their own libs from it or just compile the sources like their own source files. This can still be done automagically by the build-tool/package management. Cheers, - Daniel -- /Jacob Carlborg
Re: What Makes A Programming Language Good
On 2011-01-20 15:58, Adam Ruppe wrote: When you compile, you have to provide a path anyhow, less hostile to user and you don't have to change the code. One of the things implicit in the thread now is removing the need to provide a path - the compiler can (usually) figure it out on its own. Try dmd -v and search for import lines. But requiring it on the user side just makes sense if versioning is important. Your program won't compile with a different version - you aren't importing a generic thing, you're depending on something specific. It should be explicit. (Btw, this is the big failure of Linux dynamic libraries. They started with a decent idea of having version numbers in the filename. But then they ruined it by having generic symlinks that people can use. They start using libwhatever.so when they really wanted libwhatever.so.4.2. It's a symlink on their system, so Works for Me, but if they give that binary to someone with a different symlink, it won't work. Gah.) This is where the bundle tool (often used together with rails) shines. It's basically a dependency tool on top of rubygems which creates like a bubble for your application. * You specify, in a in a gemfile, all the package/libraries your application depends on, if you want to can also specify a specific version of a package. * Then when you want to deploy your application (deploy your rails site to the server) you lock the gemfile and it will create a new locked gemfile. The locked gemfile specifies the exact version of all the packages (even those you never specified a version for). * Later on the server you run bundle install and it will use the locked gemfile and it will install the exact same versions of the packages you had on your developer machine. -- /Jacob Carlborg
Re: Learning D
Hi guys, Ok - thanks for your answers. So, I will get TDPL book - all reviewers on amazon are raving about it. As for the Phobos class library (coz that is the D2 standard lib no?), how can I get to grips with that? Does the book cover that? Or does the book just cover the core language? Is there some online material for Phobos? Thanks.
Re: Learning D
Adrian Mercieca: As for the Phobos class library (coz that is the D2 standard lib no?), how can I get to grips with that? Does the book cover that? Or does the book just cover the core language? Is there some online material for Phobos? Phobos is a work in progress, TDPL doesn't cover it. You need to read the online docs and practice :-) Currently Phobos2 is not huge, so it doesn't take too much time to study it. Maybe Andrei is writing a book about Phobos2 too. Bye, bearophile
Re: filter!(not!(predicate))(someInputRange) does not compile
On 1/20/11 12:47 PM, Jens Mueller wrote:
Andrei Alexandrescu wrote:
On 1/19/11 7:19 PM, Jens Mueller wrote:
Andrei Alexandrescu wrote:
Place the call to not!alwaysTrue in a local function inside main:
bool alwaysFalse(uint a) { return not!alwaysTrue(a); }
Thanks. Can you elaborate a bit please? I wonder why the alias won't
work.
I thought of it for a bit. It's a limitation of the compiler that's
worth a bug report. The explanation is a bit involved. Let me start
by remarking that if you prepend static to alwaysTrue, the alias
works as expected:
static bool alwaysTrue(uint a) { return true; }
alias not!(alwaysTrue) alwaysFalse;
Without static, alwaysTrue has access to a hidden pointer to the
stack frame of the function is in.
Yeah. That makes sense.
It has this hidden pointer to access variables from the function it is
defined in.
In theory a template should be unable to manipulate alwaysTrue
because of that frame pointer. But Walter has had this great idea of
instantiating templates in the context of the function they're in,
so they gain access to the frame pointer too. However, that
instantiation mechanism still has a few limitations. I think the
code above runs into one of them.
I see.
I can file a bug report if it is considered important and should not be
forgotten.
Jens
Yes please. Make it an enhancement as it would remove a limitation of an
otherwise little explored feature. Thanks!
Andrei
Re: xxxInPlace or xxxCopy?
On Thursday, January 20, 2011 05:48:12 so wrote: auto newStr = replace(str, hello, world); replaceInPlace(newStr, world, hello); it's quite clear that the first one returns a value and the the second one does it in place. Whereas if you have auto newStr = replaceCopy(str, hello, world); replace(newStr, world, hello); the first one is clear, but the second one is only clear because seeing the first one makes it obvious that the second one must be doing something different. I don't understand how the first two are clear and the last two are not so. Where both have the name replace for different things, and replace to me means replace in place. With this in hand, how is the first replace is quite clear? I am sure this is the case for many people. Problem is the naming here. If you have named it something like replaced and return a copy, it would be obvious and clear. Here, aren't you just dictating functional language rules to a multi-paradigm language, implicitly? In a fully functional language replace(something) might mean replace and give me a copy, but it is not what we have. replace is clearer in the first case, because you're getting the return value. If you don't get the return value, then it's not immediately clear whether it's replacing world with hello in the return value or whether the function is void and world is being replaced in the original string (though they fact that we're dealing with strings here means that it _can't_ alter the original string - it's more of a question when dealing with arrays with mutable elements). Also, replaced would just be downright confusing to me, since it's not a verb. I'd expect it to be some sort of boolean test for whether something had been replaced, though that doesn't make a whole lot of sense in the context. I expect functions to be verbs unless checking state. Now, as I understdand it, python uses past participles such as replaced and sorted, but having never programmed in python, I'm not particularly familiar with that naming scheme and it wouild really throw me off at first. Regardless, I don't see anything wrong with naming functions in a manner that implies that a functional style is the default - particularly when we're talking about arrays, and they pretty much _have_ to be used in a functional style, because their elements are immutable. Andrei is essentially asking us whether the default behavior of an array function should typically be to return the changed value or to change it in place, with the longer name going to the function which has the other behavior. And since strings _have_ to be copied/sliced, and strings are generally going to be the most common type of array used, then it would make sense to make the default behavior be copying/slicing, making the functions which alter arrays in place have InPlace in their name. - Jonathan M Davis
Re: Learning D
On Thursday, January 20, 2011 11:33:38 Adrian Mercieca wrote: Hi guys, Ok - thanks for your answers. So, I will get TDPL book - all reviewers on amazon are raving about it. As for the Phobos class library (coz that is the D2 standard lib no?), how can I get to grips with that? Does the book cover that? Or does the book just cover the core language? Is there some online material for Phobos? TDPL mentions a little about Phobos but specifically avoids it on the whole, because Phobos is still very much a work in progress, and the intent of TDPL was to teach the language, not the library. The online docs for Phobos can be found here: http://www.digitalmars.com/d/2.0/phobos/phobos.html They're really the only way to learn Phobos at this point other than reading the source code, which is included in the zip file for the compiler. Overall, the documentation is fairly good though. The fact that the code can be documented in place (similar to javadoc or doxygen) makes it much easier to have good documentation. - Jonathan M Davis
Re: Struct constructors
That looks like a similar issue. Thanks!
Re: xxxInPlace or xxxCopy?
On 1/20/11, Jonathan M Davis jmdavisp...@gmx.com wrote: On Thursday 20 January 2011 03:51:48 Trass3r wrote: If such an annotation was introduced, it should be the other way around. But imo discarding a return value should always result in a warning, the function returns something for a reason. Actually, there are plenty of cases where you throw away the return value. Yeah. There are functions that can return a value that also have side-effects. An example might be a class method that modifies it's private fields and might return the number of fields that were affected. While you might not need the return value in most cases, you do want the side-effects to happen. That's why forcing an error on functions that return values which aren't used would not be a good idea, and where the annotation idea comes from.
Re: filter!(not!(predicate))(someInputRange) does not compile
Andrei Alexandrescu wrote:
On 1/20/11 12:47 PM, Jens Mueller wrote:
Andrei Alexandrescu wrote:
On 1/19/11 7:19 PM, Jens Mueller wrote:
Andrei Alexandrescu wrote:
Place the call to not!alwaysTrue in a local function inside main:
bool alwaysFalse(uint a) { return not!alwaysTrue(a); }
Thanks. Can you elaborate a bit please? I wonder why the alias won't
work.
I thought of it for a bit. It's a limitation of the compiler that's
worth a bug report. The explanation is a bit involved. Let me start
by remarking that if you prepend static to alwaysTrue, the alias
works as expected:
static bool alwaysTrue(uint a) { return true; }
alias not!(alwaysTrue) alwaysFalse;
Without static, alwaysTrue has access to a hidden pointer to the
stack frame of the function is in.
Yeah. That makes sense.
It has this hidden pointer to access variables from the function it is
defined in.
In theory a template should be unable to manipulate alwaysTrue
because of that frame pointer. But Walter has had this great idea of
instantiating templates in the context of the function they're in,
so they gain access to the frame pointer too. However, that
instantiation mechanism still has a few limitations. I think the
code above runs into one of them.
I see.
I can file a bug report if it is considered important and should not be
forgotten.
Jens
Yes please. Make it an enhancement as it would remove a limitation
of an otherwise little explored feature. Thanks!
http://d.puremagic.com/issues/show_bug.cgi?id=5469
Re: DVCS
Jeff Nowakowski Wrote: On 01/20/2011 07:33 AM, Gour wrote: On Thu, 20 Jan 2011 06:39:08 -0500 Jeff Nowakowskij...@dilacero.org wrote: No, I haven't tried it. I'm not going to try every OS that comes down the pike. Then please, without any offense, do not give advises about something which you did not try. I did use Ubuntu... Please yourself. I quoted from the FAQ from the distribution's main site. If that's wrong, then Arch has a big public relations problem. I can make rational arguments without having used a system. Listen you haven't used Arch so u don't know a shit. Stop bashing other distros and stick with your Noobuntu. You suck That's a heavy investment of time, especially for somebody unfamiliar with Linux. Again, you're speaking without personal experience... From Jonathan M Davis in this thread: There is no question that Arch takes more to manage than a number of other distros. [..] Arch really doesn't take all that much to maintain, but it does have a higher setup cost than your average distro, and you do have to do some level of manual configuration that I'd expect a more typical distro like OpenSuSE or Ubuntu to take care of for you. That was just bullshit. Gour said Arch is easier to administrate and it's true. Pacman creates new conf files in /etc. Use meld to fix them. Much easier than Nbuntu. Moreover, in TDPL's foreword, Walter speaks about himself as ..of an engineer.., so I'm sure he is capable to handle The Arch Way You're talking about somebody who is running a nearly 3 year old version of Ubuntu because he had one bad upgrade experience, and is probably running software full of security holes. If he can't spend a day a year to upgrade his OS, what makes you think he wants to spend time on a more demanding distro? Once he learns the Linux way or the Arch way, he starts to suffer from sleep deprivation because the administration is so fun. There are no incompatibilities...if I upgrade kernel, it means that package manager will figure out what components has to be updated... And what happens when the kernel, as it often does, changes the way it handles things like devices, and expects the administrator to do some tweaking to handle the upgrade? What happens when you upgrade X and it no longer supports your video chipset? What happens when you upgrade something as basic as the DNS library, and it reacts badly with your router? It just manages it. Try it. Is Arch going to maintain your config files for you? Is it going to handle jumping 2 or 3 versions for software that can only upgrade from one version ago? Yes. These are real world examples. Arch is not some magic distribution that will make upgrade problems go away. The point is, it's better than Nooobuntu or Gentoo. It doesn't need more merits. Remember: there are no packages 'tagged' for any specific release! Yeah, I know. I also run Debian Testing, which is a rolling release. I'm not some Ubuntu noob. It's GNU/Debian Linux, not just Debian, you insensitive clod! Debian only contains ancient packages like kde 3 in their stable. It's for old bearded communists.
Re: Redux on either [was: either]
On 17/01/11 6:18 PM, Ary Manzana wrote: Thanks. I searched it in wordrefence and define:redux and what is redux in Google with no luck. The definition is the first answer on Google for both those searches :-)
Re: xxxInPlace or xxxCopy?
On 01/20/2011 11:31 AM, bearophile wrote:
Andrej Mitrovic:
I think what might help out in D is if we had a way to mark some
functions so the compiler guarantees that their return values *are
not* to be discarded. For example, this code will compile:
import std.stdio;
import std.string;
void main()
{
string s = Mary has a lil lamb.;
replace(s, lil, li'l); // returns a copy, but discards it
}
If the replace function is marked with some kind of @nodiscard
annotation, then his would be a compile error since it doesn't make
sense to construct a new string, return it, and discard it.
But maybe that's going overboard. How often do these kinds of bugs
creep in?
Such bugs are common enough. GNU C has the warn_unused_result
attribute (that is like your @nodiscard if you use -Werror to turn
warnings into errors):
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html
Some C lints require a void cast where you don't want to use a
function result:
cast(void)replace(s, lil, li'l);
In a language the default is different and where you don't want to
use a function result you have to add an annotation:
unused replace(s, lil, li'l);
Something like @nodiscard is more useful in C than D because in C
there are no true built-in exceptions, so error return values are
common, and ignoring them is a mistake. In some cases like replace() or
the C realloc() ignoring a result is always a programmer error. So
something like @nodiscard is useful in D too.
But I thought D had such a feature already. Probably I'm confusing, but
I think I've had compiler warning in such cases, procisely (ingoring a
func result).
denis
_
vita es estrany
spir.wikidot.com
Re: xxxInPlace or xxxCopy?
On 01/20/2011 12:33 AM, Andrei Alexandrescu wrote: I'm consolidating some routines from std.string into std.array. They are specialized for operating on arrays, and include the likes of insert, remove, replace. One question is whether operations should be performed in place or on a copy. For example: string s = Mary has a lil lamb.; // Implicit copy auto s1 = replace(s, lil, li'l); assert(s == Mary has a lil lamb.); // Explicit in-place replaceInPlace(s, lil, li'l); assert(s == Mary has a li'l lamb.); So that would make copying the default behavior. Alternatively, we could make in-place the default behavior and ask for the Copy suffix: string s = Mary has a lil lamb.; // Explicit copy auto s1 = replaceCopy(s, lil, li'l); assert(s == Mary has a lil lamb.); // Implicit in-place replace(s, lil, li'l); assert(s == Mary has a li'l lamb.); Thoughts? I have thought at these issues (there are several playing together) in other languages. The first problem is indeed that both operations may often be useful. If you define it to operate in-place, then when the user instead wants a new element, they need copy first: col2 = col1; col2.sort(); If instead you define it to create a new element, then conversely when the user wants it to operate in-place, they need to reassign: col1 = col.sorted; The second point is how to hint the user to the actual semantics, and avoid possibly naughty bugs. It's mainly a question of naming. I have decided to follow once and for all the below guideline: * In-place modification is an action, thus it's name is an action verb, like sort (indeed, english is very often ambiguous; in such cases, verbal sense take precedence, else add some more word). * Creating a new is a function in the pure, math, sense of the word (not the C sense); name after what it creates. Usually, a simple adjective does the job, else add a noun: sorted, sortedTable, sortedList. * Never mix both action function in the same routine (except for signaling error in language without any exception system). It is often worth having both operations; difference of naming makes this easy to manage. When having both is overkill, I decided to return a new element for methods operating globally, and modify in-place for methods operating at the level of element(s). The reason is the first ones are usually costly, so it's worth using the safer functional scheme (and copying sometimes allows faster algo). While creating a whole new collection after any minimal change on element(s) is obviously not very efficient. These questions, as taken implicitely in this thread, mostly concern collections. Now, the case of string chosen as initial example is as always very particular. I'm not fan for this reason of the politics of using the same methods as for (other) arrays, except in cases where it's obvious. D strings are even more particular by having immutable elements. Well... My 2 cents. Denis _ vita es estrany spir.wikidot.com
Re: xxxInPlace or xxxCopy?
Is it ok to use: In place: trim( string ) replace( string, from, to ) or Copy: trim( string, outstring ) replace( string, from, to, outstring )
Re: xxxInPlace or xxxCopy?
Andrei Alexandrescu Wrote: I'm consolidating some routines from std.string into std.array. They are specialized for operating on arrays, and include the likes of insert, remove, replace. One question is whether operations should be performed in place or on a copy. For example: string s = Mary has a lil lamb.; // Implicit copy auto s1 = replace(s, lil, li'l); assert(s == Mary has a lil lamb.); // Explicit in-place replaceInPlace(s, lil, li'l); assert(s == Mary has a li'l lamb.); So that would make copying the default behavior. Alternatively, we could make in-place the default behavior and ask for the Copy suffix: string s = Mary has a lil lamb.; // Explicit copy auto s1 = replaceCopy(s, lil, li'l); assert(s == Mary has a lil lamb.); // Implicit in-place replace(s, lil, li'l); assert(s == Mary has a li'l lamb.); Thoughts? Andrei Like bearophile and others, I too would prefer the default behavior to be the functional option and return a copy by default. As already mentioned this agrees with the immutable d string types. Regarding the naming scheme we have several options: 1. overload based on immutability. The type system will do the right thing for you but this may be confusing to read, especially if one uses auto frequently. 2. Use past tense a-la python (sort vs. sorted). This reads more naturally for native English speakers but has the same issues as English itself (all those language exceptions such as split). 3. use artificial scheme such as Ruby's bang (sort vs. sort!). This is my preferred option. Benefits are consistency and is easier for for non native English speakers. Unfortunately, D doesn't allow '!' in function names. __InPlace is clear but also verbose. Perhaps we could use some other, more terse, notion? something like: sort vs. sort@ OR sort vs. sort# ? My two cents...
Stack-allocared linear closures in ATS
The ATS language contains a metric ton of nice ideas. ATS programs are sometimes faster than C ones (because its type system allows to avoid some runtime tests done in C programs, allows some higher order optimizations, etc) despite the programmer has ways to write them in much safer way than C ones. ATS faces this mix of so strong design requirements with a very complex type system that's hard to use. So it's not a normal language, you need to think of it as something else, more like a theorem proving language like Agda that also produces very efficient binaries. This is a little example of a safer usage of a C library from ATS: http://www.bluishcoder.co.nz/2010/06/02/safer-c-code-using-ats.html Recently I have found that ATS has two main kinds of closures, normal heap-allocated ones managed by the GC (as D2 ones), and linear closures that require manual freeing of their memory. Linear closure may also allocated on the stack, avoiding the need of the free, and making them quite efficient: http://www.bluishcoder.co.nz/2010/06/20/closures-in-ats.html http://www.bluishcoder.co.nz/2010/08/02/lin-and-llam-with-closures.html Being D2 a language that looks for performance too, the idea of stack closures may be of interest. Bye, bearophile
Ad hoc ranges
Doing my own deeds, I often found myself in need of writing up a range just to
e.g. feed it into an algorithm. Problem is, defining even the simplest range --
one-pass forward -- is verbose enough to render this (correct) approach
unprofitable.
This is how I went about the problem:
auto range(T, Whatever)(lazy bool _empty, lazy Whatever _popFront, lazy T
_front) {
struct AdHocRange {
@property bool empty() { return _empty(); }
void popFront() { _popFront(); }
@property T front() { return _front(); }
}
return AdHocRange();
}
--- example ---
try { ... }
catch(Throwable t)
{
auto r = range(t is null, t = t.next, t);
// process exception chain...
}
I don't know a terser way to get a full-fledged range. It comes at a cost,
though. Lazy parameters are just sugar over delegates, so it's not exactly
Usain Bolt**... And you can't return it because by bug or by design lazy
parameters (unlike vanilla delegates) don't work like closures. Still, even
with the overhead and limitations the idiom is remarkably useful, especially in
face of range-unfriendly libraries from outside D realm.
Enjoy.
--
Tomek
** Of course, there exists a somewhat more verbose compile-time variant of the
idiom I presented.
Re: Ad hoc ranges
Tomek Sowiñski:
auto range(T, Whatever)(lazy bool _empty, lazy Whatever _popFront, lazy T
_front) {
I am not sure, but I think Andrei has deprecated the lazy attribute.
Bye,
bearophile
Re: Ad hoc ranges
bearophile napisał: I am not sure, but I think Andrei has deprecated the lazy attribute. Yes, but AFAIR in favor of implicit conversions of expressions to parameterless delegates, which strengthens my little idiom. -- Tomek
Constructors (starstruck noob from C++)
Hi to all from a total noob. first of all, I'd like to say how impressed I am with D. In fact, I keep pinching myself. Have I *really* found a language worth leaving C++ for after two decades? It's beginning to look that way. Obviously I'm devouring the 2.0 documentation right now, but have not yet found out how to create a new instance of an existing class object. What I mean is, given... auto a = new A; how do I, in c++ speak, do the D for... A b(a); // or if you prefer... A* b = new A(a); I'm sure this must be trivial. Many many thanks, Luke
Re: Constructors (starstruck noob from C++)
Welcome! On 01/20/2011 07:18 PM, Luke J. West wrote: how do I, in c++ speak, do the D for... A b(a); // or if you prefer... A* b = new A(a); try A b = new A(a); I'm sure this must be trivial. Many many thanks, Luke
Re: Potential patent issues
BlazingWhitester wrote: I spotted some patents that can theaten current DMD implementation. Wanted to clarify things. http://www.freepatentsonline.com/6185728.pdf - this patent describes method pointers implementation (delegates) This was obviously a patent aimed at protecting Delphi from VB. It's all about the RAD designer: visual connections between GUI elements and events has a 1:1 correspondence with code; delegates are used to achieve this. D delegates can store a data pointer to a nested function, or to an object. This is rather more general (not an object-oriented feature), and doesn't provide a 1:1 correspondence to visuals. I presume they were only able to satisfy the requirements for novelty and non-obviousness, because of the RAD usage. In fact, there doesn't seem to be any suggestion that delegates would be used for anything else. The more general idea of storing a data pointer and a function pointer together is simple and obvious, and surely has prior art.
Re: Ad hoc ranges
On Thursday, January 20, 2011 16:19:54 bearophile wrote:
Tomek Sowiñski:
auto range(T, Whatever)(lazy bool _empty, lazy Whatever _popFront, lazy T
_front) {
I am not sure, but I think Andrei has deprecated the lazy attribute.
In general or on a specific function? I'm pretty sure that lazy isn't going
anywhere as far as the language goes. It's used on enforce, and Andrei hasn't
wanted to make enforce take a non-lazy attribute. Also, for cases like the unit
testing functions that I've been working on to get into Phobos, the loss of
lazy
would be pretty devastating. You could still do the, but it would be much
uglier.
- Jonathan M Davis
Re: Ad hoc ranges
On Thursday, January 20, 2011 16:12:58 Tomek Sowiński wrote:
Doing my own deeds, I often found myself in need of writing up a range just
to e.g. feed it into an algorithm. Problem is, defining even the simplest
range -- one-pass forward -- is verbose enough to render this (correct)
approach unprofitable.
This is how I went about the problem:
auto range(T, Whatever)(lazy bool _empty, lazy Whatever _popFront, lazy T
_front) { struct AdHocRange {
@property bool empty() { return _empty(); }
void popFront() { _popFront(); }
@property T front() { return _front(); }
}
return AdHocRange();
}
--- example ---
try { ... }
catch(Throwable t)
{
auto r = range(t is null, t = t.next, t);
// process exception chain...
}
I don't know a terser way to get a full-fledged range. It comes at a cost,
though. Lazy parameters are just sugar over delegates, so it's not exactly
Usain Bolt**... And you can't return it because by bug or by design lazy
parameters (unlike vanilla delegates) don't work like closures. Still,
even with the overhead and limitations the idiom is remarkably useful,
especially in face of range-unfriendly libraries from outside D realm.
Enjoy.
What types of stuff do you need ad-hoc ranges for? What's the use case? I've
never actually needed such a thing. I'm curious. If it's really something
that's
likely to be generally useful, then a function similar to what you're
suggesting
probably should be added to std.range.
- Jonathan M Davis
Re: Constructors (starstruck noob from C++)
On Thursday, January 20, 2011 17:18:48 Luke J. West wrote:
Hi to all from a total noob.
first of all, I'd like to say how impressed I am with D. In fact, I keep
pinching myself. Have I *really* found a language worth leaving C++ for
after two decades? It's beginning to look that way. Obviously I'm
devouring the 2.0 documentation right now, but have not yet found out
how to create a new instance of an existing class object. What I mean
is, given...
auto a = new A;
how do I, in c++ speak, do the D for...
A b(a); // or if you prefer...
A* b = new A(a);
I'm sure this must be trivial.
Many many thanks,
Well, you could create a constructor which is effectively a copy constructor.
There has been talk of a general cloning mechanism which would give you a
correct clone method essentially for free, but it hasn't been done yet (not
sure
why; I don't recall exactly where the last discussion on that went other than
it
was generally accepted that we wanted something like that). However, at the
moment, I'm not aware of any general way to copy a class instance like you're
trying to do.
Structs have postblit constructors:
this(this)
{
//...
}
where a shallow copy of the struct is made prior to entering this(this), and
then you do whatever you need to do inside it to make it a deep copy (or just
don't have a postblit constructor if you don't need a deep copy). However,
classes are reference types and don't have anything like that.
So, we need to add a means to generate clone methods for classes so that
copying
classes will be easy, but we haven't done it yet. I'm not sure what the current
obstacles to doing it are.
- Jonathan M Davis
Why is the in storage class missing from the ParameterStorageClass enum?
import std.stdio;
import std.traits;
alias ParameterStorageClassTuple STCTuple;
alias ParameterStorageClass STC;
void foo(in int[] x) { /*x[0] = 5; // This would be a compile-time error*/ }
void bar(int[] x) { x[0] = 5; }
void main()
{
assert(STCTuple!foo[0] == STC.NONE);
assert(STCTuple!bar[0] == STC.NONE);
}
Someone said that in was the default storage class when there is no storage
class specified for a parameter. But if that is true then how come bar can
modify the contents of the x parameter? If parameters really have in as the
default storage class, bar's function body would be a compile time error, just
like foo's is if you uncomment its code. (Yes, I know a fat pointer is passed
in with both functions. But in is supposed to give some guarantees as to what
you can do with a parameter.)
So, which part of this am I misunderstanding here?
Re: Constructors (starstruck noob from C++)
On 1/20/11 7:18 PM, Luke J. West wrote:
Hi to all from a total noob.
first of all, I'd like to say how impressed I am with D. In fact, I keep
pinching myself. Have I *really* found a language worth leaving C++ for
after two decades? It's beginning to look that way. Obviously I'm
devouring the 2.0 documentation right now, but have not yet found out
how to create a new instance of an existing class object. What I mean
is, given...
auto a = new A;
how do I, in c++ speak, do the D for...
A b(a); // or if you prefer...
A* b = new A(a);
I'm sure this must be trivial.
Many many thanks,
Luke
Hopefully this won't mark a demise of your newfound interest :o). If A
were a struct, auto b = new A(*a) would do. For classes, D does not
provide automatic copy constructors; you need to define and follow a
sort of cloning protocol.
That being said, it's not difficult to define a generic function that
copies fields over from one class object to another. Here's a start:
import std.stdio;
void copyMembers(A)(A src, A tgt) if (is(A == class)) {
foreach (e; __traits(allMembers, A)) {
static if (!is(typeof(__traits(getMember, src, e)) == function)
e != Monitor)
{
__traits(getMember, tgt, e) = __traits(getMember, src, e);
}
}
}
class A {
int x = 42;
string y = hello;
final void fun1() {}
void fun2() {}
static void fun3(){}
}
void main() {
auto a = new A;
a.x = 43;
auto b = new A;
copyMembers(a, b);
assert(b.x == 43);
}
I think copyMembers belongs to the standard library. I wanted to define
a family of functions like it but never got around to it.
Andrei
Re: Constructors (starstruck noob from C++)
Be afraid.. be very afraid!
import std.algorithm;
import std.stdio;
import std.conv;
enum fields = [__traits(allMembers, Foo)];
string populateFields(string[] haystack)
{
string result;
while (haystack.length 0)
{
switch (haystack[0])
{
case __ctor:
case __dtor:
haystack = haystack[1 .. $]; // skip ctors, dtors,
can't assign those..
continue;
default:
}
result ~= this.
~ haystack[0]
~ = foo.
~ haystack[0]
~ ;;
haystack = haystack[1 .. $];
}
return result;
}
class Foo
{
int x;
int y;
this(Foo foo)
{
mixin(populateFields(fields));
}
this()
{
}
~this()
{
}
}
void main()
{
auto foo = new Foo();
foo.x = 1;
foo.y = 2;
auto bar = new Foo(foo);
assert(foo !is bar);
assert(bar.x == 1);
assert(bar.y == 2);
}
There's a ton of nonsensical compile errors if I try to use
[__traits(allMembers, Foo)] inside the mixin call itself btw.
Okay, this really is just a silly example, but I like having fun with
string mixins. :-)
Re: Constructors (starstruck noob from C++)
Ah, damnit, Andrei beat me to the punch! Well, at least his methods make much more sense than my little hacks.
Re: Constructors (starstruck noob from C++)
On 1/21/11, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: I think copyMembers belongs to the standard library. I wanted to define a family of functions like it but never got around to it. It's a shame we can't use .dup. It would look really nice in code.
Re: Why is the in storage class missing from the ParameterStorageClass enum?
On Thursday, January 20, 2011 19:03:09 Andrej Mitrovic wrote:
import std.stdio;
import std.traits;
alias ParameterStorageClassTuple STCTuple;
alias ParameterStorageClass STC;
void foo(in int[] x) { /*x[0] = 5; // This would be a compile-time error*/
} void bar(int[] x) { x[0] = 5; }
void main()
{
assert(STCTuple!foo[0] == STC.NONE);
assert(STCTuple!bar[0] == STC.NONE);
}
Someone said that in was the default storage class when there is no
storage class specified for a parameter. But if that is true then how come
bar can modify the contents of the x parameter? If parameters really have
in as the default storage class, bar's function body would be a compile
time error, just like foo's is if you uncomment its code. (Yes, I know a
fat pointer is passed in with both functions. But in is supposed to give
some guarantees as to what you can do with a parameter.)
So, which part of this am I misunderstanding here?
Umm. in is never the default. in is essentially an alias for const scope. The
default is non-shared and mutable.
- Jonathan M Davis
Re: Why is the in storage class missing from the ParameterStorageClass enum?
On 1/21/11, Jonathan M Davis jmdavisp...@gmx.com wrote: Umm. in is never the default. in is essentially an alias for const scope. The default is non-shared and mutable. - Jonathan M Davis That's what I thought. But I did saw it mentioned in this NG a couple of times, I can't remember by who though. In any case, in seems to be missing from that enum definition. So unless there's a specific reason for its absence, I'd file an enhancement request.
Re: Constructors (starstruck noob from C++)
On Thu, 20 Jan 2011 22:02:42 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 1/20/11 7:18 PM, Luke J. West wrote:
Hi to all from a total noob.
first of all, I'd like to say how impressed I am with D. In fact, I keep
pinching myself. Have I *really* found a language worth leaving C++ for
after two decades? It's beginning to look that way. Obviously I'm
devouring the 2.0 documentation right now, but have not yet found out
how to create a new instance of an existing class object. What I mean
is, given...
auto a = new A;
how do I, in c++ speak, do the D for...
A b(a); // or if you prefer...
A* b = new A(a);
I'm sure this must be trivial.
Many many thanks,
Luke
Hopefully this won't mark a demise of your newfound interest :o). If A
were a struct, auto b = new A(*a) would do. For classes, D does not
provide automatic copy constructors; you need to define and follow a
sort of cloning protocol.
That being said, it's not difficult to define a generic function that
copies fields over from one class object to another. Here's a start:
import std.stdio;
void copyMembers(A)(A src, A tgt) if (is(A == class)) {
foreach (e; __traits(allMembers, A)) {
static if (!is(typeof(__traits(getMember, src, e)) == function)
e != Monitor)
{
__traits(getMember, tgt, e) = __traits(getMember, src, e);
}
}
}
class A {
int x = 42;
string y = hello;
final void fun1() {}
void fun2() {}
static void fun3(){}
}
void main() {
auto a = new A;
a.x = 43;
auto b = new A;
copyMembers(a, b);
assert(b.x == 43);
}
I think copyMembers belongs to the standard library. I wanted to define
a family of functions like it but never got around to it.
Andrei
First, why not use tupleof? b.tupleof = a.tupleof; works perfectly fine,
simpler and ahem, actually works. __traits(getMember, ...) has to obey
scoping rules, so using it with a class that defines private variables
results in a message like class hello.A member x is not accessible.
Furthermore, you need to filter allMembers by a lot more than just
function and Monitor as it also includes enum constants, etc. Having
tried using it for serialization, I know it's non-trivial to use
correctly, if you only want the actual data fields.
i.e.
void copyMembers(A)(A src, A tgt) if (is(A == class)) { tgt.tupleof =
src.tupleof; }
Re: Why is the in storage class missing from the ParameterStorageClass enum?
Andrej Mitrovic wrote: On 1/21/11, Jonathan M Davis jmdavisp...@gmx.com wrote: Umm. in is never the default. in is essentially an alias for const scope. The default is non-shared and mutable. - Jonathan M Davis That's what I thought. But I did saw it mentioned in this NG a couple of times, I can't remember by who though. In any case, in seems to be missing from that enum definition. So unless there's a specific reason for its absence, I'd file an enhancement request. It's not needed because it should resolve to SCOPE for ParameterStorageClass and const is not a storage class, but a type constructor.
Re: Assigning Interface to Object
Object is only the base class for all D classes. Interfaces may also represent COM objects or C++ classes, which are not subclasses of Object. Can't the compiler check if it is a normal D interface and then allow (implicit) casts to Object?
Re: Assigning Interface to Object
On Thu, 20 Jan 2011 02:01:26 -0500, Mandeep Singh Brar mand...@brars.co.in wrote: This would be easily resolved if interfaces were known to be Objects. But shouldnt this be the case, because there would be nothing called as an Interface which can be pointed to; it would be an Object which is implementing an interface which is being pointed to. So shouldnt Interfaces be Objects too. Otherwise, wouldnt it defeat the purpose of having Object as the base class for everything. The issue is COM interfaces. What bugs me about it is, whether an interface derives from IUnknown is known at compile time. I don't think it's possible to define an interface that *doesn't* derive from IUnknown that is not a D Object. I believe the compiler even handles IUnknown interfaces differently. I think the problem is that COM support was added when compile-time functionality was in its infancy. There are quite a few legacy problems due to that. For instance, the builtin array sort routine does not use compile-time information. It would be nice to fix this problem, but I'm not sure how willing Walter is to do it. For sure, we need a solution to the opEquals problem. -Steve
Re: Detecting at compile time if a string is zero terminated
Jesse Phillips wrote: First off no. Second, is their really going to be a performance gain from this. I wouldn't expect static strings to be converted very often. And last I will copy and past a comment from the source code: Thanks for your reply. In case you don't know: gettext is used to translate strings. You call gettext(english string) and it returns the translated string. Gettext might be the only corner case, but the strings gettext returns are usually not cached and big projects could translate many strings, so I thought it could be an issue. But maybe I'm overestimating that. I had a look at the source code of toStringz and found the comment you mentioned. The comment is for toStringz(const(char)[] s) toStringz(string s) is even more interesting in this case as it does do that optimization in most cases. I think that's good enough ;-) -- Johannes Pfau signature.asc Description: PGP signature
Source code annotations alla Java
Not long ago the Java Language people introduced the idea of annotations together with an annotation processing tool (apt). Now perhaps the idea of source code annotations is not actually a Java invention per se, however for someone learning D is there any equivalent idiom [of Java annotations] in the D language?
Re: Source code annotations alla Java
On 21/01/11 00:47, Justin Johansson wrote: Not long ago the Java Language people introduced the idea of annotations together with an annotation processing tool (apt). Now perhaps the idea of source code annotations is not actually a Java invention per se, however for someone learning D is there any equivalent idiom [of Java annotations] in the D language? Fair to add that while finding the Java Language annotation concept interesting I am not entirely sure as to its usefulness. Thanks for answers, Justin Johansson
