Re: Optional braces
There is one case where it might make sense. I've brought up a
variation of this before, but basically;
Object getMeSome() try {
// Really try
} catch (SpecificFailure e) {
return null;
}
vs.
Object getMeSome() {
try {
// Really try
} catch (SpecificFailure e) {
return null;
}
}
Of course, every optional feature needs good judgement for appropriate
usage, for example the ternary statement vs. if/else.
2011/8/19 Trass3r u...@known.com:
Am 19.08.2011, 14:16 Uhr, schrieb Timon Gehr timon.g...@gmx.ch:
I think this makes code harder to read for no obvious benefit.
I don't think this is any better than
class Foo{
private int a_;
int a(){return a_;}
int a(int a){return a_ = a;}
}
+1
Optional braces should be limited to statements.
Re: Prototype buildsystem Drake
2011/7/19 Jacob Carlborg d...@me.com: On 2011-07-19 16:46, Russel Winder wrote: There is clearly a string coupling between configuration and package management. Autoconf, Waf and SCons have to be portable across package management since they are not dedicated to one scheme -- springing up as they did from before package management as standard. Ok. There are some potentially tricky issues here. Ruby gets round it by having a language specific package and build system which therefore causes Debian, Fedora, FreeBSD, Macports, Fink, etc. packagers massive headaches. Haskell/Cabal, Python/Eggs, etc. The conflict between language packaging and platform packaging is central. Having a D language packaging system that was in some way harmonious with Apt/Deb, Yum/RPM, Ports, etc. would make a lot of people very happy. Indirectly it would make traction a whole lot easier. As evidence I present Java, Ruby, Python, Haskell, etc. The whole point of having a D package manager is so I don't have to create packages for all these system specific package managers. In my experience with gem and easy_install, it's not really practical for the end-user. After several attempts, I always ran into problems. Especially library-bindings in the language-specific package-manager tends to conflict with what library is installed in the system, causing problems. In all the cases I ended up biting the bullet and create a OS-package for the Python/Ruby packages we're using in production. I've later learned the experience is shared with others, I know one company who even went back to .NET due to too much hassle with Ruby On Rails deployments (gem), and I suppose distribution-developers wouldn't put as much effort into packaging all the Python and Ruby-packages they do if not others had seen problems with per-language packagers. Especially, if D is to gain traction and attract developers, getting proof-of-concept applications out in the respective app store of the target OS:es is quite important, which requires working with the native packaging format.
Re: Prototype buildsystem Drake
So what are you suggesting, that we don't have a package manager for D? I'm suggesting, I'm not likely to use it, and developing a D-specific package manager should not accidentally exclude stand-alone building of packages. As I said before, the build-system and packaging system must be independent, but well integrated. Quoting again from Russel Winder: Having a D language packaging system that was in some way harmonious with Apt/Deb, Yum/RPM, Ports, etc. would make a lot of people very happy. Indirectly it would make traction a whole lot easier.
Re: Prototype buildsystem Drake
2011/7/20 David Nadlinger s...@klickverbot.at: Do you happen to known what issues they experienced in more detail? I'm curious because I personally found Rails deployment to be quite convenient, extending the Gemfile during development as needed, and then using Bundler (http://gembundler.com/) to ensure that the exact same versions of the dependencies are used when staging and deploying… I do not know exactly what their problems was. For me, it was mainly conflicts between OS package manager and language-specific. I recall curl-bindings, and MySQL binding causing a lot of problems, also I recall some graphics library depending on GTK breaking spectacularly. Perhaps it's more polished now, or perhaps I just had bad luck.
Re: Prototype buildsystem Drake
2011/7/20 Jacob Carlborg d...@me.com: What do you need curl for? Saturating gigabit file transfers with wide support of varying protocols, encryption and authentication schemes. In any case, there's always going to be needs for bindings, either because a package in other language (usually C/C++) offers more functionality, or (not likely a problem for D) higher performance.
Re: Prototype buildsystem Drake
2011/7/19 Jacob Carlborg d...@me.com: Apperently some projects need to have their buildsystem check for the existance of, locations of, and details about certain things on the local system before building. So...that stuff. Isn't that to check what libraries, and so on, are present? That is the whole point of a package manager. A package specifies what dependencies it has, then the package manager makes sure the dependencies are met, or else it can't be installed. All dependencies aren't always mandatory. It's not uncommon for some software to adapt itself to the environment, say enabling certain features IF certain other packages can be found, otherwise just disable the functionality. Also it might adapt itself on other conditions, say auto-detecting checking what OS-kernel we are building for, and pass along D versions-keywords accordingly, including allowing the user to override, to do cross-platform or cross-version builds. Also, most build-systems offers options for whomever is building, such as --use-test-codeX, much like Tango now allows you to build with the regular, or the less tested concurrent GC. Don't know what locations it would check for. The package as no saying in where it should be installed, the package manger decides that. Same here. You may have multiple builds of the same package, and want to cross test a dependent package against two different installs to do regression-testing. (Or the classic i386/x86_64 debacle) Oh, now I mixing package manager and build tool and assume the build tool will be used with the package manager. I think the build-tool and package manager must be independent, but well integrated. Otherwise, you risk making it difficult for D-software to come by default in Linux-distros, and you make it difficult for the D-package-manager to carry a package with a different build-system (even a D based package with different build-system).
Re: Prototype buildsystem Drake
2011/7/13 Nick Sabalausky a@a.a: Jacob Carlborg d...@me.com wrote in message news:ivke5k$2m78$1...@digitalmars.com... First I have to say that I know you are doing this because you want to use D as the language for the build scripts. The reason I did choose Ruby because I think D will be too verbose and when I'm looking at drakefile.d I do think it's too verbose. Yea, D is likely to be a little more verbose than what could be done in Ruby (or Python). Personally, I think that's well worth it, though. I don't know how many others would agree or not. Not trying to be argumentative, but what exactly do you see as the gains in having a D-buildtool built in D (or D-specific build-tool in any language, for that matter)? Seriously, I'm really asking, since I'm having a hard time seeing it? Personally, I can only see the drawbacks; * Building druntime and phobos might be difficult with a d-based buildtool * The build-tool itself will need bootstrapping. A user that wants to test some D-project, will first have to aquire (build) and install some D-compiler with custom tools. Then install druntime with another custom build-system. Then Phobos. Then drake. And THEN, the application/library he/she was interested in. Shortening this path is IMHO REALLY important to see more D adoption. From my personal experience, convincing developers and testers to fight through this path is HARD. * Cross-language builds (project with bindings), and builds with external targets might be more difficult than need be, if the 2nd language is not supported by drake. * Verbose build-script is IMHO a _really_ undesireable trait. * How soon will I as a developer be able to just build a D-binding to a C++-app (with needed C-glue-code) in Drake? Will a user of, say Gentoo, be able to count on this working in his/her envrironment too? * Non-compilation actions will have to be reimplemented; document generation, test execution, install-tasks following OS-specific install procedures (XDG-guidelines etc.), ... IMHO, it sounds like a case of the NIH-syndrome, but I might be missing something obvious?
Re: D auto-tester
I too think it's awesome. Just some quick thoughts; * Could some kind of benchmarking be integrated to track performance aspects, especially find regressions? Perhaps a bit high on the utility/work-scale? * Is the script available for running offline, on some local machine, I.E. verifying different distro:s, etc? * 1280x1024 is too small for seeing the results. Could the view perhaps be made slightly more compact? (Especially since OSX64 and Win64 might be interesting targets in the near future?) * What is Linux 32/64 vs. 64/32? In any case, great stuff. 2011/5/5 Walter Bright newshou...@digitalmars.com: In case not everyone knows about this, Brad Roberts conceived, implemented, set up and maintains an automated tester that watches github for checkins, and when there's something new it does a complete build of dmd and phobos, then runs the test suite on it, and posts the results: http://d.puremagic.com/test-results/ I think it's awesome.
Re: deprecated delete and manual memory management
2011/4/26 Timon Gehr timon.g...@gmx.ch: But you understand why it is deprecated for GC memory? The main thing to note is that the semantics of C++ 'new' and D 'new' are rather different. D 'new' performs allocation on the GC heap by default. The only sane overloads of 'new' would therefore allocate the object on a custom GC heap, which you never want to do. So there is absolutely no way to overload the 'new' operator meaningfully inside the D language. The argument for removing 'delete' overloading is trivial after taking that into consideration. You can still create custom allocators by the means of template functions. (I do not think this is optimal though because they duplicate code that needn't be) They feel a little bit less natural though, which is not a problem, since in D, custom allocators and manual memory management in general, _are_ less natural. One thing that is perhaps obvious, but eludes me; when dropping the delete-operator, are there any obvious reason to not also drop the new keyword? (new is a fairly good method/variable name, if nothing else) I could see two possible alternatives: Global (and defined-by-default) template new!(Type): (as suggested elsewhere in this thread by so) This is very close to the current situation, but makes it possible to use as a method-name, and clearly states there's nothing magic about it. Explicit Allocator, such as GC.new!(Type). Would have the benefit of clearly showing who did the allocation, and would map nicely to other allocators. (Malloc.new/free!(T)!(T)). It would also allow library-methods that might allocate instances, take an allocator as an optional template argument. I.E. auto obj = dict.createObject(key); OR auto obj = dict.createObject!(Malloc)(key); scope(exit) Malloc.free(obj); Possibly an obvious bad idea, but I haven't seen it discussed? Regards / Ulrik
Re: deprecated delete and manual memory management
2011/4/27 Jacob Carlborg d...@me.com: head or to be exact HEAD if you were wondering what to call it. -- /Jacob Carlborg Sorry to be nit-picking, but HEAD is whatever branch or commit is currently checked out into your working-copy. The git-equivalent of SVN-trunk is master. The default-name of the branch that usually contains published stuff. (Although just as in SVN it's a convention, not a rule.)
Re: Re: deprecated delete and manual memory management
Den, skrevJacob Carlborg d...@me.com: Yeah, that's correct. But in this case I think he actually was referring to the latest commit. I'm pretty sure I've heard the latest commit in SVN be referred to as trunk. I'm too curious for my own good, so I had to waste some time to investigate. It seems HEAD is a meta-reference, pointing to some other reference (such as some other branch or a specific commit). For a full repository, it's also the base of the current checkout. (Or really, the index, for anyone else in my currently nit-picking mood). For a bare repository (IE without a working-copy such as you would find on GitHub), it seems to be whatever HEAD was in the repository that was initially cloned to create the bare repository. So, in the case assumed here, HEAD is the same thing as master, but it can really be anything (including the initial zero-commit). So master, is always the last commit in the master branch, while HEAD can be anything. I think master is always a better translation of trunk. :)
Re: Linus with some good observations on garbage collection
2011/4/22 Timon Gehr timon.g...@gmx.ch: That is only a problem if the reference count of that resource changes at a very high frequency. The described problem also implies that the threads would not need any form of synchronization for the data (otherwise the reference count certainly would not be a bottleneck.) Michael Stover wrote: I'd like to say were proved rather than are believed, but I don't actually know where to go for such evidence. However, I do believe many scripting languages, such as python, eventually ditched the reference counting technique for generational, and Java has very fast GC, so I am inclined to believe those real-life solutions than Linus. Well, the GC may be fast when compared to other GCs, but it has to be designed to run on general data whose reference structure can be arbitrary. Often, the objects/references have a somewhat specialized structure that a smart programmer can exploit, especially if the references point to private data. But that only matters if performance is of prime interest, and the gains may be not very big. All in all, I think the best approach is a pragmatic one, where different types of resources can be handled according to different schemes. I.E. default to GC-manage everything. After profiling, determining what resources are mostly used, and where, optimize allocation for those resources, preferably to scoped allocation, or if not possible, reference-counted. Premature optimization is a root of much evil, for instance, the malloc-paranoid might very well resort to abuse of struct:s, leading either to lots of manual pointers, or excessive memory copying. Incidentally, this was the main thing that attracted me to D. Be lazy/productive where performance doesn't matter much, and focus optimization on where it does.
Low Level Bounded Model Checker
I just saw this on Google Tech talks, and thought others on the list might enjoy it; http://www.youtube.com/watch?v=vajMUlyXw_U It's about LLBMC, an automated program-prover targeting automated proofing for functional-style programs. The idea is to go a step beyond specific test-cases, and prove function correctness for all possible input values. The method is to compile the source (currently only C supported, with C++ on the way) using Clang to LLVM-IR, and perform the analysis on the LLVM-IR-level. Now, in D I think most of the meta-information framework required is already present in the language (for C, they've added some meta-keywords), especially DBC-programming with in and out-validators. A LLBMC-like version for D should in theory be able to use only the existing in/out/invariant/assert-clauses. However, it would be a VERY useful tool able to auto-validate all functional code against it's contract. http://baldur.iti.uka.de/llbmc/
Re: too early for D2 and too late for D1
2011/4/17 Gour-Gadadhara Dasa g...@atmarama.net On Sun, 17 Apr 2011 15:11:43 -0500 Andrew Wiley debio...@gmail.com wrote: Frankly, if your definition of not ready is that the compiler isn't packaged for you, D isn't the right community to begin with. First of all, there is no 64bit compiler for FreeBSD. I was researching about gdc and Iain Buclaw told me (on IRC) that there might be problem with dmd runtime on FreeBSD. Moreover, QtD requires a patched dmd compiler., so I simply do not have time to fight such things. I just want to add one thing. I am, too, trying to develop real open source applications in my free time, as well as practical closed source applications at work. The problem I have been facing even since the start, and are still facing, is that even if _I_ can be motivated to overcome these hurdles, I cannot expect everyone else to feel the same motivation for a new obscure C-like language. * At work, I have a hard time explaining to my co-workers why they need 3 hand-rolled, this particular version of compilers and libraries they've never heard of, just to compile my simple 200-line Mpeg analyzer. * At my free time it's even worse. Finding people able and willing to spend some time on MY pet project for free is hard enough in itself. Explaining to them why they must first spend an afternoon dealing with dependencies drive away the few that got past the first criteria. My view, is the D community right now are thinking long and hard about their own needs, and less of the needs of their users. (For a language, the application programmer IS the user.) Maybe even rightly so, getting things language-wise right from the start IS important! However, if it is desirable to attract developers that want to use D for productivity right now, there are a lot of practical issues that needs addressing, rough edges to smoothen, and hardly any of them lie in the language itself.
Re: Is the world coming to an end?
2011/4/3 Walter Bright newshou...@digitalmars.com: The 0x notation is heavily used, and so justifies a custom syntax for it. Octal is pretty much never used outside of setting file permission masks. The thing is, since you already have 0x and 0b, 0o would not be much of a custom syntax. It would simply be an extrapolation of the rule. It follows the already set pattern for non 10-base literals. Regarding the but it's so uncommon-argument, there are 23 characters left for the 0base-char-notation, there isn't exactly an allocation-problem. A feature that can be handled adequately by the library should not be part of the core language. If you're looking for uncommonly used language-features that could easily be otherwise solved, go ahead and remove asm instead. I'll guess it's about as uncommon as octal literals (or maybe even more), have simple other solution (just compile it separately and link), and has much greater impact on the language and the compiler. I simply don't buy the uncommon argument, when it's such a minuscule thing in the language, following an already established framework/pattern. The phrase discriminating against people has a lot of emotional baggage associated with it that is irrelevant to this. Walter, you can make the decisions you see fit, you are the BDFL, but please don't dismiss peoples feelings like this. It will only hinder D longevity and growth. I realize the discussion is over, and the feature has been implemented. Bitching and moaning now won't change anybodys mind, but for the record, I think this is a bad design-move, breaking established patterns. I agree it minuscule and seldom used, so I'm not going to continue the discussion.
Re: Re: Is the world coming to an end?
About time someone dropped the 0777-nonsense. The least common digit-base should not easily be invoked by accident. However: I don't like the octal! a lot, I prefer a syntax like the Python3 one, but Walter never stops moving himself forward :-) I too was just about to ask why on earth octal! instead of 0o (and I didn't know about Python3). Sure, I think it's nice and clean language-wise to implement it as a template-function, but if so the same should go for 0b and 0x? Are they too deprecated in D2?
Re: Re: Is the world coming to an end?
0b and 0x are not dangerous so there's no need to remove/deprecate them and thus cause breakage of code using them. At least 0x is quite common (certainly more common than octal numbers) so it makes sense to have this short syntax (IMHO). As I wrote, I think it's great that 010 != 8 anymore. I just think that 0o10 would be more consistent with 0x and 0b. Obviously the framework is there for parsing the literals, and AFAIK, 0o isn't accepted today so no code would be broken. 011 = 11 0b11 = 3 0x11 = 17 0o11 = 9 is much more consistent than 011 = 11 0b11 = 3 0x11 = 17 octal!11 = 9 A D-newbie would probably be able to guess 0o for octal, but hardly octal!. octal! breaks the rule of least surprise. In any case, everything is better than 011 = 9
Re: Python-indentation (Was: Re: Is the world coming to an end?)
PS I don't want to say every of Python's decisions is wrong. Many of them are great (but defenitely not significant intendation). On a side-note, I thought the same, until I realised I hate redundancies even more than I hated forced code-styles. And code-indentation AND brackets are clearly redundant, since they pretty much convey the same information block, only one is structural and the other visual. Nowadays, my complaint on Python-indentation are that they aren't fully enforcing a STRICT policy on indentation. Mixed-code indentation in 3d-part can cause a lot of unexpected bugs. Personally, I'd like to see a world where plain old text (whatever that means, considering all the related encoding and line-ending-problems constantly biting us multi-platform non-ASCII-people in the behind) were replaced with something just slightly higher-level, such as semantic trees. For programming, the notion would be to, instead of storing text, storing the AST of the parsed code, letting the editor render the tree to the user's preferences, to create true separation between information (the structural code) and visualization (the readable code). If a standardized format for the serialized tree was used, VCS:es could use it to record changes not as lines changed, but changes in the AST. Name-changes would not change entire lines, but just the references to that symbol. Wrapping a block of code into an if-statement could clearly be visualized, instead of appearing like a big chunk of code were COMPLETELY rewritten (when in reality it was just indented.) For other tree structured formats, if nothing else, efficient standardized tree-representation could significantly boost performance of some protocols. (XML, I'm looking at you) I know, it's not going to happen, but one can dream?
Re: a cabal for D ?
2011/3/18 Jesse Phillips jessekphillip...@gmail.com: Russel Winder Wrote: At the expense of easy system administration. Specifics? It allows for one packaging system across all operating systems. This means you don't need to figure out how to package your source in RPM, Deb, ipgk, arc, emerge, zip, or whatever else Linux has. For the developer, yes. For the user, it just means that you have to learn N different packaging systems, which not uncommonly cause conflicts, for instance in language-bindings conflicting with native libraries. I know of at least one company that were quite serious about migrating their webapps from Java to Ruby/rails, but after a while cancelled due to just those packaging issues with gems creating weird conflicts and silent errors when bindings were complied slightly differently from the native C-lib. For the record, their apps were designed for deployment on Ubuntu Server, which at the time had native support for almost all Java-related packages, but less wide support for Ruby. The situation have changed a little since then, and quite a lot of Ruby-packages are now in native Ubuntu.
Re: O(N) Garbage collection?
Just a thought; I guess the references to the non-GC-scanned strings
are held in GC-scanned memory, right? Are the number of such
references also increased linearly?
I'm not a GC-expert, but if so, wouldn't that pretty much force the GC
to do at least one follow-up of every reference, before realizing it's
pointing to non-GC memory? That COULD explain the linear increase.
That said, I too feel some improvements in the border between GC and
other resource-managements methods are needed. The prospect of good
GC/non-GC combinations was what drew me here in the first place. I
would welcome some clear language and runtime-support for
non-GC-memory, such as frameworks for ref-counting and
tree-allocation, and well-defined semantics of object lifetime both in
GC and non-GC mode. I've mostly sorted out the kinks of the myself (I
think), but it's proving to be _very_ difficult, mostly undocumented,
and often appears to be an afterthought rather than by-design.
Regards
/ Ulrik
2011/2/19 dsimcha dsim...@yahoo.com:
I've been trying out D's new 64-bit compiler and a serious barrier to using
it effectively seems to be abysmal garbage collection performance with large
heaps. It seems like the time for a garbage collection to run scales
linearly with the size of the heap *even if most of the heap is marked as
NO_SCAN*. I'm running a program with a heap size of ~6GB, almost all of
which is strings (DNA sequences), which are not scanned by the GC. It's
spending most of its time in GC, based on pausing it every once in a while
in GDB and seeing what's at the top of the stack.
Here's a test program and the results for a few runs.
import std.stdio, std.datetime, core.memory, std.conv;
void main(string[] args) {
if(args.length 2) {
stderr.writeln(Need size.);
return;
}
immutable mul = to!size_t(args[1]);
auto ptr = GC.malloc(mul * 1_048_576, GC.BlkAttr.NO_SCAN);
auto sw = StopWatch(autoStart);
GC.collect();
immutable msec = sw.peek.msecs;
writefln(Collected a %s megabyte heap in %s milliseconds.,
mul, msec);
}
Outputs for various sizes:
Collected a 10 megabyte heap in 1 milliseconds.
Collected a 50 megabyte heap in 4 milliseconds.
Collected a 200 megabyte heap in 16 milliseconds.
Collected a 500 megabyte heap in 41 milliseconds.
Collected a 1000 megabyte heap in 80 milliseconds.
Collected a 5000 megabyte heap in 397 milliseconds.
Collected a 1 megabyte heap in 801 milliseconds.
Collected a 3 megabyte heap in 2454 milliseconds.
Collected a 5 megabyte heap in 4096 milliseconds.
Note that these tests were run on a server with over 100 GB of physical RAM,
so a shortage of physical memory isn't the problem. Shouldn't GC be O(1)
with respect to the size of the unscanned portion of the heap?
Re: DVCS vs. Subversion brittleness (was Re: Moving to D)
2011/2/17 Bruno Medeiros brunodomedeiros+spam@com.gmail: Yeah, that's true. Some projects, the Linux kernel being one of the best examples, are more distributed in nature than not, in actual organizational terms. But projects like that are (and will remain) in the minority, a minority which is probably a very, very small. Indeed. However, I think it will be interesting to see how things develop, if this will be the case in the future too. The Linux kernel, and a few other projects were probably decentralized from start by necessity, filling very different purposes. However, new tools tends to affect models, which might make it a bit more common in the future. In any case, it's an interesting time to do software development.
Re: DVCS vs. Subversion brittleness (was Re: Moving to D)
2011/2/16 Russel Winder rus...@russel.org.uk: Definitely the case. There can only be one repository that represents the official state of a given project. That isn't really the issue in the move from CVCS systems to DVCS systems. Just note that not all projects have a specific state to represent. Many projects are centered around the concept of a centralized project, a core-team, and all-around central organisation and planning. Some projects however, I guess the Linux kernel is a prime example, have been quite de-centralized even in their nature for a long time. In the case of KDE, for a centralized example, there is a definite project version, which is the version currently blessed by the central project team. There is a centralized project planning, including meetings, setting out goals for the coming development. In the case of Linux, it's FAR less obvious. Sure, most people see master@torvalds/linux-2.6.git as THE Linux-version. However, there are many other trees interesting to track as well, such as the various distribution-trees which might incorporate many drivers not in mainline, especially for older stability-oriented kernels, RHEL or Debian is probably THE version to care about. You might also be interested in special-environment-kernels, such as non x86-kernels, in which case you're probably more interested in the central repo for that architecture, which is rarely Linuses. Also, IIRC, hard and soft realtime-enthusiasts neither looks at linuses tree first. Above all, in the Linux-kernel, there is not much of centralised planning. Linus doesn't call to a big planning-meeting quarterly to set up specific milestones for the next kernel release, but in the beginning of each cycle, he is spammed with things already developed independently, scratching someones itch. He then cherry-picks the things that has got good reviews and are interesting for where he wants to go with the kernel. That is not to say that there aren't a lot of coordination and communication, but there isn't a clear centralized authority steering development in the same ways as in many other projects. The bottom line is, many projects, even ones using DVCS, are often centrally organized. However, the Linux kernel is clear evidence it is not the only project model that works.
Re: D vs Go on reddit
2011/2/16 Bruno Medeiros brunodomedeiros+spam@com.gmail: We must not be saying (or thinking) the same thing then, because I do think it is worthwhile to have orthogonality as one of the primary design goals. I believe we are still not thinking of orthogonality in the same way. You seem to be thinking in terms of pure simplicity, how easy a language is to describe, learn and understand. I'm thinking of how much expressiveness you get per amount of complexity (how easy it is to describe, learn, and understand). So considering C++ and Java again: then yes, C++ is much more complex than Java (even new-school Java, barring generics perhaps). But I never said otherwise. I did say that Java is not more orthogonal than C++, but not in the sense that Java is just as orthogonal as C++. Rather I was trying to say that the comparison doesn't make much sense in the first place, because Java has much less capabilities. Like, you can compare D's meta-programming capabilites with C++, because in D you can do pretty much the same things as C++ (if not more) meta-programming-wise, yet the way things work in D are much more orthogonal, more simpler to describe and understand (and probably because of that, more powerful). The same comparison could be done with other features, like operator overloading between D and C++. But not between C++ and Java because doesn't support most of this functionality (and it doesn't make sense to compare with the Java alternatives) I completely agree in all of this, but I think orthogonality is a poor term for it. I think what you're describing is closer to the term elegance, in the mathematical sense (http://en.wikipedia.org/wiki/Mathematical_elegance). Mathematical elegance is basically about - Finding the simplest expression or solution for a problem, that still accounts for all possibilities. - Finding generally applicable solutions for many similar problems. (Even when the do not seem very similar. Consider, for instance physical velocity, and bitrates in computers) - Finding a solution few dependencies on other work or assumptions. It is also very close to the principle of Occams Razor, (http://en.wikipedia.org/wiki/Occam's_razor), basically saying that given two solutions to a problem which is equally correct (or equal probability of being correct), the one that is simpler is preferable. (The exact meaning of simpler is open to interpretation though. ;) A couple of good related quotes; Simplicity is the ultimate sophistication. - Da Vinci Make everything as simple as possible, but not simpler. - Einstein And finally one from Ockham himself: It is futile to do with more things that which can be done with fewer.
Re: DVCS vs. Subversion brittleness (was Re: Moving to D)
2011/2/11 Bruno Medeiros brunodomedeiros+spam@com.gmail: On 09/02/2011 23:02, Ulrik Mikaelsson wrote: You don't happen to know about any projects of this kind in any other VCS that can be practically tested, do you? You mean a project like that, hosted in Subversion or CVS (so that you can convert it to Git/Mercurial and see how it is in terms of repo size)? I don't know any of the top of my head, except the one in my job, but naturally it is commercial and closed-source so I can't share it. I'm cloning the Mozilla Firefox repo right now, I'm curious how big it is. ( https://developer.mozilla.org/en/Mozilla_Source_Code_%28Mercurial%29) But other than that, what exactly do you want to test? There is no specific thing to test, if you add a binary file (from a format that is already compressed, like zip, jar, jpg, etc.) of size X, you will increase the repo size by X bytes forever. There is no other way around it. (Unless on Git you rewrite the history on the repo, which doubtfully will ever be allowed on central repositories) I want to test how much overhead the git-version _actually_ is, compared to the SVN-version. Even though the jpg are unlikely to be much more compressible with regular compression, with delta-compression and the fact of growing project-size it might still be interesting to see how much overhead we're talking, and what the performance over network is.
Re: D vs Go on reddit
2011/2/10 Bruno Medeiros brunodomedeiros+spam@com.gmail:
I'm very much a fan of simple and orthogonal languages. But this statement
has a big problem: it's not clear what one actually considers to be simple
and orthogonal. What people consider to be orthogonal can vary not only a
little, but actually a lot. Sometimes it can actually vary so much as to be
on opposite sides. I remember seeing that first hand here on D: two people
were arguing for opposing things in D (I don't remember the particular
issue, but one was probably a greater language change, the other as for the
status quo, or a minor change from the status quo), and explicitly argued
that their alternative was more orthogonal! I remember thinking that one was
stretching the notion of orthogonality a bit further than the other, but I
didn't find any of them to actually be incorrect.
For the sake of discussion I'll define orthogonal as non-redundant.
For instance, orthogonal dimensions in a coordinate-system is when the
dimension is completely unrelated to other dimensions, i.e. there is
no redundancy in the coordinate-system. Likewise orthogonality in a
language in my definition means it does not have redundancy in
features.
Now, the problem with orthogonality is that, it is not good for
exploiting 80/20 optimisations.
Example: for most (imperative) languages, you'll somewhere have the
general way of iteration;
list x;
int i = 0;
while (i x.length) {
// do something with x[i];
i++;
}
Now, if the language is truly orthogonal, you cannot add the foreach
(x in list)-feature, since it's a redundant way of doing a subset of
the same things. Yet, it's highly likely practical thinking says that
for most programs in the language, 95% of all iteration will be
list-iteration, where the foreach-version is both shorter to write,
easier to read, and not as prone to a typo.
Re: D vs Go on reddit
2011/2/9 spir denis.s...@gmail.com: Yop! this said, I recently read (no pointer, sorry) about a possibly interesting third way: making the core language as close to orthogonal as possible w/o making the rest difficult, then build compromises as sugar layers around (syntactic semantic). This may be, actually, more or less close to how some actual languages are actually constructed; but I find that making this principle intentonal and intentional totally changes the whole approach. Also think this well fits the design of PL with a main/core paradigm/style (not so for D, probably). Isn't this how much of JavaScript is ACTUALLY used nowadays? jQuery, YUI, PrototypeJS? Coding for limited embedded hardware, I'm personally hand-coding Javascript (without 3:d-party-libs) at work ATM, since I really need to know all effects (especially on the DOM) of everything I do. (Is something reading .offsetHeight? - i DEFINITELY need to know about it.) Outside the realm of embedded/limited hardware though, it seems few people are actually coding in pure JavaScript without convenience-libraries. Maybe it's the ASM of next decade.
Re: DVCS vs. Subversion brittleness (was Re: Moving to D)
2011/2/9 Bruno Medeiros brunodomedeiros+spam@com.gmail: It's unlikely you will see converted repositories with a lot of changing blob data. DVCS, at the least in the way they work currently, simply kill this workflow/organization-pattern. I very much suspect this issue will become more important as time goes on - a lot of people are still new to DVCS and they still don't realize the full implications of that architecture with regards to repo size. Any file you commit will add to the repository size *FOREVER*. I'm pretty sure we haven't heard the last word on the VCS battle, in that in a few years time people are *again* talking about and switching to another VCS :( . Mark these words. (The only way this is not going to happen is if Git or Mercurial are able to address this issue in a satisfactory way, which I'm not sure is possible or easy) You don't happen to know about any projects of this kind in any other VCS that can be practically tested, do you? Besides, AFAIU this discussion was originally regarding to the D language components, I.E. DMD, druntime and Phobos. Not a lot of binaries here.
Re: What Makes A Programming Language Good
2011/2/4 Bruno Medeiros brunodomedeiros+spam@com.gmail: language ecosystems are what matter, not just the language itself. At least for most programmers, what you want is to develop software, software that is useful or interesting, it's not about staring at the beauty of your code and that's it. My view is that language ecosystems matters TOO, but it's not enough if the language itself, or the platforms it's tied to makes me grit my teeth. What good is earning lots of money, to buy the finest food, if I only have my gums left to chew it with? (Figuratively speaking, of course)
Re: DVCS vs. Subversion brittleness (was Re: Moving to D)
2011/2/4 Bruno Medeiros brunodomedeiros+spam@com.gmail: Well, like I said, my concern about size is not so much disk space, but the time to make local copies of the repository, or cloning it from the internet (and the associated transfer times), both of which are not neglectable yet. My project at work could easily have gone to 1Gb of repo size if in the last year or so it has been stored on a DVCS! :S I hope this gets addressed at some point. But I fear that the main developers of both Git and Mercurial may be too biased to experience projects which are typically somewhat small in size, in terms of bytes (projects that consist almost entirely of source code). For example, in UI applications it would be common to store binary data (images, sounds, etc.) in the source control. The other case is what I mentioned before, wanting to store dependencies together with the project (in my case including the javadoc and source code of the dependencies - and there's very good reasons to want to do that). I think the storage/bandwidth requirements of DVCS:s are very often exagerated, especially for text, but also somewhat for blobs. * For text-content, the compression of archives reduces them to, perhaps, 1/5 of their original size? - That means, that unless you completely rewrite a file 5 times during the course of a project, simple per-revision-compression of the file will turn out smaller, than the single uncompressed base-file that subversion transfers and stores. - The delta-compression applied ensures small changes does not count as a rewrite. * For blobs, the archive-compression may not do as much, and they certainly pose a larger challenge for storing history, but: - AFAIU, at least git delta-compresses even binaries so even changes in them might be slightly reduced (dunno about the others) - I think more and more graphics are today are written in SVG? - I believe, for most projects, audio-files are usually not changed very often, once entered a project? Usually existing samples are simply copied in? * For both binaries and text, and for most projects, the latest revision is usually the largest. (Projects usually grow over time, they don't consistently shrink) I.E. older revisions are, compared to current, much much smaller, making the size of old history smaller compared to the size of current history. Finally, as a test, I tried checking out the last version of druntime from SVN and compare it to git (AFICT, history were preserved in the git-migration), the results were about what I expected. Checking out trunk from SVN, and the whole history from git: SVN: 7.06 seconds, 5,3 MB on disk Git: 2.88 seconds, 3.5 MB on disk Improvement Git/SVN: time reduced by 59%, space reduced by 34%. I did not measure bandwidth, but my guess is it is somewhere between the disk- and time- reductions. Also, if someone has an example of a recently converted repository including some blobs it would make an interesting experiment to repeat. Regards / Ulrik - ulrik@ulrik ~/p/test time svn co http://svn.dsource.org/projects/druntime/trunk druntime_svn ... 0.26user 0.21system 0:07.06elapsed 6%CPU (0avgtext+0avgdata 47808maxresident)k 544inputs+11736outputs (3major+3275minor)pagefaults 0swaps ulrik@ulrik ~/p/test du -sh druntime_svn 5,3Mdruntime_svn ulrik@ulrik ~/p/test time git clone git://github.com/D-Programming-Language/druntime.git druntime_git ... 0.26user 0.06system 0:02.88elapsed 11%CPU (0avgtext+0avgdata 14320maxresident)k 3704inputs+7168outputs (18major+1822minor)pagefaults 0swaps ulrik@ulrik ~/p/test du -sh druntime_git/ 3,5Mdruntime_git/
Re: Safety strategies
Interesting idea, especially when you start considering how software might survive errors in dependent systems, I.E. hardware, networking, or software components outside the control of the compiler. It sounds like the Erlang approach is far more likely to survive spurious bitflips, power-fluctuations and others things we all prefer to pretend don't exist. 2011/2/6 bearophile bearophileh...@lycos.com: This is one of the most interesting CS ideas I've found in the past month, here I have started to understand rationally why dynamic languages like Python may generally be not significantly more bug prone than tightly statically typed languages like ML or D: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=126394 Recently in this Reddit thread I have found a third interesting safety strategy: http://www.reddit.com/r/programming/comments/fdrtz/lisp_atoms_ruby_symbols_erlang_atoms_how_useful/ It's explained more in focus here: http://stackoverflow.com/questions/3399956/pattern-matching-f-vs-erlang Erlang software systems are among the most reliable ones, yet it refuses the static safety used by ML-class languages (like SML, Haskell, ATS, OCaML, F# and many more). It's really a different strategy to create reliable systems. -- Some mixed quotations from that stackoverflow and reddit discussions: When you run into a constraint that needs to change you change the types. If there is a case I didn't consider I add a new value to a sum type or enum or class or whatever. In a pattern matching language this will break things but the compiler will handily point out exactly which patterns no longer make any sense or which ones are now non-exhaustive. Fixing it straight forward. You mention the value of the compiler pointing out non-exhaustive pattern matching. It might interest you to know that in Erlang that is a no-no. Your pattern matching should not handle cases you do not know how to deal with in a let it crash manner. Actually Joe Armstrong (Erlang's creator) puts it as let some other process fix the error. The idea is not unlike the idea common in exception handling that you shouldn't catch all exceptions but rather those that you can handle. Crash here doesn't mean bring down the program. In Erlang, a program typically consists of a number of processes, interacting via message passing. If a process crashes then another process handles that event (oversimplified). It may elect to respawn the process crashed and/or deal with the error in whatever way it sees fit. It may also simply die as well, and then its supervisor handles the result. As I said, the nearest thing to this is other languages is exception handling. The whole point, as it is the point in exception handling, is that the process or function should not be programmed that defensively. Let's have an example. The next is F# code: let testColor c = match c with | Black - 1 | White - 0 | Other - failwith unexpected color an almost equivalent Erlang code is case c of black - 1; white - 0 end; In F#, I must use the failwith function. The reason is that the language forces me to have exhaustive pattern matching. In Erlang it doesn't. In fact, Erlang encourages me not to fill in a handler for all other cases where the color is not black or white. Now the results: - In F#, I know that my function has handled all cases. I can depend on that. On the other hand, because I was forced to do what is essentially error handling as early as possible I might get it wrong. In the example, I returned a generic error unexpected color which may or may not be true (in this case copied from here I am using an active pattern and the error might be anything else in the pattern function). In short, I am losing information because I had to handle the potential error early. This is the same argument in exception handling. You don't catch an exception which you do not know how to handle; you let it go up the stack. - In Erlang, if a colour is not matched then the pattern matching raises a badmatch error. This can be handled at the appropriate level in the function stack or the process hierarchy. - On the other hand, the F# approach is probably more amenable to proof of correctness. Depending on whether you think this is an important enough issue, you might prefer that. I have worked with both. It really depends on the whole approach you are using. Erlang has a very impressive pattern matching and it is non-exhaustive, because the whole model of fault handling is different from the ML approach where a fault is a world collapses type of event. Armstrong's PhD thesis was Making reliable distributed systems in the presence of software errors. The ML approach is to not have software errors. The point of the Erlang philosophy is not to produce bad code that always crashes. Let it crash
Re: D vs Go on reddit
2011/2/3 Jérôme M. Berger jeber...@free.fr: Then why has not Lisp won over all competition years ago? Jerome You mean why(not(has(won(lisp,all(competition)),years_ago))) ? Jokes aside, I think people in language-debates often forget that high-level languages are really just layers of syntactical sugar over machine-code. ASM is syntactical sugar over machince-code, C is syntactical sugar over ASM, and D is mostly syntactic sugar over C. They are merely ways to streamline certain programming-models, into a language that encourages those idioms and constructs. Just about anything that can be written in D, can be written with equivalent semantics in C, but the D-version is likely to be faster to write, and faster to comprehend. The purpose of higher-level languages is to encourage good programming style and readability. Period. The syntax is crucial here, it determines which constructs will become readable, and which won't, which in turn determines the mind-set of the programmer. Which is why I consider syntactic sugar to be seriously under-appreciated and undervalued in many language decisions.
Audio time-compression (Was: On 80 columns should (not) be enough for everyone)
2011/1/30 Walter Bright newshou...@digitalmars.com: People who use screen readers often crank up the playback rate to 2x. The software adjusts the pitch so it doesn't sound like the Chipmunks. I've often wondered why DVRs don't do this (I've sent the suggestion to Tivo, they ignored me). I'd like the option to play the news (or other talk shows) at a faster rate, with pitch adjustment. I've found I can watch Tivo at 3x with the closed captioning on, and can almost keep up. The problem with DVRs at any fast forward speed is they turn the sound off! G. A golden opportunity missed. I'd also love it if youtube etc. did this. It's so boring looking at youtube presentations because they talk so slow. I'd love a double speed youtube viewing option. Remember I posted this in case some troll tries to patent it. I KNEW I wasn't alone at this. My S.O. usually just rolls her eyes when I do this. (Tip: VLC does it for at least double-speed) I think the reason I.E. YouTube and Tivo don't do it is that AFAIU, it is fairly CPU-consuming (FFT back and forth?) In the TiVo-case, my guess is nobody paid for the hardware, and in the YouTube-case I doubt neither Flash nor JavaScript will enable the performance required. Perhaps it can be done browser-dependently with HTML5. Now, what we need is the audio-equivalent of this: http://www.youtube.com/watch?v=6NcIJXTlugc
Re: On 80 columns should (not) be enough for everyone
FWIW: Here's my two cents; (Non-Phobos participant, so feel free to click delete now) I'm not sure whether text-books and program-code are really comparable in this respect. When reading books I hardly put much attention to each particular word, while in computer-code, each token is very significant. The flow of reading is simply different. If it weren't, we would hardly use hard line-breaks at all, just concatenate statements like we concatenate sentences in text, and use your word processor to format code. Especially, we would not use monospaced fonts and care about columns. I would rather like to hear whether any mathematicians ever insert hard-breaks into their equations just to not get them too wide. Personally, I've been a long time on the fence regarding strict line-length, and my current position is: 90 columns is the rule of thumb. 80 columns is often hard to fit using readable names, but 90 columns generally works. When the code exceeds 90 columns, I try to look for: * local variable names that can be shortened without breaking their descriptiveness. * sub-expressions in the line, which can be reasonably be extracted into separe pre-computed variable. (Which also increases readability of the code by itself.) * unnecessary nested depth in the function, and try to either refactor parts out to separate functions, or refactor the function to be more pass-based rather then nested. One special-case which often cause problems, is function-calls, especially method-calls. Roughly lines like: (note 3-level leading indent) otherObj1.doSomethingSensible(otherObj2.internalVariable, this.config, this.context); At this point, I can see two obvious alternatives; otherObj1.doSomethingSensible(otherObj2.internalVariable, this.config, this.context); vs. otherObj1.doSomethingSensible(otherObj2.internalVariable, this.config, this.context); Both have advantages and problems. In the first alternative, you might miss the second argument if reading too fast, and in the second alternative, the vertical space can be quickly wasted, especially if the line get's just slightly too long due to many small arguments. (I.E. debug-output of many short-named local variables.) In these cases, I usually just leave it to overflow. That will * hint to the reader that it's still just one single function-call * arguments won't be missed * not waste unnecessary vertical space * it's up to the code-viewer to determine whether a line-wrap is actually needed, which it might even indicate using a wrap-marker in the margin (not possible with a manual line-break). For other common long-line sources like enums, array literals etc, I usually block-format and insert line-breaks as usual to not exceed 90 columns wide. My guess is, if I worked enough with long mathematical expression, I would use roughly the same guidelines. / Ulrik (*doh* that was probably more than 2 cents worth.) 2011/1/30 Andrei Alexandrescu seewebsiteforem...@erdani.org: On 01/30/2011 12:27 PM, Walter Bright wrote: Andrej Mitrovic wrote: 80 columns wasn't determined by some scientific method to be a good size for code, it's a product of limitations of the older generation hardware. 80 columns came from how many characters would fit on a standard size 8.5*11 sheet of paper. Even punch cards followed this precedent. That paper size has stood the test of time as being a comfortable size for reading. Reading longer lines is fatiguing, as when one's eyes carriage return they tend to go awry. You can see this yourself if you resize and reflow a text web site to be significantly wider than 80 columns. It gets harder to read. Also: pick a random book or newspaper and count the characters in a line. They range between 60 and 80, counting for about 10 words per line. This has been the case ever writing systems have been invented. It is a fallacy to assume that 80 has anything to do with the first monitors. In fact, it's the opposite - the monitors were conceived following a universal human constant. One funny thing is that at my employer (where each and every employee has a 30 2560x1600 monitor) everything is under constant debate, starting with which email server and ending with choosing UserId versus UserID. Nobody and not once has debated the 80 column rule. Phobosians have voted with their fingers. Long lines in Phobos are rare and the result of lack of enforcement, not a stylistic choice. Jonathan simply didn't know about that, and has graciously agreed to align to that convention (thanks!). Andrei
Re: Is D still alive?
2011/1/28 retard r...@tard.com.invalid: I've heard this before. I've also heard the 64-bit port and many other things are done in a year/month or two. The fact is, you're overly optimistic and these are all bullshit. When I come back here in a year or two, I have full justification to laugh at your stupid claims. 64-bit port for D (at least v1) IS available. I use LDC to build and run on 64-bit, but I'm sure GDC will work as well. The LDC-port for D2 may be untested though, and I do not know about GDC, but personally, I think it's a mistake to recommend D2 for new projects. Given the importance of compilers, runtime and base-libraries, and the kind of bug-reports I hear frustration around, it seems D2 should still be considered beta, but for people who want working development now, recommend D1. In all it's inferiority, it IS more stable. My guess is much frustration in the D community stems from slightly pre-maturely trying to push D2, before neither D1 nor D2 was ready. I've chosen to only work with D1/Tango from start, and I simply don't recognize the frustration many are feeling. I'm only concerned over that there ARE quite a few developers that seems to have been turned off by instability, and the Phobos/Tango-problem. Well, well. I'm generally a happy D-developer, and I only hope D3 won't be started until D2 is rock-stable, and fully utilized. :)
Re: (Was: On 80 columns should (not) be enough for everyone)
90 as a rule of thumb with some exceptions.
Re: On 80 columns should (not) be enough for everyone
2011/1/31 Andrei Alexandrescu seewebsiteforem...@erdani.org: On 1/31/11 11:54 AM, Ulrik Mikaelsson wrote: I'm not sure whether text-books and program-code are really comparable in this respect. When reading books I hardly put much attention to each particular word, while in computer-code, each token is very significant. The flow of reading is simply different. If it weren't, we would hardly use hard line-breaks at all, just concatenate statements like we concatenate sentences in text, and useyour word processor to format code. Especially, we would not use monospaced fonts and care about columns. Well the fact of the matter is that style used in books is very influential. People do copy book samples into code and continue working in the same style from them. I've been asked for (and released) the source code of all snippets in TDPL. Sorry, maybe I was unclear, I wasn't referring to code-snippets in a book. I meant the kind of text-books I understood Walter refer to, that made the basis for 80x25. Think fiction, not programming books. I absolutely agree there are good UI-design reasons to limit column-width in these. Commonly such text is also text-align: justify, and even broken up into multiple-column layouts to reduce horizontal scan, but precisely those two things make me skeptical about just HOW relevant it actually is for computer-code. I would rather like to hear whether any mathematicians ever insert hard-breaks into their equations just to not get them too wide. I'm not sure I can qualify as a mathematician but my research is very math-heavy. In my thesis (http://erdani.com/research/dissertation_color.pdf) I frequently inserted line breaks even when not technically necessary, check e.g. eq. 2.16 on page 12. Thank you, interesting for the topic (although I didn't understand a thing of the actual math :). I note however that given the very terse variable-names (as is common in math), the lines don't actually grow very long. However, where you HAVE chosen to insert line-breaks, is at equality-operators which I would say is roughly a statement in programming-language terms. (A = B is a statement, while A+B is not.) Interestingly enough, this is roughly the rule-of thumb I use. Try hard to keep statements below 90 characters, but don't resort to manual line-breaks if it's not possible. Personally, I've been a long time on the fence regarding strict line-length, and my current position is: 90 columns is the rule of thumb. 80 columns is often hard to fit using readable names, but 90 columns generally works. Seems reasonable. Since both Jonathan and Don prefer longer lines, I'm now more inclined to increase and/or soften the recommended limit for Phobos. Actually, writing and reading about it got me thinking. I think the real value of the 80/90/120/whatever-rule is not really the actual line-length itself. If that was the case, editors with auto-indentation could quite easily have additional rules for automatic code-wraps. The actual value of having the rule is to alert the coder that something _might_ be sub-optimally expressed. Perhaps D should have something similar to pylint? Sure, much of the need for pylint goes away in a statically typed language, but it's also quite good in diagnosing design by code-complexity measurements. OTOH things like symbols-per-file, arguments-per-function, operations-per-function, etc. could be good indicators to quickly spot hairy code. One could also check for naming-conventions and probably other cleanliness-aspects as well.
Re: Is D still alive?
2011/1/31 Jesse Phillips jessekphillip...@gmail.com: I do not think there is an issue with using D2 in a new project, but if you have to ask you probably should go with D1. I say this because someone who is aware of the issues present in the language is able to decide if their desired project would be hindered by the bug. I completely agree with this, but that important if is not conveyed by the recommendation D version 2 which is recommended for new projects. :) I think it's not as much a problem of actual problems, as a problem of wrong expectations. Anyhow, D1 is a great language. D2 looks to be an ever better language and from what I hear rapidly stabilizing. The only reason I brought this up (after days of questioning if it's even worth mentioning), is hoping to avoid the same problems when D3 arrives.
Re: Audio time-compression (Was: On 80 columns should (not) be enough for everyone)
2011/1/31 Walter Bright newshou...@digitalmars.com: I think the reason I.E. YouTube and Tivo don't do it is that AFAIU, it is fairly CPU-consuming (FFT back and forth?) In the TiVo-case, my guess is nobody paid for the hardware, and in the YouTube-case I doubt neither Flash nor JavaScript will enable the performance required. Perhaps it can be done browser-dependently with HTML5. I think the problem is it either never occurred to Tivo or Youtube, or they don't care about it. When I shut off my Tivo service, I told them that such a feature would entice me to keep it. But I seriously doubt they transmitted my idea to the right people. Perhaps, although I develop for STB:s at work, and I know how amazingly price-pressed the hardware is. Seriously, it's designed to show live HD, but the developers manual for one manufacturer, there's a performance-warning about animated GIF:s (not kidding). My guess is, the only FFT the box can manage is the one hard-coded in the video-chip, which can't easily be exploited for other means. Of course, I don't know what HW the Tivo is using, perhaps they're just lazy. :)
Re: (Was: On 80 columns should (not) be enough for everyone)
2011/1/31 spir denis.s...@gmail.com: On 01/30/2011 09:32 PM, Jérôme M. Berger wrote: Do you know of any editor that can word wrap *while respecting indentation*? Any editor I know will wrap to the first column, which renders indentation pointless in the presence of long lines... Yop, geany :-) http://en.wikipedia.org/wiki/Geany Kate does this too, and clearly marks out it's an auto-wrapped line http://imagebin.org/135452 Personally, I'd like it to find the starting-parenthesis of the call and indent to it, though.
Re: Audio time-compression (Was: On 80 columns should (not) be enough for everyone)
I might be wrong, I hardly ever get to touch things that low-level, unfortunately. However, I think the DSP:s included in most STB:s are severely limited in how much you can twist them. AFAIU, that's one quiet important aspect of the whole HTML5 video-codec debacle. I.E. in the boxes I work with, the entire video-processing-chain is done in one pipe-line, separated from the CPU almost directly at the network-interface, and color-keyed back with other graphics in the very last rendering-step. (Much as the old Voodoo2-cards worked.) From the economics stand-point, there's a HUGE cost-focus on them, so every chance of removing costs from hardware is taken. Every dollar saved on hardware is roughly a dollar on the bottom-line, and in the volumes STB:s sell, that's millions of dollars. Sure, software costs might go up, but not likely by millons of dollars yearly. I.E. even if you CAN use the DSP-components to post-process audio, I would not be surprised to learn it hasn't got the power to do it simultaneously with video-playback. Again, I don't work low-level enough to tell for sure, and TiVo might spend a lot more on the hardware than I'm used to, but hardware limitations in this industry is a very real challenge, especially for things like post-processing. I too would love 2X playback with working audio though. :) 2011/1/31 Walter Bright newshou...@digitalmars.com: Ulrik Mikaelsson wrote: Of course, I don't know what HW the Tivo is using, perhaps they're just lazy. :) I thought that DSP's were programmable.
Re: Git Contributors Guide (Was: Re: destructor order)
2011/1/27 Vladimir Panteleev vladi...@thecybershadow.net: On Thu, 27 Jan 2011 00:26:22 +0200, Ulrik Mikaelsson ulrik.mikaels...@gmail.com wrote: The way I will show here is to gather up your changes in a so-called bundle, which can then be sent by mail or attached in a bug-tracker. First, some terms that might need explaining. Many open-source projects that use git use patches generated by the format-patch command. Just type git format-patch origin. Unless you have a LOT of commits, patches are better than binary bundles, because they are still human-readable (they contain the diff), and they also preserve the metadata (unlike diffs). You can even have git e-mail these patches to the project's mailing list. The second and following patches are sent as a reply to the first patch, so they don't clutter the list when viewed in threading mode. True. The only problem with this, I think, is getting the patch out from web-based mail-readers. Key-parts of the metadata about the commit lies in the mail-header, which might not always be easily accessible in web-readers. Also, send-email is for some reason no longer included in the git-version that comes with Ubuntu 10.10. Perhaps it's been removed in later versions of git.
Re: Is D still alive?
You mean that if you give an index which is too large, it just uses $ instead? That sounds seriously bug-prone to me. I'd much rather that it blew up and thus told me that my program had a bug in it rather than silently trying to work. Sorry, but you are wrong on this. I understand this sounds unsafe, but no. Most languages, I guess, just do that without any worry. In particular, I have frequented python and Lua mailing lists for years without even reading once about this beeing a misfeature (and indeed have never run into a bug because of this myself). It is simply the right semantics in 99.999% cases. Isn't the real reason for this that bounds-checking is usually completely turned-off in release-builds? Sounds like something that could noticeably degrade runtime-performance for array-intensive code?
Git Contributors Guide (Was: Re: destructor order)
2011/1/26 Steven Schveighoffer schvei...@yahoo.com: Steve, if you could point out what I need to do I'll be glad to do it right now. Better yet, feel free to try your hand at a git commit. It's fun! *sweats nervously* I don't know, I'd like to read about how git works before doing a commit. I don't really understand it at all, I had the same problem with subversion when I started using it. This seems like a good time for a quick git-contributors guide. There are plenty of guides in other places, but anyways; (this is for Linux and the native Git). I do not know about how to work with other versions such as Tortoise, or on other platforms, but it should be very similar. One-time thing for first-time git; tell git who you are: $ git config --global user.name John Doe $ git config --global user.email john@server.com 1. Clone out a fresh copy of the project from github, i.e. $ git clone git://github.com/D-Programming-Language/druntime.git 2. Do your thing. Change whatever file you need. 3. Stage your changes with git add file for any added or changed file. $ git add path/myfile 4. Commit with git commit. Your editor will pop up asking for a commit-message. $ git commit ** Short-path **: If there are no _new_ files in the commit, you can skip step 3, and git commit -a without the git add-stage. This will make the commit-command work like in Subversion. ** GUI-alternative **: For step 3 and 4, please try out the excellent git gui command, which let's you pick individual lines in files to commit. Great for splitting up work into logical patches. Also has support for amending the last patch in line, fixing typos and such. Your commit is now done. You can examine it with the command git log which will show you the commit-history, and git show, which will show you the last commit in detail. ** GUI-alternative **: I find gitk to be immensely useful to review things before submitting or publishing them. It allows all sorts of niceties, reviewing both changes and snapshotted trees from history, comparing revisions and following changes to a single file. There are now many ways to now submit the patch. The BEST way is probably publishing your branch in some public place like github, and send a notification to the respective mailing-list, or bug-tracker. It is described at github itself. Another way is of course generating a plain old git diff, but that does not retain authorship or time. Nor is it practical for series of patches. The way I will show here is to gather up your changes in a so-called bundle, which can then be sent by mail or attached in a bug-tracker. First, some terms that might need explaining. :origin: A repository usually has neighboring repositories, friend whom you often communicate with. origin is the default-name of the repository you originally cloned. upstream so to speak. :master: In each repository, there can be many branches. master is by default the name of the trunk, in SVN-terms. So, when one speaks about origin/master, one is basically saying trunk of upstream. Now, creating your bundle is as simple as: $ git bundle create mypatch.gitbundle origin/master.. # Dont forget the double-dots. This tells git to bundle up all revisions on my current branch, that aren't in upstream. This will generate the file mypatch.gitbundle, which can be sent to for review. The reviewer then pulls from it by: $ git checkout -b review# Create new review-branch. $ git pull path/to/bundle HEAD # Import from bundle. The changes will now be merged into the reviewers tree, in a special review-branch, where verification can be made, tests can be run and, possibly small fixes to the patch can be appended. When done, change to master-branch and merge the changes (if they are acceptable). $ git checkout master # Checkout the master-branch (or some other branch if integration should happen there instead) $ git merge review # Merge in the review-branch $ git branch -d review # And drop it Hope this helps. For more advanced, and continual work, you should probably setup a private fork, described at http://help.github.com/forking/. Happy Git:ing!
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
That's the same exact concept, isn't it? My understanding is that a clone of a DVCS repository *is* a distinct DVCS repository. So, yea, like I said, you have to specify which repository. The common dev repository. The main stable repository. The only shared repository this small project actually has. Or Bob's repository for what little that would be worth. Mostly a side-note, but in many DVCS:es (git in particular, but both bzr and hg has it too), history rewriting is allowed, even encouraged under some particular circumstances. In that case, the SHA-1 revision will CERTAINLY change, while even repo+number is not very reliable. Some kernel-branches are maintained like that, for example. Furthermore, a related hg-anecdote; Personally, for my work-flow I often use history-rewriting to jump around, amending patches, rebasing them before pushing, etc. I've become very accustomed to it, and find it extremely useful. When trying out hg a while back (to make patches for LDC IIRC), the attempted linear-history was actually one of my biggest disappointments. I quickly ended up in a situation where all my patches looked like a zig-zag-stacked hodgepodge of stuff, many of them not intended to even keep in the repo. When reading the docs about it, the only useful suggestion I found was to create a new repo, and cherry-pick what I wanted from the old. It's possible this were mostly due to my inexperience with Hg, but it strengthened my conviction that the unrealistic linear-numbers of a non-linear history are really just shoe-horning in something for newbie-comfort, but quite off as a model. For me, It is the deal-breaker for hg. I don't understand why you think I'm claiming anything of the sort. I never said anything like that. I keep saying over and over and over and over and over and over and over.changeset number **PLUS WHICH REPOSITORY (and maybe branch, depending how the given system chooses to work)** How should you linearly number the two chains A B C and A D C ? Is it A, B, D, C or A, D, B, C? Should they be inter-vowen by commit-time, or what? Additionally, Hg's approach provides a trivial way to disambiguate hash collisions. I know that Git book brushes it off as very rare, but it's not as if nobody's ever going to run into it. Um, what method is that? Version number together with being specific about which repository. Again, version-number + repo is not 100% when history-rewrite is possible. Also, saying that SHA-1 hash collisions are very rare is a bit of an understatement. Point is, it's possible and it's going to happen at least to someone, and frankly, such things *have* happened. Winning the lottery and getting hit by lighting are *extremely* rare, and yet there are a *lot* of people who have had it happen. The problem is they're taking rare (doesn't matter what superlative is used) and pretending it's the same as impossible. Airplane crashes and major earthquakes are extremely rare, but they sure as hell plan for what happens should such an event occur. Getting hit by lightning isn't really on the same scale as SHA-1 collisions. According to Wolfram Alpha, the odds of being struck by lightning in a given year is one in 75. If I've understood things roughly right, (probabilities aren't my strong side) the best possible attack for SHA-1 requires 2^52 attempts (Note: intentional attack, pure random chance is likely MUCH higher). That means that, given a very big project of 1 million commits (2^20, by comparison Linux is at 232k atm), the chance of intentionally hitting a collision is 1 in 2^32 = 4billion. Suffice to say, comparatively there might be a prospering market for current-insulating clothing. I guess, when every household on earth are running it's own kernel-project, git might have to upgrade to SHA-512. (Hg too, btw. I think the REAL, internal revision-id:s for HG is sha-1 too, aren't they?)
Re: DVCS (was Re: Moving to D)
Wow. The thread that went Moving to D-Problems with DMD-DVCS-WHICH DVCS-Linux Problems-Driver Problems/Manufacturer preferences-Cheap VS. Expensive. It's a personally observed record of OT threads, I think. Anyways, I've refrained from throwing fuel on the thread as long as I can, I'll bite: It depends on a number of factors, including the quality of the card and the conditions that it's being used in. I've had video cards die before. I _think_ that it was due to overheating, but I really don't know. It doesn't really matter. The older the part, the more likely it is to break. The cheaper the part, the more likely it is to break. Sure, the lack of moving parts makes it less likely for a video card to die, but it definitely happens. Computer parts don't last forever, and the lower their quality, the less likely it is that they'll last. By no means does that mean that a cheap video card isn't necessarily going to last for years and function just fine, but it is a risk that a cheap card will be too cheap to last. Cheap in the sense of less money isn't the problem. Actually, HW that cost more is often high-end HW which creates more heat, which _might_ actually shorten the lifetime. On the other hand, low-end HW is often less heat-producing, which _might_ make it last longer. The real difference lies in what level of HW are sold at which clock-levels, I.E. manufacturing control procedures. So an expensive low-end for a hundred bucks might easily outlast a cheap high-end alternative for 4 times the money. Buy quality, not expensive. There is a difference.
Re: Moving to D
Funny thing about that: After accidentally committing a subdirectory instead of the full project one too many times, I submitted a TortoiseSVN feature request for an option to always commit the full working directory, or at least an option to warn when you're not committing the full working directory. They absolutely lynched me for having such a suggestion. Of course. You're in conflict with the only hardly-functional branching support SVN knows. (Copy directory) I know some people who considers it a feature to always check out entire SVN-repos, including all branches and all tags. Of course, they are the same people who set aside half-days to do the checkout, and considers it a days work to actually merge something back.
Re: Moving to D
2011/1/6 Nick Sabalausky a...@a.a: Caligo iteronve...@gmail.com wrote in message news:mailman.451.1294306555.4748.digitalmar...@puremagic.com... Perhaps using a modern SCM like Git might help? Everyone could have (and should have) commit rights, and they would send pull requests. You or one of the managers would then review the changes and pull and merge with the main branch. It works great; just checkout out Rubinius on Github to see what I mean: https://github.com/evanphx/rubinius I'm not sure I see how that's any different from everyone having create and submit a patch rights, and then having Walter or one of the managers review the changes and merge/patch with the main branch. With the risk of starting yet another VCS-flamewar: It gives the downstream developers an easier option to work on multiple patches in patch-sets. Many non-trivial changes are too big to do in a single step, but requires series of changes. Sure, the downstream hacker could maintain import/conversion to VCS, but with added job, and when Walter or someone else gets to review they are no longer well-annotated patches. It also facilitates a setup where Walter (BDFL? ;) starts to trust some contributors (if he wants to) more than others, for them to work on private branches and submit larger series of patches for each release. Especially, when you detect a showstopper bug that blocks your progress, IMHO, it's easier using a DVCS to maintain a local patch for the needed fix, until upstream includes it. I've often used that strategy both in D-related and other projects just to remain sane and work-around upstream bugs, I just usually have to jump through a some hoops getting the source into DVCS in the first place. I think it was on this list I saw the comparison of VCS:es to the Blub-problem? http://en.wikipedia.org/wiki/Blub#Blub Although, I don't think the current setup have any _serious_ problems, I think there might be slight advantages to gain. OTOH, unless other current key contributors wants to push it, it's probably not worth the cost of change.
Re: Less commas
2011/1/2 Peter Alexander peter.alexander...@gmail.com: That really surprises me that it's a common bug. Isn't it obvious that ! has higher precedence than ? Or have I totally misunderstood the cause of the bug? Assembler is obvious. People don't always get that right either. The purpose of a higher-level language IMO, is to make it easier for the developer to express his/her intentions, and pitfalls like this should be avoided. IMHO, the most important job of a high-level language is to encourage good programming practices. There's a reason why people aren't seriously using Brainfuck. It's not because it's not turing-complete, it's because it's simply difficult to get right. There's also a reason why object oriented languages were invented. It's not because you can't do object-oriented code in C, it's because object orientation in an object-oriented language is easier and more readable. Programming languages is all about encouraging preferred models.
Re: D without a GC
2011/1/3 Iain Buclaw ibuc...@ubuntu.com:
== Quote from bearophile (bearophileh...@lycos.com)'s article
Dmitry Olshansky:
As stated in this proposal they are quite useless, e.g. they are easily
implemented via mixin with alloca.
Thank you for your comments. Here I have added some answers to your comments:
http://d.puremagic.com/issues/show_bug.cgi?id=5348
Bye,
bearophile
Some thoughts to your proposal:
void bar(int len) {
Foo* ptr = cast(Foo*)alloca(len * Foo.sizeof);
if (ptr == null)
throw new Exception(alloca failed);
Foo[] arr = ptr[0 .. len];
foreach (ref item; arr)
item = Foo.init;
// some code here
writeln(arr);
foreach (ref item; arr)
item.__dtor();
}
1) Why call the dtors manually? Forgive me if I'm wrong, but iirc, alloca will
free the memory when the stack exits from the current frame level. :)
The dtor doesn't free memory, it allows the class to perform cleanup
on destruction, such as close():ing any native FD:s etc.
Actually, AFAICT, the above code should also after item=Foo.init
call item.__ctor(), to allow the constructor to run.
IMHO, stdlibs should provide wrappers for this type of functionality.
An application-writer should not have to know the intricate details of
__ctor and __dtor as opposed to memory-mangement etc. A template
stackAllocate!(T) would be nice.
Re: Advocacy (Was: Who here actually uses D?)
Messier is a matter of perspective. C is a beautifully clear and mature language, but some of the missing features (delegates for one) often leads to unnecessarily convoluted code. Hejlsberg describes it quite well as Simplexity, roughly speaking, when the tools are too crude, the produced result might not look as refined as with better tools. http://www.artima.com/intv/simplexity.html 2011/1/2 Jimmy Cao jcao...@gmail.com: On Sun, Jan 2, 2011 at 12:38 AM, Caligo iteronve...@gmail.com wrote: I agree with you on this. For example, Linus Torvald hates C++ and probably for good reasons. I think he hates C++ because it's messier than C. Many things are messier than C, including D.
Re: Advocacy (Was: Who here actually uses D?)
So why is D being advertised as a systems programming language? By saying Linus would not find D appealing you are basically saying kernel developers would not find it appealing. Systems programming in my vocabulary is not limited to JUST kernel programming. To be honest, I think D has a pretty long way to go to be good for kernel development (irregardless of Linus/Linux). For kernel development I suspect stop-the-world GC, or any non-deterministic GC for that matter is a big no-no. Also, imagine the current frustration over compiler/stdlib-bugs if you're operating in kernel-space, with no GDB to help you track it down. That's not to say I don't think D COULD be used for kernel development, but at the current state of things, I don't think it's really a promising cost/benefit. But systems development in my world doesn't end with the kernel, system-development is everything up to the applications the users really want, all libraries, codecs, file-format implementations etc. I.E. i would be really interested to see what kind of systems-API could be developed directly against the kernel ABI of *BSD or Linux, if you ignore the libc-layer. I.E. what would a completely event-driven (twisted) close-to-os stdlib look like, and how would that improve the simplicity of writing performant I/O-driven applications? Currently, however, I think the D community (which I'm increasingly being pulled into by common interests) should really focus on low-hanging fruit, and proving to the larger developer-community why D is worthwhile. In this area, I think the timing of D is perfect, given the current trend of cheaper hardware, rather than more powerful hardware. For instance are there currently any good database-implementations in D, suitable for beating the Tracker/Beagle/Strigi Desktop-search mess of the open source desktops? Integrating such database with the upcoming Linux fanotify API and libextractor should be an achievable goal, and could perhaps even be a compatible drop-in replacement for I.E. Tracker, but with lower footprint? I also have a stripped binding for FUSE as part of BitHorde, so implementing a fuse-based metadata-browser should be doable for integrating metadata directly into the Linux VFS. Definitely good for showing off.
Re: GC conservatism -- again
Sorry for not replying, I've had some personal issues recently that have taken up all of my time. Your suggestion seemed workable for solving the dereferencing issue, but leaving the destroyed objects in an invalid state seems likely to cause weird bugs. And the objects can't safely be reset to their initial state (ala. clear) after destruction for concurrency reasons. So I'm not sure it will really help all that much in practice. It wouldn't be a tremendous amount of work to try this out though. On the druntime-list, it was also pointed out that the assumption that related objects are collected either in the same run or in reference-order are not true for all GC-types, I.E. not for incremental GC:s. Therefore it seems like a bad semantic to impose on the GC, in case someone wants other GC:s some day. The problem I've encountered in D, is that support for complementary predictable allocation schemes which could alleviate some of the problems (i.e. reference-counting and tree-allocation), is quite weak. By weak, I mean undocumented and no supporting framework from the stdlib. In a perfect world, this could even work hand-in-hand with the GC, such that references to refcounted-object could be voided from the destruction of the reference-counted object. There's been some talk of doing this, but other things have had priority. Is this a discussion that should be held in Phobos/Tango, druntime, or on this list? The druntime list would be most appropriate, but it has very few members (partially because so few people are interested in this level of code, I suspect). The most expedient solution would be to just write the code and submit a patch for evaluation. FYI: I don't have access to build-env for D2/druntime, but I've created an implementation for RefCounting for Tango, in http://www.dsource.org/projects/tango/ticket/2024. It might be of interest to port to druntime, with the mentioned D2-improvements to SmartRef.
Re: Who here actually uses D?
Hi, I'm using D (D1,LDC+Tango) both professionally and for hobby-projects. At work, I'm using it mainly for an in-house developed all-purpose Mpeg2-TS processing library. (Records, streams, analyzes and clips Mpeg2 Transport Streams). All-in all, it's working out fine. I've hit some Tango bugs (really just one i can remember, #1331 regarding Multicast on Linux), but no LDC-bugs here. As a hobby, I'm developing a content-distribution-system at www.bithorde.org. Here I've hit one LDC-bug AFAIR, and a few Tango-bugs, in general problems with immaturity in the D ecosystem has been more of a frustration. Not only the pure bug-frustrations, but using libraries that turned out to be incompatible regarding the Tango/Phobos-problems, missing documentation, some frustrated community members, using libraries that turns out to be unsupported. All in all, general problems related to uncharted territory. My solution in both cases, since I use Ubuntu as the workstation both at home and at work, have been to fork slightly old versions of Tango and LDC and manually applied just the patches that looks safe, and useful to me, instead of tracking the tips of either project. I've then created a PPA at https://launchpad.net/~rawler/+archive/d-packaging. It's worked acceptably, although quite some hours have went into this of course. All-in-all, I would rate my D-experience as a 3/5, not unacceptable, but not reaching it's full potential either. I still believe D has a lot of potential though, which is why I'm sticking with it even when upfront-costs are a bit high. I.E. I'm currently side-tracked working on developing and documenting a simple safe Reference-Counting framework that might hopefully be included in Tango and Druntime, instead of realizing my own ambitions of BitHorde. / Ulrik 2011/1/1 Robert Clipsham rob...@octarineparrot.com: Having seen a post by Peter Alexander (in Re: D for game development), mentioning some of the issues he's hit I thought I'd post this. I've been in his shoes (every other time I use D it seems), and feel I should ask - who here uses D, and to what extent? I'm mostly interested in those of you with 1000 Line plus projects in D, as that's when I've found I start hitting issues. Just to clarify, for those D purists among you... I'm not trolling, just curious (I wouldn't normally have asked, but now I know I'm not paranoid and the only one having problems, I thought I'd ask). -- Robert http://octarineparrot.com/
Advocacy (Was: Who here actually uses D?)
2011/1/2 Robert Clipsham rob...@octarineparrot.com: Unfortunately, it's impossible to create such a system without people being paid to work on dmd and the runtime - people will fix the bugs they want to, you can't make them fix anything. Obviously you can influence what gets fixed, not to a huge extent though. Ideally the voting system would outline what needs the most effort, but people don't idle on bugzilla enough for it to work so well. I wonder if changing the 'vote' button to a 'like' button would make any difference, if facebook's any indication, people like to like things ;p Personally, I think the community is a key focus area. D cannot survive without a thriving community, both in the core projects (language design, compilers, stdlibs, druntime etc.), and in applications (especially highly visible killer-apps). I think it's absolutely critical to work on advocating the language, especially I feel D is currently missing killer-apps demonstrating why learning D is worthwhile. Let's be honest, coming into the market of C-style imperative languages in the second half of this past decade isn't exactly easy. There are already C/C++ for the performance-crazed, and Java/C# for the convenience-minded. The only complaint I ever hear in that landscape, is that C/C++ is just too much hazzle to work with, and C#/Java is ridiculously resource-hungry, partly in CPU but even more so regarding RAM consumption. Of course most users don't care, but the few passionate developers feeling this, THEY are the audience D appeals to. I think it's important to intentionally target them in advocacy. D cannot succeed in doing everything. It certainly cannot compete with Ada on writing secure stable code, and it cannot compete with C in low-level programming simply due to the sheer established mass. The one area where there is currently an unexploited opportunity is in the corner between productive yet efficient, and this is where D shines, which most developers currently do not know. On a side-note (and I'm clearly biased here so I hardly even take myself very seriously), I think the non-windows os:es, especially Linux, should also be an intentional focus-area. It is VERY difficult to compete with .NET on Windows, and somehow I don't think we'll find most of the efficiency-focused audience there, but if D can demonstrate it's usefulness in key systems components in Linux, it's likely to attract more curious right-minded developers. I'm not sure exactly how to realize this, but there may be two opportunities in quickly providing a lightwheight attractive desktop environment for the upcoming Wayland system, as well as someone finally writing a disk-indexing system that doesn't eat all your disk-bandwidth and ram during the first week. In any case, I think it's also very important to remember developers should only make up a small part of a good community, even a software development community. We need webdesigners, advocates, testers, people doing bugzilla maintenance, documentation experts, writers, artists, and just about anyone who can spare a couple of hours of the week since they want more efficient software (even if they don't know how to do it themselves). Just discovering http://d-programming-language.org/ with much nicer presentation of the docs I've already seen, raised my motivation for D just as much as any random dozen solved bugs from bugzilla. Attracting people to D is IMHO MUCH more important than any particular bug or especially new feature. If I got my wish, I would very much like to see some of the core devs allocating 75% of their time of for the next months on not doing core work, but ONLY doing things to attract new developers; I.E. * Try to get D into the Debian Language Shootout Again? * A simple web-server beating apache performance (maybe even nginx?) would be a reasonable goal, which would make great headlines, and in short time. If you can also show it's source-code is comprehensible to any medium-skilled Java dev, you've probably got yourself many new prospective developers. * Follow up new developers with top-notch support for the more promising ones to make sure they don't bounce back out. * Brush up the documentation aimed at beginners, and try to get a few articles and tutorials published (at least slashdotted) Given these above, which to my knowledge isn't done as of now, I think it's not unreasonable to expect a sizable growth in both active community and external visibility. Now, time for me to go to bed. (It's 06:00 here) when I wake up later today, I'm hoping to have the list full of further ideas, suggestions and thoughts on how to grow the community, except for implementing D3/4/5 100% bugfree. :)
Re: Why Ruby?
2010/12/21 Walter Bright newshou...@digitalmars.com: Jonathan M Davis wrote: On Tuesday, December 21, 2010 13:37:55 Walter Bright wrote: A novice follows the rules because he is told to. A master follows the rules because he understands them. A guru breaks the rules because the rules don't always apply. So, is that a (possibly paraphrased) quote or just highly quotable? I heard it a very long time ago, and I do not know where it originated, or even if it wasn't just coined by my friends. I think it stems from a traditional Japanese model of learning, known as the Shu-Ha-Ri. As usual, Wikipedia gives a good overview. http://en.wikipedia.org/wiki/Shuhari
Cross-post from druntime: Mixing GC and non-GC in D. (AKA, don't touch GC-references from DTOR, preferably don't use DTOR at all)
Cross-posting after request on the druntime list:
--
Hi,
DISCLAIMER: I'm developing for D1/Tango. It is possible these issues
are already resolved for D2/druntime. If so, I've failed to find any
information about it, please do tell.
Recently, I've been trying to optimize my application by swapping out
some resource allocation (file-descriptors for one) to
reference-counted allocation instead of GC. I've hit some problems.
Problem
===
Basically, the core of all my problems is something expressed in
http://bartoszmilewski.wordpress.com/2009/08/19/the-anatomy-of-reference-counting/
as An object’s destructor must not access any garbage-collected
objects embedded in it..
This becomes a real problem for various allocation-schemes, be it
hierarchic allocation, reference counting, or a bunch of other custom
resource-schemes. _It renders the destructor of mostly D useless for
anything but mere C-binding-cleanup._
Consequence
===
For the Reference-Counted example, the only working solution is to
have the counted object malloced, instead of GC-allocated. One could
argue that correct programs with reference-counting should do the
memory management completely explicit anyways, and yes, it's largely
true. The struct-dtor of D2 makes the C++ smartptr-construct
possible, making refcount-use mostly natural and automatic anyways.
However, it also means, that the refcounted object itself, can never
use GC-allocated structures, such as mostly ANYTHING from the stdlib!
In effect, as soon as you leave the GC behind, you leave over half of
all useful things of D behind.
This is a real bummer. What first attracted me to D, and I believe is
still the one of the key strengths of D, is the possibilities of
hybrid GC/other memory-schemes. It allows the developer to write up
something quick-n-dirty, and then improve in the places where it's
actually needed, such as for open files, or gui-context-handles, or
other expensive/limited resources.
As another indication that is really is a problem: In Tango, this have
lead to the introduction of an additional destructor-type method
dispose, which is doing AFAICT what the destructor should have done,
but is only invoked for deterministic destruction by delete or
scope-guards. IMO, that can only lead to a world of pain and
misunderstandings, having two different destructors ran depending on
WHY the object were destroyed.
Proposed Solution
=
Back to the core problem An object’s destructor must not access any
garbage-collected objects embedded in it..
As far as I can tell (but I'm no GC expert), this is a direct effect
of the current implementation of the GC, more specifically the loop
starting at
http://www.dsource.org/projects/druntime/browser/trunk/src/gc/gcx.d#L2492.
In this loop, all non-marked objects gets their finalizers run, and
immediately after, they get freed. If I understand the code right,
this freeing is what's actually causing the problems, namely that if
the order in the loop don't match the order of references in the freed
object (which it can't, especially for circular references), it might
destroy a memory-area before calling the next finalizer, attempting to
use the just freed reference.
Wouldn't it instead be possible to split this loop into two separate
loops, the first calling all finalizers, letting them run with all
objects still intact, and then afterwards run a second pass, actually
destroying the objects? AFAICT, this would resolve the entire problem,
allowing for much more mixed-use of allocation strategies as well as
making the destructor much more useful.
Alternate Solution
==
On the druntime-list, Vladimir suggested something similar could be
achieved by simply creating a custom allocator which automatically
adds it's pool to the GC-root. This would solve my problems
satisfactory, and it is probably what I'm going to do for my immediate
problem.
I believe (again, no GC-expert) it may even have the advantage of
relieving some pressure from the GC, in terms of objects it really
has to track.
However, it has the disadvantages that,
* the GC can no longer be used as a fallback/safety net, putting
extra burden of correctness on the programmer (perhaps a good thing?)
* destructors on regular GC-objects still cannot touch related
objects. I.E. consider the following example. Yes, pretty bad design,
but it's non-obvious why it's invalid, and intuitively not expected to
cause segfaults.
class List {
int count;
class Entry {
this { count++; }
~this { count--; }
}
}
--
I strongly believe the language/runtime should not needlessly lay out
non-obvious traps like this for the developer. For a C++-convert it
is quite counterintuitive, and even if you know about it, it's tricky
to work-around.
I think both solutions have their merits, but short of serious
performance-issues with the first proposed solution, I think it's
preferable. I also
BitHorde public beta released
BitHorde is a new content distribution system developed in D/Tango. The main concept of BitHorde is one of a F2F-routing network with caches in each node, caching popular content to increase availability and throughput. BitHorde separates Content from Metadata, handling only content, identified by hash, and doesn't care about metadata (including filenames). BitHorde features; * Efficent system-daemon. Doesn't use more RAM and CPU than necessary and tries to stay out of your way. * FUSE-filesystem access to let any application immediately access content * Multiple checksum-generation to be able to identify assets from multiple schemes (currently sha1, tree:tiger and ed2k). * ... More to come BitHorde can have many possible practical applications including; * Optimized CDN solutions, for streaming delivery of heavy assets, for example Video On Demand * File-Sharing * Keeping your home-media-collection partially available on the go. Popular assets are stored in the cache on the laptop-harddrive, while all content is available when internet connection is available. * Digital Asset distributions in Online Multiplayer games Short demo video: http://vimeo.com/10676999 (Old version and poor narration, sorry about that.) Website: http://www.bithorde.org Source code: http://github.com/rawler/bithorde Ubuntu PPA for convenience: https://launchpad.net/~rawler/+archive/bithorde Jabber Multiuser Conference: bitho...@jabber.org Note the version-number 0.1-beta1. The system is functional, but not all planned features are available and your mileage may vary. There's a demo-node on bithorde.org:1337, featuring the video Sintel. After getting bithorde and bhfuse up and running, try checking out videoplayer of choice 'bhfuse mountpoint/magnet:?xt=urn:tree:tiger:H5WMLKREL2KPAZEZRBPRP6HDRZX6MBEULGH3W2A'. (Assumes an internet connection capable of 8mbit+ throughput to the host located in Sweden, or you will have to pre-cache the asset.) All testers, coders, documentation-gurus or otherwise interested is welcome. / Ulrik
Re: Suggestion: Syntactic sugar for Exception handling in D2
If it's braces you're concerned with, D doesn't actually require them on try/catch/finally like many other languages: As I said, the braces is just the small obvious benefit. The larger benefit IMHO is the less obvious shift in how you think about exceptions, but I'm not sure that argument is worth anything if you haven't experienced it personally. Writing braces is even done automatically by some editors, but thinking of exception handling as a natural part of a method (just like in/out contracts are part of the method, and unittests/invariants are a natural part of a class). It's about how the language encourages the developer to think about certain aspects, and that is of course almost impossible to really assess the value of.
Suggestion: Syntactic sugar for Exception handling in D2
One thing I often encounter in D, and other languages, is functions looking
something like;
void myfunc(Obj input)
{
try {
do_something(input);
} catch (SomeException e) {
handle_error(e);
}
}
While there's no real problem with this code, I have some experience from Ruby,
which has added some syntactic sugar regarding this, making all code-blocks a
potential try-clause, if there's a catch-block (or finally).
In D, it would look something like (and have the exact same semantic meaning of
the code above);
void myfunc(Obj input)
{
do_something(input);
}
catch (SomeException e)
{
handle_error(e);
}
IMHO, this syntactic addition gives a few advantages;
* Makes the code slightly more readable, since the exceptional code-paths
are clearly separated
* Biases me as a programmer to think a little bit more of exactly what
exceptions can be raised in a function, improving my code-quality.
* When I'm about to write a try-clause, makes me think twice if the code
could not be extracted as a separate method instead (if I can only figure a
good name for it), also improving readability and code-structure.
To sum up; while this is purely syntactic sugar, my personal experience from
Ruby is that this syntax encourages better coding on my part, which I think
would be a good thing to incorporate in D.
One thing, I'm pondering though, is exactly in what blocks this should be
allowed, and what semantics should apply.
* Inner anonymous functions?
* If statements?
* For-loops? If so, is the try for the entire loop, or per iteration?
* How does this relate to the contract-programming-features in D?
Comments / opinions on this, anyone?
Re: Suggestion: Syntactic sugar for Exception handling in D2
To be honest, while the only obvious benefit is shorting down the number of braces slightly, the real benefit I experienced from practicing it in Ruby were a slight change in how I actually think about exception handling. It's very hard to quantify how much benefit it really is, but I agree on that it will make the parsing a bit backwards. If it's a big hassle I don't think it's worth it, but if it can be added easily in some already-existing phase, I think it should be seriously considered. Daniel Keep Wrote: I like the idea from a DRY perspective. That said, it's a bit problematic in that you can't tell if any given block has an exception handler until you find the end of it and check. As much as it looks like a nice simplification, I'm not sure this has enough benefit to be worth it.
